OllyDbg vs x64dbg-OllyDbg与x64dbg相比有什么特别的优势吗？

#1 楼

结合了托管代码和非托管代码的调试软件：

Ollydbg调试并很好地运行了托管代码（当然，在这种情况下，它仅作为本机调试器运行，而不像显示.Net功能的DnSpy并能完美地编码）。

有时，如果恶意软件对非托管代码（本机代码DLL）进行了大量调用，则使用OLLY这样的调试器来跟踪过渡要方便得多。

在x32dbg / x64dbg中完全不可能，并且在处理托管代码时会崩溃。

与32位系统的兼容性：

用于x32dbg的ScyllaHide不太好，并且在Windows 7和Windows 10（32位）上失败。 （它在Windows XP SP3上绝对不起作用，并不断向我们提供UNKNOWN SYSCALL错误-因此，在这种情况下，我什至不介意提及Win XP）。

我看到有关于该（适用于32位Windows 7和Windows 10）GitHub上的悬而未决的问题，但唯一的答案似乎有代表建议，我们应该迁移到64位Windows。

虽然这是事实，但由于多种原因，很多时候我们需要在32位系统上工作。

没有合适的系统来隐藏通过大多数恶意软件的防调试调用调试器，调试器基本上用处很少。

脚本引擎：

用于x32dbg / x64dbg上脚本编写的插件非常慢与Olly Script引擎相比。那么，Python脚本

修补的问题：一些可执行的处理，我觉得我需要恢复到奥利时
在我的经验，修补使用x32dbg / x64dbg是非常错误以确保可执行文件得到可靠的修补。

更新问题：
x32dbg / x64dbg调试器的每次更新都会带来其自身的错误，这在某种程度上使人想起Windows 10不断更新；）

调试目标时，我们真的不需要继续思考是由调试器引起的错误还是导致崩溃的目标程序错误！

简而言之，主要问题似乎太多的程序员已经并且仍在（仍）以自己的编程风格来从事x32dbg / x64dbg的开发工作，并且似乎在调试器的总体结构中缺乏指导。

对于Olly而言，情况并非如此，因为只有一个程序员创建了它，因此具有干净清晰的结构，很难用简单的术语进行定义或描述。

这并不是说x32dbg / x64dbg很糟糕。只是说还有很多改进的余地，以使其能够像Olly一样可靠地运行。

这些只是我想起了我的头顶上不断引起我的一些问题除尘我的旧Olly，然后一次又一次地重复使用。

#2 楼

免责声明：我是x64dbg的主要开发人员，请考虑到这一点:)

我要说OllyDbg和x64dbg之间的主要区别是OllyDbg中根本不支持64位（os） 。如果您在现代系统上工作，我认为x64dbg是一个更好的选择，因为它是为在此处工作而设计的。

那，x64dbg并非在所有方面都更好。一个主要区别是OllyDbg具有非常可靠的跟踪系统，而x64dbg具有某些功能，但仍需要大量工作。我正在使用x64dbg进行工作，但是我熟悉源代码，因此可以根据需要进行改进。

另一个很大的不同是，您可以直接为x64dbg做出贡献。报告错误，或者自己修复错误。对我来说，这是一个很大的优势，因为OllyDbg的许多插件都钩住了内部函数来修复错误或添加功能。

#3 楼

除了可能的自定义插件或埋藏的功能以及可用性差异之外，使用OllyDbg而不是使用x32dbg/x64dbg确实没有动力。由于OllyDbg多年来一直是首选的调试器，因此要花一些时间才能实现。
话说，它对于具有丰富支持/插件生态系统的32位调试器仍然具有非常强大的功能（即使现在，它有点过时了，因此，与32位应用程序的任何其他调试器相比，如果使用它，绝对没有任何错误。实际上，这种切换非常简单，以至于可以通过x32dbg/x64dbg使用调试器来使自己喘不过气来，然后直接跳到OllyDbg，几乎没有差异可以弥补。

#4 楼

x32dbg无法在加载的dll中调用任意导出以进行调试或分析，ollydbg2可以
x32dbg在与svchost附加/分离时仍然崩溃。ollydbg2可以毫无问题地处理它
x32dbg无法自动遵循子进程，ollydbg2可以