JNISleuth-MCP – Recover Stripped JNI Bindings and Ollvm Branches for Ghidra/Ida

Recovering stripped JNI bindings and unflattening OLLVM-obfuscated branches is a complex process that transforms an unreadable 'ocean of unnamed functions' into a structured, analyzable codebase. Whether using a specialized tool like JNISleuth-MCP or a manual toolkit, the objective is to restore the mapping between Java and native code and resolve the distorted control flow graph (CFG).

1. Recovering Stripped JNI Bindings

In hardened Android binaries, symbols are often removed, and the mapping between Java and C++ is handled at runtime via RegisterNatives.

The Technical Process:

• ·Static Analysis of RegisterNatives: The core goal is to locate calls to the RegisterNatives function. By tracing the JNINativeMethod array structure passed to this function, you can extract three critical pieces of data: the Java method name, the method signature (e.g., (Ljava/lang/String;)I), and the function pointer to the native implementation.
• ·Pattern Recognition: Search for function signatures that match the JNI standard: void (*)(JNIEnv*, jobject, ...). In Ghidra, you can use Function Signature Analysis (Ctrl+Shift+A) to detect these patterns.
• ·String Analysis: Even in stripped binaries, search for strings starting with Java_ (the standard naming convention) to identify potential entry points.
• ·Dynamic Validation: If the app can be run, use Frida or Xposed to hook RegisterNatives at runtime, logging the exact mappings as they are registered by the Android Runtime (ART).

Result: Once these mappings are extracted, you can rename the obfuscated addresses in Ghidra or IDA, instantly grounding the business logic in its original Java context.

2. Unflattening OLLVM Branches

OLLVM (Obfuscator-LLVM) uses Control Flow Flattening (CFF) to condense logic into a single large switch statement inside a while(true) loop, governed by a "state variable."

Methods for Recovery:

• ·Data Flow & Symbolic Execution: To resolve the "spaghetti code," you must analyze the state variable. Tools like Triton or Angr can be used to mathematically prove which state values lead to which execution paths, effectively ignoring "bogus" branches (opaque predicates) that are always true or false (e.g., if (x * x + 1 < 0)).
• ·CFG Reconstruction: By tracking how the state variable is updated at the end of each basic block, the original logic can be reconstructed.
• ·Patching and Microcode Modification: Once the true path is known, the binary can be patched. In IDA Pro, modifying the Hex-Rays microcode is more robust than patching raw assembly, as it replaces the switch dispatcher with direct jmp or conditional branch instructions.

3. Integration and Tooling

To be effective, these processes must be integrated directly into the disassembler's API:

Practical Workflow Summary

1. ·Identify Bindings: Search for RegisterNatives and Java_ strings $\rightarrow$ Map Java methods to native addresses $\rightarrow$ Rename functions.
2. ·Identify Obfuscation: Spot the "giant switch" in the decompiler $\rightarrow$ Identify the state variable.
3. ·Deobfuscate: Use symbolic execution to solve predicates $\rightarrow$ Patch the dispatcher to restore linear control flow $\rightarrow$ Decode XOR-encoded strings.
4. ·Analyze: Leverage the reconstructed pseudo-C code for vulnerability hunting or algorithmic analysis.