——————————————————————————————————————————————————————————————————————————————————
本系列的最后一篇演示如何通过调试手段摘除 QQ 过滤驱动设置的事件通知 CallBack。
内核中有几个全局的数组用来存放这些事件通知 CallBack 的指针，第一个就是 nt!PspCreateProcessNotifyRoutine，
当有进程被创建时，该数组中的函数指针就会依次被调用，与此类似，当有线程被创建时，nt!PspCreateThreadNotifyRoutine
数组中的函数指针就被调用；nt!PspLoadImageNotifyRoutine 中的回调则是在有内核模块加载时被调用。
驱动程序通过向这些数组中加入 CallBack 指针，就能够监控相应的事件。
首先来看下哪些驱动程序正在监控系统范围的进程创建事件：
1 r @$t0=poi(nt!PspCreateProcessNotifyRoutineCount); 2 r @$t1=nt!PspCreateProcessNotifyRoutine; 3 .for(r @$t2=0; @$t2<@$t0; r @$t2=@$t2+1){dds (poi(@$t1+@$t2*4)^7)+4 l1;}
从上图您可以看到，QQFrmMgr.sys 中有一个例程正在监视着进程创建事件。除此之外的其它内核模块都是合法的，比如
“avkmgr”与“avdevprot”是安装德国小红伞反病毒软件时，附带安装的两个内核模式驱动程序，它们注册了各自的回调在
监控着进程创建事件，这是实现 Real-Time Protection 用到的系统底层机制之一；“tcpip”不用我说各位也知道，它是
Windows 内核网络栈的主要实现模块之一：
注意，系统最多支持注册 8 枚事件回调指针，nt!PspCreateProcessNotifyRoutineCount 存储当前注册的回调指针数量，如下图，
这个全局变量的值与第一张图片中的事件回调指针枚数一致：
现在，我们尝试从中摘除 QQFrmMgr.sys 的监控例程：
使用类似的手段，检查 QQFrmMgr.sys 有没有监控线程创建与内核模块加载事件：
1 r @$t0=poi(nt!PspCreateThreadNotifyRoutineCount); 2 r @$t1=nt!PspCreateThreadNotifyRoutine; 3 .for(r @$t2=0; @$t2<@$t0; r @$t2=@$t2+1){dds (poi(@$t1+@$t2*4)^7)+4 l1;} 4 5 6 7 8 r @$t0=poi(nt!PspLoadImageNotifyRoutineCount); 9 r @$t1=nt!PspLoadImageNotifyRoutine; 10 .for(r @$t2=0; @$t2<@$t0; r @$t2=@$t2+1){dds (poi(@$t1+@$t2*4)^7)+4 l1;}
您看，这家伙监控的地方还真不少，为的就是保护它自己免受其它恶意软件攻击！或许你会好奇：图中的“XLGuard”是啥东
东？
它就是在安装“迅雷”（一种基于 BitTorrent 协议的 P2P 下载/分享软件）时，一并安装的内核模式驱动程序之一，如下图：
从名称中的“Guard”来看，应该也是用来保护迅雷自身组件的——现在的软件都比女性还懂得怎么保护自己呢！
你可以使用前述的方法来阻止 QQFrmMgr.sys 监控线程创建与内核模块加载事件——就布置成家庭作业吧！
———————————————————————————————————————————————————
写到这里，本系列算是大致功德圆满了。。。。还记得上一篇我抱怨说“!chkimg”调试器扩展命令不能用吗？
折腾的这几天总算找出问题所在了——从 MSDN 网站下载的 Windows 7 零售版符号包中的 ntoskrnl.exe 版本问题——我听信
该站点的建议下载了 Windows 7 Service Pack 1 x86 零售符号，结果其中的 ntoskrnl.exe 内核映像版本被最新版的
WinDbg 排斥，所以我换用了 Windows 8.1 x86 32 位零售符号，以便双机物理调试环境中检查目标机器上的 Windows 8.1
内核工作情况，也证实了 QQ 驱动没有采取反虚拟机技术，它的行为模式与在真实机器上的表现一致（至少在写作本文的时间点上
是如此，以后就难说了，搞不好也会引入反调试技术。。。），如下图：
最后贴上在 32 位 Windows 8.1 上利用“!chkimg”自动检查并恢复 SSDT 的过程，以飨读者：
NND，为啥前面手工检查 SSDT 能够发现的 QQ hooks，通过“!chkimg”自动检查却探测不到，只识别了 inline hook ？
阅读一下该扩展命令的官方文档，原来是需要指定一个特殊的选项：
正如图中红框部分所讲的那样：Hal.dll 与 Ntoskrnl.exe 中的某些特定地址不会被检查，因为当这些部分被载入时，会发生某些改变。
包含 -nospec 选项则可以检查这些地址。事实上，这就是我在前一篇谈到的——每次系统启动时都随机创建 SSDT 的基址，所以
“!chkimg”就忽略了这些“随机”的部分，偏偏给 QQ 驱动留下了可乘之机。。。。添加 -nospec 选项后，我们成功地
分析出 SSDT 中的所有 hooks，下面我仅截取了输出的前三个 hooks，它们对应于前面有一张“dps”命令解析图中的三个 hooks：
以上图中的黄框部分为例，第一个 hook 是从 8151b3a8 到 8151b3aa 的三个字节修改；冒号左边是磁盘文件中的原始字节
序列，冒号右边是内存映像中的已修改字节序列，该项 hook 距离 nt!KiServiceTable 起始地址的偏移量为 0xC。
让我们看看前三个 hook 的受害例程（原始系统服务）是什么？
原来 QQFrmMgr.sys hook 了 NtWriteVirtualMemory()（写入任意进程的虚拟内存）、NtUnmapViewOfSection()（取消
映射 section 的视图；Windows 内存管理器中用来实现共享内存和映射文件的底层原语就叫做 "section 对象" ；合法的驱动
程序程序应该仅使用 ZwOpenSection()，ZwMapViewOfSection()，以及 ZwUnmapViewOfSection() 等函数操纵 section
对象；于是 hook 该系统服务的用意在于监视映射文件与查看其中部分内容的请求）、
以及 NtTerminateProcess()（终止进程），这与我前一篇的手工分析一致。
最后，让我们用“!chkimg”的“-f”开关，自动修正内存映像中的错误：
————————————————————————————————————————————————————————
小结：本篇讨论了摘除恶意事件通知回调函数的相关技巧，并演示自动修复关键系统设施的方法，文中介绍的调试技术只是
内核攻防中的冰山一角，而且这些方法随着内核与恶意软件的不断进化也正面临着挑战！
持续研究与探索不同内核驱动/rootkit 的行为模式仍旧是必要的！
————————————————————————————————————————————————————————