REA: Reverse Engineering for Coding Agents

⏱️ Reading time: 12 min

A coding agent can already open the assembly of the Windows Calculator, find the branch that distinguishes adding 10% from multiplying by it, and explain in plain language why 200 + 10% equals 220. That is what REA does, a tool that connects Claude Code, Cursor, and other agents to the classic stack of agentic reverse engineering: decompilers, debuggers, and memory dumps.

📑 En este artículo

1. TL;DR
2. What is REA?
3. Why agentic binary analysis matters
4. How agentic reverse engineering works in REA
5. Practical Examples
6. Getting Started
7. Real-World Use Cases
8. Common Mistakes and Best Practices
9. Comparison With Alternatives
10. Going Deeper (Advanced)
11. Frequently Asked Questions
    1. What exactly does REA do for a coding agent?
    2. Is agentic reverse engineering legal?
    3. Does REA replace Ghidra or Frida?
    4. Which coding agents work with REA?
    5. Can REA be used to analyze malware?
    6. What happens if the agent gets a binary’s explanation wrong?
12. References

The project, published at rea.tools, automates work that used to require hours with a debugger: decoding branches, tracing calls, and reconstructing the rule behind a program. The interesting part is not the specific calculator trick. The same workflow works for auditing a game, firmware, or a library whose source code you don’t have.

TL;DR

• REA connects Claude Code, Cursor, and other agents to decompilers and debuggers to analyze live binaries.
• npx rea-agents@latest setup installs the connection and asks you to approve a plan before touching any files.
• The Windows Calculator reveals the real rule behind 200 + 10% = 220 by reading its x64 assembly.
• Chrome’s dinosaur game reveals its exact acceleration: it goes from speed 6 to 13 in steps of 0.001.
• Ghidra, Frida, and Binary Ninja are still necessary: REA translates their data into natural language, it doesn’t replace them.

What is REA?

REA is an open source tool that connects coding agents, like Claude Code or Cursor, to the classic pieces of agentic reverse engineering: decompilers, debuggers, and memory dumps, so the model can explain, modify, or reconstruct a program’s function without a person having to read assembly by hand.

Unlike a Ghidra plugin or a Frida script that runs automatic analysis, REA doesn’t interpret the binary on its own. It hands the agent the same data a human analyst would use (CPU instructions, decompiled code, function calls, memory values) and lets the model reason about them in natural language. The result feels more like having an assistant who reads the disassembly for you and tells you what it found, than a black box that spits out answers.

It installs into the agent you already use, it doesn’t replace any tool: it adds a layer that gives the agent eyes on compiled programs, running processes, or scripts loaded in a web page.

Why agentic binary analysis matters

For decades, understanding a program without its source code required years of practice with a disassembler. Agentic reverse engineering doesn’t erase that learning curve, but it shrinks it: someone who has never opened x64dbg can ask their agent to translate the assembly into a testable hypothesis, and focus on reviewing that hypothesis instead of building it from scratch.

The same principle applies to undocumented software: abandoned video games someone wants to preserve, drivers without a manual, closed network protocols, or malware that needs to be understood before it can be blocked. In all these cases the source code doesn’t exist or isn’t accessible, and the only way in is to examine the binary as it runs.

📌 Note: analyzing software without the owner’s authorization or outside the legal limits of your jurisdiction (interoperability exceptions, authorized security research, your own software) can have legal consequences. REA doesn’t change that rule.

There’s a broader backdrop here: coding agents already read and write files, browse the web, and run commands. Giving them access to running processes and decompilers is the next logical step in that same trend, not a separate category.

How agentic reverse engineering works in REA

REA acts as a bridge between the agent and the target program. When you ask it to inspect something, REA connects to the binary, the process in memory, or the web page (via a local debugging connection), extracts the instructions, the decompiled code, or the loaded script, and hands that material back to the agent as text the model can read and reason about.

flowchart TD
    A["Developer"] --> B["Coding agent"]
    B --> C["REA"]
    C --> D["Running binary or script"]
    D --> C
    C --> B
    B --> A

The agent doesn’t receive a magic answer: it receives the same raw inputs a human reverse engineer would use. What changes is who does the line-by-line reading.

sequenceDiagram
    participant D as Developer
    participant A as Agent
    participant R as REA
    participant P as Target program
    D->>A: why does 200 plus 10 percent equal 220
    A->>R: inspect the binary
    R->>P: read instructions and calls
    P-->>R: assembly and values
    R-->>A: decompiled code
    A-->>D: explanation of the rule

That separation of responsibilities is the key: REA handles the mechanics of connecting to the process (attaching to it, decompiling a function, reading a variable), and the agent handles interpreting that data, forming a hypothesis, and explaining it to you or turning it into new code.

Practical Examples

The example the project itself uses is the Windows Calculator: 200 + 10% equals 220, and the question is why. A human analyst would follow three steps: decode which branch of the program corresponds to the % button, trace which functions that branch calls, and reconstruct the formula from the values it sees pass through. With REA, the prompt is direct: Use REA to inspect Windows Calculator. Why does 200 + 10% give 220? The agent performs those three steps on its own and returns the rule in text.

The rule it reconstructs, in custom pseudocode to illustrate it, looks like this:

double percent_button(double accumulator, double operand) {
    double delta = accumulator * operand / 100.0;
    return accumulator + delta;
}

// percent_button(200, 10) returns 220
// because 200 * 10 / 100 = 20, and 200 + 20 = 220

The second example is more striking: the dinosaur game that runs on Chrome’s error screen when there’s no connection. The prompt used is Use REA to inspect this dinosaur game. Why does it get faster? REA reads the index.js the browser has loaded at that moment and returns the real condition driving the speed: it starts at 6, adds 0.001 for every update without a crash, and stops once it reaches 13.

let speed = 6;
const ACCELERATION = 0.001;
const MAX_SPEED = 13;

function tick() {
  if (speed < MAX_SPEED) speed += ACCELERATION;
}

for (let i = 0; i < 10000; i++) tick();
console.log(speed.toFixed(1));
// 13.0

According to the test published at rea.tools, running that same rule in a controlled environment, without obstacles or automated play, speed reaches 10.0 after 4,000 updates and 13.0 after 10,000. These are the numbers the agent extracted from the running script, not an estimate.

Getting Started

Dependencies before installing: Node.js (the official page has the installer for Windows, macOS, and Linux) and a coding agent already set up, like Claude Code or Cursor. The command is the same across all three operating systems because it runs on Node through npx; on Windows it’s enough to have Node installed via the official installer or winget, and on macOS or Linux via Homebrew, apt, or nvm.

npx rea-agents@latest setup

The CLI generates an installation plan and asks for your approval before touching any file. After approving it, you need to restart the agent so it detects the new tools. If you’d rather have the agent itself do it, the documented prompt is literally: Install REA and connect it to this coding agent using npx rea-agents@latest setup. Show me the setup plan for approval, then verify the installation.

A simple way to confirm the connection worked: after restarting the agent, ask it to list the available tools. If functions related to inspecting binaries or processes show up, the connection worked. If nothing new appears, check that the setup finished without errors before restarting again.

Real-World Use Cases

• Security research, initial triage of a malware sample or vulnerability hunting in a binary, always in an isolated environment and with authorization.
• Legacy software maintenance, understanding a file format or network protocol that never had public documentation.
• Interoperability, building a client or driver compatible with a closed system where only the binary exists.
• Video game preservation and modding, the dinosaur game case is exactly that: recovering a design rule in order to rebuild it.
• Training and CTFs, lowering the barrier to entry for someone learning RE, using the agent as a guide that explains each step.

Common Mistakes and Best Practices

• Analyzing without authorization, the basic rule doesn’t change just because an agent is involved: if it’s not yours or you don’t have permission, don’t analyze it.
• Trusting the hypothesis without verifying it, a model can hallucinate while reading assembly too. The rule REA returns is a starting point, not a proven conclusion.
• Mixing raw data with inference, what REA provides (instructions, decompiled code) is a fact; what the agent concludes from it is a hypothesis that needs to be tested against the real program.
• Ignoring anti-debugging protections or packing, an obfuscated binary confuses the human analyst and the agent alike; don’t expect a clean answer there.
• Not documenting findings, without a record of the session, next time you’ll have to rebuild the entire analysis from scratch.

Comparison With Alternatives

REA’s advantage is exploration speed: in minutes you have a hypothesis about what a function does. The limitation is the same one any language-model-assisted analysis has: the answer can sound confident and still be wrong, so it doesn’t replace a formal audit when what’s at stake is critical.

Going Deeper (Advanced)

Internally, decoding a binary goes through well-defined stages: first the disassembler translates bytes into CPU instructions (the calculator example, with CMP and JZ comparing the code of the button pressed), then the decompiler lifts those instructions into an intermediate representation and from there into C-like pseudocode, and finally someone (or something) reconstructs the control flow graph to understand which branch leads to which result.

flowchart LR
    A["Decode branches"] --> B["Trace calls"]
    B --> C["Recover the rule"]

A language model reads C-like pseudocode better than raw x64 assembly, because it resembles more closely what it saw during training. That explains why REA delivers decompiled code instead of just addresses and opcodes: it’s not a matter of aesthetics, it’s what makes the agent reason with fewer errors.

Static analysis (reading the binary at rest) and dynamic analysis (watching it while it runs) answer different questions. The calculator case is static: the logic is read without executing it. The dinosaur case is dynamic: the game’s real function is called in a controlled browser to measure how the speed changes. A complete RE workflow usually combines both, and an agent connected to REA can request either one depending on what it needs to confirm.

The protections that complicate this work the most (packing, control-flow obfuscation, debugger detection, address randomization) don’t disappear just because an agent is involved. They remain the real dividing line between an analysis that takes minutes and one that takes weeks, with or without AI involved.

💡 Tip: if the agent gives you a rule that sounds too simple, ask it to test it against a second case with different numbers before accepting it.

Your next step: install REA with npx rea-agents@latest setup in a test project and ask your agent to explain the simplest function of a binary you already know, so you can compare its hypothesis against the real code.

Frequently Asked Questions

What exactly does REA do for a coding agent?

It gives the agent access to CPU instructions, decompiled code, and function calls of a running program, so the agent can reason about that data in natural language.

Is agentic reverse engineering legal?

It depends on what you analyze and under what permission. Your own software, authorized security research, or the interoperability exceptions recognized by several jurisdictions are common cases; analyzing something you don’t have the right to analyze doesn’t change its legal status just because an agent is involved.

Does REA replace Ghidra or Frida?

No. It relies on that kind of tool (decompilers, debuggers, dynamic instrumentation) to get the data; the agent is the one that interprets and explains it.

Which coding agents work with REA?

The project is designed for agents like Claude Code or Cursor, installed via npx rea-agents@latest setup directly on top of the agent you already have set up.

Can REA be used to analyze malware?

With the same precautions as always: an isolated environment, never running the sample outside a sandbox, and never on a machine connected to real data.

What happens if the agent gets a binary’s explanation wrong?

The same thing that happens if it gets code wrong: the hypothesis needs to be verified against the real program before trusting it or building anything on top of it.

References

• REA: the project’s official site, with the installation guide and the Windows Calculator and dinosaur game examples.
• Ghidra: open source reverse engineering framework published by the NSA, used here as a reference classic decompiler.
• Frida: dynamic instrumentation toolkit for inspecting running processes.
• Reverse engineering: general historical and technical context for the field on Wikipedia.

📱 Do you like this content? Follow @programacion on Telegram for daily tech content in Spanish: quick summaries, fresh content every day.

Featured image: Foto de Pankaj Patel en Unsplash