Original Summary

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<i> vtable calls decompile as raw pointer offsets like (*(code *)(</i>param_1 + 0x548)). I built JNISleuth-MCP to automate that workflow: 1. It parses multi-DEX APKs for native declarations and sweeps .rodata &#x2F; .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 &#x2F; B instructions). 3. For runtime-packed samples that detect Frida, it includes a C++&#x2F;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&#x2F;idat64), and exposes a model-agnostic MCP server + OpenAI&#x2F;Gemini&#x2F;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!

  • 情报分类：商业与市场研究
  • 分类依据：内容涉及商业、投资或市场动态
  • 信息来源：Hacker News 新项目
  • 发布时间：2026/10/13 23:13:19