过DNF TP 驱动保护2

Hook，从而使得 DNF 游戏进程不能被附加，这样的话，咱的 OD 或者 Visual Studio 都是不能够附加上 DNF 的游戏进程来进行调试了。正如前面分析的 NtReadVirtualMemory 和 NtWriteVirtualMemory 这两个 API 一样，TP 对 KiAttachProcess 也是做的浅层的 InLine Hook，也就是只是 Hook 了函数头 7 个字节，且 TP 对 KiAttachProcess 的 InLine Hook 也没有检测，所以干掉这个 API 还是比较简单的，不过我们不可以像干掉 NtRead/WriteVirtualMemory 一样用 SSDT Hook 来对抗掉，因为 KiAttachProcess 并没有在 SSDT 表中，不过我们可以直接恢复 TP 对 KiAttachProcess 的 Hook 即可。前面也提到了 KiAttachProcess 是一个未导出的内核 API，所以我们不能使用

MmGetSystemRoutineAddress

来获得它的地址，不过好在 KeAttachProcess 这是一个导出的内核 API， (一般 Kixxx 都是未导出的 API，而 Kexxx 则是导出的 API)

在 KeAttachProcess 的内部实质上是调用的 KiAttachProcess 来完成功能的，所以咱可以通过 KeAttachProcess 来定位到 KiAttachProcess 的地址，并且让人欣喜的是在 KeAttachProcess 中的第一个 call 就是 call KiAttachProcess，所以搜索特征码也更加简单了，直接搜索第一个 e8 就 OK。如果用 WinDbg 的话，你可以输几个命令就可以把 KeAttachProcess 的地址打印出来，但是现在咱走点弯路，在驱动里面用 KdPrint 打印出 KeAttachProcess 的地址，然后我们再分析。

1: KdPrint((\

好，这里得到了 KeAttachProcess 的地址了，

那么咱就可以在 Kernel Detective 中来看看 KeAttachProcess 的反汇编代码了， 具体的就看图说话，俺也就不多说了，因为截图里面都明明白白摆着在哪里，

下面给出获取 KiAttachProcess 地址的代码： 1:

/************************************************************************/ 2: /* 获取函数 KiAttachProcess 的地址

3: /* KiAttachProcess 在 KeAttachProcess 中的第一个 Call(e8 指令) 位置 4:

/************************************************************************/

5: ULONG GetKiAttachProcessAddr() 6: {

7: ULONG uCallAddr = 0;

8: ULONG uKeAttachProcessAddr = 0;

9: ULONG uKiAttachProcessAddr = 0; 10: CHAR szCode[1] = 11: {

12: (char)0xe8 13: };

14:

15: /* 获取 KeAttachProcess 的地址 */

16: uKeAttachProcessAddr = MmGetSystemFunAddress(L\ 17:

18: /* 搜索特征码 e8 */

19: uCallAddr = SearchFeature(uKeAttachProcessAddr, szCode, 1); 20: if (uCallAddr == 0) 21: {

22: uKiAttachProcessAddr = 0; 23: } 24: else

25: {

26: /* 获取 KiAttachProcess 的地址 */

27: uKiAttachProcessAddr = *((ULONG *)uCallAddr) + uCallAddr + 4; 28: }

29:

30: return uKiAttachProcessAddr;

31: }

得到了 KiAttachProcess 的地址，那么下面就要来干掉 KiAttachProcess 了，为了简单实现，我一开始干掉 KiAttachProcess 的做法是采用的硬编码，在得到 KiAttachProcess 地址后，可以用 Xuetr 来反汇编这个地址，从而看到 KiAttachProcess 的反汇编指令，所以我的做法就是，直接将 Xuetr 中 KiAttachProcess 的头 7 个字节以硬编码的形式保存在数组中，然后等 TP 启动后，我用保存下来的这 7 个字节直接去恢复 KiAttachProcess 就 OK， 这种方式在我的虚拟机 XP 里面是 OK 的，因为我就是从这台 XP 上获取的 7 个字节的硬编码，但是在别的 XP 系统上就不 OK 了，原因是 KiAttachProcess 头 7 个字节并不是所有的 XP 都相同的，直接拿不一致的硬编码去恢复肯定是会 BSOD 的，不过后来我用了一种简单的办法就干掉这个问题了，办法很简单，在 TP 启动之前，我动态去读取 KiAttachProcess 的头 7 个字节，并且保存在数组中，等 TP 启动后，我就用数组中的这 7 个字节去恢复 TP 对 KiAttachProcess 所做的 InLine Hook。 实现的具体代码很简单，下面也贴出来：

先在 TP 启动之前保存 KiAttachProcess 的头 7 个字节：

1: PUCHAR pKiAttachProcessAddr = NULL; 2:

3: pKiAttachProcessAddr = (PUCHAR)GetKiAttachProcessAddr();