Letting Agents Reverse Engineer Anything: REA Turns Binary Analysis into MCP Calls
> Project: morluto/rea · 2963 stars/day · TypeScript
An Impossible Request
Imagine you see a feature in an app: hovering over a button smoothly scales the entire interface, but only the visible area—not the sidebar. You want to replicate this in your own product, but there's no source code, no documentation, and the developer doesn't answer emails.
The traditional path: hire a reverse engineer who opens the binary in Hopper or Ghidra, spends three days finding the relevant functions, another three days understanding the call chain, and finally delivers a report saying "it calls a private Core Animation API at offset 0x4a3c."
REA offers a different path. You open Claude Code and say "investigate this app's hover zoom feature." Your agent connects to REA's MCP tools, decides on its own to first statically analyze the JavaScript entry point, then dynamically inspect the native call chain, and finally cross-validate the evidence. Minutes later, you get a report with a full evidence chain and stated limitations.
2963 stars in one day. That number says one thing: moving reverse engineering out of the hands of experts and into the agent's toolbox is a demand that has been suppressed for far too long.
What Is REA
Full name: Reverse Engineer Anything. It's an MCP server that exposes reverse engineering tools as agent-callable interfaces.
It covers four layers:
| Layer | Tools | Capabilities | |------|------|----------| | Native binaries | Hopper / Ghidra / IDA | Disassembly, function identification, call graph recovery | | JavaScript / Electron | Built-in static analysis | Recover source from ASAR packages, trace module dependencies | | .NET assemblies | Built-in | Decompile IL code, extract type information | | Websites | Built-in | DOM structure analysis, network request tracing |
Key design: all analysis runs locally; no data is sent to the cloud. Results include two parts—conclusions and evidence. Every conclusion carries "how I know this" (which function, which offset, what call chain) and "what I don't know" (limitations).
Why Agents Suit Reverse Engineering
The core difficulty of reverse engineering isn't a lack of tools—Hopper and Ghidra are already powerful. The difficulty is decision fatigue.
A typical binary analysis workflow:
1. Open the file, see 100,000 functions 2. Search keywords, get 200 candidates 3. Inspect call graphs one by one, eliminate 180 4. Dynamically analyze the remaining 20 5. Cross-validate results, resolve contradictions 6. Write the report
Every step requires judgment: "Is this function worth digging into?" "Is this call chain the critical path?" "Is this string reference a clue or noise?" Human reverse engineers make these calls based on experience—and experience is essentially pattern matching, which is exactly what LLMs do best.
REA's approach isn't replacing Hopper with an agent, but letting the agent drive Hopper. The agent decides the analysis strategy (JavaScript entry first, or native call chain first), calls Hopper's API to execute specific analyses, then interprets results, adjusts strategy, and keeps digging. This is the same pattern as agents driving browsers (browser-use) or agents driving terminals (Claude Code)—the agent as the orchestration layer, specialized tools as the execution layer.
The Investigation Model: Methodology, Not Tool Stacking
REA's most interesting design isn't its tool collection but its investigation model. At installation, REA injects a set of workflow instructions (a skill) into the agent, defining a standardized reverse analysis process:
- Hypothesis-driven: propose a hypothesis first ("this feature might use a private API"), then find evidence to verify it
- Evidence chains: every conclusion must cite its source (function address, call chain, string reference)
- Limitation annotation: explicitly state "what I don't know"—which functions weren't analyzed, which paths weren't covered
- Cross-validation: multiple tools' results corroborate each other; contradictions are flagged, not ignored
- Tier 1 (JavaScript / Electron / websites): zero dependencies, works out of the box. Covers a huge share of modern desktop apps (VS Code, Slack, and Discord are all Electron) plus all websites.
- Tier 2 (native binaries): requires Hopper or Ghidra. Covers deep-analysis scenarios.
- Evidence: function addresses, call chains, string references, control flow graphs
- Limitations: which functions weren't analyzed, which paths weren't covered, which conclusions are inferred rather than confirmed
This isn't tool stacking—it's methodology injection. REA gives the agent not just "what it can do" but "how it should think."
This points to a bigger pattern: skills as carriers of methodology. Traditional tool calling is "the agent decides what to do"; skill injection is "the agent learns how to think." REA's investigation model is a concrete example—it encodes a reverse engineer's mindset into executable instructions.
MCP as a Universal Interface for Reverse Engineering
REA is an MCP server, meaning any MCP-compatible agent can use it: Claude Code, Codex, Cursor, Gemini CLI, Windsurf, Devin, OpenCode, Antigravity, GitHub Copilot CLI, VS Code.
That looks like just a compatibility list, but the implications are bigger. MCP is becoming the "universal plug" of the agent ecosystem. Each specialized domain (reverse engineering, database queries, filesystem operations, API calls) implements one MCP server, and any agent can plug and play.
An analogy: before USB, every peripheral had its own interface—serial, parallel, PS/2, SCSI. After USB, everything unified into one interface. MCP is to agents what USB is to hardware—the value of a standardized interface isn't the interface itself, but the combinatorial possibilities it unlocks.
REA proves this: one reverse engineering tool, because it adopted MCP, instantly plugged into a dozen agent ecosystems. Without MCP, the author would need to write dedicated integrations for each agent—workload heavy enough to make most cross-domain tools give up on compatibility.
Static JavaScript Analysis: A Zero-Dependency Entry Point
One design choice stands out: static JavaScript analysis requires no engine at all (no Hopper, Ghidra, or IDA).
Why? Because JavaScript/Electron app source is essentially text. ASAR packages just bundle files together without compiling to binary. REA can directly unpack, parse the AST, trace module dependencies, and recover function call graphs—all in Node.js.
This isn't a technical detail—it's a strategic choice. REA splits reverse engineering's barrier into two tiers:
Tier 1 is the classic "80% of needs met with 20% of the tooling" strategy. Most developers who want to understand how an app implements a feature don't need to disassemble native code—the JavaScript call chain is enough. REA made this most common scenario a zero-friction entry point, and lets users who need deeper analysis attach Hopper themselves.
Evidence and Limitations: The Foundation of Trust
Every REA analysis result contains two parts: Evidence and Limitations.
_CAViewSetScale, which exists in Core Animation's private headers, via the call chain -[AppWindow mouseMoved:] → -[AppWindow handleHover:] → _CAViewSetScale"—you can verify it yourself.Limitation annotation matters even more. An agent that proactively tells you "I didn't analyze this function's return value" or "this call chain is based on string matching and may have false positives" is far more credible than one pretending omniscience. Admitting ignorance is the prerequisite for trust—this holds for humans, and for agents too.
What This Means
The trend REA represents isn't just "reverse engineering automation." The deeper shift is: specialized tools are moving from "experts operating them directly" to "agents orchestrating calls."
Hopper and Ghidra won't disappear—they remain the best binary analysis engines. But the entity operating them changed. It used to be a reverse engineer working manually; now it's an agent orchestrating automatically while humans review conclusions and evidence.
This transition resembles what came before: databases didn't disappear, but the operator shifted from the DBA to agents calling SQL; browsers didn't disappear, but the operator shifted from humans to browser-use. The tools stay, the operator changes—a core pattern of the agent era.
REA brings this pattern to reverse engineering. 2963 stars show the demand always existed—there just wasn't a suitable interface for agents to step in. MCP provided the interface; REA filled in the content.
The next thing worth watching isn't how much REA itself can do, but how the software protection game changes when agents can autonomously reverse engineer. If any agent can dissect your binary, understand your implementation, and replicate your features, how much value remains in "protecting IP through closed source"? REA doesn't answer that question—but it makes the question urgent.