Ghidra 9.2 | Hacker News Reader

Ghidra 9.2

ghidra-sre.org

203 pointsKindOne78 comments

For anyone looking to learn Ghidra and finding it a little overwhelming, a Ghidra book was recently released. I'm finding it very helpful so far.

https://nostarch.com/GhidraBook

I'd also highly recommend the training course slides that are included in the Ghidra distribution. The "Advanced" course especially covers some cool tricks and ways Ghidra is different from IDA/Binary Ninja.

A review of the Ghidra book

https://maxkersten.nl/2020/09/13/a-review-of-the-ghidra-book...

SANS FOR610: Reverse Engineering Malware also has updated content to teach Ghidra.

Unless it changed since it incorporated Ghidra, SANS FOR610 has a very shallow look into actual static reversing of native code.

It's a good introduction but does not venture far.

Reprising a previous comment: this book is good, but fair warning that it's not, like, a fun read; it's like one of those books from the 1990s that explains every dialog box in Microsoft Word. It's an excellent reference, but if you're just getting started reversing, Eidad Eilam's _Reversing_ is still a good choice.

Part of the reason I keep saying this is, if you've done reversing work with IDA or Hopper, you can fumble your way to productivity with Ghidra without a book. So: if Ghidra is completely greek to you, start maybe with fundamentals.

I just started with https://hackaday.io/course/172292-introduction-to-reverse-en...

Currently, I don't get Ghidra that much. But I appreciate the decompiler. While it isn't perfect, it reverses simple functions to C like pseudo-code a lot faster than I can (not that I'm fast at that anyway). Combining it with the free version of IDA (the disassembler, not the decompiler of IDA) has helped me a lot with hackthebox.eu challenges :)

I've never tried IDA Pro's decompiler, but my most recent experience with the Ghidra decompiler had me going back to my tried-and-true hand decompilation steps. (Admittedly, the function in question had a switch statement that had sparse and dense cases (with holes in the dense block!), which is definitely going to do a decent job of confusing native decompilers).

Oh dear, yea no switch statement when I needed to use it. A lot of byte/bit flipping.

I've used Hex-Rays (IDA Pro's decompiler); not full-time, but 100+ hours, including professionally. My information is a few years out of date, but I think most of it is still current. I've also used Ghidra (9.1) for maybe 50 hours or so.

First, let me say: Both are leaps and bounds above _anything_ else out there. Stuff like Hopper is basically just assembler code in a different syntax; Hex-Rays and Ghidra are real, working, useful decompilers. Hex-Rays charges four-figure sums for single licenses, and it's because the product is utterly worth it if you do this kind of thing for a living (or at least was before Ghidra came along). I would estimate it speeds up reverse-engineering by 10x. There's a wonderful interactivity where the decompiler does all the boring book-keeping for you, and you keep feeding it info and it tells you stuff in return. Decompiling is often about figuring out data structures; both will infer a lot of struct types and sometimes even names based on usage and surrounding code. This is _so incredibly useful_. When you give a field a type or a name, it propagates throughout the program and gives you new understanding.

Both products are weird and have arcane UIs. IDA/Hex-Rays feels more ergonomical to me, though (for instance, highlighting happens automatically instead of having to middle-click), perhaps because it's what I started on. Both have strange bugs that you eventually learn to work around. Both have lots of bells and whistles only advanced users will get to use.

Hex-Rays' output feels much more polished to me. It recognizes a lot of compiler idioms, and every new release recognizes more. On the other hand, Hex-Rays only supports a few select platforms (when I started, it did 32-bit x86 only; now it does x86, x86-64, arm, aarch64, ppc, ppc64, mips), and you have to pay for it separately. Ghidra supports decompilation for almost all targets it can disassemble! This either is huge, or doesn't matter to you at all.

Hex-Rays' support is amazing. You report a bug, include a specialized program database by means of a function in the GUI, and four hours later, you receive an email with the bug fixed. On the other hand, Ghidra is free and Hex-Rays is the most expensive software I've ever used, which is obviously a huge deal for anyone not doing this full-time. (The Hex-Rays license lasts for only a year, but after the license is expired, you can still use the software. You just don't get support or newer versions.) If Ghidra cost $500 (for a permanent license), I would probably consider getting it, but it happens to be $0. Fantastic value for money.

If I could choose only one, and cost didn't matter? I'd probably go with Hex-Rays.

My experience with IDA versus Ghidra is that I would still vastly prefer IDA. Even without the decompiler, I found IDA's structure support quite useful for managing disassembly, and Ghidra's structure editing tool and assembly renaming were pretty poor when I tried playing with it, which is why I ultimately ended up resorting to editing objdump disassemblies to decompile the code, relying on Ghidra for the vtable analysis.

However, I use these tools strictly on a hobbyist basis, and I'm not sure that IDA Pro's price tag is really worth it. I think I might have a copy of IDA Free kicking about before they really gimped it, but what I really want is a working IDA on Linux.

The structure editing tool is less fluid, yes. It's one of many ergonomy things, although you can get used to it with some wrangling.

When I was in the cracking scene (over a decade ago now), cracking your own copy of IDA Pro was considered somewhat a "rite of passage", because the authors obviously expected it and made it more difficult. Nonetheless, cracked copies still appear.

The main problem is getting the IDA binaries in the first place.

How does one enter the cracking scene? seems very fun!

I've used Hopper a lot to assist with reverse engineering, and in comparison the Ghidra decompiler blows its equivalent out of the water.

Hopper hits a beautiful sweet spot for casual disassembly, I find it way easier to pick up again after 6 months than Ghidra or IDA. That said Ghidra's decompiler is freaking awesome, the only thing it seems to choke on are monster-sized binaries (try feeding it the Skype core lib for example)

Large binaries is one thing where the new release of Ghidra is significantly better. I've been building from master for months, because large binaries (100MB or more) take low tens of minutes, not hours, with the improvements.

Hopper is unparalleled for decompiling Objective-C code; outside of that its decompiler is simply mediocre.

I use cutter[1] as it's gives a better UX with same Ghidra decompiler.

[1]: https://cutter.re

Previous discussion when it was announced back in 2019, with 400+ comments:

https://news.ycombinator.com/item?id=19315273

Is there a database of already analyzed objects? For example, can I search on the sha256sum of my IoT device's firmware and see if someone else has done the heavy lifting?

That would be awesome, like GhidraHub or something

I'm not well versed in the legality of publishing those databases, as some discussions I've heard elsewhere treat them the same as the object code they annotate and thus it would be like publishing the .exe from Photoshop. I would guess it's possible to separate the annotations from the object code, similar to the way subtitle files are shared for the movies, but similar to a wrong subtitle file, it would take some doing to discover it and more doing to try and rescue the annotations if they could apply to a slightly different but still applicable binary

No.

I know IDA has a "Lumina" database.

https://www.hex-rays.com/products/ida/lumina/

Someone has made a public "Lumina" database for IDA.

https://lumen.abda.nl/

If you don't have a legit copy of IDA, you can always pirate a copy and use that public "Lumina" server.

V Nice. Thanks for the Lumen link.

If there was any public documentation on the "Lumina" protocol, one could create a Ghidra plugin that interacts with the server. Sadly, I don't have a copy of IDA (and therefore cannot reverse engineer the protocol) and the author of lumen.abda.nl hasn't released the source code.

I'm sure Ghidra's creator's have one

Hehe yeah, but it's a Cassandra cluster ;)

Still waiting for a built-in debugger like IDA has

Not built in, but useful:

- edb (https://github.com/eteran/edb-debugger)

- x64dbg (https://x64dbg.com)

Radare2[0] has a debugger (among other things), and can integrate with ghidra's decompiler[1].

0. https://rada.re/

1. https://github.com/radareorg/r2ghidra

The latest news on that debugger is from a reply to an issue [0] on June 17th, 2020:

>As @ryanmkurtz mentioned work is continuing on the debugger, it is a large job and there have been many issues that have come up, not the least of which is COVID. We would really like to give you a timeline, but I don't want to promise anything and not deliver in a timely manner. Dynamic analysis and easy integration of dynamic information is important to the Ghidra community as is evidenced in the thread.

>IMHO, I would not hesitate to learn/use any tool, as the knowledge gained can always be ported to another tool. Time spent learning other debuggers, such as gdb or windbg, will not be wasted as the new Ghidra based debugger will be integrated with existing debuggers or have considerable overlap with their command sets and functionality. That said, if another tool fits your needs, use it. There are many great things about each RE tool and reasons to use or not use each.

>Rest assured we are diligently working on the debugger and we think it will be worth the wait. We'll share information on features and release when we have solid timelines.

>Thanks for using Ghidra in whatever way fits your work. Feel free to request features/improvements you see lacking and we and the community will try to address them.

>We'll close the issue for now.

--------------------------

Also from the What's New 9.2 release notes:

>Dynamic Analysis Framework - Debugger

>The debugger is very much still in progress. You may have seen some commits, in the Ghidra GitHub master branch, to get in sync with the debugger. Stay tuned for more on the Dynamic Analysis Framework soon after the 9.2 release.

[0] https://github.com/NationalSecurityAgency/ghidra/issues/24#i...

Have you tried https://github.com/bootleg/ret-sync ?

It's likely that some others here have followed along with the old Flash based Lena tutorials at some point. Are there any modern resources in a similar vein? What I found fulfilling about them was that some (all?) sections talked you through reversing/keygenning actual applications, rather than simple CrackMes.

I know there are projects from OWASP etc with a realistic site for learning web security, but I don't know any realistic installed software for teaching in the same style with multiple targets in the same package.

I’m curious. Is Ghidra the state of the art? Does the NSA have something better internally?

Non NSA employee don't know the answer. NSA employee can't answer. So I think this question will have no answer unless you join NSA.

As far as I recall, Ghidra was in Wikileaks' 7 NSA tools from 2013. If Wikileaks got the state of the art then, it means that the NSA had around 5 years until Ghidra was released to get something better.

I don't think so. I remember reading that one reason they open-sourced it was that they didn't want to have to retrain every hacker they hired to use Ghidra instead of IDA or something else. They're probably holding stuff back, it's the NSA after all, but Ghidra is probably still their tool of choice.

Ghidra itself is still what they use, they released it so that potential hires don't have to be retrained from IDA Pro. What they don't release, however, is Ghidra plug-ins. I'm sure they have a vast trove of plug-ins for specific reverse engineering they do, and probably some that check for known holes they can exploit.

This is named after the three-headed dragon from the Godzilla cinematic universe, right?

I don’t think it is.

King Ghidorah is the 3 headed monster from the Godzilla universe.

Certainly seems like it is...

It's very possible. The Japanese pronunciation of hydra can be written as either Ghidorah (as seen in Godzilla) or Ghidra (as seen in Final Fantasy), among others, in English.

And the Greek pronunciation is "eedra", which has a lot fewer sounds than the above.

Good to know. As a Godzilla fan, I didn’t know that. Thanks for the info.

I strongly suspect that is the case, especially considering the logo :)

"Ghidra" sounds like "غدر" which is Arabic for "treachery" which is funny since this was released by the NSA.

Where can I hear the correct sound of "غدر"? Google Translate reads it "ha-zi-bo-m", Bing Translator reads it "laz-bo-m", both are not like "Ghidra".

The transliteration of the Arabic would be gh-d-r. (Note that Arabic doesn't normally write out its vowels). The `gh' should sound roughly like the voiced variant of the final sound of "loch" or "Bach".

Given that your purported translations all have four consonants in them, not three, I'm guessing you somehow pasted the wrong string? When I get "غدر" in Google Translate, I get the transliteration as ghadar and not ha-zi-bo-m.

You can use Google translate. This is how "ghadara" is pronounced which actually translates to "committed treason".

https://translate.google.com/?sl=ar&tl=en&text=%D8%BA%D8%AF%...

Here I added a couple diacritics (just to make it sound just like "ghidra".

https://translate.google.com/?sl=ar&tl=en&text=%D8%BA%D9%90%...

I think it's named after a monster from a Final Fantasy game.

Correct, they just spelled it differently to avoid search etc confusion.

So are we not concerned this is coming from the NSA anymore? Genuinely asking, as imo they wouldn't try to sneak something in the very first time it was released, all eyes were on them, but now?

Open source, so no, we're not.

Sometimes the best place to hide something is in plain sight :)

Of all the things on the NSA priority list, it seems like trying to inject malicious software into the wild via random reverse engineers computers seems like the best use of their time.

open source means you can review the code. pretty sure, since this comes from them, is intensely scrutinized. So again, not worried.

Generally, no. Consider that the people who use this tool are probably the best to find malicious things in it.

Except... isn't this a couple of million LoC? Doesn't the mere act of finding malicious things in it require some serious time and effort not likely to be accomplished by individuals?

It's not just individuals using it, though.

Sure, but do you think companies using it can allocate some of their budget to audit the _entire_ codebase?

tbh, I just assume my computer already has about six dozen NSA rootkits in it already, so what's a couple more? :)

Yeah - once you've admitted your adversary is the NSA, you've already lost. Cosplaying secret agents with state level support is not going to end well.

"Threat: The Mossad doing Mossad things with your email account. Solution: Magical amulets? Fake your own death, move into a submarine? YOU’RE STILL GONNA BE MOSSAD’ED UPON"

-- https://www.usenix.org/system/files/1401_08-12_mickens.pdf

Thank you for this article and the joy it has brought me!

The realistic threat model for a common person is an agency that doesn't have resources to target them personally but is happy to steal their private data if they can cheaply do it on a mass scale.

A fair point. Consider that the NSA has the ability to push code changes faster than the open source community can analyze. Also, it's entirely conceivable that the NSA has the expertise to inject RCE vulns into the codebase, and make it look like an honest mistake.

Super secret spy agencies are much less competent than you'd be led to believe. I'd be more afraid of Google and Facebook.

I would not say that they are not competent, but you are absolutely right about Google/Facebook/Amazon, the big difference is, the NSA/CIA have to justify their actions...Google/Facebook not so much.

Very naive. The CIA is per definition a lying, criminal, state-protected enterprise, which is accountable to no one. Not to the oversight committee and for sure not the president. They just keep lying, doing their own secret wars, media interference and election busting. Being fascist should also be concerning to some. There are tons of books on that. The only oversight was the Church commission, once. They collect and fabricate so much dirt on everyone that oversight is impossible.

The NSA being accountable is also news to me. They routinely violate their own constitution, and many other laws. They also cooperate with said criminals, and similar criminal enterprises worldwide.

Apparently most don't have an issue with LinuxSE either.

SELinux is from NSA, so they're already in your kernel.

Just tell me why should the NSA expose itself with their own software..especially software that targets not only programmers but highly specialized software analysts? Your Plastic Router and your half-secured OS is a much better target...and your ISP (because metadata is the most important thing to start and justify a targeted attack).

Anyone know if there’s a changelog available anywhere?

https://ghidra-sre.org/releaseNotes_9.2.html#9_2

This is a lot more complete than I needed it to be. Thanks :)

Is there a repo for popular Ghidra scripts?

I can't comment on its usefulness, but I know of https://github.com/AllsafeCyberSecurity/awesome-ghidra#readm...

Reply on news.ycombinator.com