Inspired by the, I have it a try as well.
While I have no prior experience with reverse engineering, I ported an old game from PowerPC to Apple Silicon.
First, including a few MCPs with Claude Code (including LaurieWired/GhidraMCP you forked from, and https://github.com/jtang613/GhidrAssistMCP). Yet, the agent fabricated as lot of code, instead for translating it from source.
I ended up using headless mode directly in Cursor + GPT 5.2 Codex. The results were the best.
I built this because reverse engineering software across multiple versions is painful. You spend hours annotating functions in version 1.07, then version 1.08 drops and every address has shifted — all your work invisible.
The core idea is a normalized function hashing system. It hashes functions by their logical structure — mnemonics, operand categories, control flow — not raw bytes or absolute addresses. When a binary is recompiled or rebased, the same function produces the same hash. All your documentation (names, types, comments) transfers automatically.
Beyond that, it's a full MCP bridge with 110 tools for Ghidra: decompilation, disassembly, cross-referencing, annotation, batch analysis, and headless/Docker deployment. It integrates with Claude, Claude Code, or any MCP-compliant client.
For context, the most popular Ghidra MCP server (LaurieWired's, 7K+ stars) has about 15 tools. This started as a fork of that project but grew into 28,600 lines of substantially different code.
Architecture:
Java Ghidra Plugin (22K LOC) → embeds HTTP server inside Ghidra
Python MCP Bridge (6.5K LOC) → 110 tools with batch optimization
Any MCP client → Claude, scripts, CI pipelines
I validated the hashing against Diablo II — dozens of patch versions, each rebuilding DLLs at different base addresses. The hash registry holds 154K+ entries, and I can propagate 1,300+ function annotations from one version to the next automatically.
The headless mode runs in Docker (docker compose up) for batch processing and CI integration — no GUI required.
I think your installation instructions are incomplete. I followed the instructions and installed via file -> install in the project view. Restarted. But GhidraMCP is not visible in Tools after opening a binary.
Ive been using it (the original 15 tool version) for months now. It’s amazing. Any app is suddenly “open source”. I can track down bugs. Get a deeper understanding of any tool, and even write plug-ins or preload shims that mod any app. It’s like I finally actually _own_ the software I bought years ago.
For objective C heavy code, I also use Hopper Disassembler (which now has a built in MCP server).
Last week-end I was exploring the current possibilities of automated Ghidra analysis with Codex. My first attempt derailed quickly, but after giving it the pyghidra documentation, it reliably wrote Python scripts that would alter data types etc. exactly how I wanted, but based on fixed rules.
My next goal would be to incorporate LLM decisions into the process, e.g. let the LLM come up with a guess at a meaningful function name to make it easier to read, stuff like that. I made a skill for this functionality and let Codex plough through in agentic mode. I stopped it after a while as I was not sure what it was doing, and I didn't have more time to work on it since. I would need to do some sanity checks on the ones it has already renamed.
Would be curious what workflows others have already devised? Is MCP the way to go?
Is there a place where people discuss these things?
From my experience, OpenAI Codex loves reverse engineering work. In one case it did a very thorough job of disassembling a 8051 MCUs firmware and how it spoke to its attached LCD controller.
Another (semi-related) project, given the manufacturers of above MCUs proprietary flashing SDK, it found the programmers firmware, extracted the decryption key from the updating utility, decrypted the firmware and accompanying flashing software and is currently tracing the necessary signals to use an Arduino as a programmer.
So not only is it willing, it's actually quite good at it. My thinking is that reverse engineering is a lot of pattern recognition and not a lot of "original thinking". I.e. the agent doesn't need to come up with anything new, just recognise what already exists.
Very cool project! The MCP surface area here (110 tools) is a great example of why tool-output validation is becoming critical.
When an AI agent interacts with binary analysis tools, there are two injection vectors worth considering:
1. *Tool output injection* — Malicious binaries could embed prompt injection in strings/comments that get passed back to the LLM via MCP responses
2. *Indirect prompt injection via analyzed code* — Attackers could craft binaries where the decompiled output contains payloads designed to manipulate the agent
For anyone building MCP servers that process untrusted content (like binaries, web pages, or user-generated data), filtering the tool output before it reaches the model is a real gap in most setups.
(Working on this problem at Aeris PromptShield — happy to share attack patterns we've seen if useful)
Funny coincidence, I'm working on a benchmark showcasing AI capabilities in binary analysis.
Actually, AI has huge potential for superhuman capabilities in reverse engineering. This is an extremely tedious job with low productivity. Currently reserved, primarily when there is no other option (e.g., malware analysis). AI can make binary analysis go mainstream for proactive audits to secure against supply-chain attacks.
Interesting to see Ghidra here!
A friend from work just used it (with Claude) to hack River Ride game (https://quesma.com/blog/ghidra-mcp-unlimited-lives/).
Inspired by the, I have it a try as well. While I have no prior experience with reverse engineering, I ported an old game from PowerPC to Apple Silicon.
First, including a few MCPs with Claude Code (including LaurieWired/GhidraMCP you forked from, and https://github.com/jtang613/GhidrAssistMCP). Yet, the agent fabricated as lot of code, instead for translating it from source.
I ended up using headless mode directly in Cursor + GPT 5.2 Codex. The results were the best.
Once I get some time, will share a write-up.
Hi HN,
I built this because reverse engineering software across multiple versions is painful. You spend hours annotating functions in version 1.07, then version 1.08 drops and every address has shifted — all your work invisible.
The core idea is a normalized function hashing system. It hashes functions by their logical structure — mnemonics, operand categories, control flow — not raw bytes or absolute addresses. When a binary is recompiled or rebased, the same function produces the same hash. All your documentation (names, types, comments) transfers automatically.
Beyond that, it's a full MCP bridge with 110 tools for Ghidra: decompilation, disassembly, cross-referencing, annotation, batch analysis, and headless/Docker deployment. It integrates with Claude, Claude Code, or any MCP-compliant client.
For context, the most popular Ghidra MCP server (LaurieWired's, 7K+ stars) has about 15 tools. This started as a fork of that project but grew into 28,600 lines of substantially different code.
Architecture:
I validated the hashing against Diablo II — dozens of patch versions, each rebuilding DLLs at different base addresses. The hash registry holds 154K+ entries, and I can propagate 1,300+ function annotations from one version to the next automatically.The headless mode runs in Docker (docker compose up) for batch processing and CI integration — no GUI required.
v2.0.0 adds localhost-only binding (security), configurable timeouts, label deletion tools, and .env-based configuration.
Happy to discuss the hashing approach, MCP protocol design decisions, or how this fits into modern RE workflows.
How does this compare to ReVa? https://github.com/cyberkaida/reverse-engineering-assistant
I think your installation instructions are incomplete. I followed the instructions and installed via file -> install in the project view. Restarted. But GhidraMCP is not visible in Tools after opening a binary.
Thank you for sharing, will soon try out. Does it support decompilation of android binaries?
Ive been using it (the original 15 tool version) for months now. It’s amazing. Any app is suddenly “open source”. I can track down bugs. Get a deeper understanding of any tool, and even write plug-ins or preload shims that mod any app. It’s like I finally actually _own_ the software I bought years ago.
For objective C heavy code, I also use Hopper Disassembler (which now has a built in MCP server).
Some related academic work (full recompilation with LLMs and Ghidra): https://dl.acm.org/doi/10.1145/3728958
Talking about RE'ing applications and equating that to OSS is not a good look when you work at GitHub...
Super interesting.
Last week-end I was exploring the current possibilities of automated Ghidra analysis with Codex. My first attempt derailed quickly, but after giving it the pyghidra documentation, it reliably wrote Python scripts that would alter data types etc. exactly how I wanted, but based on fixed rules.
My next goal would be to incorporate LLM decisions into the process, e.g. let the LLM come up with a guess at a meaningful function name to make it easier to read, stuff like that. I made a skill for this functionality and let Codex plough through in agentic mode. I stopped it after a while as I was not sure what it was doing, and I didn't have more time to work on it since. I would need to do some sanity checks on the ones it has already renamed.
Would be curious what workflows others have already devised? Is MCP the way to go?
Is there a place where people discuss these things?
I thought MCP interfaces with high amounts of tools perform much worse than MCP interfaces with fewer tools, this doesn't seem like a great design.
This also seems to just be vibecoded garbage.
Have you had any issues with models "refusing" to do reverse engineering work?
From my experience, OpenAI Codex loves reverse engineering work. In one case it did a very thorough job of disassembling a 8051 MCUs firmware and how it spoke to its attached LCD controller.
Another (semi-related) project, given the manufacturers of above MCUs proprietary flashing SDK, it found the programmers firmware, extracted the decryption key from the updating utility, decrypted the firmware and accompanying flashing software and is currently tracing the necessary signals to use an Arduino as a programmer.
So not only is it willing, it's actually quite good at it. My thinking is that reverse engineering is a lot of pattern recognition and not a lot of "original thinking". I.e. the agent doesn't need to come up with anything new, just recognise what already exists.
Very cool project! The MCP surface area here (110 tools) is a great example of why tool-output validation is becoming critical.
When an AI agent interacts with binary analysis tools, there are two injection vectors worth considering:
1. *Tool output injection* — Malicious binaries could embed prompt injection in strings/comments that get passed back to the LLM via MCP responses
2. *Indirect prompt injection via analyzed code* — Attackers could craft binaries where the decompiled output contains payloads designed to manipulate the agent
For anyone building MCP servers that process untrusted content (like binaries, web pages, or user-generated data), filtering the tool output before it reaches the model is a real gap in most setups.
(Working on this problem at Aeris PromptShield — happy to share attack patterns we've seen if useful)
Funny coincidence, I'm working on a benchmark showcasing AI capabilities in binary analysis.
Actually, AI has huge potential for superhuman capabilities in reverse engineering. This is an extremely tedious job with low productivity. Currently reserved, primarily when there is no other option (e.g., malware analysis). AI can make binary analysis go mainstream for proactive audits to secure against supply-chain attacks.
Thank you for sharing this, it's a a huge amount of work and I now know how I'll be spending this weekend!
Now we just need to choose a game and run Claude Code with Ghidra MCP in a loop until the game is completely decompiled.