3 ms·

I think a lot of the people that say how much better ghidra is, just started reversing and use the decompiler a lot. The workflow and UX of IDA is so much bette

I think a lot of the people that say how much better ghidra is, just started reversing and use the decompiler a lot. The workflow and UX of IDA is so much better. I guess there are a lot of people that just click around in the UI but for a keyboard based workflow, Ghidra has a lot of catching up to do even to IDA 4.x.

blincoln 4y ago
I've been doing RE work off and on for about twenty years. IDA is a solid tool with some really neat features[1], but the only reason I use it anymore is if I need to look at a binary that's for an architecture so obscure that Ghidra doesn't support it yet. I like Ghidra's interface better, but I'm also not a keyboard-first type of user. I work with a lot of different OSes and software. I stopped trying to remember most keyboard shortcuts 10+ years ago, because there were too many variations, and the consequences of using the wrong one can be dire. Releasing and open-sourcing Ghidra was a truly magnificent gift by the NSA, and I can't thank them enough for it. [1] I'd love to see a Ghidra equivalent of Lumina, for example.
- kuroguro 4y ago
  There's an open source Lumina server, writing a plugin for Ghidra wouldn't be too difficult, here's some details on how they hash functions: https://github.com/naim94a/lumen/issues/2 https://github.com/naim94a/lumen/issues/2
bitexploder 4y ago
I have not done it full time, but I find IDA is only useful for niche processors and out of the way things. I have still done it deeply and consistently for the last 16 years. For day to day use Ghidra is just better for me and I went pretty deep into the IDA well with tooling and Python scripting. Decompiler, yes, but it really depends on what features you need and what processor architectures you are reversing. IDA is still the most versatile and indispensable for some tasks, but that is not the majority of my work or interests these days and when it is, right tool, right job, etc. Arguments of keyboard/mouse efficiency are dead to me. The limiting factor of any reverse engineering is definitely not how efficiently you can keyboard navigate a UI. People are too in love with efficiency of the wrong things and not what the real limiting factors of reversing are, which is comprehending the program. I don't love clicking around but it has never once slowed me down on a project.

blincoln 4y ago

I've been doing RE work off and on for about twenty years. IDA is a solid tool with some really neat features[1], but the only reason I use it anymore is if I need to look at a binary that's for an architecture so obscure that Ghidra doesn't support it yet. I like Ghidra's interface better, but I'm also not a keyboard-first type of user. I work with a lot of different OSes and software. I stopped trying to remember most keyboard shortcuts 10+ years ago, because there were too many variations, and the consequences of using the wrong one can be dire. Releasing and open-sourcing Ghidra was a truly magnificent gift by the NSA, and I can't thank them enough for it. [1] I'd love to see a Ghidra equivalent of Lumina, for example.

kuroguro 4y ago
There's an open source Lumina server, writing a plugin for Ghidra wouldn't be too difficult, here's some details on how they hash functions: https://github.com/naim94a/lumen/issues/2 https://github.com/naim94a/lumen/issues/2

bitexploder 4y ago

I have not done it full time, but I find IDA is only useful for niche processors and out of the way things. I have still done it deeply and consistently for the last 16 years. For day to day use Ghidra is just better for me and I went pretty deep into the IDA well with tooling and Python scripting. Decompiler, yes, but it really depends on what features you need and what processor architectures you are reversing. IDA is still the most versatile and indispensable for some tasks, but that is not the majority of my work or interests these days and when it is, right tool, right job, etc. Arguments of keyboard/mouse efficiency are dead to me. The limiting factor of any reverse engineering is definitely not how efficiently you can keyboard navigate a UI. People are too in love with efficiency of the wrong things and not what the real limiting factors of reversing are, which is comprehending the program. I don't love clicking around but it has never once slowed me down on a project.