REA Hands-On: Letting AI Agents Drive Ghidra Reverse Engineering with Natural Language

Reverse engineering has long carried a reputation for being high-barrier: you need to grind through assembly, learn heavyweight tools like Ghidra or IDA, and spend countless hours manually tracing code. The open-source project REA (Reverse Engineer Anything) is trying to change that — it connects AI Agents with real reverse engineering tools, letting you ask questions in natural language and get back analysis conclusions backed by evidence.

This article breaks down what REA is, how MCP lets it invoke Ghidra, what targets it can analyze, how to install and configure it, and the legal and security boundaries beginners must understand before using it.

What REA Can Actually Analyze

REA is an MIT-licensed open-source project whose core purpose is to serve as a bridge between AI Agents (Claude Code, Codex, Cursor, Gemini CLI, etc.) and underlying reverse engineering tools. You don't need to memorize every menu in Ghidra — just describe your question in everyday language, and the Agent will call REA, which then runs heavyweight analysis tools locally on your machine and returns conclusions along with the evidence and limitations behind each one.

Its coverage is broader than most people expect:

Analysis Target	What REA Returns	Additional Dependencies
Native binaries	Pseudocode, assembly, strings, symbols, calls and references	Ghidra (free), Hopper, or IDA
JavaScript and Electron apps	Modules, imports, routes, inter-process IPC	Just Node.js and npm
.NET assemblies	Metadata and CIL instructions	No extra tools needed, static analysis only
Android APK	Manifest, classes, decompiled methods	JADX and a full JDK
Packet captures	Endpoints, DNS, TLS SNI, protocol breakdown	tshark and capinfos

The last row is especially valuable for learners focused on networking — the same Agent can both read binaries and summarize packet capture files. This "one entry point covering multiple analysis domains" design is the key to truly embedding AI-assisted reverse engineering into everyday work.

The key to distinguishing these analysis types lies in their different "intermediate representations." Native binaries have no source code — you can only reconstruct assembly from machine code, then have Ghidra's decompiler generate pseudo-C code, making this the hardest to analyze. .NET assemblies are completely different: they compile to CIL (Common Intermediate Language) bytecode, retaining full metadata (types, method names, signatures) — essentially "intermediate language with type information," so you can read the structure without a decompilation engine, though code loses readability after being processed by obfuscators. Android APKs are archives of DEX bytecode plus resource files, with JADX converting DEX back to approximate Java code while also parsing AndroidManifest.xml to expose permissions and components. JavaScript/Electron apps are typically distributed in minified or bundled form, so analysis focuses on reconstructing module boundaries and the IPC channels between main and renderer processes. Packet capture files (pcap) are another dimension entirely — they're not code but traffic records, with tshark decoding layer by layer by protocol, and REA distilling endpoints, DNS queries, TLS SNI, and more into readable summaries.

MCP: The Mechanism That Lets AI Actually "Use" Ghidra

The most counterintuitive part is: how can a language model that only knows how to read and write possibly operate Ghidra? The answer is MCP (Model Context Protocol), a standard protocol that lets AI Agents invoke external tools.

A standalone language model can only process text — dropping it into a chunk of assembly is essentially guessing. REA runs as a local MCP server, exposing toolsets like "decompile this function" and "list strings in the file" to the Agent. The whole flow forms a closed loop:

1. You ask the Agent a question about some program;
2. The Agent selects a REA tool and invokes it via MCP;
3. REA runs Ghidra or another engine locally on the file;
4. REA returns pseudocode, assembly, references, and whatever it cannot confirm;
5. The Agent reads the evidence, asks follow-up questions, and finally explains things in a way humans can understand.

The key point: the AI isn't fabricating program behavior out of thin air — it's reading the same evidence a human reverse engineer would read, just much faster. REA explicitly reports "what it cannot confirm," which matters more than you'd think — models can easily give confident wrong answers, and explicitly exposing the unknown both constrains the Agent and alerts the analyst.

MCP was proposed and open-sourced by Anthropic in late 2024, aiming to solve the "N×M integration" problem between AI applications and external systems: previously, each new tool integration (database, filesystem, GitHub, Ghidra) required a separate adapter layer for each model, but MCP abstracts this into a unified protocol. It borrows from LSP (Language Server Protocol) — an editor only needs to implement an LSP client once to interface with servers for any language; likewise, an Agent only needs to implement an MCP client once to call any conforming MCP server.

MCP servers typically expose three kinds of capabilities: Tools (functions the model can call, like "decompile function"), Resources (readable data, like file contents), and Prompts (preset prompt templates). Communication is based on JSON-RPC and supports both local stdio and remote HTTP/SSE transports. REA uses the local stdio server form, meaning all analysis runs on your own machine, and the Agent only decides "which tool to call and with what parameters" — this is also the technical premise behind REA's emphasis on "evidence comes from locally."

Installation and Configuration Essentials

REA requires Node.js and npm. Supported versions include Node 22 (22.19 and above), Node 24 (24.11 and above), or Node 26 and higher. Analyzing native binaries also requires one of Ghidra, Hopper, or IDA — beginners are advised to start with the free Ghidra.

Installation is just one command:

npx rea-agents setup

It will ask which Agents you use, show you the configuration it's about to modify, and back up your existing config before writing the REA MCP server. After restarting your Agent, the new tools are ready to use. If you want the rea command to stay available in your terminal, install it globally:

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

A few easily overlooked pitfalls: on Linux, both Ghidra and JavaScript analysis require a procps-compatible ps command in PATH — failures on minimal VMs are often caused by this. Second, the project README specifically warns about imposter repositories with the same name; only install from the official GitHub repo, rea.tools, or the rea-agents npm package — this itself is a software supply chain security lesson hidden inside an installation guide.

npx is npm's built-in package executor, letting you run a package's one-off commands without global installation — npx rea-agents setup temporarily downloads rea-agents and executes its setup subcommand, leaving no global executable behind afterward. This is friendly for users who use it occasionally and don't want to pollute their environment, but the downside is it checks for updates on every run, making the first run slower. If you plan to use it frequently and want a pinned version, npm install --global rea-agents installs it into global node_modules and adds the rea command to PATH, after which you can upgrade manually with rea update.

Regarding version requirements: even-numbered major versions of Node.js are the LTS (Long Term Support) line, while odd-numbered versions are short-term experimental ones. The Node 22 and 24 mentioned in this article belong to the LTS sequence, and Node 26 is a later LTS. The protocol version between MCP clients and servers evolves with the Node ecosystem, so REA sets a minimum Node version rather than pinning an exact one. If you have multiple Node versions installed, switching with nvm or fnm is safer than modifying the system PATH.

Two Usage Paths: Agent and Command Line

There are two ways to use REA. The first is through an AI Agent: once configured, describe in natural language what you want to understand, and the Agent decides on its own which REA tools to call. A typical prompt might be:

Explain how the clipboard feature in this app works, show me the evidence,
and list anything you could not confirm.

The second is using the command line directly, running the same workflow without depending on an Agent. For example, this command inspects an unpacked JavaScript or Electron app, requiring no native analysis engine at all:

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

According to the documentation, the output lists the app's modules, import relationships, and Electron boundaries, with evidence attached to each conclusion.

The Core Skill of Reverse Engineering: Recognizing Known Algorithms

Whether the analyst is human or AI, one of the most practical techniques in reverse engineering is recognizing common algorithms through "fingerprints." Compilation strips comments, and stripping erases function names, but the math itself cannot be hidden. Take the classic string hash djb2 as an example:

unsigned int djb2(const char *s) {
    unsigned int h = 5381;
    while (*s) {
        h = ((h << 5) + h) + *s++;
    }
    return h;
}

After compilation and stripping, the name "djb2" disappears, but two clues remain in the pseudocode or assembly: the initial value 5381, and the left-shift-by-5-then-add — equivalent to a fast multiply by 33. Someone familiar with these clues can name the function within seconds, and an Agent reading REA's evidence can match it the same way. The same applies to other famous constants, such as 0x67452301 at the start of MD5 and SHA-1, or 0xEDB88320 in CRC32.

Recognizing the algorithm is only half the job — the other half is proving it: run the original program and your rewritten version with identical inputs and confirm the outputs match exactly.

Constant fingerprints are reliable because compiler optimizations rarely change an algorithm's mathematical structure. In h = ((h << 5) + h) + *s++, (h << 5) + h is equivalent to h * 33, and many compilers optimize it directly into a lea (load effective address) instruction — on x86, something like lea eax, [eax + eax*4] followed by a left shift, or imul eax, eax, 33. So the key to recognizing djb2 isn't memorizing the source code, but recognizing these two instruction patterns plus the magic number 5381.

Other high-frequency fingerprints include: the initial vectors of MD5/SHA-1 such as 0x67452301, 0xEFCDAB89, and two more constants; the CRC32 polynomial 0xEDB88320 (in reversed representation); the 256-byte S-box initialization loop of RC4; and the S-box and Rcon tables of AES. Tools like findcrypt (an IDA plugin) or Ghidra scripts scan binaries for these constants to automatically flag candidate algorithms. But note that fingerprints only yield hypotheses — you still ultimately need behavioral verification with known input-output pairs, which is exactly why the article emphasizes that "recognition is only half the job."

Usage Boundaries: Law and Data Security

The REA project explicitly states its use is limited to legitimate research, education, interoperability, software preservation, and targets you own or are authorized to analyze. Software license agreements and local laws may restrict reverse engineering, so practicing on your own programs or CTF challenges is the safest choice.

A few principles you must follow:

• Only analyze software you own or are authorized to inspect. REA does not include licenses for paid tools like IDA, Hopper, or JEB, and the project explicitly opposes cracked versions and stolen keys. Ghidra is free and an ideal starting point for students.
• Mind your data flow. REA's analysis runs locally, but results are still sent to the Agent, and the AI provider behind it has its own data policies. Content from work or school that isn't allowed to leave should not be fed to the Agent.

Real-World Value and Next Steps

REA's showcase page offers two worthwhile case studies: someone traced the sound calculation logic in the old game DX Ball, rewrote it in C, and passed 3,205 test cases matching the original x86 code's behavior; another case mapped out how the Notion desktop app passes clipboard data between processes. These cases demonstrate the effect of the "verification" step at scale.

For learners on the networking track, REA's packet analysis capability is directly relevant to coursework, and you can get started gradually with practice platforms like picoCTF that allow "legal destruction." The core loop is simple: ask a question, let the Agent gather evidence with REA, then verify the answer yourself. AI won't replace understanding — it only accelerates it. Skip the verification step, and all you're trusting is a confident block of text.

One-line Summary

REA uses a local MCP server to let AI Agents invoke real reverse engineering tools like Ghidra, delivering evidence-backed analysis conclusions via natural language.

Paragraph Summary

REA (Reverse Engineer Anything) is an MIT-licensed open-source project positioned as a bridge between AI Agents and underlying reverse engineering tools: it runs as a local MCP server, exposing tools like "decompile function" and "list strings" to Agents such as Claude Code, Codex, and Cursor, letting language models invoke real engines instead of guessing. It supports five target categories — native binaries, JavaScript/Electron apps, .NET assemblies, Android APKs, and packet captures — relying on Ghidra, Node.js, JADX, tshark, and others respectively. Installation is just npx rea-agents setup, with attention needed to imposter-repository supply chain risks. The article also explains how to identify known algorithms via constant fingerprints (like djb2's 5381 and multiply-by-33) and emphasizes legal boundaries and data-egress considerations.