TL;DR

REA (“Reverse Engineer Anything”, morluto/rea) is an MCP server and CLI that gives a coding agent the tools to take apart software it has no source code for: native binaries through Hopper, Ghidra or IDA, JavaScript and Electron apps, .NET assemblies, Android APKs, firmware, websites and saved network captures. The pitch in the README: “See a feature in an app that you want in your own product? Ask your agent to investigate it with REA.” Every finding comes back as an Evidence record with its source locations, confidence and stated limitations, so the agent (and you) can check what it is standing on.

Facts as of October 10, 2026:

  • 58,461 GitHub stars, 11,542 forks, MIT license, written in TypeScript. The repo was created on April 14, 2026; it was the #1 trending repository on GitHub today.
  • Latest release: rea-agents 6.3.0 (October 9, 2026). The npm package has 30 published versions since July 12 and was downloaded 19,312 times between October 2 and October 8.
  • 98 open issues. Commits are spread across three main authors (morluto 1,045, N0zoM1z0 382, kaoru0822-kitauji 344).
  • Requirements: Node.js 22.x (≥22.19), 24.x (≥24.11) or 26+. Deep native analysis needs an existing Hopper, Ghidra or IDA install; static JavaScript and .NET inspection need nothing else.
  • Works with Claude Code, Codex, Cursor, Gemini CLI, Grok Build, Windsurf, OpenCode, VS Code, Copilot CLI, Pi, Hermes and more; the setup command writes the MCP registration for you.

Our verdict: the static JavaScript path works out of the box. In our lab REA installed in under 9 seconds and analyzed a real npm package in 5.8 seconds without any native engine. It is the most complete open-source bridge between coding agents and real reverse-engineering tools right now. It is also changing faster than almost anything we have reviewed: four releases with breaking changes in two days. Pin a version, and treat the agent’s conclusions as leads to verify, which is exactly what REA’s Evidence format is built for.

What problem REA solves

Ask Claude Code or Codex to “figure out how this app does X” and, without help, it improvises: it runs strings, greps a minified bundle, maybe tries to drive Ghidra’s headless analyzer and gets lost. REA replaces the improvisation with a fixed toolkit and a fixed output format.

On Hacker News, Thomas Ptacek put the case for it plainly: “Everybody has their own set of skills and specific scripts and tools to do this stuff. You might use Ghidra as the kernel of those workflows, but you still want something more than just Claude freestyling, at least for now.” REA is one packaged version of that “something more”. The intended loop, per the README: you ask your agent about an app (“Understand how search works in the Notes app, show me the evidence, and build a similar feature for my project”), the agent calls REA over MCP, REA returns findings with evidence, and the agent explains the behavior or writes an implementation.

What REA can inspect

The README’s support table is the best summary of its scope:

TargetWhat REA returnsWhat you need
Native binariesPseudocode, assembly, strings, symbols, calls, referencesHopper, Ghidra or IDA
JavaScript / ElectronModules, imports, source maps, routes, IPC, native add-on linksNode.js and npm only
.NET assembliesMetadata, CIL instructions, native dependencies, build comparisonsNothing (static only)
Android APKsManifest, classes, decompiled methods, referencesHeadless JADX and a full JDK
FirmwareRegions, extraction results, hand-off to native analysisBinwalk / Unblob on Linux
WebsitesPage structure, scripts, network observations, screenshotsA Chrome-family browser
Process behaviorTerminal output, exit, filesystem effects, run comparisonsLinux or macOS with a PTY

The installation guide says the 5.0.0 release exposed 133 MCP tools, and open roadmap issues (#1065, #723) aim to make that surface cheaper to use.

The Evidence model

The design choice that sets REA apart from a pile of Ghidra scripts is that every result is an Evidence record: an ID, the subject (with a SHA-256 digest of what was analyzed), the provider, the operation and its parameters, the raw and normalized result, a confidence and authority field, the environment, limitations, source locations and links to other evidence. Our test below shows the actual field list.

Snapshots cache results keyed by the target’s bytes and query, so a repeated query does not restart Ghidra. Evidence bundles can be exported and compared across app versions.

The showcases

The project reports that in its DX-Ball case study an agent rebuilt a sound-panning helper in C that “passes 3,205 original-x86 cases and reproduces all 63 compiled function bytes”. Another case traces Notion’s clipboard through preload and IPC. These are the project’s own results; we did not reproduce them.

Quick start

With Node.js installed, the guided route is:

npx rea-agents setup

Setup shows the planned config changes, backs up existing files, and asks before writing anything. Restart your agent afterward. For a dry run:

rea setup --client claude_code --dry-run --json

For a plain CLI install and a first look at an Electron app or extracted JavaScript directory (no native engine needed):

npm install --global rea-agents
rea analyze-javascript-application /absolute/path/to/app --json > app-evidence.json

The full Evidence can be huge (the docs cite a 334 MB file for Obsidian), so the documented pattern is to save it and read a projection:

jq -c '{source: {kind: "inline", evidence: .}, view: {kind: "summary"}}' \
  app-evidence.json > app-view.json
rea inspect-analysis-view app-view.json

For native targets, configure a provider first, then:

rea analyze /absolute/path/to/program --provider ghidra --json
rea decompile /absolute/path/to/program 0x1000 --provider ghidra --json

rea doctor --json tells you which providers are ready.

Hands-on test (October 10, 2026)

Our lab is a CPU-only GitHub-hosted runner: a fresh node:22-bookworm container (x86_64, 2 CPUs, 8 GB RAM, no GPU) with no Ghidra, Hopper, IDA or agent login. So we tested the part of REA that needs none of those: install, version, the readiness check, and the static JavaScript analysis the README offers as its no-engine example. As a target we used a real, well-known package, Express 4.21.2 from npm. We ran six steps against commit f9ce32b47490. All six passed, in 26.1 seconds in total.

StepResultTime
npm install -g rea-agents”added 144 packages in 8s”8.6 s
rea --version6.3.0 on Node v22.23.32.1 s
rea doctor --json"healthy": false: Ghidra, IDA and the agent skill not configured2.6 s
Download Express 4.21.212 .js files unpacked0.5 s
rea analyze-javascript-applicationCompleted; 20,626,773-byte Evidence file5.8 s
rea inspect-analysis-view (summary)Coverage summary returned6.5 s

What worked. The install pulled 144 npm packages and needed nothing else. The analysis streamed 26 progress events as it went: it parsed and projected 13 source files (the 12 JavaScript files plus package.json), built the application graph and Electron boundary relationships, built and sealed a semantic graph, then hashed the result. It finished with “Application graph and Electron boundaries reconstructed” and exit status 0. The top-level fields of the saved Evidence were evidence_id, subject, provider, analysis_profile, predicate_type, operation, parameters, raw_result, normalized_result, confidence, authority, environment, limitations, locations, evidence_links. That is the provenance the README promises.

The doctor output is honest. It reported "healthy": false and said exactly why: “GHIDRA_INSTALL_DIR is not set” (with the fix: point it at an extracted Ghidra 12.1.x release), “IDA MCP registration is not configured”, and “Installed REA skill identity is missing”, with “Run rea setup” as the remedy. None of that blocks static JavaScript analysis, and the docs say so.

The summary view shows what REA does not know. For Express, application coverage was "complete", but semantic coverage was "unknown". The call-flow family was "partial", with 223 relations retained and 621 counted as unknown; the boundary family had 10 retained and 2 unknown. All the Electron counters (renderer transmissions, main-process handlers, native add-on bindings) were 0, which is correct for a plain Node library. We read that as a feature: REA says where its static picture runs out instead of filling the gap.

Two things to know before you point it at something big. First, the Evidence for 12 small JavaScript files was 20.6 MB. Agents must read projections, not the raw file, and the docs say as much. Second, there is an open bug (#1387) reporting that 6.3.0’s analyze-javascript-application --json aborts on a large bundle that 6.2.0 completes.

What this does not tell you. We never connected REA to an agent, and we ran no native analysis: no Ghidra, Hopper or IDA, no decompilation, no APK or firmware work. We can’t judge how well Claude Code or Codex actually reason with REA’s tools, or whether its native pseudocode is better than what Ghidra gives you directly. Those are the parts most people will install it for.

Community reactions

REA’s first Show HN, in July, got 3 points. The launch that stuck was an October 10 post of the website, which reached 435 points and 163 comments on Hacker News. The thread is a fair map of the debate:

  • “Why not just ask Claude to use Ghidra?” The most common question. Some said it is no better than doing it yourself (“i just tell it to use radare2”); others argued a packaged workflow saves tokens and time.
  • Smaller models benefit most. One commenter said that his local Qwen model in the Pi harness “got entirely lost” when told to decompile an executable with the Ghidra CLI, but with REA it was “chugging along” and “making some sort of progress”. That fits the design: structured tools and evidence help a weaker model more than a frontier one.
  • The install prompt drew jokes. The website suggests pasting an install instruction into your agent; one commenter called it “the next evolution of installation by curl | bash”.
  • Legal caution. A developer building a creative app said his team avoids Ghidra entirely because they don’t want decompilations to “expose us to copyright infringement”. REA’s README puts responsibility on the user: it is for “lawful reverse-engineering research”, and you must obtain any authorization you need.

Honest limitations

  1. Release churn with breaking changes. 6.0.0 shipped on October 8; 6.1.0, 6.2.0 and 6.3.0 all shipped on October 9, each with a “BREAKING CHANGES” section. The 6.2 notes say REA’s “always-bump-minor policy includes breaking changes”. Older snapshots and Evidence may be rejected. Pin the version that works for you.
  2. The real power needs a native engine. Native pseudocode depends on Hopper, Ghidra or IDA. Ghidra is free but heavy; IDA and a full Hopper license cost money. Windows Ghidra support is experimental.
  3. Large outputs. Our 12-file test produced 20.6 MB of Evidence. Use views and snapshots, or you will burn your agent’s context.
  4. Open bugs on core paths. Besides #1387, #1462 reports that JavaScript analysis blocks MCP ping and cancellation while it computes, and #1384 reports inspect_web_page rejecting every target on Chromium 150.
  5. It writes to your agent configs. Setup edits MCP registration files and installs a skill for each client you choose. It backs files up and shows the plan first; read that plan.
  6. Runtime capture runs the target. Process, browser and Electron capture run the target with your user’s permissions. Do that in a VM or sandbox such as NVIDIA OpenShell.
  7. Legal exposure is yours. License terms and copyright still apply, especially if you rebuild a feature you found.

When to use REA, and what to pick instead

Use REA if you want an agent to explain how a closed app, Electron tool or binary does something, you want every claim tied to evidence you can check, and you’ll work across several kinds of target (a desktop app’s JavaScript today, its native helper tomorrow).

Look elsewhere if:

  • You live in one disassembler and know it well. Single-tool MCP bridges such as GhidraMCP or ida-pro-mcp are smaller and do one job. Plain radare2 driven by your agent works too, as the HN thread pointed out.
  • You only need to debug a web page you control. Chrome DevTools MCP gives agents live DevTools access with far less setup.
  • You want to find vulnerabilities in your own code. A code-scanning tool such as Codex Security starts from your source, not a compiled artifact.

FAQ

Is REA free?

Yes. REA is MIT-licensed and free. Native analysis needs Hopper, Ghidra or IDA: Ghidra is free and open source, while IDA and a full Hopper license are paid. You also pay for whatever model your agent uses.

Do I need Ghidra or Hopper to use REA?

Only for native binaries. Static JavaScript/Electron and .NET inspection work without one; in our test JavaScript analysis completed in 5.8 seconds with no engine configured.

Does REA upload the app I analyze?

The README says analysis runs locally. Your agent still receives the tool results, so whatever your model provider’s data policy is applies to those results.

Which agents work with REA?

Any agent that supports local MCP servers. npx rea-agents setup configures Claude Code, Codex, Cursor, Gemini CLI, Windsurf, OpenCode, VS Code, Grok Build and others; anything else can be registered manually.

That depends on where you are, the software’s license and what you do with the result. REA’s README says it is for lawful research and that obtaining authorization is your responsibility. When in doubt, ask a lawyer.

Why is my old REA snapshot rejected after an update?

Recent releases changed the Evidence and snapshot formats (6.2 and 6.3 both list breaking changes). The migration guide asks you to keep the original files and regenerate results with the current version instead of editing old ones.

Verdict

REA is the most ambitious open-source attempt so far to give coding agents real reverse-engineering tools, and its best idea is the Evidence format: every conclusion carries its source, confidence and known gaps. The part we could check, static JavaScript analysis, ran cleanly in under 30 seconds and was candid about what it could not resolve. The parts we could not check (native decompilation and the agent loop) are what the 58K stars are really for. Try the JavaScript path on an Electron app you use, pin the version, and run anything that executes targets inside a VM.

Sources