Sstrhsrtj

OllyDbg has had it's years, but x64dbg replaced it. However, some people still mention OllyDbg.

Are there any reasons to use the old OllyDbg still? Doesn't x64dbg covers all needed things?

Debugging software with a combination of managed and unmanaged code:

Ollydbg debugs and runs managed code very well (of course in this case it only runs as a native debugger and not like DnSpy which shows the .Net functions and code perfectly).

There are times when, if the malware makes a lot of calls to unmanaged code (native code DLLs) it is far more convenient to use a debugger like OLLY to track down the transition to the native DLLs.

This is not possible in x32dbg/x64dbg at all and it crashes when dealing with managed code.

Compatibility with 32-bit systems:

ScyllaHide for x32dbg is not very good and fails on Windows 7 and Windows 10 (32-bit). (It absolutely does not work on Windows XP SP3 and keeps giving us the UNKNOWN SYSCALL error - So I am not even bothering to mention Win XP in this context).

I see that there is an open issue on GitHub regarding this (for 32-bit Windows 7 and Windows 10), but the only answer there seems to advise that we should migrate to 64-bit Windows.

While this is true, there are many times where we need to work on 32-bit systems for a variety of reasons.

Without a good system in place to hide the debugger from the anti-debugg calls of most malware, the debugger is basically of very little use.

Scripting Engines:

The plugins for scripting on x32dbg/x64dbg are very slow when compared to the Olly Script engine. So is the python scripting.

Patching Issues:
In my experience, the patching using x32dbg/x64dbg is very buggy when dealing with some executable and I find that I need to revert back to Olly to ensure that the executable gets reliably patched.

Issue with Updates:
Every update of the x32dbg/x64dbg debuggers brings its own bugs with it and in a way, this reminds one of Windows 10 with its constant updates ;)

When debugging a target, we should really not need to keep thinking constantly as to whether it was a fault in the debugger or the target program that contributed to the crash!

In an nutshell, the main problem seems to be that too many programmers have been and are (still) working on x32dbg/x64dbg each in their own programming styles and there seems to a lack of direction in the overall structure of the debugger.

This was not the case for Olly where a single programmer had created it and therefore has a clean crisp structure that is very difficult to define or described in simple terms.

This is not to say that x32dbg/x64dbg is bad. Just saying that there is a lot more room for improvement to make it run as reliably as Olly.

These are just a few of the issues that I could remember the top of my head that constantly caused me to dust my old Olly and re-use it again and again.

Outside of maybe custom plug-ins or perhaps buried features and usability differences, there's really no incentive to use OllyDbg over x32dbg/x64dbg. Since OllyDbg was the debugger of choice for so many years, it will take awhile to run its course.

That said, it's still extremely capable for a 32-bit debugger with a rich support/plug-in ecosystem (even if a bit outdated now), so there's absolutely nothing wrong with using it if you prefer it over any other debugger for 32-bit applications.

Personally, I migrated to x32dbg/x64dbg quite awhile back and haven't missed OllyDbg ever since. In fact, the switch is so easy that one could presumably get up to snuff with using debuggers via OllyDbg, then bop right over to x32dbg/x64dbg with very little differences to compensate for.