Hacker News Reader

Comment by roblabla | Hacker News Reader

Too little, too late. I'll keep using Ghidra, which is free, open source, and doesn't crash every time I look at it wrong, thank you very much.

Ghidra is absolutely amazing - I've been using it since release and it's been a huge breath of fresh air compared to the hot mess IDA is. Ghidra has great APIs, which are really well documented. It has a very powerful decompiler. It comes with a built-in, programable emulator for every platform! It has a built-in way to do collaborative reverse engineering! And it's super easy to modify the Sleigh if there's something that needs tweaking to improve the decompiler output!

Not to mention, adding your own CPU is reasonably simple - all you have to do is write a "Sleigh" description of your architecture (basically map CPU instructions to PCode) and it gives you the disassembler, decompiler, and emulator for free.

View on HN

>One processor family of choice from the most common processors: PC, ARM, M68K, MIPS, PPC

This is quite unbelievable for me. Granted, a home user could reasonably only use one of these and be fine. But in the face of Ghidra's processor support, this is laughable.

Exactly, I've used IDA for 15 years, and loved it. But since Ghidra was released, I didn't need to open IDA anymore. Ghidra simple killed IDA and I couldn't be happier about it.

Imagine how bad it was for them. A free niche product killer springs up over night.

I've only just heard of Ghidra so I was happy to see your comment. I had a quick question - what is the learning curve like for Ghidra?

I noticed earlier this week that there is a forthcoming book from NoStarch about Ghidra. There's a sample chapter available in case anyone is interested:

https://nostarch.com/GhidraBook

coupon: OPERATION

I’ve been picking up both ghidra and ida and have found ghidra to be much simpler.

I think IDA's 'killer feature' over Ghidra is supposed to be the debugger. Not disagreeing, I am a Ghidra user myself, just that's the reason I usually see proffered in the Ghidra/IDA flamewar.

That's very true. Ghidra is going to get a debugger soon (there was some activity in the issue tracker about this recently), and already has some amount of dynamic analysis support through its emulator feature. But right now, IDA's debugger is pretty much best-in-class.

I mostly use Ida for exploit development, and have been struggling to find ways to connect the debugger to a proc spawned by pwntools. It’s much easier to use gdb-gef and pwntools directly. I don’t know how much of a killer feature the debugger is to others, but to me ghidra still seems easier to use.

I agree, my only issue with Ghidra is that you can't patch and then export a modified binary, which you can do in IDA.

You haven't been able to work-around that have you?

You actually can, here's a video that shows how to do it:

https://www.youtube.com/watch?v=8U6JOQnOOkg

Tl;dr - press Ctrl+Shift+G on the instruction you want to modify and it will outline the instruction in red, allowing you to modify it.

That being said, it doesn't work for all architectures, and Ghidra will pop up with a rating box when you press Ctrl+Shift+G, explaining the compatibility/support for your current processor (for example, amd64 binaries are considered a "GOLD" rating, meaning there's an extremely high chance of your modification working correctly)

Patching actually works for every architecture, since it's backed by sleigh (and disassembly wouldn't even work without that). AFAIK, The problem (and the reason behind the popup) is that on some architecture, the sleigh might give ambiguous assembly instructions, so the assembler might not select the right instruction if there are multiple possibilities.

But the biggest problem is, exporting a runable binary is not currently supported by Ghidra. Ghidra has a Binary Export function, but it's used as a sort of memory dump. It won't try to make a runnable program. This is by design, see issue #19[0]. It will probably work for RAW images, but that's it.

Exporting a runnable binary is a highly desirable feature, though I can't find any issue tracking it. There's an open PR, #1505[1], that might provide people what they need.

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

[1]: https://github.com/NationalSecurityAgency/ghidra/pull/1505

Yup this is exactly what I meant. I don’t understand why it’s not a feature. Surely it limits Ghidra significantly

The real winner for that is probably Binary Ninja. It has a built-in compiler that is well-suited for patching binaries.

IIRC Ghidra is pretty amd64-centric. IDA on the other hand has dozens of less-known CPUs types, you need when dealing with embedded and not so common stuff.

What? No! Ghidra has support for many, many less-known CPU types. With extremely good support. I recently RE'd Intel 8051 firmware, with really good results. I'm aware of people using Ghidra to reverse firmwares of all kinds, from the PS2 Emotion Engine to Nvidia Falcon Security Processor.

The amazing thing about Ghidra is that all of its tools (disassembler, emulator, decompiler) work on P-Code, which is Ghidra's IR. All you have to do to get the tools to work is write a Sleigh file, which basically describes the registers, address spaces, and map the instructions to P-Code. This is dead easy to do, and with very little tweaking, gives really clean decompiler output. A friend of mine implemented Nvidia Falcon support to Ghidra in a week-end or two[0].

As far as built-in processor goes, Ghidra has X86 16/32/64, ARM/AARCH64, PowerPC 32/64/VLE, MIPS 16/32/64/micro, 68xxx, Java / DEX bytecode, PA-RISC, PIC 12/16/17/18/24, Sparc 32/64, CR16C, Z80, 6502, 8051, MSP430, AVR8, AVR32, and variants of these processors. I dunno if IDA has more, but it's still far from AMD64 centric!

[0]: https://github.com/Thog/ghidra_falcon

> PS2 Emotion Engine

Ghidra is very useful for reverse engineering video games and all related technology! There are blogs showing how to do it:

https://cturt.github.io/pinball.html

As an embedded reverse engineer, I recently made the jump to Ghidra and haven't had any issues yet. I've been reverse engineering Infineon Tricore firmware and it's been great, though I will admit their support for it only came out recently.

Reply on news.ycombinator.com