cat posts/2019-03-12-ghidra-first-impressions.md

Ghidra, a reverse engineer's first impressions

· 4 min read · reverse-engineering security tools ctf

It’s still a bit strange to type “the NSA’s reverse engineering tool” and mean something I downloaded from a public website. Ghidra 9.0 came out at the RSA Conference last Tuesday, with Rob Joyce doing the talk, and the binaries are up at ghidra-sre.org. The source is supposed to follow on GitHub. People have known the name since the WikiLeaks Vault 7 dump in 2017, so the existence wasn’t a surprise, but the license is. It’s Apache 2.0.

My setup for this kind of thing has been the free version of IDA for anything 64-bit x86, radare2 when I want to script something or I’m on Linux and can’t be bothered, and a lot of patience with assembly, because the Hex-Rays decompiler costs a few thousand dollars and I’ve never been able to justify it for a hobby. Ghidra ships with a decompiler. For free. For x86, ARM, MIPS, PowerPC and a long list of other things. That’s really the whole story, but I tried it properly anyway.

The test

I picked a crackme from a CTF a couple of years back that I’d solved in IDA Free, so I knew the answer. It’s a small stripped 64-bit ELF that reads a key, runs it through a loop that mixes each byte with a constant table and the previous result, and compares against a buffer in .rodata. In IDA it took me most of an evening the first time, the bulk of it spent drawing the loop out on paper to work out which register held what.

In Ghidra, after the auto-analysis finished, I found the comparison from the “wrong key” string’s cross-references and hit the decompiler window. It showed me roughly this:

for (i = 0; i < 0x20; i = i + 1) {
    acc = (acc ^ (uint)(byte)input[i]) + (uint)(byte)DAT_00102040[i];
    local_48[i] = (char)acc;
}
iVar1 = memcmp(local_48, &DAT_00102060, 0x20);

Ugly variable names, some pointless casts, but correct. Rename a couple of things, retype one array, and it reads like the source. Reversing the loop and writing the keygen took about twenty minutes, most of it me double-checking the byte order in Python because I didn’t believe it was this easy. I’d be lying if I said I wasn’t a little annoyed about the evening I spent on it the first time.

The rest of it

It’s a Java Swing app and it looks like one. It needs JDK 11, which on my Mac meant installing a JDK I didn’t have, and on Windows it’s a batch file that launches it. The UI is dense and keyboard-heavy and nothing is where IDA muscle memory expects it. After a few evenings I’m getting used to it, but day one was a lot of hunting through menus.

Things I like beyond the decompiler: it has undo, which IDA doesn’t, and after years of renaming the wrong function and living with it that feels like a luxury. It works on projects that can hold many binaries, and there’s a server mode so a team can work on the same project at once, which I haven’t tried but which I can see being nice for a CTF team. Scripting is Java or Python, though the Python is Jython, so 2.7, so not quite the Python you’re writing everything else in. The processor definitions are in its own language, SLEIGH, which means people can add architectures without NSA’s help. I expect we’ll see some of that soon.

Things I don’t like, or can’t tell yet: there’s no debugger, so for dynamic work I’m still in gdb or x64dbg next to it. And there’s the obvious question of whether you want to run a tool from the NSA on your machine. I’m fairly relaxed about that, since it’s an open download that thousands of reverse engineers are going through with a fine-tooth comb right now, and the source is coming. That combing has already turned up one real problem: Matthew Hickey pointed out that if you launch it in debug mode, it opens a Java debug port on all network interfaces rather than just localhost, and anyone who can reach that port can run code on your machine. It’s not the default mode and it looks like a sloppy oversight rather than anything sinister, but don’t use debug mode on a network you don’t trust until it’s fixed.

Will it replace IDA? For me, someone who never paid for Hex-Rays, it already has for static work. For professionals with an IDA Pro license and fifteen years of IDAPython scripts, probably not this year. IDA is faster and still the better disassembler on the weird stuff. But a free decompiler that’s this good changes what a student or a CTF beginner can learn on, and I’m a bit jealous of them. I learned on DEBUG.COM and Turbo C’s inline assembler.