Tool Pick｜REA — let an agent understand any software without its source code

🌏 中文版

Tool Info

What problem it solves

You see a feature in someone else's app or website that you want in your own product, but it isn't open source. You can see what it does, not how it's built. The usual move is to open Ghidra or IDA yourself, hunt down the relevant function, and read assembly or decompiled pseudocode line by line, guessing at the logic from experience — slow, and most developers' agent workflows have no path into this at all. You end up guessing an implementation that looks roughly right.

REA wraps native-binary analysis engines (Hopper, Ghidra, IDA) together with static JavaScript/Electron parsing, .NET CIL inspection, APK decompilation, SQLite/WASM/EVM bytecode inspection, browser network capture, and a dozen other reverse-engineering capabilities behind one set of MCP tools. An agent asks in plain language how some feature in a target app works, and REA locates the relevant code and returns evidence — pseudocode, assembly, call relationships — so the agent explains the mechanism, or writes a working, testable implementation, grounded in that evidence rather than guessed from memory.

It's a good fit for building a feature a competitor already has, studying the algorithm behind an old game or piece of software with no surviving source, debugging a legacy binary you have no source for, or inspecting the behavior of an unencrypted APK. The README's own three showcases: reconstructing the sound-pan calculation in the tile-matching game DX-Ball, tracing the clipboard bridge inside Notion's Electron desktop app, and recovering the bullet-ring calculation from a 1990s PC-98 shoot-'em-up called TH04.

Quick Start

Install

npx rea-agents setup

Pick which agents to wire up interactively (Claude Code, Codex, Cursor, Gemini CLI, Grok Build, and others are supported), review the proposed configuration changes, and approve them — existing config is backed up first. Restart the agent once it's done.

Basic usage

Once set up, just ask your agent in plain language:

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

The agent calls REA's MCP tools to locate the code path behind the Notes app's search, returns the evidence it found (the relevant functions, the call chain), explains the mechanism from that evidence, and writes the corresponding implementation for your own project.

Advanced usage

Analyze an extracted JavaScript/Electron app directory or ASAR archive directly from the CLI, no agent involved:

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

The JSON result lists modules, their imports, and the boundary between Electron's renderer and main process. For regular use, install it globally instead:

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

Native-binary analysis needs an existing Hopper, Ghidra, or IDA installation as the backend engine (setup can install Hopper for you, with approval).

Compared to existing approaches

Things to watch out for

• You own the legal line, REA won't draw it for you: the project's own DISCLAIMER.md is explicit — REA is built for lawful security research, incident analysis, CTFs, education, interoperability, software preservation, and analyzing software you own or are authorized to examine, and it explicitly will not help with circumventing DRM or license checks, building cheats, bypassing authentication you aren't authorized to test, or copying proprietary code and assets. Before "borrowing" a feature from someone else's app, make sure you're on the authorized or fair-use side of that line.
• You still need to legally own the commercial engines: deep native analysis routes through IDA Pro / Hex-Rays decompilers, Hopper, or JEB — all paid commercial tools. REA grants no license, key, or activation of its own, and cracked copies or shared keys are explicitly out of bounds.
• Analysis results can be incomplete or wrong: both the README and the disclaimer are upfront that decompilation, reconstruction, and AI-assisted analysis don't guarantee accuracy or completeness — check the underlying evidence (pseudocode, assembly) before trusting a consequential conclusion, rather than taking the agent's explanation at face value.
• Some analysis has real side effects: certain workflows actually run or interact with the target program (process capture, device operations), which can affect application state, files, or connected devices. Use an isolated environment for anything you don't trust, and review the agent's proposed plan before letting it run.

Today's takeaway

I used to think of reverse engineering as a skill you build slowly through hands-on time in Ghidra or IDA. Seeing REA made it click that it can be repackaged as an agent workflow with a unified tool interface and a traceable evidence chain — the entry barrier drops, but verifiability doesn't, because every conclusion comes with a pseudocode snippet or call path you can go check, instead of the agent just making up a plausible-sounding story.

References

• morluto/rea — GitHub repo
• REA README
• rea-agents — npm package
• REA DISCLAIMER.md — lawful-use boundaries and third-party tool licensing
• Startup Fortune — An AI agent that reverse engineers any software just hit number one on GitHub