------- 软件调试——注销 QQ 过滤驱动设置的事件通知 CallBack （完）-------

——————————————————————————————————————————————————————————————————————————————————

本系列的最后一篇演示如何通过调试手段摘除 QQ 过滤驱动设置的事件通知 CallBack。

内核中有几个全局的数组用来存放这些事件通知 CallBack 的指针，第一个就是 nt!PspCreateProcessNotifyRoutine，

当有进程被创建时，该数组中的函数指针就会依次被调用，与此类似，当有线程被创建时，nt!PspCreateThreadNotifyRoutine

数组中的函数指针就被调用；nt!PspLoadImageNotifyRoutine 中的回调则是在有内核模块加载时被调用。

驱动程序通过向这些数组中加入 CallBack 指针，就能够监控相应的事件。

首先来看下哪些驱动程序正在监控系统范围的进程创建事件：

 r @$t0=poi(nt!PspCreateProcessNotifyRoutineCount);
 r @$t1=nt!PspCreateProcessNotifyRoutine;
 .for(r @$t2=; @$t2<@$t0; r @$t2=@$t2+){dds (poi(@$t1+@$t2*)^)+ l1;}

从上图您可以看到，QQFrmMgr.sys 中有一个例程正在监视着进程创建事件。除此之外的其它内核模块都是合法的，比如

“avkmgr”与“avdevprot”是安装德国小红伞反病毒软件时，附带安装的两个内核模式驱动程序，它们注册了各自的回调在

监控着进程创建事件，这是实现 Real-Time Protection 用到的系统底层机制之一；“tcpip”不用我说各位也知道，它是

Windows 内核网络栈的主要实现模块之一：

注意，系统最多支持注册 8 枚事件回调指针，nt!PspCreateProcessNotifyRoutineCount 存储当前注册的回调指针数量，如下图，

这个全局变量的值与第一张图片中的事件回调指针枚数一致：

现在，我们尝试从中摘除 QQFrmMgr.sys 的监控例程：

使用类似的手段，检查 QQFrmMgr.sys 有没有监控线程创建与内核模块加载事件：

 r @$t0=poi(nt!PspCreateThreadNotifyRoutineCount);
 r @$t1=nt!PspCreateThreadNotifyRoutine;
 .for(r @$t2=; @$t2<@$t0; r @$t2=@$t2+){dds (poi(@$t1+@$t2*)^)+ l1;}

 r @$t0=poi(nt!PspLoadImageNotifyRoutineCount);
 r @$t1=nt!PspLoadImageNotifyRoutine;
 .for(r @$t2=; @$t2<@$t0; r @$t2=@$t2+){dds (poi(@$t1+@$t2*)^)+ 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 的行为模式仍旧是必要的！
————————————————————————————————————————————————————————