Kong and the mechanical layer of binary analysis

Stripped binaries lose names, and naming is the bulk of the work

Kong is a Python tool for orchestrating large language models inside a reverse engineering workflow. The problem it targets is narrow and real. A stripped binary arrives with no function names, no type information, no variable names and no struct layouts, and the analyst has to rebuild all of it. As the project puts it, this recovery is largely pattern matching: recognising standard library functions, inferring types from usage, propagating names through call graphs.

The argument for using an LLM here is that a model is good at that kind of pattern matching and bad at patience. A binary with a couple hundred functions can eat hours or days of an analyst's time in mechanical naming work. The project's own framing, calling itself the world's first agentic reverse engineer, should be read as a positioning claim rather than a benchmark, but the underlying observation about the time-to-execute curve is concrete and matches how these jobs actually go.

Kong's angle is not simply asking a model questions about decompiler output. The documentation is explicit that pointing an LLM at raw decompiler output gives mediocre results, because the model then lacks calling context, cross-reference information and any sense of how the binary is structured.

Ghidra runs in-process, with no server and no subprocess

The integration choice is the first thing to understand about Kong. It runs Ghidra's analysis engine in-process through PyGhidra and JPype, and the project describes this as giving direct access to the program database with no server, no RPC and no subprocess overhead. Everything downstream depends on that: the results are written back into Ghidra's program database, so the output is a binary where a placeholder like FUN_00401a30 becomes parse_http_header, with recovered structs, parameter names and calling conventions.

The dependency list backs the claim up. pyghidra and jpype1 appear in the package dependencies alongside click, rich, textual for the terminal interface, anthropic and openai for model access, lief and z3-solver for binary handling and symbolic reasoning, and json-repair for handling imperfect model output. That last dependency is a small but telling detail. When an LLM is asked to emit structured data in the middle of a pipeline, malformed JSON is a normal failure mode, and a repair library in the dependency tree suggests the author hit it often.

The project is not a pure Python codebase. The repository contains a Cargo workspace with crates/kong-types and crates/kong-ml, a Cargo.lock, and a kong_output_liblzma directory, so parts of the system are Rust. The Python package itself is published as kong-re, and pyproject.toml declares a console script that binds the kong command to kong.__main__:cli.

Bottom-up call-graph ordering is the whole trick

Here is the mechanism that separates Kong from a chatbot attached to a decompiler. Functions are analysed bottom-up from the call graph, so leaf functions are named first and their callers are then analysed with callees already resolved. Each prompt carries more than the target function: cross-references, string references, caller and callee signatures, and neighbouring data are assembled into a rich context window before the model is consulted at all.

The reasoning is sound. A function that calls a known string handling routine is far easier to name than the same function in isolation, and the propagated names feed forward. The dependency-ordered orchestration is the part that a human analyst would do instinctively and an LLM cannot do without being told, which makes it a genuine contribution rather than a wrapper.

The cost of the approach is that everything waits for the bottom of the graph. A function whose meaning depends on a caller that has not been analysed yet still gets analysed at its turn, and the quality of a large binary therefore depends on how well the leaves resolve first. There is also a plain cost implication: more context per prompt means more tokens per function, and the project ships cost tracking across providers precisely because that adds up.

Signature matching pays for itself before the model ever runs

Not every function deserves inference. Kong identifies known standard library and cryptographic functions by pattern before LLM analysis and skips the expensive step for functions with a known identity. On a stripped binary that links a mainstream C library, this can remove a large share of the functions from the model queue entirely, which cuts both latency and bill.

A second optimisation happens earlier. Syntactic normalization cleans decompiler output before it reaches the LLM: modulo recovery, negative literal reconstruction and dead assignment removal. The stated effect is less noise and fewer wasted tokens. It also improves the odds of the model producing something usable, since a decompiler output full of dead stores and sign-extended constants is harder for a model to reason about and harder for a human to review afterwards.

The agentic deobfuscation pipeline sits on top of that. The project claims it can identify and remove obfuscation techniques including control flow flattening, bogus control flow, instruction substitution, string encryption and VM protection. This is the part with the highest potential payoff and the least room for verification, since the way to check is to read the decompiled output and decide whether the reconstruction is faithful. A wrong deobfuscation is worse than no deobfuscation, because it produces a clean looking listing that no longer matches the machine code.

Cleanup and synthesis reconcile the guesses from parallel workers

The pipeline is described as five phases coordinated by a supervisor: triage, parallel analysis, cleanup, semantic synthesis and export. Triage enumerates functions, classifies them, builds the call graph and matches signatures. Analysis then runs in parallel over the graph tiers. Cleanup normalises and dedupes. Synthesis unifies naming conventions across the binary, synthesises struct definitions from field access patterns, and resolves inconsistencies between functions that were analysed independently.

That synthesis pass is where the parallel work becomes coherent. Independent workers will happily invent three names for the same concept, or infer a struct layout that contradicts another function's field access. Merging those into one consistent story is a separate problem from analysis, and the project treats it as one.

There is also an evaluation harness, which scores analysis output against ground truth source code, measuring symbol accuracy with a word-based Jaccard score and type accuracy with signature component scoring. A BENCHMARKS.md sits in the repository root, and ROADMAP.md sits beside it, so the project is measuring itself against known answers rather than only shipping impressions of a demo. The caveat is that such a harness needs binaries whose original source is available, which narrows what the evaluation can represent.

Confidence falls off a cliff on ARM, Rust and MIPS

The project publishes a confidence table instead of a blanket claim, and it is the most useful page for an adopter. C and C++ are rated High on x86, x86-64, 32-bit ARM and AArch64. Rust is Medium on x86 and x86-64, Low on both ARM targets. C and C++ drop to Medium on MIPS and PowerPC, and Go and Rust are Low on both of those.

High means the project expects reliable decompilation, deobfuscation and recovery of names, types and structure. Medium means usable but noisy decompilation with partial recovery. Low means significant gaps and results that stay incomplete or unreadable. A Go binary on PowerPC is the worst cell in that table, and the honest conclusion is that Kong is currently a strong fit for stripped C and C++ on mainstream architectures and a poor fit for Rust on mobile targets.

The note on size matters as much as the table. Binary size scales positively with function count, LLM cost and time to completion, but also negatively with confidence, so larger binaries produce worse results as well as slower ones. There is no threshold given where a binary becomes too big, which is itself a gap: a team with a hundred megabyte firmware image has no documented way to know in advance whether the run will be worth it.

Installing kong-re and the licence split across the tree

The package is published to PyPI under the name kong-re, and pyproject.toml pins the runtime to Python 3.11 or newer:

[project]
name = "kong-re"
version = "0.2.2"
requires-python = ">=3.11"

The console script it registers is the kong command.

The command line surface is built on click with rich and textual for terminal rendering, and an interactive setup wizard configures the LLM providers. Kong works with Anthropic (Claude) and OpenAI (GPT-4o) out of the box, and smart routing auto-selects whichever provider has a valid key, so the first run needs an API key for at least one of them. Every run of a real binary will spend money on tokens, and the cost tracking feature exists because of that.

The licensing is split across the two languages in the repository, which is worth checking before you vendor anything. The Python distribution is Apache-2.0, while the Cargo workspace declares MIT for its members crates/kong-types and crates/kong-ml, with edition 2021. Apache 2.0 carries an explicit patent grant and conditions redistribution on the licence and notice, whereas MIT asks for the notice alone. Neither licence obliges you to open source your own project, but the two components do not share the same terms. The repository is not archived, and the last push was on 2026-04-03, with v0.2.2 published on 2026-03-18 and the two earlier v0.2 releases within a couple of days of it.

Editorial conclusion

Adopt Kong if your work involves stripped or obfuscated binaries on x86 and x86-64, you can pay for Anthropic or OpenAI API calls, and you want a named, typed Ghidra database faster than naming functions by hand. Do not adopt it for MIPS, PowerPC or Rust targets, where the project rates its own confidence as Medium to Low, and do not expect it to replace judgement on the results it writes into the program database. Verify three things first: that Ghidra can be launched through PyGhidra and JPype on your machine, that your API key routes to a provider the smart router recognises, and that the ground truth in BENCHMARKS.md matches the binary classes you actually analyse. The last push was on 2026-04-03 and the newest release is v0.2.2 from 2026-03-18, so pin that version rather than tracking main.

Frequently asked questions

Official sources

1. amruth-sn/kong on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases