REA: Reverse Engineer Anything With Your AI Agent, From Electron Apps to x86 Binaries

REA stands for Reverse Engineer Anything, and its pitch fits in one line from the README: "See a feature you like. Understand how it works, down to the binary level."

It is an open-source MCP server (Model Context Protocol, the standard AI coding agents use to call external tools) plus a command-line tool, published on npm as rea-agents. Once it is registered with Claude Code, Codex, Cursor or another agent, you can ask in plain language:

Understand how search works in the Notes app, show me the evidence, and build a similar feature for my project.

The agent then calls REA to inspect the app without its source code: disassembling native binaries, unpacking Electron bundles, reading .NET metadata or watching a website's network traffic. It traces the code behind the feature and returns what it found, with the evidence and the remaining unknowns attached. The agent uses that to explain the behavior or to write and test its own implementation.

Analysis runs locally on your machine. The project is MIT licensed, had 18,880 stars at the time of writing, and ships at a remarkable pace: version 6.0.0 landed on 8 October 2026, two days after 4.1.0.

If you have searched for a Ghidra MCP or an IDA MCP, you have found single-engine bridges: each exposes one disassembler's functions to an agent. They work, but every engine has its own tool names, and none of them helps once the interesting logic lives in JavaScript, a .NET assembly or a network call.

REA puts the three major native engines behind one interface. Ghidra, IDA Pro and Hopper are interchangeable providers, selected once per target, so the agent uses the same analysis tools whichever engine is underneath. REA does not reinvent everything either: its IDA support adapts the existing open-source ida-pro-mcp server rather than replacing it.

Then it goes well beyond native code. The generated tool catalog counts:

• 139 MCP tools in 12 families, from native disassembly to browser observation and session management
• 94 CLI commands that run the same workflows from a terminal, with --json output for scripting
• 6 guided prompts for common investigations
• 26 analysis providers, including Binwalk, Unblob, JADX, Wakaru, pwntools, mitmproxy and the Chrome DevTools Protocol

The point is that a real investigation rarely stays in one layer. A desktop feature might start in an Electron renderer, cross IPC into the main process and end in a native add-on. One server that can follow it the whole way is the difference.

REA needs Node.js 22.19 or newer (or 24.11+, or 26+) and npm. Everything else depends on the target:

Two distinctions matter. Static analysis of JavaScript and .NET reads the files without running the application. Runtime capture, of processes, Electron apps or browsers, does run or interact with the target using your user permissions, and each runtime guide spells out its effects.

Ghidra also handles 16-bit DOS executables, and one of the project's showcases recovers code from a 16-bit PC-98 game.

The most important design decision in REA is not a tool. It is the shape of every result.

An agent that reverse engineers by guessing is worse than useless, because its guesses sound exactly as confident as its facts. REA's evidence-producing tools return three things together: the result, an evidence_id, and the full evidence record behind it. That record is kept in a session bundle you can export and import.

This makes findings checkable and composable:

• Evidence from analyzing one function can be passed straight to compare_functions, and evidence from inspecting a file to compare_artifacts, for example to diff two builds of the same app.
• Some application tools can reference an earlier finding by its ID instead of repeating it, and the record passes the same identity and provenance checks without rerunning the analysis.
• Results state their limitations and unknowns, rather than smoothing them over.

The same honesty shows in small details. Progress updates omit totals that are not known, and the contract says plainly that "REA does not fabricate percentages." File integrity fails closed by default: if bytes contradict their declared hash, analysis stops. A request can opt into continuing, in which case the contradictory bytes are quarantined and recorded, and no later comparison may treat them as unchanged.

The CLI emits the same results as JSON. When you want to see exactly what changed between two runs or two app versions, a JSON compare tool turns a pair of outputs into a readable diff.

The project's showcases are worth reading because they show the method, not just the result. The best one reconstructs a function from DX-Ball 1.07, a 1996 Windows game, to answer one question: how does the game calculate stereo sound panning from where a brick sits on screen?

1. REA's decompiler output for the target function showed little more than a call to __ftol(). The pseudocode was incomplete.
2. So the investigation dropped to the instructions, which revealed an integer input on the stack that the pseudocode had hidden.
3. Following the caller that runs when a brick is hit showed that input to be the screen coordinate, 20 + 30 × tile_x.
4. Two read_bytes calls decoded the floating-point constants the function uses: 1.5625 and 500.0.
5. The x86 logic was rewritten in C: convert to double, multiply by 1.5625, subtract 500.0, scale, return as an integer.

Then it was verified properly. The C version matched the original across 3,205 behavior cases, every position from 0 to 640 at five pan scales, and compiled with the period-correct Visual C++ 4.0 compiler it reproduced all 63 bytes of the original function.

Two other showcases follow the same pattern. One traces Notion's clipboard bridge from the renderer, through preload and IPC, into the Electron main process. The other recovers bullet-ring angle calculations from a 16-bit PC-98 game and compares the rebuilt C++ against the historical compiler's output.

With Node.js and npm installed, one command does the setup:

npx rea-agents setup

You choose your agents, review the proposed changes, and approve them. Setup registers REA's MCP server with each agent and installs matching workflow instructions, backing up existing configuration first. Restart your agent afterward.

Setup can configure Claude Code, Claude Desktop, Codex, Cursor, Gemini CLI, Windsurf, Devin, OpenCode, Antigravity, GitHub Copilot CLI, Command Code and VS Code. Any other client that supports local MCP servers can register it manually.

You can also skip the agent entirely. To inspect an extracted Electron app or an ASAR archive:

npx -y rea-agents@latest analyze-javascript-application /absolute/path/to/app --json

For regular use, npm install --global rea-agents installs a rea command.

Keep it updated. With three releases in three days, the README is blunt that "new releases include frequent bug fixes". Run rea update for the global CLI, or rerun npx rea-agents@latest setup to refresh your agent registrations, and update before reporting a bug.

Static JavaScript and .NET analysis need no engine at all. For native binaries you pick one:

Ghidra is the free option, the open-source reverse engineering suite released by the NSA. REA accepts Ghidra 12.1.x with JDK 21 or newer. One practical gotcha is worth knowing before your first session: the first Ghidra-backed query starts the engine and waits for import and auto-analysis, and REA allows up to 330 seconds for that. The MCP client SDK REA pins defaults to a 60-second tool timeout, so a large binary can time out on the client side while Ghidra is still working. If your first query fails, raise the client's timeout rather than assuming the setup is broken.

Hopper is commercial software with a free demo mode, popular on macOS. Setup can install it for you after asking, REA starts it on demand when an operation needs it, and an uninstall leaves Hopper in place. REA never reads or automates license credentials.

IDA Pro works through the open-source ida-pro-mcp server, which you install and license yourself. REA adds a safety check: you open the original input binary, and its SHA-256 must match the hash IDA recorded, so the agent cannot silently analyze the wrong database. REA also never saves or closes your open IDA database.

Copying a feature from a native app is the headline, but much of REA's value is in more ordinary work.

Electron and web apps. Point it at an app directory or ASAR archive and it maps modules, imports, source maps, routes, IPC channels and native add-ons. For live websites, it observes page structure, scripts and network traffic through the browser.

Network captures. Feed it a HAR file and it reports requests, responses and exposed payloads, along with where in the code each request came from. Captures like these often carry bearer tokens, and a JWT decoder shows you what claims an exposed token actually grants.

Strings and symbols. Native analysis lists every string in a binary, which is often thousands of lines. A regex tester helps you build the pattern that pulls out just the URLs, keys or error messages you care about.

CTFs and security research. The topic list includes ctf for a reason: ELF layout and mitigation checks via pwntools, recorded Linux crash analysis with GDB or pwndbg, EVM bytecode selectors and firmware extraction. If you work on the defensive side of the same problems, Cloudflare's security audit skill is a natural companion.

Three things deserve attention before you point an agent at a target.

REA itself does not ask before each action. Its contract is explicit: it "does not require permission grants or per-call approval flags", and the effect annotations on its tools are hints, not authorization controls. Setup does print its plan and asks before changing configuration or installing Hopper, but during analysis the gate is your agent's own confirmation prompt. Runtime capture runs the target with your user permissions, so keep your agent's tool approvals on when you analyze anything you do not trust. On the positive side, REA never kills a process it cannot prove it owns.

Local analysis does not mean nothing leaves your machine. REA analyzes targets locally, but its results go to your agent, and the agent sends them to its model provider. Decompiled code from a proprietary binary is still proprietary code, so choose a provider whose data policy fits the target.

Reverse engineering has legal limits. The project's disclaimer says it is for lawful research, and that you are responsible for any required authorization. Software licenses often restrict reverse engineering, and the law on interoperability and security research varies by country. Analyzing your own software, open-source binaries, CTF challenges or targets you are authorized to test is the safe ground.

REA began on 14 April 2026 as betterBinaryMCP, an enhanced MCP server for the Hopper disassembler, and grew from there into a general reverse engineering platform. At the time of writing it had 18,880 stars, 1,985 forks, 1,362 commits and 18 contributors. Releases are frequent: v4.1.0 on 6 October 2026, v5.0.0 on 7 October and v6.0.0 on 8 October.

It has the signals of a maintained project rather than a demo: a CI pipeline, a security policy for reporting vulnerabilities, a generated and hashed tool catalog, a public roadmap, a documentation website with illustrated guides, a Discord community, and a README translated into Chinese, Japanese, Korean and Arabic.

Good fit if you want your coding agent to explain how a closed-source app does something, you analyze Electron or .NET apps regularly, you play CTFs, or you already use Ghidra, IDA or Hopper and want an agent to do the tedious navigation.

Poor fit if you need a hardened, sandboxed analysis environment for malware, since runtime capture uses your own user permissions, or if you cannot send decompiled code to a cloud model provider. In both cases, run it inside an isolated VM with a local model, or stick to static analysis.