文章目錄

• • 前言
  • KeServiceDescriptorTable
  • SSDT
  • SSDT Shadow

前言

之前我們了解到通過KTHREAD結構體0xE0的位置可以找到系統服務表，這個位置是我們通過逆向得出的。實際上，WIndows提供了一個導出的全局變量，通過這個導出的全局變量，我們就可以直接訪問系統服務表。

KeServiceDescriptorTable

用IDA打開ntkrnlpa.exe，在導出表里搜索KeServiceDescriptorTable

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-VNWev1KB-1577109726658)(assets/1577104403189.png)]

這個是Windows的內核模塊導出的全局變量，我們可以在windbg中直接查看這個全局變量

kd> dd KeServiceDescriptorTable 83fb09c0 83ec4d9c 00000000 00000191 83ec53e4 83fb09d0 00000000 00000000 00000000 00000000 83fb09e0 83f236af 00000000 026b2372 000000bb 83fb09f0 00000011 00000100 5385d2ba d717548f 83fb0a00 83ec4d9c 00000000 00000191 83ec53e4 83fb0a10 99016000 00000000 00000339 9901702c 83fb0a20 00000000 00000000 83fb0a24 00000340 83fb0a30 00000340 85cd76d8 00000007 00000000

實際上這其實是一個結構體，這個結構體就叫SSDT

SSDT

SSDT 的全稱是 System Services Descriptor Table，系統服務描述符表。SSDT這個結構包含四個成員，里面的每一個成員都是一個系統服務表的結構體。

第一個成員是ntoskrl.exe導出的系統服務表，另外三個成員是空的

我們在windbg中查看一下SSDT的第一個成員

kd> dd 83ec4d9c 83ec4d9c 840c0c28 83f0740d 84050b68 83e6b88a 83ec4dac 840c24ff 83f443fa 84132b05 84132b4e 83ec4dbc 840453bd 8414c368 8414d5c1 8403bb95 83ec4dcc 840ccb35 84125963 84078a56 840486cc 83ec4ddc 83fde928 84117898 8402f14e 84071a62 83ec4dec 840bddf1 8401f238 92731f94 8403cc0c 83ec4dfc 840ce5bc 8403f28f 840ce39c 840c6afc 83ec4e0c 840510f0 84112657 840c3ec9 840ce7ee

這里面的每一個成員都是一個內核函數地址

kd> u 840c0c28 nt!SeReleaseSecurityDescriptor+0x923: 840c0c28 8bff mov edi,edi 840c0c2a 55 push ebp 840c0c2b 8bec mov ebp,esp 840c0c2d 64a124010000 mov eax,dword ptr fs:[00000124h] 840c0c33 66ff8884000000 dec word ptr [eax+84h] 840c0c3a 56 push esi 840c0c3b 57 push edi 840c0c3c 6a01 push 1

SSDT Shadow

問題在于SSDT這個結構只包含第一張ntoskrl.exe導出的系統服務表，不包含第二張win32k.sys導出的系統服務表。那么我們如果想要修改第二張系統服務表的函數，該通過什么方式找到它呢？

也可以通過一個全局變量，這個全局變量叫KeServiceDescriptorTableShadow(SSDT Shadow)。這個全局變量是未導出的，需要通過其他方式來查找(通常是使用內存搜索的方式)

KeServiceDescriptorTableShadow的結構和SSDT完全一樣，也有四個成員，第一個成員是ntoskrl.exe導出的第一張系統服務表，第二個成員是win32k.sys導出的第二張系統服務表。

但如果你直接訪問Win32k.sys導出的第二張系統服務表的函數地址時，會發現里面的函數地址都是無效的。

這是因為Win32k.sys導出的第二張系統服務表只有在當前進程訪問的GDI相關的API的時候，里面的函數地址表才會掛載到物理內存上。如果進程沒有用到GDI相關的API，那么第二張系統服務表里面的函數地址表就不會掛載到物理內存，那么里面的函數也無效。

物理內存上。如果進程沒有用到GDI相關的API，那么第二張系統服務表里面的函數地址表就不會掛載到物理內存，那么里面的函數也無效。

總結

以上是生活随笔為你收集整理的系统调用004 SSDT的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。