#1 楼
要正确检测多态引擎本身，需要该引擎的副本。过去就是这种情况，因为病毒携带了引擎以产生自身的新副本。针对此的明显攻击是服务器端多态性，我们（“我们” = AV行业）只能猜测引擎的功能，并且可以根据我们的检测随时更改引擎的功能。但是，回到实际问题：
给定一个可以产生类似序列的引擎：寄存器分配，我们知道垃圾指令集，解密方法，寄存器调整等。
从那里，我们可以使用状态机来监视真正的指令，而忽略假的。实现细节冗长而乏味，因此在这里不适合作为答案。
在大多数情况下，这是一种单引擎的单算法关系。
因此，模拟器成为我们针对该攻击拥有的最有用的工具，使我们能够从本质上“让病毒自行解密”，然后我们可以看到其背后的内容（针对该攻击的显然是变态的，最简单的实现是在源代码级别而不是在源代码级别编译后）。
总之，答案通常是“我们不再”。也就是说，我们倾向于不再检测多态引擎本身。当然也有例外，但是在这几天之间很少。
评论
谢谢您的解释，这很有意义。我只是想问一个关于服务器端多态性的后续问题，但是您的回答已经解释了它。
– Shebaw
13年6月5日，下午3:18
#2 楼
简短答案：AV扫描仪不对多态样本使用签名。他们使用通用检测代码。长答案：多态恶意软件使代码在不同的世代中看起来都不同。谈到文件感染者（Sality和Virut），当新文件被感染时，将考虑一代。如果样品A感染B，C和D，则为第一代。这一代中的代码将或多或少看起来相似。当样本B，C和D感染新文件E，F和G时，这将是第二代，并且第一代和第二代之间的代码将有很大差异（取决于文件感染者的质量）。同样适用于后代：新一代将不同于前代（同样，这取决于文件感染器的质量，但通常是正确的）。
因此，如果您决定使用基于字节流或助记符流的签名，您将只能检测到一代，而不能检测到恶意软件本身。除了不太好的多态引擎以外。
AV工程师通常编写检测代码（而非签名）并查找恶意软件的证据，而无需依赖于多态代码，而无需依赖于特定代码更改和/或语义上的变化：尽管代码看起来可能非常不同，但是它总是一样。
所使用的证据例如可以是以下证据：
如果入口点在最后一节中（例如Sality / Virut的情况）。
具有相同语义但使用不同寄存器的特定指令（将原始入口点地址推入堆栈）如果文件感染程序使用EPO）。
在不同的世代之间相等的特定值/偏移量。
另一种方法因其速度慢且不够用而未被广泛使用，但它本身：
执行第一个功能的代码分析并比较控制流程图。您可以将其视为基于图的签名。
广泛使用的另一种方法：
使用仿真器（ClamAV缺少的主要功能之一）尝试模仿恶意软件的许多指令，然后找到特定的缓冲区（字节）或一组特定的指令。经过上述说明后，希望该恶意软件已在内存中“解压”。当然，如果正确地进行了仿真。
因此，如果您想为Sality或Virut编写ClamAV的检测代码，我建议您使用它们所谓的字节码“签名”。
#3 楼
有多种类型的多态病毒，但是通常大多数常见的解决方案实际上都是试图解决此问题并避免在用户计算机上检测未知样本。在几乎没有可用资源的情况下，很难在没有可用资源的实际计算机上实时检测病毒，而又不会使用户真正接触到病毒的恶意特性。取而代之的是，视听人员更喜欢在自己的舒适区域内进行大部分繁重的工作：内部实验室和沙箱。通常会有一些指导：
尝试生成对尽可能多的样本保持有效的签名。即不是多态或只有很少变体的签名字节。您将需要大量类似的变体。视音频通常具有聚类算法，并以此方式自动生成签名。
尝试删除多态层并检测基础样本。 UPX是一个简单的示例，因为它非常容易静态解压缩，一些XOR加密方案也很容易。
通过动态分析检测样本，例如恶意活动/ API，进程注入等。这会带来很多误报，这是HIPS系统的一个已知问题。
让您的AV产品将未知的可疑文件上传到后端，在这里由专有的静态和动态分析机，聚类算法和手动RE对样本进行分析如果需要的话。然后显然签署了旧方法。 KAV喜欢对未知文件执行此操作。
通常将其中的许多e组合在一起，第3种方法用于第4种方法检测可疑文件。 1st和4th通常具有相似的引擎和流程，它们从静态分析开始，因为它更快。由于大多数艰苦的工作都是在视音频供应商的实验室中完成的，因此这是一个巨大的瓶颈，因此提速和优先级是游戏的重要部分
评论
非常糟糕，AFAIK。并且每个“技术”都被视为“专有技术”或专利方法，不得公开披露：)
@Denis Laskov-不，这不是真的-这是一个（相对）简单的问题，即了解引擎可以产生什么，并按照引擎产生它们的顺序监视那些操作码集。也就是说，当然要检测外层。更常见的是，使用仿真器查看常量代码所在的底层。那么poly引擎什么都没有作用。