REA: How AI Agents Reverse Engineer Software
What REA is (and isn't)
REA (Reverse Engineer Anything) is an open-source MCP server and CLI published as the npm package rea-agents, MIT-licensed, written in TypeScript. It is maintained by the developer morluto and lives at github.com/morluto/rea.
REA is not a disassembler or a decompiler. It does not ship its own analysis engine. What it does is wrap existing tools — Ghidra, IDA, Hopper, JADX, Binwalk, and others — into a standardized interface that an AI agent can call through the Model Context Protocol. The agent asks a question in natural language; REA routes the request to the right backend, runs the analysis locally, and returns structured evidence the agent can reason over.
Installation is one command: npx rea-agents setup. It registers REA as a toolset for MCP-compatible agents — Claude Code, Cursor, Codex, Gemini CLI, and GitHub Copilot CLI — by injecting workflow instructions into the agent's configuration.
The three-layer architecture
REA's codebase splits into three layers, each with a single responsibility:
| Layer | Directory | What it does |
|---|---|---|
| Domain | src/domain/ | Defines what counts as "evidence" and an "analysis target." |
| Application | src/application/ | Plans the task: "decompile this function, then trace its callers." |
| Providers | src/hopper/, src/browser/, … | The execution layer. Calls Hopper, hooks the browser, runs JADX. |
The Provider layer is swappable. If you switch from Hopper to IDA, you replace the Provider interface; the Domain and Application layers do not change. All tool invocations are declared in toolContracts.ts, which the agent reads to learn what it can call.
The request-investigate-verify loop
REA's core methodology is a request-investigate-verify cycle:
- Request: The agent issues a natural-language instruction — for example, "analyze how this Electron app's login feature is implemented."
- Investigate: REA selects the appropriate Provider (static JavaScript analysis, no native engine needed for Electron) and runs the analysis locally. The target file does not leave the machine.
- Verify: REA returns structured evidence — file offsets, assembly instructions, dependency graphs, pseudocode — with confidence labels. The agent reasons over this evidence, not over its own prior knowledge of what the code "probably" does.
The loop is conversational. An agent can start with an overview, then trace strings, follow cross-references, map the call graph, and finally extract pseudocode to reconstruct a specific function. Each step produces evidence the next step builds on.
Four evidence tiers
Every conclusion REA returns is classified into one of four tiers, and each carries an independent citation number linking back to the tool output that produced it:
| Tier | Meaning |
|---|---|
| Observed | The tool directly produced this output (a byte offset, an instruction, a string). |
| Inferred | A logical derivation from observed evidence (e.g., "this function calls that function"). |
| Speculative | A plausible but unconfirmed hypothesis. |
| Unknown | The analysis could not resolve this question. |
The agent's explanation must attach evidence citations. A conclusion without a citation is not allowed. This is the mechanism that separates REA from asking a model to "guess what this binary does."
What REA can analyze
REA routes to different Providers based on the target type:
| Target | Backend | Extra engine? |
|---|---|---|
| Native binaries (ELF, PE, Mach-O) | Ghidra, Hopper, or IDA | Yes — one of these must be installed |
| JavaScript / Electron apps | Static analysis (ASAR unpack, module graph, IPC tracing) | No |
| .NET assemblies | CIL instruction analysis | No |
| Android APKs | JADX + adb | JADX (adb for device interaction) |
| EVM bytecode | Dispatch selector + mutability inference | No |
| Firmware / WASM / SQLite | Binwalk / Unblob | Depends on target |
Read-only by design
REA enforces a strict read-only posture on the tools it drives:
- Ghidra operates on a temporary database. It does not modify a single byte of the file being analyzed.
- The IDA bridge is strictly read-only. It never saves or closes an already-connected database.
- The installer shows its plan before making changes and requires confirmation. It does not install unrelated software.
- All analysis runs locally. The target file does not leave the machine, which matters when the sample contains sensitive data.
This connects to a broader agent-safety principle: the tools an agent drives should default to the least destructive operation that still answers the question. REA's read-only constraint is the same idea applied to reverse engineering — the agent can inspect, but it cannot alter the evidence it is reasoning over. For the wider argument about keeping agents on a leash, see how to put AI agents on a leash.
Why evidence beats guessing
The alternative to REA is to hand an agent a disassembler and let it figure things out. In practice that looks like this: you give the model a filename and it guesses the function from the name; you ask it how a memory region flows and it produces a confident answer with no source. Traditional retrieval-augmented generation (RAG) fares no better against obfuscated code — it retrieves text that looks similar, not evidence about the specific bytes in front of it.
REA's answer is to make the agent's claims grounded. When REA returns a conclusion, it returns the byte offset, the assembly instruction, or the dependency edge that justifies it. The model is not asked to recall what a function "probably" does; it is asked to explain what the tool actually observed. A hallucination about a binary is not a creative-writing failure — it is a factual error with a citation that can be checked.
Three public cases illustrate the difference:
- Aegis Authenticator: REA traced an Android OTP app (~3,077 classes) to the specific method computing one-time passwords, then reconstructed a demonstration program that passed 133 test cases matching RFC 6238.
- Notion desktop: REA traced the rich-text copy path from the page API through Electron IPC to the system clipboard, identifying the HTML markup preserving block associations.
- DX-Ball (1996): REA recovered the sound-panning function from a 30-year-old binary, passing 3,205 x86 test cases and reproducing 63 compiled bytes.
In each case, the output is a reimplementation of verified behavior, not a guess about what the original code looked like.
What REA cannot do
- No full source recovery. REA returns pseudocode, assembly, and evidence — not compilable source. Official showcases are single-function reconstructions, not whole-project exports.
- No one-click decompile. Claims that REA produces "complete compilable projects" are not supported by the project's own documentation or case studies.
- No licenses for proprietary tools. If an analysis path needs IDA Pro or Hopper, you must already hold a valid license. REA is an interface, not a replacement.
- Scale. A binary with tens of thousands of functions cannot be analyzed in one pass. The agent must select targets narrowly, and function-by-function reconstruction is slow.
Bottom line
REA's mechanism is not "AI that reverse engineers" — it is an evidence pipeline that forces an agent's reasoning to be grounded in what the tools actually observed. The three-layer architecture keeps the tool layer swappable; the four-tier evidence system keeps the agent honest; the read-only constraint keeps the target safe. For software interoperability, preservation, and security research, that is the difference between a model that guesses and one that shows its work.
Related: What is an MCP server · AI agent security · Verify AI-generated code · How to put agents on a leash · DeepSeek Harness · DeepInfer · How agents learn to use tools
Next Steps
Learn how MCP servers work →Read about AI agent security →Learn how AI agents work →how do AI agents work — return to the complete AI agent architecture guide.
Was this helpful?
Your feedback stays on this page — no tracking.