Before, we did not need to disable AI stuff. Now Mozilla forced us (that is those of us who don't like or use AI) into an extra step. Guess the only thing worse is being given no choice at all though.
One huge difference is that IDA is much faster and less resource-intensive than Ghidra, on account of the latter being written in Java (not surprisingly) while the former is native code. The Ghidra UI is noticeably laggy to perform basic operations even with tiny binaries, while I haven't noticed anything like that in IDA.
For UI based manual reversing of things that run on an OS, IDA is quite superior; it has really good pattern matching and is optimized on this use case, so combined with the more ergonomic UI, it’s way way faster than Ghidra and is well worth the money (provided you are making money off of RE). The IDA debugger is also very fast and easy to use compared to Ghidra’s provided your target works (again, anything that runs on an OS is probably golden here).
For embedded IDA is very ergonomic still, but since it’s not abstract in the way Ghidra is, the decompiler only works on select platforms.
Ghidra’s architecture lends itself to really powerful automation tricks since you can basically step through the program from your plugin without having an actual debug target, no matter the architecture. With the rise of LLMs, this is a big edge for Ghidra as it’s more flexible and easier to hook into to build tools.
The overall Ghidra plugin programming story has been catching up; it’s always been more modular than IDA but in the past it was too Java oriented to be fun for most people, but the Python bindings are a lot better now. IDA scripting has been quite good for a long time so there’s a good corpus of plugins out there too.
IDA is the better tool if you're being paid to work with architectures that IDA supports well (ARM(64), x86(_64), etc). This usually means 'mainstream' security/malware research. It's not worth the price for hobbyists. Before Hex-Rays was sold to private equity, it could make sense for rich hobbyists to pay for a private license once and use it for a few years without software updates, with the cloud offering now it pretty much makes no sense.
Ghidra is the better tool if you're dealing with exotic architectures, even ones that you need to implement support for yourself. That's because any architecture that you have a full SLEIGH definition for will get decompilation output for free. It might not be the best decompiler out there, sure, but for some architectures it's the only decompiler available.
Both are generally shit UX wise and take time to learn. I've mostly switched from IDA to Ghidra a while back which felt like pulling teeth. Now when I sometimes go back to IDA it feels like pulling teeth.
It's also not about lack of support, but the fact that you have to pay extra for every single decompiler. This sucks if you're analyzing a wide variety of targets because of the kind of work you do.
IDA also struggles with disasm for Harvard architectures which tend to make up a bulk of what I analyze - it's all faked around synthetic relocations. Ghidra has native support for multiple address spaces.
I really want to like Binary Ninja, but whenever I have the choice between not paying (Ghidra), paying for something that I know works (IDA) and paying for something that I don't know if it works (Binja) then the last option has always lost so far.
Maybe we need to get some good cracked^Wcommunity releases of Binja so that we can all test it as thoroughly as IDA. The limited free version doesn't cut it unfortunately - if I can't test it on what I actually want to use it for, it's not a good test.
(also it doesn't have collaborative analysis in anything but the 'call us' enterprise plan)
Agree. IDA is surely the “primary” tool for anything that runs on an OS on a common arch, but once you get into embedded Ghidra is heavily used for serious work and once you get to heavily automation based scenarios or obscure microarchitectures it’s the best solution and certainly a “serious” product used by “real” REs.
Leading this by saying I've only used Ida free, I can't comment on Ida pro. I'm also a very lite user of both, I give name functions/vars, save bookmarks, and occasionally work out custom types, and that's about it, none of the real fancy stuff.
I was recently trying to analyse a 600mb exe (denuvo/similar). I wasted a week after ghidra crashed 30h+ in multiple times. A seperate project with a 300mb exe took about 5h, so there's some horrible scaling going on. So I tried out Ida for the first time, and it finished in less than an hour. Faced with having decomp vs not, I started learning how to use it.
So first difference, given the above, Ida is far far better at interrupting tasks/crash recovery. Every time ghidra crashed I was left with nothing, when Ida crashes you get a prompt to recover from autosave. Even if you don't crash, in general it feels like Ida will let you interrupt a task and still get partial results which you might even be able to pick back up from later, while ghidra just leaves you with nothing.
In terms of pure decomp quality, I don't really think either wins, decomp is always awkward, it's awkward in different ways for each. I prefer ghidra's, but that might just be because I've used it much longer. Ida does do better at suggesting function/variable names - if a variable is passed to a bunch of functions taking a GameManager*, it might automatically call it game_manager.
When defining types, I far prefer ida's approach of just letting me write C/C++. Ghidra's struct editor is awkward, and I've never worked out a good way of dealing with inheritance. For defining functions/args on the other hand, while Ida gives you a raw text box it just doesn't let you change some things? There I prefer the way ghidra does it, I especially like it showing what registers each arg is assigned to.
Another big difference I've noticed between the two is ghidra seems to operate on more of a push model, while Ida is more of a pull model - i.e. when you make a change, ghidra tends to hang for a second propagating it to everything referencing it, while Ida tries pulling the latest version when you look at the reference? I have no idea if this is how they actually work internally, it's just what it feels like. Ida's pull model is a lot more responsive on a large exe, however multiple times I've had some decomp not update after editing one of the functions it called.
Overall, I find Ida's probably slightly better. I'm not about to pay for Ida pro though, and I'm really uneasy about how it uploads all my executables to do decomp. While at the same time, ghidra is proper FOSS, and gives comparable results (for small executables). So I'll probably stick with ghidra where I can.
> I was recently trying to analyse a 600mb exe (denuvo/similar). I wasted a week after ghidra crashed 30h+ in multiple times.
During the startup auto analysis? For large binaries it makes sense to dial back the number of analysis passes and only trigger them if you really need them, manually, one by one. You also get to save in between different passes.
Yup. It was actually an openjdk crash, which was extra interesting.
I figured I probably could remove some passes, but being a lite user I don't really know/didn't want to spend the time learning how important each one is and how long they take. Ida's defaults were just better.
That's a great opportunity for a controlled study! You should do it. If you can send me the draft publication after doing the study, I can give feedback on it.
I don't think there is a need for a new study as Cognitive Reflection Tests are a well-researched subject [1]. I am actually surprised that I got downvoted, as I thought this would be common knowledge.
I'm a bit confused by the comparison between Windsurf and Antigravity. I thought Google got involved with Windsurf, and now Antigravity is essentially the next version of Windsurf.
Actually, they are now separate competitors: Google hired the original founders of Windsurf and licensed the tech to build Antigravity, while Cognition acquired the Windsurf brand and codebase. While they share a common origin, Antigravity is Google's Gemini-native evolution, whereas Windsurf continues as a standalone product under Cognition's leadership.
How so? The kind of insatiable appetite for bloodshed that Aaronson possesses is a very human trait for those raised without an understanding of good and evil, and one that the people he identifies with are currently acting upon, even over the past few days.
He doesn't know any better, as he wasn't raised to understand right and wrong, he only understands "useful for us" or "harmful to us", but that's still no excuse.
My hypothesis is that it's due to phones. Waiting in a single row queue became much less painless so the younger ones prefer even to be on the phone and wait in line. Actually, the more chaotic types of "lines" make it more difficult to just be on the phone while waiting.
Impacted by phones removal of the pain of being in a queue sure. Due to phones seems to ignore all the comments that this "came out of nowhere" and wasn't seen before "2020".
It seems most likely that with pubs not so active over the pandemic, then operating with more socially distanced rules, new pub users just never learnt the "only used in pubs queueing system".
Which is a weird blindspot for the article, where they reference a normal queue as something from "border control", rather than then thing you do everywhere but the pub. Without the introduction to the system they just use the system they use everywhere else. And don't worry it takes longer because it's a convenient time to check your phone.
Honestly I looked at Go for malware and I mean AV detection for golang used to be ehh but recently It got strong.
Then it became a cat and mouse game with obfuscators and deobfucsators.
John Hammond has a *BRILLIANT* Video on this topic. 100% recommneded.
Honestly Speaking from John Hammond I feel like Nim as a language or V-lang is something which will probably get vibe coded malware from. Nim has been used for hacking so much that iirc windows actually blocked the nim compiler as malware itself!
Nim's biggest issue is that hackers don't know it but if LLM's fix it. Nim becomes a really lucrative language for hackers & John Hammond described that Nim's libraries for hacking are still very decent.
reply