Introduction

One of the challenges faced in Frida’s Gadget mode is an issue where the process you’re injecting into resumes immediately after injecting the JavaScript. This behavior prevents early instrumentation, which can be crucial for certain analysis tasks. In this blog post, I will guide you through a workaround to fix this issue.

When it comes to dynamic analysis and instrumentation of applications, Frida stands out as an indispensable tool in the kit of developers, reverse engineers, and security researchers alike. Its Gadget mode, in particular, offers unparalleled flexibility, allowing users to inject custom scripts into their target applications seamlessly. However, there’s a snag in the system that’s been tripping up professionals—early instrumentation.

Imagine setting up a meticulous script, ready to unravel the inner workings from the very inception of a process only to find that Frida has already allowed the application to resume before your instrumentation could catch the critical initial functions. This challenge has been particularly pronounced with the latest release, version 16.1.11, posing a significant obstacle to those needing to hook functions at the outset of program execution.

This blog post is forged from the need for a solution—crafted for persistence, it’s a beacon of hope for those grappling with this issue. Herein, we’ll walk through the intricacies of Frida’s Gadget mode and unveil a strategic approach to modify the resume_on_attach flag, a crucial step in gaining the control you require for early instrumentation. By the end of this guide, you’ll have mastered the method to hold the execution reins, ensuring your scripts are primed to hook at the starting line.

Join me as we delve into this technical deep-dive, transforming a point of frustration into a triumph of technical prowess.

Choosing Gadget Mode over Server Mode

In gernal, Frida provides 2 modes for injection, Sever mode and Dadget mode. I am debug an ARM32 program on an embedded patlform. And I tested, the server mode is not very reliable , may because the limit RAM on the dev board, and the dev board may reboot after I start frida-server, It’s very annonying, So I select Gadget mode,and reboot issue goes away. Frida offers two distinct modes for script injection: Server Mode and Gadget Mode. When working with ARM32 programs on embedded platforms, one must consider system constraints. My experience revealed that Server Mode could be unstable, potentially due to the limited RAM available on the development board. This instability often resulted in the board rebooting after initiating frida-server, which was disruptive to the debugging process.

Given these challenges, I opted for Gadget Mode. This alternative proved to be more stable under the same conditions, eliminating the frustrating reboot issues. Gadget Mode’s lightweight footprint makes it better suited for environments with resource limitations, thereby providing a more seamless and reliable debugging experience for ARM32 embedded systems.

The Solution: Modifying resume_on_attach

The root of this issue lies within the default behavior of Frida’s Gadget mode, which is controlled by the resume_on_attach field of the ControlChannel class. This field dictates whether the process should resume immediately after Frida attaches to it.

Step by Step Fix

Here’s a step-by-step guide to addressing this issue:

1. Modifying the ControlChannel Class

Locate the ControlChannel class definition within the frida-core/lib/gadget/gadget.vala file. Search for the resume_on_attach field and change its default value to false.

1
2
3
4

class ControlChannel {
  private bool resume_on_attach = false; // Change from true to false
  // ...
}

2. Compile Frida with Modified Code

After making this change, recompile Frida to incorporate the modification. Ensure you have all required dependencies and follow the standard build instructions provided in the Frida documentation. This github repository provides docker images for compiling Frida.

3. Using the Modified libGadget.so

Replace the original libGadget.so with the newly compiled version. With this change, the process will no longer resume immediately, allowing your JavaScript to hook functions at the very start of the execution.

4. Utilizing Python Script for Process Resumption in Frida Gadget Mode

While working in Frida Gadget mode, a common approach to inject a JavaScript payload into the target process would involve using the frida command from the Frida-tools package, like so:

1

frida -H <Board IP address> -n Gadget -l <Javascript file>

Executing this command initiates the injection, but it doesn’t automatically resume the process once the JavaScript file is loaded. Attempts to resume the process manually with %resume in the Frida REPL might not yield success.

To overcome this hurdle, I developed a Python script—a more reliable solution. The script not only injects the JavaScript code but also effectively resumes the process afterwards. Below is the functional part of the script where the device.resume(pid); command is used to resume the process:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

# Python script to inject JavaScript and resume process in Frida Gadget mode
import frida

# Establish a connection to the target device
device = frida.get_device_manager().add_remote_device("<Board IP address>")

# Specify the target process identifier (replace 'pid' with the actual process ID)
pid = 'pid'

# Path to the JavaScript file you want to inject
js_file_path = "<Javascript file>"

# Read the JavaScript code from the file
with open(js_file_path, 'r') as file:
    js_code = file.read()

# Inject the JavaScript code into the process
session = device.attach(pid)
script = session.create_script(js_code)

# Load and execute the JavaScript code
script.load()

# Resume the process to continue its execution with the injected code
device.resume(pid)

print("JavaScript injected and process resumed.")

By employing this script, we ensure that the injection and process flow are controlled as expected, thus maintaining the stability of the debugging session.

Conclusion

This blog post addressed early instrumentation challenges in Frida’s Gadget mode and provided a solution by modifying the resume_on_attach flag. Gadget mode was recommended over Server mode for ARM32 programs on embedded platforms due to its stability. A Python script was introduced for injecting JavaScript and resuming the process, ensuring a controlled debugging session. Overall, this post offers a solution for fixing early instrumentation in Frida, empowering developers and researchers to gain insights into application behavior from the beginning.

Introduction

This blog post aims to provide a method for accurately identifying the version of the NDK (Native Development Kit) used in a .so file within the Android platform.

Methodology

In certain situations, it becomes necessary to confirm the specific NDK version utilized in the .so files of an APK. Once achieve this, we can compile our own binary code using the same NDK version and subsequently patch the resulting binary into the .so files in order to accomplish our objectives. It is crucial to note that using a different version of the NDK may lead to ABI (Application Binary Interface) incompatibility issues with our binary.

Test Case: “Rise of Saiyan” Android Game

For the purpose of illustration, we will employ the Android game called “Rise of Saiyan.” You may download the game from the following link: Rise of Saiyan. Within this game, there exists a shared library file named libcocos2dlua.so.

Locating the Magic Word

The initial step involves finding the magic word, which in this case is “Android”. We can accomplish this by executing the following command:

1
2

$ strings -tx libcocos2dlua.so | grep "Android$"
13ab850 Android

As demonstrated, we successfully discovered the magic word located at offset 0x13ab850.

Extracting the NDK Version String

Next, we proceed to extract the NDK version string by hexdumping the content beginning from the identified offset:

1
2
3
4

$ hexdump -C -n 30 -s $((0x13ab850)) libcocos2dlua.so
013ab850  41 6e 64 72 6f 69 64 00  15 00 00 00 72 32 31 65  |Android.....r21e|
013ab860  00 00 00 00 00 00 00 00  00 00 00 00 00 00        |..............|
013ab86e

By analyzing the hexdump, we successfully identified the NDK version string as r21e. This information allows us to download the corresponding NDK version.

Conclusion

In conclusion, this blog post presents a straightforward method for identifying the NDK version string within a .so file. By following the outlined steps, developers can accurately determine the NDK version and proceed with their required tasks effectively and efficiently.

Disclaimer

Please note that the information provided in this blog post is intended for educational and informational purposes only. Any application of the techniques and tools mentioned in this post must be carried out responsibly and in accordance with local and international regulations and laws.

Attempting to hack software, including games, without express permission from the owners is strictly illegal and unethical. The author and the publishers of this blog do not condone, encourage or endorse any illegal activity, and any actions taken based on the contents of this blog will be solely at your own risk.

We strongly encourage readers to use this information to enhance their understanding of the underlying mechanisms of software and to promote improved security, rather than for ulterior purposes. This blog, its author, and its publishers bear no responsibility for misuse of the information provided.

Introduction

Hey there! Ever wondered how exciting it would be to peek under the hood of your favorite Android games, particularly the ones built using cocos2d? Well, this blog post will walk you through just that. But we’re not talking about cheats or shortcuts, we’re diving into game hacking — the good kind.

First off, why cocos2d? It’s a user-friendly, open-source software perfect for building games. On the other hand, Frida is a programmer’s secret weapon, akin to a multi-tool. It’s a powerful toolkit that allows you to weave your code seamlessly into an already-running process. This incredible ability to inject and inspect code in real-time, without causing a ruckus, makes Frida an essential instrument for any coder’s toolbelt.

Now, don’t worry if you aren’t a coding whiz. This guide is meant for anyone curious about how games work. A basic grip on the Android system, a touch of Typescript, a little bit of C++ and a whole lot of enthusiasm are all you need to level up. Ready for the ride? Let’s get started!

Create C++ module for hacking

To illustrate, I make use of a 2D game. This game adopts a unique format, defined by its developers, to house its animations. The asset files associated are denoted with a .ROM extension.

Each of these asset files can encompass multiple actions. In turn, each action is made up of several steps. Intriguingly, each step in this context represents an image. These images, which constitute the steps, might exhibit differing dimensions.

I plan on developing a C++ module that can be injected into the process for hacking. A detailed outline of this procedure can be found on my blog post.

Static analysis

Static analysis, also known as code review, is the process of examining source code without executing it, focusing instead on its structure, dependencies, and patterns. It is a widely accepted preliminary step in understanding the functionality of any software or application, including games built on frameworks like cocos2d.

Begin by familiarizing yourself with the cocos2d framework. Cocos2d is an open-source software development kit for developing games and other graphical applications. I can get cocos2d’s code from here: github.com/cocos2d/cocos2d-x.

Thoroughly reviewing the source code of the framework greatly benefits our endeavor to understand software in-depth, an essential step for ethical hacking. However, we should acknowledge that the openness of open-source platforms does present a double-edged sword. Despite its numerous advantages, it also opens a gateway for potential misuse. The exposure of the source code presents an intimate understanding of a software’s underlying mechanisms, which, while essential for improving and learning, can be exploited if it falls into the wrong hands.Reviewing the framework source code is very helpful for our hacking work. So I should say open source has its dark side. source code provides valuable insight into the underlying mechanisms of software.

Extracting information from binary

Typically, Android games developed using the Cocos2D framework incorporate a shared library known as libcocos2dcpp.so. This integral component houses the core logic underlying the game’s operations and interactions, serving as a centerpiece for the game’s design and execution.
I plan to conduct a detailed examination of this file in order to glean more comprehensive insights about the underlying mechanics of this Android game. This in-depth analysis will allow me to understand its structure and functionality more precisely.

file

1
2

$ file libcocos2dcpp.so
libcocos2dcpp.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /system/bin/linker, stripped

The result derived from executing the file command implies that the file is an ELF file, and is a ARM32 archtecture.

Ghidra

I utilized Ghidra for analyzing the shared library under examination. This comprehensive software reverse-engineering tool revealed that the library exports numerous symbols that can be invoked. A symbol that particularly caught our attention is _ZN7cocos2d14cocos2dVersionEv. This symbol is associated with a C++ function cocos2d::cocos2dVersion().

However, it’s important to note that the symbol name only provides information about the function’s namespace, name, and argument types. We can’t ascertain the return type solely from the symbol’s name. Fortunately though, we have access to the source code. By cross-referencing the function within the source code, I was able to determine that its return type is char*.

The following code illustrates the cocos2d version is cocos2d-x 3.3rc0

1
2
3
4

namespace cocos2d {
    char* cocos2dVersion();
}
LOG_INFO(" Cocos2d version: %s",  cocos2d::cocos2dVersion());

Once we precisely identify the version of the Cocos2d framework being used, it opens up the possibility to retrieve the exactly corresponding version of the source code.

Define C++ classes

In the process of extracting images from asset files, I lean on the capabilities of a particular C++ class called ActionGroupClass during the Ghidra analysis phase. This class not only streamlines the extraction process but also boasts of several utility methods.
The following is the class define I infered from Ghidra

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

namespace cocos2d{
    struct Texture2D;
}

struct ActionGroupClass{                                                                                                                     
    unsigned char _0x0[0x102];                                                                                                               
    unsigned short _totalActionCount;                                                                                                         
    ActionGroupClass();                                                                                                                      
    void vQuickLoad(unsigned char*, bool, int, int);                                                                                         
    void vGetBaseXY(short, float*, float*);                                                                                                  
    int GetTotalStep(short);                                                                                                                 
    void vGetVectorXY(short, short, short*, short*);                                                                                         
    bool GetPictureIndex(short, short, unsigned char*);                                                                                      
    ~ActionGroupClass();                                                                                                                     
    cocos2d::Texture2D* GetTexture2DwithAction(short, short);                                                                                
};                                                                                                                                           
static_assert(offsetof(ActionGroupClass, _totalActionCount) ==0x102, "_totalActionCount not at offset 0x102");             

This class, ActionGroupClass, is designed and implemented by game developers, which means it isn’t found directly within the Cocos2D framework.
Game developers have also defined several global variables, each of which is of the ActionGroupClass type. These variables are utilized throughout the game for various purposes, depending on the specific characteristics and methods defined within the ActionGroupClass.
We can utilize these global variables to extract images from asset files. In addition, the shared library should contain code within the .init section. This code is responsible for calling the constructor method of the ActionGroupClass on these global variables. This initialization is essential in setting up the initial state for these global instances.
In addition, modern C++ provides a way to call a constructor on an already allocated memory. This is called placement new. Here’s how it works:
In C++, the new keyword typically allocates memory and then constructs an object in the allocated memory. However, there are times when you want to separate these two operations. For example, when you have already allocated memory and just want to construct an object at that memory location you can use “placement new”.
Here is the general syntax:

1
2
3
4
5
6

#include <new>
    ...

    auto* p = (unsigned char*)&FishActionGroup;                                                                                              
    auto* fishActionGroup = new((void*)p) ActionGroupClass();   

We can use this way to call constructor method in these global variables.

Dynamic analysis

Dynamic analysis involves the live examination of a system while it’s operational. In terms of hacking a cocos2d Android game using the Frida toolkit, dynamic analysis enables us to inspect and alter the game while it’s being actively played. This can provide insights that are not available during static analysis—when the program or game is not running.

Read string for a pointer to std::string.

When dealing with the Android NDK, there are numerous elements involved when implementing the Standard Template Library (STL). Since I’m utilizing a recent version of the NDK, the conventional method of extracting a string from a std::string variable using std::string::c_str() is unfortunately not applicable. Hence, a different approach is needed. After a detailed analysis of the memory layout connected to a std::string variable within the process, I have developed the following function to accurately extract the required string.

1
2
3
4
5

const char* getStringCStr(std::string& str){                                                                                                 
    auto* p = (unsigned char*) &str;                                                                                                         
    auto* s= *(char**)&p[0x00];                                                                                                              
    return s;                                                                                                                                
}    

Get RTTI

The shared library has been configured with Run-Time Type Information (RTTI) enabled. This setup allows us to extract RTTI using a pointer referring to a class directly. To streamline this process, I have authored the subsequent function specifically tailored for this task.

1
2
3
4
5
6

#include <typeinfo>
const char* getInstanceTypeName(void* ptr){                                                                                                      
    void**  p = *(void***)ptr;                                                                                                                   
    std::type_info& t =*(std::type_info*)p[-1];                                                                                                  
    return t.name();                                                                                                                             
}   

Extract images from a asset file

Moving forward, let’s deftly invoke the inherent functions of our key class, ActionGroupClass, to systematically acquire all pertinent information concerning the graphic elements.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

char* romdata =  read_file_into_memory("/data/local/tmp/weapon1.rom") ;                                                                      
 if(romdata){                                                                                                                                 
     LOG_INFOS("%p", romdata);                                                                                                                
     fishActionGroup->vQuickLoad((unsigned char*)romdata, true, 30, 30);                                                                      
     free(romdata);                                                                                                                           
     romdata = NULL;                                                                                                                          
     auto totalActionCount = fishActionGroup->_totalActionCount;                                                                              
     LOG_INFOS(" totalActionCount %d", totalActionCount);                                                                                     
     for(auto action=0; action<totalActionCount; action++){                                                                                   
         auto totalStep = fishActionGroup->GetTotalStep(action);                                                                              
         float x, y;                                                                                                                          
         fishActionGroup->vGetBaseXY(action, &x, &y);                                                                                         
         LOG_INFOS(" action %d ,total step %d %f %f ", action, totalStep, x, y );                                                             
         short stepx, stepy;                                                                                                                  
         for(auto step = 0; step < totalStep; step++){                                                                                        
             fishActionGroup->vGetVectorXY(action, step, &stepx, &stepy);                                                                     
             unsigned char pic;                                                                                                               
             auto success = fishActionGroup->GetPictureIndex(action, step, &pic);                                                             
             LOG_INFOS(" action %d/%d step %d/%d base %f %f step %d %d pic %d ", action, totalActionCount, step, totalStep, x, y, stepx, stepy, pic);                                                                                                                                          
             auto* tex = fishActionGroup->GetTexture2DwithAction(action, step);                                                               
             auto w = tex->getPixelsWide();                                                                                                   
             auto h = tex->getPixelsHigh();                                                                                                   
             auto* format = tex->getStringForFormat();                                                                                        
             LOG_INFOS(" action %d/%d step %d/%d texture %p %d %d %s", action, totalActionCount, step, totalStep, tex, w, h, format);         
         }
     }
 }

Here’s an illustrative breakdown of its operations:

The first segment is devoted to reading a ROM file, specifically ‘weapon1.rom’, and storing it into memory. The in-memory address of this acquired data is logged for debugging purposes.

Next, the vQuickLoad method of fishActionGroup, an instance of ActionGroupClass, is invoked. This quickly loads in the binary content from the ROM data into our action group. Meanwhile, the parameters ‘30’ represent the default size in pixels for each sprite in the action.

The memory allocated to ‘romdata’ is subsequently cleared using ‘free’ to prevent memory leaks, and its pointer is nullified for safety.

Thereafter, we acquire the total count of actions stored within our action group by calling the _totalActionCount function. For every action, two tasks are performed: Firstly, the total number of steps related to that action are gathered. Secondly, the base coordinates (x, y) for that action are obtained via vGetBaseXY.

Each step per action is scrutinized next. This includes determining its directional vector (stepx, stepy) and the picture index related to each step. Moreover, the texture associated with each step of the action is also retrieved.

Finally, this section delves into extracting comprehensive details about said texture: the dimensions (width and height in pixels) and the format. This information, alongside other relevant details, is logged for every step in every action.

This meticulous process guarantees a thorough understanding of the movements, graphical elements, sizes, and properties involved, which immensely aids in manipulating or changing game assets for your desired outcome as part of your game hacking initiative.
After obtaining the pointers to Texture2D, it becomes possible to invoke the built-in functions within the class to save the graphic data to disk. However, elaborating on the specifics of this process falls outside the boundaries of this blog post. Therefore, we won’t delve into that here.

Conclusion

In this blog post, we explored the world of hacking Cocos2D Android games using Frida. We emphasized responsible and ethical use of the techniques and tools discussed. We covered static analysis, examining source code, and dynamic analysis for inspecting games while running. We discussed the extraction of images from asset files using the ActionGroupClass. Remember, unauthorized hacking is illegal and unethical. Use this knowledge responsibly to enhance your understanding of software and promote improved security. Happy exploring!

Hacking Android Game with Frida (Part3)

In the previous blog post, we discussed how to create a NDK project to interact with an Android game. In this follow-up article, we will delve deeper into the game’s internals by call fucntions in libmain.so.

Analyzing libmain.so

We have chosen a game for analysis because its libmain.so contains a multitude of interesting functions. To examine the symbols exported by the library, execute the following command:

1

readelf -sW libmain.so

In our case, the library exports over 36,000 symbols. In theory, we can call each exported symbol using C++. This presents an exciting opportunity for exploration.

Conducting Static and Dynamic Analysis of libmain.so

Before calling these functions from C++, it is essential to establish a goal. In our current scenario, our goal is relatively simple: we want to list all assets in the game, including their names and types. To accomplish this, we need to extract relevant class definitions from libmain.so. For static analysis, we will employ Ghidra, while Frida will assist us in adding hooks to key functions for inspecting the game’s internal state and memory data. Please note that this process is complex and time-consuming, but the results are well worth the effort. While we won’t delve into the entire analysis process in this blog, we will share the final results. The following are the classes we extracted for listing all assets in the game:

Note: These class definitions are highly dependent on the version of libmain.so used. The MD5 hash of the libmain.so file we worked with is e721395e3e327899a5a55ea4fb422a1c. Additionally, to ensure compatibility with a C compiler and facilitate analysis in Ghidra, I have utilized __cplusplus macros in the code. Ghidra supports C code, and by using these macros, we can import the code into Ghidra for easier analysis. This allows us to leverage Ghidra’s capabilities while working with the codebase.

VuAsset

1
2
3
4
5
6
7
8
9
10
11

// VuAsset
struct VuAsset
{
    void * _vtab;               // 0x00
#if defined(__cplusplus)
    std::string _name;          // 0x08
#else
    unsigned char _name[0x18];
#endif

};

The VuAsset class has a member variable, _name, of type std::string at offset 0x08, used to store the names of assets. In the ARM64 platform, a pointer occupies 8 bytes.

VuAssetDB

1
2
3
4
5
6
7
8
9
10
11
12
13

// VuAssetDB  size 0xe0
struct VuAssetDB{

    unsigned char _0x0[0x40 ];   // 0x00

#if defined(__cplusplus)
    std::map<std::string, std::vector<std::string>> _assetNames;  // 0x40
#else
    unsigned char _assets[0x18];
#endif

    // ...
};

The VuAssetDB class contains a member variable of type std::map<std::string, std::vector<std::string>> at offset 0x40, used to store the names of assets. The key of this variable is of type std::string, storing asset type names, while the value is of type std::vector<std::string>, storing asset names of the same type. We will utilize this class to print all asset names and types in the game.

VuAssetFactory

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

// VuAssetFactory size 0x190
struct VuAssetFactory {
    unsigned char _0x0[0x38 ]; // 0x00

#if defined(__cplusplus)
    std::vector<std::string> _assetTypeNames; // 0x38
    std::map<std::string, void*> _assetTypeInfos; // 0x50
#else
    unsigned char _asssetTypeNames[0x18];
    unsigned char _asssetTypeInfos[0x18];
#endif

    VuAssetDB* _vuAssetDB; // 0x68

    unsigned char _0x70[0x8];

#if defined(__cplusplus)
    std::unordered_map<unsigned int, VuAsset*> _loadedAssets; // 0x78
#else
    unsigned char _asssetTypeNames[0x28];
#endif


#if defined(__cplusplus)
    static VuAssetFactory* mpInterface;

#endif
    // ...
}; 

The VuAssetFactory class includes a member variable of type std::vector<std::string> at offset 0x38, used to store asset type names. We can utilize this member variable to print all asset type names. Additionally, this class has a member variable of type VuAssetDB* at offset 0x68 to store the pointer to VuAssetDB. Furthermore, it contains a member variable of type std::unordered_map<unsigned int, VuAsset*> at offset 0x78, used to store loaded assets. The key of this variable is of type unsigned int, representing the asset hash calculated by asset name, and the valueis of type VuAsset*, storing the asset pointer. Lastly, the class includes a static member variable of type VuAssetFactory* to store the global instance of VuAssetFactory. This class follows the singleton design pattern, allowing us to obtain the global VuAssetFactory instance using mpInterface.

Helper Function for Obtaining the Actual Class Name of VuAsset Children

Based on our analysis, we have observed that VuAsset acts as a base class for other asset-related classes. To simplify our tasks, we have implemented a helper function that allows us to retrieve the actual class names. Please find the code snippet below:

1
2
3
4
5
6

static const std::type_info& getTypeInfoOfInstance_ndk(void* p)               
{    
    p = *(void**)p;                                                           
    p = ((void**)p)[-1];                                                                                                                                     
    return *(std::type_info*)p;
}

Given that libgame.so is compiled with the RTTI (Run-Time Type Information) option, we can utilize the getTypeInfoOfInstance_ndk function to obtain the class information of instances. It’s important to note that we cannot directly use the typeid operator to retrieve runtime type information (RTTI) of an object. This is because libgame.so contains the RTTI information, and when we write our C++ code in libmousebot.so, the typeid operator will provide the RTTI information from libmousebot.so, which may lead to incorrect results. Since we don’t have visibility into how the derived classes of VuAsset are defined, the getTypeInfoOfInstance_ndk function helps us retrieve the accurate class information from libgame.so.

Print all assets names and types

Now, it’s time to rock! In this section, we will demonstrate how to print all asset names and types using functions provided by libgame.so. This will serve as a great starting point for exploring Frida’s capabilities and the powerful combination of Frida and C++.

1. Get global pointer to the instance of VuAssetFactory
   To begin, we need to obtain the global pointer to the instance of VuAssetFactory. This can be achieved with the following code snippet:

   1	auto* pVuAssetFactory = VuAssetFactory::mpInterface;

2. Get the instance of VuAssetDB
   Next, we retrieve the instance of VuAssetDB using the pointer obtained in the previous step. The code is as follows:

   1	auto* pVuAssetDB = pVuAssetFactory->_vuAssetDB;

3. List all assets in VuAssetDB
   In this step, we iterate through all the assets in VuAssetDB and print their names and types. The code snippet below demonstrates this process:

   1 2 3 4 5 6 7

   for( auto it = pVuAssetDB->_assetNames.begin(); it != pVuAssetDB->_assetNames.end(); ++it){ auto& assetType = it->first; auto& names = it->second; for(auto it1=names.begin(); it1!=names.end(); ++it1){ LOG_INFOS(" %s : %s", assetType.c_str(), it1->c_str()); } }

   Here, the LOG_INFOS macro is used to print the asset information, which internally calls the _frida_log function.
   The resulting output will be similar to the following:

   1 2 3 4 5

   <...> [/mnt/work/work.2023/frida-hackinggame/jni/mousebot.cc:104] VuTextureAsset : UI/Icons/Inventory_Prize [/mnt/work/work.2023/frida-hackinggame/jni/mousebot.cc:104] VuTextureAsset : UI/Icons/Inventory_Skin [/mnt/work/work.2023/frida-hackinggame/jni/mousebot.cc:104] VuTextureAsset : UI/Icons/KeyCard_A <...>

4. List All Loaded Assets in the Game
   In this final step, we will list all the loaded assets in the game. Although VuAssetDB contains all the assets, it only provides basic information for each asset. During the game runtime, the actual asset data is loaded on demand.
   The code snippet below demonstrates how to iterate through the loaded assets and print their information:

   1 2 3 4 5 6 7 8

   auto& v = pVuAssetFactory->_loadedAssets; for(auto it = v.begin(); it != v.end(); ++it){ auto* pAsset = it->second; auto& k = it->first; auto& assetTypeInfo = getTypeInfoOfInstance_ndk(pAsset); const char* assetTypeName = assetTypeInfo.name(); LOG_INFOS(" %x pAsset %p assetTypeName %s assetName %s", k, pAsset, assetTypeName, pAsset->_name.c_str()); }

   In this code, we use the getTypeInfoOfInstance_ndk function to retrieve the actual class name of each asset instance. The resulting output will be similar to the following:

   1 2 3 4 5

   <...> [/mnt/work/work.2023/frida-hackinggame/jni/mousebot.cc:118] e1fc0284 pAsset 0x77e86e1e40 assetTypeName 18VuStaticModelAsset assetName Env/Hall/Straight_16m [/mnt/work/work.2023/frida-hackinggame/jni/mousebot.cc:118] 93b383af pAsset 0x77c03b1f00 assetTypeName 15VuMaterialAsset assetName Paper/Cardboard_Wall [/mnt/work/work.2023/frida-hackinggame/jni/mousebot.cc:118] 9f8e3cbb pAsset 0x77b8be9810 assetTypeName 15VuTemplateAsset assetName Tile_Hall_Hazard/Hall_Hazard_Stomper_2x_16m <...>

You can find the complete source code in the repository

Conclusion

Congratulations! This marks the end of our exploration series. In this final log, we have successfully printed all asset information in the game using the functions provided by libgame.so. This serves as a solid foundation for further exploration of Frida’s capabilities. The combination of Frida and C++ opens up a world of possibilities, allowing us toperform various interesting tasks. With the knowledge gained from this series, you can continue your journey of hacking and exploring the game.

Remember, Frida and C++ together are a powerful toolset that can enable us to accomplish a wide range of tasks. The ability to access and manipulate game assets opens up exciting possibilities for customization, analysis, and experimentation.

Happy hacking, and enjoy your adventures in the world of game exploration!

Hacking Android Games with Frida (Part2)

In the previous blog post, we discussed how to create a Frida Typescript project to interact with an Android game. In this follow-up article, we will delve deeper into the game’s internals by using the NDK (Native Development Kit) and explore the process of hacking Android games using Frida.

NDK Version enumeration

To begin, we need to identify the NDK version used to compile the game’s native library (libmain.so). Follow these steps:
1. Navigate to the game data directory on the Android device. The path may vary, but an example path is:

1

cd /data/app/com.vectorunit.mercury.googleplay-hN_B8AKQmUeVXiBbDZ2Vvg==/lib/arm64

Note: Replace com.vectorunit.mercury.googleplay-hN_B8AKQmUeVXiBbDZ2Vvg== with the actual game ID on your device.
2. In the game data directory, we can find a file libmain.so. Copy it to PC.
3. Extract strings from libmain.so using the following command:

1

strings -tx libmain.so

Look for the version strings and commit IDs in the command output. For example:

1
2
3

ad4dac Android (7714059, based on r416183c1) clang version 12.0.8 (https://android.googlesource.com/toolchain/llvm-project c935d99d7cf2016289302412d708641d52d2f7ee)
ad4e4a Android (4691093 based on r316199) clang version 6.0.2 (https://android.googlesource.com/toolchain/clang 183abd29fc496f55536e7d904e0abae47888fc7f) (https://android.googlesource.com/toolchain/llvm 34361f192e41ed6e4e8f9aca80a4ea7e9856f327) (based on LLVM 6.0.2svn)
ad4f52 Linker: LLD 12.0.8 (/buildbot/src/android/llvm-r416183/out/llvm-project/lld c935d99d7cf2016289302412d708641d52d2f7ee)

Perform a Google search using the version strings and commit IDs to determine the NDK version. In this example, I assume the game was compiled with NDK r17c.
4. Download the according NDK from here, and uncompress it to your PC.

NOTE: NDK r17c is an older version and may not work with newer versions of Linux. Refer this page for potential issues of to run clang++ on NDK r17c. The provided solution in that post can help resolve the issue.

Create helper function in Typescript for C++ code

Next, we will create two helper functions in Typescript that can be called from C++ code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

const _frida_log = new NativeCallback(function(sp:NativePointer){
    console.log(sp.readUtf8String());                                         
}, 'void', ['pointer']);
                                       
const _frida_hexdump = new NativeCallback(function(sp:NativePointer, sz:number){
    console.log(                                                              
        hexdump(sp, {
            offset: 0,
            length: sz,
            header: true,
            ansi: false,
        })
    );
}, 'void', ['pointer','uint']);

• _frida_log: This function outputs a string and accepts a pointer to the string.
• _frida_hexdump:This function performs a hexdump of a block of memory and accepts a pointer to the memory and its length.

Build the NDK .so file

To build the NDK shared library (.so file), follow these steps:

1. Create a subdirectory named jni.
2. Navigate to the jni directory.
3. Create a C++ file named mousebot.cc with the following content:

   1 2 3 4 5 6 7 8 9 10 11 12

   extern "C" { void _frida_log(const char* p); void _frida_hexdump(void* p, unsigned int i); } extern "C" int test(void* base){ _frida_log("Hello from C++ !"); _frida_hexdump(base, 0x20); return 0; }

• The declarations for the helper functions are enclosed in extern “C” to avoid C++ name mangling.
• The test function accepts a pointer to memory, calls the helper functions, and returns 0.

4. Create Android.mk file with the following content:

   1 2 3 4 5 6 7 8 9 10 11

   LOCAL_PATH := $(call my-dir) include $(CLEAR_VARS) LOCAL_MODULE:= mousebot LOCAL_SRC_FILES := mousebot.cc LOCAL_C_INCLUDES := LOCAL_LDLIBS := LOCAL_CFLAGS= LOCAL_ALLOW_UNDEFINED_SYMBOLS := true LOCAL_SHARED_LIBRARIES = include $(BUILD_SHARED_LIBRARY)

• This file instructs NDK to build a shared library. I set LOCAL_ALLOW_UNDEFINED_SYMBOLS to true to avoid compiler to complain about undefined symbols for our defined helper functions. We implements the helper functions in Typescript. We have no library for compiler to link.

5. Create Application.mk file with the following content:

   1 2	APP_PLATFORM=android-27 APP_ABI=arm64-v8a

• To determine the Android API level of your device, use the following command:

  1	adb shell getprop | grep api_level

• To determine the CPU ABI, use the following command:

  1	adb shell getporop ro.product.cpu.abi

6. Create Makefile file with the following content:

   1 2 3 4 5 6 7 8 9 10 11

   ifndef NDKPATH $(error NDKPATH not set) endif all: build_android build_android: ${NDKPATH}/ndk-build V=1 clean: ${NDKPATH}/ndk-build clean

   This Makefile instructs the NDK to build the shared library, while enabling verbose mode with the V=1 flag. Make sure to export the NDKPATH environment variable with the path to your actual NDK installation. By running make, the shared library will be built, and you can find it in the libs/arm64-v8a/libmousebot.so directory.

Convert .so file to typescript module

Next, we’ll convert the generated .so file into a TypeScript module. To accomplish this, we have provided a Python script called so2ts.py, which you can find here. The script performs the following steps:

1. Parse the .so file using LIEF library
2. Generate a .ts file that loads the .so file manually:

• Allocates memory for the .so file, and loads it into the allocated memory, set ting the permissions to rwx.
• Applies hot patches to the .so file using the information from the relocation sectin.
• Invokes constoructors of the .so file.

To run the script, execute the following command:

1

./utils/so2ts.py -b libs/arm64-v8a/libmousebot.so -o modinfos/libmousebot.ts

The generated TypeScript file will be located at modinfos/libmousebot.ts.

Call the Test function in Typescript

Now that we have the converted TypeScript module, we can proceed to call the C++ function from TypeScript. Here’s how you can accomplish this:

import the generated .ts file

In your TypeScript code index.ts, import the generated .ts file as follows:

1

import {mod as libmousebotinfo} from './modinfos/libmousebot'

Load the .so file

Add the following code to index.ts to load the .so file:

1
2
3
4
5
6
7
8

const soname ='libmain.so'
const lib = libmousebotinfo.load([
    soname,
],{
    _frida_log      , 
    _frida_hexdump  ,
     
})

In the code snippet above, soname represents the name of the original libmain.so file. Since the game process loads this .so file during boot, we pass soname to libmousebotinfo.load to enable our .so file to resolve symbols from this library. Additionally, we pass _frida_log and _frida_hexdump to libmousebotinfo.load to provide these two functions to our .so file.

Call test function

To call the test function in libmousebot.so, use the following TypeScript code:

1
2

const m = Process.getModuleByName(soname);
new NativeFunction(lib.symbols.test, 'int', ['pointer'])(m.base);

In the code snippet above, we obtain the base address of libmain.so using Process.getModuleByName. Then, we invoke the test function in libmousebot.so using lib.symbols.test, where lib.symbols includes all the symbols exported by libmousebot.so.

Recompile index.ts and inject the Frida script

With all the necessary code prepared, we can recompile index.ts and inject the Frida script into the game process. Use the following command:

1

frida -U -l _agent.js -n 'MouseBot'

When executed, the console will display the following output:

1
2
3
4
5

##################################################
Hello from C++ !
             0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F  0123456789ABCDEF
7a26ace000  7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00  .ELF............
7a26ace010  03 00 b7 00 01 00 00 00 d4 04 72 00 00 00 00 00  ..........r.....

Conclusion

In this tutorial, we have learned how to build a shared library using the Android NDK and call C++ functions from TypeScript. By leveraging Frida, we successfully integrated the functionalities of libmousebot.so with the existing libmain.so of the game process. This opens up possibilities for further exploration and utilization of Frida’s capabilities.

In the next blog post, we will delve deeper into Frida’s extensive feature set and explore how to call functions in libmain.so from our custom libmousebot.so.

Thank you for following along! If you have any further questions or need assistance, feel free to reach out.

Hacking Android Games with Frida (Part1)

Disclaimer:

The techniques and information presented in this serial of blogs are strictly for educational purposes. Unauthorized use of these techniques for illicit activities, including game hacking, is strictly prohibited. The author and publisher do not condone or support any form of illegal or unethical behavior. It is essential to respect the intellectual property rights of game developers and adhere to the terms of service. Any actions taken based on the knowledge gained from this blog are solely at the reader’s own risk, and the author and publisher are not liable for any misuse or legal consequences that may arise.

Introduction:

Mobile gaming has become a massive industry, and many players strive to gain an edge by tweaking or modifying Android games. One powerful tool for game hacking is Frida, an open-source dynamic instrumentation framework. In this serial of blogs, we will guide you through the process of creating a Frida project using TypeScript, enabling you to hack Android games and unlock new possibilities.
I will put all source codes in here.

The Game for Testing:

For the purpose of testing and learning, we will use “MouseBot”, a popular and addictive runner game developed by Vector Unit. You can download the Android version of the game for free from the Play Store here. It’s free.

Prerequisites:

To follow along with this tutorial, you’ll need the following:

• A basic understanding of TypeScript.
• Node.js installed on your machine.
• A rooed Android device or emulator.
• Frida installed on your machine.
• Test game , MouseBot, installed in your machine.

Step 1: Setting Up the Project

• Create a new directory for your Frida project.
• Open a terminal or command prompt and navigate to the project directory.
• Create a file named package.json in the project directory. You can view its content from here.
• Create a file named tsconfig.json in the project directory. You can view its content from here.
• Install the Frida library for TypeScript and frida-compile by executing the following command, I have write these libraries in this package.json:

  1

  npm i

Step 2: Writing the Frida Script

• Inside your project directory, create a new TypeScript file, index.ts:
• Open the file in your preferred code editor.
  Write the Frida script to print Hello world to the console.

  1 2 3 4 5 6

  const test = ()=>{ console.log('hello world') } console.log('##################################################') test()

Step 3: Running the Frida Script

• Save the game-hack.ts file.
• Open a terminal or command prompt and navigate to the project directory.
• Create a file named Makefile in the project directory. Its content is shown as follows:

  1 2	all: ./node_modules/frida-compile/bin/compile.js -o _agent.js index.ts

• Compile the TypeScript file into JavaScript using the following command:

  1

  make

  This command will create a file named _agent.js in the project directory.
• Run the Frida script using the following command:
• Setup your Android device, start frida-server. This page has detailed instructions for this step.
• Launch MouseBot on your Android device or emulator.
• Execute the following command to inject the Frida script into the game process:

  1	frida -U -l _agent.js -n 'MouseBot'

  If everything goes well, Frida will inject the script into the game process. and you will see Hello world in the console.

Conclusion:

In this blog, we explored the initial steps of creating a Frida project using TypeScript and injecting a basic Frida script into an Android game. We emphasized the importance of using this knowledge responsibly and for educational purposes only. In the next blog of this series, we will delve deeper into Frida’s capabilities and explore more advanced game hacking techniques. Stay tuned and happy hacking!

Disclaimer

This blog is intended solely for educational purposes. Please refrain from using this information for malicious purposes.

Introduction

I recently acquired a new Pandora’s Box game cartridge, which utilizes the RK3128 system-on-a-chip (SOC) from Rockchip. I wanted to share my experience with hacking it.
The manufacturer has overclocked it to 1.5GHz to ensure smooth gameplay with HD video filtering. However, due to the increased performance, an additional fan is required for cooling. Fortunately, the cartridge uses an SD card for booting, making it easy to dump the firmware.Here is a photo of the PCB:

loader

The system initiates the “loader” program to extract necessary files and launch the main program, “mkemu.” The manufacturer has placed the “loader” in the initram filesystem of the kernel, which is in CPIO format. Extracting the “loader” binary is a straightforward process.
The following code snippet from /etc/init.d/rcS in the initram reveals how the system starts the “loader” program:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

#!/bin/sh
PATH=/bin:/sbin:/usr/bin:/usr/sbin
runlevel=S
prevlevel=N
umask 022
export PATH runlevel prevlevel

mount -t tmpfs mdev /dev
mkdir /dev/pts
mkdir /dev/shm

mount -a

echo /sbin/mdev > /proc/sys/kernel/hotplug
mdev -s

touch /dev/mdev.log

cd /tmp
mkdir -m 1777 .X11-unix

cd /lib/modules/3.4.39-h3
insmod elib.ko
#insmod ch341.ko

while true
do
        /home/games/loader
done

Analyzing the Loader Program

I loaded the “loader” program into Ghidra and performed an automated analysis. At address 0x11b10, it becomes evident that the “loader” attempts to mount a LUKS filesystem file:

1
2

sprintf(uStack_620,"echo -n \"%s\" | cryptsetup luksOpen /dev/dm-1 pass -",&DAT_00028c94);
system(uStack_620);

The LUKS key is stored in ASCII format at address DAT_00028c94 and is calculated using a number read from /dev/elib. The function at 0x14720 includes the code to read the original number from /dev/elib:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

int read_rand_seed(void *data)

{
  int __fd;
  int iVar1;
  
  __fd = open("/dev/elib",0);
  elib_fd = __fd;
  if (__fd < 0) {
    iVar1 = -1;
  }
  else {
    iVar1 = ioctl(__fd,0x80045a13,data);
    iVar1 = iVar1 >> 0x1f;
    close(__fd);
    elib_fd = -1;
  }
  return iVar1;
}

Fortunately, the programmer compiled the Linux driver into an individual .ko file instead of including it in the kernel binary. This allows us to easily locate the code responsible for returning the number within the small .ko file.

Analyzing elib.ko

We can find elib.ko in the CPIO filesystem. By loading it into Ghidra, we can locate the code that handles the 0x80045a13 ioctl code in the elib_ioctl function. Ghidra’s decompiled C code provides the following information:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

if (param_2 == 0x80045a13) {
  local_2c = (undefined *)0x0;
  memset(&local_28,0,0x10);
  pcVar2 = strstr(saved_command_line,"custom_id=");
  if (pcVar2 != (char *)0x0) {
    pcVar2 = pcVar2 + 10;
    pcVar3 = strchr(pcVar2,0x20);
    if (pcVar3 == (char *)0x0) {
      __n = strlen(pcVar2);
    }
    else {
      __n = (int)pcVar3 - (int)pcVar2;
    }
    if (__n < 0x10) {
      strncpy((char *)&local_28,pcVar2,__n);
      local_2c = (undefined *)simple_strtoul(&local_28,0,0x10);
    }
  }
  if (local_2c == (undefined *)0x0) {
    local_2c = (undefined *)0x87654321;
  }
  printk("\x011custom id: %x\n",(uint)local_2c);
  puVar6 = *(undefined **)(((uint)local_38 & 0xffffe000) + 8);
  bVar12 = (undefined *)0xfffffffb < param_3;
  if (!bVar12) {
    bVar12 = puVar6 < param_3 + 4 || (uint)((int)(param_3 + 4) - (int)puVar6) < (uint)bVar12;
  }
  if (!bVar12) {
    puVar6 = (undefined *)0x0;
  }
  if (puVar6 != (undefined *)0x0) {
    return 4;
  }
  ppuVar4 = &local_2c;
  uVar5 = 4;
  goto LAB_00010668;
}
if (param_2 != 0x80045a0b) goto LAB_00010674;

And the programmer is lazy, as he hardcoded this sensitive number. It’s 0x87654321. I noticed there is an MCU on the PCB, and I suspected the programmer might have stored the number in the MCU, but he didn’t.

Find the key for the LUKS file

Now, it’s time to calculate the key for the LUKS file. I decided to use unicorn engine for this task, I wrote a python script for this task.
This script requires the preparation of the file rocky.rsa and the number 0x87654321. The thumb instructions call the standard libc functions, memset and memcpy. I simulate these two functions in the block_hook section. The following is the code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

if(address==0x10cb4):  
    # void * memset(void *__s,int __c,size_t __n)
    s = uc.reg_read(UC_ARM_REG_R0)
    c = uc.reg_read(UC_ARM_REG_R1)
    n = uc.reg_read(UC_ARM_REG_R2)
    print('hook memset', hex(s), c, n)
    uc.mem_write(s, bytes([c]*n))
    uc.reg_write(UC_ARM_REG_R0, s)
    uc.reg_write(UC_ARM_REG_PC, uc.reg_read(UC_ARM_REG_LR))
elif(address==0x10d2c):  
    # void * memcpy(void *__dest,void *__src,size_t __n)
    __dest = uc.reg_read(UC_ARM_REG_R0)
    __src  = uc.reg_read(UC_ARM_REG_R1)
    __n    = uc.reg_read(UC_ARM_REG_R2) #TODO: hack
    print('hook memcpy', hex(__dest), hex(__src), __n)
    dat = uc.mem_read(__src,__n)
    uc.mem_write(__dest,bytes(dat));
    uc.reg_write(UC_ARM_REG_R0, __dest)
    uc.reg_write(UC_ARM_REG_PC, uc.reg_read(UC_ARM_REG_LR))

If the script succeeds, we can get the LUKS key at address 0x28c94. It is a string, and we can use this key to mount the LUKS file on a PC.

Decrypt config.dat file

The function at 0x011dc8 is a decryption function. loader uses it to decrypt config.dat and other configuration files for gaming. I wrote a Python script to perform this decryption. The script saves the resulting file to /tmp/tt.bin.

mkemu

loader starts mkemu using system. We can find the related instruction at address 0x01153c in loader. The Ghidra decompiled C code is as follows:

1
2
3
4
5

do {
  system("/home/games/mkemu");
  puts("User app exit.");
  usleep(10000);
} while( true );

Analyzing the mkemu program

mkemu is the essential program for this game cartridge. It displays the game selection menu and allows users to play their selected game. After analyzing it using Ghidra, I believe it utilizes SDL.

Decrypt asset

The programmer encrypted and packaged the assets in the file asset.dat. Therefore, we need to decrypt the assets using the Thumb instructions in mkemu. You can find the complete Python script in here. This script will save each decrypted asset file in the target folder.

Conclusion

This board isn’t very difficult, and I feel like hacking it is similar to participating in a Capture The Flag (CTF) competition. Every key is like a flag. The only difference is that the board is real.

Disclaimer

This blog is only for educational purposes. Never use these info for bad.

Introduction

Pandora’s box multi-game cartridge is a popular product from China. This cartridge usually has 1000+ retro arcade games. It supports Jamma and HDMI. Users can enjoy old-time games with it. And some newer versions of it have more than 10,000 games, and support some home console games. Many manufactures from China have the ability to design and product Pandora’s box multi-game cartridge. They always add software protection to prevent others from cloning their efforts.
Recently, I got a newer version of PB boards. And I hacked it. I will introduce the steps of how I hacked this board.
The PCB is as follows:

I uploaded all code to github

Tools/Packages I used

• strings is a GNU util to output all printable strings in files.
• file is a GNU util to determine files type.
• binwalk is a easy way to extract firmware from an image file.
• Ghidra is a great suite for disassembling and decompiling binary from variety platforms.
• Unicorn is a lightweight multi-platform, multi-architecture CPU emulator framework.

Inspect image

This board uses Amlogic s805. This SOC is old, and not very powerful for running some 3D games. I think the manufaturer selected this SOC only beacause it’s cheap. This SOC only cost near to $1 if they select to use second-hard ICs.
This board has s805, a memory IC, and no EMMC IC. It has a TF card of size 32GB, this board uses TF card boot mode.
The TF card has 2 partitions, shown as the following:

1
2
3
4
5
6
7
8
9
10
11

$ fdisk -l pb1.img
Disk pb1.img: 29.57 GiB, 31739999744 bytes, 61992187 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00007577

Device     Boot   Start      End  Sectors  Size Id Type
pb1.img1           8192  1441791  1433600  700M  6 FAT16
pb1.img2        1441792 60440575 58998784 28.1G  c W95 FAT32 (LBA)

I mounted partition 1 to check its files:

1
2
3
4
5
6
7
8
9
10
11

$ sudo mount -oloop,ro,offset=$((8192*512)) pb1.img /mnt/disk
$ ls /mnt/disk -l
total 684384
-rwxr-xr-x 1 root root   1843272 9月  26  2021  logicalcircuit
-rwxr-xr-x 1 root root     60268 9月  26  2021  logo_en.png
-rwxr-xr-x 1 root root     60268 9月  26  2021  logo_ko.png
-rwxr-xr-x 1 root root     60268 9月  26  2021  logo.png
-rwxr-xr-x 1 root root   6678528 9月  26  2021  rxnv
-rwxr-xr-x 1 root root 314572800 1月   3 18:26  rxte
drwxr-xr-x 2 root root     16384 4月  18  2022 'System Volume Information'
-rwxr-xr-x 1 root root 377487360 1月   3 18:26  user

And checked the file type using file

1
2
3
4
5
6
7
8
9

$ file /mnt/disk/*
/mnt/disk/logicalcircuit:            PC bitmap, Adobe Photoshop with alpha channel mask, 1280 x 720 x 16
/mnt/disk/logo_en.png:               PNG image data, 500 x 120, 8-bit/color RGBA, non-interlaced
/mnt/disk/logo_ko.png:               PNG image data, 500 x 120, 8-bit/color RGBA, non-interlaced
/mnt/disk/logo.png:                  PNG image data, 500 x 120, 8-bit/color RGBA, non-interlaced
/mnt/disk/rxnv:                      data
/mnt/disk/rxte:                      LUKS encrypted file, ver 1 [aes, xts-plain64, sha256] UUID: 3929e3d8-a638-4b24-93d7-a459b77ac901
/mnt/disk/System Volume Information: directory
/mnt/disk/user:                      LUKS encrypted file, ver 1 [aes, xts-plain64, sha256] UUID: 85dbb20b-1880-422f-b4e7-6564b1d13abb

It shows file rxnv maybe encrypted.
I uploaded the TF card image file here. And I striped partition 2 to save room.

Analyse U-boot

U-boot has many versions. We should find U-boot in s805 SDK. I find Odroid C1 is using s805. And I can find partitions table here.

Download related U-boot source code

As this page shows, we can download U-boot source from github

1

$ git clone https://github.com/hardkernel/u-boot.git -b odroidc-v2011.03

Extract U-boot binary

We can extract U-boot from the image accord to partitions table

1
2
3
4

$ dd if=pb1.img skip=64 count=$((8192-64)) of=uboot.bin
# 8192 is the start block of the paration 1
$ file uboot.bin 
uboot.bin: UCL compressed data

If we compile U-boot successfully, we can get a tool build/tools/uclpack to decompress UCL data. I guess UCL is the special package format for s805.

1
2
3
4
5
6
7
8
9
10
11
12

$ build/tools/uclpack -d  uboot.bin uboot.bin.decompressed

UCL data compression library (v1.03, Jul 20 2004).
Copyright (C) 1996-2004 Markus Franz Xaver Johannes Oberhumer
http://www.oberhumer.com/opensource/ucl/

uclpack: block-size is 262144 bytes
uclpack: decompressed 340268 into 740288 bytes

$ file uboot.bin.decompressed 
uboot.bin.decompressed: data

file can not recognize U-boot type. But strings can still give us some useful info.

1
2
3
4
5
6
7
8

$ strings -tx uboot.bin.decompressed 
<...>
  a9b72 switch_bootmode=if test ${reboot_mode} = factory_reset; then run recovery;else if test ${reboot_mode} = update; then run update; else if test ${reboot_mode} = usb_burning; then run usb_burning;else if test ${wipe_data} = failed; then echo wipe_data=${wipe_data}; run recovery;else   fi;fi;fi;fi
  a9c98 prepare=logo size ${outputmode}; video open; video clear; video dev open ${outputmode};if fatload mmc 0 0x13000000 logicalcircuit; then bmp display 0x13000000; bmp scale;fi;
  a9d46 storeboot=echo Rx Booting...; if unifykey get usid; then  setenv bootargs ${bootargs} androidboot.serialno=${usid};fi;echo [Maple] read info...; if mmcinfo; then if fatload mmc 0 ${loadaddr} rxnv; then setenv bootargs ${bootargs} bootfromsd; bootm;fi;fi; echo failed...; run recovery
  a9e62 recovery=echo enter recovery;if mmcinfo; then if fatload mmc 0 ${loadaddr} recovery.img; then bootm;fi;fi; if usb start 0; then if fatload usb 0 ${loadaddr} recovery.img; then bootm; fi;fi;if imgread kernel recovery ${loadaddr}; then bootm; else echo no recovery in flash; fi;
  a9f77 usb_burning=update 1000
<...>

At 0xa9d46, storeboot environment variable shows U-boot load rxnv file using fatload command, and runs it using bootm. Now I can be sure rxnv actually is the kernel, and it should be encrypted. fatload should have code to decrypt it, or the kernel will not boot.

Locate decrypt codes in U-boot

Now, open uboot.bin.decompressed with Ghidra. I can get U-boot will be loaded at 0x10000000 by check file build/u-boot.map in U-boot source code.
That’s the funnest part during the whole hacking. Inspect disassemble code with source code. To make analysis easier, I wrote a header file uboot.h. This file includes some structure definitions. We can import this file into ghidra.After hours of efforts, I found the codes to decrpyt rxnv, it’s at 0x10064aec-0x10064f2c, shown as follows:
.
And these codes mainly do the following things:

• Check the name of the file currently loading, if it is rxnv then decrytpt;
• It seems to prepare key in the first loop;
• Decrypt data in the sencode loop;
  And I found ghidra’s register renaming makes it not very easy to know the actual register name in every assembly instruction, just like instruction mov maxsize, #0x4 at 0x10064af0. We can use Patch Instruction menu item in the context menu to check the original instructions.

Decrypt data using code in U-boot

Let’s decrypt rxnv using the code we found. I worte a python script for this work. This python script uses unicorn to emulate ARM instructions in U-boot to decrypt rxnv file.

• Create an ARM emulator

  1	mu = Uc(UC_ARCH_ARM, UC_MODE_ARM)

• Allocate memory

  1 2 3 4 5 6 7 8

  mu.mem_map(code_ptr, 0x10000000); # code_ptr= 0x10000000, I will put U-boot binary in here mu.mem_map(data_ptr, 0x10000000); # data_ptr= 0x20000000, I will put encrypted data in here; mu.mem_map(alloc_ptr, 0x10000000); # alloc_ptr= 0x30000000, this rangion if for malloc/free functions mu.mem_map(0 , 0x00200000); # this is stack, and set sp_ptr = 0x00100000

• Load data

  1 2 3 4 5 6

  # load uboot mu.mem_write(code_ptr, open('uboot.bin','rb').read()) # load data data = open('rxnv','rb').read(); datalen = len(data); mu.mem_write(data_ptr, data);

• Write hook codes

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

  # callback for tracing basic blocks def hook_block(uc, address, size, user_data): if address == 0x10016248: # hook malloc, emulate malloc function, sz = uc.reg_read(UC_ARM_REG_R0); global alloc_ptr; ret = alloc_ptr; alloc_ptr+=sz; uc.reg_write(UC_ARM_REG_R0, ret); # write return value, a pointer to allocated memory uc.reg_write(UC_ARM_REG_PC, uc.reg_read(UC_ARM_REG_LR)); elif address == 0x10015fec: # hook free, do nothing uc.reg_write(UC_ARM_REG_PC, uc.reg_read(UC_ARM_REG_LR)); elif address == 0x10015bc8: # hook printf , actual printf function will access to serial port, so I emulate this function to avoid hardware operations. Unicorn is a great tool to emulate CPU, but is not very easy to implement serial ports. fmt = uc.reg_read(UC_ARM_REG_R0); bs = uc.mem_read(fmt, 0x100); s = bs.decode('utf-8').split('\0')[0]; print(s) # only print the first arguments uc.reg_write(UC_ARM_REG_PC, uc.reg_read(UC_ARM_REG_LR)); elif address == 0x10064d14: # This is at the begin of the second loop, print loop variable and total loop counter to show decrypt progress n1=struct.unpack('I', uc.mem_read(uc.reg_read(UC_ARM_REG_SP)+0x18,4))[0] n2=struct.unpack('I', uc.mem_read(uc.reg_read(UC_ARM_REG_SP)+0x28,4))[0] print('go here', n1, n2); # tracing all basic blocks with customized callback mu.hook_add(UC_HOOK_BLOCK, hook_block)

• Initialize registers and variables in the stack.

  1 2 3 4 5 6 7

  mu.reg_write(UC_ARM_REG_R5, datalen ) # datalen is length of the encrpyted data mu.reg_write(UC_ARM_REG_R4, 0x100abc80) # d = 0x100641d4+[0x10064f48] mu.reg_write(UC_ARM_REG_R0, 0 ) # mu.reg_write(UC_ARM_REG_SP, sp_ptr ) # set stack register # set maxsize mu.mem_write(sp_ptr+0x34, struct.pack('I', 0x800000)); # this variable should be greater than datalen; mu.mem_write(sp_ptr+0x2c, struct.pack('I', data_ptr)); # data_ptr is the pointer to encrypted data;

• Emulate

  1 2 3

  ADDRESS0 = 0x10064b00 ADDRESS1 = 0x10064f2c mu.emu_start(ADDRESS0, ADDRESS1, count=-1)

• Save decrypted data

  1	open('rxnv.decrypted','wb').write(mu.mem_read(data_ptr, datalen)) # now, data_ptr points to the decrypted data

  Please note: this script may take a long time to run. I tested it with my PC,(Intel(R) Core(TM) i5-9400 CPU @ 2.90GHz , 6 cores, 16GB DDR), and it took 15 minutes, so I printf loop variable at 0x10064d14.
  Now, we check decrypted rxnv.

  1 2	$ file rxnv.decrypted rxnv.decrypted: Android bootimg, kernel (0x10008000), ramdisk (0x11000000), second stage (0x10f00000), page size: 2048

  It’s a packaged Android kernel.

Analyse Kernel

I use binwalk to extract data from rxnv.decrypted

1
2
3
4
5
6
7
8
9

$ binwalk -e rxnv.decrypted 

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             Android bootimg, kernel size: 2986048 bytes, kernel addr: 0x10008000, ramdisk size: 3664373 bytes, ramdisk addr: 0x11000000, product name: ""
2048          0x800           uImage header, header size: 64 bytes, header CRC: 0x71E73C6F, created: 2022-05-19 17:19:01, image size: 2985984 bytes, Data Address: 0x208000, Entry Point: 0x208000, data CRC: 0x9502FBF, OS: Linux, CPU: ARM, image type: OS Kernel Image, compression type: gzip, image name: "Linux-3.10.99"
2112          0x840           gzip compressed data, has original file name: "ccImage", from Unix, last modified: 2022-05-19 17:19:00
2990080       0x2DA000        gzip compressed data, from Unix, last modified: 2022-05-19 17:19:01
6656000       0x659000        device tree image (dtb)

The -e flag will extract recognized data to floder _rxnv.decrypted.extracted;
Check extracted files:

1
2
3
4
5
6
7

$ ls -l _rxnv.decrypted.extracted/
total 13232
-rw-rw-r-- 1 mxp mxp 7429120 1月   4 14:05 2DA000
-rw-rw-r-- 1 mxp mxp 6117776 1月   4 14:05 ccImage
$ file _rxnv.decrypted.extracted/*
_rxnv.decrypted-0.extracted/2DA000:  ASCII cpio archive (SVR4 with no CRC)
_rxnv.decrypted-0.extracted/ccImage: data

2DA000 is a cpio archive. Use the following commands to depack it;

1
2
3
4

$ mkdir cpio.files
$ cd cpio.files/
$ sudo cpio -i < ../2DA000 
14510 blocks

ccImage should be the kernel binary.

Anslyse init script in Kernel

I checked the init file in the cpio archive. and it’s actually a bash script, and I found commands to mount rxte and user

1
2
3
4
5
6
7
8

debug_msg "校验运行1"
cryptsetup luksOpen /flash/rxte rxsys -d /usr/lib/system.key &
debug_msg "校验运行2"
cryptsetup luksOpen /flash/user user -d /usr/lib/system.key &
debug_msg "准备挂载"
mount_part "/dev/mapper/rxsys" "/sysroot" "rw,loop"
debug_msg "挂载user"
mount_part "/dev/mapper/user" "/sysroot/userdata" "rw,loop"

Recover true root file system

Run the same commands to mount rxte and user file, we can get actual rootfs.

1
2
3
4

sudo cryptsetup luksOpen rxte rxsys -d _rxnv.decrypted.extracted/cpio.files/usr/lib/system.key
sudo cryptsetup luksOpen user user -d _rxnv.decrypted.extracted/cpio.files/usr/lib/system.key 
sudo mount /dev/mapper/rxsys /mnt/disk -o "rw,loop"
sudo mount /dev/mapper/user /mnt/disk1 -o "rw,loop"

Now we have hacked this board.

Conclusion

Finally, I hacked this board, The primary part is to decrypt rxnv using unicorn. We need not to rewrite instructions in C or Python. All we need to do is emulate the ARM instructions correctly.

This tutorial introduces how to use frida-mod.
Frida-mod is trying to make us access functions more easily using Frida. We can call functions, hook and unhook functions.
These functions can come from:

• Existing modules, the process has loaded these modules after boot. I will call this is get mode.
• Our modules, we can write these modules in C/C++, and it only supports 2 file formats. .so files and .dll files. I will call this is load mode.

Prepare C/C++ source codes.

get mode

For demonstraction, I wrote sprintf function prototype in file libc.h. For simplicity, we’d better make these source files not depend on other files.

load mode

In theory, we can use module source codes directly, but because we use llvm to parse source code for further process, this compiler may be different than the compiler you compile the actual module. So we may need to do some modifications on it.

Generate typescript wrapper code.

I wrote a python util to generate typescript wrapper code. It’s modinfo2ts.py. You can run modinfo2ts.py --help to get its help page.

get mode

1

./utils/modinfo2ts.py -m get -o modinfos/libc.ts source/libc.h

-m flag specifies mode, get mode is for the existing module;
-o flag specifies the output typescript file name;
the last argument is the source file, and it supports multiple source files;

load mode

1

./utils/modinfo2ts.py -m load -b c/bins/win64.dll -o modinfos/libwin64.ts c/mod_win.cc

-m flag specifies mode, load mode is for our own modules;
-b flag specifies compiled module binary file;
-o flag specifies the output typescript file name;
the last argument is the source file, and it supports multiple source files, I use module source code here;

The generated code exports a mod variable.

Test generated typescript module

I wrote index.ts to test generated TS module.
We need to import module as follows

1
2
3
4
5
6
7

import { mod as libcmodinfo } from './modinfos/libc'
import { mod as liblinux_x64info  } from './modinfos/liblinux_x64'
import { mod as liblinux_x86info  } from './modinfos/liblinux_x86'
import { mod as libarm64info  } from './modinfos/libarm64'
import { mod as libarm32info  } from './modinfos/libarm32'
import { mod as libwin64info  } from './modinfos/libwin64'
import { mod as libwin32info  } from './modinfos/libwin32'

We need to use the alias to avoid the dupulcation of mod names.

Get mode

Function testLibcSprintf calls sprintf function in libc module.

1
2
3
4
5
6
7
8
9
10
11

// we need to specify the actual module name in here. 
//   use the following code to get the module containing `sprintf`
//     let p = Module.getExportByName(null,'sprintf)
//     let m = Process.getModuleByAddress(p); 
//     console.log(JSON.stringify(m))
let libc  = libcmodinfo.get(modname);
let buff = Memory.alloc(Process.pageSize);
// use libc.functions.sprintf.call to call sprintf
libc.functions.sprintf.call(buff, Memory.allocUtf8String("%s %d"), Memory.allocUtf8String('1 + 2 ='), ptr(1+2));
let resStr = buff.readUtf8String();
console.log('result', resStr);

Load mode

Function testLibAdd call add function implemented in our module

load module

I try to explain how to load the module on arm64 platform here. The passed parameters are slightly different on every platform.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

let lib = libarm64info.load(
    [   // an array of depended libraries. load function will try to resolve symbols at these libraries.

    ],
    {   // a map for symbols,   the key is symbol name, the value is symbol address, 
        // we can pass our defined frida NativeCall to the loaded module, 
        // and we can set some never used symbols to null.

    _frida_puts                 : _frida_puts,

    _ITM_registerTMCloneTable   : ptr(0),
    _ITM_deregisterTMCloneTable : ptr(0),
    __gmon_start__              : ptr(0),
});

Call functions in our module

1
2
3
4
5
6

let a = 2;
let b = 3;
lib.functions.add.hook();   // hook add function 
let res = lib.functions.add.call(a,b);   // call add function 
lib.functions.add.unhook();   // unhook
console.log('res', res);

Conclusion

I introduced how to access functions in modules using frida-mod. Hope this util can help you write frida code easier.

Todo

• Fix the bug on win64 platform
• support variable access
• support struct parsing

This article introduces an inline hook library using Frida, and you can download all codes about this at this link. And I only implement it on ARM64 architecture.

Concepts

In my opinion, inlinehook just like put a breakpoint in debugger. Users can hook at any instructions, and executes any codes once the hook is triggered.

How to implement it

Basic steps

• Put a jump code at the hook point, to jump to our trampoline code.
• Trampoline code does the following:
  • Save current registers.
  • Invoke hook handler function.
  • Restore all registers.
  • Execute instructions at hook point.
  • Jump back to next instruction after the hook point.

Implementation using Frda

How to add hook

Before add inline hook, user should prepare the following things:

• Hook point

  1	const hook_ptr = <Address of the instruction will be hooked> ;

  We can add hooks at any instruction.
• Hook handle function

  1 2 3

  const frida_fun = new NativeCallback(function(para1:NativePointer, sp:NativePointer){ console.log('para1', para1, 'sp', sp); },'void',['pointer','pointer'])

  This function has two arguments, all are of type NativePointer. The first argument is named para1, and we can assign it when we add hook, the second argument is named sp, of value in the sp register, we can access values in the stack by this argument.
• Memory for trampoline code

  1	const trampoline_ptr = Memory.alloc(trampoline_len)

  We can allocate a new memory for trampoline code. And because allocated memory is usually far from the hook point, so we have to use a long jump instruction at the hook point. Long jump instruction usually occupies more bytes. For using near jump instruction, we can try to find a cave near the hook point, and use the found cave to store trampoline code.

  Warning: when we allocate memory, do not use a local variable for the returned pointer, use a global variable instead. Javascript’s garbage collection mechanism will free this memory automatically once the program is out of the local variable’s scope, and will crash the process.

• Parameter1 pass to hook handle function

  1	const para1 = <parameter1 pass to hook handle function>;

  We can pass a parameter to the hook handle function, and this parameter is of type NativePointer

Now invoke InlineHooker.inlineHookPatch to add a inline hook, just as follows

1

let sz = InlineHooker.inlineHookPatch(trampoline_ptr,hook_ptr, hook_fun_ptr, para1);

This function return a number, indicating the length of the trampoline code.

Code relocation

For inline hook, we need to move some instructions from one address to another. And we need to rewrite some instructions, just like B/BL instruction in ARM64 architecture.
I am using the code in this link for rewriting instructions. I port the C code in this file to Typescript code. This file is my ported code. ARM64 instruction set is relatively easy, and Thumb/Arm32 is too complex, we may port its code in the future.
This file exports this method to rewrite code

1

export let  sh_a64_rewrite=(buf:NativePointer, inst:number, pc:NativePointer ):number=>

This method has 3 arguments

• buf, the target address of current instruction
• inst, current instruction
• pc, the source address of current instruction
  This method also return a variable of type number, to indicate how many instructions has written to target address. We actually need to rewrite several instructions for one B instruction to avoid change its behavior.

Conclusion

I wrote an inline hook library using Frida. Inline Hooking is not very easy, specially in some architecture, I only implemented on ARM64, and will do more work on other architecture.