Skip to content
Home About Services Portfolio Blog Contact Get Started
AI & Automation

Ghidra: Inside the NSA’s Open Source Reverse Engineering Tool (90,000+ Stars)

Written by

MTD Technologies

Published
Read Time 10 min
Ghidra open source reverse engineering tool analysing a microchip under a magnifying glass

If someone hands you a compiled binary with no source code and asks what it actually does, you have two options: run it and watch what happens, or read it. An open source reverse engineering tool called Ghidra exists for the second option — and it was built by the National Security Agency. With more than 90,000 stars on GitHub as of October 2026, Ghidra is the most widely trusted free framework for taking compiled software apart and understanding how it works. This guide explains what Ghidra does, what it honestly cannot do, how to install it, and the business cases where it genuinely earns its keep.

Ghidra open source reverse engineering tool analysing a microchip under a magnifying glass

What this open source reverse engineering tool actually is

Ghidra is a software reverse engineering (SRE) framework created and maintained by the NSA’s Research Directorate. It spent well over a decade as a classified internal tool — its name even leaked through the Snowden disclosures in 2013 — before the agency released it publicly at the RSA Conference in March 2019, with the source code published on GitHub a month later under the Apache 2.0 licence.

That origin story matters for a practical reason: Ghidra was not built as a demo or a research prototype. It was built to solve what the NSA calls the scaling and teaming problems of complex reverse engineering efforts — analysing malicious code and hunting for vulnerabilities in networks and systems, collaboratively, at scale. When it was open-sourced, the public got the same full-featured toolkit, not a cut-down community edition.

Technically, Ghidra runs on Windows, macOS and Linux. The main application is written in Java with a Swing interface, while the decompiler component is written in C++ and can even be used in standalone form. It is maintained in the open at github.com/NationalSecurityAgency/ghidra, where it has gathered over 90,000 stars and 10,000 forks — and the repository is still actively maintained, with commits landing days before this article was written.

What Ghidra can do: the full analysis toolkit

Calling Ghidra a “disassembler” undersells it. It is a complete analysis environment, and each component answers a different question about a binary:

  • Disassembler — translates raw machine instructions into human-readable assembly for dozens of processor architectures.
  • Decompiler — the flagship feature. It reconstructs C-like pseudocode from compiled machine code, so you can follow program logic without reading assembly line by line.
  • Function graphs — visualise control flow: branches, loops and call relationships across functions.
  • Data type manager and symbol tree — organise your growing understanding of the binary’s structures, variables and functions in one place.
  • Scripting engine — automate repetitive analysis in Java or Python through PyGhidra, with a script manager built into the interface.
  • Headless analyser — run the full analysis pipeline from the command line with no GUI (analyzeHeadless), which makes Ghidra usable inside batch triage jobs and CI pipelines.
  • Debugger — dynamic analysis through GDB, LLDB and WinDbg backends, so you can confirm what static analysis suggests.
  • BSim — similarity search that finds structurally similar functions across a database of analysed samples.
  • Version Tracking — correlates functions between two builds of the same program, which is exactly what you need when diffing a vendor patch.
  • Ghidra Server — shared, versioned projects so a whole team can analyse the same binary collaboratively instead of trading screenshots.

Under the hood, Ghidra describes processors in a specification language called SLEIGH, which is how it supports more than 30 instruction sets — x86, ARM, MIPS, PowerPC, RISC-V and many more — plus a wide range of executable formats. And everything runs in two modes: interactive, through the CodeBrowser GUI, or fully automated.

Ghidra open source reverse engineering tool decompiling a binary into readable code

How Ghidra works: from binary to readable logic

The analysis pipeline follows a clear sequence. You import a binary — an executable, a shared library, a firmware image — and Ghidra’s loader identifies the format and processor. Auto-analysis then disassembles the machine code, and SLEIGH lifts those instructions into an intermediate representation called P-code. The decompiler lifts P-code further into C-like pseudocode, which is what you read in the Decompiler window alongside the assembly listing.

Here is the part newcomers underestimate: Ghidra does not hand you finished understanding. It hands you a workspace. Compilers discard comments, meaningful names and project structure, and optimise logic for speed rather than readability. So the decompiled output arrives full of generated names like FUN_00401020 and guessed data types. Your job — the actual craft of reverse engineering — is to rename functions as you identify them, correct types, define data structures and leave comments. Ghidra persists all of that work in its program database, which is why a week-long analysis compounds instead of restarting every session.

Installing Ghidra: the official path

Installation is deliberately unglamorous, and the project’s own README is the authority. The current stable release is 12.1.4 (September 2026), and the steps are:

  • Install a 64-bit JDK 25.
  • Download the official multi-platform release file — named ghidra_<version>_<release>_<date>.zip — from the Assets dropdown on the GitHub Releases page. Do not download the files labelled “Source Code”; those are not the runnable release.
  • Extract the archive into a fresh folder. Never extract a new release on top of an existing installation.
  • Launch with ./ghidraRun on Linux or macOS, or ghidraRun.bat on Windows. Python-flavoured workflows use ./support/pyghidraRun instead.

One warning comes straight from the project itself: the README carries a security advisory notice, and it should be taken seriously. In September 2026, CVE-2026-100505 disclosed a heap out-of-bounds read in Ghidra’s string handling (versions 9.2 through 12.1.4), where specially crafted binaries could crash the tool or leak adjacent heap memory into the decompiled output. The lesson is structural, not incidental: Ghidra parses hostile input for a living. Keep it updated, check the security advisories, and run it on an isolated analysis machine — never on the same box that holds production credentials.

Ghidra has been popular since 2019, but three things have pushed it back into the spotlight this year. First, the AI agent wave: tools like REA now connect coding agents directly to Ghidra through MCP servers, so investigating a binary is becoming a conversation — ask what a function does, get an answer grounded in the actual disassembly. We track this new breed of agent tooling in our AI tools directory, and Ghidra is the engine underneath several of the most interesting entries.

Second, the economics are unbeatable. The proprietary alternative, IDA Pro, costs thousands of dollars per seat per year. Ghidra costs nothing, carries no seat limits, and its decompiler stands comparison with commercial offerings. For security teams, consultancies and universities, that turns reverse engineering capability from a budget line item into a download.

Third, the world keeps producing more compiled code and less available source: IoT firmware, embedded systems, legacy enterprise software whose vendors no longer exist. Every one of those is a binary somebody eventually needs to understand, and Ghidra is where that work increasingly starts.

From our experience: what actually matters when you adopt Ghidra

We have spent 9+ years shipping software across more than 300 projects, and binary analysis comes up more often than most businesses expect — usually at the worst possible moment. Here is the honest version of what adopting Ghidra involves.

Budget for analyst time, not licences. Ghidra is free; expertise is not. Decompiled pseudocode is a starting point, not an answer. A realistic first engagement — say, understanding what a legacy Windows service does before migrating it — takes a competent analyst days, not hours, because naming functions and reconstructing data types is manual, judgement-heavy work. The tool multiplies a skilled analyst; it does not replace one.

Pick the right tool for the job’s tempo. Ghidra is a heavyweight: JVM startup is slow and a serious session can consume 500MB to 2GB of RAM. For deep, multi-day investigations that is fine. For instant binary triage — “what is this file, quickly?” — lighter tools like radare2 answer faster. Most serious practitioners keep both installed, and you should too.

Automate the boring parts. The headless analyser is the feature businesses underuse. Malware triage, firmware intake checks and regression diffing across builds can all run as scheduled batch jobs — the same kind of unattended pipeline thinking we apply in our AI automation workflows. Write the PyGhidra script once, run it on every new sample forever.

Collaborate properly. The Ghidra Server exists because reverse engineering used to die in chat threads. Shared, versioned projects mean one analyst’s renamed functions and comments are visible to the whole team instantly. If two or more people will touch the analysis, set the server up on day one.

Know when NOT to reach for it. Ghidra is an analysis tool, not antivirus software — it cannot certify a file as safe. Heavily obfuscated or packed binaries will fight the decompiler and need unpacking first. And no decompiler output can be rebuilt into the original project; if you need to modify and recompile, you are looking at a rewrite, not a round-trip. For that kind of custom software rebuild, start from the analysis, not from the binary.

Security team collaborating on malware analysis with the Ghidra open source reverse engineering tool

Reverse engineering is dual-use by nature: the same workflow that audits a vendor binary for backdoors can be turned toward building malware or bypassing licences. The bright line is authorisation — analyse only software you own, software you have explicit permission to analyse, or software where the law in your jurisdiction permits it, such as interoperability research. Keep analysis in isolated environments, document your chain of custody for samples, and treat anything you learn about a third party’s software as their confidential information until you have reason to believe otherwise.

Getting started in 30 minutes

The fastest way to learn Ghidra is on a binary you compiled yourself, where you already know the answer and can check the tool’s work:

  1. Install 64-bit JDK 25 and download the Ghidra release zip from the GitHub Releases page.
  2. Extract it to a fresh folder and launch ./ghidraRun (or ghidraRun.bat on Windows).
  3. Create a new non-shared project: File → New Project.
  4. Write a tiny C program — a main that prints a number — compile it, and import the binary with File → Import File.
  5. When prompted, run auto-analysis with the default analysers and wait for it to finish.
  6. Double-click the binary to open it in CodeBrowser. The Decompiler window shows the C-like pseudocode next to the assembly listing.
  7. Find your main function in the Symbol Tree, rename a generated variable to something meaningful, add a comment, and save. You have just done real reverse engineering.

Frequently asked questions

Is Ghidra really free for commercial use?

Yes. Ghidra is released under the Apache 2.0 licence, which permits commercial use, modification and distribution with no seat limits or fees. There is no enterprise edition held back — the public build is the full toolkit.

Is Ghidra safe to use, given the NSA built it?

The complete source code is public and has been audited by a large open-source community since 2019, which is precisely what settled the early backdoor suspicions. That said, treat it like any powerful tool: keep it updated, read the project’s security advisories before analysing untrusted binaries, and run it on an isolated machine.

Ghidra vs IDA Pro: which should my team choose?

IDA Pro remains a polished commercial product with excellent support, and many professionals use both. But for most teams the deciding factors favour Ghidra: zero licensing cost, a decompiler that stands comparison, scriptability in Python, and the collaborative Ghidra Server that IDA’s base product does not match. Start with Ghidra; buy IDA only if a specific workflow demands it.

Can Ghidra decompile any binary back into source code?

No — and this is the most common misconception. Ghidra produces C-like pseudocode that reveals program logic, but variable names, comments and original structure are gone for good, and heavily obfuscated or packed binaries resist analysis until unpacked. You get understanding, not a rebuildable project.

Does Ghidra work on Windows, Mac and Linux?

Yes, all three, from the same multi-platform release. You need a 64-bit JDK 25 installed; Python 3 is only required for debugger, PyGhidra and full source-build workflows, not for basic CodeBrowser and decompiler use.

Sitting on compiled software nobody fully understands — a legacy system, a vendor binary, firmware headed for production? That is exactly the kind of problem we help businesses untangle. Talk to our team and we will tell you honestly whether reverse engineering is the right move, and what it will take.