[原创]逆向追踪win10 SSDT

战神伽罗

发布于 2019-07-24 15:30:48

1.8K0

发布于 2019-07-24 15:30:48

实际上我觉得这玩意就是个PE文件的导出表：

kd> u nt!ZwQuerySystemInformation
nt!ZwQuerySystemInformation:
81f82778 b89a000000      mov     eax,9Ah
81f8277d 8d542404        lea     edx,[esp+4]
81f82781 9c              pushfd
81f82782 6a08            push    8
81f82784 e8dc010100      call    nt!ExfUnblockPushLock+0x12c5 (81f92965)
81f82789 c21000          ret     10h
nt!ZwQuerySystemEnvironmentValueEx:
81f8278c b89b000000      mov     eax,9Bh
81f82791 8d542404        lea     edx,[esp+4]
kd> dd KeServiceDescriptorTable
820cf2c0  81f843b8 00000000 000001b9 81f84aa0
820cf2d0  00000000 00000000 00000000 00000000
820cf2e0  a3cd3fff 00000001 ffffffff 81f980f7
820cf2f0  00000000 00000000 00000001 00000000
820cf300  9084246c 01d435c6 00000000 00000000
820cf310  86140d80 82e89000 8603eaf8 00001000
820cf320  00010000 7ffeffff 80000000 83600000
820cf330  7fff0000 8296a000 8602c010 00001c1d
kd> dd 81f843b8
81f843b8  81eac66e 81ec934e 821a0d06 81e99a00
81f843c8  82114dca 82323a50 8218a016 8210e0a0
81f843d8  8223a612 8223a612 81f1b730 821c77e0
81f843e8  8232f409 821c7690 821a1064 822efc5c
81f843f8  82185fd4 8235cf90 8218cb92 821b7e32
81f84408  8218909e 821890c0 81f49620 82193298
81f84418  821767f8 8220a48a 8223a20a 822fe2b4
81f84428  82321564 82375032 81e91fd0 8211c150
kd> u 81eac66e 
nt!RtlLookupEntryHashTable+0xbe:
81eac66e 8bff            mov     edi,edi
81eac670 55              push    ebp
81eac671 8bec            mov     ebp,esp
81eac673 8b4d08          mov     ecx,dword ptr [ebp+8]
81eac676 33c0            xor     eax,eax
81eac678 50              push    eax
81eac679 ff7524          push    dword ptr [ebp+24h]
81eac67c 33d2            xor     edx,edx
kd> dd 81f84620    //9Ah*4+81f843b8
81f84620  8213d7b0 8220cf4e 823741af 82189160
81f84630  82375be1 82137e46 8213f6c0 821a8a9a
81f84640  822fb5ce 8223ac9e 8218c5c4 822da5fd
81f84650  822da3d9 82182e10 823780a5 821044c2
81f84660  82179f32 821d97a0 822fa322 821e9db6
81f84670  8219ff28 820728d3 81e7d36c 81e7d366
81f84680  8213f970 8210ff80 81e7d360 821bcd60
81f84690  8232388e 8215acac 821c9870 81e7d35a
kd> u 8213d7b0
nt!NtQuerySystemInformation:
8213d7b0 8bff            mov     edi,edi
8213d7b2 55              push    ebp
8213d7b3 8bec            mov     ebp,esp
8213d7b5 8b4d08          mov     ecx,dword ptr [ebp+8]
8213d7b8 83f94a          cmp     ecx,4Ah
8213d7bb 7c1c            jl      nt!NtQuerySystemInformation+0x29 (8213d7d9)
8213d7bd 83f953          cmp     ecx,53h
8213d7c0 7d17            jge     nt!NtQuerySystemInformation+0x29 (8213d7d9)


x64如下：
计算公式如下：
Ssdt为KeServiceDescriptorTable地址，Index为索引值
FunAddr =ssdt+(ssdt+4 * Index)>>4

0: kd> uf nt!zwopenprocess
Flow analysis was incomplete, some code may be missing
nt!ZwOpenProcess:
fffff802`7fd68370 488bc4          mov     rax,rsp
fffff802`7fd68373 fa              cli
fffff802`7fd68374 4883ec10        sub     rsp,10h
fffff802`7fd68378 50              push    rax
fffff802`7fd68379 9c              pushfq
fffff802`7fd6837a 6a10            push    10h
fffff802`7fd6837c 488d05fd600000  lea     rax,[nt!KiServiceLinkage (fffff802`7fd6e480)]
fffff802`7fd68383 50              push    rax
fffff802`7fd68384 b826000000      mov     eax,26h
fffff802`7fd68389 e9b2d50000      jmp     nt!KiServiceInternal (fffff802`7fd75940)  Branch
 
nt!KiServiceInternal:
fffff802`7fd75940 4883ec08        sub     rsp,8
fffff802`7fd75944 55              push    rbp
fffff802`7fd75945 4881ec58010000  sub     rsp,158h
fffff802`7fd7594c 488dac2480000000 lea     rbp,[rsp+80h]
fffff802`7fd75954 48899dc0000000  mov     qword ptr [rbp+0C0h],rbx
fffff802`7fd7595b 4889bdc8000000  mov     qword ptr [rbp+0C8h],rdi
fffff802`7fd75962 4889b5d0000000  mov     qword ptr [rbp+0D0h],rsi
fffff802`7fd75969 fb              sti
fffff802`7fd7596a 65488b1c2588010000 mov   rbx,qword ptr gs:[188h]
fffff802`7fd75973 0f0d8b90000000  prefetchw [rbx+90h]
fffff802`7fd7597a 0fb6bb32020000  movzx   edi,byte ptr [rbx+232h]
fffff802`7fd75981 40887da8        mov     byte ptr [rbp-58h],dil
fffff802`7fd75985 c6833202000000  mov     byte ptr [rbx+232h],0
fffff802`7fd7598c 4c8b9390000000  mov     r10,qword ptr [rbx+90h]
fffff802`7fd75993 4c8995b8000000  mov     qword ptr [rbp+0B8h],r10
fffff802`7fd7599a 4c8d1d4f010000  lea     r11,[nt!KiSystemServiceStart (fffff802`7fd75af0)]
fffff802`7fd759a1 41ffe3          jmp     r11
0: kd> dq KeServiceDescriptorTable
fffff802`7ffe0740  fffff802`7ff23020 00000000`00000000
fffff802`7ffe0750  00000000`000001b9 fffff802`7ff23dec
fffff802`7ffe0760  00000000`00000000 00000000`00000000
fffff802`7ffe0770  00000000`00000000 00000000`00000000
fffff802`7ffe0780  00000000`00000000 00000000`00000000
fffff802`7ffe0790  00000000`009c19c2 00007ffe`8dd556f0
fffff802`7ffe07a0  ffffe001`015763f0 ffffe001`01578c60
fffff802`7ffe07b0  00000000`00000000 00000000`00000000
0: kd> dd fffff802`7ff23020+98h    //26h*4=98h
fffff802`7ff230b8  0102d600 fdc03501 010bbc06 019ce7c7
fffff802`7ff230c8  0108c240 01a97f01 018e1600 03df8400
fffff802`7ff230d8  022720c5 014d4901 020bfe00 0211b180
fffff802`7ff230e8  01388e02 017a9b42 00f5f900 01d73707
fffff802`7ff230f8  01040800 02118100 03df6e41 0185b146
fffff802`7ff23108  02264f81 021a66c0 01450003 020cf900
fffff802`7ff23118  0208d000 0128e601 0216e140 019f3a02
fffff802`7ff23128  014d02c2 fe48c500 02460600 021eb2c1
0: kd> u fffff802`7ff23020+0102d60 //0102d600>>4=0102d60
nt!NtOpenProcess:
fffff802`80025d80 4883ec38        sub     rsp,38h
fffff802`80025d84 65488b042588010000 mov   rax,qword ptr gs:[188h]
fffff802`80025d8d 440fb69032020000 movzx   r10d,byte ptr [rax+232h]
fffff802`80025d95 4488542428      mov     byte ptr [rsp+28h],r10b
fffff802`80025d9a 4488542420      mov     byte ptr [rsp+20h],r10b
fffff802`80025d9f e80c000000      call    nt!PsOpenProcess (fffff802`80025db0)
fffff802`80025da4 4883c438        add     rsp,38h
fffff802`80025da8 c3              ret




测试修改SSDT后是否蓝屏（patch guard作用）：

0: kd> uf nt!ZwQuerySystemInformation
Flow analysis was incomplete, some code may be missing
nt!ZwQuerySystemInformation:
fffff802`c5fdc570 488bc4          mov     rax,rsp
fffff802`c5fdc573 fa              cli
fffff802`c5fdc574 4883ec10        sub     rsp,10h
fffff802`c5fdc578 50              push    rax
fffff802`c5fdc579 9c              pushfq
fffff802`c5fdc57a 6a10            push    10h
fffff802`c5fdc57c 488d05fd5e0000  lea     rax,[nt!KiServiceLinkage (fffff802`c5fe2480)]
fffff802`c5fdc583 50              push    rax
fffff802`c5fdc584 b836000000      mov     eax,36h
fffff802`c5fdc589 e9b2d30000      jmp     nt!KiServiceInternal (fffff802`c5fe9940)  Branch

nt!KiServiceInternal:
fffff802`c5fe9940 4883ec08        sub     rsp,8
fffff802`c5fe9944 55              push    rbp
fffff802`c5fe9945 4881ec58010000  sub     rsp,158h
fffff802`c5fe994c 488dac2480000000 lea     rbp,[rsp+80h]
fffff802`c5fe9954 48899dc0000000  mov     qword ptr [rbp+0C0h],rbx
fffff802`c5fe995b 4889bdc8000000  mov     qword ptr [rbp+0C8h],rdi
fffff802`c5fe9962 4889b5d0000000  mov     qword ptr [rbp+0D0h],rsi
fffff802`c5fe9969 fb              sti
fffff802`c5fe996a 65488b1c2588010000 mov   rbx,qword ptr gs:[188h]
fffff802`c5fe9973 0f0d8b90000000  prefetchw [rbx+90h]
fffff802`c5fe997a 0fb6bb32020000  movzx   edi,byte ptr [rbx+232h]
fffff802`c5fe9981 40887da8        mov     byte ptr [rbp-58h],dil
fffff802`c5fe9985 c6833202000000  mov     byte ptr [rbx+232h],0
fffff802`c5fe998c 4c8b9390000000  mov     r10,qword ptr [rbx+90h]
fffff802`c5fe9993 4c8995b8000000  mov     qword ptr [rbp+0B8h],r10
fffff802`c5fe999a 4c8d1d4f010000  lea     r11,[nt!KiSystemServiceStart (fffff802`c5fe9af0)]
fffff802`c5fe99a1 41ffe3          jmp     r11
0: kd> dq KeServiceDescriptorTable
fffff802`c6254740  fffff802`c6197020 00000000`00000000
fffff802`c6254750  00000000`000001b9 fffff802`c6197dec
fffff802`c6254760  00000000`00000000 00000000`00000000
fffff802`c6254770  00000000`00000000 00000000`00000000
fffff802`c6254780  00000000`00000000 00000000`00000000
fffff802`c6254790  00000000`009c19c2 00007ffb`8c4c56f0
fffff802`c62547a0  ffffe001`f0574360 ffffe001`f0576b00
fffff802`c62547b0  00000000`00000000 00000000`00000000
0: kd> dd fffff802`c6197020+d8h
fffff802`c61970f8  01040800 02118100 03df6e41 0185b146
fffff802`c6197108  02264f81 021a66c0 01450003 020cf900
fffff802`c6197118  0208d000 0128e601 0216e140 019f3a02
fffff802`c6197128  014d02c2 fe48c500 02460600 021eb2c1
fffff802`c6197138  fd030300 03e74980 0102c301 01d6c501
fffff802`c6197148  01409e03 02247680 01ef4780 02355305
fffff802`c6197158  03aeda84 016b01c0 010ceb01 021fdd81
fffff802`c6197168  012f6580 012e8240 038ee042 017aa207
0: kd> u fffff802`c6197020+0104080
nt!NtQuerySystemInformation:
fffff802`c629b0a0 4883ec38        sub     rsp,38h
fffff802`c629b0a4 458bd0          mov     r10d,r8d
fffff802`c629b0a7 4c8bda          mov     r11,rdx
fffff802`c629b0aa 83f94a          cmp     ecx,4Ah
fffff802`c629b0ad 7c21            jl      nt!NtQuerySystemInformation+0x30 (fffff802`c629b0d0)
fffff802`c629b0af 83f953          cmp     ecx,53h
fffff802`c629b0b2 7d1c            jge     nt!NtQuerySystemInformation+0x30 (fffff802`c629b0d0)
fffff802`c629b0b4 33d2            xor     edx,edx
0: kd> ed fffff802`c61970f8 02118100
0: kd> dd fffff802`c61970f8
fffff802`c61970f8  02118100 02118100 03df6e41 0185b146
fffff802`c6197108  02264f81 021a66c0 01450003 020cf900
fffff802`c6197118  0208d000 0128e601 0216e140 019f3a02
fffff802`c6197128  014d02c2 fe48c500 02460600 021eb2c1
fffff802`c6197138  fd030300 03e74980 0102c301 01d6c501
fffff802`c6197148  01409e03 02247680 01ef4780 02355305
fffff802`c6197158  03aeda84 016b01c0 010ceb01 021fdd81
fffff802`c6197168  012f6580 012e8240 038ee042 017aa207
0: kd> g

开调试可以关patch guard，因为int3会修改内核，如果pg还发挥作用就会蓝屏，没法调试了，所以调试即可关pg。bat代码如下：

Bcdedit /debug ON
Bcdedit /dbgsettings SERIAL DEBUGPORT:1 BAUDRATE:115200 /start AUTOENABLE /noumex

以下是转载：

1、利用NEWBLUEPILL进入VT创建 HYPERVISOR 2、对你希望关心的系统服务函数下硬件断点 3、HYPERVISOR捕获到INT1异常以后你就可以判断是否放行或者不放行了 4、HYPERVISOR处理完以后vmresume以后一定要记得清除RFLAG单步标志位 5、HYPERVISOR注意不要向操作系统注入INT1异常且HYPERVISOR一定要拒绝其他代码修改DR调试寄存器

0x00 Hook技术

hook技术分为两块：

Ring3层的Hook，俗称应用层hook技术
Ring0层的Hook，俗称内核层Hook技术

Ring3层的hook又分为两种类型

Windows消息的hook
WindowsAPI的hook

如下图所示：

hook1

hook2

hook1

关于Windows消息的Hook，相信很多朋友都有接触过的，因为一个SetWindowsHookEx即可以完成消息 Hook,在这里简要介绍一下消息 Hook，消息 Hook 是通过SetWindowsHookEx可以实现将自己的钩子插入到钩子链的最前端，而对于发送给被 Hook 的窗口(也有可能是所有的窗口，即全局 Hook)的消息都会被我们的钩子处理函数所捕获到，也就是我们可以优先于窗体先捕获到这些消息，Windows 消息 Hook 可以实现为进程内消息 Hook 和全局消息 Hook，对于进程内消息 Hook，则可以简单的将 Hook 处理函数直接写在这个进程内，即是自己 Hook 自己，而对于用途更为广泛的全局消息 Hook，则需要将 Hook 处理函数写在一个 DLL 中，这样才可以让你的处理函数被所有的进程所加载(进程自动加载包含 Hook 消息处理函数的 DLL)。

对于 Windows 消息 Hook 呢，可以有个简单的邪恶应用，就是记录键盘按键消息，从而达到监视用户输入的键值信息的目的，这样，对于一些简单的用户通过键盘输入的密码就可以被 Hook 获取到，因为没当用户按下一个键时，Windows 都会产生一个按键消息(当然有按下，弹起等消息的区分)，然后我们可以 Hook 到这个按键消息，这样就可以在 Hook 的消息处理函数中获取到用户按下的是什么键了。

不过消息的hook不是本文的重点。

本文要讲的SSDT hook呢其实是属于内核Hook，常见于病毒以及杀软中。

下图展示了内核hook的几个基本类型。

Kernel hook

0x01 SSDT简介

SSDT全称System Service Descriptor Table(系统描述符表)，这个表用于将Ring3的Win32API和内核的API联系起来。

SSDT并不仅仅只包含一个庞大的地址索引表，它还包含一些有用的信息，如地址索引的基地址，服务函数的个数等。通过修改此表可以达到对一些关心的系统动作进行过滤以及监控的目的。

在NT4.0的windows操作系统中，默认存在两个系统服务描述符表，这两个描述符表对应了两类不同的系统服务，这两个表为：KeServiceDescriptorTable(SSDT)和KeServiceDescriptorTable(SSDT Shadow)。其中SSDT负责处理来自Ring3层的Kernel32.dll的系统调用。而SSDT Shadow则主要处理来自User32.dll和GDI32.dll的系统调用。同时SSDT在ntoskrnl.exe中是导出的，而SSDT Shadow如其名是未被Windows所导出的，而关于SSDT的全部内容都是通KeServiceDescriptorTable来完成的。

以下截图说明，KeServiceDescriptorTable是在ntoskrnl.exe中被导出的：

Export1

随后我们看看看看Windows操作系统的源码中如何定义KeServiceDescriptorTable的，通过观察WRK可知，

KeServiceDescriptorTable in WRK

这么看还是有点蛋疼啊。改写以下变量的名称吧。

    typedef struct _KSYSTEM_SERVICE_TABLE{
        PULONG ServiceTableBase;            //SSDT的基地址指针
        PULONG ServiceCounterTableBase; //SSDT中每个服务被调用次数表的基地址指针
        ULONG NumberOfService;              //服务函数个数，NumberOfService*4就是整个地址表的大小
        ULONG ParamTableBase;               //SSPT的基地址
    }KSYSTEM_SERVICE_TABLE,*PKSYSTEM_SERVICE_TABLE;
    typedef struct _KSERVICE_TABLE_DESCRIPTOR{
        KSYSTEM_SERVICE_TABLE ntoskrnl;     //ntoskrnl.exe的服务函数
        KSYSTEM_SERVICE_TABLE win32k;       //win32k.sys的服务函数(GDI32/User32)
        KSYSTEM_SERVICE_TABLE notUsed1;
        KSYSTEM_SERVICE_TABLE notUsed2；
    }KSERVICE_TABLE_DESCRIPTOR,*PKSERVICE_TABLE_DESCRIPTOR;
    //导出由ntoskrnl.exe所导出的SSDT
    extern PKSERVICE_TABLE_DESCRIPTOR KeServiceDescriptorTable;

从上述介绍可知，KeServiceDescriptorTable可以看做是一个数组，是4个KSYSTEM_SERVICE_TABLE结构形成的数组，而每个KSYSTEM_SERVICE_TABLE对应一个PE文件导出的服务描述符表，根据这些服务描述符表我们可以获得更加详细的服务信息。在应用层ntdll.dll中的API在这个系统服务描述表中都存在一个与之对应的服务，当我们的应用程序调用ntdll.dll里的API时最终可以调用对应的系统服务函数，通知给内核一个索引，内核通过该索引在SSDT中查找对应的服务，内核调用服务完成应用的API调用请求。

应用层调用Win32API流程

有了以上的SSDT基础后，我们再来看看在应用层调用Win32API（主要指ntdll.dll中的API）的流程，我们主要针对ntdll.dll中的NtQuerySystemInformation这个API的调用流程来进行阐述。

这里存在四个类似的API。

4APIs

再给出这些API的调用流程。

calling way

这里我们可以看到ntdll.dll中的nt和zw都会进入内核层去调用ntoskrnl的zw函数，而zw最终会调用nt函数，这个函数作为内核API最终去请求系统服务的执行。用exescope工具可以打开ntdll.dll，看到NtQuerySystemInformation以及ZwQuerySystemInformation。

ntdll1

ntdll2

而实质上zw和nt都是同一函数，指向同一区域，入口地址相同。

因此Ntdll.dll中的API都是对内核API的封装，当Kernel32.dll中的API通过Ntdll.dll去调用系统API时，会进行参数检查，并调用中断（int 2Eh或SysEnter），从而从Ring3进入Ring0，并将所要调用的服务号，即SSDT数组的索引值，存放进寄存器EAX中，并且将参数地址放到指定的寄存器EDX中，再复制参数到内核地址空间，根据存放在EAX中的索引值来在SSDT数组中调用指定的服务。

经过上面步骤我们来到Ring0层。使用exescope看看ntoskrnl.exe中的ZwQuerySystemInformation以及NtQuerySystemInformation。

ntoskrnl1

ntoskrnl2

再反汇编ntoskrnl这个文件可以看到Zw函数中调用KiSystemService系统服务分发函数时往EAX中存放了索引号ADh。如图：

ZwQSystemInfor

随后根据该索引值检索SSDT项，最后根据该SSDT项中所存放的系统服务地址来调用这个系统服务。在这里就是调用KeServiceDescriptorTable[ADh]处保存的地址对应的系统服务。那就是Ring0下的NtQuerySystemInformation。

0x02 详解SSDT

这节内我们用WinDbg来调试XP系统，借此说明SSDT是个什么鬼。据我们上文的结构定义可知，KeServiceDescriptorTable是一个指向4个KSYSTEM_SERVICE_TABLE结构首地址的指针，以下图为例吧。

dd KeServiceDescriptorTable

这里的0x80563520这一行就是ntoskrnl对应的服务描述符表结构KSYSTEM_SERVICE_TABLE。那么第一个32位的0x804e58a0则是对应ntoskrnl对应的KSYSTEM_SERVICE_TABLE中的SSDT Base，即服务描述符表的首地址。通过对该首地址的dump，我们可以看到许多以128位为一组排列的服务描述符，每个描述符中的第一个32位（0x80591bfb）对应着系统服务的入口地址。通过对该入口地址的反汇编，可以看到这是SSDT第一个系统服务NtAcceptConnectPort函数。如图：

NtAcceptConnectPort

那么知道了SSDT首地址，同时知道了索引，那么我们就可以通过索引来找到对应的系统服务入口地址了。通过计算“SSDT中系统服务地址所在的地址 = SSDT首地址 + 4 * 索引值”，可以推算出NtQuerySystemInformation的起始地址位0x80586ff1，对该地址进行反汇编，可得下图：

NtQuerySystemInformation

由此可知，SSDT就是个保存Windows系统服务地址的数组。