24

OllyDbg had been nice in the past, but it stopped development a decade ago, x32dbg/x64dbg era came.
However, some people still use OllyDbg. Are there any reasons to use the old OllyDbg still? Doesn't x32dbg/64dbg covers all needed things?

Improve this question

4 Answers 4

Reset to default
22

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.

Improve this answer
1
  • 1
    Could you elaborate on the issues with x64dbg (patching/crashes/whatever). The current focus is stability and I feel things have been pretty good as of recently. Also for 32 bit systems you can easily use TitanHide which uses a kernel driver instead of user mode hooks. It often happens that people say that x64dbg is “unstable” because they used it in 2016 and didn’t report any issues or ever try again.
    – mrexodia
    Commented Dec 1, 2018 at 23:04
15

Disclaimer: I am the main developer of x64dbg, take that into account :)

I would say that the main difference between OllyDbg and x64dbg is that there is no 64 bit (os) support at all in OllyDbg. If you are working on a modern system I think x64dbg is a better choice because it was designed to work there.

That said, x64dbg isn’t better in all aspects. One main difference is that OllyDbg has a very solid tracing system, whereas x64dbg has something, but still requires a lot of work. I am using x64dbg for my job, but I am familiar with the source code so I can make improvements as I need them.

Another big difference is that you can contribute to x64dbg directly. Either by reporting bugs, or simply fixing them yourself. To me this is a big advantage, as many plugins for OllyDbg hook the internal functions to fix bugs or add features.

Improve this answer
5
  • 1
    ouch, i didn't know the person helped me with other questions too, is the main dev of x64. thnx ;)
    – T.Todua
    Commented Dec 2, 2018 at 9:55
  • can you please also list the differences with regard to x32dbg vs olly
    – T.Todua
    Commented May 20, 2023 at 16:25
  • I don't feel there would be a benefit to necro-editing a post from 5 years ago, even though the accepted answer has more upvotes and is factually incorrect...
    – mrexodia
    Commented May 22, 2023 at 20:03
  • the reason it was accepted answer was because user posted that earlier and by that time it was the "accepted answer". however, in recent days I had to go back to that issue and had additional questions, and I've asked you, because you had more context of that. but if you don't find a time to update that post (even though it would be beneficial to readers), then I understand.
    – T.Todua
    Commented May 27, 2023 at 12:19
  • 2
    @mrexodia I think there is nothing "necro" about this, because this isn't a forum but a QA site like a wiki with questions and answers, more targeted towards future readers finding it than to the original poster, and so editing something to improve it or bring it up to date would always be good, regardless of how old the post it. (Adding answers to years-old questions is also good for that reason because even if the question is no longer interesting to the original poster, it may be useful to someone finding it on Google, which is the main use of Stack Exchange sites anyway!)
    – CherryDT
    Commented Sep 14, 2023 at 7:19
5

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

Improve this answer
3
  • x32dbg cannot call an arbitrary export in a dll loaded for debugging or analysis, ollydbg2 can
  • x32dbg still crashes when attached/detached to svchost.exe ollydbg2 can handle it without any problem
  • x32dbg cannot automatically follow a child process, ollydbg2 can
Improve this answer
2
  • 1
    why was donwvoted ?
    – T.Todua
    Commented Nov 27, 2020 at 7:31
  • 1
    @T.Todua Upset x64dbg fans
    – Coldblackice
    Commented Jul 24, 2021 at 16:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.