下面小编为大家带来连载：反病毒误报问题机理技术蓝皮书(八)病毒防范，本文共5篇，希望大家喜欢!本文原稿由网友“woshijxs”提供。
篇1：连载：反病毒误报问题机理技术蓝皮书(四)病毒防范
【上文我们了解了样本分析与判定环节，下面再进一步认识特征提取环节，】
四、特征提取环节
另外一些误报，不是对样本的认定过程出现了问题，而是在正确的病毒样本上所提取的特征会在正常程序上被匹配到。
哪些环节引发特征提取导致的误报呢？最典型的是下面几种：
1、感染
对感染病毒特征的提取，取决于对病毒体位置的准确判定，病毒分析工程师必须能有效找到病毒代码和宿主程序之间的边界，否则如果误把特征提取到正常程序上，不但不能有效查杀病毒，反而导致了误报。这种事件并不常见，但确实发生过。
2、壳
如果一种壳，反病毒软件没有脱掉的能力，那么用这个壳处理过的有害程序，特征通常会提取在静态文件上，而如果特征的位置，正好在壳的代码，则有可能导致反病毒软件会误报所有的用这种壳压缩过的可执行程序。
3、自解压文件
广义自解压文件，不仅包括类似WINZIP、WINRAR生成的能够自动运行、自我解压的程序，也包括很多安装包制作工具制作的安装文件。自解压的机理也会被病毒作者利用，在很多木马作者构造社交工程的过程中，他们认为安装包制作工具比类似EXEBIND的机制更为好用，也更有欺骗性。因此他们用自解压包制作工具把正常程序和他们的木马打包放在一起，让用户误认为是在安装正常程序，但实际上木马被执行了。
自解压文件误报是自大量DIY蠕虫开始的，在病毒作者拼凑完成一个DIY蠕虫后，如何让这些散兵游勇成为一个文件呢？他们想到了利用WINZIP之类的工具作个自解压包，并设定其中的某个程序被解压后自动执行。
自解压导致的误报的原因与壳误报的原因很类似，就是特征被提取到了自解压的代码上，这样所有用该种工具制作的包裹可能都会被误报，
但细致来看，自解压误报还分很多种情况，一种情况是病毒分析工程师没有识别出这是一个自解压包，而可能把这种包括当作某种EXE结合器来看待。还有一种情况是，虽然识别出了自解压包裹，但必须能够保证，反病毒软件需要能够识别，并删掉这个自解压包裹，比如DIY蠕虫，前者是判定上的错误，而后者是特征提取经验的不足。
需要说明的是，由于反病毒软件通常对于自解压包的检测，与包裹文件检测是相类似的，即都需要解开察看内部的文件，因此反病毒软件和后段处置体系，是有常见自解压包裹的类型识别和处理能力的，因此对所能识别的自解压程序产生误报的原因，往往是因为病毒作者对DIY蠕虫或者木马的自解压包进行了2次修改，如通过PE_Patch修改了入口，导致分拣机制无法判定这是一个自解压样本，这样分拣机制就会把非包裹的属性送给反病毒工程师，反病毒工程师此时就有可能直接在代码段上提取特征了。
4、编译器
对于不加壳的样本，通常的病毒特征提取，为了保证质量，通常都会提取在代码段上，这就带来了一个隐含的问题，即编译器误报。不同的编译器生成的目标代码，会有不同的特性。有的编译器编译不同的程序，在入口处就会表现出明显不同的特性，但有的编译器则在入口之后，有一个相对长的相似部分。如果提取在这个相似部分上，可能会导致反病毒软件误报。通常对于主流编译器，反病毒厂商都会有一个基本的提取原则或者禁忌。但还有一些覆盖率不高、用户较少的边缘开发工具，反病毒厂商对此搜集的则未必齐全。
在编译器这里需要说明的是，有时误报源于壳与编译器的组合，如果一种壳不能脱掉的话，对于壳的特征提取往往会有一些经验方法，但那些编译结果代码相似段较长的编译器编译出来的不同程序，用壳压缩过之后，可能还会出现大量的相似部分。如果提取在这个位置上依然会产生误报。
5、非典型性特征提取
【后面的文章里，我们将继续学习引擎机理环节。】
篇2：连载：反病毒误报问题机理技术蓝皮书(二)病毒防范
【上文我们了解了误报的成因，下面再看下误报都有哪些类型，】
二、误报的类型
看待误报，可以有很多种角度，从技术角度，误报可能是一个bug，而从另外一些角度来看，误报则是一种争议，这种争议比较主要的在于什么是病毒或恶意代码这样的一个标准的不同认识。
对某一个程序，在发生误报的争议后，反病毒厂商分析确认依然认为是病毒的情况。这种情况通常不是技术的问题，而是判定病毒或更广泛的恶意代码的标准。在现实生活中，其实这种情况要比从技术上的误报更普遍。
比较常见的标准差异是广告件厂商与反病毒厂商经常发生的冲突和诉讼，由于装机量和广告件厂商的收入息息相关，因此广告件厂商往往采用一些比较极端的推广自己的方式、也包括页面注入和通过其他的广告件分发、甚至通过蠕虫或者僵尸网络分发。反病毒软件无疑成为了这种经济模式的天敌，一旦遭打反病毒软件的查杀，则它们的装机量就会骤然下降。因此，反病毒厂商最常见的误报投诉，往往来自这些厂商，伴随着误报投诉的则可能还包括律师函、直至法院的传票。
一些广告件厂商，惯常的作法是开始极端推广，达到满意的装机量后，为了逃避查杀，则马上去掉所有不规范之处，再找公正机构公证自己没有危害，然后向反病毒厂商交涉。在他们眼中，既然反病毒厂商并不是执法机构，自然也没有道理去清算“原罪”。
还有一种标准差异的情况在于对一些与安全攻防相关工具的定性，比如一些后门程序的作者，都坚称自己开发的不是后门或木马，而是网络远程管理工具。但对反病毒企业的基本技术标准来看，远程控制管理工具和后门的根本区别是前者对被控端至少是可见（如有托盘图标）的，并且是需要有安装确认过程的，
此外，在部分安全工作者中还有这样的一种认识，即反病毒软件应该查杀对所运行主机有害的东西，而无须考虑运行结果是否危害其他主机。比较突出的观点就是在BO后门开始流行后，一些人认为反病毒厂商不应该查用于控制受害主机的Client端。
被迫的误报：对反病毒工程师角度来说，还会有一些不得不添加规则去查杀一些并非病毒的东西，这往往是对市场压力的屈从。网上经常会流传一些垃圾样本集合，如所谓101种经典病毒、3000种经典病毒之类，但这其中不但所有的程序都没有主流操作系统的活性，而且有些根本就不是病毒，但往往很多普通用户则认为谁的检测率高，那种软件就好，因此反病毒工程师则在市场部门的压力下，违心的添加了这些垃圾规则。
上述的情况虽然也可能被认为误报，但从反病毒厂商的技术流程角度，不能称为误报，因为反病毒软件报警了他们主观想要报警的东西，这个过程没有技术上的问题。
我们需要分析的误报，则是一个检测对象被反病毒软件报警了，但经过反病毒厂商自身确认后，认定不是病毒的检测对象。
通常来说可能带来误报的环节有四个：样本分析与判定环节、特征提取环节、引擎工作机理环节、未知判定环节。
如果说的更明确一些，让我们来看一下误报构成的通路。
情况一：样本判定环节厂商把一个入库的非病毒样本误判定为病毒，导致这个文件被误查。
情况二：厂商把一个入库的非病毒样本误判定为病毒，导致这个文件以及这个文件同源的文件被误查。
情况三：厂商在一个入库的病毒样本上提取病毒特征，但这个特征可能在其他正常程序上能够匹配到。
情况四：厂商的未知病毒检测机制（如行为加权）判定一个可执行程序风险超过阈值，从而告警，而实际上这是一个正常程序。
当然还有一种极端的情况，即构造者根据厂商的病毒特征构造出一个能被报警的无毒文件。
图：误报的类型
【后面的文章里，我们将进一步了解样本分析与判定环节。】
篇3：连载：反病毒误报问题机理技术蓝皮书(一)病毒防范
一、误报的成因分析
首先需要澄清三个概念，即漏报、错报和误报，
漏报：反病毒产品检测一个可确认是病毒的检测对象而没有报警。
错报：反病毒产品检测一个可确认是某种病毒的检测对象，报警为另一种病毒。
误报：反病毒产品检测一个可确认不是病毒的检测对象报警为病毒。
一些用户将错报视为一种误报，实际上这是两个完全不同的概念，率先澄清这个概念有助于专心与我们今天的主题。
反病毒作为信息安全领域一门严谨的工程技术，是以保证信息系统应用为前提的，由于误报会导致用户的心理恐慌，对被误杀产品不好的舆论影响，以及直接导致误杀，从而导致信息系统出现某种不可预期的后果，因此误报问题相对漏报和错报往往更加敏感。在某个非官方技术标准中，对反病毒的误报率作出了规定，即不能超过万分之零点五，即对十万个不同的检测对象，允许有五个误报，但对此无论是公众还是反病毒工作者自己依然觉得不可接受，而希望达到零误报的境界，
这也反映了工程化应用和学术化研究的不同视角，我们也经常看到从事反病毒理论方面的年轻研究者们经常兴奋不已，“看，只要建立这样一个简单的神经网络（如BP网络），并把若干样本和正常文件进行学习，再检测此前未经神经网络学习过的样本集合时，就会获得80%以上未知病毒检出率”。这种方法无论如何先进，只要误报了任何一个windows的系统文件或者program下面的正常程序文件，就都不能不加改动的应用到实际系统中。
这就是为什么，在实际的反病毒产品中，如果有超过10%的未知病毒检出率，就可以视为很不错的结果，而反病毒的一些paper中则往往会出现令人鼓舞的比率。这是因为极低的误报率是商用反病毒技术的基础。过去关于未知检测就有这样的一个玩笑，100%检测未知病毒？很简单，只要对每个检测对象都报病毒就可以了，也就是说只有100%的误报率，才能造就100%的检出率。
当然我们依然需要学术上对新的病毒检测理论方法的不懈探索，所谓大胆想象，小心求证。
图 误报问题全图
【后面的文章里，我们将进一步了解误报的类型。】
篇4：连载：反病毒误报问题机理技术蓝皮书(八)病毒防范
【上文我们了解了降低误报的方法与流程，最后我们来认识下误报构造的可行性分析，】
八、误报构造的可行性分析
本文在这里只是论证一下误报构造的技术可能性，并不对目前是否有误报构造现象进行评论。误报构造者根据厂商的病毒特征构造出一个能被报警的无毒文件，这在技术是完全有可能的，这就象是目前很流行的网络搜索引擎优化的机理一样，通过分析反病毒厂商的病毒判定机制，从而构造出一个无毒的报警文件来。
例如，T.Com 文件会被AVP 报警为vienna.604，但实际文件长度只有几个字节，用DEBUG可以看到该文件内容如下：
用反汇编的方法可以看到，本身只是重启计算机的功能：
九、结束语
司法界的一位朋友曾告诉我们这样一个道理，“不冤枉一个好人，比不放过一个坏人更重要，因为放过一个坏人犯了一个错误，而冤枉好人是两个错误，在冤枉好人的同时，也放过了坏人”，
如果做一个类比的话“误保”的后果也不言而喻，误报和漏报相比，如果说出现“漏报”可能会造成无法有效保障用户安全，而误报则不仅干扰了用户，还可能伤害了被误报软件的作者。正因为此，误报问题一度构成了反病毒技术的危机，为了解决误报问题，一些厂商在构建更广泛的基础支撑体制，也有的在发布病毒库的时候变得缓慢而谨慎，而在寻求更有效可靠的病毒检测方法、为用户提供良好保障方面，我们一直在努力。
最后还需要与全体同路人共勉的一句话是，我们需要一个更完备的体制和更先进的方法，但我们也清楚，任何制度和方法都无法代替反病毒工程师的水平、耐心与责任感。（全文完）
篇5：连载：反病毒误报问题机理技术蓝皮书(六)病毒防范
【上文我们学习引擎机理环节，下面了解一下未知检测环节，】
六、未知检测环节
未知检测机理的误报与前面的环节都是不同的，前面的环节是由一个从样本出发、到特征提取、到病毒库升级的链条过程产生的，而未知检测则完全是依靠反病毒软件自带的经验模型在客户端智能判定程序的有害性，
未知检测的机理，很多文章都判定过，就是加权判定法，通过程序的行为或者一些静态特性设置标志，每个标志有不同的权值，通过根据程序标志取值的累加，就可以形成程序的风险值，如果超过了阈值，就会报警。这个机理说起来简单，但操作起来则是一个复杂的体系。其中重要原因之一就是因为未知病毒检测机制的误报指标与已知病毒检测技术的误报指标是完全相同的，而未知检测由于没有样本确认和提取过程，从而变得十分尴尬。
例子：某硬盘保护程序曾被我们的VCS抓毒精灵机制误报，误报的原因很简单，就是他确实和太多的病毒行为标志重合了。确实这些系统底层的保护程序，往往难以回避一些与病毒相近的特性。
