剖析Windows系統服務調用機制

剖析Windows系統服務調用機制

作者: Brief

一> 序言

Windows系統服務調用是存在於Windows系統中的一個關鍵介面，常常稱作System Call ，Sysem Service Call 或 System Service Dispatching等，在此我們就權且稱之為Windows系統服務調用，它提供了作業系統環境由使用者態切換到核心態的功能。雖然在國外關於Windows系統服務調用的討論比較多，但卻很少看到比較詳細的中文資料，希望本文能夠為和作者一樣對Windows底層感興趣並且是剛剛接觸的朋友提供一些協助。文章中將以一個核心級的進程監視/隱藏工具T-ProcMon為例來詳細討論Windows系統服務調用的相關技術細節。另需注意本文討論的技術僅適用於基於Windows NT核心的作業系統，並以Windows 2000為例。

二> Windows 2000系統體繫結構

微軟Windows 2000是一個主要面向網路伺服器的作業系統，因此它和以前大家比較熟悉的Windows 9x有很大的區別。但是對於討論一個因商業策略而出現的個人桌面作業系統的確沒有太大的價值。所以我們將主要介紹一些關於NT系統內部結構的細節。Windows 2000在實現其自身目標的過程中，我們有必要講解一些它的特性。

1. 可擴充性(Extensibility)

Windows 2000作業系統是一個面向未來的系統，所以它非常注重自身的擴充性，因為在將來可能有許多市場等方面的原因導致我們必須添加或刪除目前作業系統的一些組件，這就必須要求作業系統有較強的可擴充性。為了滿足擴充/刪除的各種需求，Windows 2000提供了一個重要的設計思想就是子系統(Subsystem)。我們可以將一些需要擴充的作業系統功能作為一個子系統添加到Windows 2000內，就像OS/2，POSIX等一樣。當然還有一個特性就是，我們可以通過為系統服務調用添加鉤子來修改系統的各項行為，這就為我們提供了一個瞭解系統內部並擴充系統功能的機會。

2. 可靠性和健壯性(Reliability and Robust)

一個系統存在的最基本的要求就是它的穩定性，沒有穩定的環境就做不出任何滿意的產品。為了滿足這項要求，Windows 2000提出了基於對象的存取控制許可權的措施。現代的大多數微處理器都支援兩種模式：使用者模式(User/Normal)和核心模式(Kernel/Privileged)。作業系統組件和關鍵的系統組件處於核心模式，而一般使用者模式的程式只能訪問私人地址空間和執行非特權等級的指令。如果使用者要調用一些核心組件的功能，就得通過系統服務調用來實現。

3. 相容性(Compatibility)

Intel和Microsoft能夠做到今天的一個很重要的因素就是他們支援對過去存在系統的相容。這一點非常的關鍵，沒有人願意三天兩頭的更換系統，當然也很少有人有這個經濟實力。Windows 2000為了實現對其他系統的相容，如Dos，16位Windows等，出現了環境子系統。而在Windows 2000中必須存在的環境子系統是Win32，它是其他子系統的基礎，其他子系統都是一些表面的介面，而實際上是調用了Win32提供的介面，而Win32最終也是通過系統服務調用來與核心聯絡的。雖然作業系統為各種環境子系統提供了不同的動態連結程式庫，而且其中的API函數名稱往往也是不同的，不過這個函數的最終都是通過相同的系統服務調用進入核心來實現的。

4. 易維護性(Maintainability)

作為一個大型的項目，Windows 2000的維護也成為了一個大型的工程。而如此巨大的項目沒有很好的維護性是無法發展下去的。為此，Windows 2000使用了分層的思想，這也是一種作業系統體繫結構模型。其中，系統服務調用將系統的核心模式代碼和使用者模式代碼隔離開來，子系統使用系統服務調用為使用者提供API(API)，而系統服務調用向下調用執行體實現各項功能。

就像在上文我們提到的作業系統存在的兩種模式，這是建立在處理器的基礎之上的。按理說，一般處理器可以提供從Ring0到Ring3的四種處理器模式，但是它們必須提供至少兩種，那就是Ring0和Ring3。而一些特殊處理器指令只能在核心模式執行，而一些地址空間必須在核心模式才可以被訪問。Windows 2000就利用了這個特點，將作業系統和其他關鍵組件保護起來，只有在核心模式才可以訪問執行，而一般的使用者程式就只能在使用者態執行咯，這樣就可以避免一些使用者程式對作業系統代碼的破壞，也就是大家看到的Windows 2000明顯比Windows 9x穩定得多的主要原因。下面我們給出了Windows 2000的體繫結構簡圖：

系統支援進程，服務進程，應用程式，環境子系統

API

基於NTDLL.dll的本地系統服務 (使用者模式)

系統服務調用 (核心模式)

執行體

系統核心，裝置驅動程式

硬體抽象層

三> Windows 2000本機系統服務(Native API)

Windows 2000本機系統服務又稱為Windows本機API，它是由執行體(Executive)為使用者模式和核心模式的程式提供的系統服務集。它包含兩種類型的函數：Windows 執行系統服務的系統服務調度佔位程式；子系統，子系統DLL和其他本機映像使用的內部支援函數。

從使用者模式調用本機系統服務是通過NTDLL.dll來實現的。表面上，Win32函數為編程人員提供了很多介面來實現我們想要的功能，但是這些Win32函數只不過是本機API的一個封裝器而已，它們將本機API封裝起來，調用本機系統服務來實現使用者期望的功能。也就是說NTDLL.dll只是系統服務調用介面在使用者模式下的一個外殼。關於使用者模式下的Windows本機系統服務的相關資訊，請參見我以前寫的一篇文章《探測Windows2K/XP/2003本機系統資訊》。

我們再談談從核心模式調用系統服務吧，這時就不是由NTDLL.dll匯出系統服務調用的函數介面了，而是由ntoskrnl.exe來實現的，它會提供兩種形式的函數：ZwXxx和NtXxx，在此我們就不多說了。大家應該注意到了，在上面我們介紹的Windows 2000系統體繫結構中的系統服務調用，執行體和核心都是存在於ntoskrnl.exe(在多處理器中為ntkrnlmp.exe)之中，並且是分層的。

四> Windows 2000系統服務調用機制

Windows 2000的陷阱調度(Trap Dispatching)機制包括了：中斷(Interrupt)，延遲程序呼叫(Deferred Procedure Call)，非同步程序呼叫(Asynchronous Procedure Call)，異常調度(Exception Dispatching)和系統服務調用。在Intel x86的Windows 2000系統中，處理器執行int 0x2e指令來啟用Windows系統服務調用；在Intel x86的Windows XP系統中處理器卻是通過執行sysenter指令使系統陷入系統服務調用程式中；而在AMD的Windows XP中使用了指令syscall來實現同樣的功能。我們暫時使用x86的Windows 2000為例來示範。我們先給出一個系統服務調用的模型：

mov eax, ServiceId

lea edx, ParameterTable

int 2eh

ret ParamTableBytes

其中，ServiceId清楚的說明了傳遞給系統服務調用的系統服務號，核心使用這個標識符來尋找系統服務調度表(System Service Dispath Table)中的對應系統服務資訊。在系統服務調度表中的每一項包含了一個指向系統服務程式的指標，我們Hook時就是修改這個指標使其指向我們自訂的系統服務的地址。ParameterTable是傳遞的參數，系統服務調用程式KiSystemService必須嚴格校正傳遞的每一個參數，並將其參數從線程的使用者堆棧中複製到系統的核心堆棧以備使用。由於執行int指令會導致陷阱發生，所以在Windows 2000內的中斷描述表(IDT = Interrupt Descriptor Table)中的0x2e項指向了系統服務調用程式。最後返回的ParamTableBytes是關於參數個數的資訊。

現在我們已經看得出來了，系統服務調用只是一個介面，它提供了將使用者模式下的請求轉寄到Windows 2000核心的功能，並引發處理器模式的切換。在使用者看來，系統服務調用介面就是Windows核心組件功能實現對外的一個介面。系統服務調用介面定義了Windows核心提供的大量服務。

五> Windows 2000系統服務調用類型

在Windows 2000中預設存在兩個系統服務調度表，它們對應了兩類不同的系統服務。這兩個系統服務調度表分別是：KeServiceDescriptorTable和KeServiceDescriptorTableShadow。

Windows 2000執行程式服務對應於NTDLL.dll為我們提供的系統服務調用。子系統通過調用NTDLL.dll中的函數介面來實現它們需要的功能。系統服務調度表KeServiceDescriptorTable定義了在ntoskrln.exe中實現的系統服務，通常在kernel32.dll/advapi32.dll中提供的函數介面均是調用的這個系統服務調度表中。

同時存在於Windows 2000作業系統中還有在Win32k.sys中實現的相關Win32USER和GDI函數，它們是屬於另一類系統服務調用。與之對應的系統服務調度表為KeServiceDescriptorTableShadow，它提供了核心模式實現的USER和GDI服務。函數KeAddSystemServiceTable允許Win32.sys和其他裝置驅動程式添加系統服務表。除了Win32k.sys服務表外，使用KeAddSystemServiceTable添加的服務表會被同時複製到KeServiceDescriptorTable和KeServiceDescriptorTableShadow中去。

我們可以看出這兩類函數實現在服務調度上的區別：Win32核心API經過Kernel32.dll/advapi32.dll進入NTDLL.dll後使用int 0x2e中斷進入核心，最後在Ntoskrnl.exe中實現了真正的函數調用；Win32 USER/GDI API直接通過User32.dll/Gdi32.dll進入了核心，最後卻是在Win32k.sys中實現了真正的函數調用。在此我們只討論與NTDLL.dll相關的函數，也就是我們例子中處理的函數。

六> Hook系統服務調用的作用

鉤子(Hooking)是一種攔截/監聽可執行代碼在執行過程中相關資訊的一種通用機制。它使我們瞭解系統內部結構，運作機制甚至修改系統行為的想法成為可能。在一個像M$存在的世界裡，Windows的很多內部資訊我們都是無法得知的，因為Windows不是Linux，但這並不意味著我們就此放棄！只要開動你的大腦，很多事情都會變成可能。

1. 事件追蹤

你想知道Windows在什麼時候會開啟一個進程嗎？你想知道Windows工作管理員中進程相關資訊的擷取調用了哪些函數嗎？我們都可以使用Hook技術來實現這些你想要的資訊。我們可以追蹤ZwOpenProcess的執行情況，我們同樣也可以追蹤ZwQueryInformationProcess的執行情況，包括傳遞的參數和返回的結果。大家可以看到本文相關的程式T-ProcMon就是一個進程監視工具，它會追蹤系統中與進程相關的各種資訊。在某些我們期望的事件發生時，程式會通知使用者發生了什麼，這也是我們期望看到的結果。

2. 修改系統行為

作業系統為我們提供了一些通用的功能，如查詢系統進程資訊ZwQuerySystemInformation(SystemInformationClass == 5)，它會返回系統中當前所有進程/線程的相關資訊。如果我們希望隱藏一些特殊的進程那該怎麼辦呢？那就是修改系統服務調用，也就是修改ZwQuerySystemInformation的行為。在查詢系統進程時，系統會返回一個進程資訊隊列，每個單元對應一個進程，如果我們想隱藏其中的某個進程，只須修改隊列中的某些資料，然後返回給上層函數，它們就不會發現Xxx.exe進程存在於系統之中了。

3. 研究系統內部機制

微軟提供的Windows作業系統是一個“封閉”的系統，很多內部資料都沒有公布，我們可以通過Hook技術來探測系統的內部資料結構和運行機制，學習作業系統內部的操作方式。基於Hook的Windows核心駭客技術(Kernel Hacking)是非常之流行和有效，在我們探測系統的一些未公開，未文檔化的技術細節時我們都可以使用鉤子技術。

4. 其他

其他如我們要調試一個非常麻煩的程式時就可以使用Hook技術，這樣就可以更好的協助我們追蹤系統的行動，更好的瞭解程式內部的執行過程。同樣，為了擷取系統的一些特殊效能資料，我們也可以在特定的情況下使用Hook技術。

七> Hook系統服務調用的實現

在此我們討論Hook的對象僅限於由Windows 2000的ntoskrnl.exe提供的系統服務調用。Windows 2000系統服務調用為核心模式的代碼，所以我們必須書寫裝置驅動程式來訪問系統服務調度表。如果你對Windows 2000下基本裝置驅動程式的書寫不太清楚，請查閱相關的書籍，此處不做介紹。我們先回顧一下Win32核心API的實現流程。

Windows 2000系統服務調用向使用者提供了經過封裝的使用者模式的函數介面(由NTDLL.dll提供)。當Kernel32.dll/Advapi32.dll中的函數執行時，先調用NTDLL.dll中對應的相關介面，經過參數檢查後使用int 0x2e指令進入核心模式，傳遞相關的服務號和參數列表。在ntoskrnl.exe中維護著兩個表系統服務調度表(System Service Dispath Table)和系統服務參數表(System Service Parameter Table)，其中int 0x2e指令就是通過服務號在SSDT中查詢相關係統服務程式指標的。現在我們已經清楚了每個系統服務調用都對應一個服務號，同時也對應一個服務程式的地址！如果我們修改SSDT中的某個系統服務程式的入口地址為指向我們自訂的函數地址，在執行完我們的代碼後再執行原始系統服務地址處的代碼，這不就實現了對系統服務調用的了Hook嗎？

對我們來說，定位系統服務調度表是實現Hook的關鍵。在Windows 2000中有一個未公開的由ntoskrnl.exe匯出的單元：KeServiceDescriptorTable，我們可以通過它來完成對SSDT的訪問與修改。KeServiceDescriptorTable對應於一個資料結構，定義如下：

typedef struct SystemServiceDescriptorTable

{

UINT *ServiceTableBase;

UINT *ServiceCounterTableBase;

UINT NumberOfService;

UCHAR *ParameterTableBase;

}SystemServiceDescriptorTable,*PSystemServiceDescriptorTable;

其中ServiceTableBase指向系統服務程式的地址，ParameterTableBase則指向SSPT中的參數地址，它們都包含了NumberOfService這麼多個單元。我們只要由KeServiceDescriptorTable找到了我們關注的系統服務調用程式，就可以修改它的ServiceTableBase參數來實現對相關係統服務調用的Hook了！

八> T-ProcMon-1.0 關鍵源碼分析

1. 基於CUI的使用者模式控製程序

由於在此之前我已經對Win32的系統服務進行了詳細的介紹，現在就不做多說了，大家如果有什麼疑問請參閱我以前寫的文章，你可以到FZ5FZ的首頁(http://www.fz5fz.org)閱讀相關文章，或下載相關原始碼。

2. 基於裝置驅動的Hook代碼

定義在使用者模式與核心模式程式間通訊的命令代碼：

#define PROCMON_MONITOR (ULONG) CTL_CODE(FILE_DEVICE_PROCMON,0x01,METHOD_BUFFERED,FILE_ANY_ACCESS)

#define PROCMON_HIDDEN (ULONG) CTL_CODE(FILE_DEVICE_PROCMON,0x02,METHOD_BUFFERED,FILE_ANY_ACCESS)

#define PROCMON_HOOK (ULONG) CTL_CODE(FILE_DEVICE_PROCMON,0x03,METHOD_BUFFERED,FILE_ANY_ACCESS)

#define PROCMON_UNHOOK (ULONG) CTL_CODE(FILE_DEVICE_PROCMON,0x04,METHOD_BUFFERED,FILE_ANY_ACCESS)

將KeServiceDescriptorTable與相關資料結構聯絡起來，定義系統調用：

__declspec(dllimport) ServiceDescriptorTableEntry KeServiceDescriptorTable;

#define SYSCALL(_function) KeServiceDescriptorTable.ServiceTableBase[*(PULONG)((PUCHAR)_function+1)]

定義各種未公開的函數，如ZwQuerySystemInformation:

typedef

NTSTATUS

(*ZWQUERYSYSTEMINFORMATION)(

IN ULONG SystemInformationClass,

IN OUT PVOID SystemInformation,

IN ULONG SystemInformaitonLength,

OUT PULONG ReturnLength OPTIONAL);

修改系統服務調用，儲存原始的入口地址，修改為我們自訂的程式入口地址，如ZwQuerySystemInformation：

OldZwQuerySystemInformation = (ZWQUERYSYSTEMINFORMATION)(SYSCALL(ZwQuerySystemInformation));

_asm cli

(ZWQUERYSYSTEMINFORMATION)(SYSCALL(ZwQuerySystemInformation)) = NewZwQuerySystemInformation;

_asm sti

解除鉤子，還原系統服務調用：

_asm cli

(ZWQUERYSYSTEMINFORMATION)(SYSCALL(ZwQuerySystemInformation)) = OldZwQuerySystemInformation;

_asm sti

調用原始的系統服務程式代碼：

NtStatus = (OldZwQuerySystemInformation)

(SystemInformationClass,

SystemInformation,

SystemInformaitonLength,

ReturnLength);

隱藏進程，既是修改系統返回的資料隊列中相關項目的位移量使起指向需要隱藏進程的下一個單元，也就是說跳過我們需要隱藏進程的單元：

if(RtlCompareUnicodeString(&pCurrentNK->Name,&ProcCur->ProcessName,TRUE) == 0)

{

RtlUnicodeStringToAnsiString(&ProcNameA,&pCurrentNK->Name,TRUE);

DbgPrint("Hidden Process Name: %s\n",ProcNameA.Buffer);

if(ProcPre != NULL)

{

if(ProcCur->NextEntryDelta != 0)

{

ProcPre->NextEntryDelta += ProcCur->NextEntryDelta;

}

else

{

ProcPre->NextEntryDelta = 0;

}

}

else

{

if(ProcCur->NextEntryDelta != 0)

{

SystemInformation = (PSYSTEM_PROCESSES)((PTSTR)ProcCur + ProcCur->NextEntryDelta);

}

else

{

SystemInformation = NULL;

}

}

break;

}