病毒和正常程序的区别可以体现在许多方面，比较常见的如通常一个应用程序在最初的指令是检查命令行输入有无参数项，清屏和保存原来屏幕显示等，而病毒程序则从来不会这样做，它通常最初的指令是直接写盘操作、解码指令，或搜索某路径下的可执行程序等相关操作指令序列。这些显著的不同之处，一个熟练的程序员在调试状态下只需一瞥便可一目了然。
启发式扫描技术实际上就是把这种经验和知识移植到一个查病毒软件中的具体程序体现。
因此，在这里，启发式指的“自我发现的能力”或“运用某种方式或方法去判定事物的知识和技能。”
一个运用启发式扫描技术的病毒检测软件，实际上就是以特定方式实现的动态高度器或反编译器，通过对有关指令序列的反编译逐步理解和确定其蕴藏的真正动机。例如，如果一段程序以如下序列开始：MOV AH ,5/INT,13h， 即调用格式化盘操作的BIOS指令功能，那么这段程序就高度可疑值得引起警觉，尤其是假如这段指令之前不存在取得命令行关于执行的参数选项，又没有要求用户交互性输入继续进行的操作指令时，可以有把握地认为这是一个病毒或恶意破坏的程序。 在具体实现上，启发式扫描技术是相当复杂的。通常这类病毒检测软件要能够识别并探测许多可疑的程序代码指令序列，如格式化磁盘类操作，搜索和定位各种可执行程序的操作，实现驻留内存的操作，发现非常的或未公开的系统功能调用的操作，等等，所有上述功能操作将被按照安全和可疑的等级可以排序，根据病毒可能使用和具备的特点而授以不同的加权值。 随便举个例子，格式化磁盘的功能操作几乎从不出现在正常的应用程序中，而病毒程序中则出现的几率极高，于是这类操作指令序列可获得较高的加权值，而驻留内存的功能不仅病毒要使用，很多应用程序也要使用，于是应当给予较低的加权值。如果对于一个程序的加权值的总和超过一个事先定义的阀值， 那么， 病毒检测程序就可以声称“发现病毒！”仅仅一项可疑的功能操作远不足以触发“病毒报警”的装置，如果不打算上演“狼来了”的谎报和虚报来故意吓人，最好把多种可疑功能操作同时并发的情况定为发现病毒的报警标准。
启发式扫描通常应设立的标志，为了方便用户或研究人员直观地检测被测试程序中可疑功能调用的存在情况，病毒检测程序可以显示为不同的可疑功能调用设置标志。例如，TbScan（参见注释）这一病毒检测软件就为每一项它定义的可疑病毒功能调用赋予一个旗标，如F,R,A……， 这样以来可以直观地帮助我们对被检测程序进行是否染毒的主观判断。
各标志的含义
F＝ 具有可疑的文件操作或能。有可疑进行感染的操作。
R＝ 重定项功能。程序将以可疑的方式进行重定向操作。
A＝ 可疑的内存分配操作。程序使用可疑的方式进行内存申请和分配操作。
N＝ 错误的文件扩展名。扩展名预期程序结构与当前程序相矛盾。
S＝ 包含搜索定位可执行程序（如EXE或COM）的例程。
#＝ 发现解码指令例程。这在病毒和加密程序中都是经常会出现的。
E＝ 灵活无常的程序入口。程序被蓄意设计成可编入宿主程序的任何部分，病毒极频繁使用的技术。
L＝ 程序截获其它软件的加载和装入。有可能是病毒为了感染被加载程序。
D＝ 直接写盘动作。程序不通过常规的DOS功能调用而进行直接写盘动作。
M＝ 内存驻留程序。该程序被设计成具有驻留内存的能力。
I＝ 无效操作指令。非8088指令等。
T＝ 不合逻辑的错误的时间标贴。有的病毒借此进行感染标记。
J＝ 可疑的跳转结构。使用了连续的或间接跳转指令。这种情况在正常程序中少见但在病毒中却很平常。
?＝ 不相配的EXE文件。可能是病毒，也可能是程序设计失误导致。
G＝ 废操作指令。包含无实际用处，仅仅用来实现加密变换或逃避扫描检查的代码序列。
U＝ 未公开的中断/DOS功能调用。也许是程序被故意设计成具有某种隐蔽性，也有可能是病毒使用一种非常规手法检测自身存在性。
O＝ 发现用于在内存在搬移或改写程序的代码序列。
Z＝ EXE/COM辨认程序。病毒为了实现感染过程通常需要进行此项操作。
B＝ 这回程序入口。包括 可疑的代码序列， 在完成对原程序入口处开始的代码修改之后重新指向修改前的程序入口病毒极常见。
K＝ 非正常堆栈。程序含有可疑的或名其妙的堆栈。
例如对于以下病毒，TbScan将点亮以下不同标志。 Jerusalum/PLO(耶路撒冷病毒) FRLMUZ Backfont/ 后体病毒 FRALDMUZK mINSK-gHOST FELDTGUZB Murphy FSLDMTUZO Ninja FEDMTUZOBK Tolbuhin ASEDMUOB Yankee-Doodle FN#ELMUZB 对于某个文件来说，被点亮的标志愈多，染毒的可能性就愈大。常规干净程序甚至很少会点亮一个标志旗，但如果要作为可疑病毒报警的话，则至少要点亮两个以上标志旗。如果再给不同的标志旗赋以不同的加权值，情况还要复杂得多。 关于虚警（谎报） ─ 正如任何其他的通用检测技术一样，启发式扫描技术有时也会把一个本无病毒的程序指证为染毒程序，这就是所谓的查毒程序虚警或谎报现象。原因很简单。被检测程序中含有病毒所使用或含有的可疑功能。例如，QEMM所提供的一个LOADHI.COM程序就会含有以下可疑功能调用。 LoadHi程序中确实含有以上功能调用，而这些功能调用足以触发检毒程序的报警装置。因为LoadHi的作用就是为了分配高端内存，将驻留程序（通常如设备驱动程序等等）装入内存，然后移入高端内存，等等……，所有这些功能调用都可以找到一个合理的解释和确认，然而，检毒程序并不能分辨这些功能调用的真正用意，况且这些功能调用又常常被应用在病毒程序中，因此，可怜的检测程序只能判定Load Hi程序为“可能是病毒程序”。 虚警（谎报）的后果有多严重 如果某个基于上述启发式代码扫描技术的病毒检测程序在检测到某个文件时弹出报警窗口“该程序可以格式化磁盘且驻留内存”而你自己确切地知道当前被检测的程序是一个驻留式格式化磁盘工具软件，这算不算虚警谎报呢？ 因为一个这样的工具软件显然应当具备格式化盘以及驻留内存的能力。启发式代码检测程序的判断显然正确无误，这可算做虚警，但不能算做谎报（误报）。问题在于这个报警是否是“发现病毒”， 如果报警窗口只是说“该程序具备格式化盘和驻留功能”，好，100%正确，但它如果说“发现病毒”，那么显然是100%的错了。关键是我们片怎样看待和理解它真正的报警的含义。检测程序的使命在于发现和阐述程序内部代码执行的真正动机，到底这个程序会进行哪些操作，关于这些操作是否预期或合法，尚需要用户方面的判断。不幸的是，对于一个一的新手来说，要做出这样的判断仍然是有困难的。 如何避免虚警和误报 ── 不管是虚警也好，误报或谎报也好，抛开具体的名称叫法不谈，我们决不希望在每次扫描检测的时候我们的检测程序无缘由地狂喊“狼来了”，我们要尽力减少和避免这种人为的紧张状况，那么如何实现呢？必须努力做好以下几点： 1、 对于病毒行为的准确把握而给定的关于可疑功能调用集合的精确的定义。除非满足两个以上的病毒重要特征，否则不予报警。 2、 对于常规的佥程序代码的和识别能力。某些编译器提供运行时实时解压或解码的功能及服务例程，而这些情形往往是导致检测时误报警的原因，应当在检测程序中加入认知和识别这些情状的功能模块，以避免再次误报。 3、 对于特定程序的识别能力。如上面涉及到的LoadHi及驻留式格式化工具软件等等。 4、 类似“无罪假定”的功能，首先假定程序和电脑是不含病毒的。许多启发式代码分析检毒软件具有自学习功能，能够记信那些并非病毒的文件并在以后的检测过程中避免再报警。 如何处理虚警谎报 ─ 不管采用什么样的措施，虚警谎报现象总是要存在的。因此不可避免地用户要在某些报警信息出现时作出自己的抉择：是真正病毒还是误报？也许会有人说：“我怎么知道被报警的程序到底是病毒还是属于无辜误报？”大多数人在问及这个问题的第一反应，是“谁也无法证明和判断。”事实上是有办法作出最终判决的，但是这还要取决于应用启发式代码分析检测技术的查病毒程序的具体解释。 假如检测软件仅仅给出“发现可疑病毒功能调用”这样简单的警告，信息而没有更多的辅助信息，对于用户来说几乎没有什么可资判断是否真正病毒的实际帮助价值，换个说法，“可能是病毒”似乎永远没错，不必担负任何责任，而用户不希望得到这样模棱两可的解释。 相反地，如果检测软件把更为具体和实际的信息报告给用户，比如“警告，当前被检测程序含有驻留内存和格式化软硬盘的功能”，类似的情况更能帮助用户扩清楚到底会发生什么？该采取怎样应对措施。比如这种报警是出现在一个字处理编辑软件中，那么用户几乎可以断定这是一个病毒。当然如果这种报警是出现在一个驻留格式化盘工具软件上，用户大可不必紧张万分了。这样以来，报警的可疑病毒常用功能调用都能得到合理的解释，因而也会得到圆满正确的处理结果。 自然地， 需要一个有经验的用户从同样的报警信息中推理出一个 “染毒”还是“无毒”的，结论并非每一个用机者可以完全胜任的。因此，如果把这类软件设计成有某种学习记忆的能力，在第一次扫描时由有经验的用户逐一对有疑问的报警信息作好“是”与“非”的判断，而在以后的各次扫描检测时，由于软件学习并记忆了第一次检测时处理结果，将不再出现同样的烦人的提示警报。因为不论在什么情况下，偶尔请教一下某个有经验的“高手”并不，难难堪的是每次就同样的问题去麻烦别人。 不管怎样的缺点和不足，和其它的扫描识别技术相比起来，启发式代码分析扫描技术几乎总能提供足够的辅助判断，信息让我们最终判定被检测的目标对象是染毒的，亦或是干净的。启发式代码分析检测技术的实用应用效果如何？启发式扫描技术仍然是一种正在发展和不断完善中的新技术，但已经在大量优秀的反病毒软件中得到迅速的推广和应用。按照最保守的估计，一个精心设计的算法支持的启发式扫描软件，在不依赖任何对病毒预先的学习和了解的辅助，信息如特征代码，指纹字串，校验和等等的支持下，可以毫不费力地检查出90%以上的对它来说是完全未知的新病毒。 可能会出现一些个虚报、谎报的情况，适当加以控制，这种误报的概率可以很容易地被降低在0.1%以下。 传统扫描技术与启发式代码分析扫描技术的结合运用 前面论述了簋多启发式代码分析技术的优点和长处，会不会引起某些人的误解，以为传统的检测扫描技术就可以丢弃了呢？情况当然不是这样。从实际应用的效果看来，传统的手法由于基于对已知病毒的分析和研究，在检测时能够更准确，减少误报；但如果是对待此前根本没有见过的新病毒，由于传统手段的知识库并不存在该类（种）病毒的特征数据，则有可能毫无瓜，产生漏报的严重后果。而这时基于规则和定义的启发式代码分析技术则正好可以大显身手，使这类新病毒不至成为漏网之鱼。传统与启发式技术的结合支用，可以使病毒检测软件的检出率提高到前所未有的水平，而另一方面，又大大降低了总的误报率。详见以下测试实验结果对比数据： 启发式判定结果 传统式判定结果 可能的真正结果 干净 干净 非常可能就是干净的 干净 有毒 很可能误报 有毒 干净 很可能有毒 有毒 有毒 极有可能确实染毒 三种技术结合使用 虚报率 10% 1% 1% 漏报率 0.1% 0.001% 0.00001% 某种病毒能够同时逃脱传统和启发式扫描分析的可能性是小的，如果两种分析的结论相一，致那么真实的结果往往就如同其判断结论一样砍无，疑两种不同技术对同一检测样分析的结果不一致的情况比较少见，这种情形下需借助另外的分析去得出最后结论。 仍然以 TbScan 6.02为测试举例，下面是分别使用不同技术和结合应用的测试结果： 测试用技术 总数为7210个样本的病毒检出数 检出率 传统的 7056 97.86% 启发式 6465 89.67% 结合应用 7194 99.78% 启发式反毒技术的未来展望 研究的逐步深入，使技术发展不断进步。一方面绝大多数反病毒厂家的产品中还未能引入一个较为成功和可靠的启发式检测技术的内核，另一方面，即使是在少数依靠的知名反病毒产品中这项技术的运用也还需要经受不断的完善和发展。任何改良的努力都会有不同程度的质量提高，但是不能企望在没有虚报为代价的前提下使检出率达到100%，或者反过来说，大约在相当长的时间里虚报和漏报的概率不可能达到0%。 这听上去或许有些不可思议，其实不难理解。100%正确的检测结果只所以不存在，是因为有相当一部分程序（或代码）介乎于病毒与非病毒之间，即便对于人脑来说，合乎逻辑又合乎病毒定义的结论往往会截然相反。随便举一个例子，如果依据广为接受的病毒的定义：“病毒，就是复制自身的拷贝或改良的复本的一些程序。”那么，众所周知的磁盘复制程序 DiskCopy岂不是也落入病毒的分类中了吗？但是，情况显然并非如此…… 病毒技术与反病毒技术恰如“道”与“魔”的关系，也许用“道高一尺，魔高一丈”来形容这对矛盾的斗争和发展进程再为恰当不过了。当反病毒技术的专家学者在研究启发式代码分析技术对传统的特征代码扫描法查毒技术进行改革的时候，也确实收到了很显著的效果，甚至可以说，相对于病毒技术的加密变换(Mutation)，尤其是多形、无定形病毒技术(Polymorphsm) 对于传统反毒技术的沉重打击，杀了一个漂亮的回马枪。但是，反毒技术的进步也会从另一方面激发和促使那些丧心病狂的病毒制作者的不断研制出更新的病毒，具有某种反启发式扫描技术功能，可以逃避这类检测技术的新型病毒。但是，值得庆幸的是，即便能够写出具有这种能力的病毒，它所需要的技术水准和编程能力要复杂得多，绝不可能象对搞传统的基于特征值扫描技术的反毒软件，那么容易，任何一个程序的新手只要将原有的病毒稍加改动， 哪怕只是一个字节，只要恰 好改变了所谓“特征字节”， 就可使这种旧病毒的新变种从未经升级的传统查毒软件的眼皮底下逃之夭夭。 结论 ── 抛开启发式代码分析技术实现的具体细节和不同手法不谈，这种代表着未来反病毒技术发展的必然趋势具备某种人工智能特点的反毒技术，向我们展示了一种通用的、不需升级（较省需要升级或不依赖于升级）的病毒检测技术和产品的可能性，由于诸多传统技术无法企及的强大优势，必将得到普遍的应用和迅速的发展。资料显示，目前国际上最著名的排名在前五名的反病毒软件产品均声称应用了这项技术，从来自不同机构和出处的评测结果来看，纯粹的启发式代码分析技术的应用（不借助任何事先的对于被测目标病毒样本的研究和了解），已能达到80%以上的病毒检出率， 而其误报率极易控制在0.1%之下，这对于仅仅使用传统的基于对已知病毒的研究而抽取“特征字串”的特征扫描技术的查毒软件来说，是不可想象的，一次质的飞跃。 在新病毒，新变种层出不穷，病毒数量不断激增的今天，这种新技术的产生和应用更具有特殊的重要意义。
注：TbScan是ThunderBYTE的产品，The technology ThunderBYTE possessed was of course not lost, it was re-used in the design of the Norman Scanner Engine，已经并入Norman。
