REA: Reverse-Engineer Anything with Your Coding Agent

0:00This week a GitHub repo shipped something unusual: it hands your coding agent a decompiler, and the entire quick start is one command. The project is REA — short for Reverse Engineer Anything — published at github.com/morluto/rea. It describes itself as one MCP server for reverse engineering, spanning binaries, applications, and runtime behavior.

What REA is

0:11The pitch is unapologetic. See a feature in an app that you want in your own product? Give the app to your agent — without its source code — and REA lets the agent investigate the feature, explain how it works, show the evidence, and build a version adapted to your stack. Reverse engineering has always been a specialist craft with a specialist toolchain: you open a stripped binary in Ghidra, IDA, or Hopper, stare at pseudo-code full of names like uVar7, and spend days building a mental model nobody else can read. MCP standardized how agents talk to external tools; REA is what happens when you point that standard at the disassembler shelf.

Setup with consent

1:05The setup step is where you decide whether to trust it, and it's designed accordingly. Running npx rea-agents setup asks which supported agents should use REA, shows you the exact paths and exact changes before applying anything, and backs up your existing configuration first. Agents that already have a REA registration are selected by default; newly detected agents show up in the list but are not auto-selected — detection is not consent. 1:38For each agent you pick, setup adds MCP access plus REA's guided workflow instructions — so the agent gets a method, not just tools. The supported list is a dozen agents (Claude Code, Claude Desktop, Codex, Cursor, Gemini CLI, Windsurf, Devon, OpenCode, Antigravity, GitHub Copilot CLI, and VS Code among them); anything else gets a manual MCP configuration path. Requirements: Node 22.19+/24.11+/26+, macOS 12+, Ubuntu 24.04+, Fedora 41+, or Arch — with docs in five languages.

Two difficulty regimes

3:06The conceptual core of the tool is that "reverse engineer an app" hides two completely different problems.

An Electron app is a web app wearing a trench coat. It ships your JavaScript, HTML, and CSS — usually bundled and minified, usually packed into an ASAR archive, which is essentially a concatenated blob with a header index, not encryption.

3:42Nothing was ever compiled to machine code — the logic is still source text, just renamed into alphabet soup by a minifier. So static analysis works: parse it, walk the module graph, rebuild call relationships, and never run a line. That's why analyze-javascript-application needs no engine and no execution. 4:34Native binaries are the other regime: a compiled Mach-O or ELF binary has no variable names, no function names, no types, no comments. To get anything readable back you need a real decompiler — one that lifts machine instructions into an intermediate representation, reconstructs control flow, infers types, and emits C-like pseudo-code. REA doesn't reimplement that; it rides an existing Hopper or Ghidra installation (setup can optionally install Hopper with its own separate consent step). The honest capability surface: JavaScript/Electron/websites are the frictionless path, .NET assemblies (with their IL's extra structure) are a middle case, and native binaries work only because a real decompiler is already on your machine. Analysis runs locally throughout — your target binary is never uploaded.

The evidence contract

2:28The part you can try with zero configuration: point it at an extracted JavaScript/Electron app tree or an ASAR archive and run npx -y rea-agents@latest analyze-javascript-application /absolute/path/to/app --json. No MCP setup, no Hopper, no Ghidra — and critically, without executing the application. What comes back is four things: evidence, a recovered graph, limitations, and unknowns. Not a verdict, not a confident paragraph of vibes — a structured answer plus an explicit statement of what it couldn't determine.

rea doctor: scoped readiness

4:56The most interesting design decision is quietly in the diagnostics. Run rea doctor with no options and you get an audit of the entire integration — every agent registration, the installed skill, every optional analysis engine. But the repo is upfront that it can report healthy: false while your current task works fine: a missing Ghidra install is a real finding for the audit and completely irrelevant if you're analyzing an Electron app. So instead of one global green light, REA gives scoped readiness — rea doctor provider ghidra --json, rea doctor client codex --json, rea doctor skill --json each narrow to one scope. When scope.mode is set to explicit, only the scoped checks determine healthy and the exit status; everything else drops to informational checks you don't need to fix for this task. 6:29The same restraint shows in engine selection: if more than one installed engine supports a native target, REA refuses to pick, reports capability unavailable, and gives the reason ambiguous — you choose, because two decompilers can produce meaningfully different pseudo-code for the same function. Refusing to guess is slightly annoying for four seconds and correct forever.

What isn't there yet

6:57Signal Coders' reality check is worth preserving in full. Confirmed today: the MCP server, the 12-agent registration flow with consent and config backups, the static JavaScript/Electron path (no engine, no execution), the native path through Hopper/Ghidra/IDA, the evidence-and-limitations output, the scoped doctor model, and five-language docs — plus a status page, an investigation model, a tool catalog, a roadmap, guides, showcases, and a community. 7:49Not published: accuracy benchmarks. There are no numbers on how often a recovered graph is correct, no comparison against a human analyst, no measured success rate on obfuscated or packed bundles. Obfuscation — string arrays, control-flow flattening, virtualized interpreters — is the historical hard wall in JS reverse engineering, and REA's record against it is unstated. 7:59By design, not addressed: the legal side. Whether you may analyze a given binary depends on its license agreement and your jurisdiction, and the clean-room convention — one team reads the original, a second isolated team writes new code from a written spec — gets structurally interesting when the same agent reads the binary and writes your implementation. REA ships analysis tooling and evidence trails; it doesn't ship legal advice and doesn't claim to.

8:27The takeaway is threefold. First, the cheapest real experiment of your week: take any Electron app, find its app directory or ASAR, run analyze-javascript-application --json, and get a structured map of how a shipping product is assembled — one command, no install, no engine, no execution. 8:49Second, the pattern matters more than the product: evidence / recovered graph / limitations / unknowns turns an agent's output from a confident essay into something you can audit — if you build any tool that feeds an LLM, copy that shape. 9:08Third, interoperability just got boring, and boring is the win: one MCP server, a dozen agents, same tool catalog whether you're in Claude Code, Codex, Cursor, Gemini CLI, or the rest. Nobody shipped twelve plugins — they shipped one server and a setup command that writes twelve configs after showing you every path it's about to touch. The skill ceiling hasn't moved (obfuscated bundles are still hard, stripped native code is still hard); what moved is the floor — the weeks of staring at uVar7 before you learn anything is now a prompt that comes back with citations.

Claims checked

Sources & further reading