Author: admin

Introduction: The Enigma of Native Android Code

Android applications often leverage native libraries (written in C/C++ and compiled into .so files) to achieve performance-critical tasks, implement security features, or reuse existing codebases. While static analysis tools like Ghidra or IDA Pro provide invaluable insights into the structure and logic of these libraries, understanding their runtime behavior – especially how they interact with Java code via JNI (Java Native Interface) – can be challenging. Dynamic JNI registration, obfuscation techniques, and complex control flows often obscure the true functionality.

This is where Frida, a dynamic instrumentation toolkit, shines. And when it comes to deep, instruction-level tracing of native code, Frida Stalker emerges as an indispensable tool for reverse engineers and security researchers. This article will guide you through using Frida Stalker to unveil hidden JNI logic within Android native libraries.

Prerequisites and Environment Setup

Before we begin our deep dive, ensure you have the following:

• A rooted Android device or an emulator (e.g., AVD, Genymotion)
• ADB (Android Debug Bridge) installed and configured on your host machine
• Frida tools installed on your host machine (pip install frida-tools)
• Frida server running on your Android device (download the correct architecture from Frida releases, push to device, set permissions, and execute)

Setting Up Frida Server on Android

Assuming you’ve downloaded frida-server--android-, follow these steps:

adb push frida-server /data/local/tmp/frida-server
adb shell "chmod 755 /data/local/tmp/frida-server"
adb shell "/data/local/tmp/frida-server &"

Then, forward the Frida port to your host machine:

adb forward tcp:27042 tcp:27042

Understanding the Challenge with JNI

Traditional Frida hooking with Interceptor.attach() is excellent for known, exported functions. However, JNI functions can be:

• Dynamically Registered: Many libraries don’t export their JNI methods directly. Instead, they register them at runtime using RegisterNatives, often within the JNI_OnLoad function. This makes it hard to locate them by name.
• Internal and Obfuscated: The actual complex logic might reside in internal, non-exported C++ functions called *from* the JNI wrapper. These functions might have obfuscated names or be part of intricate call chains.
• Branching and Conditional Logic: Critical execution paths might depend on runtime values, making static analysis insufficient to understand dynamic behavior.

Frida Stalker addresses these challenges by allowing instruction-level tracing of any code section, enabling us to observe the actual execution flow and register/memory state changes.

Introducing Frida Stalker: Instruction-Level Tracing

Frida Stalker is a dynamic code tracing engine that allows you to observe, log, and even modify the execution of code at an instruction level. It achieves this by rewriting the target code on the fly to insert callbacks for each instruction or basic block. This means it can follow the execution path through complex branching, function calls, and even self-modifying code.

Key features of Stalker:

• Granular Control: Trace individual instructions, basic blocks, or function calls.
• Context Awareness: Access CPU registers, stack, and memory state at each instruction.
• Persistent Tracking: Follow execution across multiple threads and within a specified memory region.

Targeting a Native Library and JNI Logic

Let’s assume we have an Android application com.example.myapp that uses a native library libcryptolib.so. We suspect a critical cryptographic operation or a hidden check is performed within this library, triggered by a Java method. Our goal is to understand what happens inside libcryptolib.so when a specific Java method calls into native code.

Step 1: Identify the Target Application and Library

First, we need to know the package name and the native library’s name. You can often find this in the app’s APK structure (lib/<arch>/libcryptolib.so) or by examining /proc/<pid>/maps once the app is running.

frida-ps -Uai | grep com.example.myapp
# Get PID, e.g., 12345

frida -U -p 12345 --no-pause
> Process.getModuleByName("libcryptolib.so")

This will give you the base address and size of the library, which is crucial for Stalker.

Step 2: Crafting a Frida Stalker Script

Our script will do the following:

1. Attach to the target process.
2. Locate the libcryptolib.so module.
3. Use Interceptor to hook JNI_OnLoad to find dynamically registered native methods, or if we already know a JNI function name (e.g., from static analysis or a string search), we can directly target it.
4. Once inside a native function or a specific memory range, use Stalker.follow() to trace its execution.
5. Define an onReceive callback to process the trace data.

Example: Stalking a Known JNI Function

Let’s assume, through some prior analysis, we’ve identified a JNI function, say Java_com_example_myapp_Crypto_doWork. We want to see every instruction executed within this function.

import frida
import sys

def on_message(message, data):
    if message['type'] == 'send':
        print(f"[+] {message['payload']}")
    elif message['type'] == 'error':
        print(f"[-] {message['stack']}")


def main():
    device = frida.get_usb_device(timeout=10)
    pid = device.spawn(["com.example.myapp"])
    session = device.attach(pid)
    device.resume(pid)

    script = session.create_script("""
        Interceptor.attach(Module.findExportByName(null, 'android_dlopen_ext'), {
            onEnter: function(args) {
                this.libname = Memory.readUtf8String(args[0]);
                if (this.libname.includes("libcryptolib.so")) {
                    console.log("[*] Loading: " + this.libname);
                }
            },
            onLeave: function(retval) {
                if (this.libname && this.libname.includes("libcryptolib.so")) {
                    const cryptoLib = Module.findExportByName(null, 'dlopen') ? 
                                      Module.findExportByName(null, 'dlopen').address.add(retval.toUInt32() - 0x1000) : // Heuristic
                                      Module.findModuleByName("libcryptolib.so");

                    if (cryptoLib) {
                        console.log("[*] libcryptolib.so loaded at: " + cryptoLib.base);
                        
                        const targetFunction = cryptoLib.findExportByName("Java_com_example_myapp_Crypto_doWork");
                        if (targetFunction) {
                            console.log("[*] Found Java_com_example_myapp_Crypto_doWork at: " + targetFunction);
                            
                            Interceptor.attach(targetFunction, {
                                onEnter: function(args) {
                                    console.log("[+] Entering Java_com_example_myapp_Crypto_doWork");
                                    this.context = Thread.getIcsContext(); // Get context for current thread
                                    Stalker.follow({
                                        events: {
                                            call: true, // Log calls
                                            ret: false, // Don't log returns
                                            exec: true, // Log instruction execution
                                            block: false, // Don't log basic blocks
                                            compile: true // Log whenever a basic block is compiled
                                        },
                                        onReceive: function(events) {
                                            const reader = new Stalker.EventsReader(events);
                                            let event = null;
                                            while ((event = reader.next()) !== null) {
                                                if (event.type === 'exec') {
                                                    console.log('0x' + event.address.toString(16) + ": " + Instruction.parse(event.address));
                                                } else if (event.type === 'call') {
                                                    console.log('  CALL from 0x' + event.address.toString(16) + ' to 0x' + event.target.toString(16));
                                                }
                                            }
                                        }
                                    });
                                },
                                onLeave: function(retval) {
                                    console.log("[-] Leaving Java_com_example_myapp_Crypto_doWork");
                                    Stalker.unfollow();
                                }
                            });
                        } else {
                            console.log("[-] Java_com_example_myapp_Crypto_doWork not found in libcryptolib.so. Trying JNI_OnLoad...");
                            // Fallback: Hook JNI_OnLoad and monitor RegisterNatives
                            const jniOnLoad = cryptoLib.findExportByName("JNI_OnLoad");
                            if (jniOnLoad) {
                                Interceptor.attach(jniOnLoad, {
                                    onEnter: function(args) {
                                        console.log("[+] Entering JNI_OnLoad");
                                        Stalker.follow({
                                            events: {
                                                call: true,
                                                exec: true
                                            },
                                            onReceive: function(events) {
                                                const reader = new Stalker.EventsReader(events);
                                                let event = null;
                                                while ((event = reader.next()) !== null) {
                                                    if (event.type === 'exec') {
                                                        const inst = Instruction.parse(event.address);
                                                        // Look for calls to RegisterNatives
                                                        if (inst.mnemonic === 'bl' || inst.mnemonic === 'call') {
                                                            const target = inst.opStr;
                                                            if (target.includes("RegisterNatives")) {
                                                                console.log("[*] RegisterNatives call detected at 0x" + inst.address.toString(16));
                                                            }
                                                        }
                                                    }
                                                }
                                            }
                                        });
                                    },
                                    onLeave: function(retval) {
                                        console.log("[-] Leaving JNI_OnLoad");
                                        Stalker.unfollow();
                                    }
                                });
                            }
                        }
                    }
                }
            }
        });
    """)
    script.on('message', on_message)
    script.load()

    print("[+] Attached to PID: " + str(pid) + ". Waiting for input...")
    sys.stdin.read()
    session.detach()

if __name__ == '__main__':
    main()

Analyzing the Output

When you run the script, every instruction executed within Java_com_example_myapp_Crypto_doWork (or during JNI_OnLoad if you take that path) will be printed to your console. This includes:

• The memory address of the instruction.
• The disassembled instruction (e.g., ADD R0, R1, #0x10).
• Information about function calls made from within the stalked region.

By carefully examining this trace, you can piece together the native function’s logic. You can identify memory accesses, arithmetic operations, control flow changes (jumps, branches), and calls to other internal functions. This is incredibly powerful for:

• Parameter Analysis: Observe how input parameters are used and modified.
• Return Value Discovery: See how the return value is computed.
• Algorithm Reconstruction: Understand the sequence of operations, especially in cryptographic routines.
• Obfuscation Bypass: Follow the actual execution path through anti-analysis constructs.

Advanced Stalker Usage: Tracing Entire Modules or Memory Ranges

Instead of a single function, you might want to trace an entire module or a specific memory range. Stalker allows this by passing a start and end address to Stalker.follow(). For example, to stalk the entire .text section of libcryptolib.so (assuming you know its base address and size):

// In your Frida script
const cryptoLib = Module.findModuleByName("libcryptolib.so");
if (cryptoLib) {
    const textSection = cryptoLib.findExportByName("dl_iterate_phdr") ? // Heuristic for text section start
                        cryptoLib.base.add(cryptoLib.findExportByName("dl_iterate_phdr").offset - 0x1000) : 
                        cryptoLib.base; // Simplified, in reality you'd parse ELF sections
    const textSectionEnd = cryptoLib.base.add(cryptoLib.size);

    Stalker.follow({
        range: [textSection, textSectionEnd],
        events: {
            call: true,
            exec: true
        },
        onReceive: function(events) {
            // ... process events as before ...
        }
    });
}

Note on range: Accurately determining the .text section’s boundaries can be tricky without parsing the ELF header. A simpler approach might be to stalk from cryptoLib.base for a certain size, or to hook internal functions that are likely to be called.

Limitations and Considerations

• Performance Overhead: Stalker is highly granular and can introduce significant performance overhead, especially when tracing large sections of frequently executed code. This can make the target application very slow or even crash.
• Output Volume: Instruction-level tracing generates a massive amount of data. Filtering and intelligent logging are crucial to avoid being overwhelmed.
• Context Switching: Stalker traces individual threads. If the logic you’re interested in spans multiple threads, you’ll need to manage Stalker.follow() and Stalker.unfollow() on each relevant thread.
• Platform Specifics: ARM/ARM64 assembly knowledge is essential for interpreting the trace output correctly.

Conclusion

Frida Stalker is an incredibly powerful tool for reverse engineering Android native libraries, especially when confronted with dynamic JNI registration, complex control flows, or obfuscated logic. By providing instruction-level visibility into code execution, it allows researchers to dissect the runtime behavior of even the most elusive native functions. While it comes with a learning curve and potential performance implications, the insights gained are invaluable for understanding hidden JNI interactions, reconstructing algorithms, and identifying vulnerabilities.

Mastering Frida Stalker transforms your dynamic analysis capabilities, turning opaque native code into transparent execution traces, ultimately unveiling the secrets within Android’s deepest layers.