A friend of mine has also been working on a Ghidra MCP: looks like theres a few of them: https://github.com/themixednuts/GhidraMCP

+1

I once tried learning how to RE with radare2 but got very frustrated by frequent project file corruption (meaning radare2 could no longer open it). The way these project files work(ed?) in radare2 at the time was that it just saved all the commands you executed, instead of the state. This was brittle, in my experience.

I don't have a lot of free time, so I have to leave projects for long periods of time, not being able to restart from a previous checkpoints meant I never actually got further.

IIUC, one of the first things Rizin did was focus on saving the actual state, and backwards/forwards-compatibility. This fact alone made me switch to Rizin. To its credit, my 3-year old project file still works!

Now for the downside: there is apparently a gap in Windows (32-bit) PE support, causing stack variables to be poorly discovered: https://github.com/rizinorg/rizin/issues/4608. I tested this on radare2, which does not have this bug. I'm hoping this gets fixed in Rizin at some point, at which point I'll continue my RE adventure. Or maybe I should give an AI reverse engineer a try... (https://news.ycombinator.com/item?id=46846101).

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.

Almost every hobbyist reverse engineer uses cracked IDA which is easily available. I have never seen ghidra being recommended for serious work.

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.

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.

Can you be more specific? Is it getting easier to reverse rust and go, since I have read about it being the hardest to reverse.

Sounds like `strings' on the binary would've sufficed if it's just hardcoded.

Just use the official github link or links that are linked there. The URL you mentioned seems bogus at best.

Looks like AI slop and SEO junk. The Guide page you linked opens with an article on Dubai sports car rental. There are also .net and .org variants of the domain, which appear to be also AI-generated slop. There's no such program as Ghidralite, and every site just links to the official Ghidra repository.

Very likely people who actually work on RE at the NSA also have access to IDA Pro licenses. I don't work in this space, so take it with a pinch of salt, but my understanding is this is a fairly long term strategic initiative to _eventually_ be the best tool.

Too many people in the know about this stuff I think to keep it hidden for that long. At the same time, we keep finding stuff that that should have held for and it didn't, so maybe you're right.

I doubt it. Ghidra is extremely extensible with their plugin/tool architecture. Public Ghidra includes the extremely helpful decompiler tool, and a few others, but I'm willing to bet that NSA uses regular Ghidra + some way more capable plugins instead of having another Ghidra.

The gains come from pairing Ghidra with a coding agent. It works amazing well.

This was discussed when Ghidra was first open sourced. To the best of my knowledge, nobody's found an NSA backdoor in Ghidra.

Without providing any proof that either this or SELinux is backdoored.

Well it’s open source, so you can check in principle. I would imagine there’s some fame and notoriety in discovering that.

Yes, we are working on rewriting analysis completely[1][2] that would fix your issue along with many others.

[1] https://github.com/rizinorg/rizin/pull/5505

[2] https://github.com/rizinorg/rizin/issues/4736

I tried radare2 with the official GUI Iaito. Iaito saves the project in a git repo, so whenever I got corruption (and I got it a lot, like every 4-5 saves) I was just a `git reset --hard` away from restoring a good state. Not the most efficient way of operation, but for me it was better this than tolerating Ghidra's tiny Courier New font.

Since we're judging each other, I'm genuinely wondering how bad you are at making friends. I mean, non-LLM friends. Relatives don't count.

You were rude but I understand what you mean. People can obviously Google "reverse engineering tutorial" or something similar. And certainly "what are good resources for X" can be a way to signal interest in something, get people to respond, and not necessarily do anything about it. But I think the most charitable interpretation of that question is they want a group consensus for the best place to start, since Google might return a heavily promoted site that had deprecated info. I remember years ago people hated "cplusplus.com" because out of a volume that is the size of a textbook, it had a few bad examples. So instead they promoted cppreference. (For learning C++).

I think we should conclude people want to maximize learning while minimizing wasted time, hence they ask for the "best resources". Even though the question seems tiring at times (when I was on reddit I heard this constantly, and cynically projected that very few people actually used the resources they requested. But I solved this problem by quitting/getting banned from Reddit and never looked back).

How interesting.

Anyway, I would recommend YouTube. Find a series you can follow along. Best of luck!

God forbid someone pose an interesting question on a discussion board.

I often wonder why on this forum of alleged hacker types, there seems to be such an impetus to push what all VC's are desperately bought into at the moment, whether it be crypto, or AI nonsense.

Oh wait... Right.

Asking for resources or asking "does anyone know where I can start?" Followed by a description of "here's where I'm at" has been table stakes for the uninitiated since time immemorial.

When I see "ask the LLM", all I hear is "prop up my investment portfolio".

To this OP in particular: try playing around with different binaries you already have source to, and using the RE tools to get a feel for their post compilation structure and flow; start by compiling with no compiler optimization. You'll want an understanding of what the structural primitives of "nothing up my sleeve" code reads and looks like post-compilation to build off of. Then start enabling different layers of optimization, again, to continue familiarizing yourself with output of modern compilers when dealing with fundamentally "honest" code.

Once you can eyeball things and get an intuitive sense for that sort of thing is where you jump off into dealing with dishonest code. Stuff put through obfuscators. Stuff designed to work in ways that hide what the actual intent of the code is, or things designed in ways that make it clear that the author had something up their sleeve.

It'll be a lot of work and memorization and pattern recognition building, and you'll have to put in the effort to get to know the hardware and memory architecture, and opcodes and ISA's, and virtual machines you're reversing for, but it will click eventually.

Just remember; odds are it won't make you money, and it will set time on fire. I cut my teeth on reversing some security firm's snake oil, and just trying to figure out why the code I wrote was acting weird after the compiler got done with it. (I have cursed at more compiler writers than about anyone but myself).

Then just remember that if someone got it to run, then it's gotta eventually make sense. The rest is all persistence on your part of laying bare their true, usually perverted motivations (generally boiling down to greed, job security, or wasting your goddamn time).

Would the world be nicer if that wasn't the case? Absolutely. I lived through a period where a lot of code wasn't "something up my sleeve" code. Now is not so much that time anymore. We've made programming too accessible to business types that now the interests of organization's at securing their power has a non-trivial distortion on how code gets written; which generally means user hostile in one way or another.

This is changing, Ghidra is increasingly replacing IDA for commercial work.

And everyone uses Ghidra exclusively where I work. I'd say we're a serious operation

The NSA doesn't do serious work?

I recommend it for serious work. Well, serious enough that I got paid for doing it, and/or given talks about it.

(not if you're only doing x86/ARM stuff, though)

Which exotic architectures is IDA missing from your perspective?

> 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.

No, that’s not enough.

The password would be visible, but the encyption algorithm and the script’s text wouldn’t.

It's not perfect, but in my personal experience it is still tough in languages like that due to the sheer volume of indirection and noise that makes it hard to follow. For example Go's calling convention is a little nutty compared to other languages, and you'll encounter a few *****ppppppppVar values that are otherworldly to make sense of, but the ability to recognize library functions and sys calls is for sure better.

Curious, the ghidralite page download button links to the NSA's github releases page.

I wonder what is the purpose of ghidralite dot com. SEO spam? Are they building trust and then will swap out the Download button with a poisoned binary.

It’s better in some dimensions and not others, and it’s built on a fundamentally different architecture, so of course they use both.

Ghidra excels because it is extremely abstract, so new processors can be added at will and automatically have a decompiler, control flow tracing, mostly working assembler, and emulation.

IDA excels because it has been developed for a gazillion years against patterns found in common binaries and has an extremely fast, ergonomic UI and an awesome debugger.

For UI driven reversing against anything that runs on an OS I generally prefer IDA, for anything below that I’m 50/50 on Ghidra, and for anything where IDA doesn’t have a decompiler, Ghidra wins by default.

For plugin development or automated reversing (even pre LLMs, stuff like pattern matching scripts or little evaluators) Ghidra offers a ton of power since you can basically execute the underlying program using PCode, but the APIs are clunky and until recently you really needed to be using Java.

Ghidra has a slightly different focus than IDA, so they're definitely not just using Ghidra :-)

I'll second this. I used opencode + opus 4.6 + ghidra to reverse engineer a seedkey generation algorithm[1] from v850 assembly. I gave it the binary, the known address for the generation function, and a set of known inputs/outputs, and it was able to crack it.

[1] https://github.com/Mattwmaster58/ic204

would you have a tutorial on that?

Powerful, "capable" plugins are obvious; NSA cannot stop people from writing them, and they have little reason to restrict their use.

I think what NSA is likely to keep confidential are in-house plugins that are so specialized and/or underengineered that their publication would give away confidential information: stolen and illegitimate secrets (e.g. cryptographic private keys from a game console SDK), or exploits that they intend to deny knowledge of and continue milking, or general strategies and methods (e.g. a tool to "customize" UEFI images, with the implication that they have means to install them on a victim's computer).

Yeah this. I saw some guys on youtube use AI MCPs to do some crazy reverse engineering.

It's difficult to be an AI doomer when you see stuff like this.

Can't wait! Do you have any idea how far along this is? Is it likely to be months, quarters, years?

(Funny expression, that. I'll wait, of course. It'll be a happy day when this works again and I can slowly make progress RE'ing again.)

Thanks for the note.

Your corruption frequency anecdote matches mine. I don't have the mental werewithal to deal with that. I won't go back to radare2 until they change their project file stability somehow.

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.

That wasn't the claim. Ability + interest + time + budget + ... are what makes a serious tool.

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.

Months.