之前我們了解到通過kthread結構體0xe0的位置可以找到系統服務表,這個位置是我們通過逆向得出的。實際上,windows提供了乙個匯出的全域性變數,通過這個匯出的全域性變數,我們就可以直接訪問系統服務表。
用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 的全稱是 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這個結構只包含第一張ntoskrl.exe匯出的系統服務表,不包含第二張win32k.sys匯出的系統服務表。那麼我們如果想要修改第二張系統服務表的函式,該通過什麼方式找到它呢?
也可以通過乙個全域性變數,這個全域性變數叫keservicedescriptortableshadow(ssdt shadow)。這個全域性變數是未匯出的,需要通過其他方式來查詢(通常是使用記憶體搜尋的方式)
keservicedescriptortableshadow的結構和ssdt完全一樣,也有四個成員,第乙個成員是ntoskrl.exe匯出的第一張系統服務表,第二個成員是win32k.sys匯出的第二張系統服務表。
但如果你直接訪問win32k.sys匯出的第二張系統服務表的函式位址時,會發現裡面的函式位址都是無效的。
這是因為win32k.sys匯出的第二張系統服務表只有在當前程序訪問的gdi相關的api的時候,裡面的函式位址表才會掛載到物理記憶體上。如果程序沒有用到gdi相關的api,那麼第二張系統服務表裡面的函式位址表就不會掛載到物理記憶體,那麼裡面的函式也無效。
列舉SSDT 系統服務表中的函式位址
網上關於ssdt的有很多的部落格可以參考,我就不囉嗦了直接上碼 include ssdt服務表中,各項對應的函式名稱,num 代表引數 4的大小 char funcname typedef struct ksystem service tableksystem service table,pksys...
Windows核心 系統描述符表與SSDT
以下參考自水滴教程及 system services descriptor table system services descriptor table,即系統服務描述符表,核心中實際存在兩個系統服務描述符表,乙個時keservicedescriptortable 由ntoskrnl.exe匯出 乙...
read系統呼叫,mmap系統呼叫
read系統呼叫,mmap系統呼叫 2012 07 23 09 54 28 分類 linux 標籤 linux 檔案系統 虛擬記憶體 儲存系統 字型大小 訂閱 一般情況下,操作檔案既可以使用標準i o,也可直接使用系統呼叫。兩者有何區別呢?在輸入輸出中,直接使用底層的系統呼叫效率是非常低的,為什麼?...