360安全卫士hookport.sys简单逆向——KiFastCallEntry挂钩

KiFastCallEntry的挂钩

         360安全卫士并没有使用通常的方式——直接修改SSDT和SSDTShadow进行挂钩。由于两个表中的函数最终是由系统未导出的函数KiFastCallEntry调用的，所以360在适当的位置挂载了KiFastCallEntry函数，达到了过滤的目的。大多数ARK软件只检测了两个表是否被更改，所以不能检测出360的HOOK。

         上面介绍的MyHookMgr结构之所以占据近6K的连续内存空间，是因为KiFastCallEntry是一个频繁被系统调用的函数，所以钩子的效率十分重要，使用连续的空间可以节省出大量寻址时间，是一种空间换时间的做法。

KiFastCallEntry内存地址的确定

         KiFastCallEntry并没有被系统模块导出，360采取了一个比较巧妙的方法简介获得其地址。

1.       常规方法挂 载ZwSetEvent函数，代理函数为hookprot.sys模块中的_HookKiFastCallEntryKnrl。

2.       之后马上调 用ZwSetEvent函数。

可以看到这里的handle为0x288C58F1，显然是一个不合法的句柄。这里起到一个标志，所用，我们的_HookKiFastCallEntryKnrl函数看到这个handle就会做一些特殊处理来寻找KiFastCallEntry的地址啦。

1.       然后会跳转 到_HookKiFastCallEntryKnrl中，如果句柄是0x288C58F1则恢复刚才的SSDT钩子。并对KiFastCallEntry进行挂载。

由于_HookKiFastCallEntryKnrl是KiFastCallEntry调用的，所以我们可以从栈针中找到的返回地址也就是KiFastCallEntry所在了。

代码只需要一句 mov eax, [ebp+4] 就可以了。

KiFastCallEntry的挂载

KiFastCallEntry是一个非常复杂的函数，挂载位置很重要。

我们对比一下360安全卫士挂载前和挂载后的函数。

挂载前：

8053d7dc ff0538f6dfff    inc     dword ptr ds:[0FFDFF638h]
8053d7e2 8bf2            mov     esi,edx
8053d7e4 8b5f0c          mov     ebx,dword ptr [edi+0Ch]
8053d7e7 33c9            xor     ecx,ecx
8053d7e9 8a0c18          mov     cl,byte ptr [eax+ebx]
8053d7ec 8b3f            mov     edi,dword ptr [edi]
8053d7ee 8b1c87          mov     ebx,dword ptr [edi+eax*4]
8053d7f1 2be1            sub     esp,ecx
8053d7f3 c1e902          shr     ecx,2
8053d7f6 8bfc            mov     edi,esp
8053d7f8 3b35b48b5580    cmp     esi,dword ptr [nt!MmUserProbeAddress (80558bb4)]
8053d7fe 0f83a8010000    jae     nt!KiSystemCallExit2+0x9f (8053d9ac)
8053d804 f3a5            rep movs dword ptr es:[edi],dword ptr [esi]
8053d806 ffd3            call    ebx
8053d808 8be5            mov     esp,ebp
8053d80a 8b0d24f1dfff    mov     ecx,dword ptr ds:[0FFDFF124h]

挂载后：

8053d7dc ff0538f6dfff    inc     dword ptr ds:[0FFDFF638h]
8053d7e2 8bf2            mov     esi,edx
8053d7e4 8b5f0c          mov     ebx,dword ptr [edi+0Ch]
8053d7e7 33c9            xor     ecx,ecx
8053d7e9 8a0c18          mov     cl,byte ptr [eax+ebx]
8053d7ec 8b3f            mov     edi,dword ptr [edi]
8053d7ee 8b1c87          mov     ebx,dword ptr [edi+eax*4]
8053d7f1 e93289ca01      jmp     821e6128
8053d7f6 8bfc            mov     edi,esp
8053d7f8 3b35b48b5580    cmp     esi,dword ptr [nt!MmUserProbeAddress (80558bb4)]
8053d7fe 0f83a8010000    jae     nt!KiSystemCallExit2+0x9f (8053d9ac)
8053d804 f3a5            rep movs dword ptr es:[edi],dword ptr [esi]
8053d806 ffd3            call    ebx
8053d808 8be5            mov     esp,ebp
8053d80a 8b0d24f1dfff    mov     ecx,dword ptr ds:[0FFDFF124h]
8053d810 8b553c          mov     edx,dword ptr [ebp+3Ch]

根据WRK的代码我们知道，这时所有调用需要的环境都已经准备好了。360这里替换了

8053d7f1 2be1            sub     esp,ecx

8053d7f3 c1e902          shr     ecx,2

这两条指令，实现了jmp，将这两条指令放到Hook后的函数中处理，这里就不详细叙述了。IDB文件中有比较详细的注释。