Introduction to Android Native Library Reverse Engineering on MIPS/x86 Architectures

While ARM dominates the modern Android landscape, legacy devices, specialized industrial hardware, and emulators often rely on MIPS or x86 architectures. Reversing native Android libraries (.so files) for these less common architectures presents unique challenges and requires a specialized workflow. This guide explores a powerful combination of IDA Pro and Ghidra for tackling MIPS and x86 native code, providing a detailed, expert-level workflow for security researchers and reverse engineers.

Understanding MIPS and x86 assembly is crucial. Unlike the relatively uniform ARM instruction sets, MIPS is RISC-based with a fixed-length instruction format and a load/store architecture, while x86 is CISC-based with variable-length instructions and complex addressing modes. Both IDA Pro and Ghidra offer robust support for these architectures, but their strengths complement each other in a comprehensive reverse engineering process.

Phase 1: Initial Analysis with IDA Pro

Loading and Initial Setup

IDA Pro excels in its interactive disassembly and advanced static analysis capabilities. Begin by loading your target native library (e.g., libnative.so).

1. File > Open: Select your .so file.
2. Processor Module: IDA Pro will usually auto-detect the architecture (MIPS/x86/x64). Confirm it’s correct.
3. Analysis Options: Stick with default analysis for the first pass. IDA’s auto-analysis is highly sophisticated.

Once loaded, IDA presents the Disassembly View. The ‘Functions’ window (Ctrl+F) is your primary navigation point. Look for exported functions, especially those starting with Java_, indicating JNI (Java Native Interface) methods, or well-known C/C++ library functions.

Navigating Assembly and Identifying Key Areas

IDA’s graph view (Spacebar) is invaluable for understanding control flow. For MIPS, pay attention to delay slots, where an instruction following a branch instruction executes before the branch takes effect. For x86, identify common function prologues (e.g., push ebp, mov ebp, esp) and epilogues.

Example MIPS Instruction (Load Word):

lw $t0, 0($sp)    ; Load word from stack pointer + 0 into register $t0

Example x86 Instruction (Move Register to Register):

mov eax, ebx     ; Move contents of EBX into EAX

Utilize cross-references (x key) to trace where functions are called from and where data is accessed. Identifying string references (Shift+F12) can often reveal error messages, URLs, or other indicative text within the binary, providing clues about functionality.

Data Structures and Signature Analysis

IDA’s ‘Structures’ window (Shift+F9) allows you to define complex data structures, which is critical for making sense of memory layouts. For MIPS/x86, custom calling conventions or compiler optimizations might obscure standard structures, so manual definition based on register usage and stack frame analysis is often necessary.

Applying FLIRT (Fast Library Identification and Recognition Technology) signatures (Shift+F5) can automatically identify common library functions (like those from libc, libstdc++), significantly reducing the analysis scope by labeling known code.

Phase 2: Deep Dive with Ghidra

Project Setup and Initial Analysis

Ghidra, with its powerful decompiler, offers a complementary perspective, translating complex assembly into more readable C-like pseudocode. This is particularly beneficial for high-level understanding of algorithms.

1. File > New Project: Create a non-shared project.
2. File > Import File: Select your .so file. Ghidra will prompt for language and endianness; confirm these match your target.
3. Analyze It?: When prompted, select ‘Yes’. Enable default analyzers. ‘Aggressive Instruction Finder’ and ‘ELF Exteranl Just In Time Thunk Function Analyzer’ can be helpful for native libraries.

Leveraging the Decompiler

The Decompiler window (Window > Decompiler) is Ghidra’s standout feature. As you navigate through functions in the Listing window, the Decompiler will display corresponding pseudocode. This drastically speeds up understanding complex logic compared to pure assembly analysis.

Example Ghidra Decompiler Output (conceptual):

// Original assembly might be dozens of instructions (MIPS/x86)mov r0, #0x10ldr r1, [sp, #0x4]add r0, r0, r1...int custom_function(int param_1, char *param_2){  int local_var = 0x10;  local_var += param_1;  // ... more logic ...  return local_var;}

Rename variables and functions (L key) in the Decompiler or Listing windows to improve readability. Ghidra propagates these changes throughout the analysis, making the code much easier to follow. Define custom data types (Ctrl+L) to represent structures used in the native code, mirroring the effort in IDA Pro but with immediate pseudocode reflection.

Cross-Architecture Challenges and Ghidra’s PCode

Ghidra’s internal representation, PCode, is architecture-agnostic. This intermediate language allows Ghidra to apply generic analysis techniques across different CPU architectures before generating pseudocode. While usually transparent, understanding PCode can be helpful for advanced debugging or when dealing with highly obfuscated binaries where direct assembly-to-pseudocode translation struggles.

For MIPS and x86, pay close attention to calling conventions. MIPS typically passes arguments in registers $a0-$a3 and returns in $v0, while x86 has various conventions (cdecl, stdcall, fastcall) often using the stack or registers like ECX/EDX. Ghidra usually infers these correctly, but manual correction via ‘Edit Function Signature’ can be necessary for accurate pseudocode.

Phase 3: Advanced Techniques and Challenges

Handling Anti-Reverse Engineering

Native libraries, especially for Android, frequently employ anti-reverse engineering techniques:

• Obfuscation: Control flow flattening, instruction substitution, string encryption. Ghidra’s decompiler helps cut through some obfuscation, but manual analysis in IDA might be needed for intricate schemes.
• Anti-debugging: Checks for debuggers (e.g., ptrace on Linux). Dynamic analysis (e.g., using Frida or GDB) might require anti-anti-debugging patches.
• Self-modifying code: MIPS and x86 can both execute code generated or modified at runtime. This often requires dynamic analysis or iterative static analysis, where code is re-analyzed after a known modification point.

Symbol Management and External Libraries

Both IDA Pro and Ghidra allow for robust symbol management. Importing external symbol files (e.g., debug symbols, if available) can greatly enhance the clarity of your analysis. For unstripped binaries, functions and global variables will be clearly named. For stripped binaries, symbol renaming and type definition become crucial for readability.

Understanding the interaction with system libraries (like libc, libm) is vital. Identify calls to standard functions to quickly understand high-level operations, and then focus your effort on the custom logic implemented in the target library.

Conclusion

Reverse engineering MIPS/x86 Android native libraries requires a methodical approach, leveraging the strengths of specialized tools. IDA Pro excels at meticulous assembly-level inspection, control flow graphing, and extensive static analysis. Ghidra complements this with its powerful decompiler, providing a higher-level, C-like abstraction of the code that accelerates understanding of complex algorithms. By integrating these two industry-standard tools into a unified workflow, reverse engineers can effectively dissect and comprehend even the most intricate native binaries across these less common Android architectures, overcoming unique challenges posed by their distinct instruction sets and calling conventions.