一、序言

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)，而系統服務調用向下調用執行體實現各項功能。

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

系統支持進程，服務進程，應用程序，環境子系統 應用程序編程接口 基于NTDLL.dll的本地系統服務 (用戶模式) ----------------------------------------- 系統服務調用(內核模式) 執行體 系統內核，設備驅動程序 硬件抽象層

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

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

從用戶模式調用本機系統服務是通過NTDLL.dll來實現的。表面上，Win32函數為編程人員提供了很多接口來實現我們想要的功能，但是這些Win32函數只不過是本機應用程序編程接口的一個包裝器而已，它們將本機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, ParameterTableint 2ehret 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;UINTNumberOfService;UCHAR*ParameterTableBase;}SystemServiceDescriptorTable,*PSystemServiceDescriptorTable;

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

八、T-ProcMon-1.0 關鍵源碼分析1. 基于CUI的用戶模式控制程序

由于在此之前我已經對Win32的系統服務進行了詳細的介紹，現在就不做多說了，大家如果有什么疑問請參閱我以前寫的文章，你可以到FZ5FZ的主頁閱讀相關文章，或下載相關源代碼。

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,OUTPULONGReturnLength 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: %sn',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;}