------- 软件调试——注销 QQ 过滤驱动设置的事件通知 CallBack (完)-------
——————————————————————————————————————————————————————————————————————————————————
本系列的最后一篇演示如何通过调试手段摘除 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 的行为模式仍旧是必要的!
————————————————————————————————————————————————————————
posted on 2018-02-13 01:03 f1yin9_0x5hark 阅读(1301) 评论(1) 编辑 收藏 举报