Windows核心分析索引目錄：https://www.cnblogs.com/onetrainee/p/11675224.html

Windows系統呼叫中的系統服務表描述符

　　在前面，我們將解過 系統服務表。可是，我們有個疑問，系統服務表儲存在哪裡呢？

　　答案就是：系統服務表 儲存在 系統服務描述符表中。(其又稱為 SSDT Service Descriptor Table)

 一、使用PELord函式從ntoskrnl.exe檔案中檢視SSDT匯出函式

　　如圖，可以看出KeServiceDescriptorTable匯出函式。

　　通過該函式可以查詢SSDT表的位置。

二、通過Windbg來記憶體中檢視SSDT表

　　使用Windbg，可以使用 kd> dd nt!KeServiceDescriptorTable 指令來檢視SSDT表。

　　但該指令存在缺點，可以看到第二張表為0，說明如果使用KeServiceDescriptorTable這個公開的匯出函式，我們無法看到win32k.sys這張表結構

　　kd> dd nt!KeServiceDescriptorTable
　　　　83f759c0  83e89d9c 00000000 00000191 83e8a3e4
　　　　83f759d0  00000000 00000000 00000000 00000000
　　　　83f759e0  83ee86af 00000000 0327aa43 000000bb
　　　　83f759f0  00000011 00000100 5385d2ba d717548f

　　為了解決上面這個問題，我們只能使用另外一個指令，該指令對應的是一個未公開匯出的函式。

　　如下，可以看到其第二行，win32k.sys系統服務表已經可見。

　　kd> dd KeServiceDescriptorTableShadow
　　　　83f75a00  83e89d9c 00000000 00000191 83e8a3e4
　　　　83f75a10  83b66000 00000000 00000339 83b6702c
　　　　83f75a20  00000000 00000000 83f75a24 00000340
　　　　83f75a30  00000340 855e8440 00000007 00000000

三、驗證ReadMemory真正的核心實現部分

　　我們在這篇《Windows系統呼叫中API的三環部分(依據分析重寫ReadProcessMemory函式)》中曾提到過直接使用快速呼叫來摒棄R3層層封裝的API，其中給eax一個函式號，現在我們來實戰刨析一下。

mov eax, 0x115
mov edx, 0X7FFE0300

　　如下，系統描述符的資料結構，其依次分別為

　　其依次分別為 ServiceTable 83e89d9c,Count 00000000,ServiceLimit  00000191,ServiceTable 83e8a3e4　

　　使用Windbg來檢視其115h序號的函式地址 115h*4 + 83e89d9c (ServiceTable)

　　得到函式地址為 8406c82c

　　kd> dd 115h*4 + 83e89d9c
　　　　83e8a1f0  8406c82c 840feb46 83fb488c 83fb6128　

　　再對此進行反彙編可得

　　kd > u 8406c82c　　　
                nt!NtReadVirtualMemory:
                8406c82c 6a18            push    18h
                8406c82e 68282ae683      push    offset nt!? ? ::FNODOBFM::`string'+0x3ea8 (83e62a28)
                8406c833 e870e3e1ff      call    nt!_SEH_prolog4(83e8aba8)
                8406c838 648b3d24010000  mov     edi, dword ptr fs : [124h]
                8406c83f 8a873a010000    mov     al, byte ptr[edi + 13Ah]
                8406c845 8845e4          mov     byte ptr[ebp - 1Ch], al
                8406c848 8b7514          mov     esi, dword ptr[ebp + 14h]
                8406c84b 84c0            test    al, al

　　之後，我們檢視該nt!NtReadVirtualMemory函式的引數個數

　　kd > db 83e8a3e4 + 115
                83e8a4f9  14 08 04 04 14 04 10 08 - 0c 04 14 18 08 08 08 0c
                83e8a509  0c 08 10 14 08 08 0c 08 - 0c 0c 04 08 08 08 08 08  
                83e8a519  08 0c 0c 24 00 08 08 08 - 0c 04 08 04 08 10 08 04　　

四、通過修改SSDT表增添系統服務函式

　　我們在 Windows系統呼叫中API的三環部分(依據分析重寫ReadProcessMemory函式) 呼叫的是 115h 號函式。

　　現在，我們將該函式地址放到 191 號函式處(之前一共有191個函式，佔據0-190位)。

　　修改思路：

　　1）將 nt!NtReadVirtualMemory 函式地址 8406c82c 放到 191號處(83e89d9 + 191h*4)

　　　　kd> ed 83e89d9 + 191h*4　8406c82c　

　　2)  增大 服務表最大個數。 (因為我們上一節分析其反彙編程式碼的時候，發現其會進行最大個數的判斷)

　　　　kd> ed 83f75a00+8 192

　　3)  修改引數個數表中對應的191號引數個數。（我們之前查閱過其為 14,以位元組為單位)

　　　　kd> eb 83e8a3e4+191 14

　　4)  之後，我們執行下列程式碼。其與《Windows系統呼叫中API的三環部分(依據分析重寫ReadProcessMemory函式)》唯一的不同調用函式號為192，最終效果完全一樣。

 1 #include "pch.h"
 2 #include <iostream>
 3 #include <algorithm>
 4 #include <Windows.h>
 5 void  ReadMemory(HANDLE hProcess, PVOID pAddr, PVOID pBuffer, DWORD dwSize, DWORD  *dwSizeRet)
 6 {
 7 
 8     _asm
 9     {
10         lea     eax, [ebp + 0x14]
11         push    eax
12         push[ebp + 0x14]
13         push[ebp + 0x10]
14         push[ebp + 0xc]
15         push[ebp + 8]
16         sub esp, 4
17         mov eax, 0x192  // 注意：修改的是這裡
18         mov edx, 0X7FFE0300   //sysenter不能直接呼叫，我間接call的
19         CALL DWORD PTR[EDX]
20         add esp, 24
21 
22     }
23 }
24 int main()
25 {
26     HANDLE hProcess = 0;
27     int t = 123;
28     DWORD pBuffer;
29     //hProcess = OpenProcess(PROCESS_ALL_ACCESS, 0,a);
30     ReadMemory((HANDLE)-1, (PVOID)&t, &pBuffer, sizeof(int), 0);
31     printf("%X\n", pBuffer);
32     ReadProcessMemory((HANDLE)-1, &t, &pBuffer, sizeof(int), 0);
33     printf("%X\n", pBuffer);
34 
35     getchar();
36     return 0;
37 }

&n