Ask a coding agent how a closed app works and it will happily explain, whether or not it actually read anything. REA (Reverse Engineer Anything) is the project trying to fix that by giving agents real analysis tools and making every answer carry evidence. It picked up 304,554 GitHub stars between April 14 and October 18, 2026, over three times Ghidra's 90,126, and the rea.tools submission on Hacker News climbed to 808 points on October 10.
I wanted to know whether the evidence holds up, so I ran REA 6.5.0 against an app whose source I could read. The short version: it mapped the app's renderer API perfectly and skipped a security-relevant setting entirely. The full write-up on DevToolLab has every command, the comparison script and the complete output.
What REA Actually Adds to Your Agent
Everything comes in a single npm package, rea-agents, under the MIT license: a command-line tool, an agent skill and an MCP server. npx rea-agents setup wires it into Claude Code, Codex, Cursor, Gemini CLI, Grok Build or any other MCP client and keeps backups of the config files it touches. Its rea mcp doctor check listed 207 tools and 6 prompts on my machine.
It does not decompile anything itself. Native binaries go through whichever of Hopper, Ghidra or IDA you have installed, Android through JADX, and Rizin or GNU objdump handle offline inspection. For Electron and JavaScript apps, .NET assemblies, Go or Rust binaries' build info and HAR captures, REA uses analyzers of its own, so no extra engine is needed.
One thing to internalize before using it on anything sensitive: the analysis is local, the conversation is not. REA's FAQ notes that your agent gets the tool results and "its model provider has its own data policy," so a cloud model sees whatever code REA extracts.
The Test Setup
The target was T3 Code, an MIT-licensed Electron app that controls coding agents like Claude Code and Codex, with 28,088 stars. Its v0.1.0 release came out October 15, 2026 from commit 81493ef, which meant every REA finding could be compared with the exact source behind the binary.
Two things broke first. REA's engines field skips Node 25 (it wants 22.19+, 24.11+ or 26+), so I switched to Node 24.22.0. Then it rejected the app archive with artifact_integrity_mismatch, because a native .node addon no longer matched its recorded hash. The error text suggests the fix itself:
npx rea analyze-javascript-application \
"/Applications/T3 Code (Beta).app/Contents/Resources/app.asar" \
--integrity-policy record-and-continue \
--source-path apps/desktop/dist-electron/main.cjs \
--source-path apps/desktop/dist-electron/preload.cjs \
--filter-output normalized_result.summary --format yaml
Those --source-path flags matter. Analyzing the entire archive took 227 seconds, covering 2,665 files and roughly 8.5 million AST nodes, before hitting REA's result limit of about 2 GB inside a dependency. Limited to the app's own two bundles, the run finished in about 35 seconds and reported 4 windows, 121 exposed bridge members, 207 renderer IPC calls and only 10 main-process handlers.
Where REA Was Exactly Right
T3 Code exposes one object to its UI, desktopBridge, through Electron's contextBridge. REA listed 121 members on it, including nested ones. I parsed the real preload.ts from the v0.1.0 tag with Babel and diffed the two lists: 121 matched, 0 missed, 0 invented. The script that does that comparison is in the original post if you want to rerun it.
Window settings checked out too. The three windows built from literal options all use contextIsolation: true, nodeIntegration: false and sandbox: true, which matches the source. The fourth, the main window, is built from an options variable passed through a wrapper, and REA labeled it dynamic rather than guessing. That is the right call, but it means the most important window still has to be read by hand.
Where It Fell Short
The IPC picture was lopsided. Of the 10 handlers REA found, 9 live inside @clerk/electron, the sign-in library bundled into the app, and only 1 of 207 renderer calls was matched to a handler. T3 Code registers its own handlers through a generic wrapper that passes the channel name as a variable, and REA counts those 132 operations as unresolved instead of inventing a mapping. Honest, but a careless agent could read the summary as "most of this bridge goes nowhere."
The bigger gap: T3 Code turns contextIsolation off for its in-app browser preview inside a will-attach-webview handler, keeping the sandbox on, so a picker script can share globalThis with the page. That code sits unminified at line 113,485 of the shipped main.cjs, and the string never appears in the 186 MB of evidence REA produced. REA understands window constructors, not preferences modified later in an event handler.
How It Compares to Other AI Reverse Engineering Tools
Most competitors connect one engine to one protocol, which keeps them small and leaves you with that engine's license.
| Tool | What it is | License | Stars (Oct 18, 2026) |
|---|---|---|---|
| REA | 207-tool MCP server over Hopper, Ghidra, IDA, JADX and Rizin | MIT | 304,554 |
| IDA Pro MCP | IDA Pro to language models via MCP | MIT, IDA itself is commercial | 12,980 |
| GhidraMCP | MCP server for Ghidra | Apache 2.0 | 11,346 |
| eleven | ACP agents patch binaries, Android apps and GPU kernels | Apache 2.0 | 666 |
| Binary Ninja MCP | Binary Ninja plugin with an MCP server | GPL 3.0 | 454 |
| radare2-mcp | radare2 over MCP stdio | MIT | 327 |
| BINNY | Standalone RE agent harness, any model | AGPL 3.0 | 141 |
REA can drive Ghidra too, so picking it does not replace Ghidra; it changes who is at the keyboard.
Things to Know Before You Install It
The model may refuse. A commenter in the Hacker News thread said even hinting at reverse engineering makes Anthropic and OpenAI models "extremely sensitive to refusals," and no tool changes that.
Setup is agent-driven: the site suggests pasting an install instruction into your agent, which someone in the same thread likened to curl | bash. It does show a plan before applying it, but trying the CLI in a scratch folder first is safer.
Licenses still apply. REA's README says you must legally obtain commercial tools like IDA Pro, Hopper and JEB, and its disclaimer says the project will not help anyone get around DRM, license checks or anti-cheat systems. The project also moves quickly: 32 npm versions since July 12, 2026, with 6.1.0 through 6.5.0 landing within six days in October, so pin a version anywhere it runs unattended.
A Safer Way to Try It
- Start on a target with known source, such as an open-source project or something you built yourself.
- Put
rea-agents@6.5.0in a throwaway directory and runrea doctorbefore registering it with your agent. - Restrict analysis to the app's own bundles with
--source-path. - Read the evidence's limitations and dynamic counts before the agent's summary.
- Search the bundle yourself for things REA does not model, like
will-attach-webview.
When the evidence points at minified code it could not resolve, the JavaScript Deobfuscator helps, and the Source Map Decoder maps bundled lines back to original files when an app ships its .map files.
Which Tool Fits Which Job
- Mixed targets across Electron, Android and native code: REA.
- You already pay for IDA Pro: IDA Pro MCP.
- Native binaries with no budget: GhidraMCP on Ghidra.
- Electron security reviews: REA for the bridge and windows, plus a manual look at event handlers.
- Code that cannot leave your network: REA with a locally hosted model.
Takeaway
REA makes decompilers something an agent can operate and attaches receipts to the answers. In this test the receipts were exact where REA had visibility and empty where it did not, so the useful habit is asking what the tool never looked at. The original DevToolLab post walks through the full run.
Top comments (0)