Tersafe.sys的Tricky

使用RootKit Unhooker可以很容易的发现Tersafe.sys对Shadow Service Descriptor Table进行了HOOK，但基本上是静态HOOK，即在Tersafe.Sys启动的时候会替换Shadow table中对应的原始System Service，主要是如下几个函数：NtGdiSetVirtualResource、NtUserSetClipboardData、NtUserQueryWindow、NtUserGetDC、NtUserGetDCEx、UserBuildHwndList、NtUserExcludeUpdateRgn、NtUserGetForegroundWindow、NtUserWindowFromPoint等Win32K.Sys导出的系统服务。替换成Tersafe.sys相应的服务； 网上有相关的资料是解决这个tricky的，在应用层，用户就可以FindWindow，GetWindowThreadProcessById等函数来获得进程ID号。 但依然无法使用OpenProcess打开进程。 打开Windbg，进入本地（Local）的Kernel Debug； lkd> x nt!NtOpenProcess 805cc408 nt!NtOpenProcess = 然后 lkd> u nt!NtOpenProcess nt!NtOpenProcess: 805cc408 68c4000000 push 0xc4 805cc40d e9c4415e3a jmp babb05d6 //这里很明显被Inline HOOK， 805cc412 e87907f7ff call nt!_SEH_prolog (8053cb90) 805cc417 33f6 xor esi,esi 805cc419 8975d4 mov [ebp-0x2c],esi 805cc41c 33c0 xor eax,eax 805cc41e 8d7dd8 lea edi,[ebp-0x28] 805cc421 ab stosd 由于卡巴斯基也会静态HOOK这个处理，所以基本上可以肯定这个就是tersafe.sys偷偷摸摸干的事情。 这就需要首先获得最原始的byte code，然后在等tersafe.sys启动后，将其恢复，当然了，这还要检查tersafe.sys会不会动态监测这个INLINE HOOK，明天继续。 经过仔细测试805cc40d e9c4415e3a jmp babb05d6 //这里很明显被Inline HOOK， 这里其实是RKU下的钩子。 但是我想写个程序将其恢复，可惜很遗憾，好不容易经过大半天的copy 粘贴代码之后，编译。加载测试程序之后，就BSOD了。 再次启动系统后，鼠标不见了。USB端口也不见了，无线网卡也没有了。打开设备管理器，发现这些设备都打上了红叉。 仔细比对后发现是卡巴斯基的某些驱动被我在Autoruns.exe delete掉了。导致这些驱动没能被正确加载。 卡巴也太霸道了，它几乎接管了系统的所有大部分驱动层，难怪OS加载如此之慢。这太过分了，Windows其实并不见得技术有多高深，但是最复杂的是它是个庞大的系统，对于其核心层，其实高手们也只是某一方面的高手。这种几乎对所有设备驱动层下钩子的做法，对OS的性能，稳定性都有极高的挑战。 我不否认卡巴有一定的技术水平，但似乎有点过头了。总有一天我也会将其彻底干净的清除出系统。