Learning How AI Can Reverse Engineer Software

Reverse engineering has always looked intimidating from the outside. It usually means reading assembly, learning heavy tools like Ghidra or IDA, and spending hours tracing code by hand. Recently I came across an open source project called REA that connects AI agents to those same tools, so you can ask questions about a program in plain English and get answers back with evidence attached.

In this post I break down what REA is, how it works under the hood, what it can analyze, how to set it up, and what every beginner should know before trying it, including how to stay on the right side of the law.

🧩 The Idea: Reverse Engineer Anything

Reverse engineering is figuring out how software works when you do not have its source code. Security teams use it to pick apart malware, researchers use it to find vulnerabilities, and developers use it to make old software talk to new systems. As a networking and server admin student leaning toward cybersecurity, it is a skill I kept seeing on job postings and kept avoiding because the learning curve looked like a cliff.

Then I found REA (Reverse Engineer Anything), an open source, MIT licensed project that connects AI agents like Claude Code, Codex, Cursor and Gemini CLI to real reverse engineering tools. Instead of memorizing every menu in Ghidra, you ask your agent a question in plain English. The agent calls REA, REA runs the heavy tools on your own machine, and you get findings back along with the evidence and limitations behind each conclusion.

What surprised me most is how much it covers. Here are the targets that stood out to me:

Target	What REA gives back	What you need
Native binaries	Pseudocode, assembly, strings, symbols, calls and references	Ghidra (free), Hopper or IDA
JavaScript and Electron apps	Modules, imports, routes and IPC between processes	Just Node.js and npm
.NET assemblies	Metadata and CIL instructions	Nothing extra, static analysis only
Android APKs	Manifest, classes and decompiled methods	JADX and a full JDK
Packet summaries	Endpoints, DNS, TLS SNI and protocol breakdown	tshark and capinfos

That last row is the one that got me as a networking student. The same agent that reads a binary can also summarize a packet capture.

Source: REA README

🔑 The Part That Broke My Brain: MCP

The concept that took me the longest to understand was how an AI chatbot could suddenly "use" a program like Ghidra.

Here is the short version of what I learned. MCP stands for Model Context Protocol, and it is a standard way for an AI agent to call outside tools. On its own, an AI model can only read and write text, so if you paste in some assembly it is basically guessing. REA runs as a local MCP server that offers the agent a set of tools, things like "decompile this function" or "list the strings in this file." The loop looks like this:

1. You ask your agent a question about a program.
2. The agent picks a REA tool and calls it through MCP.
3. REA runs Ghidra (or another engine) locally against the file.
4. REA sends back pseudocode, assembly and references, plus what it could not confirm.
5. The agent reads the evidence, asks follow up questions, and explains it to you.

The moment it clicked for me: the AI is not making up what the program does. It is reading the same evidence a human reverse engineer would read, just a lot faster.

That "what it could not confirm" part matters more than I expected. AI models can sound confident while being wrong, so a tool that reports its own unknowns keeps both you and the agent honest.

⚙️ Getting It Running

REA needs Node.js and npm. The supported versions are Node 22 (22.19 or newer), Node 24 (24.11 or newer), or Node 26 and up. For native binaries you also need an analysis engine such as Ghidra, Hopper or IDA. Ghidra is the easiest place for a beginner to start because it is free. Setup is one command:

npx rea-agents setup

It asks which agents you use, shows you the changes it wants to make, and backs up your existing config before adding the REA MCP server. After that you restart your agent and it can use the new tools.

If you want the rea command in your terminal for regular use, you can install it globally:

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

One gotcha to watch for on Linux: Ghidra and the JavaScript analysis need a procps compatible ps command on your PATH, so if things fail on a minimal VM, check that first.

One more thing I did not expect to learn from a README: the project warns that copycat repos with similar names exist, and you should only install from the official GitHub repo, rea.tools, or the rea-agents npm package. That is a real supply chain attack lesson hiding inside an install guide.

🔍 How You Actually Use It

There are two ways to work with REA. The first is through your AI agent. After setup, you describe what you want to understand in plain English, and the agent decides which REA tools to call. A prompt might look like this:

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

The second way is the terminal, which runs the same workflows without an agent. For example, this command inspects an extracted JavaScript or Electron app and needs no native analysis engine at all:

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

According to the docs, the output lists the app's modules, imports and Electron boundaries, along with the evidence for each one.

🧪 A Core Skill: Spotting Known Algorithms

Whether a person or an AI is doing the analysis, one of the most useful reverse engineering tricks is recognizing well known algorithms by their fingerprints. Compiling throws away comments, and stripping a binary removes function names, but neither can hide the math. Here is a classic example, a string hash called djb2, written in C:

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

Once this is compiled and stripped, the name djb2 is gone. What survives in the pseudocode or assembly are two clues: the starting value 5381, and a shift left by 5 followed by an add, which is just a fast way to multiply by 33. Someone who knows those clues can name the function in seconds, and an agent reading evidence from REA can match them the same way. Other famous constants work like this too, such as 0x67452301 at the start of MD5 and SHA-1, or 0xEDB88320 in CRC32.

Compilers erase names, but they cannot erase math. That is why constants are one of the first things reverse engineers look for.

Identifying an algorithm is only half the job. The other half is proving it, by running the original program and a rewritten version on the same inputs and checking that the outputs match.

🧠 What I Learned (Including Staying Legal)

The biggest takeaway is that AI does not replace understanding, it speeds it up. An agent can find an answer fast, but testing that answer against the original program is what proves it. Skip that step and you are just trusting a confident sounding paragraph.

The second lesson is about responsibility, because reverse engineering tools can be misused:

• Only analyze what you own or are authorized to examine. The REA project says it is meant for lawful research, education, interoperability, software preservation, and software you own or have permission to analyze. Software license agreements and laws can restrict reverse engineering, so practicing on your own programs or on CTF challenges is the safe move.
• Use legit tools. REA does not come with licenses for paid tools like IDA, Hopper or JEB, and the project is clear that cracked copies and stolen keys are not okay. Ghidra is free, which makes it perfect for students.
• Think about your data. REA runs the analysis locally, but the results still go to your agent, and the AI provider behind it has its own data policy. I would not feed it anything from work or school that I am not allowed to share.

🚀 What's Coming Next

Next, I want to dig into the packet capture side of REA, since that ties straight into my networking classes. I also want to work through beginner reverse engineering challenges on picoCTF, where breaking things is the whole point and completely allowed.

If you want to see what this looks like on real software, the REA showcases are worth reading. In one, someone traced a sound calculation in the old game DX Ball and rebuilt it in C so accurately that it passes 3,205 test cases against the original x86 code. Another follows how the Notion desktop app moves clipboard data between its processes. They are a great example of the verify step done at scale.

The core idea is simple: ask a question, let the agent gather evidence with REA, then verify the answer yourself. That loop makes a field that once felt out of reach a lot more approachable for beginners.

Thanks for reading. More updates coming as I keep digging in.

Links: REA on GitHub · rea.tools · Ghidra