Introduction: Navigating the Labyrinth of Android Native Binaries

Reverse engineering Android native binaries, especially those compiled for ARM64 and stripped of symbols, presents a formidable challenge. Developers often strip these binaries to reduce size and obscure internal logic, making traditional debugging difficult. However, by combining the dynamic instrumentation capabilities of Frida with the powerful debugging features of GDB, we can peer into the darkest corners of these executables. This guide will walk you through setting up a comprehensive Android reverse engineering lab and demonstrate advanced techniques for analyzing stripped ARM64 binaries, laying the groundwork for exploit development.

Understanding ARM64 assembly and its calling conventions is paramount. Unlike higher-level languages, assembly directly manipulates registers and memory, revealing the true execution flow. Our focus will be on leveraging dynamic analysis to compensate for the lack of static information, enabling us to reconstruct function logic and identify potential vulnerabilities.

Setting Up Your Android RE Lab

Before diving into analysis, ensure you have the following prerequisites:

• Rooted Android Device or Emulator: Necessary for installing Frida-server and `gdbserver` and for elevated permissions.
• ADB (Android Debug Bridge): For interacting with the device.
• Frida-server: The on-device component of Frida. Download the `frida-server-*-android-arm64` binary.
• Frida-tools: The host-side Python tools (e.g., `frida-ps`, `frida`). Install via `pip install frida-tools`.
• GDB Multiarch: A cross-architecture GDB capable of debugging ARM64 binaries (e.g., `aarch64-linux-android-gdb` from Android NDK toolchains).
• `gdbserver`: The on-device GDB server. Often found in the Android NDK toolchain (`prebuilt/android-arm64/bin/gdbserver`).
• Obfuscated ARM64 Native Binary: A target `.so` library or executable from an Android app for practice.

Basic Setup Steps:

1. Push Frida-server and GDBserver:

   adb push frida-server /data/local/tmp/frida-server
   adb push gdbserver /data/local/tmp/gdbserver

2. Make Executable and Run:

   adb shell
   cd /data/local/tmp
   chmod +x frida-server gdbserver
   ./frida-server &

   For `gdbserver`, you’ll typically run it attached to a process or listen for connections, which we’ll cover later.

3. Port Forwarding (for GDB):

   adb forward tcp:1234 tcp:1234

The Challenge: Stripped ARM64 Binaries

Stripped binaries lack symbol tables, debug information, and sometimes even relocation tables. This means function names (like `main`, `do_calculation`) are replaced with raw memory addresses, making it difficult to understand code flow statically. When debugging, you can’t simply `b main`; you must set breakpoints at specific memory offsets.

ARM64 Calling Conventions (AArch64):

• Arguments: Passed in registers `x0` through `x7`. Additional arguments are pushed onto the stack.
• Return Value: Stored in `x0`.
• Link Register (`lr` / `x30`): Holds the return address for function calls.
• Stack Pointer (`sp`): Points to the top of the stack.
• Frame Pointer (`fp` / `x29`): Often used to manage stack frames, especially for local variables.

Recognizing these conventions is crucial for understanding function calls, parameters, and return values even without symbols.

Initial Reconnaissance with `file` and `readelf`

Before dynamic analysis, get basic information about your target binary.

file /path/to/your/binary.so

Output might look like:

/path/to/your/binary.so: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, stripped

The