ReAgent: an LLM reverse-engineering loop that gates its own decompiled output
Reconstruct and validate C/C++ code from compiled programs with AI.
At a glance
- What is it?
- ReAgent wraps Ghidra exports and a reverser/checker model pair in a bounded validation loop that produces candidate C/C++ functions. The interesting part is not the model choice but the four independent gates a candidate has to clear before the tool calls the reversal successful.
- Who is it for?
- ReAgent fits teams already using Ghidra who want candidate source for specific functions and are willing to run build and test gates against a project copy. It is a poor fit if you want a binary patched in place or a semantic equivalence proof, because the README states plainly that the verification is conservative, not a proof, and that the tool never patches the original source tree.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 6 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap ReAgent targets: decompiler output that nobody validates
A decompiler gives you pseudocode. It does not give you code that compiles, links, or passes the project's own tests, and it does not tell you whether the reconstructed function is structurally consistent with the binary it came from. ReAgent is built around that second problem. According to the README, it reconstructs and validates C/C++ functions from compiled programs, combining independent reverser and checker models with agentic evidence gathering, candidate build and test gates, structural verification, and parity analysis. The intended user is someone doing reverse engineering on a codebase they can build, not someone who only has a stripped binary and no toolchain. The validation stages assume a configured build, test, and runtime gate, which means the project has to be compilable in the first place. That is a narrower audience than the topic list suggests.
What actually runs between the Ghidra export and the candidate file
The README's pipeline diagram is the clearest statement of the mechanism. A reverse run starts from configuration (YAML plus environment overrides plus CLI flags) and a function selection strategy: dependency-order, easiest-first, or high-impact. It then collects source and binary context, which the diagram breaks into decompilation, xrefs, structs, enums, vtables, globals and strings on one side, and normalized high P-code, CFG, assembly and nearby project source on the other. Those two context sets feed a reverser to checker to fix loop with bounded rounds and investigations. A conservative structural verifier runs next, then a candidate overlay applies the configured build, test and runtime gates, and a parity gate returns GREEN, YELLOW or RED. The output is reports, per-call logs, round checkpoints, session history and a knowledge graph. The bounded rounds matter: the loop is not open-ended, so a function the models cannot get right will terminate rather than burn calls indefinitely.
Four gates, and what each one can and cannot catch
The README lists four independent conditions for a successful reversal. The LLM checker must return PASS. The objective verifier must find no strong structural mismatch. Candidate validation must satisfy the configured acceptance policy. Parity must not be blocked by the configured RED/YELLOW policy. Splitting the checker from the reverser is the design decision worth noting, because a single model grading its own output tends to converge on agreement. The README also supports this at the configuration level: the agents block lets you set a different provider and model for the checker, with codex and gpt-5.4 shown as an example against a claude-cli reverser on sonnet. The structural verifier is described as conservative, and the README is explicit that this is conservative verification, not a proof of semantic equivalence. Read that sentence as the tool's own boundary: a GREEN parity result means the candidate cleared the gates you configured, not that it behaves identically to the original.
Installation path and the config keys that matter
Installation is a single pip command with the bridge extra: python3 -m pip install --upgrade "auto-re-agent[ghidra-bridge]>=0.4.0". For headless Ghidra exports the README gives a separate extra, auto-re-agent[headless]. Requirements are Python 3.10 or newer, Git for the source install, Ghidra with a configured Ghidra Bridge, and at least one LLM path: ANTHROPIC_API_KEY, OPENAI_API_KEY, an authenticated local claude command, or an authenticated local codex command. Evidence comes from four bridge commands run inside the target project: ghidra-bridge init, ghidra-bridge export all, ghidra-bridge build-map, and ghidra-bridge info. In the project itself, re-agent init --profile generic-cpp writes re-agent.yaml; other profiles are windows-x64, gta-reversed and openrct2, and running init without a profile keeps the original GTA-reversed defaults, which the README advises against for new projects. The YAML keys shown are llm.provider, llm.model, agents.checker.provider, agents.checker.model, backend.type, backend.cli_path, project_profile.name, project_profile.language_standard, project_profile.source_root and project_profile.hooks_csv.
The Windows shell dependency is a real constraint, not a footnote
Version 0.4.0 changed how validation commands are executed. The release notes state that build, test and runtime validation now support argument arrays that execute directly on Windows and POSIX, and that on native Windows shell strings must be converted to arrays because legacy strings still require /bin/sh. The same notes say re-agent doctor reports a missing shell. That is the failure mode to plan for: a project whose validation commands are written as shell strings will not run on native Windows without migration, and the doctor command is the check that surfaces it. The README points to a migration and configuration document for portable validation commands. If your build gate is a POSIX shell one-liner, budget time for converting it before you expect a reversal to complete, because the candidate overlay stage depends on those gates executing.
Manifest mode and what it buys you
The 0.4.0 notes add a set of manifest-oriented subcommands. re-agent plan builds bounded function manifests without model calls, which is the cheapest way to inspect what the tool intends to do. re-agent reverse --manifest reconstructs selected functions across classes with dependency ordering and cumulative validation in an isolated project copy. re-agent evidence --manifest exports stored evidence into linked JSON packets and TSV indexes, and re-agent status --manifest reports coverage, stale results and individual validation checks. The isolated project copy is the detail that makes batch reversal tolerable: candidates are applied to a copy, not to your working tree, which matches the README's statement that the tool generates candidate implementations and does not patch the original source tree automatically. Evidence gaps are described as remaining explicit rather than being filled in silently, and manifests are said to stay readable after backend errors with empty messages.
Where a different tool is the better answer
The README's own first instruction is to give the repository to an AI coding agent and let it check the setup, install missing tools and walk through configuration. That is a reasonable onboarding route, but it means the practical alternative for many users is not a competing decompiler. It is the AI coding agent they already have, pointed at Ghidra exports by hand. The difference in approach is the loop. A general agent with shell access can read decompiled output and write a C++ file, but it brings no reverser/checker split, no bounded fix rounds, no structural verifier, no candidate overlay against build and test gates, and no GREEN/YELLOW/RED parity state. If your goal is a handful of functions and you will read every line yourself, the manual route costs less setup. ReAgent earns its complexity when the function count is large enough that per-function human review of the validation evidence is the bottleneck, and when the project already builds and tests cleanly enough to serve as a gate.
Licence, maintenance and what to check before committing
ReAgent is MIT-licensed, which permits commercial use and modification, though the repository is the only authority on the exact terms and this is not legal advice. The dependency situation is worth noting: the Ghidra Bridge is a separate project under Dryxio, installed as an extra or from its own Git URL, so your maintenance surface includes two repositories and a local Ghidra installation. The release cadence visible in the material is three releases between July and September 2026, with 0.4.0 arriving five days after 0.3.0, which suggests active churn in the CLI surface. The manifest subcommands and the Windows argument-array handling both landed in 0.4.0, so configuration written against 0.3.0 may need revision. Pin the version in the pip command rather than tracking main if you are scripting around the CLI. The first thing to verify on your own machine is that ghidra-bridge info reports your exports, because every later stage depends on evidence that stage produced.
Editorial conclusion
ReAgent fits teams already using Ghidra who want candidate source for specific functions and are willing to run build and test gates against a project copy. It is a poor fit if you want a binary patched in place or a semantic equivalence proof, because the README states plainly that the verification is conservative, not a proof, and that the tool never patches the original source tree. Before adopting, run re-agent doctor to confirm the Ghidra bridge and a shell are present, then run re-agent plan on a small class and inspect the manifest before spending a single model call.
Community notes