REA: AI Agent MCP Server for Reverse Engineering

Background and Context

Reverse engineering has always been a high-barrier craft. To learn how one feature of an app works, a researcher may face native binaries, bundled JavaScript, Electron apps, .NET assemblies and live websites in a single project. Each target type has its own toolchain. The usual workflow means switching between disassemblers such as Hopper, Ghidra and IDA, noting clues by hand, and then writing the findings up as prose.

REA, short for Reverse Engineer Anything, tries to change that workflow. It is a reverse engineering MCP server built for AI agents. The project is maintained by morluto, written in TypeScript and distributed as the npm package rea-agents. It does not try to be a new decompiler. It sits on top of existing analysis engines and gives agents such as Claude Code, Codex, Cursor and Gemini CLI one consistent way to call them.

The project also ships a website, guides, a case showcase, an FAQ and MCP contract documents. The README is available in more than ten languages, and a Discord community covers questions and shared work.

Deep Analysis

How does REA let an AI agent reverse engineer an app that has no source code? REA exposes native binaries, JavaScript and Electron apps, .NET assemblies and websites through one MCP entry point. The agent calls it, and every finding returns with its supporting evidence and a statement of its limits. For native targets the server can drive an installed Hopper, Ghidra or IDA. Static JavaScript analysis needs no native engine at all. Three design choices stand out. First, the same toolset works for the agent and in the terminal. A developer can let the agent run a first pass and then check the result with the command line. Second, analysis runs locally. Third, the evidence-and-limits convention answers the main weakness of language models in this field, which is confident but unsupported explanation. A reader can follow the evidence instead of simply trusting the answer.

Setup is short. With Node.js and npm installed, you run npx rea-agents setup, choose the agents to connect, and review the changes the installer lists. The installer backs up existing configuration, and you restart the agent afterwards. The README names Claude Code, Codex, Cursor, Gemini CLI and Grok Build as supported, and other agents have separate installation notes. Installation also writes matching workflow instructions, so the agent knows in what order to use the tools. The repository topics, including agent-skills, binary-analysis and decompiler, point to this idea of shipping tools and method together. One practical detail matters on Linux. Ghidra, JADX, firmware tool launch, and static JavaScript and Electron analysis need a procps-compatible ps on the PATH, which REA uses to check process ownership. Recovery steps are in the relevant section of docs/installation.md.

Industry Impact

The typical use case is simple. You see a feature in a desktop app that you want to understand. You ask the agent to investigate it with REA. The agent inspects the app without source, explains how the feature works, cites evidence, and can then help write a matching implementation for your own project. This moves reverse engineering from a task for a few specialists toward a workflow an agent can assist.

For independent developers and small teams, this lowers the cost of competitor research, compatibility debugging and understanding legacy software. For security researchers, one MCP interface lets the strengths of different engines be combined instead of staying isolated.

The risks are real, and the source material is clear about some of them. Reverse engineering someone else's software raises licensing and legal questions, so users must check the license terms and local law themselves. Agent explanations still need human review, even with evidence attached, especially when they rest on decompiled output. Native analysis quality also depends on the state of Hopper, Ghidra or IDA. Finally, the README warns that tools like this are easy to imitate. Users should get REA only from morluto/rea, rea.tools or the npm package, because a repository with a similar name is not proof of an official download.

Outlook

Three things are worth watching. The first is coverage: whether REA extends to more target types beyond the four it supports today. The second is community knowledge. The case showcase and the agent-skills approach could grow into a reusable library of methods, if contributors keep adding tested workflows.

The third is the convention itself. REA requires every conclusion to carry evidence and stated limits. If other agent tools adopt the same habit, reviewing machine-generated analysis becomes easier across the field. If they do not, REA's approach will remain a useful but isolated example.

For now, the practical test is modest. Install it with npx rea-agents setup, point it at an app you already understand, and check whether the evidence it cites holds up. That experiment will show quickly how far you can trust it on an app you do not understand.