为什么不可能进行真正的仿真？

#1 楼

问题被错误地放置

您问的是错误的问题。从字面上看。问题绝不是为什么不可能（在许多情况下是可能的）。更好的问题是：为什么它不切实际？

还是很有趣。

为什么不使用硬件辅助虚拟化？

对于初学者，我过去曾与某些同事（我在AV行业工作）发生过争执，并试图通过某些硬件虚拟化方法解决这一问题，与自己的仿真实现相比，您可以在不损失安全性的情况下提高速度。其中一些同事认为，恶意软件绝不能在没有气隙的情况下在计算机上本地执行。我个人认为这是一个有问题的陈述，因为恶意软件的泛滥以及因为当今的硬件虚拟化功能无论如何都提供（近乎）本地执行。但是我想这最终还是一个品味和政治问题。

除此之外，您还必须具有对系统的特权访问权才能控制虚拟机监控程序。在以内核模式运行的文件系统筛选器的上下文中，这可能很好，但是在其他纯用户模式的情况下（例如命令行扫描程序）则不是一个选择。

然后仅“模拟”机器，而不是“操作系统”环境，正常情况下无害或恶意代码将在该环境中运行。

AV中的速度很重要实用性问题主要归结为速度。如果您认为AV文件系统过滤器至少扫描每个对象一次，那就很多了。

现在，AV引擎通常会尝试确保某些可执行打包程序有静态解压缩程序，因此可以不必被模仿等等。在进行仿真之前，还有其他启发式方法和静态方法。

但是在这种情况下，即使部分扫描，在整个扫描文件中仍有相当一部分需要被模拟。由于仿真通常比本地执行慢至少一个数量级，因此即使最后只对整个代码的一部分进行仿真，这也会迅速加起来。

要仿真哪个系统？

现在看来表面上这很容易。始终模拟正在运行的操作系统。

然后问题就变成了如何将整个操作系统安装到引擎中。现在您可能会反驳：“为什么不使用正在运行的操作系统的库”，对此我会回答，这仅适用于上面的特定用例。但是，当在AIX下的PowerPC上运行时，如何仿真Win32 API？还是在Android手机上的ARM处理器上？ br />
仿真器应该紧贴实际环境的行为吗？

如果您曾经尝试过ReactOS-一个旨在重新实现Windows XP和2003二进制接口的开源项目保留最后一个细节的服务器-除了CD映像中附带的内容外，您将知道它具有各种故障。 Wine同样也有很多故障（ReactOS和Wine共享很多代码）。

AV仿真通常比Wine快捷得多，因为不需要很多功能。让函数成功或失败，就可以了。问题出在Win32 API的非常详细的细节上。 Windows 95、98，Me，NT 4、2000，XP，2003，Vista，2008、7、2008 R2、8、2012、8.1、2012 R2
/>
...然后您还应该照顾Linux和Mac恶意软件吗？还有其他情况，例如某些硬件配置（想想Stuxnet以及它如何“捆绑”到某些USB密钥）。要求与模拟整个操作系统或可以在其上运行操​​作系统的计算机一样，就像在真实硬件上运行时一样。

结论：近似值已足够

因此，通常只需逼近实际环境即可。此外，您还应记住，许多逃避尝试本身可以被检测到，可疑并会升旗。