荔园在线
荔园之美，在春之萌芽，在夏之绽放，在秋之收获，在冬之沉淀
[回到开始]
[上一篇][下一篇]
发信人: mmkiller (玩乐主义者), 信区: Virus
标 题: 全球流行的几款杀毒软件的引擎zz
发信站: 荔园晨风BBS站 (2006年01月04日13:00:02 星期三), 站内信件
看好文章就转贴分享给大家!
为防止误解，特作如下声明：
1.鉴于个人能力有限，文中大量借用了业已在病毒界获得公认的两篇文章：先进杀毒
引擎的设计原理 ，流行杀毒软件的引擎设计 。
2.为便于理解，文中很多词语未使用严格的工业研发用语。比如杀毒引擎的前端正式
名称为“基于初步预扫描的（文件）对象汇入工程部分”。很多工业用语听起来很拗口
，自己变通了一下，感兴趣者可查阅L.Felly:系统的安全与防护 中的有关章节。
3.我认为现今在全球流行的几款杀毒软件在技术上并不存在谁的技术远远领先的问题
，没有必要过与赞扬那一款杀毒软件，自己用着高兴就好。文中对某些杀软的介绍比较
详细，主要是因为它的资料较多，有东西可写，没有其余的意思。
4.到现在为止，我已经用过几乎所有的杀毒软件（论坛上提到的）
5. 我个人非常不喜欢设计病毒，私下写过的几个纯粹是写着玩，大部分时候是MM生
气的时候写个玩笑程序让她高兴用的
6.很长时间不在专业病毒论坛上走动了。我认为如果因为喜欢程序设计看一下病毒
的代码是可以的，当出于其他目的的时候，还是收手吧。
7.鉴于个人能力原因，有一部分是MM写的，MM很漂亮，也很娇气，但对我基本上言
听计从，必经一起走过了十几年了。原帖子中有一部分是错误的，已经由她修改过。
8.文中有一部分内容来自一个朋友提供的杀毒软件公司的开发文档，我已经大幅改
动过。
9.本人是学生，且正在忙于考G，上网的时间并不怎么多，因此很多问题可能并不能
及时作出解答，还望原谅。
10.我一直在使用的杀毒软件（其余的半路都卸了）：SAV9.0，KV2004（两套系统）
。在我看来杀毒软件就只是一款软件罢了，没必要大家为用什么争来争去，自己感觉好
就行了，争论的时间还不如用来多陪陪女友呢。
正文部分
文章比较长，加之本人写作水平有限和某些技术文档需要核实，只能写一段发一段
，还望大家原谅。有误之处，敬请指出，谢谢！（各段数值标出,每次均对该文件进行编
辑.
1.什么是杀毒软件引擎，与病毒库的关系？
首先必须指出杀毒软件的引擎与其病毒库并没有什么直接的关系。杀毒引擎的任务
和功能非常简单，就是对于给定的文件或者程序进程判断其是否是合法程序（对应于杀
毒软件厂商自己定义的正常和非异常程序规范而言。正常的程序规范是指在程序所在系
统平台上操所系统本身洗净有定义的或者业界已经公认的程序行为过程，比如操作系统
正常运行就必须要求应用程序与系统核心进行进程响应并与交换相关数据。非异常程序
活动是指可能存在非法程序操作结果但能够以较高的置信度确定其非非法程序活动规范
的。一般情况下，相关文件的复制，移动，删除等都奔包括在该界定范围内）。
我们知道病毒的最终目的有些是与合法活动很类似的，在这种情况下，要求软件厂
商必须自己有一个行为规范界定规则，在一个给定的范围和置信度下，判断相关操作是
否为合法。在这方面，各个厂商的界定是有区别的，一般而言非美国厂商界定是非常严
格的，只有有很高的置信水平的程序行为，他们才判别为非病毒操作。记得前一阵论坛
上有人给了四段简单的代码，很多杀毒软件将其判为病毒或有病毒性质的文件行为，实
际上看那几段代码可以知道，其结果并不足以视之为病毒。美国厂商一般判断比较复杂
，这主要由于美国市场上的杀毒软件引擎来源比较复杂，比如诺顿，有足够的技术资料
确信它的杀毒软件引擎是自成体系的，而mcafee 则存在一定的外界技术引进（收购所罗
门）。
用简单的话说，杀毒引擎就是一套判断特定程序行为是否为病毒程序（包括可疑的
）的技术机制。一个完整的技术引擎遵守如下的行为过程：
1.非自身程序行为的程序行为捕获。包括来自于内存的程序运行，来自于给定
文件的行为虚拟判断，来自于网络的动态的信息等等。一般情况下，我们称之为引擎前
端。捕捉的方法非常多，除诺顿以外的杀毒软件采用的都是行为规范代码化的方法。诺
顿由于与微软有这远远高于其它厂商合作关系，其实现过程比较独特，另有叙述。
2.基于引擎机制的规则判断。这个环节代表了杀毒引擎的质量水平，一个好的
杀毒引擎应该能在这个环节发现很多或者称之为相当规模的病毒行为，存而避免进入下
一个判断环节。传统的反病毒软件引擎使用的是基于特征码的静态扫描技术，即在文件
中寻找特定十六进制串，如果找到，就可判定文件感染了某种病毒。但这种方法在当今
病毒技术迅猛发展的形势下已经起不到很好的作用了。为了更好的发现病毒，相继开发
了所谓的虚拟机，实时监控等相关技术。这个环节被叫做杀毒软件引擎工作的核心层。
3.引擎与病毒库的交互作用。这个过程往往被认为是收尾阶段，相对于前两个
环节，这个阶段速度是非常慢的，杀毒引擎与要将非自身程序行为过程转化为杀毒软件
自身可识别的行为标识符（包括静态代码等），然后与病毒库中所存贮的行为信息进行
对应，并作出相应处理。当然必须承认，当前的杀毒软件对大量病毒的识别都是在这个
阶段完成的。因此一个足够庞大的病毒库往往能够弥补杀毒软件引擎的不足之处。但是
必须意识到，如果在核心层阶段就可以结束并清除病毒程序，那么杀毒软件的工作速度
将会大幅提升。“很可惜的是，当前我们没有足够聪明的杀毒引擎来完成这个过程”，
这就是为什么有病毒库的原因。
诺顿是微软最高级的安全方面核心合作厂商，因此它的杀毒软件在某些方面工作
比较特殊。比如在杀毒软件的安装，使用和功能实现方面，大部分厂商采用的是中间件
技术，在系统底层与非自身应用程序之间作为中间件存在并实现其功能；另有一些厂商
使用的是应用程序或者嵌入技术，相对而言这种方法安全性较低；诺顿和 mcafee实现方
式比较相似，诺顿采用了基于系统最底层的系统核心驱动，这种实现方式是最安全的或
者说最高级的实现方式，当然这需要微软的系统源代码级的支持（要花许多money），业
界公认，这是最稳定的实现方法，但从目前而言，只诺顿一家。Mcafee实现方式与诺顿
很接近，一般称之为软件驱动。相当于在系统中存在一个虚拟“硬件”，来实现杀毒软
件功能。这些实现方式关系着杀毒引擎对程序行为进行捕捉的方式。
我们使用的intel系的处理器有两个 ring层，对应两个层，微软的操作系统将
系统中的所有行为分为如下几个层：
1.最底层：系统核心层，这个层的所有行为都由操作系统已经内置的指令
来实现，所有外界因素（即使你是系统管理员）均不能影响该层的行为。诺顿的核心层
既工作在这个层上。
2.硬件虚拟层，一般称之为HAL。为了实现硬件无关性，微软设计了该层。
所有的外部工作硬件（相对于系统核心而言）都进入HAL，并被 HAL处理为核心层可以相
应的指令。我们所使用的硬件的驱动程序既工作在该层上。当外界硬件存在指令请求时
，驱动程序作出相关处理后传给核心层。如果无与之对应的驱动相应，那么将按照默认
硬件进行处理。好像安全模式下硬件的工作就被置于默认硬件模式。Mcafee被认为工作
与该层上。
3.用户层（分为两个子层，不详细叙述，感兴趣的可以查阅《windows xp入
门到精通》（有中文版），第二部分四节有叙述）。我们所知的大部分杀毒软件既工作
与该层上。一个完整的程序行为请求是如下流程：位于3户层上的应用程序产生指令行为
请求，被传递至2HAL进行处理，最后进入1最底层后进入CPU的指令处理循环，然后反向
将软件可识别的处理结果经1－2－3再响应给应用程序。对于诺顿而言，其整个工作过程
如下：3-2-1，完成；mcafee：3-2-1-1-2，完成：其余：3-2-1-1-2-3，完成；这个环节
代表了杀毒软件引擎的前端行为规范的获得。只从这个过程而言，诺顿和mcafee是比较
先进的。（具体的系统与CPU的ring()的对应，记不清楚了。 WinNT时代，微软的NT系统
被设计有与四个ring()层相对应，RISC系列的处理器有四个ring。因此现在的大部分杀
毒软件是不能工作与NT上的。具体的CISC和RISC的ring()数我记得可能有误，反正是一
个2ring(),一个4ring().）。
尽管比较先进的工作方式给诺顿和mcafee带来了较高的系统稳定性（HAL层很少出现
问题，最底层出问题的几率接近于零），较快的响应速度（减少了环节），但同时也带
来了一些问题：1.资源占用比较厉害。在mcafee上体现的不是很明显，在诺顿上表现非
常明显。因为对于越底层的行为，硬件资源分配越多。最好资源的是什么？当然是操作
系统。应为它最最底层。2.卸载问题。卸载底层的组件出问题的概率是相对比较高的，
因此诺顿的卸载比较慢，偶尔还出问题。
有人质疑由于微软操作系统的不稳定性是否会拖累诺顿，想开发人士询问后得知，微软
操作系统的内核层设计是非常优秀的，很多时候操作系统的不稳定性来源于以下几个方
面：
1.应用程序设计不合理，许多程序设计者根本就未读过微软的32位程序设计
指南，所设 计的程序并不严格符合微软规范。我们看到很多软件多年前设计还能运行
于最新的xp平台，原因很简单：这个软件在设计时完全遵循了微软的程序设计规范。
2. 驱动程序的编写有问题，与HAL层有冲突。
因此认为微软的操作系统将会影响诺顿的稳定性是不合理的。
注:刚才问了一下偶MM,她告诉我应该是CISC有四个ring(),RISC有两个ring().对应
于系统的最低层而言，工作在ring0()上。应用程序工作在ring3()上 。偶的记忆力比较
差，文中可能有部分技术错误，请原谅。
业界有人认为，先进杀毒软件的引擎设计已经日趋复杂，类如诺顿这一类的厂商
其产品的引擎应该已经覆盖了操作系统的各个层级，以提高防护能力。在一篇文档中有
程序员提出有足够的信息认为诺顿，mcafee，趋势的产品自己修改了标准的系统相关协
议，比如TCP/IP等，以达到所谓的完整防护的目的。 NOD32的一篇官方文档（说实话，
我没有看到过）指出有必要全面更新（说白了就是修改）系统的诸多协议，以达到最快
的速度和杀毒效果。
要讨论怎样反病毒，就必须从病毒技术本身的讨论开始。正是所谓“知己知彼，百战不
殆”。很难想象一个毫无病毒写作经验的人会成为杀毒高手。目前国内一些著名反病毒
软件公司的研发队伍中不乏病毒写作高手。只不过他们将同样的技术用到了正道上，以
‘毒’攻‘毒’。当今的病毒与DOS和WIN3.x时代下的从技术角度上看有很多不同。最大
的转变是：引导区病毒减少了，而脚本型病毒开始泛滥。原因是在当今的操作系统下直
接改写磁盘的引导区会有一定的难度（DOS则没有保护，允许调用INT13直接写盘），而
且引导区的改动很容易被发现，并且微软在设计操作系统时加强了对引导区的程序行为
管理，写一个完美的引导区病毒难度很大，所以很少有人再写了；而脚本病毒以其传播
效率高且容易编写而深得病毒作者的青睐。但是最最落后的杀毒引擎也就是只基于静态
代码的杀毒引擎都能干掉该种病毒（病毒库搞好就行）。
要讨论的技术主要来自于二进制外壳型病毒（感染文件的病毒），并且这些技术
大都和操作系统底层机制或386以上CPU 的保护模式相关，值得研究。DOS下的外壳型病
毒主要感染 16位的COM或EXE文件，由于DOS没有（文件和引导区）保护，它们能够轻松
地进行驻留，减少可用内存（通过修改MCB链），修改系统代码，拦截系统服务或中断。
而到了WIN9X和WINNT/2000时代，搞个运行其上的32位WINDOWS病毒变得难了点。由于存
在页面保护，你不可能修改系统的代码页（如果你强到连操作系统代码都能改，偶无话
可说）。由于I/O许可位图中的规定，你也不能进行直接端口访问（29A的一个美女[听说
叫 Mercy.Chan]可以通过汇编方法直接访问端口的目的，但是没有见过给出事例代码。
知道得给介绍一下她的程序代码）WINDOWS中你不可能象在 DOS中那样通过截获INT21H来
拦截所有文件操作。总之，你以一个用户态权限运行，你的行为将受到操作系统严格的
控制，不可能再象DOS下那样为所欲为了（在xp中，这种权限管理极为严格，大致分成了
4-8个等级）。 WINDOWS下采用的可执行文件格式和DOS下的 EXE截然不同（普通程
序采用PE格式，驱动程序采用LE），所以病毒的感染文件的难度增大了（PE和LE比较复
杂，中间分了若干个节，如果感染错了，将导致文件不能继续执行）。当今病毒的新技
术太多，随便介绍几个。
1.系统核心态病毒
386及以上的CPU实现了4个特权级模式（WINDOWS只用到了其中两个），其中特权
级0（Ring0）是留给操作系统代码，设备驱动程序代码使用的，它们工作于系统核心态
；而特权极3（Ring3）则给普通的用户程序使用（我想知道一个问题，ring1,2是干什么
的？），它们工作在用户态。运行于处理器核心态的代码不受任何的限制，可以自由地
访问任何有效地址，进行直接端口访问。而运行于用户态的代码则要受到处理器的诸多
检查，它们只能访问映射其地址空间的页表项中规定的在用户态下可访问页面的虚拟地
址，且只能对任务状态段（TSS）中I/O许可位图（I/O Permission Bitmap）中规定的可
访问端口进行直接访问（此时处理器状态和控制标志寄存器EFLAGS中的IOPL通常为0，指
明当前可以进行直接I/O的最低特权级别是Ring0）。以上的讨论只限于保护模式操作系
统，象DOS这种实模式操作系统则没有这些概念，其中的所有代码都可被看作运行在核心
态。既然运行在核心态有如此之多的优势，那么病毒当然没有理由不想得到Ring0。处理
器模式从Ring3向Ring0的切换发生在控制权转移时，有以下两种情况：访问调用门的长
转移指令CALL，访问中断门或陷阱门的INT指令。具体的转移细节由于涉及复杂的保护检
查和堆栈切换，不再赘述，请参阅相关资料。现代的操作系统通常使用中断门来提供系
统服务，通过执行一条陷入指令来完成模式切换，在INTEL X86上这条指令是INT，如在
WIN9X下是INT30（保护模式回调），在LINUX下是INT80，在WINNT/2000下是INT2E。用户
模式的服务程序（如系统DLL）通过执行一个INTXX来请求系统服务，然后处理器模式将
切换到核心态，工作于核心态的相应的系统代码将服务于此次请求并将结果传给用户程
序。
在即将发布的xp-sp2中采用所谓增强的内存页面保护将会更为严格的控制用户权
限，据说在访问内存地址时得到的将是经过系统映射处理的对应内存范围，在内存实地
址与用户层之间，搞了一个类似于转换协议的东西，害的很多软件都不能运行，应为他
们总是试图按照原有的HAL层访问规则进行工作。
2.驻留病毒
驻留病毒是指那些在内存中寻找合适的页面并将病毒自身拷贝到其中且在系统运
行期间能够始终保持病毒代码的存在。驻留病毒比那些直接感染（Direct- action）型
病毒更具隐蔽性，它通常要截获某些系统操作来达到感染传播的目的。进入了核心态的
病毒可以利用系统服务来达到此目的，如CIH病毒通过调用一个由VMM导出的服务VMMCAL
L _PageAllocate在大于0xC0000000的地址上分配一块页面空间。而处于用户态的程序要
想在程序退出后仍驻留代码的部分于内存中似乎是不可能的，因为无论用户程序分配何
种内存都将作为进程占用资源的一部分，一旦进程结束，所占资源将立即被释放。所以
我们要做的是分配一块进程退出后仍可保持的内存。
病毒写作小组29A的成员GriYo 运用的一个技术很有创意：他通过CreateFileMappingA
和MapViewOfFile创建了一个区域对象并映射它的一个视口到自己的地址空间中去，并把
病毒体搬到那里，由于文件映射所在的虚拟地址处于共享区域（能够被所有进程看到，
即所有进程用于映射共享区内虚拟地址的页表项全都指向相同的物理页面），所以下一
步他通过向Explorer.exe中注入一段代码（利用WriteProcessMemory来向其它进程的地
址空间写入数据），而这段代码会从Explorer.exe的地址空间中再次申请打开这个文件
映射。如此一来，即便病毒退出，但由于Explorer.exe还对映射页面保持引用，所以一
份病毒体代码就一直保持在可以影响所有进程的内存页面中直至Explorer.exe退出（我
直接试过该种方法，在xp下注意要写一个空循环语句，以免被踢出处理队列）。
另外还可以通过修改系统动态连接模块（DLL）来进行驻留。WIN9X下系统DLL（如Kerne
l32.dll 映射至BFF70000）处于系统共享区域（2G-3G），如果在其代码段空隙中写入一
小段病毒代码则可以影响其它所有进程。但Kernel32.dll 的代码段在用户态是只能读不
能写的。所以必须先通过特殊手段修改其页保护属性；而在WINNT/2000/xp系统DLL所在
页面被映射到进程的私有空间（如 Kernel32.dll 映射至77ED0000）中，并具有写时拷
贝属性，即没有进程试图写入该页面时，所有进程共享这个页面；而当一个进程试图写
入该页面时，系统的页面错误处理代码将收到处理器的异常，并检查到该异常并非访问
违例，同时分配给引发异常的进程一个新页面，并拷贝原页面内容于其上且更新进程的
页表以指向新分配的页。这种共享内存的优化给病毒的写作带来了一定的麻烦，病毒不
能象在WIN9X下那样仅修改Kernel32.dll一处代码便可一劳永逸。它需要利用 WritePro
cessMemory来向每个进程映射Kernel32.dll的地址写入病毒代码，这样每个进程都会得
到病毒体的一个副本，这在病毒界被称为多进程驻留或每进程驻留（Muti-Process Res
idence or Per-Process Residence ）。
文中列举方法在xp－sp1下略作修改即可使用 ，大部分为在代码段内加入空循环 。在s
p2下，很多时候报如下类型的错误不可访问的内存地址段.........。
在原来的帖子中我援引了另一篇文档中的例子，但经MM告知那些挂钩-捆绑等方法在如今
的设计中并不是很受欢迎，原因在于新的操作系统许多函数规则是不可预知的，也就是
所谓的”黑箱“设计使得设计人员更加偏爱系统级别的线程捆绑或者更加直接的接管权
限控制的方法，采用最复杂的线程捆绑技术甚至可以使杀毒软件和防火墙得不到足够的
信息来区分一个程序是否合法。更高级别的抢夺权限控制甚至可以结束所有杀毒软件的
进程，包括卡巴斯基所采用的受保护的内存线程技术。
尽管微软隐藏了很多系统函数，但是经过很多高手的努力，许多隐藏的系统函数已
经被找出，并且微软也有意识的减少隐藏函数的数量。在前段时间网上泄漏的 2000的部
分代码中，其中关于磁盘文件读写的部分（大小为700M的那个压缩包里标号为115BH的那
个文件其中的第三节子代码）其中有很多进程是微软的开发文档中是没有给出介绍的，
不知道以后会不会有人利用这些东西写病毒。对病毒稍微有些常识的人都知道，普通病
毒是通过将自身附加到宿主尾部（如此一来，宿主的大小就会增加），并修改程序入口
点来使病毒得到击活。但现在不少病毒通过使用特殊的感染技巧能够使宿主大小及宿主
文件头上的入口点保持不变。附加了病毒代码却使被感染文件大小不变听起来让人不可
思议，其实它是利用了PE文件格式的特点：PE文件的每个节之间留有按簇大小对齐后的
空洞，病毒体如果足够小则可以将自身分成几份并分别插入到每个节最后的空隙中，这
样就不必额外增加一个节，因而文件大小保持不变。著名的CIH病毒正是运用这一技术的
典型范例（它的大小只有1K左右）。
病毒在不修改文件头入口点的前提下要想获得控制权并非易事：入口点不变意味着程序
是从原程序的入口代码处开始执行的，病毒必须要将原程序代码中的一处修改为导向病
毒入口的跳转指令。原理就是这样，但其中还存在很多可讨论的地方，如在原程序代码
的何处插入这条跳转指令。一些查毒工具扫描可执行文件头部的入口点域，如果发现它
指向的地方不正常，即不在代码节而在资源节或重定位节中，则有理由怀疑文件感染了
某种病毒。所以刚才讨论那种病毒界称之为EPO（入口点模糊）的技术可以很好的对付这
样的扫描，同时它还是反虚拟执行的重要手段。
另外值得一提的是现在不少病毒已经支持对压缩文件的感染。如Win32.crypto病毒
就可以感染ZIP，ARJ，RAR，ACE，CAB 等诸多类型的压缩文件。这些病毒的代码中含有
对特定压缩文件类型解压并压缩的代码段，可以先把压缩文件中的内容解压出来，然后
对合适的文件进行感染，最后再将感染后文件压缩回去并同时修改压缩文件头部的校验
和。目前不少反病毒软件都支持查多种格式的压缩文件，但对有些染毒的压缩文件无法
杀除。原因我想可能是怕由于某种缘故，如解压或压缩有误，校验和计算不对等，使得
清除后压缩文件格式被破坏。病毒却不用对用户的文件损坏负责，所以不存在这种担心
。
个人看来，目前的杀毒软件在对待加壳病毒的时候表现比较差的为瑞星，怀疑瑞星
的杀毒引擎对加壳的东西放映不灵敏，因此瑞星自己加壳了很多病毒放到病毒库里，我
曾使用一些很少用的加壳方式对某些普通病毒加壳，结果瑞星没查出来，有待改进。
以上关于病毒的相关文字均来源于 某病毒论坛的文章 ，我个人作了少量修改 。再
往下为引擎部分的实现 。
杀毒引擎目前主流有两种实现方式：1.虚拟机技术 2.实时监控技术 3.智能码标识技术
4.行为拦截技术 3.4.为最近两年搞出来的技术。3的目的是提高杀毒速度并且预防未知
病毒，但就现实而言，除了东方卫士试验了一下（并且不成功），其余厂商未开发完全
基于该技术的引擎，诺顿的开发人员认为：“没有足够的技术手段来实现文中所提出的
杀毒理念（翻译的可能有不准确之处。‘文中’是指智能码标示技术的理论基础：IBM
:Another way to the end (实现目的的另一种方式)，在该文中提出了基于预定规则的
智能杀毒技术）”。行为拦截技术（或者别的什么智能杀毒技术）也是一种预防未知病
毒的方法，与虚拟机技术相似，通过对程序行为的分析来判断其是否为病毒。
对于未知病毒的判断实际上代表着杀毒软件厂商在引擎研究方面的最高能力。业
界公认，防止未知病毒是“代表研究水平的”。平心而论，非美国厂商在这方面能力较
差。业界对于防止未知病毒能力是按照如下方法衡量的：以评测当日的杀毒软件最新版
本为该厂商的供测试版本，未知病毒由如下而来： 1.病毒作者提供。有些病毒作者在将
自己的病毒发布以前总爱送给一些业界的安全杂志供其评测（最佩服这种人）2.大部分
真正的业界安全杂志都有自己的研究实验室，他们自己的研究人员会根据最新的趋势和
技术手段及工具写一些病毒。一般情况下，这些病毒是不会流到网上去的。3.假病毒。
一些很类似于病毒行为的文件，程序等。测试的时候病毒库被置空（就是杀毒软件试图
调用病毒库时采用程序方法向其返回一个空结果），在这种情况下进行测试。如果有人
有兴趣，可以到病毒论坛上搞点新手写的小病毒（一般也就100-200行），弄上几十个拿
自己的杀毒软件试一试，就会发现在平均状态下诺顿病毒库被置空时起对未知病毒判断
能力还是挺强的，怎么着也到了x%,(x为两位数)，很多杀毒软件结果挺惨的，尤其在对
付比较复杂的蠕虫病毒时，某厂商的产品近乎全军覆没。下面对虚拟机和实时监控进行
介绍。由于大家认为在文中加入程序代码看着很累，因此不再给出技术实现代码，其实
根据原理你自己也可以写出来。
虚拟机，在反病毒界也被称为通用解密器，已经成为反病毒软件中最重要的部分
之一虚拟机的概念和它与诸如Vmware和WIN9X下的VDM（DOS 虚拟机，它用来在32位保护
模式环境中运行16实模式代码）是有区别的。其实这些虚拟机的设计思想是有渊源可寻
的，都来自于IBM的一批研究人员搞的一套东西。 Vmware作为原操作系统下的一个应用
程序可以为运行于其上的目标操作系统创建出一部虚拟的机器，目标操作系统就象运行
在单独一台真正机器上，丝毫察觉不到自己处于Vmware的控制之下。当在Vmware中按下
电源键（Power On）时，窗口里出现了机器自检画面，接着是操作系统的载入，一切都
和真的一样。而WIN9X为了让多个程序共享CPU和其它硬件资源决定使用VMs（所有Win32
应用程序运行在一部系统虚拟机上；而每个16位DOS程序拥有一部DOS虚拟机），winxp是
采用区域内存访问来实现16位程序支持的。 VM是一个完全由软件虚构出来的东西，以和
真实电脑完全相同的方式来回应应用程序所提出的需求。从某种角度来看，你可以将一
部标准的PC的结构视为一套 API。这套API的元素包括硬件I/O系统，和以中断为基础的
BIOS和MS-DOS。WIN9X常常以它自己的软件来代理这些传统的API元素，以便能够对珍贵
的硬件多重发讯。在VM上运行的应用程序认为自己独占整个机器，它们相信自己是从真
正的键盘和鼠标获得输入，并从真正的屏幕上输出。稍被加一点限制，它们甚至可以认
为自己完全拥有CPU和全部内存。
查毒的虚拟机并不是象某些人想象的：如Vmware一样为待查可执行程序创建一个
虚拟的执行环境，提供它可能用到的一切元素，包括硬盘，端口等，让它在其上自由发
挥，最后根据其行为来判定是否为病毒。当然这是个不错的构想，但考虑到其设计难度
过大（需模拟元素过多且行为分析要借助人工智能理论），因而只能作为以后发展的方
向。就目前可以知道的信息而言，卡巴斯基在这方面做得还可以，mcafee的新产品中加
入了一种溢出保护技术，本质上而言也是一种所谓的虚拟技术。查毒的虚拟机是一个软
件模拟的CPU，它可以象真正CPU一样取指，译码，执行，它可以模拟一段代码在真正CP
U上运行得到的结果。给定一组机器码序列，虚拟机会自动从中取出第一条指令操作码部
分，判断操作码类型和寻址方式以确定该指令长度，然后在相应的函数中执行该指令，
并根据执行后的结果确定下条指令的位置，如此循环反复直到某个特定情况发生以结束
工作，这就是虚拟机的基本工作原理和简单流程。设计虚拟机查毒的目的是为了对付加
密变形病毒，虚拟机首先从文件中确定并读取病毒入口处代码，然后以上述工作步骤解
释执行病毒头部的解密段（decryptor），最后在执行完的结果（解密后的病毒体明文）
中查找病毒的特征码。这里所谓的“虚拟”，并非是创建了什么虚拟环境，而是指染毒
文件并没有实际执行，只不过是虚拟机模拟了其真实执行时的效果。这就是虚拟机查毒
基本原理。曾经跟搞杀毒的技术人员探讨是否可以采用模拟实际执行的方法来搞一套杀
毒软件，回答是微软可以，因为微软可以在系统底层搞一套硬件虚拟层，来实现硬件虚
拟。我忽然想到，如果微软真的搞杀毒软件，其实无论别的杀毒软件公司多么强，大家
都得彻底玩完。
早期病毒没有使用任何复杂的反检测技术，如果拿反汇编工具打开病毒体代码看到
的将是真正的机器码。因而可以由病毒体内某处一段机器代码和此处距离病毒入口（注
意不是文件头）偏移值来唯一确定一种病毒。查毒时只需简单的确定病毒入口并在指定
偏移处扫描特定代码串。这种静态扫描技术对付普通病毒是万无一失的。
随着病毒技术的发展，出现了一类加密病毒。这类病毒的特点是：其入口处具有解
密子（decryptor），而病毒主体代码被加了密。运行时首先得到控制权的解密代码将对
病毒主体进行循环解密，完成后将控制交给病毒主体运行，病毒主体感染文件时会将解
密子，用随机密钥加密过的病毒主体，和保存在病毒体内或嵌入解密子中的密钥一同写
入被感染文件。由于同一种病毒的不同传染实例的病毒主体是用不同的密钥进行加密，
因而不可能在其中找到唯一的一段代码串和偏移来代表此病毒的特征，似乎静态扫描技
术对此即将失效。但仔细想想，不同传染实例的解密子仍保持不变机器码明文（从理论
上讲任何加密程序中都存在未加密的机器码，否则程序无法执行），所以将特征码选于
此处虽然会冒一定的误报风险（解密子中代码缺少病毒特性，同样的特征码也会出现在
正常程序中），但仍不失为一种有效的方法。
由于加密病毒还没有能够完全逃脱静态特征码扫描，所以病毒写作者在加密病毒的基础
之上进行改进，使解密子的代码对不同传染实例呈现出多样性，这就出现了加密变形病
毒。它和加密病毒非常类似，唯一的改进在于病毒主体在感染不同文件会构造出一个功
能相同但代码不同的解密子，也就是不同传染实例的解密子具有相同的解密功能但代码
却截然不同。比如原本一条指令完全可以拆成几条来完成，中间可能会被插入无用的垃
圾代码。这样，由于无法找到不变的特征码，静态扫描技术就彻底失效了。在这种情况
下，虚拟机技术将会派上用场。
实时监控技术其实并非什么新技术，早在DOS编程时代就有之。只不过那时人们没
有给这项技术冠以这样专业的名字而已。在WINDOWS下要实现实时监控决非易事，普通用
户态程序是不可能监控系统的活动的，这也是出于系统安全的考虑。病毒实时监控（Fo
r WIN9X&WINNT/2000）都使用了驱动编程技术，让工作于系统核心态的驱动程序去拦截
所有的文件访问。当然由于工作系统的不同，驱动程序无论从结构还是工作原理都不尽
相同的，当然程序写法和编译环境更是千差万别了，上面提到的病毒实时监控其实就是
对文件的监控，说成是文件监控应该更为合理一些。除了文件监控外，还有各种各样的
实时监控工具，它们也都具有各自不同的特点和功用。现在流行的什么网络监控，邮件
监控基本上是对文件监控的改进，革命性的改动没有。
病毒实时监控其实就是一个文件监视器，它会在文件打开，关闭，清除，写入等操作时
检查文件是否是病毒携带者，如果是则根据用户的决定选择不同的处理方案，如清除病
毒，禁止访问该文件，删除该文件或简单地忽略。这样就可以有效地避免病毒在本地机
器上的感染传播，因为可执行文件装入器在装入一个文件执行时首先会要求打开该文件
，而这个请求又一定会被实时监控在第一时间截获到，它确保了每次执行的都是干净的
不带毒的文件从而不给病毒以任何执行和发作的机会。以上说的仅是病毒实时监控一个
粗略的工作过程，病毒实时监控的设计主要存在以下几个难点：
其一是驱动程序的编写不同于普通用户态程序的写作，其难度很大。写用户态程
序时你需要的仅仅就是调用一些熟知的API函数来完成特定的目的，比如打开文件你只需
调用CreateFile就可以了；但在驱动程序中你将无法使用熟悉的CreateFile。在NT/200
0下你可以使用 ZwCreateFile 或NtCreateFile（native API），但这些函数通常会要求
运行在某个IRQL（中断请求级）上，如果你对如中断请求级，延迟/异步过程调用，非分
页/分页内存等概念不是特别清楚，那么你写的驱动将很容易导致蓝屏死机（BSOD），R
ing0下的异常将往往导致系统崩溃，因为它对于系统总是被信任的，所以没有相应处理
代码去捕获这个异常。在NT下对KeBugCheckEx的调用将导致蓝屏的出现，接着系统将进
行转储并随后重启。另外驱动程序的调试不如用户态程序那样方便，用象VC ++那样的调
试器是不行的，你必须使用系统级调试器，如softice,kd,trw等。
其二是驱动程序与ring3下客户程序的通信问题。这个问题的提出是很自然的，试
想当驱动程序截获到某个文件打开请求时，它必须通知位于ring3 下的查毒模块检查被
打开的文件，随后查毒模块还需将查毒的结果通过某种方式传给ring0下的监控程序，最
后驱动程序根据返回的结果决定请求是否被允许。这里面显然存在一个双向的通信过程
。写过驱动程序的人都知道一个可以用来向驱动程序发送设备I/O控制信息的API调用De
viceIoControl，它的接口在MSDN中可以找到，但它是单向的，即ring3下客户程序可以
通过调用DeviceIoControl将某些信息传给ring0下的监控程序但反过来不行。既然无法
找到一个现成的函数实现从ring0下的监控程序到ring3下客户程序的通信，则我们必须
采用迂回的办法来间接做到这一点。为此我们必须引入异步过程调用（APC）和事件对象
的概念，它们就是实现特权级间唤醒的关键所在。现在先简单介绍一下这两个概念，具
体的用法请参看后面的每子章中的技术实现细节。异步过程调用是一种系统用来当条件
合适时在某个特定线程的上下文中执行一个过程的机制。当向一个线程的APC队列排队一
个APC时，系统将发出一个软件中断，当下一次线程被调度时，APC函数将得以运行。AP
C分成两种：系统创建的APC称为内核模式APC，由应用程序创建的APC称为用户模式APC。
另外只有当线程处于可报警（alertable）状态时才能运行一个APC。比如调用一个异步
模式的ReadFileEx时可以指定一个用户自定义的回调函数FileIOCompletionRoutine，当
异步的I/O操作完成或被取消并且线程处于可报警状态时函数被调用，这就是 APC的典型
用法。Kernel32.dll中导出的QueueUserAPC函数可以向指定线程的队列中增加一个APC对
象，因为我们写的是驱动程序，这并不是我们要的那个函数。很幸运的是在Vwin32.vxd
中导出了一个同名函数QueueUserAPC，监控程序拦截到一个文件打开请求后，它马上调
用这个服务排队一个ring3下客户程序中需要被唤醒的函数的APC，这个函数将在不久客
户程序被调度时被调用。这种APC唤醒法适用于WIN9X，在 WINNT/2000下我们将使用全局
共享的事件和信号量对象来解决互相唤醒问题。有关WINNT/2000下的对象组织结构我将
在3.4.2节中详细说明。NT/2000版监控程序中我们将利用KeReleaseSemaphore来唤醒一
个在ring3下客户程序中等待的线程。目前不少反病毒软件已将驱动使用的查毒模块移到
ring0，即如其所宣传的“主动与操作系统无缝连接”，这样做省却了通信的消耗，但把
查毒模块写成驱动形式也同时会带来一些麻烦，如不能调用大量熟知的API，不能与用户
实时交互，所以我们还是选择剖析传统的反病毒软件的监控程序。
其三是驱动程序所占用资源问题。如果由于监控程序频繁地拦截文件操作而使系
统性能下降过多，则这样的程序是没有其存在的价值的。本论文将对一个成功的反病毒
软件的监控程序做彻底的剖析，其中就包含有分析其用以提高自身性能的技巧的部分，
如设置历史记录，内置文件类型过滤，设置等待超时等。
这段文字也是从关于病毒工作原理那篇文章里搞出来的，由于那是一片老文章，因
此其中的很多观点可能在现在已经不再适用，很多加密方式已经变得很强。本人并不非
常赞同文章关于实时监控技术的解释。MM告诉我，现在的基于NT内核的操作系统应用程
序文件-应用程序－操作系统之间的响应关系与原9x时代还是有一定区别的，特别是加入
了很多线程级的权限控制，杀毒软件现在可以采用实时内存监控的方法来影射应用程序
的活动。为什么欧美的软件厂商没有搞出那么多的监控方式像什么“网页监控，聊天软
件监控等”,原因很简单，因为病毒能够起作用，就必须在内存中运行，因此良好的文件
监控和内存监控足以解决病毒，国内搞出那么多名堂更多的是出于市场商业考虑。
毋庸置疑，现在的杀毒软件引擎都是虚拟机技术和实时监控技术的复合体。由于各
家研发人员所研究的方向不同，各产品的杀毒品质也非常迥异。比如诺顿的杀毒理念就
是在确保系统正常运行的前提下，控制最终消除可能影响系统稳定的因素；而另有些厂
商则认为杀毒软件应该最快的消除有害程序。业界一种获得公认的设计底线是杀毒软件
绝对不能因为杀毒导致系统崩溃，可惜的是现在很多厂商屡屡撞线。
以下为各家厂商的杀毒引擎简介，文中有一部分来源于业已公开的技术资料，有一部分
来源于在病毒论坛上被奉为经典的反编，还有一部分来源于厂商技术人员的介绍（官方
和私下的都有）。
1.诺顿：这个最熟悉了，诺顿的杀毒软件实际上防止侦测方面做得并不是很好，
很多病毒程序在子程序段中经常借鉴搞崩诺顿的代码，希望在新版本中诺顿可以采用更
强的自身防护技术。诺顿的引擎应该是完全自成封闭体系的，没有资料证实诺顿曾经购
买或者借鉴过别的杀毒引擎。传闻很多公司都在设计时参考过卡巴斯基的泄漏版引擎设
计，因此曾经在微软社区在线聊天时，问过这个问题。回贴一致认为诺顿借鉴卡巴斯基
的杀毒引擎毫无必要，它自己的引擎搞得挺好的。有一个叫 fenssa的家伙甚至回贴说不
考虑病毒库因素，诺顿的杀毒引擎相当先进，综合防护性能很好。在微软，除了用mcaf
ee的就使用诺顿的（这一点我比较相信，很少见到别的杀软在微软被使用）。从诺顿的
技术文档描述和在病毒论坛上流传的29A的一个家伙搞的一篇叫虚拟机环境下诺顿工作过
程的步进追踪和反编的文章来看，诺顿的杀毒引擎应该是传统的静态代码对应与实时监
控的完美结合，应该有一些改进的虚拟机技术在里面（诺顿的人并不怎么推崇虚拟机技
术）。诺顿的杀毒速度慢，应该源于诺顿采用了较多的静态代码这种传统的检查方式有
关。我个人非常喜欢诺顿的隔离机制，我认为在没有确定完全正确的处理方式之前，删
除是不应该被采用的。一个高手写的病毒应该能尽可能的与系统进程相关，在这种情况
下，隔离的优势立刻显现。诺顿资源占用量比较大，但实现了如下设计目标：能识别的
病毒和被识别为病毒的进程完全可以正确处理，对已经不可能产生破坏作用的’病毒尸
体‘不会产生误判，更不会出现出现一次又一次的在处理完某病毒后又检测其为病毒的
状况。
很多人认为诺顿企业版和个人板采用的引擎完全一致这种理解不很正确。实际上企
业版在个人板的技术上还是有改进的。zdnet上刊登过一篇文章指出：企业版和个人版引
擎的核心规则完全一样，但在前端文件汇入部分企业版是优于个人版的，企业版使用了
更多的API接口。文章中说，在大规模文件扫描时，企业版明显优于个人版。并且由于使
用了负载技术，企业版资源占用还好一点。另外据说企业版支持基于网络的多重负载技
术。
Mcafee:记得看过一篇报道说mcafee收购过别的杀毒软件引擎设计公司，据回贴可知为所
罗门。在网上很少能看到关于对mcafee的杀毒引擎进行过分析的技术文档，但从他自己
宣传的资料看，mcafee对虚拟机技术和实时监控研究的都挺彻底的。比如他最近宣传防
止应用程序溢出（大致这个名字）的技术，应该是在不考虑硬件平台的情况下虚拟机技
术和实时监控技术结合的上乘之作，尽管经常出现错误的溢出侦测（软件层面的放溢出
技术确实不很稳定）。在处理大量的文件时，mcafee有一定的速度优势（微软社区中有
这个问题的论述）。有来自于mcafee论坛的消息说，mcafee 正在研究更先进的智能码扫
描技术，估计肯
--
*┌*┬*┬╮┌*┬*┬╮╭*╮ ╮*╭*┬*┬*╮╭╮ *╭*╮ *╭*┬─*╮╭*┬─*
*│*┤*│*│*│*┤*│*│*│┤ │ │*┤ │*┤ *│*┤ │┤ *│*┤ │
*│*┤*│*││*┤*│*│*├*┴*┬*╯ │*┤ *│*┤ │*┤ *│*┼*─*╯├*?
*╰╯*╯*╯*╰*╯*╯*╯*╰*╯*╰*╯╰*┴*┴*╯*╰*┴*─*╯*╰*┴*─*╯╰┴*─╯
※ 来源:·荔园晨风BBS站 bbs.szu.edu.cn·[FROM: 192.168.110.120]
[回到开始]
[上一篇][下一篇]
荔园在线首页 友情链接：深圳大学 深大招生 荔园晨风BBS S-Term软件 网络书店