REA: an MCP Server for Reverse-Engineering Binaries, Electron Apps, and Websites

Table of Contents

Why This Repo, Why Now

Checking github.com/trending today, the top repository is morluto/rea — “REA: Reverse Engineer Anything,” described by its maintainer as “one MCP for reverse engineering across binaries, applications, and runtime behavior.” The pitch: point a coding agent (Claude Code, Codex, Cursor, and others) at a native binary, an Electron app, a .NET assembly, or a live website, and have it come back with pseudocode, module structure, or network traffic — plus the evidence behind each conclusion — instead of a guess.

The project’s own README frames the use case plainly: “See a feature you like. Understand how it works, down to the binary level.” That resonates with the current wave of agentic coding tools, because it gives an agent a way to investigate software it has no source code for (a competitor’s app, a legacy binary, an undocumented API) and turn findings into a tested reimplementation. REA has also crossed 110,000 GitHub stars per its own README star-history section. As always, a trending position and a star count reflect visibility and momentum, not a verdict on quality or security — those are reviewed independently below.

What the Technology Actually Is

Per the repository’s README and documentation site, REA is distributed as the rea-agents npm package and runs as a local Node.js-based MCP (Model Context Protocol) server, with a matching CLI for the same operations from a terminal.

Documented architectural pieces:

• MCP server — registers with a coding agent (Claude Code, Codex, Cursor, Gemini CLI, Grok Build, and other supported agents) so the agent can call REA’s tools directly during a conversation.
• CLI (rea) — the same analysis operations invoked from a shell, documented in the CLI and Evidence guide.
• Static analyzers requiring no external engine — JavaScript/Electron bundle and ASAR inspection, .NET assembly/CIL inspection, Go binary metadata, Android APK/resource decoding (via caller-supplied JADX/Apktool), WASM artifact inspection (via caller-supplied WABT), and offline ELF/EVM-bytecode diagnostics.
• Native deep-analysis providers — Hopper, Ghidra, or IDA, selected per task; REA bridges to an existing installation (or, for Hopper on supported platforms, can install it after explicit approval) rather than shipping a disassembler itself.
• Runtime capture — process behavior capture via a native PTY, Android device interaction via caller-supplied adb, and website inspection via a Chrome-family browser.

At a high level, the agent (or you, via the CLI) picks a target type, REA selects or is told which provider/tool handles it, and the result comes back as structured findings — modules, imports, pseudocode, requests — each tied to the evidence it was derived from, per the MCP contracts documentation.

Purpose and Use Cases

Per the README, REA’s primary purpose is letting an agent inspect software without its source code and explain a feature “down to the binary level,” so that explanation can be turned into a tested implementation for your own project.

Documented use cases and target users:

• Reverse-engineering native software — inspecting binaries for pseudocode, assembly, strings, symbols, and references via Hopper, Ghidra, or IDA, per the native analysis guide.
• Electron/JavaScript app analysis — tracing modules, imports, source maps, routes, and IPC boundaries in a desktop or web app, as shown in REA’s own Notion clipboard-bridge case study.
• Legacy and retro-game reconstruction — recovering fixed-point math and compiled logic from old DOS or Windows binaries, as in the DX-Ball and TH04 showcases, which compare reconstructed C/C++ against the original compiled bytes.
• Mobile and managed-code inspection — decoding Android APKs/resources and .NET assemblies without running them, per the Android and managed-code guides.
• Network and web behavior review — inspecting saved HAR/mitmproxy captures or live website structure, scripts, and requested screenshots, per the network captures guide.
• Coding-agent-assisted engineering teams — anyone already using Claude Code, Codex, Cursor, or similar agents who wants those agents to be able to answer “how does this binary/app actually work?” with cited evidence instead of speculation.

Installation

Per the project’s documented Quick start and Installation and setup guide. The maintainer documents the setup wizard, run through npx, as the primary path for agent integration, plus a separate global install for the standalone CLI.

Prerequisites

• Node.js 22.x (>=22.19), 24.x (>=24.11), or 26+, plus npm. Node.js 23, 25, and prereleases are unsupported; REA never upgrades Node.js, npm, or Homebrew itself.
• An agent that supports local MCP servers (Claude Code, Codex, Cursor, Gemini CLI, Grok Build, and others listed in supported agents) — optional if you only use the CLI.
• Per-target tooling, only as needed: an existing Hopper, Ghidra, or IDA installation for native binaries; Node.js/npm for JavaScript/Electron; a Chrome-family browser for websites; a full JDK plus headless JADX for Android APKs; caller-supplied WABT, pwntools, or Apktool for their respective formats.

Recommended: register REA with your agent

npx rea-agents setup

The wizard offers detected agents in a multi-select, shows its proposed configuration changes, and asks for approval before writing anything or installing Hopper; it backs up existing configuration first. Restart your agent afterward.

Install the standalone CLI (optional)

npm install --global rea-agents
rea --help

Running npm install rea-agents without --global only places the executable in the current project’s node_modules/.bin and does not add a shell-visible rea command.

Minimal getting-started example

Inspect an extracted JavaScript/Electron app directory or ASAR archive directly from the CLI:

npx -y rea-agents@latest analyze-javascript-application /absolute/path/to/app --json

The result includes modules, imports, Electron boundary, and native add-on relationships, with the evidence behind each. From an agent, the equivalent getting-started prompt per the README is:

Understand how search works in the Notes app, show me the evidence, and build a
similar feature for my project.

Keep it updated

rea update

For npx-based agent setups, refresh registrations instead with npx rea-agents@latest setup.

Quick Verification

Based on the documented commands:

1. CLI responds — rea --help (after a global install) should print the command list without error.
2. Agent registration healthy — rea doctor --client codex --json (swap codex for your registered client ID) reports whether that specific MCP registration is correctly configured.
3. Installed workflow instructions — rea doctor --skill --json confirms the companion skill/instructions were installed alongside the MCP server.
4. One analysis engine ready — rea doctor --provider ghidra --json (or hopper, ida) reports whether a selected native-analysis engine is reachable.
5. Static analysis runs with no provider — npx -y rea-agents@latest analyze-javascript-application PATH --json against any local JS/Electron app directory should return structured results with no native engine configured at all.

Per the docs, rea doctor --json without a scope option audits every detected registration, so its overall healthy field can read false while the specific workflow you actually use is fine — use the scoped --client/--provider/--skill flags above to check just what you need.

Security Review

Verified from the repository itself (SECURITY.md and docs/installation.md):

• The project documents a private disclosure process: use Report a vulnerability in the repository’s Security tab; public issues requesting a private contact channel are explicitly discouraged. Security fixes are provided only for the latest published version.
• SECURITY.md describes an explicit security boundary, not a sandbox: REA authenticates each local provider-bridge session with a random capability token and a current-user Unix socket, with tokens transferred through private session descriptors rather than process arguments or environment variables. It states plainly that this “does not protect against malicious processes already running as the same operating-system user,” and that opening an untrusted binary delegates parsing to the selected local provider with that user’s own permissions.
• Ghidra sessions run through a packaged headless script in an isolated temporary project with private home/cache/runtime directories, bounded startup/protocol messages and CPU/heap settings, and the temporary project is deleted when the session closes — documented as limiting accidental persistence and resource use, explicitly not as making Ghidra a sandbox. REA does not open or modify user-owned Ghidra projects, and does not download, install, upgrade, or modify Ghidra or Java itself.
• On Linux, REA’s optional Hopper installer accepts release metadata only from Hopper’s HTTPS endpoint, restricts package URLs to Hopper’s public download origin, bounds the package size, and verifies the downloaded bytes against Hopper’s published checksum before installing — SECURITY.md itself notes the published SHA-1 is “a corruption check, not a modern package signature,” with HTTPS origin validation as the actual trust boundary. Dependency installation goes through apt-get, dnf, or pacman directly as root or via pkexec; the project states REA never invokes sudo.
• Setup, Hopper installation, and agent-configuration changes are explicitly approval-gated: the README and installation docs state the wizard shows its plan and requires approval before writing files or installing Hopper, and that declining or cancelling “makes no file write.”
• The project is licensed MIT for REA-authored code (LICENSE), with third-party material under its own licenses documented in THIRD_PARTY_NOTICES.md.
• The project maintains a dedicated DISCLAIMER.md scoping lawful use (research, education, interoperability, software preservation, and analysis of software you own or are authorized to examine), and is explicit that commercial tools REA can bridge to (IDA Pro / Hex-Rays, Hopper, JEB) require your own valid license — REA grants no license, key, or activation entitlement, and the project states cracked copies or bypassing license restrictions are not authorized.
• Release history shows an active cadence: 30 published rea-agents tags at the time of writing, from rea-agents-1.0.0 through rea-agents-6.4.0, visible on the repository’s tags page.
• No published GitHub Security Advisories were found against this repository at the time of writing; absence of advisories is not proof of absence of vulnerabilities.

Security considerations to weigh yourself (documented factors, not verified vulnerabilities):

• Native analysis runs the selected provider (Hopper/Ghidra/IDA) with your own OS-user permissions on whatever binary you point it at; the project’s own security boundary section states this is not sandboxed against other processes running as that same user.
• Several formats (ELF diagnostics, recorded crashes, WASM, EVM bytecode) require you to supply your own tooling (pwntools, WABT, GDB/pwndbg) — REA documents what it does with that tooling, but the tooling itself is outside REA’s security boundary.
• Opening an untrusted binary for native analysis means trusting the selected provider (Hopper/Ghidra/IDA) to parse it safely; REA does not add its own isolation layer on top of the provider.
• The optional Hopper auto-installer runs a privileged package manager (apt-get/dnf/pacman) as root or via pkexec; even with the documented checksum verification, installing software with root privileges is worth reviewing before approving, especially in CI or shared environments.

Practical recommendations:

• Pin a specific published rea-agents version rather than always running @latest, given the active release cadence (30 tags to date).
• Review the setup wizard’s proposed plan line-by-line before approving agent-configuration writes or the optional Hopper install, since the project explicitly designed that approval gate for this purpose.
• Treat native-binary analysis as running with your full user permissions: avoid analyzing untrusted or malicious-suspect binaries on a machine with access to production credentials or infrastructure.
• If you enable the optional Hopper installer on Linux, confirm you’re comfortable with root-level package-manager execution (apt-get/dnf/pacman via pkexec) before approving it.
• Test any new provider integration (Ghidra, Hopper, IDA) in an isolated environment first, particularly before wiring REA into an unattended CI job per the project’s own Hopper-in-CI guidance.

Should You Use It?

Strengths: a documented, explicit security-boundary section that distinguishes “limits accidental persistence” from “this is a sandbox” rather than overselling isolation; broad format coverage (native binaries, JavaScript/Electron, .NET, Go, Android, WASM, EVM bytecode, firmware, websites, network captures) behind one consistent MCP/CLI interface; an approval-gated setup flow for both agent configuration and the optional Hopper installer; real worked showcases (DX-Ball, Notion, TH04) with reproducible claims (e.g., “reproduces all 63 compiled function bytes”); and a fast, active release cadence (30 tags from 1.0.0 to 6.4.0).

Limitations: deep native analysis depends on Hopper, Ghidra, or IDA — commercial or separately licensed tools REA does not provide; several formats require caller-supplied external tooling (pwntools, WABT, JADX, Apktool), adding setup steps outside REA’s own install; there is no sandbox around the provider doing the actual parsing of untrusted binaries, by the project’s own documentation; and Hopper-specific workflows carry platform-specific quirks (macOS first-run license/demo prompts, Linux-only auto-install, /tmp/.X11-unix requirements for the Xvfb-based demo path) that need reading the install docs closely.

Good fit for: engineers and security researchers who already use an agent that supports local MCP servers and want it to explain an app’s or binary’s behavior with cited evidence rather than speculation; teams doing feature-parity research, interoperability work, or legacy-system archaeology on software they own or are authorized to examine; and anyone reconstructing old game or firmware logic who wants pseudocode tied back to the original instructions.

Evaluate alternatives if: you need a fully self-contained, sandboxed analysis environment with no dependency on a separately-licensed commercial disassembler; your policy prohibits installing or bridging to third-party reverse-engineering tools at all; or you need to analyze binaries you are not authorized to examine — REA’s own disclaimer scopes its intended use to lawful research, education, interoperability, preservation, and software you own or are authorized to analyze.

Primary sources used: GitHub repository · README · SECURITY.md · DISCLAIMER.md · Documentation home · Installation and setup · CLI and Evidence · MCP contracts · Repository tags · LICENSE