REA Anatomized: How a 62k-Star Repo Collapses Reverse Engineering into a Single Prompt

You spot a feature in some app and want it, but there's no source code. The traditional solution is a professional career path: install Ghidra or Hopper, learn to read assembly, trace call chains—budget weeks. The open-source project REA that went viral last week offers a different answer: just ask your coding agent "how is this feature written?"

The repo is morluto/rea on GitHub, MIT licensed, created in mid-April, and it has accumulated 62,202 stars in six months (measured via the API at the time of writing). One correction to earlier coverage: some posts claimed "over 12k stars"—that was a snapshot from weeks ago; the real figure is now five times higher. The project is so hot that the README carries a disclaimer: they have never issued and will never endorse any token—fake coins exploiting the name already exist.

What REA actually is

This matters for every judgment that follows: REA is not a decompilation engine. Decompilation has been handled for twenty years by Ghidra, Hopper, and IDA; JADX has eaten Android for a decade; pwntools has handled binaries for ten years. What REA does is put this existing arsenal uniformly within an agent's reach.

The repo's bridge directory contains seven bridges:

• A native bridge backed by Hopper/Ghidra/IDA
• An android bridge backed by JADX
• Plus bridges for pwntools, pwndbg, mitmproxy, and process behavior capture

Ask "how does offline search work here" and the agent calls tools over MCP; the tools return pseudocode, assembly, strings, symbols, and call references. Every conclusion comes with evidence and stated limitations—not "it probably works like this," but "this line of assembly, this string, this reference chain." Three entry points (MCP, CLI, agent skill) run the same workflow, READMEs exist in 15 languages, and a single npx rea-agents setup registers the service into your agent.

Coverage

The marketing doesn't overstate. Twelve target categories: native binaries (Mach-O, ELF, PE), JavaScript/Electron, .NET assemblies, APKs, firmware, web pages, packet-capture files, process behavior, even EVM bytecode and 16-bit DOS games.

Two prerequisites: deep native analysis requires one of Hopper/Ghidra/IDA installed (setup can install Hopper with your approval), and APK analysis requires you to bring JADX and a JDK.

Tools run entirely locally, and REA itself does not upload your target files—but note the precise wording. The README's FAQ states it outright: results enter the agent's context, and "your model provider has its own data policy." The tool layer doesn't go to the cloud; whether the session layer does depends on which model you connect. Blurring these two layers into a single "fully local, never touches the cloud" claim credits REA's cleanliness to the entire pipeline.

Verifiable reconstruction: three showcases

The replication capability has real backing, and the three showcases get progressively harder.

1. DX-Ball (1997): from a single sound call, trace into the volume-panning conversion function, complete incomplete pseudocode into C—the rebuilt code passed 3,205 original x86 test cases, and 63 compiled functions were byte-identical to the original. 2. TH04: recovered fixed-angle and aimed-angle calculations from 16-bit instructions of a 90s PC-98 game, then compared the rebuild byte-by-byte against historical compiler output. 3. Notion: an Electron live dissection—following the clipboard API from the renderer process through preload and IPC into the main process.

The common thread: the endpoint of replication isn't "we understood it," it's verification—tests pass, bytes align. The old principle that assertions must be closed out by execution lands at the byte level in the reverse-engineering context.

Agent-side engineering density

The official skill has iterated to version 35, and it contains rare honesty:

• Installing the skill only provides workflow instructions; it does not register MCP services or install engines
• "A skill installed from the repo's main branch may describe capabilities not yet in the published npm package"—version drift, documented in the instructions themselves
• The diagnostic tree splits "can't connect" into three causes: missing registration, expired registration, session not connected—and admits that rea doctor "cannot prove the current agent is actually connected"

One funny yet practical detail: Kimi's API caps the schema size per tool—community testing found 13.7 KB passes, 15 KB gets rejected. REA ships a compression-mode environment variable that squeezes each tool's declaration into a 13,312-byte budget. A dirty detail of the MCP ecosystem, digested by the tool layer on the agent's behalf.

Supported agents

Claude Code, Claude Desktop, Codex, Cursor, Gemini CLI, Windsurf, OpenCode, Antigravity, Devin, Copilot CLI, Qwen Code, Grok Build, Grok Bot... the skill's diagnostic checklist lists 18 clients—"around ten" in the copy was conservative.

The fine print on "copying the homework"

What REA delivers is evidence-chain-backed understanding; replication is done by the agent re-implementing and then testing—not a binary-to-binary copy. The DX-Ball rebuild reproduces the math, not the original bytecode. Feature ideas themselves aren't copyrightable; code is, and trademarks and licenses each draw their own lines. The README's disclaimer explicitly leaves licensing responsibility with the user.

The tool compresses the cost of "understanding how someone else did it" from weeks to an afternoon. How this cost curve gets used—the bill lands on the user. Sixteen months ago, the NSA open-sourced Ghidra, moving the decompiler from the armory into everyone's download folder; now agent bridging has moved it into the conversation window. The barrier to reverse engineering is sliding from "can read assembly" to "can ask good questions."