Virus 版 (精华区)
发信人: Kernel (--->哈尔滨), 信区: Virus
标 题: 杀毒软件的引擎.3(zz)
发信站: BBS 哈工大紫丁香站 (Tue Jul 27 10:34:35 2004)
以下为各家厂商的杀毒引擎简介,文中有一部分来源于业已公开的技术资料,有一部分来
源于在病毒论坛上被奉为经典的反编,还有一部分来源于厂商技术人员的介绍(官方和私
下的都有)。
1.诺顿:这个最熟悉了,诺顿的杀毒软件实际上防止侦测方面做得并不是很好,很
多病毒程序在子程序段中经常借鉴搞崩诺顿的代码,希望在新版本中诺顿可以采用更强的
自身防护技术。诺顿的引擎应该是完全自成封闭体系的,没有资料证实诺顿曾经购买或者
借鉴过别的杀毒引擎。传闻很多公司都在设计时参考过卡巴斯基的泄漏版引擎设计,因此
曾经在微软社区在线聊天时,问过这个问题。回贴一致认为诺顿借鉴卡巴斯基的杀毒引擎
毫无必要,它自己的引擎搞得挺好的。有一个叫fenssa的家伙甚至回贴说不考虑病毒库因
素,诺顿的杀毒引擎相当先进,综合防护性能很好。在微软,除了用mcafee的就使用诺顿
的(这一点我比较相信,很少见到别的杀软在微软被使用)。从诺顿的技术文档描述和在
病毒论坛上流传的29A的一个家伙搞的一篇叫虚拟机环境下诺顿工作过程的步进追踪和反编
的文章来看,诺顿的杀毒引擎应该是传统的静态代码对应与实时监控的完美结合,应该有
一些改进的虚拟机技术在里面(诺顿的人并不怎么推崇虚拟机技术)。诺顿的杀毒速度慢
,应该源于诺顿采用了较多的静态代码这种传统的检查方式有关。我个人非常喜欢诺顿的
隔离机制,我认为在没有确定完全正确的处理方式之前,删除是不应该被采用的。一个高
手写的病毒应该能尽可能的与系统进程相关,在这种情况下,隔离的优势立刻显现。诺顿
资源占用量比较大,但实现了如下设计目标:能识别的病毒和被识别为病毒的进程完全可
以正确处理,对已经不可能产生破坏作用的’病毒尸体‘不会产生误判,更不会出现出现
一次又一次的在处理完某病毒后又检测其为病毒的状况。
很多人认为诺顿企业版和个人板采用的引擎完全一致这种理解不很正确。实际上企业
版在个人板的技术上还是有改进的。zdnet上刊登过一篇文章指出:企业版和个人版引擎的
核心规则完全一样,但在前端文件汇入部分企业版是优于个人版的,企业版使用了更多的
API接口。文章中说,在大规模文件扫描时,企业版明显优于个人版。并且由于使用了负载
技术,企业版资源占用还好一点。另外据说企业版支持基于网络的多重负载技术。
的确,一位朋友反汇编过norton,就知道它在ring0。另外,其实网页的监控还是比较
必要的,网页的脚本在内存中运行,文件监控无法做到拦截。当然如果有很好的内存监控
可以解决这个问题。但是真正的内存监控比较难实现。
Mcafee:记得看过一篇报道说mcafee收购过别的杀毒软件引擎设计公司,据回贴可知为所
罗门。在网上很少能看到关于对mcafee的杀毒引擎进行过分析的技术文档,但从他自己宣
传的资料看,mcafee对虚拟机技术和实时监控研究的都挺彻底的。比如他最近宣传防止应
用程序溢出(大致这个名字)的技术,应该是在不考虑硬件平台的情况下虚拟机技术和实
时监控技术结合的上乘之作,尽管经常出现错误的溢出侦测(软件层面的放溢出技术确实
不很稳定)。在处理大量的文件时,mcafee有一定的速度优势(微软社区中有这个问题的
论述)。有来自于mcafee论坛的消息说,mcafee 正在研究更先进的智能码扫描技术,估计
肯定比东方卫士搞得要好。根据组长的回贴,McAfee自发布VSE8.0i以来就着重于“前慑防
范”这一新型的安全领域,并且NORTON也在超这一方向迈进。“前慑防范”一共分为两个
部分,其一为运用部分防火墙技术外加其入侵检测技术有效的阻断病毒的传播源,以至于
病毒在传染的初期无法得到大面积的传播降低了危害性;其二为依靠其强大的特征码检测
技术(Extra.dat)对病毒的行为方式、特征代码等进行检测,依靠它强大的研发团队以及
策略联盟伙伴使其在这一领域独树一帜。诺顿能在其新版产品中也加入了一些原本属于防
火墙的功能。发邮件询问诺顿的研究人员为什么没有采用特征码杀毒技术,回应说一个完美的特征码扫描技术应该能够达到根据用户的指定加入特定文件为病毒的目的,也就是当用户指定某个活动程序为病毒时,杀毒软件的引擎能够根据自身的规则为该活动程序定义一个特征码,并且在控制该活动程序时,能够有效地断绝其与系统正常进程的关联。在没有这个水平之前,诺顿不会大规模采用特征码技术。从mcafee的技术文档来看,mcafee也只是有限度的试验性的研究该技术,并在比较有把握的地方应用。实际上两家公司在这方面还有很长的路要走。
卡巴斯基:本论坛上被过度神话的杀毒软件。我个人非常尊重卡巴斯基的高水准,但说
句实话,在不考虑资源占用的情况下,卡巴斯基并没有什么足够的理由能够让我放弃诺顿
,二者的水平并没有什么差异。在稳定性上,卡巴斯基比诺顿要差一些。由于早些年卡巴
斯基的引擎曾经泄漏(实际上泄漏的并不是初始源代码,只是泄漏的引擎可以比较容易的
反编),因此网上可以找到很多关于卡巴斯基引擎的非常详细的技术分析,尤其是德国的
病毒高手写的关于如何优化卡巴斯基杀毒引擎的文章,被认为是所有采用卡巴斯基引擎的
杀毒软件厂商必看的文章之一,就象美国人写的那篇VB100到底怎么测试杀毒软件(里面作
者综合近几年的测试结果推测了VB100在测试时可能使用的病毒类型,相关比例等)是杀毒
软件厂商在将自己的软件送测前必看的文章一样。从网上大量的分析文档看卡巴斯基的虚
拟机技术是很优秀的,但是去年有人发贴认为卡巴斯基的良好的性能来源于它非常庞大的
病毒库和良好的升级速度,其杀毒引擎设计水平并不高于其余的公司。卡巴斯基的引擎采
用了所谓的单一形式的规则判断,众所周知诺顿是基于分类的规则处理。卡巴斯基的引擎
在文件标识比对病毒库的时候被认为有着很好的性能,充分利用了处理器的处理能力,“
但令人担忧的是,该公司对最新出现的技术并不充分重视”(英国的计算机杂志去年年末的评论),究竟是对原有引擎进行彻底改进还是大量使用新技术,估计谁都不知道。卡巴斯基的引擎存在叫做所谓的“过与简短的文件码”问题,说白了就是有时候会鞭尸,它的研究人员说正在改进。前段时间有人发帖子中指出病毒编写者只认可卡巴斯基,说实话看了很多论坛文档,好像没有哪个强人这么说过。卡巴斯基走的是与美国厂商有很大区别的研发道路,卡巴斯基很少引用别的公司开发的技术,而是在不断的深化,改进自身的杀毒引擎,单从某些方面评论,卡巴斯基的引擎代表着业界最高水准,但并不是全部。卡巴斯基是一款很好的杀毒软件,但并不是神。应该说它与诺顿,mcafee一样都站在杀毒软件的顶峰水平上。
在国内,一直有江民的杀毒软件采用卡巴斯基引擎的传闻,说句实话业界相当一
部分杀毒软件都参考了其引擎设计,即使在国内也没有足够的信息证实只是江民参考了其
引擎设计。很多人都使用各种各样的病毒包对卡巴斯基和江民进行测试,测试结果是完全
一样。说句实话,这种测试并没有什么可信性,对化石孢的检测各种杀毒软件结果几乎都
一样。只有两种方法能够说两者的引擎如何:1.将两款软件送至VB100或者类似的权威机构
进行测试,如果两者对其中未知病毒的测试结果(这个结果并不公布,厂商自己去买)完
全一样,那什么都没说的。两个不同的引擎机制在对待同样大规模的未知病毒库时出现相
同的检测结果近乎是不可能的。可惜的是,江民没有参加过VB100测试,好像也不大可能个
人有足够庞大的未知病毒库来进行检测。2.采用类似于破解的方法进行反编,分析整个软
件的工作机制,工作量有多大相信都能猜出来,也没有见过有人搞过这种研究。因此我个
人只能认为江民可能(较大程度的)参考了卡巴斯基的杀毒引擎设计,但从两款杀毒软件
的灵敏程度,杀毒速度等诸多方民看,即使江民采用了卡巴斯基的引擎,江民也应该进行
了很大程度的源代码修改或者优化,另外也有消息说江民在引擎中加入了一些自己开发的
技术,在实现方法上类似于数字码技术。霏凡上曾有高手指出假如公布两款软件的源代码,可能
并不会有人能看出二者有什么关系。实际上,当发现江民的软件并不能使用卡巴斯基的病
毒库的时候,我们就应该知道即便曾经借鉴过,二者也已经可以被认为是不同的杀毒引擎
。可能在win3.x平台下,二者曾经很相近;但是今天我们在使用winxp.即使江民确实采用
过卡巴斯基的引擎,那么可以说江民在某些方面发展了这套引擎,尽管这种发展未必与原
始的研发方向相符。但无论基于何种角度考虑,我认为江民的杀毒软件还是有优秀之处的
。毕竟你回头看一看国内的杀毒软件厂商,在真正的技术研发领域只有这么一面旗帜偶尔
飘扬。一步步走下来,江民还是有技术进步的。只就纯技术因素而论,假如江民采用了卡
巴斯基的引擎,那么今天两家厂商在不同的方向上发展着那套原始的引擎,这未必是坏事
,只要不固步自封,我们好像没什么必要争论两家厂商是否一个原始祖先,怕的就是在别
人都往前跑的时候自己停下来,这跟自取灭亡没什么区别。尽管市场是杀毒软件厂商的第
一要素,但别忘了技术是一个杀毒软件能否基业常青的决定性力量。
有人问趋势采用什么引擎,现在我个人只知道它的引擎是自己研发的,属于纯规则分析型引擎,在技术上应用中间件技术。但是趋势公司的病毒库好像有点小,仅是传闻而已。能够看到的关于它的评论如下:"在不考虑病毒库因素的情况下,趋势的产品拥有优秀的引擎技术和防护性能(翻译大致意思)”。
全文完。
※ 修改:·Kernel 於 Jul 27 10:43:05 2004 修改本文·[FROM: 218.108.197.181]
※ 来源:·哈工大紫丁香 http://bbs.hit.edu.cn·[FROM: 218.108.197.181]
Powered by KBS BBS 2.0 (http://dev.kcn.cn)
页面执行时间:2.595毫秒