主动防御，不可能完成的任务
首先我先说明一下我自己的立场,我认为主动防御是一项不可完成的任务。单独使用主动防御无法真正达到“主动防御”概念所描述的那样的一个状态。为什么呢？简单说是因为其主动防御标准含糊不清楚，没得具体的行业标准，可以说是理论上可行而技术上不可行的东西。看了众多贴子，现在已经有了专门的主动防御软件,有人支持这个主动防御软件，有人质疑这个主动防御软件。众说分云，因此我们需要从主动防御这个概念来说是否真的可行!首先，根据这个主动防御软件所称有众多的逻辑分析来确定是否为不合法的程序或者病毒等。我们搞技术的都知道，所谓复杂的逻辑分析如果用程序表达出来就是很多的if条件。但是这些if条件只是这个主动防御软件的标准，而不是主动防御标准，那这样的标准怎样能让用户信服？因此，就常常会出现误报。也许有人会说，其它安全工具或者杀毒软件也会出现这样的状况。因此，这就恰恰说明了为什么其它工具把主动防防御作为辅助手段，也说明了这个主动防御软件根本没有质的飞跃。这也许不是这个主动防御软件的错，这是因为的确主动防御这个概念很吸引人，但是没有非常清晰的界定。即通过行为特征认定病毒的标准。同样，这个主动防御软件自身产品也会做很多挂接动作，为什么就不被认定是恶意程序或者病毒。因为开发者知道自己做的这个主动防御软件是来保护系统的。这我也知道。但是，为什么偏偏就要认为我开发的游戏外挂之类(单机游戏外挂)的东东是病毒，我游戏外挂第一不访问网络，只是挂接一些API或者修改游戏主程序的一些变量即内存指令。为什么我的程序就是病毒。也许又有人会说了，你不是可以将这些你认为信任的程序加入到这个主动防御软件中嘛？那如果是这样，对于用户来说，他能知道哪些是可信任和不可信任，干嘛还要来用这些东东？因此，我认为由于主动防御由于没有既定的标准，也就大大限制这个主动防御软件自身的成长(冲其量也无非是有更多的if语句而已)，这样根本不是质的创新，也谈不上优越于其它的杀毒软件。
从技术角度来讲,如果单独使用主动防御是否真的能冲当主力?根据一些贴子描述得知这个主动防御软件使用了Driver，这是很明智的选择!先支持一下^_^!但是这个主动防御软件的Driver似乎只对ntoskrnl中的一些内核例程还有AP层的一些API有所挂接,我是想问这样就能挡得住病毒嘛?假设一个程序使用NtOpenFile或者CreateFile打开一个磁盘盘符,然后使用WriteFile或者NtWriteFile来进行直接写扇区,如果是一个正常程序写入合法的数据OK，如果这个主动防御软件没有认为是病毒那么我觉得是正确的。但是，如果一个病毒或者恶意程序同样使用与正常程序同样的流程只是WriteFile的时候写入的数据是恶意的、有破坏性的那么这个主动防御软件能防住嘛?因为根据其这个主动防御软件的行为特征来判定,由于默认了正常程序的行为流程那么也意味着其病毒或者恶意程序的流程也在这个主动防御软件中视为合法,这带来的后果我不想多说了。另外，像NtWriteFile或者ZwWriteFile等一些内核例程，其实是把命令打成IRP丢到文件系统层,如果病毒不经由NtWriteFile或者ZwWriteFile这些内核例程直接像文件系统发送命令，那么x有办法拦到嘛?另外,随着操作系统内核技术公开化,有些病毒也许还会自带Driver,而这些Driver并不是由病毒动态加载。而是由系统每次启动时加载,也许比这个主动防御软件的Driver还要先启动起来。此时我就展开联想说一下,假设病毒Driver一旦加载,他要感染某个程序非常简单。最简单的方法是直接调用内核例程,像上面提到的，其次自动构造IRP扔到文件系统中,除非x在文件系统Driver层进行拦截。OK,病毒Driver它干脆不扔文件系统层了,而走更低层的Disk磁盘层。有办法主动防御嘛？如果这都有办法主动防御,那么病毒根本不在使用操作系统提供的Driver层次结构,而直接使用IN、OUT指令来对硬盘进行读写。有办法主动防御嘛,可以说到了这里可以说从实践中基本上是无法拦截住了,就算在Disk层就很困难。当然不是没有办法,使用DR调试寄存器来拦截下来。当然不提其它什么更深层的RootKit技术。就说得更简单一点,如果病毒Driver一旦被加载是没有办法让其Unload,除非重启。主动防御不仅从理论上有缺陷,从技术层面来说是不可真正的实现动态监视，基于这两方面主动防御目前只能成为安全工具的辅助手段，也是不可完成的任务。现在这个主动防御软件看似强悍，只是因为它还没有名气，没有世界一流的病毒制造者来研究破解主动防御的方法罢了。
用户系统信息：Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; Maxthon; CIBA)
