先给大家道个歉，我是《内核模式结束冰刃》的作者。我在文中有句话说错了，这是最近和同学做课设时发现的。错误地方在比较SSDT挂钩和内联优劣处“......原因有二。一是当SSDT函数被其他驱动挂钩后，再次挂钩就‘必死无疑’......”

以前主要是用SSDT挂钩的驱动进行实验，发现只要一加载启动，我的安有金山的机子就挂，所以一直有这样一个错觉。前不久和同学做课设任务管理器时，添加一些内核东西来增色，其中SSDT进程守护是其中之一，但是我们通过先前规划在测试时(机子有卡巴)发现没有蓝而且很稳定，然后我发现我的安装金山的机子也很稳定，所以觉得之前说得肯定有问题——不是“必死无疑”。

主要在于代码，黑防的作者们在SSDT挂钩上大多都是这样写的：

...
ZWOPENPROCESS OldZwOpenProcess = NULL; //原来函数地址，但不一定是原始地址
...
//传入挂钩宏的是当前SSDT表上指定函数地址
HOOK_SYSCALL(ZwOpenProcess,NewZwOpenProcess, OldZwOpenProcess);
...
//卸载驱动就是把原来存的地址还给SSDT表中之前HOOK的位置
UNHOOK_SYSCALL(ZwOpenProcess,OldZwOpenProcess,NewZwZwOpenProcess);

我想之所以不出问题，就是相当于新加驱动如同链表一样加到内核模块和卡巴驱动模块中，然后新驱动和卡巴驱动都检查一次。这就是为什么我加载驱动后，自编任务管理器和卡巴都不能由WIndows任务管理器结束的原因。

内核——卡巴检查——内核执行
内核——新驱动检查——卡巴检查——内核执行

但是如果卡巴驱动卸载(断链)，那就是“必杀”之一了；还有可能就是我们的驱动未正常卸载，然后又一次挂钩，驱动按代码要求，把SSDT表当前的HookAddr存入原始地址，再写入SSDT表另一个HOOK位置，我想驱动又不能同样的加载两次，这个新HOOK位置和HookAddr极可能是同一个。我们之前也因此蓝屏数次，后来加了个标字位就好了

......
case IOCTL_PROTECT_CONTROL:        //保护驱动
//MDL修改完成，现在HOOK内核函数
if(FlagProtected==0)
{
HOOK_SYSCALL(ZwOpenProcess,NewZwOpenProcess, OldZwOpenProcess);
HOOK_SYSCALL(ZwTerminateProcess,NewZwTerminateProcess, OldZwTerminateProcess);        
}
FlagProtected=1;
ProtectPID = *(long*)Irp->AssociatedIrp.SystemBuffer;//接受外部输入数据
break;
......

我画了副图，大家可以看看，再次道歉啦，今后会注意、慎重




顺便提句，前不久有人提出，我这个程序有个地方没有重定位，主要见下
//启动冰刃前
lkd> u nt!NtOpenProcess
nt!NtOpenProcess:
80574c96 68c4000000      push    0C4h
80574c9b 68b0a94e80      push    offset nt!ObReferenceObjectByPointer+0x127 (804ea9b0)
80574ca0 e896e7f6ff      call    nt!CIsqrt+0x2da (804e343b)
80574ca5 33f6            xor     esi,esi

//启动冰刃后
lkd> u nt!NtOpenProcess
nt!NtOpenProcess:
80574c96 e9a319866c      jmp     ecdd663e
80574c9b 68b0a94e80      push    offset nt!ObReferenceObjectByPointer+0x127 (804ea9b0)

//截杀冰刃后
lkd> u nt!NtOpenProcess
nt!NtOpenProcess:
80574c96 68c4000000      push    0C4h
80574c9b 68b0294100      push    4129B0h ;重定位：804d8000+4129b0-400000就对了

错误原因：ByteCount = 10;//设得大了些，其实IS只拦截了前面五字节，只要恢复前5字节就行。
ByteCount = 5;        //获取更改代码的个数，把原10改为5
PatchHighMemory(NtAddr,ByteCount);

//更改程序后，干掉冰刃就正常了
lkd> u nt!NtOpenProcess
nt!NtOpenProcess:
80574c96 68c4000000      push    0C4h
80574c9b 68b0a94e80      push    offset nt!ObReferenceObjectByPointer+0x127 (804ea9b0)

虽然象我以前那样改没明显情况，比如瞬秒等，但是引用别人的话“有可能获得错误的指令”。要解决问题的最好是找到如何修正重定位，现在我不大清楚，只知道是PE文件Data中的重定位那里获得些东西。这属于知识的缺陷，非常抱歉，向大家赔不是了。
错误原文出处：
http://hi.baidu.com/zoo%5F/blog/item/d61caf17e9fb3e0fc83d6d02.html

顶...
没看过，但崇敬作者的此次主动.

非常佩服和支持楼主的责任心，楼主加油啊！！

楼主是个很有责任感的人，值得学习！支持．

佩服，ColdZenLeft兄果然是驱动方面的高手，今后还要多多向你学习呢。

赞楼主

KeRaiseIrql 和 操作 CR0 的 WP bit 的 顺序反了， 同步问题！

我觉得应该不会是断链的问题。

因为 SSDT表的元素是存放的用户模式进入内核模式函数的地址，SSDT HOOK 只是修改了了这个地址，让用户模式中断进入内核的时候改变了函数的跳转方向，而多次HOOK以后函数的跳转流程虽然会出现你所说的那个链表的情况，但是SSDT修复的时候会自动重定向SSDT函数，所以跳转就绕过了后修改的驱动。举个例子

用户模式=>驱动A=>驱动B=>ntoskrnl.exe
这个时候如果驱动B重新修复SSDT则会出现

用户模式=>驱动B=>ntoskrnl.exe
直接就会忽略驱动A。

一个现实的例子，我以前写过的内核文章挂钩 NtOpenProcess 的时候就是多层的，因为我的防火墙本身防入注会挂钩这函数，杀软也是挂钩了这个函数，而我写的驱动也是挂钩这个函数，除非不按顺序卸载驱动才会出现你说的情况。蓝屏崩溃，因为这个时候相当于堆栈结构，高层驱动调用下层驱动的函数，如果中间断掉一个,调用则会被定位在一个不存在的地址造成崩溃。所以这个时候才会必须按顺序卸载，驱动中很多时候都是要求按顺序卸载这个很正常。

但是你说的情况不是以上的情况，所以应该不是这个问题。除非你设置开机自动启动服务，然后动态卸载，才可能出现。

哦不对，我也自我批斗下，上面说的不对，不按顺序卸载也不会出现蓝屏问题，以内卸载时候会恢复SSDT，这个时候SSDT被恢复为加载前的地址，如果多个驱动都修改了SSDT形成了链表结构

A-B-C-D-E-F

中间D卸载，则会出现，SSDT函数重新被定为在E的函数上，这时也不会蓝屏，不过A-B-C虽然没卸载，但是也已经不起作用了。应该会出现这个现象。开始脑子有点晕，想糊涂了。

嘿嘿！谢谢两位高人前辈陪我一起“捉虫”，今天才发现这个贴又转了过来，我才能回复。

看来一篇文章真要纠错还是很容易的，毕竟第一次写，而且驱动的东西都是在黑防的带领下才开始学。我嘛：菜是从来不否认的！

我才开始看夜岚的《内核进程守护》时，编程就出现过，当时机子上有金山毒霸。我只要一加载驱动就立刻死掉，必须先用IS还原NtOpenProcess。这就一直造成了我的错误概念，直到一个月前的课设，才发现自己肯定说错了。这个贴我是想了很久才写的，目前个人认为没什么大问题了。我看了xfill的第二个回复应该大概知道，其实我们的理解应该差不多。

事实上杀软就算关也不会卸驱动，我到现在还是没搞懂金山的鬼玩意，因为后来我们编的任务管理器怎么挂钩也不会挂机。没机会给我"蓝屏DUMP"研究了。。。

pixiebox大哥东西写得很好，最近看了相当受教育，你在文件方面的研究是很深入啊！你说的问题我记得当初好象在网上看的别人代码是这样写，后来查了下书和DDK文档用了这个中断优先级的函数。其实用不用中断优先级都可以改。你说的对！这个问题我一定会注意。不过改CR0一直不安全，现在用内存映射了