REA: evidence-backed reverse engineering through a CLI and MCP server

Give an agent a traceable inspection workflow

REA provides a command-line interface and MCP workflows for reverse engineering. Its documented process lets an agent inspect a target, trace relevant code and receive findings with supporting evidence for follow-up questions or implementation work.

The project covers several kinds of targets rather than treating all applications as the same format. Native inspection can return pseudocode, assembly, symbols and references. Website analysis covers page structure, scripts, network observations and requested screenshots. Saved network captures have a separate inspection workflow.

Match the target to its dependencies

The repository lists supported Node.js release ranges and additional tools required for particular targets. Native analysis can depend on Hopper, Ghidra or IDA. Android decompilation requires JADX and a full JDK, while Android device work uses a caller-supplied adb installation.

Other paths are static. The documentation describes inspection of embedded Go build information, cargo-auditable Rust metadata, .NET metadata and instructions, and package inventories. These target-specific requirements should be checked before assuming that installing one package enables every listed capability.

REA distinguishes static inspection from runtime capture. Static JavaScript and .NET workflows read supplied files without running the application. Runtime capture runs or interacts with the selected target under the user's permissions, and the individual guides describe those effects.

That distinction is relevant when deciding which artifact and environment to provide. The tool's returned evidence supports an interpretation; a decompiled function or observed request still needs to be read in its surrounding context.

Start with a narrow, inspectable question

Franklin analysis: use a target you are authorized to analyze and ask about one behavior with a known entry point. Save the artifact digest and the references behind the answer.

Compare a reported finding with the relevant code or a controlled execution before building a replacement. A useful reverse-engineering result should make it possible to retrace how the conclusion was reached, including which parts came from static files and which were actually observed at runtime.