kong - Moses Yebei

The Problem

Reverse engineering stripped binaries is time-consuming due to the loss of context—function names, type information, and variable names—that makes code readable. The manual process of recovering this context through pattern matching is tedious and repetitive, even for relatively small binaries with a few hundred functions. Existing tools require significant manual intervention, making the process inefficient and error-prone.

What This Does

Kong is an autonomous reverse engineering pipeline that automates the mechanical aspects of binary analysis. It integrates with Ghidra (via kong/ghidra/client.py) to perform a full analysis pipeline, including triaging functions, building call-graph context, recovering types and symbols through LLM-guided decompilation, and writing results back into Ghidra's program database. The key components are:

Agentic Deobfuscation Pipeline: Located in kong/agent/deobfuscator.py, this module handles deobfuscation of stripped binaries.
LLM Orchestration: Managed by kong/llm/client.py and kong/llm/openai_client.py, this component uses LLMs to infer function names, types, and structures from decompiled code.
Call-Graph Analysis: Implemented in kong/agent/analyzer.py, this module ensures functions are analyzed in dependency order, leveraging already-resolved context for callees.

The pipeline is designed to be fully autonomous, requiring minimal manual intervention.

How It Is Wired

Execution starts with kong/__main__.py, which orchestrates the entire pipeline. Key control flows include:

Initialization: The kong/config.py file handles configuration, while kong/db.py manages database interactions.
Ghidra Integration: The kong/ghidra/client.py file runs Ghidra's analysis engine in-process, providing direct access to the program database.
Function Analysis: The kong/agent/analyzer.py file performs bottom-up analysis from the call graph, naming leaf functions first.
LLM Interaction: The kong/llm/client.py and kong/llm/openai_client.py files handle LLM prompts and responses, enriching the decompiled code with context from cross-references, string references, and caller/callee signatures.
Post-Analysis Synthesis: The kong/agent/supervisor.py file unifies naming conventions and resolves inconsistencies between independently analyzed functions.

The most critical files in terms of blast radius are kong/agent/analyzer.py and kong/llm/client.py, as they are central to the analysis pipeline and LLM interaction.

How To Use It

Setup

To set up Kong, clone the repository and install dependencies:

git clone https://github.com/moses-y/kong
cd kong
pip install -e .

Configuration

Configure Ghidra and LLM credentials in kong/config.py. Ensure you have the necessary environment variables set for API keys and database connections.

Running It

Invoke the main script to start the analysis:

python -m kong <binary_path>

Replace <binary_path> with the path to the binary you want to analyze.

Real-World Use

Kong is particularly useful in scenarios where quick reverse engineering of stripped binaries is required. For example, security researchers can use Kong to analyze malware samples or proprietary binaries, quickly recovering function names and types to understand the code's behavior.

Code Health & Issues

Tests: 29 test files found, covering various components of the pipeline.
Documentation: 3 doc files found, providing basic setup and usage information.
Code Quality: No structural red flags detected. Tests, CI, license, and lockfile are present where expected.

The Bottom Line

Kong provides a valuable solution for automating the tedious aspects of reverse engineering stripped binaries. Its integration with Ghidra and use of LLMs for context-aware analysis makes it a powerful tool for security researchers and reverse engineers. However, the project is still in its early stages, with some components requiring further refinement and testing.

What the analyser found

Deployment readiness

6/7

Container image
CI pipeline
Lockfile committed
Test suite
README
License
No committed secrets

Composition

134 files

Python84
Rust12
Markdown9
Shell6
TOML5
YAML4

FlaskDockerTransformers

Architecture

Top-level areas of the codebase, sized by module count. Arrows show how many imports cross from one area into another.

graph TD g0["kong<br/>45 modules"] g1["tests<br/>24 modules"] g2["tools<br/>15 modules"] g1 -->|76| g0

Module dependencies

The 10 most depended-upon modules of 84, from static import analysis. Red outline marks a module in an import cycle.

graph LR n0_kong_ghidra_types["types"] n1_kong_config["config"] n2_kong_agent_models["models"] n3_kong_agent_analyzer["analyzer"] n4_kong_ghidra_client["client"] n5_kong_agent_queue["queue"] n6_kong_llm_usage["usage"] n7_kong_llm_client["client"] n8_kong_llm_tools["tools"] n9_kong_agent_events["events"] n3_kong_agent_analyzer --> n2_kong_agent_models n3_kong_agent_analyzer --> n5_kong_agent_queue n3_kong_agent_analyzer --> n4_kong_ghidra_client n3_kong_agent_analyzer --> n0_kong_ghidra_types n3_kong_agent_analyzer --> n8_kong_llm_tools n3_kong_agent_analyzer --> n6_kong_llm_usage n2_kong_agent_models --> n3_kong_agent_analyzer n5_kong_agent_queue --> n0_kong_ghidra_types n4_kong_ghidra_client --> n0_kong_ghidra_types n7_kong_llm_client --> n3_kong_agent_analyzer n7_kong_llm_client --> n8_kong_llm_tools n7_kong_llm_client --> n6_kong_llm_usage n8_kong_llm_tools --> n4_kong_ghidra_client n6_kong_llm_usage --> n1_kong_config classDef cyc stroke:#ef4444,stroke-width:2px; class n2_kong_agent_models,n3_kong_agent_analyzer cyc;

Dependencies

12 declared dependencies, none a major version behind. Resolved 0 of 12 against the registry.

What would stop me shipping this

Ranked by severity × confidence × production reach. Reach is the honest discriminator across a collection that is mostly other people's code: the same finding matters more in something that ships.

high1

medium5

low2

Pin third-party GitHub Actions to a commit SHAhigh

.github/workflows

astral-sh/setup-uv@v4

A tag can be moved, so the action running with your token and secrets is whatever its owner last pushed; this is how tj-actions/changed-files leaked secrets from thousands of repos.

Fix: Replace each @vN with the 40-character commit SHA, keep # vN as a comment, and let Dependabot bump the SHAs.

Declare least-privilege permissions for GITHUB_TOKENmedium

.github/workflows/ci.yml

1 workflow(s) declare no permissions

With no declaration the token inherits the repository default, so any injected step can push commits or mint releases from inside your own CI.

Fix: Add permissions: contents: read at the top of the workflow and widen per job only where needed.

Enable Dependabot or Renovatemedium

5 manifest(s), no update bot configured

Without a bot a published advisory sits unpatched until someone audits by hand, which across 1,322 repositories means never.

Fix: Commit .github/dependabot.yml covering the repo ecosystems plus github-actions.

Pin the container base image by digestmedium

tools/xda/scripts/Dockerfile.corpus

debian:bookworm

An untagged or mutable base means today's build and last month's contain different libc and a different CVE set, with no record of which shipped.

Fix: Use image:tag@sha256:<digest> and enable Dependabot's docker ecosystem.

Gate pull requests on a dependency vulnerability scanmedium

.github/workflows

no dependency scan in CI

This is the one gate that would catch a known-vulnerable package before it reaches a build, and no repository in the sample had it.

Fix: Add dependency-review-action on pull_request, or osv-scanner on push and a schedule.

Add a non-root USER to the imagemedium

tools/xda/scripts/Dockerfile.corpus

CMD or ENTRYPOINT with no USER directive

A process running as root in the container is root against every mounted volume, and it turns any container escape or writable-mount mistake from a contained problem into a host one.

Fix: Create an unprivileged user, chown what it needs, and end the Dockerfile with USER.

Set timeout-minutes on the workflow jobslow2 occurrences

.github/workflows/ci.yml

2 workflow(s) declare no job timeout

A wedged step runs to the six-hour platform default, which on a two-hourly schedule means three runs overlap behind it.

Fix: Add timeout-minutes with a realistic bound to each job.

Add the repository convention files this project lackslow3 occurrences

missing .editorconfig, .gitattributes, a formatter config

Without them one contributor's editor writes tabs into a Python file, a shell script commits with CRLF and fails in the container, and a notebook diff is unreviewable.

Fix: Add .editorconfig, .gitattributes with text=auto eol=lf, and a formatter config.

Checked deterministically against the repository tree and a bounded set of its files: committed credentials, unpinned actions and base images, missing lockfiles and update bots, workflows that discard failures, published advisories against the declared dependencies, runtime configuration, licensing and notebook reproducibility. No language model is involved in this section.