REA: an MCP and CLI layer that puts reverse-engineering tools behind an agent
Reverse engineer anything with agents, from app behavior down to native binaries.
At a glance
- What is it?
- REA (rea-agents) is an MIT-licensed TypeScript tool that gives coding agents a single interface for investigating software, from native binaries through Hopper or Ghidra down to managed PE triage and V8 Inspector observation. The judgement below: it is a workflow coordinator, not a decompiler, and its value depends on the provider you already have installed.
- Who is it for?
- Adopt REA if you already run an MCP-capable coding agent and have Hopper installed on macOS, or Ghidra available for the Linux native path, and you want the agent to keep the investigation history instead of you moving files between tools. Do not adopt it if you need a finished decompiler, since REA explicitly does not claim to recover original source code or clone an application, or if your target is a Windows PE beyond the experimental Ghidra P0 described in the README.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 8 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap REA fills is tool orchestration, not analysis
Reverse engineering normally makes the operator choose a tool, learn its API, move evidence between programs, and decide what to inspect next. That sentence from the README is the product definition. REA does not decompile anything itself. It installs and manages the reverse-engineering tools behind the scenes, then exposes them to a coding agent through commands, skills, structured results, and what the project calls repeatable investigation workflows. The intended user is an engineer who sees a feature in an app and wants it in their own product, without source access. The README's example prompt is to understand how search works in the Notes app, show the evidence, and build a similar feature. That framing matters: the output is a feature adapted to your stack, plus the evidence trail behind it, not a binary patch or a source dump. Anyone whose job is malware triage, exploit development, or firmware extraction will find the workflow oriented toward product imitation rather than adversarial analysis. The project is honest about this boundary in its own text: it does not claim to recover original source code or automatically clone an application.
What the agent can actually reach today
The capability list in the README is uneven, and the unevenness is the most useful thing to read carefully. Deep native analysis and function dossiers run through Hopper, or bring-your-own Ghidra on Linux. Windows x64 Ghidra support is labelled experimental and P0, scoped to approved native PE applications. Managed PE and CLI triage is described as execution-free, meaning the agent inspects without running the target. Evidence v2 records are reproducible, which implies a stable schema for findings rather than free-form agent prose. There is controlled process capture, passive observation of websites, Electron pages and Node/Electron V8 Inspector sessions, and bounded JavaScript and source-map reconstruction. A versioned domain graph connects JavaScript application layers, and the README draws a line between static inference and runtime observation inside that graph. The roadmap names APIs, protocols, mobile artifacts, firmware, richer runtime behavior, and version differences as future scope. Read that list as a maturity map: native binary work on macOS and Linux is the settled part, JavaScript and Electron observation is present, and everything mobile or firmware is a stated intention rather than a shipped capability.
Setup is a wizard with an explicit approval gate
The documented install is `npm install --global rea-agents && rea setup`, or the package-runner form `npx --yes rea-agents@latest setup`. The Node.js floor shown in the README badge is 22.19 or later. Setup opens by summarising the detected agents, then asks which capabilities to enable: agent integration (MCP registration plus the matching guided workflow) and, when needed, the Hopper provider. Nothing is preselected. Choosing agent integration opens a second, empty checklist for the specific detected agents that should receive a registration. Before writing, REA validates existing configuration, prints exact paths and external effects, and asks for final approval with No as the default. Ctrl-C or declining leaves the system unchanged. Detected clients are Claude Code, Claude Desktop, Codex, Cursor, Gemini CLI, Windsurf, and Devin. The first six are configured when detected. Devin is reported but left unchanged, and the README gives the reason: it has no documented local MCP configuration boundary. Registrations are additive, backup-first, and read back after writing, so rerunning setup is described as safe. Flags worth knowing: `rea setup --dry-run` prints the plan, `--client` repeated selects exact agents, and `--accessible` switches to sequential vertical prompts. On the `@latest` tag, the README notes that REA does not silently replace the package version npm selected, so an exact version request is the documented rollback path.
Local-only analysis and what that rules out
The design constraint the README states most plainly is that analysis runs on your supported local host and REA does not upload the app to a hosted analysis service. For a proprietary binary or an internal Electron build, that removes a whole class of review friction. It also means the ceiling on any given investigation is your machine and your provider licence. Hopper is a paid commercial disassembler on macOS; the Linux native path expects you to bring your own Ghidra. REA manages installation and routing, but it cannot supply the analysis engine. If you have neither, setup's capability checklist will ask about the Hopper provider and you will have nothing to point it at. That is the wrong-tool case worth stating directly: a team that wants a self-contained open source analysis stack with no commercial dependency should look at the Ghidra path first and confirm the Linux native workflow covers their targets before installing anything. The experimental Windows x64 Ghidra P0 is explicitly not a general Windows answer, and managed PE triage is execution-free, so it will not tell you what a sample does when it runs.
How this differs from driving Ghidra or Hopper directly
The obvious alternative is to open Hopper or Ghidra yourself, or to point an agent at their scripting APIs directly. Ghidra ships a headless analyzer and a Python and Java scripting layer; Hopper has its own scripting interface. Both give you full control of the engine and no intermediate layer to debug. The difference in approach is where the investigation state lives. With direct scripting, the agent writes a script per question, you keep the outputs somewhere, and the connection between finding one and finding two is your own notes. REA instead presents one consistent interface across providers and keeps a versioned domain graph plus Evidence v2 records, so the agent can follow code from one part of the app to another and show how it reached a conclusion. That is a real gain for multi-step investigations and a real cost in abstraction: when a provider behaves unexpectedly, you are debugging REA's bridge rather than your own script. The README's own screenshot shows REA launching its analysis bridge inside Hopper, which confirms the model. It is a coordinator sitting on top of an existing engine, and it should be evaluated as one.
Version cadence, licence and upgrade cost
The release history shows rea-agents 3.1.0 on 2026-08-09, 3.0.0 a week earlier on 2026-08-02, and 2.7.0 on 2026-07-28. A major version roughly one week after the previous major, with a minor release a week after that, is a fast-moving surface. For a tool that writes MCP registrations into six different agent clients, that cadence is the practical upgrade cost: each release can change what setup writes, and the README's promise that registrations are additive, backup-first, and read back after writing is what makes rerunning setup tolerable. The `@latest` tag pulls whatever is published under it, so pinning an exact version is the only way to freeze behaviour, and the README frames exact requests as the intended rollback mechanism. The licence is MIT, which is permissive and places few obligations on how you redistribute or modify the code. That says nothing about the licences of the providers REA drives: Hopper is commercial, and Ghidra ships under its own Apache 2.0 terms. Check those separately, and treat this paragraph as a description of what the repository states rather than legal advice.
Who should install it, and what to confirm first
The fit is narrow and specific. You run an MCP-capable coding agent from the detected list, you are on macOS with Hopper or on Linux with Ghidra, and your goal is to understand a feature well enough to rebuild it in your own stack during the same coding session. In that configuration REA removes the tool-switching step and gives the agent a persistent evidence trail, which is the part that is genuinely hard to do by hand. The misfit is equally specific. If your target is a Windows PE outside the experimental Ghidra P0 scope, if you need behavioural analysis of a sample rather than static inspection, if you have no Hopper or Ghidra, or if you want an agent to produce original source code, REA is the wrong layer and the README says so itself. Before running the wizard, run `rea setup --dry-run` and read the printed paths and external effects, then decide whether the Hopper provider prompt applies to you. The default answer to the final approval prompt is No, so the first run is safe by construction; the decision that matters is which detected clients you tick in the second checklist.
Editorial conclusion
Adopt REA if you already run an MCP-capable coding agent and have Hopper installed on macOS, or Ghidra available for the Linux native path, and you want the agent to keep the investigation history instead of you moving files between tools. Do not adopt it if you need a finished decompiler, since REA explicitly does not claim to recover original source code or clone an application, or if your target is a Windows PE beyond the experimental Ghidra P0 described in the README. Verify three things first: that your agent appears in the detected list (Claude Code, Claude Desktop, Codex, Cursor, Gemini CLI, Windsurf), that you accept the provider requirement setup will ask about, and that the Node.js 22.19+ floor matches your machine. Run `rea setup --dry-run` before letting the wizard write anything, because the default answer to its final approval prompt is No and the plan is the only place the exact config paths are printed.
Community notes