求大神们轻喷……
注：本文测试主要依据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，火绒的反调试技术成熟了许多。但是由于其容量轻便的原因，导致其病毒库容量较小，杀毒的范围和能力有限。
