各种杀毒引擎技术分析

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导出的服务VMMCALL _PageAllocate在大于0xC0000000的地址上分配一块页面空间。而处于用户态的程序要想在程序退出后仍驻留代码的部分于内存中似乎是不可能的，因为无论用户程序分配何种内存都将作为进程占用资源的一部分，一旦进程结束，所占资源将立即被释放。所以我们要做的是分配一块进程退出后仍可保持的内存。
病毒写作小组29A的成员GriYo 运用的一个技术很有创意：他通过CreateFileMappingA 和MapViewOfFile创建了一个区域对象并映射它的一个视口到自己的地址空间中去，并把病毒体搬到那里，由于文件映射所在的虚拟地址处于共享区域（能够被所有进程看到，即所有进程用于映射共享区内虚拟地址的页表项全都指向相同的物理页面），所以下一步他通过向Explorer.exe中注入一段代码（利用WriteProcessMemory来向其它进程的地址空间写入数据），而这段代码会从Explorer.exe的地址空间中再次申请打开这个文件映射。如此一来，即便病毒退出，但由于Explorer.exe还对映射页面保持引用，所以一份病毒体代码就一直保持在可以影响所有进程的内存页面中直至Explorer.exe退出（我直接试过该种方法，在xp下注意要写一个空循环语句，以免被踢出处理队列）。
另外还可以通过修改系统动态连接模块（DLL）来进行驻留。WIN9X下系统DLL（如Kernel32.dll 映射至BFF70000）处于系统共享区域（2G-3G），如果在其代码段空隙中写入一小段病毒代码则可以影响其它所有进程。但Kernel32.dll 的代码段在用户态是只能读不能写的。所以必须先通过特殊手段修改其页保护属性；而在WINNT/2000/xp系统DLL所在页面被映射到进程的私有空间（如 Kernel32.dll 映射至77ED0000）中，并具有写时拷贝属性，即没有进程试图写入该页面时，所有进程共享这个页面；而当一个进程试图写入该页面时，系统的页面错误处理代码将收到处理器的异常，并检查到该异常并非访问违例，同时分配给引发异常的进程一个新页面，并拷贝原页面内容于其上且更新进程的页表以指向新分配的页。这种共享内存的优化给病毒的写作带来了一定的麻烦，病毒不能象在WIN9X下那样仅修改Kernel32.dll一处代码便可一劳永逸。它需要利用 WriteProcessMemory来向每个进程映射Kernel32.dll的地址写入病毒代码，这样每个进程都会得到病毒体的一个副本，这在病毒界被称为多进程驻留或每进程驻留（Muti-Process Residence or Per-Process Residence ）。
文中列举方法在xp－sp1下略作修改即可使用 ，大部分为在代码段内加入空循环 。在sp2下，很多时候报如下类型的错误不可访问的内存地址段.........。
在原来的帖子中我援引了另一篇文档中的例子，但经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一样取指，译码，执行，它可以模拟一段代码在真正CPU上运行得到的结果。给定一组机器码序列，虚拟机会自动从中取出第一条指令操作码部分，判断操作码类型和寻址方式以确定该指令长度，然后在相应的函数中执行该指令，并根据执行后的结果确定下条指令的位置，如此循环反复直到某个特定情况发生以结束工作，这就是虚拟机的基本工作原理和简单流程。设计虚拟机查毒的目的是为了对付加密变形病毒，虚拟机首先从文件中确定并读取病毒入口处代码，然后以上述工作步骤解释执行病毒头部的解密段（decryptor），最后在执行完的结果（解密后的病毒体明文）中查找病毒的特征码。这里所谓的"虚拟"，并非是创建了什么虚拟环境，而是指染毒文件并没有实际执行，只不过是虚拟机模拟了其真实执行时的效果。这就是虚拟机查毒基本原理。曾经跟搞杀毒的技术人员探讨是否可以采用模拟实际执行的方法来搞一套杀毒软件，回答是微软可以，因为微软可以在系统底层搞一套硬件虚拟层，来实现硬件虚拟。我忽然想到，如果微软真的搞杀毒软件，其实无论别的杀毒软件公司多么强，大家都得彻底玩完。
早期病毒没有使用任何复杂的反检测技术，如果拿反汇编工具打开病毒体代码看到的将是真正的机器码。因而可以由病毒体内某处一段机器代码和此处距离病毒入口（注意不是文件头）偏移值来唯一确定一种病毒。查毒时只需简单的确定病毒入口并在指定偏移处扫描特定代码串。这种静态扫描技术对付普通病毒是万无一失的。
随着病毒技术的发展，出现了一类加密病毒。这类病毒的特点是：其入口处具有解密（decryptor），而病毒主体代码被加了密。运行时首先得到控制权的解密代码将对病毒主体进行循环解密，完成后将控制交给病毒主体运行，病毒主体感染文件时会将解密子，用随机密钥加密过的病毒主体，和保存在病毒体内或嵌入解密子中的密钥一同写入被感染文件。由于同一种病毒的不同传染实例的病毒主体是用不同的密钥进行加密，因而不可能在其中找到唯一的一段代码串和偏移来代表此病毒的特征，似乎静态扫描技术对此即将失效。但仔细想想，不同传染实例的解密子仍保持不变机器码明文（从理论上讲任何加密程序中都存在未加密的机器码，否则程序无法执行），所以将特征码选于此处虽然会冒一定的误报风险（解密子中代码缺少病毒特性，同样的特征码也会出现在正常程序中），但仍不失为一种有效的方法。
由于加密病毒还没有能够完全逃脱静态特征码扫描，所以病毒写作者在加密病毒的基础之上进行改进，使解密子的代码对不同传染实例呈现出多样性，这就出现了加密变形病毒。它和加密病毒非常类似，唯一的改进在于病毒主体在感染不同文件会构造出一个功能相同但代码不同的解密子，也就是不同传染实例的解密子具有相同的解密功能但代码却截然不同。比如原本一条指令完全可以拆成几条来完成，中间可能会被插入无用的LJ代码。这样，由于无法找到不变的特征码，静态扫描技术就彻底失效了。在这种情况下，虚拟机技术将会派上用场。
实时监控技术其实并非什么新技术，早在DOS编程时代就有之。只不过那时人们没有给这项技术冠以这样专业的名字而已。在WINDOWS下要实现实时监控决非易事，普通用户态程序是不可能监控系统的活动的，这也是出于系统安全的考虑。病毒实时监控（For WIN9X&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调用DeviceIoControl，它的接口在MSDN中可以找到，但它是单向的，即ring3下客户程序可以通过调用DeviceIoControl将某些信息传给ring0下的监控程序但反过来不行。既然无法找到一个现成的函数实现从ring0下的监控程序到ring3下客户程序的通信，则我们必须采用迂回的办法来间接做到这一点。为此我们必须引入异步过程调用（APC）和事件对象的概念，它们就是实现特权级间唤醒的关键所在。现在先简单介绍一下这两个概念，具体的用法请参看后面的每子章中的技术实现细节。异步过程调用是一种系统用来当条件合适时在某个特定线程的上下文中执行一个过程的机制。当向一个线程的APC队列排队一个APC时，系统将发出一个软件中断，当下一次线程被调度时，APC函数将得以运行。APC分成两种：系统创建的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的家伙甚至回贴说不考虑病毒库因素，诺顿的杀毒引擎相当先进，综合防护性能很好。在微软，除了用mcafee的就使用诺顿的（这一点我比较相信，很少见到别的杀软在微软被使用）。从诺顿的技术文档描述和在病毒论坛上流传的29A的一个家伙搞的一篇叫虚拟机环境下诺顿工作过程的步进追踪和反编的文章来看，诺顿的杀毒引擎应该是传统的静态代码对应与实时监控的完美结合，应该有一些改进的虚拟机技术在里面（诺顿的人并不怎么推崇虚拟机技术）。诺顿的杀毒速度慢，应该源于诺顿采用了较多的静态代码这种传统的检查方式有关。我个人非常喜欢诺顿的隔离机制，我认为在没有确定完全正确的处理方式之前，删除是不应该被采用的。一个高手写的病毒应该能尽可能的与系统进程相关，在这种情况下，隔离的优势立刻显现。诺顿资源占用量比较大，但实现了如下设计目标：能识别的病毒和被识别为病毒的进程完全可以正确处理，对已经不可能产生破坏作用的'病毒尸体‘不会产生误判，更不会出现出现一次又一次的在处理完某病毒后又检测其为病毒的状况。

其一是驱动程序的编写不同于普通用户态程序的写作，其难度很大。写用户态程序时你需要的仅仅就是调用一些熟知的API函数来完成特定的目的，比如打开文件你只需调用CreateFile就可以了；但在驱动程序中你将无法使用熟悉的CreateFile。在NT/2000下你可以使用 ZwCreateFile 或NtCreateFile（native API），但这些函数通常会要求运行在某个IRQL（中断请求级）上，如果你对如中断请求级，延迟/异步过程调用，非分页/分页内存等概念不是特别清楚，那么你写的驱动将很容易导致蓝屏死机（BSOD），Ring0下的异常将往往导致系统崩溃，因为它对于系统总是被信任的，所以没有相应处理代码去捕获这个异常。在NT下对KeBugCheckEx的调用将导致蓝屏的出现，接着系统将进行转储并随后重启。另外驱动程序的调试不如用户态程序那样方便，用象VC ++那样的调试器是不行的，你必须使用系统级调试器，如softice,kd,trw等。
其二是驱动程序与ring3下客户程序的通信问题。这个问题的提出是很自然的，试想当驱动程序截获到某个文件打开请求时，它必须通知位于ring3下的查毒模块检查被打开的文件，随后查毒模块还需将查毒的结果通过某种方式传给ring0下的监控程序，最后驱动程序根据返回的结果决定请求是否被允许。这里面显然存在一个双向的通信过程。写过驱动程序的人都知道一个可以用来向驱动程序发送设备I/O控制信息的API调用DeviceIoControl，它的接口在MSDN中可以找到，但它是单向的，即ring3下客户程序可以通过调用DeviceIoControl将某些信息传给ring0下的监控程序但反过来不行。既然无法找到一个现成的函数实现从ring0下的监控程序到ring3下客户程序的通信，则我们必须采用迂回的办法来间接做到这一点。为此我们必须引入异步过程调用（APC）和事件对象的概念，它们就是实现特权级间唤醒的关键所在。现在先简单介绍一下这两个概念，具体的用法请参看后面的每子章中的技术实现细节。异步过程调用是一种系统用来当条件合适时在某个特定线程的上下文中执行一个过程的机制。当向一个线程的APC队列排队一个APC时，系统将发出一个软件中断，当下一次线程被调度时，APC函数将得以运行。APC分成两种：系统创建的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的家伙甚至回贴说不考虑病毒库因素，诺顿的杀毒引擎相当先进，综合防护性能很好。在微软，除了用mcafee的就使用诺顿的（这一点我比较相信，很少见到别的杀软在微软被使用）。从诺顿的技术文档描述和在病毒论坛上流传的29A的一个家伙搞的一篇叫虚拟机环境下诺顿工作过程的步进追踪和反编的文章来看，诺顿的杀毒引擎应该是传统的静态代码对应与实时监控的完美结合，应该有一些改进的虚拟机技术在里面（诺顿的人并不怎么推崇虚拟机技术）。诺顿的杀毒速度慢，应该源于诺顿采用了较多的静态代码这种传统的检查方式有关。我个人非常喜欢诺顿的隔离机制，我认为在没有确定完全正确的处理方式之前，删除是不应该被采用的。一个高手写的病毒应该能尽可能的与系统进程相关，在这种情况下，隔离的优势立刻显现。诺顿资源占用量比较大，但实现了如下设计目标：能识别的病毒和被识别为病毒的进程完全可以正确处理，对已经不可能产生破坏作用的'病毒尸体‘不会产生误判，更不会出现出现一次又一次的在处理完某病毒后又检测其为病毒的状况。很多人认为诺顿企业版和个人板采用的引擎完全一致这种理解不很正确。实际上企业版在个人板的技术上还是有改进的。zdnet上刊登过一篇文章指出：企业版和个人版引擎的核心规则完全一样，但在前端文件汇入部分企业版是优于个人版的，企业版使用了更多的API接口。文章中说，在大规模文件扫描时，企业版明显优于个人版。并且由于使用了负载技术，企业版资源占用还好一点。另外据说企业版支持基于网络的多重负载技术。
2.Mcafee:记得看过一篇报道说mcafee收购过别的杀毒软件引擎设计公司，据回贴可知为所罗门。在网上很少能看到关于对mcafee的杀毒引擎进行过分析的技术文档，但从他自己宣传的资料看，mcafee对虚拟机技术和实时监控研究的都挺彻底的。比如他最近宣传防止应用程序溢出（大致这个名字）的技术，应该是在不考虑硬件平台的情况下虚拟机技术和实时监控技术结合的上乘之作，尽管经常出现错误的溢出侦测（软件层面的放溢出技术确实不很稳定）。在处理大量的文件时，mcafee有一定的速度优势（微软社区中有这个问题的论述）。有来自于mcafee论坛的消息说，mcafee 正在研究更先进的智能码扫描技术，估计肯定比东方卫士搞得要好。根据组长的回贴，McAfee自发布VSE8.0i以来就着重于"前慑防范"这一新型的安全领域，并且NORTON也在超这一方向迈进。"前慑防范"一共分为两个部分，其一为运用部分防火墙技术外加其入侵检测技术有效的阻断病毒的传播源，以至于病毒在传染的初期无法得到大面积的传播降低了危害性；其二为依靠其强大的特征码检测技术（Extra.dat）对病毒的行为方式、特征代码等进行检测，依靠它强大的研发团队以及策略联盟伙伴使其在这一领域独树一帜。诺顿能在其新版产品中也加入了一些原本属于防火墙的功能。发邮件询问诺顿的研究人员为什么没有采用特征码杀毒技术，回应说一个完美的特征码扫描技术应该能够达到根据用户的指定加入特定文件为病毒的目的，也就是当用户指定某个活动程序为病毒时，杀毒软件的引擎能够根据自身的规则为该活动程序定义一个特征码，并且在控制该活动程序时，能够有效地断绝其与系统正常进程的关联。在没有这个水平之前，诺顿不会大规模采用特征码技术。从mcafee的技术文档来看，mcafee也只是有限度的试验性的研究该技术，并在比较有把握的地方应用。实际上两家公司在这方面还有很长的路要走。
3.卡巴斯基：本论坛上被过度神话的杀毒软件。我个人非常尊重卡巴斯基的高水准，但说句实话，在不考虑资源占用的情况下，卡巴斯基并没有什么足够的理由能够让我放弃诺顿，二者的水平并没有什么差异。在稳定性上，卡巴斯基比诺顿要差一些。由于早些年卡巴斯基的引擎曾经泄漏（实际上泄漏的并不是初始源代码，只是泄漏的引擎可以比较容易的反编），因此网上可以找到很多关于卡巴斯基引擎的非常详细的技术分析，尤其是德国的病毒高手写的关于如何优化卡巴斯基杀毒引擎的文章，被认为是所有采用卡巴斯基引擎的杀毒软件厂商必看的文章之一，就象美国人写的那篇VB100到底怎么测试杀毒软件（里面作者综合近几年的测试结果推测了VB100在测试时可能使用的病毒类型，相关比例等）是杀毒软件厂商在将自己的软件送测前必看的文章一样。从网上大量的分析文档看卡巴斯基的虚拟机技术是很优秀的，但是去年有人发贴认为卡巴斯基的良好的性能来源于它非常庞大的病毒库和良好的升级速度，其杀毒引擎设计水平并不高于其余的公司。卡巴斯基的引擎采用了所谓的单一形式的规则判断，众所周知诺顿是基于分类的规则处理。卡巴斯基的引擎在文件标识比对病毒库的时候被认为有着很好的性能，充分利用了处理器的处理能力，"但令人担忧的是，该公司对最新出现的技术并不充分重视"（英国的计算机杂志去年年末的评论），究竟是对原有引擎进行彻底改进还是大量使用新技术，估计谁都不知道。卡巴斯基的引擎存在叫做所谓的"过与简短的文件码"问题，说白了就是有时候会鞭尸，它的研究人员说正在改进。前段时间有人发帖子中指出病毒编写者只认可卡巴斯基，说实话看了很多论坛文档，好像没有哪个强人这么说过。卡巴斯基走的是与美国厂商有很大区别的研发道路，卡巴斯基很少引用别的公司开发的技术，而是在不断的深化，改进自身的杀毒引擎，单从某些方面评论，卡巴斯基的引擎代表着业界最高水准，但并不是全部。卡巴斯基是一款很好的杀毒软件，但并不是神。应该说它与诺顿，mcafee一样都站在杀毒软件的顶峰水平上。
在国内，一直有江民的杀毒软件采用卡巴斯基引擎的传闻，说句实话业界相当一部分杀毒软件都参考了其引擎设计，即使在国内也没有足够的信息证实只是江民参考了其引擎设计。很多人都使用各种各样的病毒包对卡巴斯基和江民进行测试，测试结果是完全一样。说句实话，这种测试并没有什么可信性，对化石孢的检测各种杀毒软件结果几乎都一样。只有两种方法能够说两者的引擎如何：1.将两款软件送至VB100或者类似的权威机构进行测试，如果两者对其中未知病毒的测试结果（这个结果并不公布，厂商自己去买）完全一样，那什么都没说的。两个不同的引擎机制在对待同样大规模的未知病毒库时出现相同的检测结果近乎是不可能的。可惜的是，江民没有参加过VB100测试，好像也不大可能个人有足够庞大的未知病毒库来进行检测。2.采用类似于破解的方法进行反编，分析整个软件的工作机制，工作量有多大相信都能猜出来，也没有见过有人搞过这种研究。因此我个人只能认为江民可能（较大程度的）参考了卡巴斯基的杀毒引擎设计，但从两款杀毒软件的灵敏程度，杀毒速度等诸多方民看，即使江民采用了卡巴斯基的引擎，江民也应该进行了很大程度的源代码修改或者优化，另外也有消息说江民在引擎中加入了一些自己开发的技术，在实现方法上类似于数字码技术。霏凡上曾有高手指出假如公布两款软件的源代码，可能并不会有人能看出二者有什么关系。实际上，当发现江民的软件并不能使用卡巴斯基的病毒库的时候，我们就应该知道即便曾经借鉴过，二者也已经可以被认为是不同的杀毒引擎。可能在win3.x平台下，二者曾经很相近；但是今天我们在使用winxp.即使江民确实采用过卡巴斯基的引擎，那么可以说江民在某些方面发展了这套引擎，尽管这种发展未必与原始的研发方向相符。但无论基于何种角度考虑，我认为江民的杀毒软件还是有优秀之处的。毕竟你回头看一看国内的杀毒软件厂商，在真正的技术研发领域只有这么一面旗帜偶尔飘扬。一步步走下来，江民还是有技术进步的。只就纯技术因素而论，假如江民采用了卡巴斯基的引擎，那么今天两家厂商在不同的方向上发展着那套原始的引擎，这未必是坏事，只要不固步自封，我们好像没什么必要争论两家厂商是否一个原始祖先，怕的就是在别人都往前跑的时候自己停下来，这跟自取灭亡没什么区别。尽管市场是杀毒软件厂商的第一要素，但别忘了技术是一个杀毒软件能否基业常青的决定性力量。