Reverse Engineering with Ghidra

When the NSA released Ghidra in March 2019, the most significant thing about it wasn’t that a government agency had open-sourced a tool — it was that they had open-sourced a decompiler. A decompiler that actually worked, on real binaries, across a wide range of architectures, for free. Until that point, if you needed a decompiler you either paid Hex-Rays a five-figure license fee for IDA Pro, used Hex-Rays’ cloud decompiler with all the attendant confidentiality concerns, or made do with the handful of open-source attempts that ranged from incomplete to frankly dangerous to rely on. Ghidra changed the economics of binary analysis for individual researchers, small security teams, and academia overnight.

The case for reverse engineering as a defensive skill is direct: you cannot defend against what you cannot understand. Incident responders who can read a dropped binary determine scope in hours rather than days. Teams evaluating a third-party library can confirm it behaves as documented rather than trusting a vendor’s word. Vulnerability researchers analyzing a patch can identify what was actually fixed — and whether adjacent code contains the same class of bug. This guide walks through Ghidra from the standpoint of a defender: someone who did not write the binary in front of them and needs to understand what it does well enough to make a decision about risk. It does not cover writing shellcode, bypassing defenses, or weaponizing findings — the goal is comprehension, not exploitation.

What Ghidra Actually Is

Ghidra is a full software reverse-engineering (SRE) suite, not just a disassembler. The distinction matters. A disassembler converts raw machine code bytes back into assembly mnemonics — resolves addresses, identifies instruction boundaries, labels branch targets. A decompiler goes further: it reconstructs C-like pseudocode from those same bytes, recovering control flow structures, local variables, and approximate function signatures. For analysts comfortable reading C, the decompiler is far faster to work through than raw assembly on any non-trivial binary.

Ghidra is written in Java, maintained by the NSA’s Research Directorate, and developed publicly on GitHub. Architectures supported span x86/x64, ARM/AArch64, MIPS, PowerPC, RISC-V, 68k, and several dozen others, defined in a domain-specific language called SLEIGH. Adding an obscure architecture is a feasible community contribution — a meaningful edge over IDA Pro’s base installation for embedded firmware and IoT work. The 11.3 release (February 2025) shipped a JIT-accelerated P-Code emulator (JitPcodeEmulator), kernel debugging via LLDB and eXDI, and fully bundled PyGhidra as first-class CPython 3 scripting. By mid-2026 the project has progressed into the 12.x series.

How the Decompiler Works: P-Code and the Reconstruction Pipeline

Understanding the decompilation pipeline at a high level makes the decompiler’s output — including its occasional failures — much easier to interpret.

Source Code
    |
    v
[Compiler: gcc, clang, MSVC]
    |
    v
Native Machine Code (x86_64, ARM, ...)
    |
    v  [Ghidra Loader: reads PE/ELF/Mach-O, maps sections]
    |
    v
[SLEIGH Disassembler: resolves instruction boundaries, mnemonics]
    |
    v
Low P-Code  (direct 1-to-many translation of each instruction)
    |
    v
[Decompiler: SSA conversion, data-flow analysis, type recovery,
             control-flow structuring, dead code elimination]
    |
    v
High P-Code  (simplified, optimized intermediate representation)
    |
    v
Pseudo-C Output  (displayed in the Decompiler window)

P-Code is Ghidra’s architecture-neutral intermediate representation. Every machine instruction — whether it is an x86 IMUL, an ARM LDRH, or a MIPS JAL — is translated into a small set of P-Code operations that model the instruction’s behavior on abstract storage locations called varnodes. A varnode is simply a triple: an address space (register, RAM, stack, constant), an offset within that space, and a size in bytes. The low P-Code translation is mechanical and explicit; it captures flag effects, sub-register aliasing, and implicit writes that assembly notation often elides.

The decompiler converts low P-Code into SSA (Static Single Assignment) form — each varnode write creates a unique new node — then applies constant folding, copy propagation, dead store elimination, and control-flow structuring to recover loop headers, conditionals, and switch dispatch. The final output is pseudo-C: not valid source code, but an approximation readable by a C programmer.

Decompiler quality is proportional to how much information survived compilation. Debug symbols, type information, and calling convention metadata dramatically improve output. Heavily optimized code — inlined, vectorized, aggressively restructured — requires extensive manual annotation. Packed or obfuscated code produces garbage until the packing layer is removed.

The Static Analysis Workflow

Creating a Project and Importing a Binary

Ghidra organizes work into projects, which are directories on disk containing one or more analyzed programs along with their markup, comments, and type information. Before importing anything, create a non-shared local project. The project is your analysis workspace; keep one project per investigation so that annotations, bookmarks, and scripts stay scoped to the relevant work.

Importing a binary (File > Import File) prompts Ghidra to auto-detect the format (PE, ELF, Mach-O, raw binary, firmware image) and the target architecture. For most common binaries this detection is correct. For firmware blobs with no recognized header, you will need to specify the processor, endianness, and base address manually — mistakes here produce nonsense disassembly, so when the format is ambiguous, check the first few bytes against known magic bytes and consult file(1) output before committing.

After import, Ghidra offers to run auto-analysis. Accept it. The auto-analysis pass covers disassembly, function boundary detection, call graph construction, data type recovery, string identification, and FunctionID matching. On a modern workstation, a 5 MB binary completes analysis in under a minute. Larger binaries or firmware images can take considerably longer; Ghidra’s Java runtime makes it memory-hungry — allocate at least 4 GB heap for serious work (set in ghidraRun via the JVM -Xmx flag).

The Main Views

Ghidra’s GUI is dense and configurable. The windows that matter most for day-to-day analysis:

Listing (disassembly view) — the canonical disassembly annotated with Ghidra’s analysis results. Labels, cross-references, data types, and comments all appear inline. This is the ground truth; the decompiler output is derived from what Ghidra knows here.

Decompiler — synchronizes with the Listing to show the pseudo-C for whatever function the cursor is in. Most analysis time is spent here. Double-clicking a called function navigates into it; right-clicking a variable opens rename and retype dialogs.

Function Graph — a control-flow graph view of the current function with basic blocks as nodes. Invaluable for understanding complex branching logic, recognizing obfuscated dispatch patterns, and seeing the overall structure of a function before reading it line by line.

Symbol Tree — a hierarchical browser of all named symbols: functions, labels, exported/imported symbols, namespaces. This is your map of the binary’s logical structure.

Defined Strings — lists every string Ghidra found in the binary with its address and cross-references. Frequently the fastest path to relevant functionality: search for “http”, “cmd”, registry key paths, or error messages to land directly in interesting code.

Bytes view — the raw hex dump synchronized with the disassembly. Used when you need to examine data structures at the byte level, identify encoded payloads, or verify that Ghidra’s interpretation of a byte range is correct.

Core Analyst Tasks

Strings and Imports as First Triage

Before opening Ghidra at all, run a minimal external triage sequence on the sample. This costs nothing and immediately narrows the question space:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# Identify the file type without relying on extension
file suspicious_binary

# List printable strings (ASCII and wide); pipe through sort/uniq for clarity
strings -a -n 6 suspicious_binary | sort -u

# For ELF binaries: inspect sections, imports, and dynamic dependencies
readelf -a suspicious_binary | grep -E '(NEEDED|IMPORT|FUNC)'

# For PE binaries on Linux: use objdump or python-pefile
objdump -x suspicious_binary | head -80

The strings output tells you the immediate story: readable URLs, domain names, registry key paths, Windows API function names, error messages. Suspiciously sparse output on a large binary is a strong indicator of packing or encryption. Inside Ghidra, Search > For Strings lets you filter and cross-reference hits to land directly in the code that uses them.

The import table is the binary’s declared intent. A binary that imports CreateRemoteThread, VirtualAllocEx, and WriteProcessMemory is advertising process injection before you read a single instruction. Imports of RegSetValueEx or service installation APIs signal persistence. Pair this fast-triage pass with your incident response playbook procedures for scoping the incident before going deeper.

Identifying and Naming Functions

Ghidra names undiscovered functions FUN_<address> and unresolved data DAT_<address>. The first substantive task after auto-analysis is to work through the function list, starting from known entry points (the Symbol Tree’s entry label, exported functions, or interesting xref sources), and build a map of what each function does.

FunctionID (FidDB) — Ghidra’s auto-analysis matches function bodies against a database of hashes from known compiled libraries, automatically renaming functions that match _malloc, strcmp, and hundreds of other C runtime or SDK routines. This eliminates noise from statically-linked code. The community-maintained ghidra-fidb-repo on GitHub extends coverage considerably beyond Ghidra’s defaults. For everything that does not match, you rename manually based on behavior — the discipline is cumulative, and every function named reduces the entropy of functions that call it.

Recovering Data Structures and Applying Types

Ghidra emits generic types — int, undefined4, char * — when it cannot determine the real type. Code passing a struct pointer through multiple functions produces *(param_1 + 0x18) at every field access, which is unreadable at scale. Ghidra’s Data Type Manager lets you define a struct, then retype param_1 to a pointer to it — every field access throughout the function and its callees immediately renders as conn->socket_fd or conn->timestamp. This single retype step can transform an opaque function into something comprehensible in seconds.

Following Cross-References

Cross-references (xrefs) answer “who calls this, and what reads or writes this.” Right-clicking any label and selecting References > Show References to lists every location in the binary that touches that item — function, string, global variable. This is how you trace from a suspicious string to the code that constructs it, from an API import to every call site, or from a decrypted C2 configuration buffer back to the decryption routine and forward to every consumer. Xrefs are the graph that makes a binary navigable rather than a linear slog.

Incremental Annotation

The decompiler supports inline comments (Ctrl+; end-of-line, Ctrl+Shift+; pre-comment) and persistent renames that survive across sessions and shared projects. Renaming local_38 to decryption_key takes five seconds and pays compounding returns every time that variable appears further up the call graph. The rename-retype-comment-xref loop, repeated function by function, is the actual practice of reverse engineering — there is no shortcut, only the discipline of building a coherent behavioral model until your original question has a defensible answer.

Scripting and Automation

The Java API and Python/Jython

Ghidra exposes its entire analysis API through a Java scripting interface. Scripts can iterate over functions, query the decompiler programmatically, apply types, add comments, and extract data. The built-in scripting environment (Window > Script Manager) supports both Java and Jython (Python 2 implemented on the JVM), and as of Ghidra 11.3, PyGhidra provides a full CPython 3 bridge.

A minimal Ghidra Python script using the FlatProgramAPI — sufficient for most automation tasks:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

# Run via: Script Manager, or analyzeHeadless with -postScript
# Iterates all functions and prints those with suspicious import calls

from ghidra.app.script import GhidraScript
from ghidra.program.model.symbol import RefType

# currentProgram, currentAddress, monitor are injected globals
listing = currentProgram.getListing()
func_iter = listing.getFunctions(True)

suspicious_imports = {
    "VirtualAllocEx", "WriteProcessMemory", "CreateRemoteThread",
    "NtUnmapViewOfSection", "SetWindowsHookEx"
}

for func in func_iter:
    name = func.getName()
    if name in suspicious_imports:
        refs = getReferencesTo(func.getEntryPoint())
        for ref in refs:
            caller_func = getFunctionContaining(ref.getFromAddress())
            caller_name = caller_func.getName() if caller_func else "unknown"
            print(f"[!] {name} called from {caller_name} @ {ref.getFromAddress()}")

Headless Analysis for Batch Processing

The analyzeHeadless script enables fully non-interactive Ghidra analysis, critical for processing large malware corpora or integrating Ghidra into CI/CD pipelines that scan newly built or received binaries. This is particularly relevant when evaluating third-party or supply chain security concerns at scale.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

# Basic headless analysis: create/open a project, import a binary, run auto-analysis
$GHIDRA_HOME/support/analyzeHeadless \
    /tmp/analysis_projects MyProject \
    -import /path/to/suspicious.exe \
    -overwrite \
    -analysisTimeoutPerFile 300

# Run a post-analysis script to extract strings and imports
$GHIDRA_HOME/support/analyzeHeadless \
    /tmp/analysis_projects MyProject \
    -process suspicious.exe \
    -postScript ExtractStringsAndImports.py \
    -scriptPath /path/to/my/scripts \
    -log /tmp/analysis.log

# Batch-process an entire directory of samples
$GHIDRA_HOME/support/analyzeHeadless \
    /tmp/analysis_projects BatchProject \
    -import /samples/*.exe \
    -recursive \
    -postScript Triage.py \
    -deleteProject   # clean up after export

Ghidrathon and PyGhidra

Historically, Ghidra shipped only with Jython (Python 2 on the JVM). Two CPython 3 paths now exist. Ghidrathon (Mandiant FLARE team) uses Jep to embed CPython interpreters inside the JVM, integrating with Ghidra’s Script Manager GUI. PyGhidra — bundled in Ghidra 11.3+ and the preferred new path — derives from the DoD Cyber Crime Center’s pyhidra project and uses JPype to expose the Ghidra Java API to an external CPython process. Both give you the full Python data science ecosystem against your analysis data: networkx for call-graph similarity, scikit-learn for malware family clustering, or simply requests to push results to a SIEM.

A Safe First Look at an Unknown Sample

The discipline of malware triage has one overriding rule: never execute an unknown sample on a system you care about, or any system connected to a network you care about. The operational environment is an isolated, network-controlled, disposable VM — network interface either fully airgapped or routed through a logging proxy, snapshotted before analysis and disposable after. Treat your analysis environment with the same containment logic you would apply to a compromised host, as covered in the incident response playbook.

Given that environment, the static-first workflow is:

1. File identification. Run file and check the PE/ELF headers. Note the architecture, whether it is packed (high section entropy, section names like .packed, .upx), and whether it has a recognizable compiler signature in the strings output (MSVC runtime strings, GCC build IDs, Go version strings).

2. Entropy check. High entropy across the entire binary (>7.0 bits/byte) is a strong packing or encryption indicator. Ghidra’s Entropy analysis pass, or the standalone binwalk -E tool, will visualize this quickly.

3. Import table review. As discussed above, the declared Windows API imports are the fastest behavioral signal available before any disassembly. A process injection toolkit, a keylogger, and a ransomware encryptor all have characteristic import patterns.

4. String extraction. Search for URLs, domain names, IP addresses, registry paths, mutex names, file paths, and error messages. Hardcoded C2 infrastructure is a common finding even in moderately sophisticated samples. Wide-character strings (strings -el on Linux) catch Windows malware that uses wchar_t throughout.

5. Open in Ghidra. Let auto-analysis run. Navigate to the imports panel and cross-reference each suspicious import to find every call site. Follow the call graph upward from call sites to understand how the malicious capability is invoked. Work through the decompiler view to understand control flow, decode any in-memory decryption routines, and extract configuration data.

The output is a behavioral profile: what does the binary do, what artifacts does it create, what network indicators does it generate, what persistence mechanisms does it use. That profile maps directly to YARA rules, Sigma detections, and IOC feeds. The methodology also parallels sound debugging strategies: form a hypothesis about what a function does, trace through the decompiler to confirm or refute, update your model, repeat.

Ghidra vs. IDA Pro vs. radare2/rizin: An Honest Assessment

When IDA Pro Is Still the Right Answer

IDA Pro’s Hex-Rays decompiler produces consistently cleaner output on optimized x86/x64 code, particularly on MSVC-compiled Windows binaries. The decompiler correctly handles more edge cases, produces fewer spurious casts, and recovers calling conventions with higher fidelity. IDA’s interactive debugger is more battle-tested than Ghidra’s connector-based approach for dynamic analysis sessions that interleave stepping and static analysis. The plugin ecosystem — with decades of accumulated tooling from the commercial security industry — has no peer. For a professional malware analyst at a threat intelligence firm doing daily analysis of production malware, the IDA Pro investment is defensible.

Ghidra’s Real Weaknesses

The weaknesses are worth naming directly rather than dismissing. The Java Swing UI is sluggish and has idiosyncratic behaviors that frustrate analysts coming from IDA or Binary Ninja — window management, keyboard shortcuts, and rendering responsiveness all lag behind native tools. The decompiler produces noisier output on heavily optimized code: excessive casts, spurious temporaries, and inaccurate type recovery on C++ virtual dispatch are common pain points. The integrated debugger, while improved in 11.3, still requires more setup for live dynamic analysis than IDA’s integrated debugger or a dedicated x64dbg/gdb workflow. Headless analysis is powerful but underdocumented; building robust automation pipelines requires significant initial investment in understanding the API.

radare2/rizin’s Niche

radare2 and its community fork Rizin (with the Cutter GUI) occupy a different niche. They excel at targeted, scriptable, command-line-driven analysis where you know exactly what you are looking for — binary patching, small-function analysis, integration into fuzzing pipelines (relevant if you have read the fuzzing for developers guide and want to close the loop from crash to root cause). The r2pipe interface makes radare2 composable with external tooling in ways that Ghidra’s headless analyzer does not match. However, for the kind of full-binary comprehension work that malware analysis requires — navigating a 2 MB binary you know nothing about, cross-referencing imports, recovering data structures, reading thousands of lines of decompiled code — Ghidra’s GUI and decompiler integration are more ergonomic than radare2’s command-line-first design.

Verdict

Ghidra is the right starting point for any team that needs binary analysis capability and does not already have an IDA Pro budget. The decompiler alone, available for free, is what makes it genuinely transformative compared to what existed before 2019. The platform has matured considerably through the 11.x cycle — Python 3 scripting is no longer a workaround, the debugger is credible for kernel-level work, and the community extension ecosystem covers most of the gaps in the base installation. For defenders specifically, the headless analyzer’s batch processing and the scripting API’s ability to automate signature extraction, import table analysis, and string classification make Ghidra viable not just as an interactive tool but as an infrastructure component in automated analysis pipelines.

The honest ceiling: if you are doing production-grade threat intelligence work on complex, obfuscated Windows malware where decompiler accuracy directly affects analysis speed, IDA Pro + Hex-Rays remains ahead on raw output quality. That gap has narrowed considerably, but it exists. Use Ghidra as your daily driver, understand its failure modes on heavily optimized or obfuscated code, and treat IDA Pro access as an escalation path rather than a prerequisite.

The prerequisite for any of this is the operational discipline: an isolated analysis environment, a static-first approach, and the habit of treating unknown binaries as adversarial inputs until proven otherwise. The tools are the easy part.

Sources

• Ghidra 11.3 Released: New Features, Performance Improvements, Bug Fixes — Help Net Security
• What’s New in Ghidra 11.3 — ghidradocs.com
• What’s New in Ghidra 12.0 — ghidradocs.com
• NationalSecurityAgency/ghidra — GitHub
• Decompiler System — Ghidra DeepWiki
• Decompiler Concepts — ghidradocs.com
• Guide to P-Code Injection — PT SWARM
• Exploring Ghidra Decompiler Internals for P-Code — NCC Group
• Ghidrathon: Snaking Ghidra with Python 3 Scripting — Mandiant / Google Cloud Blog
• PyGhidra Python Integration — Ghidra DeepWiki
• mandiant/Ghidrathon — GitHub
• No Symbols? No Problem! — Trellix Research (FunctionID/FidDB)
• ghidra-fidb-repo: Ghidra Function ID Dataset Repository — GitHub
• Headless Analyzer README — grumpycoder.net
• Ghidra Headless Scripts — GitHub (galoget)
• Ghidra vs. IDA Pro in 2026: A Comprehensive Comparison — secybers.com
• Ghidra vs. IDA Pro: Strengths and Weaknesses — Hack Magazine
• Radare2 vs Ghidra — 0x2DeD
• How to Use Ghidra for Malware Analysis — TechTarget
• Ghidra Review 2026: NSA Reverse Engineering Tool — AppSecSanta