In an nutshell, the main problem seems to be that too many programmers have been and are (still) working on x32dbg/圆4dbg each in their own programming styles and there seems to a lack of direction in the overall structure of the debugger. 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 my experience, the patching using x32dbg/圆4dbg 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.Įvery update of the x32dbg/圆4dbg debuggers brings its own bugs with it and in a way, this reminds one of Windows 10 with its constant updates ) The plugins for scripting on x32dbg/圆4dbg are very slow when compared to the Olly Script engine.
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. While this is true, there are many times where we need to work on 32-bit systems for a variety of reasons. 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.
(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). ScyllaHide for x32dbg is not very good and fails on Windows 7 and Windows 10 (32-bit). This is not possible in x32dbg/圆4dbg at all and it crashes when dealing with managed code. 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. 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. Debugging software with a combination of managed and unmanaged code:
0 kommentar(er)
