REA: Turning AI Agents into Reverse Engineering Assistants with MCP

Reverse engineering has long been regarded as a high-barrier field. When developers face undocumented binaries, legacy systems, or third-party libraries, they often need to manually trace assembly instructions in Ghidra or IDA—a time-consuming process that easily gets lost in low-level details. REA (Reverse Engineer Anything) aims to change this: it connects local reverse engineering tools to AI Agents via the Model Context Protocol (MCP), allowing Agents to directly read binaries, JavaScript, Electron apps, and .NET assemblies, and to cite specific offset addresses as evidence during analysis.

What Is REA

At its core, REA is a set of MCP-based tools designed to bridge raw machine code and human-readable logic. It does not replace Ghidra, Hopper, or IDA Pro itself; rather, it serves as a bridge between AI Agents and these local decompilers—the Agent sends analysis requests, and REA calls the locally installed decompilation engines to do the heavy lifting.

According to the project documentation, REA runs entirely locally, so proprietary code and sensitive binaries never leave your machine. Its explanations are evidence-based and cite specific binary offsets or code blocks, meaning you get analyses that can be immediately verified in a decompiler—not LLM "guesses."

MCP (Model Context Protocol) is an open-source protocol standard proposed by Anthropic for establishing a unified interface between AI applications and external data sources and tools. You can think of it as "USB-C for the AI world": previously, every AI client that wanted to integrate a tool (such as a database, file system, or command line) needed to write its own custom adapter code; with MCP, tool providers only need to implement an MCP Server once, and any client supporting the protocol can call it directly. MCP typically communicates via JSON-RPC, usually launching a subprocess through stdio in local scenarios, or using SSE or HTTP for remote scenarios. Precisely because it standardizes "tool discovery" and "tool invocation," projects like REA can be distributed as a single npm package and plug-and-play across different clients such as Claude Desktop, Cursor, and Continue.

Decompiler differs from a disassembler: a disassembler translates machine code into assembly instructions, while a decompiler further reconstructs assembly into C-like pseudocode, greatly reducing the reading burden. Ghidra is a free suite open-sourced by the NSA, Hopper focuses on lightweight, interactive macOS experiences, and IDA Pro is the long-standing benchmark in the commercial reverse engineering space, with the Hex-Rays decompiler particularly renowned for its reconstruction quality. The three differ in pseudocode style, API, and automation capabilities, and REA abstracts away these differences, allowing the Agent to call them through a unified interface.

Installation and Configuration

REA is distributed as an npm package, and Node.js must be installed locally before installation. The basic process is as follows:

npm install -g rea-agents
npx rea-agents setup
rea-agents --help

The setup command registers the REA tools into your local AI Agent configuration, such as Claude Desktop or other MCP-compatible clients. If you need to analyze native binaries, you also need to pre-install one of Ghidra, Hopper, or IDA Pro; REA will call these engines to perform decompilation.

Typical Usage Workflow

Here is a typical scenario: you need to figure out how the authentication flow is implemented in a legacy Windows binary.

Connect the Agent

Open an MCP-compatible AI client (such as Claude Desktop), and you should see the rea toolset in the tool list. If you are using a custom MCP client, you need to manually add the rea-agents server to the configuration file.

Specify the Analysis Target

Provide the Agent with the target file path and a specific question. For example:

"I need to understand the authentication logic in this binary: /path/to/target_app.exe. Please use REA to decompile the relevant functions and explain how it validates user tokens."

Review the Evidence-Based Output

The Agent will trigger the REA tools, interact with the local decompiler, extract pseudocode, and provide a breakdown. A typical output will include specific offset addresses—for example, noting that the authentication logic is located at 0x4012A0, that the validate_token function first extracts the header from the request buffer, then performs an XOR operation using the static key at 0x405000, and finally compares the result with the hardcoded string AUTH_SUCCESS, along with a decompiled code snippet. With precise offsets, you can immediately verify the conclusions in your own decompiler.

Offset address (Offset) is a key concept for understanding binary analysis. Once an executable file is loaded into memory, every instruction and every piece of data resides at a virtual address—for example, 0x4012A0 indicates the entry point of a function. In reverse engineering, "citing an offset" means using that address as an evidence anchor: upon receiving the address, the reader can press G in a decompiler to jump to that location and personally confirm whether the instructions or data there match the AI's description.

This is precisely what distinguishes REA from "letting an LLM guess code from its training memory"—large language models, when faced with raw bytes, can easily fabricate plausible-sounding logic, whereas offset addresses pin conclusions to reproducible coordinates. It should be noted that the same function may display different addresses under different tools and different image bases (Image Base); when comparing, be careful to unify the load base or reference relative virtual addresses (RVA), otherwise you may mistakenly conclude that "the addresses don't match."

Why This Approach Is Worth Noting

REA's design reflects three clear orientations.

Evidence first. The Agent does not infer logic out of thin air but cites exact binary offsets, anchoring the LLM's output to verifiable facts. This is especially critical for security analysis and legacy system maintenance—where the cost of a wrong conclusion can be high.

Privacy first. Analysis is performed locally, with no need to upload proprietary software to the cloud, thereby lowering compliance barriers in enterprise environments.

Workflow integration. There is no need to constantly switch between an IDE and standalone reverse engineering suites; analysis results appear directly in the AI chat window, reducing context-switching costs.

Target Audience and Boundaries

REA is aimed at security researchers, developers who need to reproduce functionality, and engineers maintaining legacy code. It is important to note that it depends on external decompilers, so output quality is affected by the underlying engine and the degree of binary obfuscation; citing offset addresses improves credibility but cannot entirely eliminate the possibility of the AI misreading decompilation results. For highly obfuscated or packed samples, human judgment is still required.

Project resources include the GitHub repository (github.com/morluto/rea), the official website and guide (rea.tools), the npm package (rea-agents), and the Discord community. For teams looking to introduce AI into their reverse engineering workflow in a secure local environment, this is a starting point worth evaluating.