Ghidra from zero: reversing your first crackme

I have everything I need. Writing the post now.

The dialog box that will not open

There is a specific kind of frustration that turns people into reverse engineers. You have a program. It asks for a password, a serial number, a license key. You type something. It says Wrong. You type something else. Wrong. The correct answer is sitting right there, baked into the file on your own disk, and the program simply refuses to tell you what it is. The good news is that the answer really is in there, and with the right tool you can read it. The tool most people reach for now is Ghidra, a reverse-engineering suite built by the United States National Security Agency and given away for free. Its nearest commercial rival, IDA Pro, costs several thousand dollars for full x86 and x64 decompilation. Ghidra costs nothing, and the first thing most people do with it is defeat a crackme: a small program written for the express purpose of being broken. This is a guide to that first session. Not a button-by-button screencast, but the mental model underneath it: what Ghidra is actually doing when it turns a wall of machine code into something that reads like C, and how you use that to find a password the program was trying to hide.

The tool the NSA gave away

For most of its life Ghidra was a secret. Comments in the source code suggest development goes back as far as 1999, and the agency's own analysts used it internally for well over a decade. The public did not learn it existed until March 2017, when WikiLeaks published the CIA's "Vault 7" documents, which referenced the tool by name. Two years later the NSA did something unusual for an intelligence agency: it declassified the whole thing. Rob Joyce, then a senior cybersecurity adviser at the agency, announced the public release at the RSA Conference on 5 March 2019. A month later, in April, the complete source code went up on GitHub under the permissive Apache 2.0 licence. The security researcher Bruce Schneier, writing at the time, called it "a really good reverse-engineering tool" and noted the obvious question hanging over it: why would a signals-intelligence agency hand its own capability to the world? The likely answer is recruitment and standardisation. An analyst trained on Ghidra at university arrives at an agency job already fluent. And an open tool gets battle-tested by thousands of outside users who file bugs the NSA never would. Whatever the motive, the release has held up. Ghidra is now on version 12, with 12.1.3 shipping on 18 August 2026, and it has grown steadily: an integrated debugger arrived in version 10.0 (2021), support for Rust and Go binaries in 11.0, and in the 11.3 release of February 2025, kernel-level debugging, just-in-time P-code emulation, and Visual Studio Code integration.

Why a crackme is the right place to start

A crackme is a program built to be reverse-engineered. Someone writes a small binary that checks a password or generates a serial key, then publishes it as a puzzle for others to solve. The canonical home for these is crackmes.one, a community site where every challenge is tagged with the platform it runs on, the language it was written in, and a numeric difficulty rating so you can start at level 1 and climb. The site is active enough to run its own capture-the-flag competition, the most recent of which wrapped up in early 2026. Crackmes matter for a reason beyond convenience, and it is worth being blunt about it: legality. Reverse-engineering software you do not own, or circumventing protections on commercial software, can run headlong into copyright law. In the United States, Section 1201 of the Digital Millennium Copyright Act makes it unlawful to bypass "technological measures" that control access to a copyrighted work. There is a narrow exception in Section 1201(f) for interoperability, which lets you analyse a program you legally possess in order to make independent software work with it, but it is narrow, and cracking a licence check to avoid paying for software is not what it covers. A crackme sidesteps all of this. It is published specifically so that you will break it. The author wants you to succeed. That makes it the one context where a beginner can practise every technique in this article with zero legal ambiguity, which is exactly why they exist.

What Ghidra is really doing when you press "analyze"

Here is the misconception that trips up almost everyone: people expect Ghidra to hand them back the program's original source code. It cannot, and understanding why is the single most useful thing you can learn on day one. When a developer compiles a C program, the compiler throws away nearly everything that made the code readable. Variable names, function names, comments, type definitions, the blank lines you left for your future self: all of it is gone. What remains is machine code, a dense stream of numeric opcodes that the processor executes directly. Reversing that stream back into something human-readable is guesswork, informed guesswork, but guesswork all the same. Ghidra does this in stages. First it disassembles, translating raw bytes into assembly mnemonics like MOV, CALL, and CMP. That step is close to mechanical. The clever part comes next. Rather than analyse x86 assembly directly, and then ARM assembly separately, and then MIPS, Ghidra translates every architecture into a single intermediate language called P-code. P-code is a small, uniform set of operations, things like LOAD, STORE, INT_ADD, and CBRANCH, that describe precisely what an instruction does to data in registers and memory. Each native instruction decomposes into one or more P-code operations. The rules for that translation are written in a domain-specific language called SLEIGH, which is how Ghidra supports more than twenty processor architectures without rewriting its analysis engine for each one. Add a SLEIGH specification for a new chip and the entire decompiler works on it for free. The decompiler itself, written in C++, performs its data-flow analysis on P-code and reconstructs the C-like output you actually read. The result is a reconstruction, not a recovery. Ghidra invents plausible variable names (local_28, iVar1, uVar2), guesses at types, and structures the control flow as best it can. It is often wrong in small ways and occasionally wrong in large ones. Treating its output as gospel is the classic beginner mistake. Treating it as a very good first draft you refine as you understand more is the professional habit.

Your first session, from binary to broken

Now the actual work. Suppose you have downloaded a level-1 crackme: a small Linux executable that asks for a password and prints either "Access granted" or "Access denied." Before Ghidra, spend ten seconds at the command line. On Linux, file ./crackme tells you the architecture and whether the binary is stripped of its symbols. Running strings ./crackme dumps every run of printable characters in the file, and you will often see the success and failure messages, sometimes the password itself if the author was careless. Even simpler, ltrace ./crackme traces the library calls the program makes as it runs, and a naive crackme will show you a strcmp of your input against the real answer in plain sight. Plenty of level-1 challenges fall to that alone. When they do not, you open Ghidra. Create a project, import the binary, and let the auto-analysis run. This is Ghidra doing everything from the previous section: disassembling, lifting to P-code, identifying functions, and decompiling. On a small crackme it finishes in seconds. Then you follow the strings. Open Window → Defined Strings to list every string Ghidra recovered, and scroll to "Access denied." Here is the technique that makes reverse engineering tractable: a cross-reference, or XREF. Ghidra tracks every place in the code that touches a given address. Right-click the "Access denied" string, choose References → Show References to Address, and Ghidra jumps you to the exact instruction that loads that message to print it. Work backwards from the answer to the question. The code that decides whether to print "denied" is the check you need to defeat. Double-click into that function and read the decompiler pane on the right. On a simple crackme you will see something close to this:

undefined8 main(void) {
    char local_48 [64];
    printf("Enter password: ");
    fgets(local_48, 64, stdin);
    local_48[strcspn(local_48, "\n")] = '\0';
    iVar1 = strcmp(local_48, "sup3r_s3cr3t");
    if (iVar1 == 0) {
        puts("Access granted");
    } else {
        puts("Access denied");
    }
    return 0;
}

There it is. The program reads your input into a buffer, strips the trailing newline, and compares it with strcmp against the literal string "sup3r_s3cr3t". The strcmp function returns zero when two strings match, so iVar1 == 0 is the "you got it right" branch. The password was in the file the whole time; you just needed to read the right sixty bytes.

Reading assembly without flinching

That example was deliberately gentle. Real crackmes, even at level 2, rarely leave the password sitting in a strcmp. The author might build the correct string one character at a time, XOR each byte of your input against a constant, or compute a checksum and compare that. When the decompiler output stops being obvious, you drop from the C-like view into the assembly listing in the centre panel, and this is where beginners freeze. They should not. The assembly a crackme cares about usually reduces to a handful of patterns. A comparison, CMP or TEST, sets processor flags. A conditional jump reads those flags and branches: JE/JZ jumps if the last comparison was equal, JNE/JNZ jumps if it was not. The decision point you are hunting for is almost always a compare followed by a conditional jump, with one branch leading to "granted" and the other to "denied." Find that fork and you understand the check. The two views are linked. Click a line in the assembly and Ghidra highlights the corresponding line in the decompiler, and vice versa. This is how you learn: read the friendly C, then look at the assembly it came from, and slowly the mnemonics stop being noise. You are not memorising an instruction set. You are learning to recognise the shape of a decision. As you go, you rename things. When you work out that local_48 holds the user's input, right-click and rename it user_input. When FUN_00101189 turns out to validate the serial, call it check_serial. Ghidra propagates the new name everywhere the variable appears, and the decompiler output gets more readable with every edit. Reverse engineering is not a single pass; it is an accumulation of small annotations that turn a stranger's compiled binary into something you understand as well as its author did.

Two ways to win

Once you understand the check, there are two philosophically different ways to beat it, and serious crackme sites treat them as separate sports. The first is to recover the key. You read the algorithm, work out what input would satisfy it, and supply that input. If the program XORs your serial with 0x42 and compares it to a stored value, you compute the value that produces a match. Done at scale, this becomes a keygen: a program that generates valid keys for any input, which proves you fully understood the algorithm rather than just one answer. Keygenning is considered the more elegant solve because it demonstrates complete comprehension. The second is to patch the binary. Instead of finding the right password, you edit the program so it accepts any password, typically by flipping the conditional jump, changing a JNE to a JE or replacing the comparison with instructions that do nothing. Ghidra supports patching assembly out of the box: right-click an instruction, choose Patch Instruction, type the replacement, and export a modified binary. Patching is faster and cruder. It defeats one program; it teaches you less about the algorithm. Both skills matter, and knowing which the challenge is asking for is part of reading it correctly.

Where the training wheels come off

Everything above works because a level-1 crackme wants to be understood. The moment you leave that sandbox, the target starts fighting back, and the techniques that defeat a strcmp stop being enough. Malware, the field where these skills earn a living, is written to be unreadable. It arrives packed, compressed or encrypted so that strings and the disassembler see only garbage until the program unpacks itself in memory at run time. It carries anti-debugging checks that detect when it is being watched and change behaviour to mislead you. It obfuscates control flow so the clean compare-and-jump forks dissolve into spaghetti. This is why the demand for reverse engineers and malware analysts consistently outstrips supply: the work does not automate away, and job listings routinely name Ghidra and IDA Pro side by side as the tools of the trade. The honest gap to acknowledge is the decompiler quality. On the gnarled, optimised code that real-world binaries are full of, Hex-Rays, the decompiler inside IDA Pro, still produces cleaner output than Ghidra, and IDA supports more exotic architectures and file formats. Ghidra has closed that gap faster than anyone predicted, its output is often comparable and occasionally clearer, and its headless command-line analyzer makes it superb for automating analysis across thousands of files, a quiet advantage IDA does not match as cleanly. For a beginner, the difference is irrelevant. The tool is free, capable, and used by the same agency that once kept it secret. The password in your first crackme took a few minutes to read. The interesting question is what happens the tenth time, when the author has hidden it well enough that reading the file is not enough, and you have to run it, watch it, and trick it into revealing the answer itself. That is where reverse engineering stops being a puzzle and starts being an argument, between you and someone who did not want you here, conducted entirely in a language neither of you wrote by hand.

Sources

1. National Security Agency, "Ghidra — the Software Reverse Engineering Tool You've Been Waiting for — is Here!", 2019.
2. Wikipedia, "Ghidra", accessed 2026.
3. The Hacker News, "NSA to Release Its GHIDRA Reverse Engineering Tool for Free", 2019.
4. The Hacker News, "NSA Releases GHIDRA Source Code — Free Reverse Engineering Tool", 2019.
5. Security Affairs, "NSA releases the source code of the GHIDRA reverse engineering framework", 2019.
6. Bruce Schneier, "Ghidra: NSA's Reverse-Engineering Tool", Schneier on Security, 2019.
7. Help Net Security, "Ghidra 11.3 released: New features, performance improvements, bug fixes", 2025.
8. NationalSecurityAgency/ghidra, "SLEIGH specification (sleigh.xml)", GitHub.
9. Ghidra documentation, "SLEIGH".
10. Ghidra documentation, "Decompiler Concepts".
11. Hackmag, "Ghidra vs. IDA Pro: Strengths and weaknesses of NSA's free reverse engineering toolkit", 2019.
12. Reverse Engineering, "IDA Pro vs Ghidra: Which Disassembler Wins?".
13. Reverse Engineering, "Ghidra Tutorial: A Beginner's Guide to Reverse Engineering".
14. Crackmes.one, homepage and "Crackmes.one CTF 2026 — A Recap", 2026.
15. Devansh Batham, "crackmes.one — Beginner Friendly Reversing Challenges, Part 1", Medium.
16. Hexg0d, "Reverse engineering a Crackme: A Step-by-Step Guide", Medium.
17. Zero Day Arcade, "Getting Started in Reverse Engineering".
18. Electronic Frontier Foundation, "Coders' Rights Project Reverse Engineering FAQ".
19. Congressional Research Service, "Anticircumvention under the DMCA and Reverse Engineering".
20. CyberSN, "Reverse Engineer / Malware Analyst: Role Overview, Salary & Career Path".
21. Ghidra, "Headless Analyzer README".