Auto RE Agent
Reconstruct and conservatively validate C/C++ functions from binaries with Ghidra evidence and LLMs.
Per-dimension scores and reasoning
Evidence shows: the tool explicitly does not modify the original source tree automatically, candidate code is written to an overlay, isolated validation runs in a temporary copy, and trust_configured_commands must be explicitly set to trust project-owned shell commands. This reflects least privilege and user confirmation. Data flow transparency: documentation describes evidence collection, candidate generation, validation, and reporting, but lacks detailed internal data flow diagrams. Sensitive data handling: involves API keys, but documentation suggests environment variables, no hardcoded keys found. Dependency security: dependencies include anthropic and openai, but no version pinning or vulnerability scanning evidence. External effects: tool executes configured build/test commands, but explicitly warns these should be controlled by project owner. Rollback: session file atomically rewritten, but no explicit rollback mechanism. Source attribution: publisher identity unverified, but documentation and code clearly attribute to Dryxio. Deductions: insufficient dependency security evidence, unclear rollback mechanism, unverified publisher.
Evidence shows: documentation and config examples are consistent, CLI commands and config options clearly described. Dependency availability: dependencies available on PyPI, but no locked versions. Failure messages: documentation mentions error handling, but no specific failure message examples. Deductions: dependency versions not locked, failure message details insufficient.
Evidence shows: targets reverse engineers and developers, provides multiple use scenarios (single function, class batch, parity analysis). Capability boundaries: clearly states cannot prove semantic equivalence, requires Ghidra and LLM. Trigger precision: CLI commands and config options clear. Environment fit: supports multiple LLM providers and OS, but requires Ghidra and bridge. Deductions: many environment dependencies, but documentation provides installation guide.
Evidence shows: README structure clear, includes installation, quick start, CLI reference, FAQ. Install notes detailed. Naming stability: command and config item names consistent. Examples and FAQ: provides config examples and FAQ. Known limitations: documentation lists safety and limitations. License: MIT. Versioning and changelog: pyproject.toml has version, but no CHANGELOG. Maintenance responsibility: publisher unverified, but GitHub Actions shows continuous integration. Deductions: missing CHANGELOG, unclear maintenance responsibility.
Evidence shows: outputs include generated code, logs, knowledge graph, formats clear. Marginal value: automates reverse engineering workflow, saves manual effort. Cost benefit: documentation mentions cost control (bounded rounds), but no actual cost data. Deductions: cost benefit lacks quantitative data.
Evidence shows: README claims consistent with code and config examples. Cross-source: documentation mentions YouTube demo, but no other independent verification. Fact/inference separation: documentation clearly distinguishes conservative verification from formal proof. Deductions: insufficient cross-source evidence.
- Publisher identity unverified, proceed with caution.
- Dependency versions not pinned, supply chain risk.
- Configured build/test commands may execute arbitrary shell commands, must be controlled by project owner.
- Tool cannot prove semantic equivalence, only conservative verification.
What does this agent do, and when should you use it?
Auto RE Agent is an open-source tool for reconstructing C/C++ functions from compiled binaries. It consumes Ghidra evidence through ghidra-ai-bridge and runs bounded reverser/checker review loops over decompilation, references, types, control flow, and assembly context. Generated implementations are written to reports and candidate overlays rather than directly changing the original source tree. Optional validation copies the target project to a temporary location, replaces the matching candidate body there, and runs configured build, test, and runtime gates. Its CLI includes init, reverse, parity, status, and estimate commands, with support for Claude API, Claude CLI, OpenAI-compatible APIs, and Codex CLI. The checks provide conservative evidence, not a formal proof that generated source is semantically equivalent to a binary.
With re-agent reverse --address ADDR or re-agent reverse --class CLASS, the tool selects functions according to configuration and obtains available evidence from ghidra-ai-bridge, including decompile, xrefs_from, xrefs_to, struct, enum, vtable, global, strings, context, normalized pcode, and cfg. A reverser produces candidate C/C++ code, while a checker reviews it through bounded repair and investigation rounds. Each round invokes an objective structural verifier against decompile, assembly, CFG, and normalized high P-code evidence, then evaluates 11 built-in parity signals. It writes final code to reports/re-agent/code/ and candidates to overlays; when validation is enabled, it copies the project, replaces the matching body, and executes configured build_commands, test_commands, and runtime commands. Outputs also include per-round logs, re-agent-progress.json, and reports/re-agent/knowledge-graph.json.
- A reverse engineer maintaining a legacy C++ codebase who needs to reconstruct one function at a known binary address using exported Ghidra evidence.
- A team recovering methods from a large class that wants a bounded, dependency-ordered batch through re-agent reverse --class CTrain --max-functions 10.
- A project maintainer with reliable build and test commands who wants to validate a candidate implementation in a temporary copy without overwriting source files.
- An analyst reviewing existing recovered source who wants to run re-agent parity --filter REGEX or source-only checks with --skip-ghidra.
- A reverse-engineering project that needs function-level run history, model logs, and an evidence graph alongside generated implementations.
What are this agent's strengths and limitations?
- Builds an evidence bundle from Ghidra decompilation, references, types, control flow, assembly, and normalized P-code instead of relying on a decompiler snippet alone.
- Combines independent reverser and checker roles with structural verification, configured build/test gates, and parity signals in a bounded workflow.
- Uses candidate overlays and can validate in a temporary project copy, avoiding automatic replacement of the original source tree.
- Supports Claude API, Claude CLI, OpenAI-compatible APIs, and Codex CLI; the reverser and checker may use different provider or model configurations.
- The complete binary-backed workflow depends on local Ghidra, ghidra-ai-bridge, and correctly configured projects and exports.
- Validation commands are arbitrary project-owned shell commands; the tool cannot establish from their text that they validate a candidate, so they require explicit trust_configured_commands attestation.
- Structural and parity checks are not formal semantic or binary-equivalence proofs, and insufficient evidence can yield UNKNOWN.
- Cost and run time depend on selected models, evidence volume, and target complexity; review rounds, investigations, and attempts per function must be managed in configuration.
How do you install or deploy this agent?
Requires Python 3.10+, Git, Ghidra, a configured ghidra-ai-bridge, and at least one LLM setup. Install the agent and bridge:
python3 -m pip install --upgrade "auto-re-agent[ghidra-bridge]>=0.2.0"For headless Ghidra exports:
python3 -m pip install --upgrade "auto-re-agent[headless]>=0.2.0"From the target project, run:
ghidra-bridge init
ghidra-bridge export all
ghidra-bridge infoClaude API requires ANTHROPIC_API_KEY or RE_AGENT_LLM_API_KEY. OpenAI-compatible APIs require OPENAI_API_KEY or RE_AGENT_LLM_API_KEY. Claude CLI and Codex CLI require an authenticated local command.
How do you use this agent?
In the target project, start with re-agent init --profile generic-cpp and edit re-agent.yaml. At minimum, configure llm, backend.cli_path, source_root, and validation. One supported example uses llm.provider: codex, llm.model: gpt-5.4, backend.type: ghidra-bridge, and backend.cli_path: ghidra-bridge. Run re-agent reverse --address 0x401000 for an initial function, or re-agent reverse --class CTrain --max-functions 10 for a bounded class batch; use re-agent status to inspect progress. For strict candidate validation, configure build_commands, test_commands, require_build, require_tests, and require_verified, then set trust_configured_commands: true only after confirming the project-owned shell commands are meaningful gates.
How does this agent compare with similar options?
Compared with a traditional decompiler, Ghidra continues to perform disassembly, decompilation, and program analysis, while Auto RE Agent orchestrates evidence collection, candidate implementation, review, validation, and reporting. Compared with an interactive Ghidra AI or MCP assistant, it uses a bounded reverser/checker pipeline and persistent reports rather than an analyst-led conversational workflow.