让我们假设我有一个程序可以执行一些众所周知的加密例程，例如 AES、RSA 或其他什么。我想检测此类算法何时运行，在哪些关键材料上运行，以及可能在哪些输入和输出数据流上运行。
这个想法是在虚拟机中运行整个程序，然后检测虚拟机本身来研究程序的行为。例如，我可能会实施试探法来检查是否计算了 AES S-box（当您看到某些字节和一些时钟周期之后，S-box 中的相应字节出现在某个寄存器中，那么您可能会知道 S-box正在运行）。追踪这些字节之前是如何在内存中移动的，可能会让我知道加密密钥的存储位置。
在虚拟机中执行所有这些操作的目的是我可以组成环境，以便程序无法检测到我试图监视他。通过这种方式，我想避免与保护者之类的所有混乱，看看它的表现如何。
是否已经以类似的方式尝试过逆向工程程序？“类似方式”是指在虚拟机中运行程序并查看它如何在内存和寄存器上移动数据，以便找到可以帮助我追踪我正在寻找的信息的模式。
如果有帮助，我想使用的架构是 x86，而实际的程序是我上面描述的程序：拦截已知密码程序。
正如 Guntram 所提到的，PANDA 项目旨在使这种事情成为可能。本质上，它为 QEMU 添加了检测点，以便您可以构建插件，在整个系统执行时对其进行分析。
一个挑战是您想要进行的分析类型的计算量非常大，以至于在系统实际运行时执行它们实际上并不可行。为了在 PANDA 中解决这个问题，我们有record 和 replay。本质上，这让您可以记录整个系统的执行，然后在启用检测的情况下重放它。记录本身只产生很小的开销，然后可以在不改变执行的情况下对重放执行任意昂贵的分析。在 Chow 等人的论文《将动态程序分析与虚拟环境中的执行解耦》中更详细地解释了这一基本思想。
目前，我们有两篇与您正在查看的 RE 相关的论文：
PANDA 的一个缺点是，严格来说，它不使用虚拟化。相反，它在 TCG（即仿真）模式下使用 QEMU。这使得它更易于检测，因为 QEMU 的 CPU 仿真中存在许多使用硬件虚拟化时不存在的错误。但是，除非您正在分析的程序明确尝试检测 QEMU，否则这不太可能成为问题。
一个好主意！
我不知道与您的方法直接匹配的现有解决方案。但是您可能会使用“虚拟机内省”作为关键术语来找出类似的方法。Garfinkel 和 Rosenblum 在 2003 年发表的论文“A Virtual Machine Introspection Based Architecture for Intrusion Detection”描述了这种策略。它在这里用于执行入侵检测 - 即他们在 2003 年就已经监视了 VM 内代码行为。
在过去的 11 年里，这些工具变得更加智能。一种对我来说似乎很有希望的方法：一旦您可以从外部访问正在运行的 VM 的主内存，您就可以使用 Volatility 轻松解析它——即重建用户模式进程、它们的虚拟内存等。但是，这主要足以仅静态分析。因此，您可以从主存储器中获取现有软件，而它没有机会检测您的采集工具 (*)。然后可以像通常在 IDA 等中一样在 VM 外部分析提取的代码。
更棘手的部分是如何动态记录和分析执行流程，而无需在 VM 内部引入额外的辅助代码。
(*) 你的方法的一个缺点是有问题的代码可能已经以敌对的方式运行，因为它可以检测到自己在虚拟机中运行。这通常是一件非常简单的事情。因此，主体可能无法看到它正在 VM 外部受到监视，但即使它在 VM 内部运行这一事实也很可疑……