Kong: Agentic Reverse Engineering Framework

Kong is an LLM-orchestrated framework designed for automated binary reverse engineering. It automates the mechanical layers of analysis by integrating with Ghidra to perform a full analysis pipeline on stripped or obfuscated binaries.

Key capabilities include:

• Function Triage: Classifying functions and building call-graph context.
• Context-Aware Decompilation: Using Ghidra's program database (call graphs, cross-references, string references) to build rich context windows for LLMs.
• Bottom-Up Analysis: Analyzing functions in dependency order (leaf functions first) so that callers benefit from already-resolved names and types.
• Agentic Deobfuscation: Identifying and removing obfuscation techniques like control flow flattening or string encryption.
• Semantic Synthesis: Unifying naming conventions and synthesizing struct definitions across the entire binary.
• Ghidra Writeback: Automatically applying recovered names, types, and signatures back into the Ghidra program database.

VM-based protection (like VMProtect or Themida) replaces native code with custom bytecode interpreted by an embedded virtual machine. You can identify these patterns by looking for a dispatcher loop that fetches, decodes, and executes bytecodes.

Key indicators include:

• A large switch statement or function pointer table inside a loop.
• A "virtual instruction pointer" (VIP) that increments after each dispatch.
• A "virtual stack pointer" (VSP) or register file used for operands.
• Handler cases that are small (1-5 operations) and uniform in structure.
• Bytecode data stored in a separate section or embedded inline.

Distinguishing VM from Control Flow Flattening (CFF):

• CFF: The state variable is reassigned to large hex constants, and cases contain actual program logic.
• VM: The dispatch variable is loaded from a data pointer (e.g., *vip++), and cases contain generic operations (push, pop, add) while the real logic resides in the bytecode data.

while (1) {
    opcode = *vip++;
    switch (opcode) {
        case 0x01: /* push */ ...
        case 0x02: /* pop */ ...
        case 0x03: /* add */ ...
        case 0x10: /* jmp */ ...
        case 0xFF: return;
    }
}

Kong operates through a five-phase pipeline orchestrated by a supervisor. The process moves from initial triage to final export:

1. Triage: Enumerates functions, classifies them by size, builds the call graph, detects the source language, and performs signature matching for known standard libraries/crypto functions.
2. Analysis: Processes functions bottom-up from the call graph. For each function, Kong builds a context window (decompilation, XREFs, string refs, and callee signatures), normalizes the output, and uses an LLM for recovery. If obfuscation is detected, an agentic deobfuscation pass is triggered.
3. Cleanup: Unifies struct types and retries failed signature applications.
4. Synthesis: Performs a global pass to unify naming conventions and refine names based on the broader binary context.
5. Export: Writes the final analysis.json and performs the Ghidra writeback to update the program database.

Bogus Control Flow (BCF) obfuscation injects fake branches into functions using opaque predicates—conditions that always evaluate to the same value regardless of input. The actual logic remains unchanged, but the control flow graph is artificially expanded with 'dead' branches containing junk code or modified copies of real code.

Common Opaque Predicate Patterns

Look for mathematical identities or bitwise operations that are constant:

• (x * (x + 1)) % 2 == 0 (Always true)
• (x * x) % 2 == x % 2 (Always true)
• (x | ~x) == -1 (Always true)
• (x ^ x) != 0 (Always false)
• (x & ~x) != 0 (Always false)
• Conditions involving global variables that are never modified.

Identifying Dead Branches

Dead branches often exhibit these characteristics:

• Unreachable code that still references valid memory addresses.
• Cloned/modified copies of nearby legitimate code.
• Random arithmetic that produces no visible side effects.

To de-obfuscate a function protected by Control Flow Flattening, follow this recovery strategy:

1. Identify the state variable: Find the local integer reassigned in every switch case.
2. Extract transitions: Use the trace_state_machine tool to automatically extract the state transition graph.
3. Trace state transitions: For every case, record the mapping of (current_state → next_state) and any logic that determines the next state.
4. Build a state transition graph: Map out all states and their connections.
5. Collapse linear chains: If states transition unconditionally from one to another, combine them into sequential statements.
6. Identify conditional branches: Cases where the next state depends on a condition should be converted into if/else blocks.
7. Identify loops: Any cycles found in the state graph should be reconstructed as while or for loops.
8. Reconstruct structured code: Map the processed graph back into standard high-level programming constructs.
9. Finalize: Name and type the function based on the newly recovered logic.