---

⚡ Perché JNISleuth-MCP?

Il malware Android moderno, i trojan bancari, lo spyware e i packer commerciali nascondono la loro logica principale (cifratura C2, derivazione delle chiavi, controlli sull'ambiente e routine di exploit) all'interno di librerie native C/C++ stripped (lib*.so).

Quando si fa reverse engineering attraverso il confine JNI, gli analisti si scontrano con tre ostacoli:

1. Riferimenti incrociati interrotti: i metodi native dichiarati in classes.dex non utilizzano i simboli standard Java_com_pkg_Class_method. Invece, vengono associati dinamicamente a runtime all'interno di un JNI_OnLoad offuscato tramite JNIEnv->RegisterNatives().
2. Decompilazione cieca: aprire una .so stripped in Ghidra o IDA mostra migliaia di funzioni sub_XXXX senza nome, dove le chiamate alla vtable di JNIEnv* appaiono come pura aritmetica di puntatori ((**(code **)(*param_1 + 0x538))(param_1, param_2)).
3. Contesto AI disconnesso: i server MCP esistenti per Ghidra e Jadx vivono in silos: un LLM non può tracciare il flusso di dati da un BroadcastReceiver Android in Java direttamente fino a una routine di cifratura ARM64 in libnative-lib.so.

JNISleuth-MCP elimina il cambio di contesto. Recupera automaticamente le associazioni statiche e dinamiche di RegisterNatives, ridigita le funzioni ARM64 stripped in Ghidra ed espone un unico server unificato Model Context Protocol (MCP) che collega il bytecode DEX all'assembly nativo.

Capacità	MCP standard Jadx / Ghidra	JNISleuth-MCP
Risolvere le esportazioni standard Java_*	✅	✅
Recuperare staticamente gli array di struct RegisterNatives stripped (.rodata / .data.rel.ro + CFG di JNI_OnLoad)	❌	✅
Raccolta stealth di RegisterNatives sul dispositivo tramite Dobby (aggira i controlli anti-Frida)	❌	✅
Applicare automaticamente i tipi della vtable di JNIEnv* e ricostruire Call*Method / GetStringUTFChars in Ghidra	❌	✅
Dataflow cross-boundary in una singola chiamata (Java Caller ➔ JNI Bridge ➔ C++ ARM64 decompilato)	❌	✅

---

🏗️ Architettura e come funziona

flowchart LR
    subgraph Input["📦 Target APK / Malware"]
        DEX["classes*.dex"]
        ELF["Stripped lib/*.so (ARM64)"]
    end

    subgraph Harvester["🔍 Stage 1: JNI Bridge Harvester"]
        StaticScan["Static ELF & DEX Scanner\n(LIEF + Capstone + Heuristic Triplets)"]
        DobbyAgent["Stealth Native Agent\n(C++ / NDK / Dobby Inline Hook)"]
    end

    subgraph GhidraEngine["⚙️ Stage 2: Ghidra Headless Reconstructor"]
        Renamer["Function Renamer & Signature Applier"]
        VTable["JNIEnv* VTable & Struct Propagator"]
    end

    subgraph MCPServer["🤖 Stage 3: Unified FastMCP Server"]
        CrossGraph["Cross-Boundary Callgraph\n(Jadx Java + Ghidra C/ARM64)"]
        CallbackTrace["Upcall Tracer\n(Native -> Java Reflection)"]
    end

    DEX --> StaticScan
    ELF --> StaticScan
    ELF -. "Packed / OLLVM?" .-> DobbyAgent
    StaticScan --> Renamer
    DobbyAgent -- "register_natives.json" --> Renamer
    Renamer --> VTable
    VTable --> CrossGraph
    VTable --> CallbackTrace

🎬 Vedilo In Azione

1. Recupero RegisterNatives Statico + Dinamico da CLI

Esegui jnisleuth scan su un APK con librerie native ripulite:

$ jnisleuth scan --apk samples/banker_dropper.apk --arch arm64-v8a

[*] Parsing 3 DEX files... Found 14 declared `native` methods across 4 classes.
[*] Inspecting lib/arm64-v8a/libcore-crypto.so (Stripped ELF, 0 exported Java_* symbols)
[*] Running static JNINativeMethod triplet scanner on .rodata / .data.rel.ro...
    [+] Resolved 11/14 methods via static struct table @ 0x0004d210
[!] 3 methods unresolved (constructed dynamically on stack in JNI_OnLoad).
[*] Launching headless Dobby collector on device (emulator-5554)...

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━┓
┃ Java Class & Method                      ┃ JNI Signature        ┃ .so Offset (ARM64)  ┃ Resolution Mode  ┃
┡━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━┩
│ com.dropper.Core#initEngine              │ (Landroid/content/.. │ libcore.so+0x001a40 │ Static (.rodata) │
│ com.dropper.Core#decryptPayload          │ ([BLjava/lang/Stri.. │ libcore.so+0x0023c8 │ Static (.rodata) │
│ com.dropper.Core#signC2Beacon            │ (Ljava/lang/String.. │ libcore.so+0x003f10 │ Dynamic (Dobby)  │
│ com.dropper.net.SocketBridge#connectRaw  │ (Ljava/lang/String.. │ libcore.so+0x004890 │ Dynamic (Dobby)  │
└──────────────────────────────────────────┴──────────────────────┴─────────────────────┴──────────────────┘
[+] Synced 14 function signatures and JNIEnv* types to Ghidra project: banker_dropper.gpr

2. Prima e dopo in Ghidra

Prima di JNISleuth-MCP (FUN_000123c8):

long FUN_000123c8(long *param_1, undefined8 param_2, undefined8 param_3, undefined8 param_4) {
  char *pcVar1;
  long lVar2;
  pcVar1 = (char *)(**(code **)(*param_1 + 0x548))(param_1, param_4, 0);
  lVar2 = (**(code **)(*param_1 + 0x5c0))(param_1, param_3, 0);
  sub_00014a00(lVar2, pcVar1);
  (**(code **)(*param_1 + 0x550))(param_1, param_4, pcVar1);
  return param_3;
}

Dopo JNISleuth-MCP (Java_com_dropper_Core_decryptPayload):

jbyteArray Java_com_dropper_Core_decryptPayload(
    JNIEnv *env, jobject thiz, jbyteArray encryptedData, jstring rc4KeyStr) 
{
  const char *key_utf = (*env)->GetStringUTFChars(env, rc4KeyStr, NULL);
  jbyte *payload_bytes = (*env)->GetByteArrayElements(env, encryptedData, NULL);
  rc4_crypt_buffer(payload_bytes, key_utf);
  (*env)->ReleaseStringUTFChars(env, rc4KeyStr, key_utf);
  return encryptedData;
}

🤖 Supporto universale LLM e MCP (funziona con qualsiasi modello)

JNISleuth-MCP è completamente indipendente dal modello. Puoi collegarlo a qualsiasi LLM cloud o locale tramite il Model Context Protocol standard (stdio JSON-RPC 2.0) oppure esportare schemi nativi di function-calling OpenAI / Gemini / Ollama:

• LLM e agenti cloud: Google Gemini CLI, OpenAI / ChatGPT Desktop / Codex CLI, Cursor, Windsurf, Cline, Roo Code, Claude Desktop / Claude Code
• LLM locali / self-hosted: Ollama, vLLM, LM Studio, OpenWebUI, Continue.dev (DeepSeek-R1, Qwen-2.5-Coder, Llama-3.3)
• SDK Python per agenti personalizzati: esportazione diretta dello schema degli strumenti (jnisleuth llm-tools --format openai|gemini|mcp) per LangChain, LlamaIndex, LiteLLM, OpenAI SDK o google-genai.