Ghidra and IDA, hands on

Three weeks ago I wrote up my first look at reverse engineering from the reading side: what Ghidra and IDA are, and what a decompiler actually hands you. This entry was the follow-through – using the tools rather than reading about them.

The honest thing first, because it’s the more interesting half: it was slower going than I expected, by a wide margin. The reading had given me the vocabulary but none of the reflexes, and the distance between opening a tool and answering an actual question about the program in front of me was much larger than I’d assumed.

Why it’s slow

The mechanics are simple to describe. Auto-analysis produces a listing and a set of best guesses. Functions with no surviving symbol get default labels – Ghidra’s is FUN_ followed by the address – and unidentified data types are named after their size and nothing else. From there the loop is: form a hypothesis about what something is, rename or retype it, follow the cross-references, check whether the picture still holds together. No single step is difficult. The cost is that nothing in the listing is labelled by anything that cares about meaning, so every hypothesis needs a detour to confirm, and an early guess that’s wrong quietly poisons everything downstream of it.

With source, a question like “who calls this?” is one jump to a definition and a glance at the references. Without source, the tool can show you the references but cannot tell you what any of them mean. Working that out is the actual skill, and a week of reading had not installed it.

The fundamentals it drags back out

The value the log entry records, and I’d agree with it, is the fundamentals this work forces you back to: calling conventions and memory layout. Both were pure vocabulary to me a month ago.

A calling convention is the contract for a function call: where the arguments arrive, where the return value goes, and who restores the stack afterwards – registers or stack, caller or callee. The compiler emits code against that contract; a decompiler has to invert it. Ghidra models the convention as part of each function’s signature, alongside parameter types and where each parameter lives, and the pseudocode you read is only as good as those assumptions. Get them wrong and you don’t get an error. You get confident nonsense.

Memory layout is the other one. In decompiled output a structure is not a thing; it’s a base address plus offsets, and the struct only exists once somebody imposes one. What’s a pointer and what’s an integer, how big each field is, where alignment leaves gaps – those are judgements you’re making, not facts you’re reading off. Nothing in my working life had asked me to hold all that in my head. On the JVM the runtime lays out objects and I never see an offset; in TypeScript a number is a number and where it lives is somebody else’s problem.

That’s exactly why the material I usually read – performance write-ups, security research – tosses off phrases like “assuming the usual calling convention” or “the field at offset 16” as assumed knowledge. It is assumed, universally. I had just never been on the side of the assumption that has to use it.

Where this leaves me: still slow, if I’m honest. But the machine my code actually runs on is less of a black box than it was a month ago, and “what does this compile down to?” has moved from a question I could ask to one I partly know how to answer. For a frustrating week, that’s a decent return.