逆向工程中的实际常识是，尝试在“受 VM 保护”或虚拟化程序上使用本机调试器或反汇编器更难分析。但是，我想知道这种情况的具体具体方式以及原因。请列出一些原因以及是否已手动克服各种原因（不使用脚本）的任何相关工作。
如果认为这个问题过于笼统，让我们关注一个具体的例子。该示例是我们尝试使用本机调试器（例如 x64Dbg）来定位对 Windows API CreateFile 的调用并找出文件写入的位置。在不受保护的程序中，我们可以打开它，在 CreateFile 上放置一个断点，并在检查交叉引用调用后定位调用。
Themida Protector 如何成功阻止这个过程？显然，最终程序仍然必须写入文件，但是哪些步骤严重阻碍了分析？
这取决于你的目标。如果您只关心副作用（如 API 调用、写入的文件、网络内容等），它们并不会真正让您感到困难。正如您所说，最终必须使用API 并且您将能够捕获它。
虚拟化的目的是阻止人们了解目标的内部流程。因此，人们通常只虚拟化特定的代码块以减少整体负面性能影响，并且只保护例如读取许可证文件的代码、执行加密的代码等。
这使得从目标中提取算法变得非常繁琐。如果您的问题是内部发生了什么，那么 VM 保护是最糟糕的。如果你只关心目标是什么呢，好了，他们什么都不做。
基本上，他们的目标是将可执行文件变成一个黑匣子，而不是掩盖他们的行为。
所以据我所知，这个问题有两个主要部分。首先是为什么很难逆向/分析虚拟化代码。标准汇编指令具有特定的字节码，通过它您可以了解程序中发生的事情。通过使用虚拟化，人们可以创建任意字节代码，然后将其转换为系统可以理解的原始代码。这意味着通过查看代码您无法理解发生了什么。
当我们遇到在运行时逐部分生成原始代码而不是一次生成所有代码的虚拟化机器时，情况会更进一步。因此，作为分析师，您会在运行时看到真实装配的小部分。
第二部分关于 CreateFile/WriteFile。如果在这个例子中你的意思是分析程序的行为，那么大多数时候虚拟化或普通可执行文件之间没有区别。在这两种情况下，您都可以将 BP 放在调试器中的 CreateFile/WriteFile 上，或者更好的方法是进行黑盒监控。
值得一提的是，我们在逆向虚拟化代码时面临的另一个问题是，它们也主要受益于重型保护器/反调试技术。
http://resources.infosecinstitute.com/reverse-engineering-virtual-machine-protected-binaries/#gref