JNISleuth-MCP – Recover Stripped JNI Bindings and Ollvm Branches for Ghidra/Ida
2•akdapunk•5h ago
Hi HN, I’m a security engineer focused on Android anti-malware and reverse engineering.
When reversing hardened Android apps or wild malware, one of the most tedious parts is crossing the Java-to-Native (JNI) boundary when `.so` binaries are stripped, methods are bound dynamically via `RegisterNatives` inside an OLLVM-flattened `JNI_OnLoad`, and `JNIEnv` vtable calls decompile as raw pointer offsets like `(*(code *)(param_1 + 0x548))`.
I built JNISleuth-MCP to automate that workflow:
1. It parses multi-DEX APKs for `native` declarations and sweeps `.rodata` / `.data.rel.ro` (or section-header-stripped `PT_LOAD` segments) for `(char* name, char* sig, void* fnPtr)` triplets.
2. It statically resolves ARM64 OLLVM `CSEL` + `BR X8` indirect branches and `.rodata` jump tables in `JNI_OnLoad` (and can patch them in-place with direct `B.cond` / `B` instructions).
3. For runtime-packed samples that detect Frida, it includes a C++/NDK Dobby collector that hooks `RegisterNatives` mid-function.
4. It syncs the full 233-slot `JNIEnv*` vtable types and recovered C signatures into headless Ghidra and IDA Pro 9.0 (`idalib`/`idat64`), and exposes a model-agnostic MCP server + OpenAI/Gemini/Ollama tool schemas.
The repo includes a synthetic multi-DEX + stripped ARM64 `.so` crackme so you can test the entire pipeline in 30 seconds without needing a live malware sample. Would love feedback from anyone doing mobile RE or binary analysis!