Virus 版 (精华区)

发信人: Kernel (Kermit), 信区: Virus
标  题: [合集]随便说说杀毒软件的速度和设计工具
发信站: 哈工大紫丁香 (2004年04月27日13:00:50 星期二), 站内信件


────────────────────────────────────────
 seak (江海客)                        于 Fri Mar 12 15:10:14 2004 说道:


首先说明一点，这篇文章只是有感而发。希望对反病毒感兴趣的
朋友有所参考。

今天讨论速度，不谈是否解包、解压缩这些先天问题，或者用户
配置问题，只是作为设计思路来做一个讨论。同时今天谈的重点是
scanner而不是monitor，虽然他们使用着同样的引擎。
杀毒软件的扫描时间花费在哪里呢，对一个完整的处理有毒的文
件的过程来说，那么这些环节可能都在消耗时间。

读扫描对象文件
对象预处理
病毒库匹配
病毒处理
屏幕显示
LOG。

1、关于病毒库：需要认识到的一个事实是，多数情况下，扫描
器面对的99%文件是无毒文件，我们必须按照这样的思路去考虑优化
的问题，多数情况下，检测文件所对应的子库是会被全部匹配到的。
试图以提高命中率作为减少扫描时间的思路是错误的。
原则上说，反病毒软件用于病毒匹配的主干引擎（不包括那些用
于深度检测）只需要有两个，其一是针对2进制类型文件的（针对感
染式病毒、worm、malware等等），其二是针对脚本类型文件（如各
种脚本病毒和宏病毒）。
从这个角度上说，病毒库只需要有两个，但客观上说，利用病毒
特征记录的标记做出相应的匹配子库，是减少扫描检测时间的很好方
式，因为我们前置一个格式分析模块会反馈给我们正确的数据类型，
因此我们降低了每个检测对象需要匹配规则的总数量。当然，如果我
们实现了一个时间与记录条数非线性的算法，则无所谓了。
让我们看看可以如何划分
PE特征库
MZ特征病毒库
普通2进制库

脚本病毒库
宏病毒库

另外，那些可能跨格式感染的，比如即感染对象，如果其特征没
有改变的话，这样的规则需要做一个特殊标志，以保证在内存生成子
库的时候，有这种标记的记录会被分发到不同子库中。


2、关于匹配引擎
不论病毒如何千变万化，必须认可的一个事实是，95%以上的病
毒反病毒软件依然是依靠特征码匹配的方式检测到的，而目前国内外
几乎所有的反病毒产品的特征码总数都在3万以上，即使我们对病毒
库作了分类，也要承受一个很大的匹配压力。因此匹配算法的优化很
重要。

假如这是一个纯的串匹配问题，那么问题其实很简单，这要看设
计者如何去理解这个问题： 
如果把病毒库匹配视为为多个单模式匹配的话，那么我们有很多
算法可以推荐，最著名的两个是KMP算法(Knuth-Morris-Pratt)和
BM算法（Boyer-Moore）。
当然如果使用有限自动机要更为快一些。
“有限自动机的基本思想是根据输入和当前的状态决定下一个
状态和输出，接着再进入下一次输入。在字符串多模式匹配中，向自
动机输入所要查找的目标字符串，自动机可以输出查找到的模式串以
及模式串在目标串的位置。有限自动机的构造过程是将模式串集合变
换成由转向函数，失效函数和输出函数所组成的树型有限自动机。模
式匹配的处理过程就变成了状态转换的处理过程。
有限自动机的构造中，每个模式串的字符是从前到后依次加到树
型的有限自动机中的，在匹配时，目标串的输入，即匹配过程，也是
按照从前到后的次序。”
但有限自动机需要逐一去查看文本的每个字符串，这是他的弱
点，而BM算法在不断屈的突破，相关资料希望读者自己去查询，或
者参考《算法导论》。

其实真正的客观问题是，反病毒软件即试图加快检测速度，同时
又想隐藏真正的病毒特征码，比如有些反病毒产品是用病毒入口点的
一端短码（比如2个dword，甚至是一个word）+一端长码的签名的
方法。
由于短码的长度比较短，而且短码会大大提高碰撞的概率，匹配
算法的效率就会严重下降，更何况在匹配到短码之后，还要根据offset
取到相应的长度计算sign。因此速度很慢也在情理之中。
如果是这种结构设计，就不该照搬上面的算法，而应该结合offset
的标志考虑新的算法。


3、关于IO
反病毒软件很可能70%以上的时间不是病毒匹配的时间，而是
IO时间。
关于IO的优化，我们也没有更多经验。但从体系结构上我们需
要做这样一个考虑，那就是假如说scanner是一个前台程序的话，我
们需要考虑到这样的问题：从宏观上看我们的工作序列是
读文件  | IO忙
预处理  | IO空闲
病毒匹配| IO空闲
….
读下一个文件 IO忙
…
可以看出，如果检测引擎是单线程的话，那么IO就没有充分得
到利用。如果检测引擎是多线程的话，那么可以保证把IO跑满。
同时其实屏显和写log要占用很多时间，这是我们有的时候不注
意的，特别是如果我们支持，反馈正常文件的话。

同时很重要的一点是，IO应该是封装在引擎之外的，不应该成
为检测引擎的一部分。

4、关于设计工具
vb能不能做反病毒软件，其实也没有什么可争论的，能。
虽然我们做框架的时候很方便，但如果下层模块都如此来实现，
肯定不是很舒服的。不要说monitor需要做驱动。比如独占打开文件
如何读出，流文件如何读写等等。
不过如果只是用VB或者dephi之类来做一个gui框架，那倒也不
错。从主流反病毒产品来看以c和asm混合编程为主。框架以c++实
现，底层模块或者用c或者用asm，这是很老套了，但还是很好用的。
    
午休的时间到了，干活去也，下次再聊。
                 2004年3月12日于Antiy Labs

────────────────────────────────────────
 Sun (大灯泡)                         于 2004年03月12日15:56:45 星期五 说道:

scaner能否跨过系统级I/O，直接扫描非空闲扇区，发现病毒再回追文件名呢？
这样效率能增高，不过遇到特征码不连续的问题会有些麻烦。
这样还有一个好处是多线程操作时，可以控制不同线程扫描不同的盘片，更好地榨取I/O资
源。不过我觉得多线程未必能提高速度，还不如用非阻塞型I/O，在等数据的时候特征匹配
。
另外曾经听一个专门研究系统级存储的朋友说过，在windows下把缓冲区开成64k的i/o效率
最高，能提高至少30%
【 在 seak (江海客) 的大作中提到: 】
: 
: 首先说明一点，这篇文章只是有感而发。希望对反病毒感兴趣的
: 朋友有所参考。
: 
: 今天讨论速度，不谈是否解包、解压缩这些先天问题，或者用户
: 配置问题，只是作为设计思路来做一个讨论。同时今天谈的重点是
: scanner而不是monitor，虽然他们使用着同样的引擎。
: 杀毒软件的扫描时间花费在哪里呢，对一个完整的处理有毒的文
: 件的过程来说，那么这些环节可能都在消耗时间。
: 
: 读扫描对象文件

────────────────────────────────────────
 seak (江海客)                        于 Fri Mar 12 17:21:55 2004 说道:


【 在 Sun 的大作中提到: 】
: scaner能否跨过系统级I/O，直接扫描非空闲扇区，发现病毒再回追文件名呢？
: 这样效率能增高，不过遇到特征码不连续的问题会有些麻烦。
这个恐怕不行，杀毒软件是效力优先与效率的，而且离开了格式识别和格式预处理
很多病毒检测都无法进行了。


: 【 在 seak (江海客) 的大作中提到: 】
: : 
: : 首先说明一点，这篇文章只是有感而发。希望对反病毒感兴趣的
: : 朋友有所参考。
: : 
: : 今天讨论速度，不谈是否解包、解压缩这些先天问题，或者用户
: : 配置问题，只是作为设计思路来做一个讨论。同时今天谈的重点是
: : scanner而不是monitor，虽然他们使用着同样的引擎。
: : 杀毒软件的扫描时间花费在哪里呢，对一个完整的处理有毒的文
: : 件的过程来说，那么这些环节可能都在消耗时间。
: : 
: : 读扫描对象文件

────────────────────────────────────────