REA: give your coding agent a reverse-engineering toolkit, safely

The pitch on the REA README is one line: “See a feature you like. Understand how it works, down to the binary level.” REA (short for Reverse Engineer Anything) is a single MCP server that hands your coding agent a reverse-engineering toolkit. Point it at an app you don’t have the source for, ask how a feature works, and the agent comes back with an explanation and the evidence it’s based on.

It’s also very popular: the official repo, morluto/rea, has over 370k stars as of Oct 23. Popularity isn’t a safety review, though. A tool that lets an agent take apart binaries raises questions a linter doesn’t: what leaves your machine, what you’re allowed to analyze, and whether your copy is the real one.

What REA actually is

According to the README, REA connects your agent to tools for inspecting native binaries, JavaScript and Electron apps, .NET assemblies, and websites, and the same tools are available from your terminal. Two design points matter most:

Analysis runs locally. REA inspects the target on your machine.
Results carry evidence and limitations. Each conclusion comes with the evidence behind it and what REA couldn’t establish. The project calls these “unknowns.”

The second point is the one I care about. An agent left to guess will describe internals with full confidence whether or not it’s right. Evidence (the pseudocode, the string, the call reference) lets you check the answer. If a finding has none attached, treat it as a guess.

The README’s target table also covers Android APKs, WASM, firmware, packet captures, SQLite databases and more, each with its own requirements. REA’s code is MIT-licensed.

What you need on the machine

Node.js and npm. The README currently requires Node 22.x (≥22.23.4), 24.x (≥24.22.1), or 26.12.1+.
A native engine for deep native analysis. Pseudocode and assembly for native binaries come from an existing Hopper, Ghidra, or IDA install. Setup can optionally install Hopper, but only with your approval. Ghidra and IDA have to be installed already.
Nothing extra for static JavaScript or .NET. Static JS/Electron and .NET inspection read the files without running the app and need no native engine.
On Linux, a procps-compatible ps on REA’s PATH. Ghidra, JADX, firmware tool launches, and static JS/Electron analysis use it for process-ownership checks.

Licensing is your job. The README says you must legally obtain commercial tools like IDA Pro, Hopper, and JEB, that REA grants no license or activation, and that trials and demos stay subject to the vendor’s terms.

Setup: what the installer touches

npx rea-agents setup

You choose your agents, review the proposed config changes, and approve them. Setup then registers REA’s MCP server, installs matching workflow instructions, and backs up your existing configuration. Restart the agent afterward. The supported agents are Claude Code, Codex, Cursor, Gemini CLI, and Grok Build, plus others listed in the installation docs. Any client that supports local MCP servers can register it by hand.

The npm package is rea-agents. Its current version is 6.7.0, and its registry metadata points back to github.com/morluto/rea. npm install --global rea-agents gives you a rea command, and rea update keeps it current.

Security sidebar: impersonator copies. The README has an explicit warning: get REA only from github.com/morluto/rea, rea.tools, or the rea-agents npm package. It adds that “a similar repository name or copied README does not establish that a download is official.” A popular agent tool that edits your agent configs and launches native tooling is exactly what attackers clone. Check the org name, check the npm package name letter by letter, and run npm view rea-agents repository.url before you install anything.

Where the safety lines are

“Local” doesn’t mean private. REA analyzes targets locally, but the README is direct about the catch: your agent receives the tool results, and its model provider has its own data policy. Pseudocode, strings, and network observations all end up in the model’s context. If the target contains anything you couldn’t paste into a chat window, it shouldn’t go through a cloud model either.

Static and runtime analysis carry different risks. Static JS and .NET inspection never runs the target. Runtime capture does: it runs or interacts with the target using your user permissions. REA’s DISCLAIMER warns that these workflows can affect files, accounts, devices, and services. It also says that being authorized to inspect an artifact doesn’t necessarily mean you’re authorized to run it, intercept its traffic, or touch another party’s system.

Licenses and terms of service still apply. The project lists what it won’t help with: circumventing DRM, license checks, or anti-cheat; building game cheats; bypassing authentication or access controls; and copying proprietary code or assets. Reverse engineering can also be restricted by your jurisdiction or by the license of the software you’re analyzing. “Understand how a feature works, then build your own version” is a legitimate engineering exercise. Lifting someone else’s implementation is not.

Malware needs isolation. REA lists malware and incident analysis as a lawful use, and its disclaimer says to “use an appropriate environment for untrusted targets.” An agent that can run unknown binaries on the laptop where you’re signed into everything is a bad setup.

How I’d try it safely

Use a VM or a disposable machine, not your daily driver. Take a snapshot before setup so you can roll back the agent config changes and any provider installs.
Install only from the official sources above, and read the setup plan before you approve it.
Start with static analysis of something you own. Open-source Electron apps, your own builds, or the project’s public showcase targets are fine. The analyze-javascript-application command works on an extracted app directory or ASAR and needs no native engine.
Ask one narrow question, such as “how does this app’s search index get built?”, and grade the answer by its evidence. Can you follow each claim back to a function, string, or reference yourself?
Hold off on runtime capture until you know what each runtime guide says it will do, and never point it at systems you aren’t authorized to test.

The showcase page shows what good output looks like. Examples include tracing how Notion’s Electron app gets copied text and HTML to the system clipboard through IPC, and rebuilding a sound-pan calculation from the 1996 game DX-Ball as C. The project says that rebuild passes 3,205 original-x86 cases and matches all 63 compiled function bytes. The repo also has a screenshot of REA driving Hopper.

Takeaways

REA gives your agent evidence-backed tools for native binaries, JS/Electron, .NET, websites, and more, behind one MCP server.
Analysis is local, but tool results go to your model provider. Decide what you can afford to send.
Static analysis is the low-risk starting point. Runtime capture and native engines take more care and, for commercial tools, proper licenses.
Install only from morluto/rea, rea.tools, or rea-agents on npm. The project itself warns about copies.
Analyze only software you own or are authorized to examine, and use an isolated environment for anything untrusted.