求大神们轻喷……
注:本文测试主要依据3.x版本的病毒库,但是4.x环境依然有效
0x0
调试了好几个晚上,在茫茫汇编代码里,在无穷无尽的各种结构体里,太容易绕晕了,一个结构体套一个结构体,一个指针一个函数都容易乱指地址,看着看着就晕乎了……
写本文有些忐忑,但是处于对火绒的一个评价的态度,还是希望火绒今后会更加强大一些,同时,这里的测试不够全面,仅仅测试了几个小的方面。
0x1简介
前几天发现火绒已经升级到4.x版本了。于是乎,好奇心比较重,然后用x64dbg调试之。这里说一下,x64dbg已经可以完全代替OD了,谁用谁知道啊……
0x2病毒库
就目前技术而言,无论什么杀毒软件,依然绕不开病毒库的。火绒的病毒库有4个文件。Ps:但是我只发现prop和pset两个库有关联,(其他的库,我真的没用到……)
火绒的病毒库比较坑,不是直接解压了就可以用的。而是各种xor解密,还有一个函数专门负责算key的函数。
在这4个病毒库中:
Pset.db主要是病毒名称。
Prop.db包含了特征码和特征字符串等
Hwl、troj两个库,还真没用到……
但是,不要以为病毒库这样就结束了,在文件libvxf开头的dll文件中,依然发现了病毒匹配判断的相关函数。
下图:病毒库header部分的结构体如下,如果有未知的,就当看不到看不到吧……
经过一长串循环计算,病毒库xor完毕,解压就是利用zlib啦,解压后,病毒库文件建立索引。(ps:这里的索引,是我这么称呼的- -具体是什么,得火绒的大神来解释了。还有一点比较有意思的地方,我猜测这个写索引的作者:是198707xx出生的(xx是我故意给隐藏的),因为代码里用了198707xx来做计算……),这里我直接dump出来了整个添加了索引的病毒库。
下图所示建立索引前后的对比:
Ps:有趣的一点是,在火绒3.x年代,有处代码写的相对不严谨,虽然在4.x时代已经修改了。这处代码如下:malloc后直接去使用了,而没有验证申请的内存是否成功……
0x3静态扫描
关于静态扫描,我只测试了几个较为简单的。所以不能以偏概全。
测试1:conficker病毒无壳版
Conficker病毒作为典型的僵尸网络病毒,依然活跃在互联网络上。此次用它测试也正是来看看火绒的静态扫描能力。
果不其然,火绒发现了病毒……
经过调试,我发现病毒库中命中conficker的特征有4条,如下图:
其中第一条匹配数据库prop.db内容:prop是病毒特征库。
然后我们再来看看在pset中命中了多少条索引呢?如下图。可见在pset中命中4条索引,然后修改
通过上图,我们发现,火绒在判断是否是病毒的时候一种方法是,采用了多段内容间字符串匹配,来预防误报。如果pset中的索引能匹配到3条,则可以确定是病毒,并且报毒,然后通过pset进行确认病毒名称。
如此,火绒在某些病毒匹配过程中,会依靠特定的字符串进行匹配。既然如此,我们修改一下被检测到的字符串,再来测试,如下图:(右侧是修改后的)
修改后,没有再报毒了……
再测试一个Linux病毒。
这个是命中4条特征:
特征1:67 65 74 52 61 6E 64 6F 6D 49 50
特征2:63 6F 6D 6D 53 65 72 76 65 72
特征3:73 65 6E 64 4A 55 4E 4B
特征4:73 63 61 6E 50 69 64
通过上述两个病毒匹配,发现火绒杀毒在匹配特征码的过程中,采用了匹配API名称和独有字符串的方法来检测的。在字符串匹配模式下,只要稍微修改一丢丢,即可绕过检测,匹配API过程中,需要在源码中修改API的名称来绕过检测。在这方面匹配的过程中,火绒还是考虑不够严谨。
测试2:特征码匹配
特征码匹配作为传统的匹配方式,在各种杀毒软件中屡见不鲜。火绒也不会避过这些特征。下面,我们通过几个例子代码,可见一斑。(不要误解这个词语的意思啊,语文一定要学好……)
我们在此选择libvfx自带的程序进行匹配。
例子1:
例子2:
其实从这些例子中,我们不难发现,特征码匹配的方式相对更容易绕过,这完全是依靠病毒库大量的数据进行安全防护……
当然,这里的测试不够全面,还有一些沙盒测试,其他匹配没有测试到。不可能方方面面全面的总结火绒。
0x4总结
火绒作为新兴的杀毒软件,默默耕耘着自己的一片天地,从火绒3.x版本到现在4.x,火绒的反调试技术成熟了许多。但是由于其容量轻便的原因,导致其病毒库容量较小,杀毒的范围和能力有限。
[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入!