There is a project on GitHub whose name is a straight promise: REA, short for Reverse Engineer Anything. The pitch of REA reverse engineering is easy to state and a little unsettling to sit with. You see a feature in an app you like, you do not have the source code, and you ask your AI coding agent to find out how it works. The agent investigates the actual binary or bundle, shows you the evidence behind every claim, and can then build a similar feature for your own project. How is that possible? Follow the tools.
What REA reverse engineering actually is
Here is the first thing to understand, because most commentary gets it wrong. REA is not a new decompiler. It invents no new analysis technology. As MindStudio’s write-up puts it, REA is a connector: it wires AI agents into tools that already exist, Ghidra, Hopper, IDA, and lets the agent operate them autonomously, chaining decompilation, hypothesis generation and code writing into a single automated loop. The novelty is the interface layer, not the engine.
📹 Video: Reverse Engineer Anything with AI, Here’s How (REA #1 On Github)
Video credit: lustoykov
REA itself is open source under the MIT licence, written in TypeScript, and it ships in two forms: an MCP server that your agent calls, and a command-line toolkit, rea, that runs the same workflows from your terminal. Analysis runs locally on your machine, and every result comes back with the evidence and the stated limitations behind each conclusion. That last part is the design philosophy in one sentence: the agent never gets a bare answer, it gets an answer, plus where the answer came from, plus what is still unknown.
One warning the project itself insists on. Get REA from the repository at github.com/morluto/rea, the project site at rea.tools, or the rea-agents npm package. A similar repository name or a copied README does not make a download genuine, and for a tool with this much attention, lookalikes are a real hazard.
How the MCP reverse engineering server works
REA speaks MCP, the Model Context Protocol, an open protocol in which a server exposes tools, resources and prompts that an AI application can discover and call (modelcontextprotocol.io). Your agent sends a question about a local target, REA inspects that target with the right analysis tool, and it returns findings together with their evidence. The agent then asks follow-up questions, explains the behavior, or writes and tests an implementation. The CLI uses exactly the same workflows, so a human in a terminal gets what an agent gets.
How much tooling are we talking about? According to one technical overview, the toolkit organizes its capabilities into 12 tool families containing 126 strongly typed MCP tools, covering everything from low-level disassembly to Electron IPC tracking and Android APK analysis. The repository’s own documentation points to a generated tool catalog for the exact inventory.
Evidence is the product
The thing REA is really selling is not answers, it is receipts. The CLI and Evidence guide describes Evidence records that retain artifact identity, source locations, observations, inferences and unresolved findings. And it is compressed for context windows: the same guide notes that a 334 MB Obsidian application Evidence file yields a summary view of about 10 KB. Snapshots cache successful analysis results, so when the target bytes, operation, parameters, provider and settings all match, REA reuses the exact earlier result instead of recomputing it. Snapshot files stay local and use owner-only permissions.
How to install the REA reverse engineering MCP server
Set up your agent
With Node.js and npm installed, one command does it: npx rea-agents setup. Setup supports Claude Code, Codex, Cursor, Gemini CLI, Grok Build and other agents. It proposes changes, you review and approve them, and it registers REA’s MCP server plus matching workflow instructions, keeping backups of your existing configuration. Restart your agent afterward. REA requires Node.js 22.x (22.19 or later), 24.x (24.11 or later), or 26 and newer.
Use the terminal
Prefer the terminal? To inspect an extracted JavaScript or Electron app directory, or an ASAR file, run npx -y rea-agents@latest analyze-javascript-application /absolute/path/to/app --json. The result includes modules, imports, Electron boundaries and their evidence. For regular use, install the command with npm install --global rea-agents and explore rea --help. Updates matter here because releases are frequent: run rea update for global installs (Bun global updates need Bun 1.2.17 or later), or npx rea-agents@latest setup to refresh an agent registration.
Pick a native analysis provider
Deep native analysis needs an engine under the hood. REA works with an existing Hopper, Ghidra or IDA installation, and setup can optionally install Hopper after your approval. Ghidra means a 12.1.x release paired with a 64-bit JDK 21 or newer, per the installation guide. Large binaries take time: the default provider startup deadline is 330,000 ms for Ghidra and 120,000 ms for Hopper, and you can raise them with REA_GHIDRA_STARTUP_TIMEOUT_MS and REA_HOPPER_STARTUP_TIMEOUT_MS. On Windows x64, Ghidra support is experimental and read-only, covering native x86 and x64 PE files on fixed local NTFS drives with a 64-bit JDK 21 or newer (get started guide). Static JavaScript analysis needs no native engine at all.
What you can analyze with REA
The target list is long, so let us group it the way a practitioner would.
Native binaries, Go and Rust
Point REA at a native binary through Hopper, Ghidra or IDA and you get pseudocode, assembly, strings, symbols, calls and references. Go binaries give up their embedded compiler version, modules, replacements and build settings through built-in static ELF, PE and thin Mach-O inspection, with no Go installation required. Rust binaries expose cargo-auditable crate names, versions, sources and dependency edges. For offline work, REA also accepts caller-supplied GNU objdump and Rizin (it installs neither), validates WASM artifacts with caller-supplied WABT 1.0.42, and reads EVM bytecode dispatch selectors on Linux x64.
JavaScript application analysis and Electron
This is where REA is most approachable, because the barrier is lowest: Node.js, npm, and a folder or ASAR archive. Static analysis returns modules, imports, source maps, routes, IPC and native add-on relationships. The JavaScript workflows guide lists tools such as trace_application_feature, compare_application_versions and compare_source_to_bundle, and describes deriving a complete reachable feature trace from one authenticated JavaScript Application Graph. Static inspection reads the files without running the application, which matters when you do not trust the thing you are examining.
Everything else: web, mobile, firmware, packets, processes
Websites are observed through a Chrome-family browser (page structure, scripts, network activity, requested screenshots), and saved HAR or Fiddler Everywhere SAZ captures can be replayed offline. .NET assemblies are read statically: metadata, CIL instructions, declared native dependencies, though the managed parser requires PE/CLI metadata and does not unpack .NET single-file hosts or decode IL2CPP metadata. Android APKs go through headless JADX with a full JDK, devices through caller-supplied adb, and JEB projects through a caller-started client selected with REA_JEB_MCP_URL. Flutter apps are parsed statically from the APK. Firmware extraction uses Binwalk or Unblob on Linux, recorded packets need TShark 4.x, logic signal recordings need sigrok-cli 0.7.2, and process behavior capture runs on Linux and macOS with a native PTY. Runtime capture executes or interacts with the target under your own user permissions, and each runtime guide describes its effects.
REA in practice: three showcases
Claims are cheap, so the project publishes worked case studies on its site. Three stand out.
DX-Ball: an investigation follows a sound call into its position-to-pan helper, inspects the instructions, and turns incomplete pseudocode into C. The reconstruction passes 3,205 original-x86 test cases and reproduces all 63 compiled function bytes, with the code published in a separate reconstruction repository. Notion: a trace of the Electron clipboard bridge, from the renderer’s clipboard API through preload and IPC into the main process, ending at the rich clipboard format. TH04: the original PC-98 game’s 16-bit instructions are inspected to recover the fixed and aimed bullet-ring angle calculations, and the reconstructed C++ is compared against the historical compiler output.
Notice the pattern. Each showcase ends not with a screenshot of a finding but with working, verified code. That is the evidence philosophy applied to the project’s own marketing.
The honest part: limits and criticism
Now the part the hype skips. MindStudio ran a hands-on test rebuilding the macOS Preview app: the REA-assisted agent reproduced the zoom, annotation, drawing, rotation and save functionality fairly faithfully, but a vanilla agent working from screenshots and reasoning finished faster in that informal comparison. The same piece argues the project’s sudden fame tracks a viral attention cycle more than a sudden technical leap, and notes that general coding agents can reverse engineer basic app functionality without specialized tooling. And the output, remember, is pseudocode with unknowns, not raw source code. A human, or a patient agent, still has to interpret and rebuild.
The practical costs are real too. The hoangyell.com overview lists heavy local prerequisites: Ghidra engine cold starts can take up to 330 seconds on large binaries, standard MCP client libraries time out after 60 seconds so you must raise the client request timeout to 360,000 ms or the first query fails, and Hopper requires a purchased license for full decompilation features. This is a young project moving fast, and the README itself tells you to update first when you hit a bug, because a recent release may already fix it.
So the trade-off is clear. REA gives you depth, evidence and repeatability. It costs you setup time, disk space, patience on big binaries, and in some workflows, raw speed against a clever agent with screenshots.
Licence and lawful use
REA-authored code is MIT licensed, and third-party material retains its own licences and notices, inventoried in THIRD_PARTY_NOTICES.md. The commercial tools are a separate matter: you must legally obtain and be authorized to use IDA Pro and Hex-Rays decompilers, Hopper and JEB under their own licences. REA grants no tool license, key or activation entitlement, and the project states plainly that cracked copies, stolen keys and bypassing license restrictions are not authorized.
The project’s DISCLAIMER.md frames the intended use: lawful research, education, interoperability, software preservation, and analysis of software you own or are authorized to examine. That position covers all REA versions and distribution channels. Vulnerability reports go through SECURITY.md.
People Also Ask
Which operating systems and Node.js versions does REA support?
REA supports Node.js 22.x (22.19 or later), 24.x (24.11 or later) and 26 or newer, while Node.js 23, 25 and prereleases are unsupported. Host operating system support depends on the target: Android APK analysis runs on Linux, macOS and Windows x64, process capture needs Linux or macOS, several capture workflows are Linux-only, and Windows x64 native analysis is experimental, read-only and Ghidra-based.
Does REA require Hopper, Ghidra, or IDA?
Only for deep native analysis. Static JavaScript and .NET inspection work without any native analysis engine. Setup can install Hopper after your approval, while Ghidra (12.1.x with JDK 21 or newer) and IDA use your existing installations. REA does not install or update Ghidra, IDA, objdump or Rizin for you.
Can REA analyze JavaScript and Electron applications without running them?
Yes. Static inspection reads the supplied files, an extracted application directory or an ASAR archive, without executing the app, and returns modules, imports, source maps, routes, IPC and native add-on relationships. On Linux, this analysis requires a procps-compatible ps on REA’s PATH for process ownership checks.
Does REA upload my app anywhere?
No. REA analyzes targets locally on your machine. Your agent receives the tool results, and the agent’s model provider has its own data policy for whatever the agent then sends it.
So should you use it?
If you run a coding agent and you have a legitimate question about how a piece of software behaves, REA is currently the most direct route to an evidence-backed answer, and the only one that hands you the receipts with the conclusion. The tools underneath are decades old. The loop on top of them is new. That is the whole trick, and it is a good one. Anyway. Install from the right place, read the disclaimer, and good luck.
Additional Resources
This article includes content created with AI.