为什么检测多态恶意软件如此困难?

时间:2015-05-29 16:03:17

标签: detection malware

为什么检测多态恶意软件如此困难?

在解压缩恶意软件的加密部分后,是否足够构建签名?

然后只需通过类似的过程将此签名与另一个可能的恶意软件版本匹配?

使用类似的过程,我的意思是使用PEID之类的软件实时解压缩恶意软件的加密部分,然后针对先前生成的签名进行测试。

通过签名,我正在参考防病毒软件中使用的经典签名,一个sintactic签名(例如十六进制的常规表达)。

修改

为什么不考虑所有无法正确解压缩的软件的恶意软件?

Benign软件还使用自定义包方法吗?

修改

¿你怎么知道软件是否包装好? ¿如果软件包装好你总是能意识到这一点? ¿你能不能总是知道恶意软件混淆部分的开头在哪里?

¿mimimorphism怎么样?

是否有一些关于多态恶意软件的书或手册? 或者关于混淆的恶意软件? 我很感激任何参考。

2 个答案:

答案 0 :(得分:0)

嗯,不,不是那么简单。 首先,PEiD检测用于通过签名包装样品的包装机。所以你假设打包器有一个常量签名,这不是多态。多态性只是对文件进行模糊处理(加密,打包或编码)的方法,其中文件的反混淆部分(解密器)在每次感染时都会不断变化,因此不能从PEiD中提取静态签名。一个更普遍的想法是变形,不仅解密器改变,而且整个代码,然后不需要加密/解密,因为所有文件都不是常量..但是这些都很难写。

另一个挑战是当您决定自动停止解压缩过程时。直到现在,这是一个悬而未决的问题有一些启发式检测解密结束,但这些只能用于弱混淆方法。

答案 1 :(得分:0)

如上面的答案中所提到的,为了使语法签名起作用,您需要有一些可靠的机制来获取完整的解压缩二进制文件。然而,实施增量拆包的包装商(例如Themida和(我认为)Armadillo)使这很困难。其中一些增量打包程序创建打包的可执行文件,其中原始指令在本地函数或基本块级别打包/解包,即,在执行期间“及时”解压缩在函数之前的本地函数体或基本块上执行或块被执行。执行后,可以重新打包函数或块,以确保整个解压缩的可执行文件永远不会在内存中。

如果签名与函数或基本块之间的指令匹配,它将永远不会匹配,因为从来没有完全解压缩的程序出现在内存中。

  

为什么不考虑所有无法正确解压缩的软件的恶意软件?

看起来现有的AV扫描仪可以配置为执行此类操作,特别是将ANYTHING标记为恶意打包。在工作中,我正在使用几个标准打包器(UPX和Packman),AV扫描仪将触发并删除我创建的所有打包(良性)可执行文件。我最终在Linux下使用Wine运行打包程序以避免Windows AV。

  

是否包装了任何良性程序?

也许。我只看过一个打包的良性程序(我买的东芝外置USB驱动器附带的软件由于某种原因装满了UPX)。有些良性软件可能装有保护装置,使逆向工程更难。