Open a compiled program in Ghidra for the first time and you get a wall. There’s a listing full of hex and assembly, a decompiler window full of C-looking code, and function names like FUN_00401a30 everywhere. Nothing has a real name because the names were thrown away when the program was built. So the work is to give those functions names, one by one, until the program starts making sense.
Ghidra is the free tool a lot of people reach for to do that. The NSA built it, the GitHub repo sits at about 83,800 stars and 9,300 forks, and you hear it said that it’s suddenly everywhere. I went looking for the one big recent reverse engineering case that explains the jump. I couldn’t find one, and I spent longer on that than I’d like to admit. What I found was a pile of smaller things, plus a lot of people connecting AI assistants like Claude to it.
My view up front: Ghidra is the tool, Claude is a helper that sits on top of it, and the helper is useful but rougher than the demos make it look.
What Ghidra actually is
The NSA Research Directorate created it and still maintains it. The README says it was built to solve scaling and teaming problems on large reverse engineering jobs, and that the agency has used it for analysing malicious code. The public first got it at the RSA Conference in San Francisco in March 2019, as version 9.0. Dark Reading covered that launch and reported that the infosec crowd was happy about it, with Maddie Stone, who does reverse engineering at Google, especially excited. Same article claimed Ghidra could decompile MIPS code, which IDA Pro couldn’t do at that time. That was seven years ago though, so I wouldn’t use it to argue about IDA today.
Per the README, Ghidra does disassembly, assembly, decompilation, graphing and scripting, plus hundreds of smaller features. It runs on all the major desktop systems, handles a wide range of processors and file formats, and works either interactively or in automated mode. You can write your own scripts and extensions in Java or Python. The licence is Apache-2.0, so you can use it at work without asking anybody.
The decompiler gets most of the attention. It takes machine code and produces C-like pseudocode you can read. One beginner guide I found says plainly that it’s not a button that gives you the original source back, and that’s right. The output is a guess, a good one sometimes, and you’ll still be fixing variable types by hand.
Install is simple but has a trap. You need JDK 25, then download release zip from the Releases page, extract it into a fresh folder and run ghidraRun. The trap is that GitHub also lists two files called “Source Code” right there, and those are the wrong ones. The README has a whole note about it, so I’d guess plenty of people trip on that step. Never extract a new version on top of an old one either, that’s another README warning.
A first session usually goes like this. You make a project, import a program, and Ghidra asks if it should run auto analysis. You say yes. It chews on the file for a minute or a few, depending on size, and fills the listing with labels and cross references. Then you open the CodeBrowser, find a text string you recognise, and follow it to the function that uses it. That function is called FUN_something, so you rename it to what you think it does. Three functions later you realise the first rename was wrong and you go back. It’s slow, and it’s meant to be slow at the start. The beginner guide I mentioned suggests practising on a small harmless program you wrote yourself, which I think is the right advice.
Why it keeps showing up in 2026
Part of it is just that the project doesn’t stop moving. The repo shows around 1,600 open issues and almost 500 open pull requests, and Wikipedia lists 12.1.4 as the stable release from August 18, 2026. A post announcing 12.1.3 the day before listed fixes for a path traversal bug when importing XML .bytes files and a shell command injection problem in the debugger agents.
Which is also why the security side matters more than it looks. Three advisories came out in June 2026, and that same post says they affect versions before 12.1.1. So if you’re on something older than that, update. The README itself starts with a warning about known vulnerabilities in certain versions. Reverse engineers open hostile files all day, which means a bug in how the tool parses a file hurts more here than in a normal app.
There’s also a new book. The Ghidra Book is listed for 2026 and the author is Chris Eagle, who has been reverse engineering for 45 years and wrote The IDA Pro Book earlier. It covers scripting, headless mode and collaborative work, and it has an appendix for people coming over from IDA. When the person who wrote the IDA book writes a Ghidra book with a chapter for IDA users, that tells me something about where the crowd is moving. It’s only my read, I can’t see sales numbers.
So the “Ghidra is everywhere now” story is mostly true, though I’m oversimplifying, because stars only go up and I have no download counts.
And then there’s the AI part, which is probably the real reason you saw it in your feed.
Where Claude fits
Ghidra has no AI assistant built in. Rafal Strzalinski said so directly in a January 2026 post on the Quesma blog, where he tried to bridge the gap himself. The bridge is MCP, the Model Context Protocol, which is a standard way for an AI app to call outside tools. The chain looks like this: Claude talks to an MCP server, the server talks to a Ghidra extension, and the extension talks to Ghidra.
The best known server is ghidraMCP. Its tools decompile and analyse binaries, rename methods and data automatically, and list methods, classes, imports and exports. For Claude Desktop you install the extension in Ghidra through File, then Install Extensions, restart, and then edit claude_desktop_config.json under Settings and Developer so it points at a Python bridge script. Another option is Ghidra Headless MCP by mrphrazer, which has 212 tools in 34 groups, is built for agents running inside containers, and was last updated in March 2026. It adds to Claude Code with one claude mcp addcommand. A directory I checked also lists a socket-based GhidraMCP updated in May 2026. So choices are not the problem, and that's part of the mess.
Why bother? Renaming, mostly. Those FUN_ names are the boring part of the job, and a model that reads a decompiled function body and suggests something like parse_config_line can save real time. A Medium series on malware analysis with ghidraMCP says Claude asks permission before it touches Ghidra and that the analysis gets faster and more accurate. I didn’t see timing numbers in the part I read, so I’d treat that as the author’s impression.
One real attempt, and what broke
Strzalinski wanted unlimited lives in River Raid, the Atari game, from a ROM dump. He says Ghidra’s workflow was new to him, so the plan was to let Claude guide him.
Claude’s first move was reasonable. It asked for the MD5 hash of the file so it could look for known ROM signatures, but the MCP tools don’t expose hashing, so that was a dead end. Next, Ghidra had loaded the ROM at address $0000 when Atari cartridges live at $A000. Claude spotted the problem and then said the tools had no write access for that operation, so it couldn’t rebase the file.
Pattern recognition was the win.
Claude worked out the target platform from the hardware registers the code touches, which is the kind of thing a person would need a reference manual for. It then guessed the game was Centipede, with full confidence, and that was wrong. Still, it understood the code structure well enough to search for the classic load, decrement, store pattern and find where the lives counter drops. That’s the actual patch location.
The cost was time and patience. Claude sent batches of tool calls and some took 30 seconds each. Strzalinski also had a complaint I haven’t seen elsewhere: MCP has no standard way to ship a server, no Docker image or npm package, so you git clone and hope. He called setup a troubleshooting ritual and I believe him.
Where I land
Ghidra first, Claude second. Claude helps most with naming and orientation, where a wrong guess costs you one rename. It helps least when the answer needs an operation the MCP server doesn’t expose, because the model can’t improvise around a missing tool, and the rebase problem shows that clearly. Anyone saying AI will replace reverse engineers should look at that River Raid run: wrong game, and a rebase it couldn’t do.
There is a real cost to using it, and it changes how I’d set things up. You’d be pointing an agent at a tool that was still getting path traversal and shell injection fixes this August, and feeding it files that may be malware. So I’d run the whole thing in a throwaway virtual machine on the latest 12.1.x release, with nothing important on it. And I’d leave Claude’s permission prompts switched on.
Try it small
And start without the AI. Write a tiny C program, compile it, it will only take a minute, then import it into Ghidra, run auto analysis and rename one function by hand. Get used to what a FUN_ name looks like and how much the decompiler gets wrong. Add an MCP server after that, once you can tell when Claude’s rename is bad, because sometimes it will be and you won’t catch it if you’ve never done the job yourself.
Github Link: https://github.com/NationalSecurityAgency/ghidra
One loose end from the README. The Python launcher is written as pyghidraRun now, all lowercase after the first letter, and a commit in May 2026 fixed the old pyGhidraRun spelling in the docs. If you copied the old one from a tutorial and it fails on Linux, check the capital letters first.