REA: Letting AI Coding Assistants Reverse Engineer Finished Applications

A New Scenario for AI Assistants: From "Writing Code" to "Reading Code"

AI coding assistants are typically used to generate code or complete functions, but an open-source project called REA (Reverse Engineer Anything) is trying to make them do the opposite: understand already-compiled finished applications. REA is an open-source server based on the MCP protocol that connects coding agents like Claude Code, Codex, Cursor, and Gemini CLI to reverse engineering tools. You simply point it at an application and ask a specific question—such as "how is the search feature implemented"—and the agent, assisted by the tools, traces the underlying code path.

The value of this approach lies in the fact that a large amount of code developers face daily isn't written by themselves, but comes from third-party libraries, legacy systems, or already-packaged and shipped products. REA lowers the barrier to reverse engineering from "being proficient with IDA" to "being able to ask an agent questions."

MCP (Model Context Protocol) is a protocol proposed and open-sourced by Anthropic to establish standardized connections between large language models (like Claude) and external tools and data sources. It uses a client-server architecture: MCP servers expose a set of tools (such as file reading, database queries, API calls), and agents act as clients calling them on demand. Compared to writing a separate plugin for each tool, MCP provides a unified interface that allows agents to dynamically discover and use capabilities. REA is precisely based on MCP, wrapping reverse engineering tools as an MCP server, so that MCP-compatible agents like Claude Code and Cursor can connect without customization.

Supported Analysis Targets and Capability Boundaries

According to the project documentation, REA currently covers five categories of analysis targets, each returning information at different levels of granularity:

• Native binaries: Outputs pseudocode, assembly, strings, symbols, and call/reference relationships. Deep analysis relies on commercial or open-source disassemblers like Hopper, Ghidra, or IDA.
• JavaScript and Electron applications: Extracts modules, imports, source maps, routes, and IPC communication.
• .NET assemblies: Reads metadata and CIL instructions; static analysis only.
• Android APK: Parses the manifest, class information, and decompiled methods; requires JADX and JDK environment.
• Websites: Observes page structure, scripts, and network requests.

Interestingly, static JavaScript and .NET analysis can run without installing additional native analysis engines. But when it comes to deep binary analysis, users need to provide their own valid licenses for IDA, Hopper, or JEB. The project documentation clearly states that REA is intended for legitimate research, interoperability, software preservation, and software that users own or are authorized to inspect—with clear compliance boundaries.

Static analysis and dynamic analysis are the two fundamental approaches in reverse engineering. Static analysis examines code or binaries without running the program, such as disassembly, decompilation, and extracting symbols and strings; dynamic analysis observes behavior by running the program, injecting debuggers, or monitoring system calls. REA currently provides only static analysis for .NET assemblies (reading metadata and CIL instructions), and while it can output pseudocode and assembly for native binaries, deep analysis requires disassemblers like Hopper, Ghidra, or IDA—tools that themselves are primarily static analysis tools. Understanding this distinction helps assess the limitations of REA's output: it excels at revealing code structure but cannot directly capture behaviors that only appear at runtime (such as dynamic loading, reflection calls, anti-debugging, etc.).

Installation and Operating Mechanism

The installation process is quite simple. In an environment with Node.js and npm installed, run:

npx rea-agents setup

After confirming the configuration changes and restarting the agent, the MCP server is registered and the accompanying workflow instructions are installed. The analysis process runs locally, but the agent's model provider still receives the results returned by the tools—this needs to be considered in privacy-sensitive scenarios.

Installation sources should be treated with caution. The project warns of counterfeit repositories; the official channels are limited to the GitHub repository morluto/rea, the rea.tools website, and the rea-agents package on npm.

Every Conclusion Comes with an Evidence Chain

REA's most noteworthy design is that it requires every finding to come with evidence and limitations, rather than just providing a "black-box answer."

The official showcase includes a case tracing the Notion clipboard API: starting from the renderer process, going through the preload script, crossing the IPC channel, and finally reaching the main process. The entire path is presented in full, and developers can question the source of conclusions at each step.

Another case is even more hardcore. In the classic game DX-Ball, REA revealed the instruction and data-reading logic behind a sound panning function, and a reconstruction project subsequently rewrote that function in C. The rewritten version was verified against the original x86 code through 3,205 test cases and fully reproduced all 63 compiled bytes of the function. This level of precision shows that REA's output can be used not only for understanding but also to support verifiable engineering reconstruction.

CIL (Common Intermediate Language) is the intermediate representation of compiled .NET assemblies, similar to Java bytecode. CIL instructions are compiled to native code by the CLR (Common Language Runtime) via JIT at runtime. REA's analysis of .NET assemblies reads their metadata (type, method, and field definitions) and CIL instruction streams to reconstruct high-level logic without executing the program. Since CIL retains considerable structural information (such as method names and exception handling blocks), .NET static analysis typically yields pseudocode closer to the source code than native binary disassembly—one reason REA lists it as supported without additional engines.

From Understanding to Reuse: Letting Agents "Do It the Same Way"

REA's README provides a typical prompt: have the agent understand how the search feature in the Notes app works, show the evidence, and build a similar feature in your own project. This allows the results of reverse analysis to flow directly into the implementation phase, forming a "read—reproduce" loop.

However, the author also reminds that the reproduced implementation still needs to be tested against expected behavior. Reverse analysis provides understanding, not a guarantee of a correct port.

Practical Advice and Risk Warnings

If you plan to try REA, a safe starting point is to choose an Electron application you are authorized to inspect and ask a narrowly scoped question, such as "which code path produces this behavior." Then validate the output quality from two dimensions: first, whether another engineer can independently reproduce the same conclusion using only the evidence REA provides; second, whether the application's actual behavior matches what the explanation predicts when you change inputs.

Keep in mind that REA is still in its early stages, and the author of the original material admits they have not personally run the project; all information in the article comes from the documentation. Its potential lies in turning reverse engineering from an expert tool into a callable capability for agents, but evidence quality, toolchain dependencies, and compliant use remain the key variables determining its practical value.

One-line Summary

REA is an open-source MCP-based server that lets AI coding assistants reverse engineer finished applications with an evidence chain.

Paragraph Summary

REA (Reverse Engineer Anything) is an MIT-licensed open-source MCP server that connects coding agents like Claude Code, Codex, and Cursor to reverse engineering toolchains, enabling them to answer specific questions about compiled applications, such as "how is the search feature implemented." It supports five categories of targets: native binaries, JavaScript/Electron, .NET, Android APK, and websites, with deep binary analysis relying on tools like IDA and Hopper. REA emphasizes that every conclusion comes with evidence and limitations; in the DX-Ball case, a rewritten function passed 3,205 test cases and reproduced all 63 compiled bytes. Analysis runs locally, but tool results are sent to the model provider, so privacy needs attention; the project is intended only for legitimate authorized use, and users should beware of counterfeit repositories.