Reverse engineer anything with REA

REA (‘Reverse Engineer Anything’) is one MCP server plus one CLI that connects your AI coding agent to real reverse-engineering tooling. Instead of guessing how a feature works from its behavior, your agent can inspect the actual binary, trace the relevant code, and come back with findings plus the evidence behind each one. Analysis runs locally on your machine — nothing is uploaded — and every result ships with its evidence and its stated limitations, which is the part that separates this from asking a chatbot to speculate.

Out of the box it handles native binaries (pseudocode, assembly, strings, symbols, call graphs), JavaScript and Electron apps (modules, imports, IPC boundaries), .NET assemblies, Go and Rust binaries, WASM, Android APKs, firmware images, SQLite databases, websites, and even recorded network captures. Static JavaScript and .NET inspection only read the supplied files — the app never runs. Runtime capture does run or interact with the target, using your user permissions, and each guide in the docs spells out what that does before you do it.

REA needs Node.js 22.x (at least 22.19), 24.x (at least 24.11), or 26+, plus npm. Check first: `node --version`. If you are on an older Node, upgrade before anything else — half the setup failures people report are just an old runtime. On Linux, a few targets (Ghidra launches, firmware tools, static JS analysis) also need a procps-compatible `ps` on REA’s PATH so it can verify process ownership; the fix is in docs/installation.md under ‘Linux owned-process prerequisite’ if you hit it.

Then, with Node and npm working, run: `npx rea-agents setup`. Pick your agents from the list — Claude Code, Codex, Cursor, Gemini CLI, Grok Build, and others are supported — review the changes it proposes to your agent configuration, and approve them. Setup registers REA’s MCP server and installs matching workflow instructions, keeping backups of your existing config. Restart your agent when it finishes. That is the whole install; there is no separate server to run.

The agent way: ask it like you would a colleague. The README’s example: ‘Understand how search works in the Notes app, show me the evidence, and build a similar feature for my project.’ Swap in your target app and the feature you care about. A sharper version for real work: name the exact behavior (‘the auto-save debounce in Obsidian’), demand the evidence chain (‘show me the function, the callers, and what you could not confirm’), and ask for a rebuild (‘now implement the same logic in my project and write a test that proves it matches’). The evidence demand matters — REA returns unknowns alongside findings, and a good investigation ends with a short list of what is still unproven.

The terminal way: you can drive the same workflows without an agent. To inspect an extracted JavaScript or Electron app directory (or an ASAR archive): `npx -y rea-agents@latest analyze-javascript-application /absolute/path/to/app --json`. The JSON result includes modules, imports, and Electron boundaries with their evidence. If you will use it regularly, install it once: `npm install --global rea-agents`, then `rea --help` to see the commands. Keep it current with `rea update` (or `npx rea-agents@latest setup` to refresh your agent registrations) — the project ships frequent bug fixes and the README says to stay updated.

For native binaries you need a provider: an existing Hopper, Ghidra, or IDA installation. Setup can optionally install Hopper for you if you approve it during setup; otherwise point REA at the tools you already have (the reverse-engineering tools guide covers provider selection, and there is an optional native MCP bridge for IDA). For large binaries, raise the provider startup deadline with `REA_GHIDRA_STARTUP_TIMEOUT_MS` or `REA_HOPPER_STARTUP_TIMEOUT_MS` instead of watching it time out and retrying.

The discipline that makes this worth doing: never accept a finding without its evidence. REA is built to return the code references, the unknowns, and the limitations with every conclusion — make your agent show them. ‘The login check happens in auth_validate’ is a claim; ‘here is auth_validate, here are its three callers, and I could not confirm the server-side half’ is a result. The project’s own showcases model this: reconstructing a sound-pan calculation from a 90s game binary and verifying it against thousands of original cases, or tracing an Electron clipboard bridge and naming exactly what was proven.

Running a stale install — REA changes fast, and old versions produce confusing failures; `rea update` first when something breaks. Trying native analysis with no provider configured and wondering why it stalls. Trusting the summary instead of reading the evidence REA attached to it. On Linux, missing the procps `ps` prerequisite and misreading the error as a broken install. And the big one: pointing runtime capture at something you do not own or understand — static inspection is safe reading, but runtime capture executes and interacts, so read the guide for your target type first and stay on software you have the right to analyze.