On 2 November 2026 the morluto/rea repository sat at roughly 420k GitHub stars and 105k forks. The project, created 14 April 2026 and written in TypeScript under MIT, is an MCP server plus CLI that lets coding agents (Claude Code, Codex, Cursor, Gemini CLI and others) drive local reverse-engineering tools instead of guessing from screenshots or shell noise. It does not invent a new decompiler. It orchestrates the ones you already have—Hopper, Ghidra, IDA—plus built-in inspectors for JavaScript, Electron, .NET, websites, firmware and network captures, and it returns every finding with an evidence record and an explicit list of limitations and unknowns.
That last part is the actual engineering contribution. Most agent tool calls dump unstructured text. REA’s contract forces evidence_id, the raw supporting artifact, and a limitations field. You can export the session, compare_functions across two builds, or feed the structured result into the next agent step without losing the chain of custody. Analysis stays on the machine. Windows Ghidra uses authenticated loopback TCP and a private NTFS runtime whose DACL admits only the current user and SYSTEM; POSIX uses Unix sockets. No cloud round-trip for the disassembly itself.
What the agent actually gets
For native PE/ELF/Mach-O the path is provider-dependent. Point GHIDRA_INSTALL_DIR at a local Ghidra install, run npx rea-agents setup, and the agent receives tools that return pseudocode, assembly, symbols, strings, callers, callees and cross-references. Windows x64 Ghidra support is still marked experimental and scoped to approved native PE applications; deep function dossiers are more mature on Hopper (macOS) or Linux Ghidra. Offline triage can fall back to GNU objdump or Rizin when you do not want to spin the full decompiler.
JavaScript and Electron paths need no external engine. The inspector maps bundles, modules, imports, source maps, routes, preload boundaries, IPC channels and native add-ons by reading the files. Websites get page structure, script inventory and network observations via a Chrome-family browser. .NET assemblies, Android APKs (via JADX/Apktool), firmware and HAR/mitmproxy captures each have dedicated routes. The README is explicit that you do not recover original source; you get a reconstruction backed by evidence you can audit.
Setup is one command that registers the MCP server and installs matching skill/workflow files for the agent, backing up existing config first. The same engine is available as the rea CLI with --json for scripts and session snapshots. Version 5.x already exposed on the order of 130+ MCP tools; later builds added more while keeping the evidence contract.
Practical Windows notes
If you ship Windows tools that touch audio pipelines, capture stacks or real-time overlays, the interesting part is not the star count. It is that an agent can now ask “where does this process open the default audio endpoint and how does it handle the WASAPI shared-mode buffer” and get back disassembly plus the exact bytes that led to the conclusion, all local. You still have to verify the result—Ghidra’s decompiler is not perfect on heavily optimized MSVC output, and experimental Windows support means you should expect gaps—but the loop is no longer “manually copy addresses into a notes file.”
Tradeoffs are the usual ones for local analysis:
- Setup cost is non-zero. You need a working Ghidra (or Hopper/IDA) install and the agent must be restarted after MCP registration.
- Throughput is limited by the underlying engine. A full Ghidra project analysis on a large PE is still minutes, not milliseconds; REA does not magically parallelize the decompiler.
- Evidence volume can explode. A 2 MB binary with thousands of functions produces a session you will want to prune before stuffing it into a 128k-token context.
- The security boundary is local-user. That is correct for a developer workstation and wrong for a multi-tenant CI runner unless you isolate the runtime.
For real-time systems the same pattern applies to anything you can snapshot: a minidump of a hung audio thread, a ETW trace, or the PE of a capture helper. You feed the artifact, the agent walks the call graph with evidence, and you decide which hypothesis to test next. That is more useful than another chat window that confidently invents Win32 call sequences.
Automation angle
Once the MCP or CLI is in place the obvious next step is scripting the boring parts. A small wrapper can:
rea analyze-pe --json target.exe > session.json
# then a local model or another agent step consumes only the evidence fields
Or drive it from an agent that already has the codebase open and asks REA only for the closed-source dependency or the third-party overlay DLL. Rate limits do not exist because nothing leaves the box. The bottleneck is disk and the decompiler’s own CPU time.
This is the same class of problem that shows up when you build local STT or translation pipelines: capture latency, buffer sizing, and the exact COM/WASAPI or Media Foundation calls that decide whether you drop frames. Having an agent that can point at the binary and return “this function calls IAudioClient::Initialize with AUDCLNT_SHAREMODE_SHARED and a 10 ms period” with the disassembly attached is faster than reading the docs and hoping the vendor sample matches shipping code.
REA’s growth from a few dozen stars in early October to 420k by early November is mostly the MCP moment—agents finally have a stable way to call real tools instead of role-playing them. The useful part for people who ship is the evidence contract and the local execution model. You still own the verification step. The tool just stops making you copy-paste hex by hand.
I'm building Talkaside, a Windows app for job interviews and calls in another language.
Drafted with AI assistance from this project's code and logs.
Top comments (0)