写在前面

此系列是本人一个字一个字码出来的，包括示例和实验截图。由于系统内核的复杂性，故可能有错误或者不全面的地方，如有错误，欢迎批评指正，本教程将会长期更新。 如有好的建议，欢迎反馈。码字不易，如果本篇文章有帮助你的，如有闲钱，可以打赏支持我的创作。如想转载，请把我的转载信息附在文章后面，并声明我的个人信息和本人博客地址即可，但必须事先通知我。

你如果是从中间插过来看的，请仔细阅读 羽夏看Win系统内核——简述 ，方便学习本教程。

看此教程之前，问一个问题，你明确学系统调用的目的了吗？ 没有的话就不要继续了，请重新学习 羽夏看Win系统内核——系统调用篇 里面的内容。

华丽的分割线

SSDT

SSDT的全称是System Services Descriptor Table，意为系统服务描述符表。在32位XP中，我们可以通过ETHREAD结构体加偏移的方式进行访问。在内核文件中，有一个变量是导出的：KeServiceDescriptorTable。通过它我们可以访问SSDT。

我们在WinDbg看一看SSDT是什么样子：

kd> dd KeServiceDescriptorTable
80553fa0  80502b8c 00000000 0000011c 80503000
80553fb0  00000000 00000000 00000000 00000000
80553fc0  00000000 00000000 00000000 00000000
80553fd0  00000000 00000000 00000000 00000000
80553fe0  00002730 bf80c0b6 00000000 00000000
80553ff0  bad6da80 ba0deb60 89c3e0f0 ba6bf8e8
80554000  00000000 00000000 00000000 00000000
80554010  0ceb6c40 01d7db79 00000000 00000000

SSDT有四个成员，每个成员都是一张系统服务表。根据系统服务表的结构，它有四个四字节的成员，第一个是函数地址表，第二个是调用次数，第三个是函数个数，最后一个是参数个数表，我们之前用过ReadProcessMemory做的实验，它的服务号是0xBA，我们做一下测试：

kd> dd 80502b8c+ba*4
80502e74  805aa712 805c99e0 8060ea76 8060c43c
80502e84  8056f0d2 8063ab56 8061aca8 8061d332
80502e94  8059b804 8059c7cc 8059c1d4 8059baee
80502ea4  805bf456 80598d62 8059908e 805bf264
80502eb4  806064b6 8051ee82 8061cc3e 805cbd40
80502ec4  805cbc22 8061cd3a 8061ce20 8061cf48
80502ed4  8059a07c 8060db50 8060db50 805c892a
80502ee4  8063d80e 8060be28 80607fb8 8060882a
kd> uf 805aa712
805aa712 6a1c            push    1Ch
805aa714 68d8a44d80      push    offset nt!MmClaimParameterAdjustDownTime+0x90 (804da4d8)
805aa719 e8f2e7f8ff      call    nt!_SEH_prolog (80538f10)
805aa71e 64a124010000    mov     eax,dword ptr fs:[00000124h]
805aa724 8bf8            mov     edi,eax
805aa726 8a8740010000    mov     al,byte ptr [edi+140h]
805aa72c 8845e0          mov     byte ptr [ebp-20h],al
805aa72f 8b7514          mov     esi,dword ptr [ebp+14h]
805aa732 84c0            test    al,al
805aa734 7466            je      nt!NtReadVirtualMemory+0x8a (805aa79c)  Branch

kd> db 80503000+ba
805030ba  14 04 08 0c 14 08 08 0c-08 10 14 08 04 08 0c 04  ................
805030ca  08 0c 0c 04 08 08 0c 0c-24 08 08 08 0c 04 08 04  ........$.......
805030da  10 08 04 04 04 14 14 10-10 10 10 10 10 08 14 18  ................
805030ea  04 04 10 0c 08 14 0c 0c-08 08 1c 0c 04 18 14 04  ................
805030fa  10 04 04 04 08 18 08 08-08 00 10 10 04 04 08 14  ................
8050310a  10 08 08 10 14 0c 04 04-24 24 18 14 00 10 0c 10  ........$$......
8050311a  10 00 00 00 00 00 cc cc-cc cc cc cc cc cc 0f 57  ...............W
8050312a  c0 b8 40 00 00 00 0f 2b-41 00 0f 2b 41 10 0f 2b  ..@....+A..+A..+

是不是逐个对应起来了？那么我们如何在驱动程序使用呢？我们只需要在驱动程序输入这行代码声明即可。

extern PKSERVICE_TABLE_DESCRIPTOR KeServiceDescriptorTable;

注意，PKSERVICE_TABLE_DESCRIPTOR是自己构造的系统服务表指针，结构体需要自行编写，我们来测试一下：

#include <ntddk.h>

extern ULONG KeServiceDescriptorTable;    //只是为了访问地址，就不写那个结构体了

NTSTATUS UnloadDriver(PDRIVER_OBJECT DriverObject)
{
    DbgPrint("卸载成功！！！");
}

NTSTATUS DriverEntry(PDRIVER_OBJECT DriverObject, PUNICODE_STRING RegistryPath)
{

    DriverObject->DriverUnload = UnloadDriver;

    DbgPrint("SSDT 的地址：%X", KeServiceDescriptorTable);
    return STATUS_SUCCESS;
}

演示效果如下：

如果你细心地发现，咱操作系统系统服务表不是用了两个吗？的确，但SSDT并没有导出与GUI相关的服务表。那么如何别的方式找到呢？接下来我们来介绍SSDTShadow。

SSDTShadow

SSDTShadow和SSDT不一样的是它并没有从内核文件导出。不过我们还是可以从WinDbg找到它：

kd> dd KeServiceDescriptorTableShadow
80553f60  80502b8c 00000000 0000011c 80503000
80553f70  bf999b80 00000000 0000029b bf99a890
80553f80  00000000 00000000 00000000 00000000
80553f90  00000000 00000000 00000000 00000000
80553fa0  80502b8c 00000000 0000011c 80503000
80553fb0  00000000 00000000 00000000 00000000
80553fc0  00000000 00000000 00000000 00000000
80553fd0  00000000 00000000 00000000 00000000

它的结构和SSDT是一模一样的，只不过它多了一张表，就是少的那个与GUI相关的服务表。那么我们能不能直接用驱动访问这张表呢？答案是不行，我们用WinDbg测试一下。

kd> dd bf999b80
ReadVirtual: bf999b80 not properly sign extended
bf999b80  ???????? ???????? ???????? ????????
bf999b90  ???????? ???????? ???????? ????????
bf999ba0  ???????? ???????? ???????? ????????
bf999bb0  ???????? ???????? ???????? ????????
bf999bc0  ???????? ???????? ???????? ????????
bf999bd0  ???????? ???????? ???????? ????????
bf999be0  ???????? ???????? ???????? ????????
bf999bf0  ???????? ???????? ???????? ????????

嘿嘿，是不是人傻了？根本看不到，是为什么呢？根据我们学过的段页的知识很容易地判断出没有挂物理页。并不是每一个应用程序都是有GUI，有的是后台没界面的。我们绑定一个GUI进程看一看：

kd> !process 0 0
**** NT ACTIVE PROCESS DUMP ****
（***省略无关进程***）

Failed to get VadRoot
PROCESS 89b28768  SessionId: 0  Cid: 06cc    Peb: 7ffd9000  ParentCid: 05d8
    DirBase: 157001a0  ObjectTable: e1d763f8  HandleCount:  44.
    Image: notepad.exe

kd> .process 89b28768
ReadVirtual: 89b28780 not properly sign extended
Implicit process is now 89b28768
WARNING: .cache forcedecodeuser is not enabled

kd> dd bf999b80
ReadVirtual: bf999b80 not properly sign extended
bf999b80  bf935f7e bf947b29 bf88ca52 bf93f6f0
bf999b90  bf949140 bf936212 bf9362b7 bf83b4cd
bf999ba0  bf948a67 bf934a17 bf94905f bf90f2f4
bf999bb0  bf902318 bf809fdf bf948f31 bf94a72d
bf999bc0  bf900c15 bf893b44 bf94900f bf94a860
bf999bd0  bf820f34 bf8dcb55 bf87a2e4 bf8c29a0
bf999be0  bf91052f bf80e2c5 bf8dc7fd bf94a525
bf999bf0  bf94b430 bf813a71 bf80cf90 bf8d14e4

是不是可以正常访问了？我们随便u一个试试：

kd> u bf935f7e
ReadVirtual: bf935f7e not properly sign extended
bf935f7e ??              ???
             ^ Memory access error in 'u bf935f7e'

发现不成功，并不代表每一个函数不行，我们再随便u一个试试：

kd> u bf949140
ReadVirtual: bf949140 not properly sign extended
bf949140 6a5c            push    5Ch
ReadVirtual: bf949150 not properly sign extended
bf949142 68804599bf      push    offset win32k!`string'+0x4dc (bf994580)
ReadVirtual: bf949152 not properly sign extended
bf949147 e8bc7aebff      call    win32k!_SEH_prolog (bf800c08)
bf94914c 33db            xor     ebx,ebx
bf94914e 43              inc     ebx
bf94914f 33f6            xor     esi,esi
bf949151 8975e4          mov     dword ptr [ebp-1Ch],esi
bf949154 39750c          cmp     dword ptr [ebp+0Ch],esi

SSDTShadow就介绍到这里了，感兴趣地自行继续研究。