REA is a single MCP server, published on npm as rea-agents, that gives a coding agent the tools to inspect software whose source it does not have. After npx rea-agents setup, an agent can ask Ghidra, Hopper or IDA for pseudocode, follow an Electron app's IPC bridges, pull an Android APK apart, or compare two versioned builds of the same artifact. The repository reached 164,002 stars by 13 October 2026, and the package recorded 132,518 downloads in the week ending 11 October.
It is not a cracking toolkit, and the project says so in its own disclaimer: REA provides inspection, capture and comparison tools for lawful reverse-engineering research, and the user is responsible for authorization. What it ships is the plumbing between an agent and the tools a human reverse engineer already uses.
Scope and entry points
One codebase exposes the same workflows twice: as an MCP server that an agent calls, and as a CLI (rea) for scripts and one-off commands. It is TypeScript under the MIT licence, requires Node 22.19 or newer (24.11+, or 26+), and the registry entry for rea-agents 6.4.0 lists 1,161 files and 7.78 MB unpacked, published from GitHub Actions with SLSA provenance attestations.
Setup is the product's front door. It detects the agents you have installed, prints every path it is about to write, and configures them after approval: Claude Code, Claude Desktop, Codex, Cursor, Gemini CLI, Windsurf, Devin, OpenCode, Antigravity, GitHub Copilot CLI, Command Code, VS Code, and Grok Build. It can also install Hopper if you approve it, but it will not install Ghidra or Java.
The CLI side is scriptable and explicit about outcomes. rea analyze, rea search, rea function, rea decompile, rea xrefs and rea trace take a path and a provider; output is a terminal format by default and JSON on request; exit status is 0 for a completed operation even when the result carries partial evidence or unresolved questions, 1 when the operation could not complete, and 128 plus the signal number when a signal ended the process. A separate rea doctor inspects the client registrations it finds and reports each as aligned, stale, missing or invalid, and it can diagnose one engine with --provider when a target fails to open.
Permissions and confirmation
The project's posture on authority is worth stating plainly, because a tool that parses untrusted binaries and can drive a browser is exactly where agent permissions get interesting. REA no longer has its own permission grants, scope ceilings, elicitation flow or repeated per-call approval flags; those were removed and the tool now runs with the current user's operating-system permissions. What remains is per-tool contract work: input and protocol validation, provider prerequisite checks, target identity, cancellation, and cleanup of resources the tool owns.
Setup still gates the two things that change the machine. It prints the plan and requires confirmation before writing client configuration or installing Hopper, and every detected agent's existing config is backed up first. MCP tool annotations are shipped as descriptions of effect rather than as authorization: the docs note that readOnlyHint accounts for session state, so an analysis call that appends Evidence is marked non-read-only even though the target is untouched, and destructiveHint is reserved for possible data loss rather than ordinary evidence recording. Client-side confirmation UI is left to the client.
Targets and providers
The target list is wide, and the prerequisites are not uniform. Native binaries need a real decompiler on disk: Hopper, Ghidra or IDA, with the Ghidra adapter verified against Ghidra 12.1.4 and JDK 21. Static JavaScript and Electron analysis needs nothing beyond Node and npm, and static .NET inspection needs no native engine at all. In between sit WASM (caller-supplied WABT 1.0.42), offline ELF layout and recorded Linux crashes (pwntools on Linux x64), EVM bytecode through a local hex carrier, websites over Chrome's CDP endpoint, saved HAR or mitmproxy captures, Android APKs through headless JADX, Android devices through adb, JEB projects through a JEB MCP server you start yourself, Android resources through Apktool, firmware through Binwalk or Unblob on Linux, artifact and package inventories including Apple bundle anatomy and plists, and process behaviour captured through a native PTY on Linux or macOS.
The Ghidra adapter is the deepest integration and the clearest measure of scope: thirteen inventory operations and twelve function-analysis operations, twenty-five read-only calls in total. On Linux and macOS it also performs atomic function-name and entry-comment edits with refreshed analysis, discarding the metadata on close and leaving the executable bytes unchanged.
Host support is where the fine print lives. Windows x64 support is an experimental P0 that covers those twenty-five read-only operations on local NTFS, with Job Object ownership and handle-based admission; process capture, Hopper and broad filesystem workflows are described as separate Windows projects. Importing a historical source tree returns unsupported_host on native Windows. I would choose the target type before installing anything, because the gap between "needs Node" and "needs Ghidra, the 64-bit JDK and the matching macOS native decompiler" is the difference between a five-minute setup and an afternoon.
Evidence, snapshots, and cancellation
The design choice that distinguishes REA from a wrapper script is that findings arrive as evidence records rather than prose. Each record keeps artifact identity, source locations, observations, inferences and unresolved findings, and the CLI can validate a bundle, export its canonical form, or compare two bundles (rea evidence-import, evidence-export, compare). The roadmap puts the same idea as a rule: CLI and MCP must expose equivalent behaviour and preserve observations, inferences, and unknowns.
Snapshots make repeat queries cheap. A snapshot retains successful analysis results and is reused only when target bytes, operation, parameters, provider and settings all match; mutations and cursor-dependent calls are excluded from the cache, and snapshot files are written with owner-only permissions. For an agent that asks the same question twice in one session, that is the difference between a second 60-second Ghidra import and a cached answer.
Progress reporting is unusually constrained, and the constraint is documented: updates are monotonic, rate-limited to at most one intermediate update per 100 milliseconds, and unknown totals are omitted because "REA does not fabricate percentages". Cancellation is treated as distinct from timeout, failed cleanup is reported as cleanup_incomplete with the owned resource kinds that remain, and the server never kills a process it cannot prove it owns.
The Ghidra path also publishes its deadlines, which is rare. REA allows 330,000 ms for engine startup by default, adjustable through REA_GHIDRA_STARTUP_TIMEOUT_MS; the pinned client SDK defaults to a 60,000 ms call timeout, so a client can cancel before the server gives up. The docs give a measured example rather than a promise: on a controlled Linux x64 fixture with Ghidra 12.1.4, JDK 21, two CPUs and a 512 MiB heap, the first overview took about 64 seconds.
Integrity handling fails closed. Artifact hashing mismatches stop nested expansion by default; a caller can opt into integrity_policy=record-and-continue, which quarantines the contradictory bytes with declared and observed hashes recorded, and continues with verified siblings.
The catalog itself is generated rather than hand-maintained. tools/list returns the complete canonical inventory including tools that are currently unavailable, and the docs point at a running server's binary_session as the authoritative source of identity and tool availability; a build step produces the machine-readable catalog from the exact source revision, and CI keeps it with the packaged skill.
The growth numbers
The repository was created on 14 April 2026 and spent months as a normal project: the npm package's first version, 0.2.1, appears on 12 July 2026, and the release list runs continuously from there. Then it went vertical. A third-party star tracker records 5,000 stars on 5 October, 8,100 on 6 October, 13,500 on 7 October, 21,400 on 8 October, 40,500 on 9 October, 67,100 on 10 October and 86,200 on 11 October; the GitHub API read on 13 October reports 164,002 stars, 38,613 forks, 535 watchers and 387 open issues.
The release cadence in the same window moved as fast: 5.0.0 on 7 October, 6.0.0 on 8 October, 6.1.0 and 6.2.0 on 9 October, 6.3.0 on 10 October, 6.4.0 on 11 October. Thirty-five releases exist in total, and 6.4.0 added Android device inspection over adb, split-APK acquisition, logs, screenshots and file transfer, manifest and localized-string decoding through Apktool, JEB project browsing through a caller-started JEB MCP server, and Evidence discovery that avoids loading every payload for large analyses.
The download curve matches the stars and is harder to inflate. The npm registry reports 134,114 downloads for the month ending 11 October and 132,518 for the week ending 11 October, which puts about 99% of the month's installs in its final week; 59,665 of them landed on 11 October alone, roughly thirteen times the month's daily average. Stars are free to give and installs are not, so I would read the package numbers first and treat the star count as a measure of reach rather than use.
Two details mark how far past its own project REA has travelled. The README carries a notice that the project has issued no cryptocurrency token and that tokens using the name are not affiliated with it, and the 6.4.0 notes credit outside contributors by handle for the Android and JEB work.
Reconstruction showcases and their limits
Three worked cases anchor what the tool does end to end. In DX-Ball, an agent follows a sound call into its position-to-pan helper, reads the instructions, and turns incomplete pseudocode into C; the reconstruction passes 3,205 original x86 cases and reproduces all 63 bytes of the compiled function. In TH04, a 1996 PC-98 game, the recovered bullet-ring calculation is compared against the historical compiler's output. In Notion, the clipboard bridge is traced from the renderer through preload and IPC into the main process.
None of that is a success rate. The repository publishes no accuracy benchmarks for any target class, and its own testing documentation asks for real-provider verification lanes rather than scores: host-native stripped fixtures, a native type-layout object, and separate cross-target fixtures for AArch64 ELF, PE and Mach-O. An independent review of the project reaches the same place from the outside, noting that obfuscated bundles and stripped native code remain hard and that compiled targets still need a real decompiler on disk. The legal framing is equally open: the disclaimer assigns authorization to the user, and "build a version for your project" from someone else's shipped artifact is a licensing question, not a technical one.
If the goal is to understand one shipped artifact rather than to rebuild a product, I would start with the JavaScript and .NET paths, because they need no external engine and return evidence on the first day.
The commits carry a trace of how the project itself is built. A browser-capture commit from 7 October names the agent skills that worked on it in Assisted-by: trailers, and the docs describe provider support in terms of verification lanes rather than features, with experimental Windows coverage explicitly separated from the parts that have real host fixtures.
Loading comments…