Reverse engineering: a first look

This entry was reading rather than building, and it sits entirely outside the apprenticeship: reverse engineering – how the field is approached, and a first pass at getting familiar with its two flagship tools, Ghidra and IDA.

It’s worth stating where I started from, because it explains what I got out of it. By trade I’m a web and JVM developer, which means my working life is spent behind two thick layers of insulation from the machine. TypeScript goes through a bundler and then an engine’s JIT. Java and Kotlin compile to bytecode that a JVM interprets, profiles and compiles on the fly. I couldn’t tell you what any of that finally emits as machine code, and I’ve never had a reason to care. Reverse engineering starts from exactly the place I’ve spent a career avoiding: a program in its final form, no source available, and a question.

Ghidra

Ghidra is a software reverse engineering framework created and maintained by the NSA’s Research Directorate. Its own README is clear about why it exists: it was “built to solve scaling and teaming problems on complex SRE efforts”, and the NSA applied it to analysing malicious code and finding vulnerabilities in networks and systems. It was an internal tool before it was a public one.

It went public in 2019. I want to be careful here, because the tidy version of this story – binaries at the RSA Conference, source on GitHub a month later – is repeated everywhere and I couldn’t confirm the sequence from a primary source. What I can confirm: the GitHub repository was created on 1 March 2019 and its earliest tagged builds are the 9.0 series. That is the level of precision I can actually stand behind.

The capability list is disassembly, assembly, decompilation, graphing and scripting; it supports a wide range of processor instruction sets and executable formats, runs interactively or headless, and takes extensions and scripts in Java or Python. It’s Apache 2.0, with one wrinkle worth knowing if you ever plan to vendor part of it: the tree carries a separate GPL/ subdirectory for a handful of components, so “Ghidra is Apache 2.0” is true of the project and not of every file in it.

It’s written in Java, which gave me the odd pleasure of meeting a Java application from the wrong side of the abstraction: installing it means installing a JDK first – JDK 21 for a release build, JDK 25 if you build from source.

IDA, and the tier that matters if you’re a student

IDA, from Hex-Rays, is the proprietary incumbent Ghidra gets measured against. Its licensing is tiered, and the published comparison is more specific than the summaries suggest:

	Commercial use	Disassemblers	Decompilers	Dev kits
IDA Free	No	x86-32, x86-64	cloud only, x86	none
IDA Classroom	No	x86-32/64, ARM-32/64	cloud only	IDAPython + C++ SDK
IDA Home	No	1 of PC, ARM, MIPS, PPC, RISC-V	cloud only, matching	IDAPython + C++ SDK
IDA Pro	Yes	all 60+	2 to 12 of your choice	IDAPython + C++ SDK

Two things I’d have missed by reading a summary instead of the table. First, the free tiers give you a cloud decompiler, not a local one – your binary goes to Hex-Rays to be decompiled. For a hobby target that’s fine. For anything confidential it is the whole decision. And “just buy Pro” does not settle it either: IDA Pro is sold in plans, and the pricing page shows the entry-level Essential plan is still “2 cloud-based decompilers of your choice from the same family”. Local decompilation starts at Expert 2 and runs up to Ultimate (“All local decompilers”). The four-column table above collapses all of that into one Pro column, which is how I nearly got it wrong.

Second, and I only found this because I went looking at the actual page: IDA Classroom is free of charge for universities, engineering schools and professional trainers, and it is strictly better than IDA Free – it adds ARM-32 and ARM-64 alongside x86, and it includes IDAPython and the C++ SDK, which IDA Free flatly does not. IDA Free is the tier everyone mentions; Classroom is the one that’s actually appropriate for someone learning this through a college, and nobody had pointed me at it. That alone justified reading the source rather than a blog post about the source.

The shape of it for a beginner: both routes are free to start on, and the money buys breadth – more architectures, commercial use, and eventually getting the decompiler off someone else’s servers – rather than a different activity.

What a decompiler gives you

A disassembler translates machine code back into assembly. A decompiler goes a step further and reconstructs something high-level from it, and both tools do both. For someone at my level the decompiler is the entire point of entry: I don’t read assembly, and pseudocode in roughly C’s shape is the only view of a binary I can reason about unaided.

The part that took me a while to internalise is what that output is. It’s a reconstruction, not a recovery, and the difference is the whole story.

The misconception I started with: I assumed a decompiler’s job was to get the original source back. It can’t. Compilation is lossy. Names, types and comments are gone the moment the source is compiled, and optimisation rewrites the control flow besides. What a decompiler produces is code with equivalent behaviour, not the author’s code. Ghidra’s defaults make this concrete: a function with no surviving symbol is labelled FUN_ followed by its address, and an unidentified type gets a name based purely on its size.

That lossiness is why the throwaway line in my log turned out to be the real substance: reading decompiled output forces you to think about what your source actually compiles down to. I’d have claimed I understood compilation – I write Kotlin, I know roughly what bytecode looks like, I know the JIT exists – but that knowledge has never been load-bearing. It changes nothing about how I work day to day. Reading a decompiled function, where every helpful name is gone and all that’s left is structure, made the distance between what I write and what runs the subject of the exercise rather than the backdrop.

A week of reading makes me familiar with the vocabulary, not competent. The stated next step was to stop reading and actually drive the tools. I’ve since done that; it went slower than I expected, and that week has its own writeup.

Sources

Read on 25 August 2026. Both tools are documented by their makers, so everything here comes from the vendor or the repository rather than from a tutorial.

NationalSecurityAgency/ghidra – the README, for provenance, the capability list, the Java/Python scripting support and the JDK requirements. Licence is Apache 2.0; note the separate GPL/ subtree in the source layout.
The GitHub repository metadata – repository created 1 March 2019, SPDX licence Apache-2.0, primary language Java. This is what the 2019 dating rests on; I could not source the RSA-then-GitHub sequence to a primary document and have not asserted it.
IDA Free – Hex-Rays’ own tier comparison table, the source of every row above, plus the FAQ confirming IDA Free is non-commercial only and ships no IDAPython or C++ SDK.
IDA Classroom – the free education tier.
Hex-Rays documentation – the supported-processor list behind “all 60+“.