剖析Windows系統服務呼叫機制
創建時間：2004-05-06
文章屬性：原創
文章提交：Brief (brief_at_safechina.net)
剖析Windows系統服務呼叫機制
Author: Brief
E-Mail: Brief#fz5fz.org
Homepage: http://www.fz5fz.org && http://www.safechina.net
Date: 07-18-2003
一> 序言
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, 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;
}
附錄 T-ProcMon-1.0源代碼
請參見相關檔案夾中對應CUI和Driver中的源代碼。
下載鏈接： http://www.fz5fz.org/Codes/T-ProcMon-1.0Src.rar
轉載請註明出處，本文鏈接：https://www.uj5u.com/caozuo/115681.html
上一篇：怎么解區域分電腦不能訪問共享？
下一篇：驅動安裝