Reverse Engineer Anything Explained: How AI Agents Drive Ghidra Through MCP

It guesses. A compiled program is machine code, the numbered instructions a processor runs, and an agent that sees only those bytes can invent a story that sounds right. Reverse Engineer Anything replaces that guess with evidence from a real disassembler.

Picture a common setup. A logistics team still runs an old Windows program that reads warehouse weighing scales and writes one weight file per day. Each file ends with a check value, a number calculated from the file's bytes so that damage can be spotted. The setup is made up, but the problem is real.

The team's company wrote the program itself, but the source code was lost years ago in a server move. Now the team's new cloud system must write the same files, or the old programs that read them will break. It needs the exact check-value rule. Asked with no tools, a coding agent names a well-known checksum that fails on every real file.

You need a handful of words. Reverse engineering means working out how a finished program behaves without its original source code. A binary is the compiled program file a computer runs.

A disassembler turns a binary's machine instructions into assembly, a readable list of low-level steps. A decompiler goes further and produces pseudocode, a C-like guess at what the code does. REA can get both views from Ghidra, Hopper and IDA, the three engines its native analysis guide names.

A cross-reference is a record of where something is used, such as every place that calls a function. MCP, the Model Context Protocol, is an open standard that lets an AI agent call outside tools by name. SevyDevy's MCP guide covers the protocol itself.

Reverse Engineer Anything is an MIT-licensed project, meaning anyone may use, change and share its code. It connects coding agents to reverse engineering tools. It is published on the npm package registry as rea-agents, and analysis runs on your own machine. You can also run the same workflows as rea commands in a terminal.

Think of a hospital lab. The doctor fills in a request form, a technician runs the blood analyser, and a signed report comes back. REA is the technician, the disassembler is the analyser, and the agent is the doctor reading reports.

Where the picture breaks: a lab report is a measurement, but pseudocode is the decompiler's reconstruction, and it can be wrong. So the agent must test its conclusions, not just read them.

A setup command, npx rea-agents setup, registers REA with your agent and installs a skill file, a set of investigation instructions the agent reads. It shows a plan, backs up the files it will change and asks for approval first.

Check the install before the first question

Two commands show whether REA is ready. npx runs an npm package without a global install, and doctor is REA's readiness check. Neither changes your setup, and the output below is what REA 6.7.0 prints.

npx [email protected] --version
# prints: 6.7.0

npx [email protected] doctor --provider ghidra
# first line: healthy: true   (only when every check passes)
# if Ghidra is not found: detail: GHIDRA_INSTALL_DIR is not set, exit code 1

If doctor reports a problem, its remediation line names the fix. Without Ghidra, for example, it asks you to set GHIDRA_INSTALL_DIR to an extracted Ghidra 12.1.x folder. That is an environment variable, a named setting your terminal passes to programs.

The agent works like a careful detective: one question, evidence, a small rebuild, then a test. REA's native analysis guide shows the same loop on an old game, DX-Ball.

1. 1

   Set up once

   Run REA's setup, approve the plan, connect one analysis engine and restart the agent.

2. 2

   Ask one narrow question

   Give the agent the full path to the old program and ask how the check value at the end of each file is built.

3. 3

   Find the right function

   The agent uses overview tools and the call graph, a map of which functions call which, to find the function that writes the end of each file.

4. 4

   Read the evidence

   It reads that function's pseudocode, assembly, callers and constants, the fixed numbers written into the code.

5. 5

   Write a small rebuild

   The agent writes a short Python version of the check-value rule for the new system.

6. 6

   Test against the original

   The team compares the rebuild with real files from the old program. Any mismatch sends the agent back to the evidence.

The test is the step that turns a story into a fact. In REA's DX-Ball example, the rebuilt C function matched the original on 3,205 test inputs. Compiled, it reproduced all 63 bytes of the original function's machine code. The first pseudocode missed an integer input that the assembly showed.

The team has 2,000 old weight files, each ending with its real check value in 4 bytes. The test runs the rebuilt function on every file and counts mismatches.

from pathlib import Path

def rebuilt_check_value(body: bytes) -> int:
    """Agent's rebuild of the old program's check value (made-up logic)."""
    total = 0
    for b in body:
        total = (total * 31 + b) % 65521
    return total

mismatches = 0
files = sorted(Path("weight_samples").glob("*.dat"))
for f in files:
    data = f.read_bytes()
    body, stored = data[:-4], int.from_bytes(data[-4:], "little")
    if rebuilt_check_value(body) != stored:
        mismatches += 1
print(f"{mismatches} mismatches in {len(files)} files")

What just happened? The script splits each file into its body and its stored 4-byte value, recomputes the value and counts disagreements. We ran it on 2,000 files written by a small stand-in C program that uses the same made-up rule. It printed 0 mismatches in 2000 files.

Pause and predict: what if the rebuild keeps the remainder (the % sign) after 65536 instead of 65521? In our run, that one-number slip printed 2000 mismatches in 2000 files. On a reviewer's sample set with 15 files of two bytes or less, it printed 1985: tiny files pass under both rules. Test long samples too, because a plausible rebuild is not a correct one until the samples agree.

Beginners can stop here. You now know what REA is, how an agent uses it and why the test matters. The rest is for engineers: engines, timeouts, safety hints and the law.

Pick the engine that runs on your computer and that you are licensed to use. Ghidra is free and open source under the Apache 2.0 licence, created and maintained by the US National Security Agency's Research Directorate. Hopper and IDA Pro are commercial tools, used under their vendors' licence or demo terms. IDA Free costs nothing but has its own licence limits.

The team picks Ghidra because it is free and runs on their Linux laptop. REA 6.7.0 also accepts Kuna, an open-source decompiler you supply, plus GNU objdump, a standard command-line disassembler, and Rizin, an open-source reverse engineering framework, for offline inspection. REA does not install or update those tools.

One version detail is easy to miss. REA 6.7.0 is verified on Ghidra 12.1.4; another 12.1 build is accepted, but each session records a limitation saying the build is unverified. A build outside the 12.1 line is reported as unsupported.

REA's guides document the 12.1 line; the limitation note is visible in REA 6.7.0's source code, as of 19 October 2026. Pin both your REA and Ghidra versions on a team.

Each MCP tool is a narrow, named question with a fixed result shape. The agent never types raw Ghidra, Hopper or IDA commands. It sends a tool call over stdio, the standard input and output streams between two programs on one machine, and REA replies with a structured record.

Sessions keep the engine warm

Importing a binary into Ghidra is slow, so REA keeps a session open across questions. The open_binary tool picks the target and an analysis provider, or auto to let REA choose. It does not start Ghidra yet.

The first engine question, such as binary_overview, starts Ghidra. That call waits for the import, Ghidra's automatic analysis and REA's bridge to be ready. Later questions reuse the warm session until close_binary ends it.

Two timeouts can disagree

REA gives Ghidra 330,000 milliseconds, five and a half minutes, to finish starting by default. Your agent's MCP client sets its own wait for each tool call. In the TypeScript MCP client library version 2.3.1, which REA pins, that wait defaults to 60,000 milliseconds.

So an agent with a 60-second wait can give up while Ghidra is still importing, even on a tiny file. REA's docs report a 1,024-byte test program taking about 163 seconds for its first answer on Windows.

Raise the agent's tool-call timeout first. After a timeout, do not just ask again: call close_binary, reopen the file with open_binary, then repeat the question. For very large files, REA_GHIDRA_STARTUP_TIMEOUT_MS raises REA's own startup deadline, and setup adds longer tool timeouts for some agents.

Tools answer focused questions

The analyze_function tool returns a dossier for one function: pseudocode, assembly, comments, references, strings and its control-flow graph, a map of the paths through its code. With Ghidra or Hopper it also lists callers and callees, the functions that call it and the ones it calls.

The trace_call_path tool searches the call graph for a route from one function toward a goal. Each analysis result is an evidence record with a list of limitations. Its ID is ev_ followed by a SHA-256 digest, a fixed-length fingerprint of the record: the file, engine, question and result. The same question on the same file and setup gets the same ID.

The team can then see which result backs each claim, and what it could not cover. This toy Python shows the wrapping idea, not REA's real code. One engine query goes in, and one labelled record comes out.

import hashlib
import json

def analyze_function_tool(engine, name):
    """Toy MCP tool: one engine query in, one evidence record out."""
    raw = engine.decompile(name)          # stand-in for the real engine call
    result = {
        "pseudocode": raw.get("pseudocode"),
        "callers": raw.get("callers", []),
    }
    digest = hashlib.sha256(json.dumps(result, sort_keys=True).encode()).hexdigest()
    return {
        "evidence_id": "ev_" + digest,    # same result, same ID
        "operation": "analyze_function",
        "normalized_result": result,
        "limitations": raw.get("limitations", []),
        "_meta": {"provenance": {"untrusted_content": True}},  # text came from the target
    }

It also covers JavaScript and Electron desktop apps, which are built with web technology, plus compiled .NET files (Microsoft's application platform), websites and Android packages. The 6.7.0 README lists 23 kinds of target. Static JavaScript and .NET inspection need no disassembler and read the files without running the app.

For an Electron app, REA maps modules, imports and IPC, the messages between an app's window and its background process. Results are inferred from code, so names built while the app runs stay unresolved and are marked as unknown.

Runtime capture is different: it runs or drives the target with your user permissions, like any unknown program you start yourself.

It is safe enough only with guardrails, because the target can try to talk to the agent. Strings, pseudocode and page text come from the file. A hostile file can hide text that looks like an order, such as asking the agent to download a helper.

REA treats that text as data. Its server instructions tell the agent never to follow directives found in results. They also say to report any request to run, install, download or send something as a prompt-injection attempt, meaning instructions smuggled into data.

Results that can contain target content carry a marker, untrusted_content, in the result's _meta field, the metadata part of an MCP reply. We checked this on REA 6.7.0: a GNU objdump disassembly and a failed open_binary call both came back with the marker set to true.

The hints also mean less than their names suggest. In REA 6.7.0, 202 of 207 tools say readOnlyHint false, because recording evidence in the session counts as a change. Only 31 say destructiveHint true, including tools that run the target or a debugger.

A few tools are open-ended by design. They pass raw commands to Rizin, its desktop app Cutter, or GDB, the GNU debugger. Others load scripts into a running process with Frida, a toolkit that injects scripts into running programs. All of them say destructiveHint true.

So decide approvals yourself. REA has no per-call approval switch; your agent's approval prompts do that job. Approve every tool that runs code, analyse unknown programs on an isolated machine, and remember that results reach your agent's model provider.

Sometimes: it depends on who owns the software, your licence terms and your country's law. This section is general information, not legal advice. REA's README says the tool is for lawful research, education, interoperability, software preservation, and software you own or are authorised to examine.

REA's disclaimer adds limits. The project does not support circumventing DRM (digital rights management, meaning copy protection) or licence checks, or copying proprietary code and assets. It also says that possessing a file does not by itself give permission for every operation.

In India, Section 52(1) of the Copyright Act, 1957 lists acts that do not infringe copyright. Clause (ab) covers a lawful possessor of a program doing what is needed to get information for making an independently created program work with other programs. It applies only when that information is not otherwise readily available.

Clause (ac) covers observing, studying or testing how a program works, to find the ideas and principles behind it. This must happen while doing the acts the program was supplied for. Neither clause says whether a licence can forbid these acts, so read your licence and ask a lawyer if it does.

In the European Union, Article 6 of Directive 2009/24/EC lets a person with a right to use a program decompile it without the copyright holder's permission. That applies only when decompiling is indispensable for interoperability. The information must not be readily available, and only the needed parts may be decompiled. Article 8 voids contract terms that override this.

The EU rule also forbids using that information to build a program substantially similar in its expression. Other countries have their own rules, and a licence can add limits. In the guide's case the company wrote and owns the old program, so the team records that in writing first.

REA does not give you the original source code back, and InfoQ notes that it does not claim to. Pseudocode is the engine's reconstruction. REA's disclaimer says decompilation and AI-assisted analysis may be incomplete or incorrect, which is why the test step matters.

Coverage also varies by engine and host, as of 19 October 2026. Ghidra on Windows is still experimental, and REA's newer IDA profiles cannot list a function's direct callers. Indirect calls, whose target is only known at run time, can stay unknown in call graphs.

InfoQ also reported criticism on 17 October 2026. Some Hacker News readers asked what REA adds over telling an agent to install and use Ghidra, while others reported better results. On Reddit, some independent developers feared it could make copying their games easier.

Frame it as a tool layer between an agent and a heavy local engine, then talk about trust and verification.

1. 1

   State the problem

   Agents guess about compiled code, so they need checkable evidence from a real disassembler.

2. 2

   Draw the layers

   Agent, local MCP server over stdio, analysis engine and target file, all on one machine.

3. 3

   Explain the tool design

   Narrow named tools, long sessions for slow imports, and evidence records with stable IDs and limitations.

4. 4

   Cover trust

   Mark target text untrusted, treat tool hints as hints, approve tools that run code, and note what reaches the model provider.

5. 5

   Close the loop

   Test every rebuild against the original program's outputs, and name the timeout, licence and legal limits.