KiServiceTable其实是KeServiceDescriptorTable的关键部分。。。

KeServiceDescriptorTable 这个结构中包含了4个KiServiceTable。
通常用到的是第一个。楼主可以看看下面的定义

typedef struct _SERVICE_DESCRIPTOR_TABLE
{
    SYSTEM_SERVICE_TABLE ntoskrnel;    //ntoskrnl.exe的服务函数
    SYSTEM_SERVICE_TABLE win32k;    //win32k.sys的服务函数,(gdi.dll/user.dll的内核支持)
    SYSTEM_SERVICE_TABLE NotUsed1;
    SYSTEM_SERVICE_TABLE NotUsed2;
}SYSTEM_DESCRIPTOR_TABLE,*PSYSTEM_DESCRIPTOR_TABLE;

上面的是系统服务描述符表,里面包含了四个系统服务表,是不是有点绕口，我觉得是比较绕口。
下面是系统服务表
typedef struct _SYSTEM_SERVICE_TABLE
{
    PVOID ServiceTableBase;    //这个指向系统服务函数地址表
    PULONG ServiceCounterTableBase;
    ULONG NumberOfService;     //服务函数的个数,NumberOfService*4 就是整个地址表的大小
    ULONG ParamTableBase;
}SYSTEM_SERVICE_TABLE,*PSYSTEM_SERVICE_TABLE;

另外关于楼主说的修复SSDT表我是这样理解的，不知道对不对。

我们Hook SSDT的时候修改的是内存中的SSDT表，而这个表是从Kernel32.dll中加载的，也就是说内存中的
所有东西在Kernel32.dll这个文件中是有备份的,注意是硬盘上的"文件"，而不是已经加载到内存的那个Kernel32.dll。恢复的时候只需要分析硬盘上的这个Kernel32.dll就可以获取到原始的函数地址，这样就可以恢复了。

谢谢楼上的两位，明白了！