Virus 版 (精华区)

发信人: Kernel (--->哈尔滨), 信区: Virus
标  题: 杀毒软件的引擎.2(zz)
发信站: BBS 哈工大紫丁香站 (Tue Jul 27 10:08:49 2004)

杀毒引擎目前主流有两种实现方式：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）时，窗口里出现了机器自检画面，接着是操作系统的载入，一切都和真的一样。而WI
N9X为了让多个程序共享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一样取指，译码，执行，它可以模拟一段代码在真正CPU上运行得到的结
果。给定一组机器码序列，虚拟机会自动从中取出第一条指令操作码部分，判断操作码类
型和寻址方式以确定该指令长度，然后在相应的函数中执行该指令，并根据执行后的结果
确定下条指令的位置，如此循环反复直到某个特定情况发生以结束工作，这就是虚拟机的
基本工作原理和简单流程。设计虚拟机查毒的目的是为了对付加密变形病毒，虚拟机首先
从文件中确定并读取病毒入口处代码，然后以上述工作步骤解释执行病毒头部的解密段（
decryptor），最后在执行完的结果（解密后的病毒体明文）中查找病毒的特征码。这里所
谓的“虚拟”，并非是创建了什么虚拟环境，而是指染毒文件并没有实际执行，只不过是虚拟机
模拟了其真实执行时的效果。这就是虚拟机查毒基本原理。曾经跟搞杀毒的技术人员探讨
是否可以采用模拟实际执行的方法来搞一套杀毒软件，回答是微软可以，因为微软可以在
系统底层搞一套硬件虚拟层，来实现硬件虚拟。我忽然想到，如果微软真的搞杀毒软件，
其实无论别的杀毒软件公司多么强，大家都得彻底玩完。
     早期病毒没有使用任何复杂的反检测技术，如果拿反汇编工具打开病毒体代码看到的
将是真正的机器码。因而可以由病毒体内某处一段机器代码和此处距离病毒入口（注意不
是文件头）偏移值来唯一确定一种病毒。查毒时只需简单的确定病毒入口并在指定偏移处
扫描特定代码串。这种静态扫描技术对付普通病毒是万无一失的。
     随着病毒技术的发展，出现了一类加密病毒。这类病毒的特点是：其入口处具有解密
子（decryptor），而病毒主体代码被加了密。运行时首先得到控制权的解密代码将对病毒
主体进行循环解密，完成后将控制交给病毒主体运行，病毒主体感染文件时会将解密子，
用随机密钥加密过的病毒主体，和保存在病毒体内或嵌入解密子中的密钥一同写入被感染
文件。由于同一种病毒的不同传染实例的病毒主体是用不同的密钥进行加密，因而不可能
在其中找到唯一的一段代码串和偏移来代表此病毒的特征，似乎静态扫描技术对此即将失
效。但仔细想想，不同传染实例的解密子仍保持不变机器码明文（从理论上讲任何加密程
序中都存在未加密的机器码，否则程序无法执行），所以将特征码选于此处虽然会冒一定
的误报风险（解密子中代码缺少病毒特性，同样的特征码也会出现在正常程序中），但仍
不失为一种有效的方法。
     由于加密病毒还没有能够完全逃脱静态特征码扫描，所以病毒写作者在加密病毒的基
础之上进行改进，使解密子的代码对不同传染实例呈现出多样性，这就出现了加密变形病
毒。它和加密病毒非常类似，唯一的改进在于病毒主体在感染不同文件会构造出一个功能
相同但代码不同的解密子，也就是不同传染实例的解密子具有相同的解密功能但代码却截
然不同。比如原本一条指令完全可以拆成几条来完成，中间可能会被插入无用的垃圾代码
。这样，由于无法找到不变的特征码，静态扫描技术就彻底失效了。在这种情况下，虚拟
机技术将会派上用场。
      实时监控技术其实并非什么新技术，早在DOS编程时代就有之。只不过那时人们没有
给这项技术冠以这样专业的名字而已。在WINDOWS下要实现实时监控决非易事，普通用户态
程序是不可能监控系统的活动的，这也是出于系统安全的考虑。病毒实时监控（For WIN9
X&WINNT/2000）都使用了驱动编程技术，让工作于系统核心态的驱动程序去拦截所有的文
件访问。当然由于工作系统的不同，驱动程序无论从结构还是工作原理都不尽相同的，当
然程序写法和编译环境更是千差万别了，上面提到的病毒实时监控其实就是对文件的监控
，说成是文件监控应该更为合理一些。除了文件监控外，还有各种各样的实时监控工具，
它们也都具有各自不同的特点和功用。现在流行的什么网络监控，邮件监控基本上是对文
件监控的改进，革命性的改动没有。

病毒实时监控其实就是一个文件监视器，它会在文件打开，关闭，清除，写入等操作时检
查文件是否是病毒携带者，如果是则根据用户的决定选择不同的处理方案，如清除病毒，
禁止访问该文件，删除该文件或简单地忽略。这样就可以有效地避免病毒在本地机器上的
感染传播，因为可执行文件装入器在装入一个文件执行时首先会要求打开该文件，而这个
请求又一定会被实时监控在第一时间截获到，它确保了每次执行的都是干净的不带毒的文
件从而不给病毒以任何执行和发作的机会。以上说的仅是病毒实时监控一个粗略的工作过
程，病毒实时监控的设计主要存在以下几个难点：
       其一是驱动程序的编写不同于普通用户态程序的写作，其难度很大。写用户态程序
时你需要的仅仅就是调用一些熟知的API函数来完成特定的目的，比如打开文件你只需调用
CreateFile就可以了；但在驱动程序中你将无法使用熟悉的CreateFile。在NT/2000下你可
以使用 ZwCreateFile 或NtCreateFile（native API），但这些函数通常会要求运行在某
个IRQL（中断请求级）上，如果你对如中断请求级，延迟/异步过程调用，非分页/分页内
存等概念不是特别清楚，那么你写的驱动将很容易导致蓝屏死机（BSOD），Ring0下的异常
将往往导致系统崩溃，因为它对于系统总是被信任的，所以没有相应处理代码去捕获这个
异常。在NT下对KeBugCheckEx的调用将导致蓝屏的出现，接着系统将进行转储并随后重启
。另外驱动程序的调试不如用户态程序那样方便，用象VC ++那样的调试器是不行的，你必
须使用系统级调试器，如softice,kd,trw等。
      其二是驱动程序与ring3下客户程序的通信问题。这个问题的提出是很自然的，试想
当驱动程序截获到某个文件打开请求时，它必须通知位于ring3下的查毒模块检查被打开的
文件，随后查毒模块还需将查毒的结果通过某种方式传给ring0下的监控程序，最后驱动程
序根据返回的结果决定请求是否被允许。这里面显然存在一个双向的通信过程。写过驱动
程序的人都知道一个可以用来向驱动程序发送设备I/O控制信息的API调用DeviceIoContro
l，它的接口在MSDN中可以找到，但它是单向的，即ring3下客户程序可以通过调用Device
IoControl将某些信息传给ring0下的监控程序但反过来不行。既然无法找到一个现成的函
数实现从ring0下的监控程序到ring3下客户程序的通信，则我们必须采用迂回的办法来间
接做到这一点。为此我们必须引入异步过程调用（APC）和事件对象的概念，它们就是实现
特权级间唤醒的关键所在。现在先简单介绍一下这两个概念，具体的用法请参看后面的每
子章中的技术实现细节。异步过程调用是一种系统用来当条件合适时在某个特定线程的上
下文中执行一个过程的机制。当向一个线程的APC队列排队一个APC时，系统将发出一个软
件中断，当下一次线程被调度时，APC函数将得以运行。APC分成两种：系统创建的APC称为
内核模式APC，由应用程序创建的APC称为用户模式APC。另外只有当线程处于可报警（alertab
le）状态时才能运行一个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版监控程序中我们将利用KeR
eleaseSemaphore来唤醒一个在ring3下客户程序中等待的线程。目前不少反病毒软件已将
驱动使用的查毒模块移到ring0，即如其所宣传的“主动与操作系统无缝连接”，这样做省
却了通信的消耗，但把查毒模块写成驱动形式也同时会带来一些麻烦，如不能调用大量熟
知的API，不能与用户实时交互，所以我们还是选择剖析传统的反病毒软件的监控程序。
      其三是驱动程序所占用资源问题。如果由于监控程序频繁地拦截文件操作而使系统
性能下降过多，则这样的程序是没有其存在的价值的。本论文将对一个成功的反病毒软件
的监控程序做彻底的剖析，其中就包含有分析其用以提高自身性能的技巧的部分，如设置
历史记录，内置文件类型过滤，设置等待超时等。
     这段文字也是从关于病毒工作原理那篇文章里搞出来的，由于那是一片老文章，因此
其中的很多观点可能在现在已经不再适用，很多加密方式已经变得很强。本人并不非常赞
同文章关于实时监控技术的解释。MM告诉我，现在的基于NT内核的操作系统应用程序文件
-应用程序－操作系统之间的响应关系与原9x时代还是有一定区别的，特别是加入了很多线
程级的权限控制，杀毒软件现在可以采用实时内存监控的方法来影射应用程序的活动。为
什么欧美的软件厂商没有搞出那么多的监控方式像什么“网页监控，聊天软件监控等”,原
因很简单，因为病毒能够起作用，就必须在内存中运行，因此良好的文件监控和内存监控
足以解决病毒，国内搞出那么多名堂更多的是出于市场商业考虑。
     毋庸置疑，现在的杀毒软件引擎都是虚拟机技术和实时监控技术的复合体。由于各家
研发人员所研究的方向不同，各产品的杀毒品质也非常迥异。比如诺顿的杀毒理念就是在
确保系统正常运行的前提下，控制最终消除可能影响系统稳定的因素；而另有些厂商则认
为杀毒软件应该最快的消除有害程序。业界一种获得公认的设计底线是杀毒软件绝对不能
因为杀毒导致系统崩溃，可惜的是现在很多厂商屡屡撞线。


※ 修改:·Kernel 於 Jul 27 10:33:38 2004 修改本文·[FROM: 218.108.197.181]
※ 来源:·哈工大紫丁香 http://bbs.hit.edu.cn·[FROM: 218.108.197.181]