LaurieWired

and here's the code! LaurieWired/CallMeMaybe

and here's the code! LaurieWired/CallMeMaybe

Ghidra MCP vs REA: How AI Agents Reverse Engineer Software, and What the Setup Changes on Your Machine --- title: Ghidra MCP vs REA: How AI Agents Reverse Engineer Software, and What the Setup Changes on Your Machine published: true date: 2026-10-29 08:00:00 UTC tags: ghidramcp,ghidramcpserver,ghidradecompiler,reaagents canonical_url: alekseialeinikov.com --- !Ghidra MCP vs REA: How AI Agents Reverse Engineer Software, and What the Setup Changes on Your Machine An AI agent that can read compiled code sounds like a party trick until you watch what it replaces: hours of scrolling through decompiler output, renaming FUN_00401a30 to something that means anything, and tracing who calls what. There are now two families of tools that hand that work to an agent. The first is a growing pile of Ghidra MCP servers , bridges that let Claude, Cursor or Codex drive the NSA’s open-source reverse engineering framework. The second is a newcomer called REA (rea-agents on npm), which says it is “one MCP for reverse engineering across binaries, applications, and runtime behavior”. They get lumped together because both end with an agent asking for a decompiled function. They are not the same kind of thing, and they do not change your machine in the same way. This article compares them from the documentation, explains in plain words what each layer does, walks through what the setup actually touches, and ends with the part most posts skip: where the legal lines are. !Ghidra MCP vs REA: a sealed black box cracks open and pours out readable pseudocode while Ghidra plugs in with one cable and REA with a bundle of cables, an illustration of AI reverse engineering. The Short Answer - Want Ghidra’s decompiler inside a chat, for native binaries? Use a Ghidra MCP bridge. GhidraMCP is the simplest start, pyghidra-mcp suits headless and multi-binary projects, ghidra-mcp has the most tools and the most to configure. - Your question crosses formats? An Android app plus its backend traffic, an Electron app, firmware, WebAssembly. REA is built for that, and Ghidra is only one of its engines. - Care about knowing what was proven? REA’s docs make evidence and limitations first-class. A static call graph is labelled as static, an empty result is not read as “does not exist”. - Care about a small footprint? A Ghidra bridge adds a plugin and a local port. REA edits your agent’s global configuration. Both are reversible, neither is nothing. - Analyzing unknown malware? Do it in an isolated VM, with either tool, and with no credentials on the box. More on why below. What Is a Ghidra MCP Server? Engine, Bridge, Agent Three words get mixed up, so it is worth separating them. A disassembler turns machine code into assembly instructions. A decompiler goes one step further and reconstructs C-like pseudocode from those instructions. The pseudocode compiles to nothing and is not the original source: names are gone, types are guessed, loops are inferred. That matters later. Ghidra is the engine, and its decompiler is the part an AI agent leans on most. It is a software reverse engineering framework created and maintained by the NSA Research Directorate, with disassembly, assembly, decompilation, graphing and scripting, support for a wide range of processor instruction sets and executable formats, and both user-interactive and automated modes. You can extend it in Java or Python. MCP (the Model Context Protocol) is the plug that lets an agent call tools. If the idea is new, the MCP gateway article explains why every MCP server is a place where an agent gains real capabilities. A Ghidra MCP server is therefore a translator between two worlds: the agent speaks MCP, Ghidra speaks Java and Python. The agent says “decompile the function at this address”, the bridge asks Ghidra, Ghidra answers, the agent reads and reasons. That loop, repeated a few hundred times with renames in between, is what turns FUN_00401a30 into verify_license_key. Ghidra MCP Servers Compared: GhidraMCP vs ghidra-mcp vs pyghidra-mcp Search for “ghidra mcp” and you will find several projects with similar names. Three lead by GitHub stars, and smaller ones exist, such as mrphrazer’s ghidra-headless-mcp. Two of the three shipped major releases this month: GhidraMCP 2.0 on October 10 and ghidra-mcp 7.0.0 on October 21. They share the engine and differ in how they reach it. | | GhidraMCP (LaurieWired) | ghidra-mcp (bethington) | pyghidra-mcp (clearbluejar) | | --- | --- | --- | --- | | GitHub stars | about 11.6k, created March 2025 | about 6k, created August 2025 | about 455, created July 2025 | | Licence | Apache-2.0 | Apache-2.0 | Apache-2.0 | | Shape | Ghidra plugin plus a Python MCP bridge | Rewrite of the above: Python bridge, HTTP REST, Java plugin | Headless-first, runs Ghidra in the same JVM through pyghidra and JPype | | Needs Ghidra GUI running | Yes, with an optional headless mode through PyGhidra | Yes for the full tool set, a headless server exists with fewer endpoints | No, it has a --gui mode but cannot attach to a running Ghidra | | Scope | Decompile, rename methods and data, list methods, classes, imports, exports | 219 MCP tools by the project’s own count | Project-wide analysis, semantic code search, xrefs, call graphs | | Transport | stdio and streamable HTTP | stdio and streamable HTTP | streamable HTTP recommended | | Requires | Ghidra 12.1.4, uv | Ghidra 12.1.4, Java 21, uv | pyghidra, Python | Three details from those READMEs are worth knowing before you pick one. The architecture is a chain, and every link is a process. In ghidra-mcp, the agent talks to a Python MCP bridge over stdio or streamable HTTP, the bridge talks to a Java plugin inside Ghidra over an HTTP REST API on localhost port 8089, and Ghidra does the analysis. GhidraMCP uses the same pattern with its HTTP server on localhost port 8080. The practical meaning: there is a local network port on your machine that can read and, in some tools, modify your analysis database. Both projects bind to localhost by default, and ghidra-mcp requires an auth token (GHIDRA_MCP_AUTH_TOKEN) if you bind to anything else. More tools is not automatically better for the agent. ghidra-mcp ships 219 tools (the GUI plugin serves 216 of them, the headless server 201). Its README documents an unusual consequence: Gemini rejects the full tool schema with a 400 INVALID_ARGUMENT “too many states” error. So the project loads tools lazily by default, 70 endpoints plus 8 static tools in the listing, function and program groups, and the agent pulls in more groups on demand. That is a good illustration of a real limit: every tool description costs context and every client has a tolerance. Dangerous capabilities are opt-in, which is the right default. Since version 5.4.1 of ghidra-mcp, the script execution endpoints are off unless you set GHIDRA_MCP_ALLOW_SCRIPTS, and the README says plainly that they “execute arbitrary Java against the Ghidra process”. There is also a GHIDRA_MCP_FILE_ROOT setting to restrict file access. Its other headline features, per its own README: write tools for renaming, typing, structs and comments, P-code emulation, debugger integration through TraceRmi (GUI only), malware-oriented tools such as detect_malware_behaviors and extract_iocs_with_context, cross-binary documentation transfer by function hash, Ghidra Server integration and a Docker headless setup. The README also claims “3x more than any competing implementation” and “93% fewer API calls” through batching. Those are the project’s own claims. pyghidra-mcp thinks in projects, not single binaries. It can analyze every binary in a Ghidra project concurrently, searches code semantically with a ChromaDB vector index, generates call graphs as Mermaid, decompiles in batches, and ships a CLI client and a Docker image. That is the better fit for “here are 40 binaries from one firmware, find the one that parses the config”. > “Ghidra MCP” is a category, not a product. Pick by shape: plugin plus GUI (GhidraMCP), maximum tools (ghidra-mcp) or headless and project-wide (pyghidra-mcp). The engine, and therefore the quality of the decompilation, is the same. What Is REA (rea-agents)? One MCP for Many Targets REA (github.com/morluto/rea, site rea.tools) is MIT licensed and distributed as the npm package rea-agents. It is a different shape of tool: an MCP server, a command-line tool called rea and an agent skill called reverse-engineer-anything, all in one package. Its pitch is breadth. The documented targets include: - native binaries, ELF layout, Go, Rust and IL2CPP - WebAssembly and EVM bytecode - GGUF and safetensors model files, SQLite databases - JavaScript and Electron apps (modules, IPC, source maps) and live websites through Chrome - HAR and SAZ captures, packets through TShark - .NET assemblies, Android APKs through JADX, ADB, Flutter - firmware through Binwalk and Unblob, PyInstaller bundles - process behavior at runtime For native code, REA does not reinvent the decompiler. It calls one: Ghidra 12.x (12.1 or newer) with a full 64-bit JDK, Hopper (commercial), IDA or Kuna, plus objdump and Rizin. It requires an existing Ghidra install and never installs Ghidra itself. So the honest relationship is not “REA vs Ghidra” but “REA on top of Ghidra, among others”. If you point REA’s Ghidra provider at a binary, you get Ghidra’s decompiler either way. What sets REA apart is less the tool list than the contract it puts on every answer. Its native investigation docs repeat the same discipline in many places: - A result carries Evidence and explicit limitations. Unknown means unknown, not false. - “An empty Hopper inventory cannot establish that no such call exists.” - A static call route “does not establish runtime reachability”. - Decompiler pseudocode is never treated as original source. - Static references enumerated by the analyzer “are not observed runtime reads or writes”. For an agent, that contract is the point. Language models want to give a clean answer. A tool whose output says “this is a static observation, completeness unknown” gives the model less room to overclaim, and gives you something to check. On the Ghidra side specifically, REA’s adapter is deliberately conservative. It exposes 27 operations, all read-only: 15 for inventory, names and search, and 12 for function analysis. It opens the target in an ephemeral project (-readOnly -deleteProject), and name and comment edits are session metadata that is discarded when the session closes. The default startup deadline is 330 seconds. Windows support is marked experimental. If that reads like a trade-off, it is one: you give up Ghidra’s full write surface for a smaller, auditable one. REA’s showcase examples show the intended style: finding why a Chrome dino game’s speed starts at 6 and rises while below 13, tracing the % button of Windows Calculator (200 + 10% = 220), recovering an Electron app’s clipboard bridge, reproducing 63 compiled function bytes of a DX-Ball sound routine against 3,205 original-x86 test cases. These are demonstrations from the project, not independent results. A quick note on REA’s numbers. GitHub shows about 404,000 stars for a repository created in April, and npm has 34 releases since July 12 (6.8.0 on October 25). How the stars accumulated can’t be checked, so judge REA by its docs and code. It is also essentially a one-maintainer project, with about 3,800 of roughly 6,200 commits from one developer, so pin the version you tested. Ghidra MCP vs REA Side by Side !Ghidra MCP vs REA architecture: a Ghidra bridge connects the agent to one Ghidra engine through a Python bridge, a local HTTP port and a plugin; REA connects the agent to one MCP server with provider adapters for Ghidra, Hopper, IDA, JADX, Chrome and more, and returns Evidence with limitations. _One engine behind a bridge, or a toolbench behind one server._ | | Ghidra MCP bridges | REA | | --- | --- | --- | | What it is | Adapter between an agent and Ghidra | MCP server, CLI and skill over many engines | | Targets | What Ghidra imports: native binaries, many architectures | Native, Android, JS and Electron, .NET, firmware, WASM, packets, runtime and more | | Decompiler | Ghidra | Ghidra, Hopper, IDA or Kuna for native code | | Interface to the engine | Plugin plus local HTTP, or headless through PyGhidra | Provider adapters, Ghidra in an ephemeral read-only project | | Write access | Yes: rename, retype, comment, structs, depending on the project | Ghidra adapter read-only; annotations live in a temporary session | | Scripts | Script execution endpoints exist, off by default in ghidra-mcp | Not part of the Ghidra adapter described in the docs | | How results are framed | Raw tool output, the agent interprets | Evidence, coverage and limitations on every result | | Runtime analysis | ghidra-mcp: emulation and a GUI-only debugger | Opt-in runtime capture; LLDB call observation launches an owned process | | Install effort | Install Ghidra, an extension or Python package, match versions | npx rea-agents setup plus an existing Ghidra if you want native analysis | | Maturity signal | Three independent projects, the oldest from March 2025 | One project, first release July 2026, fast release cadence | | Licence | Apache-2.0 (GhidraMCP, ghidra-mcp) | MIT | How AI Reverse Engineering Works: What the Agent Actually Does The two families share the same loop. Only the commands differ. With a Ghidra bridge , the agent works the way a human would in the CodeBrowser. It lists functions, imports and strings, decompiles the interesting ones, follows cross-references, renames what it understands and writes comments. Because the writes land in the open Ghidra database, a good session leaves behind an annotated project you can open afterwards. With REA , the documented native workflow is explicit about picking exact names. From its docs, with the Ghidra provider: _Terminal window_ rea inspect /absolute/path/to/program --provider ghidra --json rea search /absolute/path/to/program entry --kind procedures --provider ghidra --json rea function /absolute/path/to/program <procedure> --provider ghidra --json rea decompile /absolute/path/to/program <procedure> --provider ghidra <button title="Copy to clipboard" data-copied="Copied!" data-code="rea inspect /absolute/path/to/program --provider ghidra --jsonrea search /absolute/path/to/program entry --kind procedures --provider ghidra --jsonrea function /absolute/path/to/program &lt;procedure&gt; --provider ghidra --jsonrea decompile /absolute/path/to/program &lt;procedure&gt; --provider ghidra"><div></div></button> The docs add a small warning that is easy to miss and typical for the project: do not assume every target names its entry function entry; pick an exact name or address from the returned inventory. Over MCP the same flow is open_binary, then focused tools such as list_procedures and analyze_function on the same session. Beyond that: - batch_decompile reads several functions at once, and decompile_all writes one pseudocode file per function plus a manifest that contains counts but no code. - search_bytes finds masked byte patterns and says what it did not search, for example uninitialized blocks. - trace_native_values builds def-use graphs from the decompiler’s high p-code across statically resolved calls. - export_evidence_bundle keeps the observations so a conclusion can be reviewed later without trusting the chat. The last item is the quiet strength. A transcript of an agent saying “this function validates a licence key” is a claim. An evidence bundle with the addresses, references and limitations behind it is something a second person can check. Ghidra MCP and REA Setup: What Changes on Your Machine This is the section most comparisons skip, and the one that should decide whether you try something. Everything below is from the projects’ docs. Ghidra bridges Typical flow: install a JDK and the exact Ghidra release the extension was built for (the READMEs name Ghidra 12.1.4), install the plugin zip through File, Install Extensions , enable it in the configuration, restart Ghidra, then register the MCP server with your client, for example with uvx --from git+https://github.com/LaurieWired/GhidraMCP ghidra-mcp --ghidra-server http://127.0.0.1:8080/. What changes: - a plugin inside Ghidra, which loads only in the exact Ghidra version it was built for - a local HTTP server on a fixed port while Ghidra runs - an entry in your agent’s MCP configuration - a Python process started on demand, with uvx fetching code from a Git URL at run time, which is worth pinning to a commit or tag Note a version tension: the Ghidra README for its current master branch asks for JDK 25, while the bridge projects document Ghidra 12.1.4 and Java 21. Match them to the bridge’s README rather than to the newest Ghidra. REA npx rea-agents setup is the documented entry point. According to the install docs: 1. It first prints a plan that lists config file paths, skill destinations, external software it might need, network origins, integrity evidence and package-manager commands. 2. It writes nothing until you approve. Approving the plan is separate from your approval of the npm download itself. 3. It makes .rea.backup copies of config files before editing, preserves unrelated entries, and treats a malformed config as a reason to block the whole transaction instead of guessing. 4. For Claude Code it registers mcpServers.rea in ~/.claude.json and installs the skill in ~/.claude/skills/reverse-engineer-anything. You choose the clients in a multi-select. Existing REA registrations are preselected, newly detected clients are not, because detection gives setup context, not permission. The skill is installed by default and --skill=false skips it. If you use Claude Desktop, quit it fully before approving, since a running app can overwrite the registration. More than two dozen client identifiers are supported, including Claude Code and Desktop, Codex, Cursor, Gemini CLI, Windsurf, VS Code, Copilot CLI and OpenCode, and there is a plugin route (/plugin marketplace add morluto/rea) and an MCP Registry entry, io.github.morluto/rea. What deserves attention, again straight from the docs: - The registration is global. For Claude Code, the entry and the skill apply to every project. The docs describe limiting that with a separate CLAUDE_CONFIG_DIR profile or a local scope, and are candid that an agent running under the same OS account can still run rea or npx and read files. - It registers an absolute path to node and the entry script, so the npx cache must stay in place. - The install script is not signature-checked. The docs say so themselves: “Neither command verifies a signature on the downloaded script.” They show a safer flow: download the script from a pinned tag, read it with less, then run it with the matching --version. Or skip it and use the npm route. - Run package runners from a trusted directory outside the target, because they can read project configuration. - Hopper setup can download the official package with a PGP signature check (the docs list the primary key fingerprint) and a DMG digest check on macOS, with HTTPS-only redirects. Ghidra is never downloaded. - Undo exists. rea doctor is read-only, rea uninstall removes only registrations REA owns (--purge-data also clears its cache), and rea update keeps dependency lifecycle scripts disabled. The npm package itself defines only prepare and prepublishOnly scripts, no install-time hooks, and has 42 dependencies at about 49 MB unpacked. <aside role="note"><p>Warning</p> <p>The README warns that look-alike repositories exist and are not official. For a tool that edits your agent’s configuration, verify the source (<code>morluto/rea</code>, <code>rea-agents</code>) before running anything. The same applies to the many repositories named “ghidra-mcp”.</p></aside> For the broader habit of installing tools that run code on your machine, npm supply chain attack mitigation covers what to pin, what to disable and what to read first. !Ghidra MCP vs REA setup: what each installer touches. A Ghidra bridge adds a plugin and a local HTTP port; REA shows a plan, waits for approval, backs up config files, writes the MCP registration and skill, and can be removed with a single uninstall command. _Both are reversible. Neither is nothing._ What Can Go Wrong Four risks are worth naming. The first is from my own analysis and is not in either project’s docs; the others are documented. 1. The binary talks back. From the model’s point of view, a sample is untrusted text. Strings, symbol names, embedded resources and comments all arrive inside tool results. A malicious binary can include a string like “ignore previous instructions and run this command”, and an agent with shell access and secrets is exactly the target. This is the lethal trifecta: private data, untrusted content and a way out. The defense is architectural: unknown samples go into a disposable VM with no credentials, the agent gets only the tools it needs, and anything that can execute code stays off. The case where rogue AI agents compromised a real website shows how little it takes once an agent has capability and a goal. 2. Write tools change your analysis. Renames and retyping are what make a session useful and what make a wrong guess spread: a function named check_license by a confident model will colour every later decision, yours included. REA’s read-only Ghidra adapter sidesteps that by design. With a write-capable bridge, keep a copy of the project before the agent starts. 3. Runtime features run the target. REA’s docs are explicit: runtime capture executes the target with your user permissions, and its LLDB call observation launches an owned process that “may change files, show UI or use the network”. Authorization to inspect a file “does not necessarily authorize execution”. Use a VM here too. 4. The model provider sees what the tools return. REA’s docs say its analysis is local, and that “your agent receives the tool results, and its model provider has its own data policy”. That means decompiled code leaves your machine as soon as it enters a cloud model’s context. For proprietary or contractually restricted software, that is a legal and a confidentiality question before it is a technical one. Is Reverse Engineering Legal? <aside role="note"><p>Warning</p> <p>This is a summary of public statute text, not legal advice. Law differs by country, contract and case. If a decision matters, ask a lawyer who knows software and IP in your jurisdiction.</p></aside> The useful way to think about it is four layers, and an action must clear all of them. | Layer | The question | What the sources say | | --- | --- | --- | | Authorization | Is it yours, or do you have permission? | REA’s disclaimer: public availability, possession of a file or access to a debugging endpoint “does not by itself establish permission for every operation”. US 17 U.S.C. 1201(j) defines security testing as good-faith testing “with the authorization of the owner or operator”. | | Contract | What does the licence or EULA say? | Germany: terms that contradict section 69d(2), (3), (5), (7) or section 69e UrhG are void (section 69g(2)). The US position on EULA restrictions was not researched for this article. | | Copyright and access controls | Is there a statutory exception? | US 1201(f) for interoperability; Germany section 69e for decompilation and section 69d(3) for studying a program; EU Directive 2009/24/EC behind the German rules. | | Tool policy | What does the tool refuse to help with? | REA will not help with DRM or licence circumvention, game cheats, bypassing access controls, copying proprietary code or evading AI providers’ usage policies. | United States. Section 1201 of the Copyright Act is about circumventing technical protection measures that control access to a work. Its reverse engineering exception, 1201(f), lets a person who lawfully obtained the right to use a copy of a computer program circumvent such a measure “for the sole purpose of identifying and analyzing those elements of the program that are necessary to achieve interoperability of an independently created computer program with other programs”, where those elements were not previously readily available, “to the extent any such acts of identification and analysis do not constitute infringement”. The tools to do it, and the information gained, may be shared only for interoperability. Separately, 1201(c)(1) says the section does not affect fair use or other defenses to infringement. Note what this is not: a general permission to disassemble anything for any reason. Germany and the EU. The German rules implement the EU computer programs directive, 2009/24/EC, which replaced the original 1991 directive. Section 69d(3) UrhG says a person entitled to use a copy may “observe, study or test the functioning” of the program to determine the ideas and principles behind its elements, if this happens through acts of loading, displaying, running, transmitting or storing that they are entitled to perform. Section 69e allows decompilation without the rightholder’s consent only if reproducing the code or translating its form is indispensable to obtain information needed for interoperability of an independently created program, and only if: it is done by a licensee or authorized person; the information was not already readily accessible; and the acts are limited to the parts necessary. The information may not be used for other purposes, passed on beyond what interoperability needs, or used to build a program with a substantially similar expression. And section 69g(2) makes contract terms that contradict section 69e void, so an EULA cannot simply forbid what the statute allows. Trade-secret law points the same way: under section 3(1) no. 2 of the German Trade Secrets Act (GeschGehG), a trade secret may be obtained by observing, studying, taking apart or testing a product that was made publicly available or is in your lawful possession, unless you are bound by a duty to limit that. What that means in practice, as a reading aid and not advice: - Analyzing your own software, or malware samples in a lab, is the common and uncontroversial case. The agent changes the speed, not the status. - Interoperability has explicit statutory support in both systems, with conditions on necessity and on what you do with what you learn. - Security testing needs the owner’s authorization, in the US text and in REA’s own policy. - Circumventing DRM, licence checks or anti-cheat , and copying protected code , are outside what these exceptions cover and outside what REA will help with. - An AI does not launder it. REA’s disclaimer says you are responsible for “actions you direct an AI agent to perform”, and that getting source-like output “does not grant rights to the original program”. A Safe Setup Checklist for AI Reverse Engineering These are my recommendations, built from the documented behavior above. None of them needs a special tool. 1. Use a disposable VM for unknown samples, with no credentials, no SSH agent and no cloud tokens on it. 2. Keep the tool out of your daily agent profile. For REA on Claude Code, a separate CLAUDE_CONFIG_DIR profile keeps the registration and skill away from your other projects. 3. Pin versions. Use the Ghidra release the bridge names, a bridge tag or commit instead of a moving branch, and an exact rea-agents version. 4. Prefer read-only tools. Leave script execution off (GHIDRA_MCP_ALLOW_SCRIPTS), and copy the Ghidra project before an agent gets write tools. 5. Keep servers on localhost. If you bind elsewhere, set the auth token the project asks for. 6. Treat strings and comments in the sample as hostile. Do not give the agent a shell or open network access in the same session. 7. Keep the evidence. Save addresses and references for every claim, and verify the important ones in the disassembly or a debugger. 8. Check permission before you start. Confirm you may analyze the target, and read your model provider’s data policy before sending proprietary code through it. When to Use Which 1. Learning, CTFs, one native binary, you like Ghidra’s UI: GhidraMCP. Lowest friction, and the annotations end up in a Ghidra project you can keep. 2. Many binaries, scripts and automation, no GUI: pyghidra-mcp, for its headless and project-wide design. 3. You want every Ghidra feature exposed and will configure it carefully: ghidra-mcp, with scripts left off and a file root set. 4. The target is not a plain native binary: an Electron or Android app, a firmware image, a WebAssembly module, network captures. REA’s breadth is the reason to use it. 5. You need reviewable conclusions, for example for an incident report: REA’s evidence bundles and explicit limitations fit better than a chat transcript. 6. Unknown, possibly hostile samples: either tool, only in a VM without secrets, preferably with read-only tools and no execution features. !Ghidra MCP vs REA and the law: four layers an analysis must clear, authorization, contract, statutory exceptions in the US and Germany, and the tool’s own policy. _AI changes how fast you read, not whether you are allowed to._ When Neither Is the Answer - You have the source. Read the source. - You need ground truth. A decompiler tells you what the code appears to do. A debugger, a test or the vendor’s documentation tells you what it does. - The code is heavily obfuscated or packed. The agent will still produce fluent output, and it will be less trustworthy. Unpack first, with the right tools. - The task is circumvention. No tool here is a licence for that. The Bottom Line Ghidra MCP and REA answer different questions. A Ghidra MCP server answers “how do I let my agent drive the decompiler I already use?”, and three decent open-source projects exist for it. REA answers “how do I let an agent investigate anything compiled or packaged, and make the answer say how much it proves?”, at the price of a broader integration with your agent’s configuration. REA also uses Ghidra when you ask it to, so the two are less rivals than neighbouring layers. What does not change is the shape of the risk. The agent reads untrusted input, the tools can write or execute, a cloud model sees the output, and the law cares about permission and purpose. The best setup is the boring one: a disposable VM, read-only tools, pinned versions, a saved evidence trail and a clear answer to “am I allowed to do this?”. > If you are connecting agents to tools in a team, how an MCP gateway enforces user-level permissions is the control layer that sits above any single server. Sources - REA: GitHub repository, rea.tools, rea-agents on npm - Ghidra: NationalSecurityAgency/ghidra - Ghidra MCP: GhidraMCP, ghidra-mcp, pyghidra-mcp - Law: 17 U.S.C. 1201, UrhG sections 69d, 69e, 69g, GeschGehG section 3, Directive 2009/24/EC _Originally published at alekseialeinikov.com_

Ghidra MCP vs REA: Wie KI-Agenten Software per Reverse Engineering analysieren und was das Setup auf deinem Rechner verändert --- title: Ghidra MCP vs REA: Wie KI-Agenten Software per Reverse Engineering analysieren und was das Setup auf deinem Rechner verändert published: true date: 2026-10-29 08:00:00 UTC tags: ghidramcp,ghidramcpserver,ghidradecompiler,reaagents canonical_url: alekseialeinikov.com --- !Ghidra MCP vs REA: Wie KI-Agenten Software per Reverse Engineering analysieren und was das Setup auf deinem Rechner verändert Ein KI-Agent, der kompilierten Code lesen kann, klingt nach Partytrick, bis man sieht, was er ersetzt: Stunden im Scrollen durch Decompiler-Ausgabe, das Umbenennen von FUN_00401a30 in etwas, das irgendeine Bedeutung hat, und das Nachverfolgen, wer wen aufruft. Heute gibt es zwei Werkzeugfamilien, die diese Arbeit an einen Agenten übergeben. Die erste ist ein wachsender Haufen von Ghidra-MCP-Servern , Brücken, über die Claude, Cursor oder Codex das Open-Source-Reverse-Engineering-Framework der NSA steuern. Die zweite ist ein Neuling namens REA (rea-agents auf npm), der sich als „one MCP for reverse engineering across binaries, applications, and runtime behavior“ beschreibt. Beide werden in einen Topf geworfen, weil am Ende ein Agent eine dekompilierte Funktion anfordert. Sie sind aber nicht dieselbe Art Werkzeug, und sie verändern deinen Rechner nicht auf dieselbe Weise. Dieser Artikel vergleicht sie anhand der Dokumentation, erklärt in einfachen Worten, was jede Schicht tut, geht durch, was das Setup tatsächlich anfasst, und endet mit dem Teil, den die meisten Beiträge auslassen: wo die rechtlichen Grenzen verlaufen. !Ghidra MCP vs REA: Eine versiegelte Black Box bricht auf und gibt lesbaren Pseudocode frei, Ghidra steckt mit einem Kabel an, REA mit einem Kabelbündel, eine Illustration von KI-Reverse-Engineering. Die kurze Antwort - Du willst Ghidras Decompiler im Chat, für native Binärdateien? Nimm eine Ghidra-MCP-Brücke. GhidraMCP ist der einfachste Einstieg, pyghidra-mcp passt zu Headless und Projekten mit mehreren Binärdateien, ghidra-mcp hat die meisten Tools und am meisten zu konfigurieren. - Deine Frage überschreitet Formate? Eine Android-App samt Backend-Verkehr, eine Electron-App, Firmware, WebAssembly. Dafür ist REA gebaut, und Ghidra ist nur eine seiner Engines. - Dir ist wichtig, was bewiesen wurde? REAs Doku macht Belege und Einschränkungen zu Kernelementen. Ein statischer Aufrufgraph wird als statisch bezeichnet, ein leeres Ergebnis nicht als „existiert nicht“ gelesen. - Dir ist ein kleiner Fußabdruck wichtig? Eine Ghidra-Brücke fügt ein Plugin und einen lokalen Port hinzu. REA ändert die globale Konfiguration deines Agenten. Beides ist rückgängig zu machen, keines ist nichts. - Du analysierst unbekannte Malware? Mach das in einer isolierten VM, mit jedem der Werkzeuge, ohne Zugangsdaten auf der Kiste. Warum, steht weiter unten. Was ist ein Ghidra-MCP-Server? Engine, Brücke, Agent Drei Begriffe werden oft vermischt, deshalb lohnt sich die Trennung. Ein Disassembler übersetzt Maschinencode in Assembler-Anweisungen. Ein Decompiler geht einen Schritt weiter und rekonstruiert aus diesen Anweisungen C-ähnlichen Pseudocode. Dieser Pseudocode lässt sich nicht einfach kompilieren und ist nicht der Originalquelltext: Namen fehlen, Typen sind geraten, Schleifen sind erschlossen. Das wird später wichtig. Ghidra ist die Engine, und ihr Decompiler ist der Teil, auf den sich ein KI-Agent am meisten stützt. Es ist ein Software-Reverse-Engineering-Framework (SRE), das von der NSA Research Directorate entwickelt und gepflegt wird, mit Disassemblierung, Assemblierung, Dekompilierung, Graphen und Skripting, Unterstützung für viele Prozessor-Befehlssätze und Dateiformate sowie interaktivem und automatisiertem Betrieb. Erweitern lässt es sich in Java oder Python. MCP (Model Context Protocol) ist der Stecker, über den ein Agent Tools aufruft. Falls die Idee neu ist: Der Artikel zum MCP-Gateway erklärt, warum jeder MCP-Server ein Ort ist, an dem ein Agent echte Fähigkeiten erhält. Ein Ghidra-MCP-Server ist deshalb ein Übersetzer zwischen zwei Welten: Der Agent spricht MCP, Ghidra spricht Java und Python. Der Agent sagt „dekompiliere die Funktion an dieser Adresse“, die Brücke fragt Ghidra, Ghidra antwortet, der Agent liest und schlussfolgert. Diese Schleife, einige hundert Mal mit Umbenennungen dazwischen, macht aus FUN_00401a30 ein verify_license_key. Ghidra-MCP-Server im Vergleich: GhidraMCP vs ghidra-mcp vs pyghidra-mcp Wer nach „ghidra mcp“ sucht, findet mehrere Projekte mit ähnlichen Namen. Drei Projekte führen nach GitHub-Sternen, und es gibt kleinere wie mrphrazers ghidra-headless-mcp. Zwei der drei haben diesen Monat Major-Releases veröffentlicht: GhidraMCP 2.0 am 10. Oktober und ghidra-mcp 7.0.0 am 21. Oktober. Sie teilen sich die Engine und unterscheiden sich darin, wie sie sie erreichen. | | GhidraMCP (LaurieWired) | ghidra-mcp (bethington) | pyghidra-mcp (clearbluejar) | | --- | --- | --- | --- | | GitHub-Sterne | rund 11,6k, erstellt März 2025 | rund 6k, erstellt August 2025 | rund 455, erstellt Juli 2025 | | Lizenz | Apache-2.0 | Apache-2.0 | Apache-2.0 | | Aufbau | Ghidra-Plugin plus Python-MCP-Brücke | Neuentwicklung auf dieser Basis: Python-Brücke, HTTP-REST, Java-Plugin | Headless zuerst, Ghidra läuft in derselben JVM über pyghidra und JPype | | Ghidra-GUI nötig | Ja, optionaler Headless-Modus über PyGhidra | Ja für den vollen Tool-Satz, ein Headless-Server mit weniger Endpunkten existiert | Nein, es gibt einen --gui-Modus, aber ein Anhängen an ein laufendes Ghidra ist nicht möglich | | Umfang | Dekompilieren, Methoden und Daten umbenennen, Methoden, Klassen, Importe, Exporte auflisten | 219 MCP-Tools nach eigener Zählung | Projektweite Analyse, semantische Codesuche, Xrefs, Aufrufgraphen | | Transport | stdio und Streamable HTTP | stdio und Streamable HTTP | Streamable HTTP empfohlen | | Voraussetzungen | Ghidra 12.1.4, uv | Ghidra 12.1.4, Java 21, uv | pyghidra, Python | Drei Details aus diesen READMEs solltest du kennen, bevor du dich entscheidest. Die Architektur ist eine Kette, und jedes Glied ist ein Prozess. Bei ghidra-mcp spricht der Agent über stdio oder Streamable HTTP mit einer Python-MCP-Brücke, die Brücke spricht über eine HTTP-REST-API auf localhost Port 8089 mit einem Java-Plugin in Ghidra, und Ghidra analysiert. GhidraMCP nutzt dasselbe Muster mit seinem HTTP-Server auf localhost Port 8080. Praktisch heißt das: Auf deinem Rechner gibt es einen lokalen Netzwerkport, der deine Analysedatenbank lesen und in manchen Tools auch verändern kann. Beide Projekte binden standardmäßig an localhost, und ghidra-mcp verlangt ein Auth-Token (GHIDRA_MCP_AUTH_TOKEN), sobald du an etwas anderes bindest. Mehr Tools ist für den Agenten nicht automatisch besser. ghidra-mcp liefert 219 Tools (das GUI-Plugin bedient 216 davon, der Headless-Server 201). Sein README dokumentiert eine ungewöhnliche Folge: Gemini lehnt das vollständige Tool-Schema mit dem Fehler 400 INVALID_ARGUMENT („too many states“) ab. Deshalb lädt das Projekt Tools standardmäßig lazy, 70 Endpunkte plus 8 statische Tools in den Gruppen listing, function und program, und der Agent holt weitere Gruppen bei Bedarf nach. Das ist ein gutes Beispiel für eine echte Grenze: Jede Tool-Beschreibung kostet Kontext, und jeder Client hat eine Toleranzgrenze. Gefährliche Fähigkeiten sind Opt-in, und das ist die richtige Voreinstellung. Seit Version 5.4.1 von ghidra-mcp sind die Endpunkte zur Skriptausführung aus, solange du nicht GHIDRA_MCP_ALLOW_SCRIPTS setzt, und das README sagt klar, dass sie „execute arbitrary Java against the Ghidra process“. Mit GHIDRA_MCP_FILE_ROOT lässt sich der Dateizugriff einschränken. Weitere Hauptmerkmale laut README: Schreib-Tools für Umbenennen, Typisieren, Strukturen und Kommentare, P-Code-Emulation, Debugger-Anbindung über TraceRmi (nur GUI), malware-orientierte Tools wie detect_malware_behaviors und extract_iocs_with_context, Übertragung von Dokumentation zwischen Binärdateien über Funktions-Hashes, Ghidra-Server-Integration und ein Docker-Headless-Setup. Das README behauptet außerdem „3x more than any competing implementation“ und „93% fewer API calls“ durch Batching. Das sind Eigenangaben des Projekts. pyghidra-mcp denkt in Projekten, nicht in einzelnen Binärdateien. Es kann alle Binärdateien eines Ghidra-Projekts parallel analysieren, durchsucht Code semantisch mit einem ChromaDB-Vektorindex, erzeugt Aufrufgraphen als Mermaid, dekompiliert im Batch und bringt einen CLI-Client und ein Docker-Image mit. Das passt besser zu „hier sind 40 Binärdateien aus einer Firmware, finde die, die die Konfiguration parst“. > „Ghidra MCP“ ist eine Kategorie, kein Produkt. Wähle nach Bauform: Plugin plus GUI (GhidraMCP), maximale Tool-Zahl (ghidra-mcp) oder Headless und projektweit (pyghidra-mcp). Die Engine, und damit die Qualität der Dekompilierung, ist dieselbe. Was ist REA (rea-agents)? Ein MCP für viele Ziele REA (github.com/morluto/rea, Website rea.tools) steht unter MIT-Lizenz und wird als npm-Paket rea-agents verteilt. Es ist ein anderer Werkzeugtyp: ein MCP-Server, ein Kommandozeilenwerkzeug namens rea und ein Agenten-Skill namens reverse-engineer-anything, alles in einem Paket. Das Versprechen ist Breite. Dokumentierte Ziele sind unter anderem: - native Binärdateien, ELF-Layout, Go, Rust und IL2CPP - WebAssembly und EVM-Bytecode - GGUF- und safetensors-Modelldateien, SQLite-Datenbanken - JavaScript- und Electron-Apps (Module, IPC, Source Maps) und Live-Websites über Chrome - HAR- und SAZ-Mitschnitte, Pakete über TShark - .NET-Assemblies, Android-APKs über JADX, ADB, Flutter - Firmware über Binwalk und Unblob, PyInstaller-Bündel - Prozessverhalten zur Laufzeit Für nativen Code erfindet REA den Decompiler nicht neu, sondern ruft einen auf: Ghidra 12.x (ab 12.1) mit einem vollständigen 64-Bit-JDK, Hopper (kommerziell), IDA oder Kuna, dazu objdump und Rizin. Es verlangt eine vorhandene Ghidra-Installation und installiert Ghidra nie selbst. Das ehrliche Verhältnis lautet also nicht „REA gegen Ghidra“, sondern „REA auf Ghidra, neben anderen“. Wenn du REAs Ghidra-Provider auf eine Binärdatei richtest, bekommst du so oder so Ghidras Decompiler. Was REA unterscheidet, ist weniger die Werkzeugliste als der Vertrag, den es jeder Antwort auferlegt. Die Doku zur nativen Analyse wiederholt dieselbe Disziplin an vielen Stellen: - Ein Ergebnis trägt Evidence (Belege) und ausdrückliche Limitations. Unbekannt heißt unbekannt, nicht falsch. - „An empty Hopper inventory cannot establish that no such call exists.“ - Ein statischer Aufrufpfad „does not establish runtime reachability“. - Decompiler-Pseudocode gilt nie als Originalquelltext. - Vom Analysator aufgezählte statische Referenzen „are not observed runtime reads or writes“. Für einen Agenten ist dieser Vertrag der Kern. Sprachmodelle wollen eine saubere Antwort geben. Ein Werkzeug, dessen Ausgabe sagt „das ist eine statische Beobachtung, Vollständigkeit unbekannt“, lässt dem Modell weniger Spielraum zum Übertreiben und gibt dir etwas zum Nachprüfen. Speziell auf der Ghidra-Seite ist REAs Adapter bewusst konservativ. Er bietet 27 Operationen, alle schreibgeschützt: 15 für Inventar, Namen und Suche, 12 für Funktionsanalyse. Das Ziel wird in einem flüchtigen Projekt geöffnet (-readOnly -deleteProject), und Umbenennungen und Kommentare sind Sitzungs-Metadaten, die beim Schließen der Sitzung verworfen werden. Die Standard-Startfrist beträgt 330 Sekunden. Windows-Unterstützung ist als experimentell markiert. Wenn das nach einem Kompromiss klingt, ist es einer: Du gibst Ghidras volle Schreibfläche für eine kleinere, prüfbare auf. REAs Showcase-Beispiele zeigen den gedachten Stil: herausfinden, warum die Geschwindigkeit im Chrome-Dino-Spiel bei 6 beginnt und steigt, solange sie unter 13 liegt, die %-Taste des Windows-Rechners nachverfolgen (200 + 10 % = 220), die Zwischenablagen-Brücke einer Electron-App rekonstruieren, 63 kompilierte Funktionsbytes einer DX-Ball-Soundroutine gegen 3.205 Original-x86-Testfälle reproduzieren. Das sind Demonstrationen des Projekts, keine unabhängigen Ergebnisse. Kurz zu REAs Zahlen. GitHub zeigt rund 404.000 Sterne für ein im April angelegtes Repository, und npm hat seit dem 12. Juli 34 Releases (6.8.0 am 25. Oktober). Wie die Sterne zusammenkamen, lässt sich nicht prüfen, beurteile REA also nach Doku und Code. Es ist außerdem im Kern ein Ein-Personen-Projekt, rund 3.800 von etwa 6.200 Commits stammen von einem Entwickler, also pinne die Version, die du getestet hast. Ghidra MCP vs REA im direkten Vergleich !Ghidra MCP vs REA Architektur: Eine Ghidra-Brücke verbindet den Agenten über eine Python-Brücke, einen lokalen HTTP-Port und ein Plugin mit einer Ghidra-Engine; REA verbindet ihn mit einem MCP-Server und Provider-Adaptern für Ghidra, Hopper, IDA, JADX, Chrome und mehr und liefert Evidence mit Limitations zurück. _Eine Engine hinter einer Brücke oder eine Werkbank hinter einem Server._ | | Ghidra-MCP-Brücken | REA | | --- | --- | --- | | Was es ist | Adapter zwischen Agent und Ghidra | MCP-Server, CLI und Skill über viele Engines | | Ziele | Was Ghidra importiert: native Binärdateien, viele Architekturen | Nativ, Android, JS und Electron, .NET, Firmware, WASM, Pakete, Laufzeit und mehr | | Decompiler | Ghidra | Ghidra, Hopper, IDA oder Kuna für nativen Code | | Schnittstelle zur Engine | Plugin plus lokales HTTP, oder Headless über PyGhidra | Provider-Adapter, Ghidra in einem flüchtigen, schreibgeschützten Projekt | | Schreibzugriff | Ja: umbenennen, Typen setzen, kommentieren, Strukturen, je nach Projekt | Ghidra-Adapter schreibgeschützt; Annotationen leben in einer temporären Sitzung | | Skripte | Endpunkte zur Skriptausführung vorhanden, bei ghidra-mcp standardmäßig aus | Laut Doku nicht Teil des beschriebenen Ghidra-Adapters | | Rahmung der Ergebnisse | Rohe Tool-Ausgabe, der Agent deutet | Evidence, Abdeckung und Limitations bei jedem Ergebnis | | Laufzeitanalyse | ghidra-mcp: Emulation und ein Debugger nur in der GUI | Opt-in-Laufzeitmitschnitt; LLDB-Aufrufbeobachtung startet einen eigenen Prozess | | Installationsaufwand | Ghidra installieren, Erweiterung oder Python-Paket, Versionen abstimmen | npx rea-agents setup plus vorhandenes Ghidra für native Analyse | | Reife-Signal | Drei unabhängige Projekte, das älteste von März 2025 | Ein Projekt, erstes Release Juli 2026, hohe Release-Frequenz | | Lizenz | Apache-2.0 (GhidraMCP, ghidra-mcp) | MIT | So funktioniert KI-Reverse-Engineering: Was der Agent tatsächlich tut Beide Familien teilen dieselbe Schleife. Nur die Befehle unterscheiden sich. Mit einer Ghidra-Brücke arbeitet der Agent wie ein Mensch im CodeBrowser. Er listet Funktionen, Importe und Strings auf, dekompiliert die interessanten, folgt Querverweisen, benennt um, was er versteht, und schreibt Kommentare. Weil die Schreibvorgänge in der offenen Ghidra-Datenbank landen, hinterlässt eine gute Sitzung ein annotiertes Projekt, das du danach öffnen kannst. Mit REA ist der dokumentierte native Ablauf ausdrücklich darauf bedacht, exakte Namen zu wählen. Aus der Doku, mit dem Ghidra-Provider: _Terminal window_ rea inspect /absolute/path/to/program --provider ghidra --json rea search /absolute/path/to/program entry --kind procedures --provider ghidra --json rea function /absolute/path/to/program <procedure> --provider ghidra --json rea decompile /absolute/path/to/program <procedure> --provider ghidra <button title="Copy to clipboard" data-copied="Copied!" data-code="rea inspect /absolute/path/to/program --provider ghidra --jsonrea search /absolute/path/to/program entry --kind procedures --provider ghidra --jsonrea function /absolute/path/to/program &lt;procedure&gt; --provider ghidra --jsonrea decompile /absolute/path/to/program &lt;procedure&gt; --provider ghidra"><div></div></button> Die Doku ergänzt einen leicht zu übersehenden, für das Projekt typischen Hinweis: Nimm nicht an, dass jedes Ziel seine Einstiegsfunktion entry nennt, sondern wähle einen exakten Namen oder eine Adresse aus dem zurückgelieferten Inventar. Über MCP ist es derselbe Ablauf mit open_binary, danach fokussierte Tools wie list_procedures und analyze_function in derselben Sitzung. Darüber hinaus: - batch_decompile liest mehrere Funktionen auf einmal, und decompile_all schreibt pro Funktion eine Pseudocode-Datei plus ein Manifest, das Zählungen, aber keinen Code enthält. - search_bytes findet maskierte Byte-Muster und sagt, was es nicht durchsucht hat, etwa nicht initialisierte Blöcke. - trace_native_values baut Def-Use-Graphen aus dem High-P-Code des Decompilers über statisch aufgelöste Aufrufe hinweg. - export_evidence_bundle bewahrt die Beobachtungen auf, sodass eine Schlussfolgerung später geprüft werden kann, ohne dem Chat zu vertrauen. Der letzte Punkt ist die stille Stärke. Das Protokoll eines Agenten, der sagt „diese Funktion prüft einen Lizenzschlüssel“, ist eine Behauptung. Ein Evidence-Bundle mit Adressen, Referenzen und Limitations dahinter kann eine zweite Person prüfen. Ghidra MCP und REA einrichten: Was sich auf deinem Rechner ändert Das ist der Abschnitt, den die meisten Vergleiche überspringen und der entscheiden sollte, ob du etwas ausprobierst. Alles Folgende stammt aus der Doku der Projekte. Ghidra-Brücken Typischer Ablauf: ein JDK und genau die Ghidra-Version installieren, für die die Erweiterung gebaut wurde (die READMEs nennen Ghidra 12.1.4), das Plugin-ZIP über File, Install Extensions einspielen, in der Konfiguration aktivieren, Ghidra neu starten und dann den MCP-Server beim Client registrieren, zum Beispiel mit uvx --from git+https://github.com/LaurieWired/GhidraMCP ghidra-mcp --ghidra-server http://127.0.0.1:8080/. Was sich ändert: - ein Plugin in Ghidra, das nur in genau der Ghidra-Version lädt, für die es gebaut wurde - ein lokaler HTTP-Server auf festem Port, solange Ghidra läuft - ein Eintrag in der MCP-Konfiguration deines Agenten - ein Python-Prozess, der bei Bedarf startet, wobei uvx zur Laufzeit Code von einer Git-URL holt, was du auf einen Commit oder Tag pinnen solltest Beachte eine Versionsspannung: Das Ghidra-README für den aktuellen Master-Branch verlangt JDK 25, während die Brücken-Projekte Ghidra 12.1.4 und Java 21 dokumentieren. Richte dich nach dem README der Brücke, nicht nach dem neuesten Ghidra. REA npx rea-agents setup ist der dokumentierte Einstieg. Laut Installationsdoku: 1. Es gibt zuerst einen Plan aus, der Konfigurationspfade, Skill-Ziele, mögliche externe Software, Netzwerk-Ursprünge, Integritätsnachweise und Paketmanager-Befehle auflistet. 2. Es schreibt nichts, bis du freigibst. Die Freigabe des Plans ist getrennt von deiner Freigabe des npm-Downloads selbst. 3. Es legt vor dem Bearbeiten .rea.backup-Kopien der Konfigurationsdateien an, bewahrt fremde Einträge und blockiert die gesamte Transaktion, wenn eine Konfiguration fehlerhaft ist, statt zu raten. 4. Für Claude Code registriert es mcpServers.rea in ~/.claude.json und installiert den Skill in ~/.claude/skills/reverse-engineer-anything. Die Clients wählst du in einer Mehrfachauswahl. Vorhandene REA-Registrierungen sind vorausgewählt, neu erkannte Clients nicht, denn Erkennung liefert dem Setup Kontext, keine Erlaubnis. Der Skill wird standardmäßig installiert, mit --skill=false lässt du ihn weg. Wenn du Claude Desktop nutzt, beende es vor der Freigabe vollständig, weil eine laufende App die Registrierung überschreiben kann. Unterstützt werden mehr als zwei Dutzend Client-Kennungen, darunter Claude Code und Desktop, Codex, Cursor, Gemini CLI, Windsurf, VS Code, Copilot CLI und OpenCode, dazu gibt es einen Plugin-Weg (/plugin marketplace add morluto/rea) und einen MCP-Registry-Eintrag, io.github.morluto/rea. Was Aufmerksamkeit verdient, wieder direkt aus der Doku: - Die Registrierung ist global. Für Claude Code gelten Eintrag und Skill für jedes Projekt. Die Doku beschreibt, wie man das mit einem separaten CLAUDE_CONFIG_DIR-Profil oder einem lokalen Scope begrenzt, und sagt offen, dass ein Agent unter demselben OS-Konto weiterhin rea oder npx ausführen und Dateien lesen kann. - Es registriert einen absoluten Pfad zu node und zum Einstiegsskript, der npx-Cache muss also bestehen bleiben. - Das Installationsskript wird nicht per Signatur geprüft. Die Doku sagt es selbst: „Neither command verifies a signature on the downloaded script.“ Sie zeigt einen sichereren Ablauf: das Skript von einem gepinnten Tag laden, mit less lesen und dann mit passendem --version ausführen. Oder du nimmst den npm-Weg. - Starte Paket-Runner aus einem vertrauenswürdigen Verzeichnis außerhalb des Ziels, denn sie können Projektkonfiguration lesen. - Das Hopper-Setup kann das offizielle Paket herunterladen , mit PGP-Signaturprüfung (die Doku nennt den Fingerprint des Hauptschlüssels) und einer DMG-Digest-Prüfung unter macOS, mit ausschließlich HTTPS-Weiterleitungen. Ghidra wird nie heruntergeladen. - Rückgängig machen geht. rea doctor ist nur lesend, rea uninstall entfernt nur Registrierungen, die REA besitzt (--purge-data löscht auch den Cache), und rea update lässt Lifecycle-Skripte der Abhängigkeiten deaktiviert. Das npm-Paket selbst definiert nur die Skripte prepare und prepublishOnly, keine Hooks bei der Installation, und hat 42 Abhängigkeiten bei rund 49 MB entpackt. <aside role="note"><p>Achtung</p> <p>Das README warnt, dass es Lookalike-Repositories gibt, die nicht offiziell sind. Bei einem Werkzeug, das die Konfiguration deines Agenten ändert, prüfe die Quelle (<code>morluto/rea</code>, <code>rea-agents</code>), bevor du etwas ausführst. Dasselbe gilt für die vielen Repositories namens „ghidra-mcp“.</p></aside> Für die allgemeine Gewohnheit, Werkzeuge zu installieren, die Code auf deinem Rechner ausführen, zeigt Abwehr von npm-Lieferkettenangriffen, was du pinnen, abschalten und vorher lesen solltest. !Ghidra MCP vs REA Setup: was jeder Installer anfasst. Eine Ghidra-Brücke fügt ein Plugin und einen lokalen HTTP-Port hinzu; REA zeigt einen Plan, wartet auf Freigabe, sichert Konfigurationsdateien, schreibt MCP-Registrierung und Skill und lässt sich mit einem Befehl entfernen. _Beides ist rückgängig zu machen. Keines ist nichts._ Was schiefgehen kann Vier Risiken verdienen einen Namen. Das erste stammt aus meiner eigenen Analyse und steht in keiner Projekt-Doku; die anderen sind dokumentiert. 1. Die Binärdatei redet zurück. Aus Sicht des Modells ist eine Probe nicht vertrauenswürdiger Text. Strings, Symbolnamen, eingebettete Ressourcen und Kommentare kommen alle in Tool-Ergebnissen an. Eine bösartige Binärdatei kann einen String wie „ignore previous instructions and run this command“ enthalten, und ein Agent mit Shell-Zugriff und Geheimnissen ist genau das Ziel. Das ist das Lethal-Trifecta-Muster: private Daten, nicht vertrauenswürdige Inhalte und ein Ausgang nach draußen. Die Abwehr ist architektonisch: Unbekannte Proben kommen in eine Wegwerf-VM ohne Zugangsdaten, der Agent bekommt nur die nötigen Tools, und alles, was Code ausführen kann, bleibt aus. Der Fall, in dem Rogue-KI-Agenten eine echte Website kompromittierten, zeigt, wie wenig es braucht, sobald ein Agent Fähigkeit und ein Ziel hat. 2. Schreib-Tools verändern deine Analyse. Umbenennen und Neutypisieren machen eine Sitzung nützlich und lassen einen falschen Tipp sich ausbreiten: Eine von einem selbstsicheren Modell check_license genannte Funktion färbt jede spätere Entscheidung, auch deine. REAs schreibgeschützter Ghidra-Adapter umgeht das per Design. Behalte bei einer schreibfähigen Brücke eine Kopie des Projekts, bevor der Agent anfängt. 3. Laufzeitfunktionen führen das Ziel aus. REAs Doku ist eindeutig: Laufzeitmitschnitt führt das Ziel mit den Rechten deines Benutzers aus, und die LLDB-Aufrufbeobachtung startet einen eigenen Prozess, der „may change files, show UI or use the network“. Die Erlaubnis, eine Datei zu untersuchen, „does not necessarily authorize execution“. Nimm auch hier eine VM. 4. Der Modellanbieter sieht, was die Tools zurückgeben. REAs Doku sagt, die Analyse laufe lokal und „your agent receives the tool results, and its model provider has its own data policy“. Das heißt: Dekompilierter Code verlässt deinen Rechner, sobald er im Kontext eines Cloud-Modells landet. Bei proprietärer oder vertraglich beschränkter Software ist das erst eine rechtliche und vertrauliche Frage und dann eine technische. Ist Reverse Engineering legal? <aside role="note"><p>Achtung</p> <p>Dies ist eine Zusammenfassung öffentlicher Gesetzestexte, keine Rechtsberatung. Das Recht unterscheidet sich nach Land, Vertrag und Einzelfall. Wenn eine Entscheidung zählt, frag eine Juristin oder einen Juristen, die oder der Software- und IP-Recht in deinem Land kennt.</p></aside> Nützlich ist es, in vier Schichten zu denken, und eine Handlung muss alle passieren. | Schicht | Die Frage | Was die Quellen sagen | | --- | --- | --- | | Erlaubnis | Gehört es dir, oder hast du die Erlaubnis? | REAs Disclaimer: öffentliche Verfügbarkeit, Besitz einer Datei oder Zugang zu einem Debugging-Endpunkt „does not by itself establish permission for every operation“. US 17 U.S.C. 1201(j) definiert Sicherheitstests als Tests in gutem Glauben „with the authorization of the owner or operator“. | | Vertrag | Was sagen Lizenz oder EULA? | Deutschland: Vertragsbestimmungen, die zu § 69d Abs. 2, 3, 5, 7 oder zu § 69e UrhG im Widerspruch stehen, sind nichtig (§ 69g Abs. 2). Die US-Lage zu EULA-Beschränkungen wurde für diesen Artikel nicht recherchiert. | | Urheberrecht und Zugriffskontrollen | Gibt es eine gesetzliche Ausnahme? | US 1201(f) für Interoperabilität; Deutschland § 69e für Dekompilierung und § 69d Abs. 3 für das Untersuchen eines Programms; EU-Richtlinie 2009/24/EG hinter den deutschen Regeln. | | Regeln des Werkzeugs | Wobei hilft das Werkzeug nicht? | REA hilft nicht bei DRM- oder Lizenzumgehung, Spiele-Cheats, dem Umgehen von Zugriffskontrollen, dem Kopieren proprietären Codes oder dem Umgehen der Nutzungsregeln von KI-Anbietern. | USA. Section 1201 des Copyright Act betrifft die Umgehung technischer Schutzmaßnahmen, die den Zugang zu einem Werk kontrollieren. Die Reverse-Engineering-Ausnahme 1201(f) erlaubt jemandem, der rechtmäßig das Recht erlangt hat, eine Kopie eines Computerprogramms zu nutzen, eine solche Maßnahme zu umgehen „for the sole purpose of identifying and analyzing those elements of the program that are necessary to achieve interoperability of an independently created computer program with other programs“, sofern diese Elemente nicht schon leicht zugänglich waren, „to the extent any such acts of identification and analysis do not constitute infringement“. Die Werkzeuge dafür und die gewonnenen Informationen dürfen nur zur Interoperabilität weitergegeben werden. Davon getrennt sagt 1201(c)(1), dass der Abschnitt Fair Use und andere Verteidigungen gegen den Vorwurf der Verletzung nicht berührt. Beachte, was das nicht ist: eine allgemeine Erlaubnis, beliebiges zu beliebigem Zweck zu disassemblieren. Deutschland und EU. Die deutschen Regeln setzen die EU-Computerprogramm-Richtlinie 2009/24/EG um, die die ursprüngliche Richtlinie von 1991 ersetzt hat. § 69d Abs. 3 UrhG sagt, dass der zur Verwendung einer Programmkopie Berechtigte das Funktionieren des Programms „beobachten, untersuchen oder testen“ kann, um die einem Programmelement zugrundeliegenden Ideen und Grundsätze zu ermitteln, wenn dies durch Handlungen zum Laden, Anzeigen, Ablaufen, Übertragen oder Speichern geschieht, zu denen er berechtigt ist. § 69e erlaubt die Dekompilierung ohne Zustimmung des Rechtsinhabers nur, wenn die Vervielfältigung des Codes oder die Übersetzung der Codeform unerlässlich ist, um die für die Interoperabilität eines unabhängig geschaffenen Programms erforderlichen Informationen zu erhalten, und nur wenn: die Handlungen vom Lizenznehmer oder einer anderen berechtigten Person vorgenommen werden; die Informationen nicht bereits ohne Weiteres zugänglich sind; und die Handlungen auf die notwendigen Programmteile beschränkt bleiben. Die Informationen dürfen nicht zu anderen Zwecken verwendet, nicht über das für die Interoperabilität Notwendige hinaus weitergegeben und nicht für ein Programm mit im Wesentlichen ähnlicher Ausdrucksform genutzt werden. Und § 69g Abs. 2 erklärt Vertragsbestimmungen, die § 69e widersprechen, für nichtig, eine EULA kann also nicht einfach verbieten, was das Gesetz erlaubt. Das Geheimnisschutzrecht geht in dieselbe Richtung: Nach § 3 Abs. 1 Nr. 2 des Geschäftsgeheimnisgesetzes (GeschGehG) darf ein Geschäftsgeheimnis durch Beobachten, Untersuchen, Rückbauen oder Testen eines Produkts erlangt werden, das öffentlich verfügbar gemacht wurde oder sich in deinem rechtmäßigen Besitz befindet, solange du keiner Pflicht zur Beschränkung unterliegst. Was das praktisch bedeutet, als Lesehilfe und nicht als Beratung: - Die Analyse eigener Software oder von Malware-Proben im Labor ist der übliche, unstrittige Fall. Der Agent ändert die Geschwindigkeit, nicht den Status. - Interoperabilität hat in beiden Systemen ausdrückliche gesetzliche Unterstützung, mit Bedingungen an Notwendigkeit und an den Umgang mit dem Gelernten. - Sicherheitstests brauchen die Erlaubnis des Eigentümers, im US-Text wie in REAs eigener Regel. - Das Umgehen von DRM, Lizenzprüfungen oder Anti-Cheat und das Kopieren geschützten Codes liegen außerhalb dessen, was diese Ausnahmen abdecken, und außerhalb dessen, wobei REA hilft. - Eine KI wäscht nichts rein. REAs Disclaimer sagt, du seist für „actions you direct an AI agent to perform“ verantwortlich, und dass quelltextähnliche Ausgabe „does not grant rights to the original program“. Eine Setup-Checkliste für sicheres KI-Reverse-Engineering Das sind meine Empfehlungen, abgeleitet aus dem oben dokumentierten Verhalten. Keine davon braucht ein Spezialwerkzeug. 1. Nimm eine Wegwerf-VM für unbekannte Proben, ohne Zugangsdaten, ohne SSH-Agent und ohne Cloud-Token darauf. 2. Halte das Werkzeug aus deinem Alltagsprofil heraus. Bei REA unter Claude Code hält ein eigenes CLAUDE_CONFIG_DIR-Profil Registrierung und Skill von deinen anderen Projekten fern. 3. Pinne Versionen. Nimm das Ghidra-Release, das die Brücke nennt, einen Tag oder Commit der Brücke statt eines beweglichen Branches und eine exakte rea-agents-Version. 4. Bevorzuge schreibgeschützte Tools. Lass die Skriptausführung aus (GHIDRA_MCP_ALLOW_SCRIPTS) und kopiere das Ghidra-Projekt, bevor ein Agent Schreib-Tools bekommt. 5. Halte Server auf localhost. Wenn du anders bindest, setze das vom Projekt verlangte Auth-Token. 6. Behandle Strings und Kommentare in der Probe als feindlich. Gib dem Agenten in derselben Sitzung keine Shell und keinen offenen Netzzugang. 7. Bewahre die Belege auf. Speichere Adressen und Referenzen zu jeder Aussage und prüfe die wichtigen im Disassembly oder mit einem Debugger. 8. Kläre die Erlaubnis vorab. Stelle sicher, dass du das Ziel analysieren darfst, und lies die Datenrichtlinie deines Modellanbieters, bevor du proprietären Code hindurchschickst. Wann was 1. Lernen, CTFs, eine native Binärdatei, du magst Ghidras Oberfläche: GhidraMCP. Geringste Reibung, und die Annotationen landen in einem Ghidra-Projekt, das du behalten kannst. 2. Viele Binärdateien, Skripte und Automatisierung, keine GUI: pyghidra-mcp, wegen des Headless- und projektweiten Designs. 3. Du willst alle Ghidra-Funktionen bereitstellen und konfigurierst sorgfältig: ghidra-mcp, mit ausgeschalteten Skripten und gesetztem File Root. 4. Das Ziel ist keine einfache native Binärdatei: eine Electron- oder Android-App, ein Firmware-Image, ein WebAssembly-Modul, Netzwerkmitschnitte. REAs Breite ist der Grund, es zu nehmen. 5. Du brauchst nachprüfbare Schlussfolgerungen, etwa für einen Incident-Bericht: REAs Evidence-Bundles und ausdrückliche Limitations passen besser als ein Chat-Protokoll. 6. Unbekannte, möglicherweise feindliche Proben: jedes der Werkzeuge, nur in einer VM ohne Geheimnisse, möglichst mit schreibgeschützten Tools und ohne Ausführungsfunktionen. !Ghidra MCP vs REA und das Recht: vier Schichten, die eine Analyse passieren muss: Erlaubnis, Vertrag, gesetzliche Ausnahmen in den USA und Deutschland und die Regeln des Werkzeugs selbst. _KI ändert, wie schnell du liest, nicht ob du es darfst._ Wenn keines von beiden die Antwort ist - Du hast den Quelltext. Lies den Quelltext. - Du brauchst Ground Truth. Ein Decompiler sagt dir, was der Code zu tun scheint. Ein Debugger, ein Test oder die Dokumentation des Herstellers sagt dir, was er tut. - Der Code ist stark verschleiert oder gepackt. Der Agent liefert trotzdem flüssige Ausgabe, und sie ist weniger vertrauenswürdig. Entpacke zuerst, mit den richtigen Werkzeugen. - Die Aufgabe ist Umgehung. Kein Werkzeug hier ist eine Lizenz dafür. Das Fazit Ghidra MCP und REA beantworten verschiedene Fragen. Ein Ghidra-MCP-Server beantwortet „wie lasse ich meinen Agenten den Decompiler steuern, den ich ohnehin nutze?“, und dafür gibt es drei brauchbare Open-Source-Projekte. REA beantwortet „wie lasse ich einen Agenten alles Kompilierte oder Gepackte untersuchen und sorge dafür, dass die Antwort sagt, wie viel sie beweist?“, zum Preis einer breiteren Integration in die Konfiguration deines Agenten. REA nutzt außerdem Ghidra, wenn du es verlangst, die beiden sind also weniger Rivalen als benachbarte Schichten. Was sich nicht ändert, ist die Form des Risikos. Der Agent liest nicht vertrauenswürdige Eingaben, die Tools können schreiben oder ausführen, ein Cloud-Modell sieht die Ausgabe, und das Recht fragt nach Erlaubnis und Zweck. Das beste Setup ist das langweilige: eine Wegwerf-VM, schreibgeschützte Tools, gepinnte Versionen, ein gesicherter Beleg-Pfad und eine klare Antwort auf „darf ich das?“. > Wenn du Agenten im Team mit Tools verbindest: Wie ein MCP-Gateway benutzerbezogene Berechtigungen durchsetzt ist die Kontrollschicht, die über jedem einzelnen Server sitzt. Quellen - REA: GitHub-Repository, rea.tools, rea-agents auf npm - Ghidra: NationalSecurityAgency/ghidra - Ghidra MCP: GhidraMCP, ghidra-mcp, pyghidra-mcp - Recht: 17 U.S.C. 1201, UrhG §§ 69d, 69e, 69g, GeschGehG § 3, Richtlinie 2009/24/EG _Ursprünglich veröffentlicht auf alekseialeinikov.com_

Ghidra MCP: Let AI Help You Reverse Engineer Binaries Originally published at GeekCoding101. Reverse Engineering Meets AI Reverse engineering is slow, careful work. You open a stripped binary in Ghidra, stare at FUN_100000db8, read the decompiled C, guess what it does, rename it, add a comment, and repeat a few hundred times. It's the kind of work that's perfect for an AI assistant, as long as the assistant can actually see and touch the Ghidra project. That's what GhidraMCP does. It's an open-source MCP server by LaurieWired (Apache-2.0) that exposes Ghidra's core features as tools, so Claude, Cursor, VS Code Copilot or any other MCP client can decompile functions, follow cross-references, rename things and leave comments, inside a real Ghidra project. In this post I install the whole stack from scratch on an Apple Silicon Mac, compile a real open-source program, strip it, and use GhidraMCP to find and name its checksum and gzip functions. Every screenshot below is real output from that run, including the parts that didn't go smoothly. > Only analyze software you are allowed to analyze: your own binaries, open-source builds like the one in this post, CTF crackmes, or malware samples inside an isolated VM for defensive research. Reverse engineering commercial software may be restricted by its license or by law where you live. How GhidraMCP Works GhidraMCP has two parts: 1. A Ghidra extension (GhidraMCPPlugin) that runs inside Ghidra and starts a small HTTP server on loopback, by default http://127.0.0.1:8080/. 2. A Python MCP server (ghidra-mcp) that your AI app launches. It speaks MCP to the AI app and turns each tool call into an HTTP request to the extension. !GhidraMCP architecture: the AI app talks MCP over stdio to the ghidra-mcp Python server, which calls the GhidraMCPPlugin inside Ghidra over HTTP on localhost port 8080 There are two ways to run it: - GUI mode: you open the program in Ghidra's CodeBrowser, the plugin serves it, and every rename or comment the AI makes appears in your Ghidra window right away (and can be undone like any other edit). - Headless mode: ghidra-mcp --headless --binary <file> starts Ghidra in-process through PyGhidra, imports and analyzes the file, and serves it through the same Java backend on a random loopback port. No GUI, which makes it easy to script and to run on a server or in a throwaway VM. The tools are the same in both modes. I use headless mode for the walkthrough because it's fully reproducible from a terminal, and then open the saved project in the GUI to look at the result. What I Used | Piece | Version | Where it came from | | --- | --- | --- | | Mac | Apple Silicon, macOS 26.6 | | | Ghidra | 12.1.4 (ghidra_12.1.4_PUBLIC_20260921.zip) | NationalSecurityAgency/ghidra releases | | JDK | Temurin 21.0.12.1+1 (aarch64) | adoptium/temurin21-binaries releases (brew install openjdk@21 works too) | | GhidraMCP | release 2.0 (2026-10-10): extension ghidra_12.1.4_PUBLIC_20261010_GhidraMCP.zip + Python package ghidra-mcp 2.0.0 | LaurieWired/GhidraMCP releases | | uv / Python | uv 0.12.3, Python 3.13 (headless mode needs 3.10 to 3.13) | Homebrew / uv-managed | | MCP client | Python mcp SDK 2.3.0 | PyPI | | Target | minigzip from zlib 1.3.2 (zlib license), built with Apple clang 21 | zlib GitHub release | Check the downloads before you unpack them. GitHub shows a SHA-256 for every release asset, and shasum -a 256 <file> should print the same value. For the Ghidra zip above it's ddac49f9…87d2d4db. Install, Step by Step Step 1: Unpack Ghidra and Give It Java 21 Unzip Ghidra and the JDK into their own folders (I use ~/tools/). Ghidra finds Java through JAVA_HOME or asks for the JDK path on first start: export JAVA_HOME=~/tools/jdk-21.0.12.1+1/Contents/Home ~/tools/ghidra_12.1.4_PUBLIC/ghidraRun Step 2: Build the Native Decompiler (macOS and Linux ARM Only) This is the first thing that trips people up on a Mac. The official release ships native binaries (the decompiler, the SLEIGH compiler, the demanglers) only for Windows and Linux x86-64. On Apple Silicon the os/ folder simply has no mac_arm_64 entry, and decompiling fails until you build them yourself. You need the Xcode command line tools (xcode-select --install). Run Gradle from support/gradle, not from the Ghidra root. From the root you get Directory '…/ghidra_12.1.4_PUBLIC' does not contain a Gradle build. !Terminal: the Decompiler os folder only has linux_x86_64 and win_x86_64; gradlew buildNatives in support/gradle detects mac_arm_64, builds the decompile and sleigh executables and finishes with BUILD SUCCESSFUL The Gradle wrapper downloads Gradle on first use, so this step needs internet once. Step 3: Install the GhidraMCP Extension Another small trap: the file you download from the GhidraMCP releases page, GhidraMCP-release-2-0.zip, is a wrapper. Unzip it first. Inside are three files: GhidraMCP-release-2-0/ ghidra_12.1.4_PUBLIC_20261010_GhidraMCP.zip <- the Ghidra extension ghidra_mcp-2.0.0-py3-none-any.whl <- the Python MCP server ghidra_mcp-2.0.0.tar.gz Then, in Ghidra: 1. File → Install Extensions, click +, and pick the inner ghidra_12.1.4_PUBLIC_20261010_GhidraMCP.zip. 2. Restart Ghidra. 3. Open a program in the CodeBrowser. Ghidra notices the new extension and asks whether to configure it: !Ghidra project window with the dialog New Plugins Found: New extension plugins detected. Would you like to configure them? with Yes and No buttons 4. Click Yes and tick GhidraMCPPlugin (description "GhidraMCP backend"): !The New Plugins Found list with GhidraMCPPlugin ticked, description GhidraMCP backend, category Analysis If you clicked No, you can enable it later under File → Configure in the CodeBrowser. Once it's on, Ghidra's application.log shows GhidraMCP backend listening on 127.0.0.1:8080. The extension version must match your Ghidra version exactly (version=12.1.4 in its extension.properties). Ghidra copies it to ~/Library/ghidra/ghidra_12.1.4_PUBLIC/Extensions/GhidraMCP/ on macOS, which is also where headless mode looks for it. Port 8080 already taken? It was on my machine: an SSH port forward was listening on 8080. Check with lsof -nP -iTCP:8080 -sTCP:LISTEN. If something is there, change Edit → Tool Options → GhidraMCP HTTP Server → Server Port in Ghidra and point the MCP server at the new port with --ghidra-server http://127.0.0.1:<port>/. Headless mode doesn't have this problem because it picks a free port. If the Python side can't reach the plugin, it doesn't fail at startup. It only logs a warning, and every tool call fails later: WARNING:ghidra_mcp:GhidraMCP backend at http://127.0.0.1:8089/ is not reachable yet; tools will fail until Ghidra is running with the plugin enabled. So if your AI app shows the Ghidra tools but every call errors, look at this line in the MCP server's log first. Step 4: Connect Your MCP Client GUI mode, Claude Code: claude mcp add ghidra -- uvx --from git+https://github.com/LaurieWired/GhidraMCP ghidra-mcp --ghidra-server http://127.0.0.1:8080/ GUI mode, Claude Desktop, Cursor and most other clients (JSON config): { "mcpServers": { "ghidra": { "command": "uvx", "args": [ "--from", "git+https://github.com/LaurieWired/GhidraMCP", "ghidra-mcp", "--ghidra-server", "http://127.0.0.1:8080/" ] } } } VS Code (.vscode/mcp.json): the same command under a servers key with "type": "stdio". Headless mode needs GHIDRA_INSTALL_DIR, a Java 21 JAVA_HOME, Python 3.13 and the headless extra: { "mcpServers": { "ghidra": { "command": "uvx", "args": [ "--python", "3.13", "--from", "ghidra-mcp[headless] @ git+https://github.com/LaurieWired/GhidraMCP", "ghidra-mcp", "--headless", "--binary", "/Users/you/tools/ghidra-demo/minigzip", "--project", "/Users/you/tools/ghidra-demo/proj" ], "env": { "JAVA_HOME": "/Users/you/tools/jdk-21.0.12.1+1/Contents/Home", "GHIDRA_INSTALL_DIR": "/Users/you/tools/ghidra_12.1.4_PUBLIC" } } } } With this config Claude Code connected and listed all 28 tools as mcp__ghidra__*. --project keeps the Ghidra project between runs and saves the AI's renames when the session ends. Without it you get a temporary project that's thrown away. If your client only accepts a URL, run the server yourself with --transport streamable-http --mcp-host 127.0.0.1 --mcp-port 8081 and add http://127.0.0.1:8081/mcp. Hands-On: Find zlib's Checksums in a Stripped Binary The Target minigzip is the small gzip clone in zlib's test/ folder. It's a good practice target: it's open source, so you can check every answer against the source, and it statically links the whole compression library, so there's plenty to find. I built it with zlib's own makefile and stripped all symbols: curl -LO https://github.com/madler/zlib/releases/download/v1.3.2/zlib-1.3.2.tar.gz shasum -a 256 zlib-1.3.2.tar.gz # bb329a0a…de64f0119d16, same as the release page tar xzf zlib-1.3.2.tar.gz && cd zlib-1.3.2 ./configure --static && make libz.a minigzip # clang -O3, arm64 cp minigzip ~/tools/ghidra-demo/ && strip ~/tools/ghidra-demo/minigzip nm now shows only the imported libc symbols. The 102 KB arm64 binary still works (./minigzip t.txt makes t.txt.gz, -d restores it), but inside Ghidra every zlib function is just FUN_<address>. The Client You'd normally let Claude, Cursor or VS Code drive the tools. To show exactly which calls happen and what comes back, I wrote a small MCP client with the official Python SDK that starts ghidra-mcp in headless mode and calls the tools one by one, the same way an AI app does. The core of it: import asyncio, json, os from mcp import ClientSession, StdioServerParameters from mcp.client.stdio import stdio_client HOME = os.path.expanduser("~") SERVER = StdioServerParameters( command="uvx", args=["--python", "3.13", "--from", "ghidra-mcp[headless] @ git+https://github.com/LaurieWired/GhidraMCP", "ghidra-mcp", "--headless", "--binary", f"{HOME}/tools/ghidra-demo/minigzip", "--project", f"{HOME}/tools/ghidra-demo/demo-proj"], env={**os.environ, "JAVA_HOME": f"{HOME}/tools/jdk-21.0.12.1+1/Contents/Home", "GHIDRA_INSTALL_DIR": f"{HOME}/tools/ghidra_12.1.4_PUBLIC"}, ) async def call(session, tool, **args): result = await session.call_tool(tool, args) text = "\n".join(c.text for c in result.content if hasattr(c, "text")) return json.loads(text) # GhidraMCP 2.0 tools return JSON async def main(): async with stdio_client(SERVER) as (read, write): async with ClientSession(read, write) as session: await session.initialize() print(await call(session, "get_program_info")) # ... the steps below asyncio.run(main()) > The Python mcp SDK 2.x uses snake_case attributes. My first version used init.serverInfo, as in older examples, and crashed with AttributeError: 'InitializeResult' object has no attribute 'serverInfo'. It's server_info, input_schema and is_error now. Step 1: Get Oriented The first run imports and analyzes the binary, which took about 6 seconds here. Then the usual first questions: what is this file, what strings does it have, how many functions? !Terminal: demo.py connects to ghidra-mcp with 28 tools; get_program_info reports a Mach-O AARCH64 AppleSilicon binary with 170 functions; list_strings with filter invalid shows zlib inflate error messages; list_functions shows entry and FUN_ names Strings like invalid distance too far back and incorrect header check are zlib's inflate error messages, so even without symbols you know the library inside. The 170 functions are all anonymous except entry. Step 2: Find the Interesting Functions Checksums and file formats leave fingerprints in code: Adler-32 reduces modulo 65521 (0xfff1), the reflected CRC-32 polynomial is 0xEDB88320, and gzip files start with the magic bytes 1f 8b. GhidraMCP has no "search for a constant" tool, so the client decompiles every function and greps the C, using only list_functions and decompile_function_by_address: consts = {"0xfff1": "65521 (Adler-32 modulus)", "0xedb88320": "CRC-32 polynomial", "0x8b1f": "gzip magic 1f 8b"} for f in (await call(session, "list_functions", limit=500))["items"]: code = (await call(session, "decompile_function_by_address", address=f["address"])).get("code") or "" hits = [v for k, v in consts.items() if k in code] if hits: print(f'{f["address"]} {f["name"]:<16} {", ".join(hits)}') !Terminal: the constant hunt finds three functions using 65521, six using the CRC-32 polynomial and one using the gzip magic, after decompiling 170 functions in 46.7 seconds Ten candidates out of 170, and the whole pass took about 40 seconds. This is the kind of brute-force search that's tedious by hand and cheap for an AI with tool access. Step 3: Read the Candidate !Terminal: decompiled FUN_100000db8 splits the input into two 16-bit halves, reduces modulo 0xfff1, and processes the buffer in blocks of 0x15b0 bytes Reading FUN_100000db8: - It splits the first argument into two 16-bit sums (>> 0x10 & 0xffff and & 0xffff). - It returns 1 when the buffer pointer is NULL. - It processes the input in blocks of 0x15b0 = 5552 bytes before reducing modulo 0xfff1 = 65521. 5552 is zlib's NMAX, the largest block you can sum before the 32-bit accumulators could overflow. This is adler32_z(adler, buf, len) from adler32.c, with the 16-byte inner loop unrolled by clang -O3. The other two 0xfff1 hits are the adler32_combine helpers, FUN_100001284 is crc32_z, and FUN_1000071a0 (the one with the gzip magic, and 53 KB of decompiled C) is inflate(). The get_xrefs_to tool connects the rest: the string gunzip is used only by entry, which is minigzip's main (it checks argv[0] for gunzip and zcat). From there the call graph leads to gzopen, gzread, gzclose and minigzip's own gz_compress / gz_uncompress. Step 4: Write the Findings Back into Ghidra Answers in a chat window are easy to lose. The real value is writing them into the Ghidra project, where every later decompile (yours or the AI's) gets better: !Terminal: ten rename_function_by_address calls rename entry to main and FUN_ functions to adler32_z, crc32_z, inflate, gzopen, gzread, gzclose, gzerror, gz_uncompress and gz_compress; then set_function_prototype and set_decompiler_comment on gz_uncompress Step 5: Read Again Here's gz_uncompress after the renames. Callee names flow into every caller, so the loop reads as what it is: gzread 16 KB at a time, fwrite it, then fclose and gzclose. !Terminal: decompiled gz_uncompress after the renames, with gzread, gzerror and gzclose named, the new prototype and the comment at the top highlighted, plus a list of its callees The renames are stored in the Ghidra project, so they also show up when you open it in the GUI. Here's the same address in the same binary in Ghidra's CodeBrowser, first in a fresh import and then in the project the MCP session saved: !Ghidra CodeBrowser before the renames: at address 100000bb4 the Listing and Decompile windows show void FUN_100000bb4(void) calling FUN_10000cbf0, FUN_10000cb24 and FUN_10000c174, referenced from entry !Ghidra CodeBrowser after the renames: the same address now shows void gz_uncompress(void *in, FILE *out) with the minigzip comment at the top, calls to gzread, gzerror and gzclose, and references from main Two honest observations from this step: - The prototype didn't fully take. set_function_prototype succeeded, but the decompiler now prints WARNING: Unknown calling convention -- yet parameter storage is locked and still reads the arguments out of ___chkstk_darwin's return value. Any macOS arm64 function with a big stack buffer (here 16 KB) starts with a call to ___chkstk_darwin, and Ghidra 12.1.4 doesn't model it well. The names helped; the types didn't. Expect cases like this and check the output instead of trusting that a tool call "succeeded". - Error helpers stay anonymous. FUN_10000eb4c, FUN_10000ec60 and friends are minigzip's error() paths that clang outlined into tiny cold functions. They're the next thing to ask the AI to name. When I started ghidra-mcp again on the same --project, the log said Opening existing program /minigzip from the project and search_functions_by_name("gz") returned all six gz* names, so the work survives the session. Let Claude Code Drive The script shows the mechanics. The point of MCP, though, is that the AI picks the calls itself. So I ran the same kind of task with Claude Code as the client: the same stripped binary in a fresh Ghidra project, the headless config from Step 4 saved as mcp.json, and only the Ghidra tools allowed (--tools "" switches off Claude Code's built-in tools, so it can't cheat by reading the zlib source): Answer in English. You have a Ghidra MCP server with a stripped arm64 macOS binary called minigzip already loaded and analyzed. Use only the ghidra tools. 1. Tell me what this program is and which library it contains. 2. Find the function main calls to decompress a .gz file to a FILE (the loop that reads 16 KB at a time and fwrites it). Explain it in two sentences. 3. Rename that function and the zlib functions it calls to their real zlib/minigzip names, and add a one-line decompiler comment on it. 4. Finish with a short table: address, old name, new name, evidence. With --output-format stream-json, every tool call ends up in run.jsonl. Here they are in order: !Terminal: claude -p with the Ghidra MCP config connects to the ghidra server and makes 16 tool calls: get_program_info, list_strings, get_xrefs_to, nine decompile_function_by_address calls, four rename_function_by_address calls and set_decompiler_comment, in 17 turns and 40.6 seconds The path it took is close to what a human reverser would do: - It identified the program from strings alone: the zlib version banners (inflate 1.3.2 Copyright 1995-2026 Mark Adler) and minigzip's own messages (can't gzdopen stdin, failed fwrite). - It followed failed fwrite with get_xrefs_to to an error stub, then decompiled main and the 16 KB loop. - Before naming the callees it decompiled each one and matched it to zlib internals. For example, gzread checks state->mode == 0x1c4f, which is zlib's GZ_READ (7247). - It left minigzip's outlined error() stubs alone because they aren't zlib functions. Its final table, with the evidence column shortened to fit: !Terminal: Claude Code's final table renaming FUN_100000bb4 to gz_uncompress, FUN_10000cbf0 to gzread, FUN_10000cb24 to gzerror and FUN_10000c174 to gzclose, each with the evidence from the decompiled code All four names match zlib 1.3.2's test/minigzip.c and gzread.c, gzlib.c and gzclose.c, which I checked against the source afterwards. Its answer also explained the ___chkstk_darwin problem from Step 5 by itself: the probe for the 16 KB stack buffer hides the real arguments in the decompiler output. The whole run took 17 turns, about 40 seconds, and Claude Code reported a cost of $0.28. A Prompt Workflow for Real Sessions With an AI app instead of a script, the same steps become prompts: !Five steps of an AI-assisted reverse engineering session: orient, find, understand, annotate, report, repeating find to annotate for every callee 1. Orient. "Give me an overview of this program: architecture, imports, interesting strings." → get_program_info, list_imports, list_strings. 2. Find. "Which functions contain 0xfff1 or 0xedb88320? Which ones use the string 'gunzip'?" → decompile_function_by_address in a loop, get_xrefs_to. 3. Understand and name. "Explain FUN_100000db8, then rename it and add a one-line comment." → rename_function_by_address, set_decompiler_comment. 4. Walk the call graph. "Do the same for every function main calls, depth 2." → get_function_calls, then repeat. 5. Report. "Write a short report of what this binary does, with addresses." The full tool list, grouped by job: | Job | Tools | | --- | --- | | Get oriented | get_program_info, list_functions, list_segments, list_imports, list_exports, list_strings, list_classes, list_methods, list_namespaces, list_data_items | | Find things | search_functions_by_name, get_function_by_address | | Read code | decompile_function, decompile_function_by_address, disassemble_function, read_memory | | Follow the flow | get_xrefs_to, get_xrefs_from, get_function_xrefs, get_function_calls | | Improve the database | rename_function, rename_function_by_address, rename_data, rename_variable, set_function_prototype, set_local_variable_type, set_decompiler_comment, set_disassembly_comment | That's the 28 tools headless mode reports. In GUI mode the plugin also offers get_current_function and get_current_address, which read where your cursor is, so you can click a function in Ghidra and just ask "what does this one do?". Limits and Risks - The AI can be confidently wrong. Optimized code is hard to read even for people; the ___chkstk_darwin case above is a small example. Treat names and comments as hypotheses, verify the important ones, and keep the project under version control or work on a copy. - Prompt injection from the binary. Strings inside the binary go into the model's context. A malicious sample could contain text written to mislead an AI. Don't give the same agent tools that touch the outside world (shell, email, uploads) while it reads untrusted samples. - Never run the sample. GhidraMCP only does static analysis, which is good; keep it that way and keep malware inside an isolated VM. - Confidentiality. Decompiled code and strings are sent to whatever model your client uses. For sensitive or proprietary binaries, check your company's policy or use a local model. - Local HTTP server. The plugin listens on loopback only. Don't expose it on a shared network: anyone who can reach it can read and modify your Ghidra project. FAQ Is GhidraMCP free? Yes. Ghidra is free and open source (from the NSA), and GhidraMCP is open source under Apache-2.0. You only pay for the AI model you connect, if any. Does GhidraMCP work on Apple Silicon Macs? Yes, but build Ghidra's native components first (cd support/gradle && ./gradlew buildNatives), because the release has no macOS binaries. On my M-series Mac that took about 10 seconds. Can I use GhidraMCP without the Ghidra GUI? Yes. ghidra-mcp --headless --binary <file> runs Ghidra through PyGhidra, analyzes the file and serves the same tools. Add --project DIR to keep the results. Which Ghidra version do I need? The extension release must match your Ghidra version; GhidraMCP 2.0 targets Ghidra 12.1.4. For another version, build the extension from source against your GHIDRA_INSTALL_DIR. Does GhidraMCP work with local models? Yes, through any MCP client that supports a local model. Expect weaker results than frontier models on hard code, but the binary stays on your machine. Ghidra MCP vs IDA Pro MCP? Same idea, different disassembler. Community MCP servers exist for IDA Pro and Binary Ninja too. Ghidra's advantage is that the whole stack is free. > More on AI tooling and security 👇 > > 🚀 What Is an MCP Server? How to Build One in Python > > 🚀 What Is an AI Agent? How to Build One from Scratch in Python > > 🚀 STRIDE Threat Modeling Explained with an Example

REA nedir? Ajanla tersine mühendislik --- title: "REA nedir? Ajanla tersine mühendislik" published: true description: "REA, Claude Code ve Codex gibi ajanlara tersine mühendislik araçlarını bağlayan açık kaynak MCP sunucusu. Ne yapıyor, ne yapmıyor, nerede durmalı?" tags: ai,reverseengineering,opensource,security canonical_url: huseyinbozdemir.com cover_image: huseyinbozdemir.com --- Ekim'de GitHub'da en hızlı yükselen depo bir yapay zekâ modeli ya da yeni bir framework değil, bir tersine mühendislik aracı oldu. REA (Reverse Engineer Anything) 23 Ekim itibarıyla 370 binin üzerinde yıldızı geçti; ay başında adını bilen yok gibiydi. REA, Claude Code, Codex, Cursor ya da Gemini CLI gibi kodlama ajanlarına tersine mühendislik araçlarını tek bir MCP sunucusu üzerinden bağlayan, MIT lisanslı açık kaynak bir araç. Fikri basit: bir uygulamada beğendiğin bir özellik var, kaynak kodu elinde yok. Ajana "bu özellik nasıl çalışıyor, kanıtıyla göster" diyorsun, ajan da REA'nın araçlarıyla uygulamanın içine bakıyor. REA ne yapıyor? MCP (Model Context Protocol), bir ajanın dış araçları çağırmasını sağlayan ortak bir protokol. REA bu protokolle ajana bir dizi inceleme aracı sunuyor ve kurulumu tek komut: npx rea-agents setup. Komut, seçtiğin ajanlara REA'yı kaydediyor ve ajanın nasıl inceleme yapacağını anlatan talimatları ekliyor. REA ile bir inceleme nasıl ilerler: Ajan, bir uygulamadaki özelliğin nasıl çalıştığını sorar. Soru MCP araç çağrısı olarak REA'ya gider. REA bilgisayardaki analiz araçlarını çalıştırır: Ghidra, Hopper ya da IDA ile derlenmiş programlar; JavaScript, Electron ve .NET için yerleşik statik analiz; tarayıcı, APK ve ağ kayıtları. Sonuç kanıtları ve bilinmeyenleriyle ajana döner; ajan açıklar, benzerini yazar ve test eder. Asıl iş REA'nın kendisinde değil, arkasına bağladığı araçlarda. Derlenmiş programlar için bilgisayarında kurulu Ghidra, Hopper ya da IDA'yı kullanıyor; yani kendi decompiler'ı yok. JavaScript ve Electron uygulamalarını, .NET dosyalarını ise ek bir araç olmadan, programı çalıştırmadan okuyabiliyor. Bunların yanında web sitelerini bir tarayıcı üzerinden, Android uygulamalarını JADX ile, kaydedilmiş ağ trafiğini de HAR dosyalarından inceleyebiliyor. !Hopper'da açılmış bir macOS programı: solda assembly kodu ve bölüm bilgileri, sağda dosya ve adres bilgileri, altta REA'nın başlattığı analiz adımlarının çıktısı REA, Hopper'ı kendisi başlatıp bir programı incelerken. Görsel: REA deposu (MIT lisansı). Projenin README'si iki noktada dürüst. Analiz senin bilgisayarında çalışıyor, ama araçların bulduğu sonuçlar ajana, dolayısıyla ajanın kullandığı model sağlayıcısına gidiyor. Bir de REA her bulguyu kanıtıyla ve "bunu bilmiyorum" dediği yerlerle birlikte döndürüyor; uygulamanın orijinal kaynak kodunu geri getirdiğini iddia etmiyor. Örneklerde ne var? Projenin örnek vakaları neyin mümkün olduğunu iyi gösteriyor. Birinde Notion'ın masaüstü uygulamasında panoya kopyalama özelliği, ekrandan Electron'un iç katmanlarına kadar izleniyor. Diğerinde eski bir oyun olan DX-Ball'da topun sesinin hangi hoparlörden çıkacağını hesaplayan fonksiyon assembly'den C'ye geri yazılıyor; yeniden yazılan kod, orijinal programla 3.205 test durumunda aynı sonucu veriyor. !REA'nın üç örnek vakasını anlatan çizimler: hoparlörlü bir blok kırma oyunu, bir uygulama penceresinden panoya giden bağlantı ve bir noktanın çevresinde dizilmiş mermiler Örnek vakalar: DX-Ball, Notion ve TH04. Görsel: REA deposu (MIT lisansı). Abartı mı? Kısmen. Ajanları Ghidra'ya bağlamak yeni bir fikir değil; GhidraMCP Mart 2025'ten beri var. InfoQ'nun haberine göre Hacker News'te de ilk soru buydu: ajana "Ghidra'yı kur ve kullan" demekten farkı ne? Bazı kullanıcılar REA ile daha iyi sonuç aldığını söylüyor, ama bunu ölçen bağımsız bir karşılaştırma yok. REA'nın asıl katkısı kolaylık gibi duruyor: tek kurulum, tek arayüz ve birçok dosya türü. Yıldız sayısı da bir ilgi göstergesi, kaç kişinin gerçekten kullandığını söylemiyor. Nerede durmalı? Tersine mühendislik meşru bir iş: güvenlik araştırması, zararlı yazılım analizi, eski bir sistemin nasıl çalıştığını anlamak, başka bir yazılımla uyumlu çalışacak bir şey yazmak. Ama sınırı ince ve REA'nın sorumlu kullanım metni bu yüzden açık konuşuyor: yalnızca sahibi olduğun ya da incelemeye yetkin olduğun yazılım; lisans kontrolünü, DRM'i ya da kimlik doğrulamayı atlatmak yok. Tersine mühendislik bazı ülkelerde ve bazı lisans sözleşmelerinde kısıtlı, sorumluluk da kullanıcıda. Hopper ve IDA gibi ticari araçların lisansını da ayrıca alman gerekiyor. Bir de şirket ortamında unutulan bir nokta var: incelediğin dosya senin bilgisayarında kalsa bile, ondan çıkan kod parçaları ve bulgular model sağlayıcısına gidiyor. Bir iş ortağının verdiği kapalı bir kütüphaneyi ajana inceletmeden önce bunun sözleşmeye uyup uymadığına bakmak gerekiyor. Özetle REA, kaynak kodu olmayan bir şeyi anlamaya çalışırken ajanına doğru araçları veriyor; neyi anlamaya yetkin olduğuna karar vermek yine sana kalıyor. --- Bu yazı ilk olarak huseyinbozdemir.com'da yayımlandı.

14,780 Reverse Engineering Projects: What AI Changed Open source, explained: REA (morluto/rea) is free and open source (MIT licence), and 13 of the 16 classic reverse engineering tools in this video are free and open source too. Related news (not in the video): ArtCraft, a separate project, has used AI to rebuild Photoshop-, Premiere-, Word- and Figma-style apps (PhotoCraft, FigCraft and more) as free open-source projects. Early alpha and unofficial: not made by Adobe, Microsoft or Figma, and not built with REA. Reverse engineering with AI: how many tools exist, what people are doing, and REA, the free GitHub repo (morluto/rea) that lets an AI explain how any app works. Repo: morluto/rea (free and open source, MIT licence) Reverse engineering with AI, explained simply: what reverse engineering is, the AI tools (REA, GhidraMCP, IDA MCP, JADX), how many tools exist on GitHub, what people do with them (game preservation, malware analysis, CTFs), and how to stay safe and legal. Real sources on screen. Chapters: 0:00 Intro 0:30 What reverse engineering is 1:12 The AI wave: GhidraMCP, IDA, REA 2:25 How many tools exist? The numbers 3:37 What people are actually doing 4:54 Fake copies, the law, staying safe 5:56 The number we saved, and our take Sources (date = the source's own date): 1. What reverse engineering is (20 Oct 2026) EFF, Reverse Engineering FAQ: eff.org Ghidra (NSA): NationalSecurityAgency/ghidra REA responsible use: github.com/morluto/rea/blob/main/DISCLAIMER.md 2. The AI wave: GhidraMCP, IDA, REA (20 Oct 2026) GhidraMCP: LaurieWired/GhidraMCP ida-pro-mcp: mrexodia/ida-pro-mcp Official Hex-Rays IDA MCP: HexRaysSA/ida-mcp jadx-ai-mcp: zinja-coder/jadx-ai-mcp REA: morluto/rea 3. How many tools exist? The numbers (20 Oct 2026) GitHub topic: topics/reverse-engineering (count via the GitHub search API, 20 Oct 2026) awesome-ai-reverse-engineering: zhuyansen/awesome-ai-reverse-engineering IDA pricing: hex-rays.com Binary Ninja pricing: binary.ninja 4. What people are actually doing (20 Oct 2026) Chris Lewis, Decompiling a Nintendo 64 Game in 84 Days (26 Aug 2026): blog.chrislewis.au Maurice Heumann, 500+ Billion Tokens Later (9 Oct 2026): momo5502.com SentinelOne Labs, Adversarial Consensus Engine: sentinelone.com REA CTF showcase: rea.tools 5. Fake copies, the law, staying safe (20 Oct 2026) REA issue no. 2424 (one user's report of a fake copy): rea#2424 REA official sources (README): morluto/rea 37 CFR 201.40(b)(18): law.cornell.edu EU Software Directive 2009/24/EC: eur-lex.europa.eu REA DISCLAIMER: github.com/morluto/rea/blob/main/DISCLAIMER.md 6. The number we saved, and our take (20 Oct 2026) SRE-Bench, arXiv 2608.11469 (v2, 1 Oct 2026): arxiv.org Every number comes from the source named on screen. Charts are drawn by ITG Now from those numbers. Reports marked unconfirmed are not confirmed by the companies. Counts: GitHub search API (topic total_count, forks excluded), checked 20 Oct 2026. These count repositories, not tools. Stars are bookmarks, not users. Legal notes are general information, not legal advice. We do not show or teach bypassing DRM, licence checks or other protections. One user reported a fake REA copy (issue no. 2424). Official REA: github.com/morluto/rea, rea.tools, npm rea-agents. ITG Now: free AI tools and AI news, explained simply. Read more on our site: REA (Reverse Engineer Anything), explained: itgnow.vercel.app Follow ITG Now everywhere: 🌐 Website (news, guides, tools): itgnow.vercel.app 📸 Instagram: instagram.com 💼 LinkedIn: linkedin.com ▶️ YouTube: youtube.com 🐙 GitHub: shilpausingh1-create.github.io #AI #ReverseEngineering #CyberSecurity

Testing REA, the Viral AI Reverse Engineering Repo, Against Real Source Code Ask a coding agent how a closed app works and it will happily explain, whether or not it actually read anything. REA (Reverse Engineer Anything) is the project trying to fix that by giving agents real analysis tools and making every answer carry evidence. It picked up 304,554 GitHub stars between April 14 and October 18, 2026, over three times Ghidra's 90,126, and the rea.tools submission on Hacker News climbed to 808 points on October 10. I wanted to know whether the evidence holds up, so I ran REA 6.5.0 against an app whose source I could read. The short version: it mapped the app's renderer API perfectly and skipped a security-relevant setting entirely. The full write-up on DevToolLab has every command, the comparison script and the complete output. What REA Actually Adds to Your Agent Everything comes in a single npm package, rea-agents, under the MIT license: a command-line tool, an agent skill and an MCP server. npx rea-agents setup wires it into Claude Code, Codex, Cursor, Gemini CLI, Grok Build or any other MCP client and keeps backups of the config files it touches. Its rea mcp doctor check listed 207 tools and 6 prompts on my machine. It does not decompile anything itself. Native binaries go through whichever of Hopper, Ghidra or IDA you have installed, Android through JADX, and Rizin or GNU objdump handle offline inspection. For Electron and JavaScript apps, .NET assemblies, Go or Rust binaries' build info and HAR captures, REA uses analyzers of its own, so no extra engine is needed. !REA's homepage, headlined "Find out how software works.", next to its npx setup command One thing to internalize before using it on anything sensitive: the analysis is local, the conversation is not. REA's FAQ notes that your agent gets the tool results and "its model provider has its own data policy," so a cloud model sees whatever code REA extracts. The Test Setup The target was T3 Code, an MIT-licensed Electron app that controls coding agents like Claude Code and Codex, with 28,088 stars. Its v0.1.0 release came out October 15, 2026 from commit 81493ef, which meant every REA finding could be compared with the exact source behind the binary. Two things broke first. REA's engines field skips Node 25 (it wants 22.19+, 24.11+ or 26+), so I switched to Node 24.22.0. Then it rejected the app archive with artifact_integrity_mismatch, because a native .node addon no longer matched its recorded hash. The error text suggests the fix itself: npx rea analyze-javascript-application \ "/Applications/T3 Code (Beta).app/Contents/Resources/app.asar" \ --integrity-policy record-and-continue \ --source-path apps/desktop/dist-electron/main.cjs \ --source-path apps/desktop/dist-electron/preload.cjs \ --filter-output normalized_result.summary --format yaml Those --source-path flags matter. Analyzing the entire archive took 227 seconds, covering 2,665 files and roughly 8.5 million AST nodes, before hitting REA's result limit of about 2 GB inside a dependency. Limited to the app's own two bundles, the run finished in about 35 seconds and reported 4 windows, 121 exposed bridge members, 207 renderer IPC calls and only 10 main-process handlers. Where REA Was Exactly Right T3 Code exposes one object to its UI, desktopBridge, through Electron's contextBridge. REA listed 121 members on it, including nested ones. I parsed the real preload.ts from the v0.1.0 tag with Babel and diffed the two lists: 121 matched, 0 missed, 0 invented. The script that does that comparison is in the original post if you want to rerun it. Window settings checked out too. The three windows built from literal options all use contextIsolation: true, nodeIntegration: false and sandbox: true, which matches the source. The fourth, the main window, is built from an options variable passed through a wrapper, and REA labeled it dynamic rather than guessing. That is the right call, but it means the most important window still has to be read by hand. Where It Fell Short The IPC picture was lopsided. Of the 10 handlers REA found, 9 live inside @clerk/electron, the sign-in library bundled into the app, and only 1 of 207 renderer calls was matched to a handler. T3 Code registers its own handlers through a generic wrapper that passes the channel name as a variable, and REA counts those 132 operations as unresolved instead of inventing a mapping. Honest, but a careless agent could read the summary as "most of this bridge goes nowhere." The bigger gap: T3 Code turns contextIsolation off for its in-app browser preview inside a will-attach-webview handler, keeping the sandbox on, so a picker script can share globalThis with the page. That code sits unminified at line 113,485 of the shipped main.cjs, and the string never appears in the 186 MB of evidence REA produced. REA understands window constructors, not preferences modified later in an event handler. How It Compares to Other AI Reverse Engineering Tools Most competitors connect one engine to one protocol, which keeps them small and leaves you with that engine's license. | Tool | What it is | License | Stars (Oct 18, 2026) | |---|---|---|---| | REA | 207-tool MCP server over Hopper, Ghidra, IDA, JADX and Rizin | MIT | 304,554 | | IDA Pro MCP | IDA Pro to language models via MCP | MIT, IDA itself is commercial | 12,980 | | GhidraMCP | MCP server for Ghidra | Apache 2.0 | 11,346 | | eleven | ACP agents patch binaries, Android apps and GPU kernels | Apache 2.0 | 666 | | Binary Ninja MCP | Binary Ninja plugin with an MCP server | GPL 3.0 | 454 | | radare2-mcp | radare2 over MCP stdio | MIT | 327 | | BINNY | Standalone RE agent harness, any model | AGPL 3.0 | 141 | REA can drive Ghidra too, so picking it does not replace Ghidra; it changes who is at the keyboard. !The morluto/rea GitHub page showing 304.6k stars, 77.1k forks and the v6.5.0 release Things to Know Before You Install It The model may refuse. A commenter in the Hacker News thread said even hinting at reverse engineering makes Anthropic and OpenAI models "extremely sensitive to refusals," and no tool changes that. Setup is agent-driven: the site suggests pasting an install instruction into your agent, which someone in the same thread likened to curl | bash. It does show a plan before applying it, but trying the CLI in a scratch folder first is safer. Licenses still apply. REA's README says you must legally obtain commercial tools like IDA Pro, Hopper and JEB, and its disclaimer says the project will not help anyone get around DRM, license checks or anti-cheat systems. The project also moves quickly: 32 npm versions since July 12, 2026, with 6.1.0 through 6.5.0 landing within six days in October, so pin a version anywhere it runs unattended. A Safer Way to Try It 1. Start on a target with known source, such as an open-source project or something you built yourself. 2. Put rea-agents@6.5.0 in a throwaway directory and run rea doctor before registering it with your agent. 3. Restrict analysis to the app's own bundles with --source-path. 4. Read the evidence's limitations and dynamic counts before the agent's summary. 5. Search the bundle yourself for things REA does not model, like will-attach-webview. When the evidence points at minified code it could not resolve, the JavaScript Deobfuscator helps, and the Source Map Decoder maps bundled lines back to original files when an app ships its .map files. Which Tool Fits Which Job - Mixed targets across Electron, Android and native code: REA. - You already pay for IDA Pro: IDA Pro MCP. - Native binaries with no budget: GhidraMCP on Ghidra. - Electron security reviews: REA for the bridge and windows, plus a manual look at event handlers. - Code that cannot leave your network: REA with a locally hosted model. Takeaway REA makes decompilers something an agent can operate and attaches receipts to the answers. In this test the receipts were exact where REA had visibility and empty where it did not, so the useful habit is asking what the tool never looked at. The original DevToolLab post walks through the full run. References - REA: AI Reverse Engineering Tool, Tested (DevToolLab) - REA on GitHub - rea.tools - T3 Code on GitHub - Ghidra - GhidraMCP - IDA Pro MCP - Hacker News discussion

REA Got 200,000 GitHub Stars. Did It Invent Anything? (Reverse Engineer Anything, Explained) REA (Reverse Engineer Anything, github.com/morluto/rea) went from about 10,000 to more than 200,000 GitHub stars in less than a week. It is an MCP server that lets AI coding agents such as Claude Code, Codex and Cursor inspect programs without their source code. Our idea: REA did not invent a new reverse engineering method; it collected old tools and gave them to AI through one connection. We test that idea against REA's own README, its third-party notices and its workflow skill, and against older projects: Ghidra, IDA Pro, JADX, Frida, and the 2025 AI bridges GhidraMCP and ida-pro-mcp. We also show what REA did build itself: one setup for 15 agents, its own readers for some file types, and strict rules for evidence. Theory only: we did not install or run REA. ⏱️ Chapters 0:00 Intro 0:44 What is reverse engineering? 1:27 What REA says it does 2:04 Who does the actual work? 2:52 Was the AI connection new? 3:28 So what did REA build? 4:19 What it does not do 4:46 Why so many stars? 5:31 Our verdict on our own idea 6:07 Wrap-up 📰 Sources - REA (morluto/rea): morluto/rea - REA third-party notices: github.com/morluto/rea/blob/main/THIRD_PARTY_NOTI… - REA workflow skill: github.com/morluto/rea/blob/main/.agents/skills/r… - GhidraMCP (LaurieWired, Mar 2025): LaurieWired/GhidraMCP - ida-pro-mcp (mrexodia, Mar 2025): mrexodia/ida-pro-mcp - jadx-ai-mcp (zinja-coder, Apr 2025): zinja-coder/jadx-ai-mcp - Ghidra (NSA): NationalSecurityAgency/ghidra - JADX: skylot/jadx - Frida: frida/frida - Startup Fortune, Elroy Fernandes (Oct 9, 2026): startupfortune.com Theory only: we did not install, run or test REA. Star counts and dates: GitHub API, read Oct 13, 2026 (the Oct 8 count is Startup Fortune's). REA is MIT-licensed; its README says it is for lawful research, education, interoperability, software preservation, and analysis of software you own or are authorized to examine. Music: original. Narration: AI-generated voice; script and fact-checking reviewed by a human. 🔔 One Prompt Away: real Claude runs and AI tools, explained in plain words. Subscribe! Independent channel, not affiliated with or endorsed by Anthropic, REA or any project shown. Claude is a trademark of Anthropic. #REA #ReverseEngineering #MCP #ClaudeCode #Ghidra #AIagents #GitHub

Wahrscheinlich MUSS ich mir doch wohl bald so eine lokal KI (Qwen?) aufsetzen, sonst ist man in dieser Branche sicherlich bald komplett abgehängt. 🥴🔫 Und wenn ich dann sowas sehe, lockt das leider doch schon sehr 😔 LaurieWired/GhidraMCP