Introduction

Android applications often leverage the Native Development Kit (NDK) to execute performance-critical code or integrate existing C/C++ libraries directly. These native binaries, typically shared object files (.so), are compiled for the device’s architecture, with ARM64 (AArch64) being prevalent in modern Android devices. While Java/Kotlin code benefits from robust security features, NDK code operates closer to the hardware, making it a prime target for attackers seeking memory corruption vulnerabilities, privilege escalation, or data exfiltration. Mastering the art of static and dynamic ARM64 NDK code analysis is crucial for security researchers and exploit developers.

This article dives deep into practical techniques for analyzing ARM64 NDK binaries, combining powerful static analysis tools like Ghidra with dynamic runtime analysis frameworks like Frida and GDB. We will explore how to identify potential weaknesses, understand ARM64 assembly, and lay the groundwork for effective exploit development.

Setting Up Your Analysis Environment

Essential Tools and Prerequisites

• Rooted Android Device or Emulator: Necessary for dynamic analysis with Frida and GDB.
• ADB (Android Debug Bridge): For interacting with the device, pushing files, and forwarding ports.
• Ghidra: A powerful open-source reverse engineering framework for static analysis.
• Android SDK & NDK: For ADB, relevant platform tools, and potentially compiling small test binaries.
• Frida: A dynamic instrumentation toolkit for hooking functions, injecting code, and observing runtime behavior.
• GDB Multiarch: A version of GDB capable of debugging ARM64 binaries on a host machine.
• GDB Server: The GDB debugger agent running on the Android device.

Device Preparation

Ensure your rooted device has adb root access. For Frida, install the Frida server on the device:

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

For GDB, you’ll need the gdbserver binary from the Android NDK (e.g., <NDK_HOME>/prebuilt/android-arm64/gdbserver/gdbserver). Push it to your device:

adb push <NDK_HOME>/prebuilt/android-arm64/gdbserver/gdbserver /data/local/tmp/gdbserver
adb shell "chmod 755 /data/local/tmp/gdbserver"

Static Analysis with Ghidra

Loading and Initial Exploration

Begin by extracting the target NDK binary (e.g., libnative-lib.so) from an APK. APKs are essentially ZIP files; you can rename them to .zip and extract. The .so files are usually found in lib/arm64-v8a/.

Open Ghidra, create a new project, and import the .so file. Ghidra will prompt you to analyze it; accept the default options, ensuring ARM64 is selected.

Identifying Key Functions and Structures

Once analyzed, Ghidra’s symbol tree will list exported functions. Android NDK binaries often export functions using the JNI (Java Native Interface) naming convention, such as Java_com_example_app_MainActivity_nativeFunction. These are excellent starting points.

Navigate to the decompiled view of an interesting function. Ghidra’s decompiler is remarkably effective for ARM64, often providing C-like pseudo-code. Pay close attention to:

• Function arguments: In ARM64, the first eight integer arguments are passed in registers X0 through X7. Additional arguments are passed on the stack.
• Return values: Typically returned in X0.
• Memory operations: Look for calls to memcpy, strcpy, snprintf, read, etc., and analyze their parameters. Incorrect size calculations or unchecked input can lead to buffer overflows.
• Loop constructs and comparisons: Identify potential off-by-one errors or integer overflows in loop bounds.
• String operations: Functions like strlen or strcat, especially when combined with fixed-size buffers, are common sources of vulnerabilities.

Example Static Analysis: Buffer Overflow Hunt

Consider a hypothetical native function:

// In Ghidra's Decompiler view, you might see something like:
void Java_com_example_app_MainActivity_processData(JNIEnv *env, jobject thiz, jbyteArray data) {
  jbyte *buffer = (*env)->GetByteArrayElements(env, data, NULL);
  jsize data_len = (*env)->GetArrayLength(env, data);
  char local_buffer[256];

  if (data_len > 256) {
    // This check is good, but what if it's flawed or missing in other places?
    // Or what if it's 256 and memcpy tries to write 257?
    // For this example, let's assume a slightly different bug in the actual memcpy call
    // where data_len is used directly without proper bounds check for the destination.
  }
  memcpy(local_buffer, buffer, data_len); // POTENTIAL VULNERABILITY: data_len could exceed 256
  // ... further processing ...
  (*env)->ReleaseByteArrayElements(env, data, buffer, JNI_ABORT);
}

In the ARM64 assembly, the memcpy call would look like:

00101234  mov  x2, x19            // x19 holds data_len
00101238  add  x1, sp, #0x100     // x1 points to local_buffer (stack allocated)
0010123c  bl   memcpy             // Call memcpy(local_buffer, buffer, data_len)

Here, x2 (third argument) receives data_len, x1 (second argument) receives the source buffer (buffer), and the destination buffer local_buffer (first argument) is passed implicitly before the bl instruction. If data_len exceeds 256 bytes, a stack-based buffer overflow occurs.

Dynamic Analysis with Frida and GDB

Runtime Inspection with Frida

Frida allows you to hook into running processes and instrument native functions. This is invaluable for understanding how functions behave with live data and for confirming static analysis findings.

First, get the package name of the target application (e.g., com.example.app). You can find this in the APK’s AndroidManifest.xml or using adb shell pm list packages.

Here’s a basic Frida script to hook memcpy and observe its arguments:

// hook_memcpy.js
Java.perform(function() {
  var baseAddr = Module.findBaseAddress('libnative-lib.so');
  if (baseAddr) {
    console.log('libnative-lib.so base address: ' + baseAddr);
    // Find memcpy. If it's imported, you can use Module.findExportByName. Else, resolve address.
    // For demonstration, let's assume we know the offset from static analysis (e.g., 0x123c from base)
    var memcpyPtr = baseAddr.add(0x123c); // Replace with actual memcpy address if not exported

    Interceptor.attach(memcpyPtr, {
      onEnter: function(args) {
        console.log("[*] memcpy called!");
        console.log("  Destination: " + args[0]);
        console.log("  Source:      " + args[1]);
        console.log("  Size:        " + args[2].toInt32());
        // You can read memory here to inspect content
        // console.log("  Source data: " + Memory.readByteArray(args[1], args[2].toInt32()));
      },
      onLeave: function(retval) {
        console.log("[*] memcpy returned.");
      }
    });
    console.log("[*] Hooked memcpy in libnative-lib.so!");
  } else {
    console.log('libnative-lib.so not found or not loaded.');
  }
});

Run this script using:

frida -U -l hook_memcpy.js -f com.example.app --no-pause

Now, interact with your application. When memcpy is called, Frida will print the arguments, allowing you to confirm if a large data_len is indeed being passed.

Deep Debugging with GDB

For more granular control, including setting breakpoints, stepping through assembly, and modifying registers, GDB is indispensable. You’ll typically use gdbserver on the Android device and gdb-multiarch on your host machine.

1. Start the application on your device.

2. Attach gdbserver to the running process:

adb shell "/data/local/tmp/gdbserver --attach <PID> --remote-debug :1234"

Replace <PID> with the process ID of your app (e.g., adb shell pidof com.example.app).

3. Forward the GDB port from your device to your host:

adb forward tcp:1234 tcp:1234

4. Connect with gdb-multiarch on your host:

gdb-multiarch
(gdb) set architecture aarch64
(gdb) target remote :1234

Once connected, you can set breakpoints, inspect memory, and step through code:

• b *0xADDR: Set a breakpoint at a specific address (e.g., the memcpy call). Remember to add the base address of libnative-lib.so to the Ghidra offset.
• c: Continue execution.
• s: Step instruction.
• n: Step over instruction.
• info registers: Display current register values.
• x/16xg $sp: Examine 16 8-byte (quad-word) values from the stack pointer.
• x/s $x1: Examine string at register x1.

GDB allows you to confirm register values (X0-X7 for arguments) at the exact point of a function call, verifying the inputs that lead to a vulnerability.

Bridging Static and Dynamic Analysis for Exploitation

The true power lies in combining these techniques. Static analysis identifies potential vulnerabilities and gives you addresses. Dynamic analysis confirms these vulnerabilities with live data, helps you understand the execution flow, and allows you to test different inputs.

• Identify a primitive: Use static analysis to find functions like memcpy, read, sprintf, or custom functions that might handle user input without proper bounds checks.
• Determine input vector: How does the vulnerable function receive attacker-controlled data? Is it through JNI arguments (jbyteArray, jstring), IPC, or file I/O?
• Craft PoC input: Use dynamic analysis (Frida, GDB) to confirm that crafted input can trigger the vulnerability (e.g., cause a crash, overwrite specific memory regions). For a buffer overflow, this might involve sending an overly long byte array.
• Exploit development: Once confirmed, you can use the detailed understanding of the stack layout, register usage, and memory addresses (obtained from static analysis and refined by dynamic debugging) to develop an exploit payload (e.g., ROP chain for arbitrary code execution or shellcode injection).

Conclusion

Hunting for vulnerabilities in ARM64 NDK code is a challenging but rewarding endeavor. By meticulously combining static analysis with Ghidra to map out the binary’s structure and identify suspicious patterns, and dynamic analysis with Frida and GDB to observe runtime behavior and confirm hypotheses, security researchers can effectively uncover critical flaws. This comprehensive approach empowers you to move beyond superficial analysis and understand the intricate details required for robust vulnerability research and exploit development in the Android ecosystem.