Agreed. I find IDA to be much better than Ghidra for common things: Windows C++ or Delphi applications and ARM Objective-C where the heuristic guided decompiler really shines and Ghidra gets lost easily.
For the obscure architectures Ghidra does support, it's way better than IDA by virtue of having a decompiler alone. Even if the decompilation is subtly wrong, the broad strokes are so much easier to navigate that finding the right method to go through by hand is much easier.
And once you dive into Ghidra's P-Code IR and more advanced plugin support and move beyond existing IDA plugins, it's honestly better than IDA for things nobody has done before.
Now, there are some obscure architectures like C167 for which we still lack a working Ghidra processor model, but this is only a matter of time - and once it comes, it will already be way ahead of IDA!
If automation and analysis over the IR is your goal, Binary Ninja is the far better choice compared to both Ghidra and IDA. There's always things to work on but even most people who don't use Binary Ninja regularly who have evaluated it agree that our API/BNIL stack is superior to other options.
Disclaimer: BN founder, so biased of course but I'm pretty up-front about our strengths/weaknesses.
I confirm. P-code IL is archaic and was designed at the onset of "decompiler science". Modern ILs are much more consistent and suitable for both uplifting and further analysis.
As I mainly reverse automative hardware, I care about only Tricore, C167, SuperH, and PowerPC, in that order - which means Binary Ninja is out for me for the time being!
Thanks for the post though, as I did look into adding a new Architecture and the setup for defining a new ISA is much simpler than it is in even Ghidra/SLEIGH, so kudos to that. Maybe if I find myself with a lot of free time I will try adding something.
Totally fair -- breadth of architecture support is definitely one of the biggest strengths of Ghidra! IDA does as well but purely for disassembly which isn't nearly as useful.
EDIT: But yeah, we designed our lifting to be as simple as possible. Specifically the way we handle flags tends to simplify much of the normal tedium around what's required for other decompilers. If you do decide to build a C167 module, give us a look again. :-)
Would you say its easy or possible to learn reversing while you learn binary ninja? I bought a license a while back and was struggling to figure out how to do things I could easily look up tutorials for in other programs so I ended up not using it much. I found a couple of videos that were pretty out of date and other than that I saw that there were expensive training courses from a single company.
You guys should try and get someone to write a book kind of like the IDA / Ghidra books that Chris Eagle did.
There could be something out there I just missed. Got any advice?
We've got a few more in the editing queue I need to clear out as well.
That said, I agree in terms of needing more intro tutorials would be helpful. Part of the problem with producing something like the IDA books is that we are under far too active development. Our UI and features have grown exponentially over the past few years so there was just never a good time to make something that wouldn't be out of date before it was even done.
You might be interested in joining the Binary Ninja slack which is a great community for getting questions answered. https://slack.binary.ninja/
There's also the free cloud version which doesn't have quite the same features but is an easier introduction without paying. https://cloud.binary.ninja/
True. I wanted to analyze some or1k binaries. No IDA support. Two weekends, and I had a disassembler and decompiler for the architecture, without writing any Java code. Just amazing.
You don't even need to describe the whole instruction set, just all the instructions that your target binary uses.
Such an amazing thing. And or1k is a nasty architecture with delay slots, which makes manual assembly reading quite tedious, etc. So the decompiler "C" output is very useful in this situation. I was in awe.
For the obscure architectures Ghidra does support, it's way better than IDA by virtue of having a decompiler alone. Even if the decompilation is subtly wrong, the broad strokes are so much easier to navigate that finding the right method to go through by hand is much easier.
And once you dive into Ghidra's P-Code IR and more advanced plugin support and move beyond existing IDA plugins, it's honestly better than IDA for things nobody has done before.
Now, there are some obscure architectures like C167 for which we still lack a working Ghidra processor model, but this is only a matter of time - and once it comes, it will already be way ahead of IDA!