为什么检测多态恶意软件如此困难?
解压缩恶意软件的加密部分后,是否有足够的生成签名?
然后简单地通过一个类似的过程将此签名与另一个可能版本的恶意软件匹配?
使用类似的过程,我的意思是使用像PEID这样的软件实时解压缩恶意软件的加密部分,然后根据以前生成的签名进行测试。
在使用签名时,我引用了杀毒软件中使用的经典签名(例如,常规的十六进制签名)。
编辑:
为什么不考虑恶意软件所有不能正确解压的软件?
良性软件也使用自定义包方法?
编辑:
你怎么知道软件是否被打包了?如果软件是打包的,你总是能意识到这一点吗?你能永远知道恶意软件的模糊部分的开始在哪里吗?
那拟态呢?
是否有关于多态恶意软件的书籍或手册?或者是关于混淆恶意软件?我很感谢你的推荐信。
发布于 2015-05-31 21:17:28
不,没那么简单。首先,PEiD检测用于用签名包装样本的封隔器。因此,您假设packer有一个常量签名,而不是多态。多态只是一种混淆(加密、打包或编码)文件的方法,其中文件的解混淆部分(解密器)在每次感染时都会不断变化,因此不能为PEiD从文件中提取静态签名。一个更普遍的想法是变形,其中不仅解密器改变,而且整个代码,然后不需要加密/解密,因为所有的文件不是常量。但这些都很难写。
另一个挑战是当您决定自动停止解压缩过程时。到目前为止,这是一个悬而未决的问题。有一些启发式方法可以检测解密的结束,但这些方法只能在弱混淆方法中工作。
发布于 2015-06-04 15:22:23
正如在上面的答案中提到的,为了使语法签名工作,您需要一些可靠的机制来获得完整的解压缩二进制文件。然而,实现增量解包(如Themida和(我认为) Armadillo)的包装器使得这很困难。这些增量包装器中的一些创建打包可执行程序,其中原始指令在本地函数或基本块级别上打包/解压缩,即在执行过程中,在执行函数或块之前在本地功能体或基本块上执行“及时”解压缩。执行之后,可以重新打包函数或块,以确保整个未打包的可执行文件永远不会在内存中。
如果签名与跨函数或基本块的指令匹配,它将永远不会匹配,因为在内存中永远不会出现完全解压的程序。
为什么不考虑恶意软件所有不能正确解压的软件?
看起来,现有的AV扫描器可以配置为这样的操作,特别是标记任何打包为恶意的内容。在工作中,我正在玩几个标准的包装机(UPX和Packman),AV扫描仪会触发和删除我创建的所有打包(良性)可执行文件。最后,为了避免Windows,我在Linux中运行了葡萄酒下的打包器。
有什么良性的程序吗?
也许吧。我只看到过一个被打包的良性程序(我购买的东芝外部USB驱动器附带的软件由于某种原因使用了UPX )。这是可能的,一些良性的软件包装了一个保护器,以使逆向工程更困难。
https://stackoverflow.com/questions/30534119
复制相似问题