windows 内核情景分析
原文很長；先轉部分過來，有時間看一下；
?
一 windows 內核情景分析---說明
說明
本文結合《Windows內核情景分析》（毛德操著）、《軟件調試》（張銀奎著）、《Windows核心編程》
、《寒江獨釣-Windows內核安全編程》、《Windows PE權威指南》、《C++反匯編與逆向分析揭秘》以及
ReactOS操作系統 (V0.3.12)源碼，以《Windows內核情景分析》為藍本，對Windows內核重要框架、函數
、結構體進行解析
由于工程龐大，我能理解到的只是冰山一角，但本文力求做到讓每個讀者都能從整體上理解Windows內核
的架構，并大量解釋一些關鍵細節。
本文解讀方式：1、源碼、偽碼結合，展示主流程，很多時候忽略權限、錯誤檢查，多線程互斥等旁枝末
節
2、函數的參數沒有嚴格排序，很多不重要的參數也省略了，要注意
3、結構體內的成員沒有嚴格排序，成員名稱也不嚴格對應，并只列出一些重要成員
4、一些清理工作，如關閉句柄、釋放內存、釋放互斥對象等工作省略
5、很多時候，函數體開頭聲明的那些沒有初始值的局部變量我都略去了
翻看了毛老師的大作，受益匪淺，在基本理清了原理與細節后，特此做了一番總結，
，ReactOS本來就與Windows有一些小差別，
分析的部分項目截圖：
本文術語約定：
描述符：指用來描述一件事物的“結構體”。如緩沖描述符，描述了一個緩沖的基址、長度等信息。中
斷描述符，描述了那個中斷向量對應的分配狀態、isr等信息
Entry：指表中的表項、條目，有時也指函數入口
SSDT：基本系統服務表（其實全稱應叫系統服務派遣表）
Shadow SSDT：GUI/GDI系統服務函數表，這是第二張SSDT
SSDTDT：系統服務表描述符表，表中每個元素是一個SSDT描述符（注意內核中有兩張SSDT和兩張SSDTDT
）
IDT：中斷描述符表，每個cpu一個。（每個表項是一個描述符，可以簡單視為isr）
ISR：中斷服務例程，IDT表中的中斷描述符所描述的中斷處理函數
EPR：異常處理例程，IDT表中的異常描述符所描述的異常處理函數
VA：虛擬地址， ? ?PA：物理地址， ? LA：線性地址， ? RVA：相對虛擬地址 ? ?foa：文件偏移
PDE：頁目錄中的表項，保存著對應二級頁表的物理地址，又叫“二級頁表描述符”
PTE：二級頁表中的表項，真正記錄著每個虛擬頁面的映射情況以及其他信息，又叫“映射描述符”
頁目錄：（又叫一級頁表、總頁表），一個PDE數組，這個數組的大小剛好占據一個頁面
二級頁表：一個PTE數組，這個數組的大小也剛好占據一個頁面（進程有一個總頁表+1024個二級頁表）
AREA：地址空間中的一塊連續的區段，VirtualAlloc分配內存都是以區段為單位
內存分配：表示從地址空間中用VirtualAlloc預定或者提交映射一塊內存，不是指malloc、new、
HeapAlloc
PID：進程ID、進程號。（其實也是個句柄）
TID：線程ID、線程號。（其實也是個句柄）
PDO：物理設備對象，相對于fdo而言。Pdo并不一定是最底層的那個硬件pdo
FDO：功能設備對象，相對于pdo而言。Fdo也可能直接訪問硬件芯片。fdo與pdo只是一種相對概念。
棧底pdo：又叫‘基石pdo’，‘硬件pdo’，指用作堆棧基石的那個pdo，它是由相應的總線驅動內部創
建的 。?
端口設備對象:端口驅動或者小端口驅動中創建的設備對象（他下面是硬件pdo）
總線驅動：用來驅動總線的驅動（總線本身也是一種特殊的設備），如pci.sys總線驅動
端口驅動：由廠家提供的真正用來直接訪問硬件芯片的驅動，位于總線驅動上層
功能驅動：指類驅動。如鼠標類驅動mouseclass.sys，磁盤類驅動disk.sys
上層過濾驅動：位于功能類驅動上面的驅動
下層過濾驅動：位于功能驅動下面，端口驅動上面的驅動
頂層驅動：指位于棧頂的驅動
中間驅動：intermediate drivers，凡是夾在頂層驅動與端口驅動之間的那些驅動都叫中間驅動
設備樹：由PnP管理器構造的一顆用來反映物理總線布局的‘硬件設備樹’。
設備節點：設備樹中的節點。每個節點都表示一個真正的‘硬件pdo’
老式驅動：即NT式驅動，指不提供AddDevice或通過NtLoadDriver加載的驅動
WDM驅動：指提供了AddDevice并且不是通過NtLoadDriver加載的驅動
IRP派遣例程：又叫分發例程、派遣函數。驅動程序中用來響應處理irp的函數。（Dispatch）
設備綁定：指將設備‘堆棧’到原棧頂設備上面，成為新的棧頂設備。
文件：指物理介質上的文件（磁盤、光盤、U盤）
文件對象：每次打開設備時生成一個文件對象（文件對象不是文件，僅僅表示對設備的一次打開上下文
，因此文件對象又叫打開者）
套接字驅動：afd.sys
套接字設備：\Device\Afd\Endpoint
套接字文件對象：每打開一次套接字設備生成一個套接字文件對象
套接字FCB：每個套接字文件對象關聯的FCB，用來描述套接字的其他信息
地址文件對象：每次打開傳輸層的tdi設備時生成的一個文件對象，用于套接字綁定
地址對象：傳輸層中為每個地址文件對象創建一個地址對象，用來描述一個地址（IP、端口號、協議等
）
Socket irp：發往afd套接字設備（即\Device\Afd\Endpoint）的irp
Tdi irp：發往傳輸層設備(即\Device\Tcp,\Device\Udp,\Device\RawIp)的irp
物理卷設備：指磁盤卷、光盤卷、磁帶卷等物理卷設備，由相應類型的硬件驅動創建
磁盤卷設備：指磁盤分區，設備對象名為\Device\HarddiskN\PartitionN 形式（N從0開始）
文件卷設備：由文件系統內部創建的掛載（即綁定）在物理卷上的匿名設備
Cdo：控制設備對象。一個驅動通常創建有一個cdo，用來與外界通信。
FSD：文件系統驅動，File System Driver縮寫。
簇：文件以簇為分配單位。一個文件包含N個簇，簇之間不必物理連續，一個簇一般為4KB
扇區：系統以扇區為單位進行磁盤IO。一個簇包含N個扇區，一個扇區一般為512B
文件塊：磁盤文件中的文件塊，對應于內核中的文件緩沖段
緩沖段：文件塊在內核中的緩沖
ACL：訪問控制表。每個Ntfs文件、內核對象都有一份ACL，記錄了各用戶、組的訪問權限
Token：訪問令牌。每個線程、進程都有一個Token，記錄了包含的特權、用戶、組等信息
SID：指用戶ID、組ID、機器ID，用來唯一標識。
主令牌：進程自己的令牌
客戶令牌：也即模擬令牌。每個線程默認使用進程的令牌，但也可模式使用其他進程的令牌
二 windows內核情景分析--系統調用
Windows的地址空間分用戶模式與內核模式,低2GB的部分叫用戶模式,高2G的部分叫內核模式,位于用戶空
間的代碼不能訪問內核空間,位于內核空間的代碼卻可以訪問用戶空間
一個線程的運行狀態分內核態與用戶態,當指令位于用戶空間時,就表示當前處于內核態,當指令位于內核
空間時,就處于內核態.
一個線程由用戶態進入內核態的途徑有3種典型的方式:
1、 主動通過int 2e（軟中斷自陷方式）或sysenter指令（快速系統調用方式）調用系統服務函數，主
動進入內核
2、 發生異常，被迫進入內核
3、 發生硬件中斷，被迫進入內核
現在討論第一種進入內核的方式：（又分為兩種方式）
1、 通過老式的int 2e指令方式調用系統服務(因為老式cpu沒提供sysenter指令)
如ReadFile函數調用系統服務函數NtReadFile
Kernel32.ReadFile() ?//點號前面表示該函數的所在模塊
{
//所有Win32 API通過NTDLL中的系統服務存根函數調用系統服務進入內核
NTDLL.NtReadFile();
}
NTDLL.NtReadFile()
{
? ?Mov eax,152 ? //我們要調用的系統服務函數號，也即SSDT表中的索引，記錄在eax中
? ?If(cpu不支持sysenter指令)
? ?{
? ? ? Lea edx,[esp+4] //用戶空間中的參數區基地址，記錄在edx中
? ? ? Int 2e ?//通過該自陷指令方式進入KiSystemService，‘調用’對應的系統服務
? ?}
? ?Else
? ?{
? ? ? Lea edx,[esp +4] //用戶空間中的參數區基地址，記錄在edx中
? ? ? Sysenter //通過sysenter方式進入KiFastCallEntry，‘調用’對應的系統服務
? ?}
? ?Ret 36 //不管是從int 2e方式還是sysenter方式，系統調用都會返回到此條指令處
}
Int 2e的內部實現原理：
該指令是一條自陷指令，執行該條指令后，cpu會自動將當前線程的當前棧切換為本線程的內核棧（棧分
用戶棧、內核棧），保存中斷現場，也即那5個寄存器。然后從該cpu的中斷描述符表（簡稱IDT）中找到
這個2e中斷號對應的函數（也即中斷服務例程，簡稱ISR），jmp 到對應的isr處繼續執行，此時這個ISR
本身就處于內核空間了，當前線程就進入內核空間了
Int 2e指令可以把它理解為intel提供的一個內部函數，它內部所做的工作如下
Int 2e
{
? ?Cli ?//cpu一中斷，立馬自動關中斷
? ?Mov esp, TSS.內核棧地址 //切換為內核棧，TSS中記錄了當前線程的內核棧地址
? ?Push SS
? ?Push esp
? ?Push eflags
? ?Push cs
Push eip ?//這5項工作保存了中斷現場【標志、ip、esp】
Jmp ?IDT[中斷號] ?//跳轉到對應本中斷號的isr
}
?
IDT的整體布局：【異常->空白->5系->硬】（推薦采用7字口訣的方式重點記憶）
異常：前20個表項存放著各個異常的描述符（IDT表不僅可以放中斷描述符，還放置了所有異常的異常處
理描述符，0x00-0x13）
保留：0x14-0x1F,忽略這塊號段
空白：接下來存放一組空閑的保留項(0x20-0x29)，供系統和程序員自己分配注冊使用
5系：然后是系統自己注冊的5個預定義的軟中斷向量（軟中斷指手動的INT指令）
? ? ?（0x2A-0x2E ?5個系統預注冊的中斷向量，0x2A：KiGetTickCount, 0x2B:KiCallbaclReturn
0x2C:KiRaiseAssertion, ?0x2D:KiDebugService, ?0x2E:KiSystemService）
硬： ?最后的表項供驅動程序注冊硬件中斷使用和自定義注冊其他軟中斷使用（0x30-0xFF）
......
......
參見《寒江獨釣》一書P93頁注冊鍵盤中斷時，搜索空閑未用表項是從0x20開始，到0x29結束的,就知道
為什么寒江獨釣是在這段范圍內搜索空白表項了（其實我們也完全可以從0x14開始搜索）
......
明白了IDT，就可以看到0x2e號中斷的isr為KiSystemService,顧名思義，這個中斷號專用于提供系統服
務。
在正式分析KiSystemService,前,先看下幾個輔助函數
SaveTrap() ?//這個函數用來保存寄存器現場和其他狀態信息
{
Push 0 ? //LastError
Push ebp
Push ebx
Push esi
Push edi
Push fs ? //此時的fs若是從用戶空間自陷進來的就指著TEB，反之指著kpcr
Push kpcr.ExceptionList
Push kthread.PreviousMode
Sub esp,0x48 //騰給調式寄存器保存用
-----------至此，上面的這些語句連同int 2e中的語句在棧上構造了一個trap幀-----------------
Mov CurTrapFrame,esp ?//當前Trap幀的地址
Mov CurTrapFrame.edx, kthread.TrapFrame //將上次的trap幀地址記錄到edx成員中
Mov kthread.TrapFrame, CurTrapFrame, //修改本線程當前trap幀的地址
Mov kthread.PreviousMode,GetMode(進入內核前的CS) ?//根據CS自動確定上次模式
Mov kpcr.ExceptionList,-1 ?//表示剛進入內核時，尚未安裝seh
Mov fs,kpcr ? //一進入內核就讓fs改指向當前cpu的描述符kpcr，不再指向TEB
If(當前線程處于調試狀態)
? ?保存DR0-DR7到trap幀中
}
FindTableCall() //這個函數用來查表，拷貝參數，調用系統服務
{
Mov edi,eax ?//系統函數號,低12位為索引，第13為表示是哪張系統服務表中的索引
Mov eax, edi.低12位 //eax=真正的服務號
If(edi.第13位=1) ?//if這是shadow SSDT中的系統函數號
{
? ?If(當前線程.服務描述符表!=shadow)
? ? ? 當前線程.服務描述符表=shadow ?//換用另外一張描述符表
}
服務表描述符=當前線程.服務描述符表[edi.第13位]
Mod edi=服務表描述符.base //這個系統服務表的地址
Mov ebx,[edi+eax*4] ?//查表獲得這個函數的地址
Mov ecx=服務表描述符.Number[eax] ?//查表獲得的這個系統函數的參數大小
Mov esi,edx ? //esi=用戶空間中的參數地址
Mov edi,esp ?//esp已經為內核棧的棧頂地址
Rep movsb ?//將所有參數從用戶空間復制到內核空間，相當于N個連續push壓參
Call ?ebx ?//調用對應的系統服務函數
}
......
Struct KSERVICE_TABLE_DESCRIPTOR
{
? ?ULONG* base;//系統服務表的地址
? ?ULONG* CountTable;//該系統服務表中每個函數的歷史調用次數統計表
? ?ULONG limit;//該系統服務表的大小，也即容量
? ?BYTE* ArgSizeTable;//記錄該系統服務表中每個函數參數大小的表 ??
}
2、 通過快速調用指令（Intel的是sysenter，AMD的是syscall）調用系統服務
老式的cpu不支持、不提供sysenter指令，只能由int 2e模擬中斷方式進入內核，調用系統服務，
但是，那種方式有一個明顯的缺點，就是速度慢！（如int 2e內部本身要保存5個寄存器的現場，然后還
要去IDT中查找isr，這個過程消耗的時間太多），因此x86系列從奔騰2代開始為系統調用專門增設了一
條sysenter指令以及相應的寄存器msr。同樣，sysenter指令也可看做intel提供的一個內部函數，它做
的工作如下：
Sysenter()
{
? ?Mov ss,msr_ss
? ?Mov esp,msr_esp //關鍵
? ?Mov cs,msr_cs
? ?Mov eip,msr_eip //關鍵
}
系統在啟動初始化過程中，會將上面四個msr寄存器設為固定的值，其中msr_esp為DPC函數專用堆棧，
Msr_eip則固定為KiFastCallEntry
......
......
KeGetPreviosMode()
{
Return kthread.PreviousMode;
}
這樣：內核API KeGetPreviosMode的返回值就是內核模式了
......
三 windows內核情景分析--內存管理
32位系統中有4GB的虛擬地址空間
每個進程有一個地址空間，共4GB，（具體分為低2GB的用戶地址空間+高2GB的內核地址空間）
各個進程的用戶地址空間不同，屬于各進程專有，內核地址空間部分則幾乎完全相同
虛擬地址如0x11111111, ?看似這8個數字是一個整體，其實是由三部分組成的，是一個三維地址，將這
個32位的值拆開，高10位表示二級頁表號，中間10位表示二級頁表中的頁號，最后12位表示頁內偏移
（2^12=4kb）,因此，一個虛擬地址實際上是一個三維地址，指明了本虛擬地址在哪個二級頁表，又在哪
個頁以及頁內偏移是多少 ?這三樣信息！
【虛擬地址 = 二級頁表號.頁號.頁內偏移】：口訣【頁表、頁號、頁偏移】
Cpu訪問物理內存的原理介紹：
如高級語言
DWORD ?g_var; ?//假設這個全局變量被編譯器編譯為0x00000004
g_var=100;?
那么這條賦值語句編譯后對應的匯編語句為：mov DWORD PTR[0x00000004]，100
這里0x00000004就是一個虛擬地址，簡稱VA，那么這條mov 指令究竟是如何尋址的呢？
尋址過程為：CPU中的虛擬地址轉換器也即MMU，將虛擬地址0x00000004轉換為物理地址
具體轉換過程為：
根據CR3寄存器中記錄的當前進程頁表的物理地址，找到總頁表也即頁目錄，再根據虛擬地址中的頁表號
，以頁表號為索引，找到總頁表中對應的PDE，再根據PDE，找到對應的二級頁表，再以虛擬地址中的頁
號部分為索引，找到二級頁表中的對應PTE，再根據這個PTE記錄的映射關系，找到這個虛擬頁面對應的
物理頁面，最后加上虛擬地址中的頁內偏移部分，加上這個偏移值，就得出最后的物理地址。具體用下
面的函數可以形象表達尋址轉換過程：
mov DWORD PTR[0x00000004]，100 //這條指令的內部原理（沒考慮二級緩沖情況）
{
va=0x00000004;//頁表號=0，頁號=0，頁內偏移=4
? ? ? 總頁表=CR3; ?//本進程的總頁表的物理地址固定保存在cr3寄存器中
? ? ? PDE=總頁表[va.頁表號]; ?//PDE為對應的二級頁表描述符
? ? ? 二級頁表=PDE.PageAddr; ?//得出本二級頁表的地址
? ? ? PTE=二級頁表[va.頁號]; ? //得出到該虛擬地址所在頁面的PTE映射描述符
? ? ? If(PTE空白) ?//PTE為空表示該虛擬頁面尚未建立映射
? ? ? ? ?觸發0x0e號頁面訪問異常（具體為缺頁異常）
? ? ? Else
? ? ? If(PTE.bPresent==false) //PTE的這個字段表示該虛擬頁面當前是否映射到了物理內存
? ? ? ? ?觸發0x0e號頁面訪問異常（具體為缺頁異常）
? ? ? Else
? ? ? If(CR0.wp==1 ?&& ?PTE.Writable==false) //已開啟頁面寫保護功能,就檢查這個頁面是否可寫
? ? ? ? ?觸發0x0e號頁面訪問異常（具體為頁面訪問保護越權異常）
? ? ? Else
? ? ? ? ?物理地址pa =cs.base + PTE.PageAddr + va.頁內偏移 ?//得出對應的物理地址
? ? ? 將得到的pa放到地址總線上,100放在數據總線上,經由FSB->北橋->內存總線->內存條 寫入內存
}
PTE是二級頁表中的表項，記錄了對應虛擬頁面的映射情況，這個PTE實際上可以看做一個描述符。
上面的過程比較簡單，由于每次訪問內存都要先訪問一次PTE獲取該虛擬頁面對應的物理頁面，再訪問物
理頁面讀得對應的數據，因此實際上訪問了兩次物理內存，如果類似于每條這樣的Mov指令都要訪問物理
內存兩次，才能獲得數據，效率就很低。因此，cpu芯片中專門開辟了一個二級緩沖，用來保存那些頻繁
訪問的PTE，這樣，cpu每次去查物理頁面時，就先嘗試在二級緩沖中查找對應的PTE，如果找不到，再才
去訪問內存中的PTE。這樣，效率就比較高，實際上絕大數情況就可以在二級緩沖中一次性找到對應的
PTE。
另外有一個問題需要說明下：va---->pa的轉換過程實際上是va->la->pa,實際上PTE.PageAddr表示的是
相對于cs段的偏移，加上cs段的base基址，就得到了該頁面的la線性地址。
（線性地址=段.基地址 + 段內偏移），但是由于Windows采取了Flat也即所謂的平坦分段機制，使得每
個段的基地址都在0x00000000處，長度為4GB，也即相當于Windows沒有采取分段機制。前面講過，cs是
GDT表中的索引，指向GDT表中的cs段描述符，由于Windows不分段，因此GDT中每個段描述符的基址=0，
長度=4GB，是固定的！這樣一來，由于不分段，線性地址就剛好是物理地址，所以本來是由虛擬地址->
線性地址->物理地址的轉換就可以直接看做虛擬地址->物理地址。
（注：在做SSDT hook、IDT hook時，由于SSDT與IDT這兩張表各自所在的頁面都是只讀的，也即他們的
PTE中標志位標示了該頁面不可寫。因此，一修改SSDT、IDT就會報異常，一個簡單的處理方法是是關閉
CRO中的wp即寫保護位，這樣就可以修改了）
前文說了，每個進程有兩個地址空間，一個用戶地址空間，一個內核地址空間，該地址空間的內核結構
體定義為：
Struct ?MADDRESS_SPACE ?//地址空間描述符
{
? ?MEMORY_AREA* ?MemoryRoot;//本地址空間的已分配區段表（一個AVL樹的根）
? ?VOID* ?LowestAddress;//本地址空間的最低地址（用戶空間是0，內核空間是0x80000000）
? ?EPROCESS* Process;//本地址空間的所屬進程
/*一個表，表中每個元素記錄了本地址空間中各個二級頁表中的PTE個數，一旦某個二級頁表中的PTE個
數減到了0，就自動釋放該二級頁面表本身，體現為稀疏數組特征*/
? ?USHORT* PageTableRefCountTable;?
? ?ULONG PageTableRefCountTableSize;//上面那個表的大小
}
地址空間中所有已分配的區段都記錄在一張表中，這個表不是簡單的數組，而是一個AVL樹，用來提高查
找效率。每個區段的基址都對齊64KB或4KB（指64KB整倍數），各個區段之間可以有空隙，
區段的分布是很零散的！各個區段之間，夾雜的空隙就是尚未分配的虛擬內存。
注：所謂已分配區段，是指已經過VirtualAlloc預訂（reserve）或提交（commit）后的虛擬內存
區段的描述符如下：
Struct ?MEMORY_AREA ? ?//區段描述符
{
? ?Void* StartingAddress; //開始地址，普通區段對齊64KB，其它類型區段對齊4KB
? ?Void* EndAddress;//結尾地址，EndAddress – StartingAddress就是該區段的大小
? ?MEMORY_AREA* ?Parent;//AVL樹中的父節點
? ?MEMORY_AREA* ?LeftChild;//左邊的子節點
? ?MEMORY_AREA* ?RightChild;//右邊的子節點
//常見的區段類型有：普通型區段、視圖型區段、緩沖型區段（后面文件系統中會講到）等
? ?ULONG type;//本區段的類型
? ?ULONG protect;//本區段的保護權限，可讀、可寫、可執行的組合
? ?ULONG flags;//當初分配本區段時的分配標志
? ?BOOLEAN DeleteInProgress;//本區段是否標記為了‘已刪除’
? ?ULONG PageOpCount;
? Union
{
? ? Struct //這個Struct專用于視圖型區段
? ? {
? ? ? ?//凡是含有ROS字樣的函數與結構體都表示是ReactOS與Windows中不同的實現細節
? ? ? ?ROS_SECTION_OBJECT* ?section;?
? ? ? ?ULONG ViewOffest;//指本視圖型區段在所在Segment內部的偏移
? ? ? ?MM_SECTION_SEGMENT* Segment;//所屬Segment
? ? ? ?BOOLEAN WriteCopyView;//本視圖區段是不是一個寫復制區段 ??
? ? }SectionData;
LIST_ENTRY ?RegionListHead;//本區段內部的所有Region區塊，放在一個鏈表中
}Data;
}//end
淺談區段類型：
MEMORY_AREA_VIRTUAL_MEMORY：//普通型區段，由VirtuAlloc應用層用戶分配的區段都是普通區段
MEMORY_AREA_SECTION_VIEW：//視圖型區段，用于文件映射、共享內存
MEMORY_AREA_CACHE_SEGMENT：//用于文件緩沖的區段（一個簇大小）
MEMORY_AREA_PAGED_POOL://內核分頁池中的區段
MEMORY_AREA_KERNEL_STACK：//用于內核棧中的區段
MEMORY_AREA_PEB_OR_TEB://用于PEB、TEB的區段
MEMORY_AREA_MDL_MAPPING：//內核中專用于建立MDL映射的區段
MEMORY_AREA_CONTINUOUS_MEMORY：//對應的物理頁面也連續的區段
MEMORY_AREA_IO_MAPPING：//內核空間中用于映射外設內存（如顯存）的區段
MEMORY_AREA_SHARED_DATA：//內核空間中用于與用戶空間共享的區段
Struct ?MM_REGION ?//區塊描述符
{
? ?ULONG type;//指本區塊的分配類型（預定型分配、提交型分配），又叫映射狀態（已映射、尚未映
射）
? ?ULONG protect;//本區塊的訪問保護權限,可讀、可寫、可執行的組合
? ?ULONG length;//區塊長度，對齊頁面大小（4KB）
? ?LIST_ENTRY RegionListEntry;//用來掛入所在區段的區塊鏈表
}
內存以區段為分配單位，一個區段內部，又按分配類型、保護屬性劃分區塊。一個區塊包含一到多個內
存頁面，分配類型相同并且保護權限相同的區域組成一個個的區塊，因此，稱為“同屬性區塊”。一個
區段內部，相鄰區塊之間的屬性肯定是不相同的（分配類型或保護權限不同），若兩個相鄰區塊的屬性
相同了，會自動合并成一個新的區塊。
......
......
......
創建好了section對象后，就可以讓任意進程拿去映射了，不過映射是以視圖為單位進行的
【section. ?segment. ?視圖. 頁面】,這是這四者之間的層級關系，請牢記
NtMapViewOfSection(hSection, ViewOffset, ViewSize, ? AllocType, protect, ?hProcess, void**
BaseAddr )
{
? ?PreviousMode=ExGetPreviousMode();
? ?If(PreviousMode == UserMode)
? ? ? ?參數檢查；
? ?ViewOffset=Align4kb(ViewOffset);
? ?ViewSize=Align4kb(ViewSize);
? ?ObReferenceObjectByHandle(hSection---> Section);//獲得對應的對象
? ?MmMapViewOfSection(Section, ViewOffset,ViewSize, AllocType, protect, hProcess, void**
BaseAddr );
}
MmMapViewOfSection(Section, ViewOffset, ViewSize , AllocType, protect, hProcess, void**
BaseAddr )
{
? ?AddressSpace=process->VadRoot;//那個進程的用戶地址空間
//若是PE文件的section,則加載映射文件中的每個segment，注意此時的ViewOffset和ViewSize參數不
起作用，將自動把每個完整segment當做一個視圖來映射。
? ?If(Section->AllocationAttribute ?& ?SEC_IMAGE)
? ?{
? ? ? ULONG i;
? ? ? ULONG NrSegments;
? ? ? ULONG_PTR ImageBase;
? ? ? ULONG ImageSize;
? ? ? PMM_IMAGE_SECTION_OBJECT ImageSectionObject;
? ? ? PMM_SECTION_SEGMENT SectionSegments;
? ? ? ImageSectionObject = Section->ImageSection;
? ? ? SectionSegments = ImageSectionObject->Segments;//節數組
? ? ? NrSegments = ImageSectionObject->NrSegments;//該pe文件中的節數
? ? ? ImageBase = (ULONG_PTR)*BaseAddress;
? ? ? if (ImageBase == 0)
? ? ? ? ?ImageBase = ImageSectionObject->ImageBase;
? ? ? ImageSize = 0;
? ? ? //下面的循環遍歷該pe文件中所有需要加載的節，計算所有節的大小總和
? ? ? for (i = 0; i < NrSegments; i++)
? ? ? {
? ? ? ? ?if (!(SectionSegments[i].Characteristics & IMAGE_SCN_TYPE_NOLOAD))//所需要加載這個
節
? ? ? ? ?{
? ? ? ? ? ? ULONG_PTR MaxExtent;
? ? ? ? ? ? //該節的rva+該節的對齊4KB長度
? ? ? ? ? ? MaxExtent=SectionSegments[i].VirtualAddress + SectionSegments[i].Length;
? ? ? ? ? ? ImageSize = max(ImageSize, MaxExtent);
? ? ? ? ?}
? ? ? }
? ? ? ImageSectionObject->ImageSize = ImageSize;
? ? ? //如果該pe文件期望加載的區域中有任何一個地方被占用了，重定位，dll文件一般都會重定位
? ? ? if (MmLocateMemoryAreaByRegion(AddressSpace, ImageBase,PAGE_ROUND_UP(ImageSize)))
? ? ? {
? ? ? ? ?if ((*BaseAddress) != NULL)//如果用戶的要求是必須加載到預期地址處，返回失敗！
? ? ? ? ? ? return(STATUS_UNSUCCESSFUL);
? ? ? ? ?ImageBase = MmFindGap(AddressSpace, ImageSize, PAGE_SIZE, FALSE);//重定位，找空閑
區
? ? ? }
? ? ? //一次性加載映射該pe文件中的所有節
? ? ? for (i = 0; i < NrSegments; i++)
? ? ? {
? ? //注意pe文件中有的節是不用加載的
? ? ? ? ?if (!(SectionSegments[i].Characteristics & IMAGE_SCN_TYPE_NOLOAD))
? ? ? ? ?{
? ? ? ? ? ? PVOID SBaseAddress = ?((char*)ImageBase + (SectionSegments[i].VirtualAddress);
? ? ? ? ? ? //把該節整體當做一個view進行映射。由此可見，pe文件中的每個節也是一個視圖型區段
? ? ? ? ? ? MmMapViewOfSegment(AddressSpace,
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Section,
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?&SectionSegments[i],//該視圖所在的第一個節
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?&SBaseAddress,//該節的預期映射地址
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?SectionSegments[i].Length,//ViewSize=整個節的長度
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?SectionSegments[i].Protection,
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?0,//ViewOffset=0
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?0);
? ? ? ? ?}
? ? ? }
? ? ? *BaseAddress = (PVOID)ImageBase;//返回該PE文件實際加載映射的地址
? ?}
? ?Else//普通數據文件和頁文件的section，都只有一個segment
? ?{
? ? ? MmMapViewOfSegment(AddressSpace, ?section, section->segmen, ? ViewOffset, ViewSize , ?
AllocType & MEM_TOPDOWN, ?protect, ?hProcess, ?void** BaseAddr);
? ?}
}
MmMapViewOfSegment(AddressSpace, ?section, segmen, ? ViewOffset, ViewSize , ?AllocType, ?
protect, ?hProcess, ?void** BaseAddr);
{
? ?MEMORY_AREA* ?Area;
? ?MmCreateMemoryArea(AddressSpace, ?視圖型區段, ?BaseAddr,ViewSize, ?protect, AllocType,
&Area);
? ?//記錄本視圖區段映射的是哪個section的哪個segment中的哪個位置
? ?Area->Data.SectionData.Section=Section;
? ?Area->Data.SectionData.Segment=segment;
? ?Area->Data.SectionData.ViewOffset=ViewOffset;
? ?Area->Data.SectionData..WriteCopyView=FALSE;//視圖型區段默認是不‘寫復制’的
? ?初始化Area區段中的區塊鏈表;//初始時，整個區段中就一個區塊
}
......
? ?if (NumberOfBytes > PageSize-BlockHeadSize)//超出一個頁面
? ?{
? ? ? ? //大于一個頁面大小的分配特殊處理;
? ? ? ? Retun ?MiAllocatePoolPages(PoolType, NumberOfBytes);;
? ?}
? ?For(遍歷空閑塊表)
? ?{
If(找到了一個合乎大小的空閑塊)
{
? ? ? ? ? 從空閑塊鏈表中摘下一個合乎大小的塊；
? ? ? ? ? 前后合并相鄰塊；//是在一個頁面內分隔、合并
? ? ? ? ? Return 找到的塊地址;
? ? ? }?
? ?}
? ?//如果已有的空閑鏈表找不到這樣一個大小的塊
? ?在池中分配一個新的頁面;
? ?在新頁面中把前面的部分割出來，后面剩余的部分掛入池中的空閑塊表中;
? ?Return 分得的塊地址 ?
}
內核中池的分配原理同用戶空間中的堆一樣，都是先用VirtuAllocate去分配一個頁面，然后在這個頁面
中
尋找空閑塊，分給用戶。每個池塊的塊頭含有一些附加信息，如這個池塊的大小，池類型，該池塊的tag
標記等信息。用戶空間中的malloc,new堆塊分配函數，都是調用HeapAlloc API函數從堆管理器維護的N
個虛擬頁面中分出一些零散的塊出來，每個堆塊的塊頭、塊尾也含有一些附加信息，如堆塊大小，防止
堆塊溢出的cookie等信息。堆管理器則在底層調用VirtualAlloc ?API分配，增長虛擬頁面，提供底層服
務。
......
四 Windows內核情景分析---內核對象
寫過Windows應用程序的朋友都常常聽說“內核對象”、“句柄”等術語卻無從得知他們的內核實現到底是怎樣的, 本篇文章就揭開這些技術的神秘面紗。
常見的內核對象有：
Job、Directory（對象目錄中的目錄）、SymbolLink（符號鏈接），Section（內存映射文件）、Port（LPC端口）、IoCompletion（Io完成端口）、File（并非專指磁盤文件）、同步對象（Mutex、Event、Semaphore、Timer）、Key（注冊表中的鍵）、Token（用戶/組令牌）、Process、Thread、Pipe、Mailslot、Debug（調試端口）等
內核對象就是一個數據結構，就是一個struct結構體，各種不同類型的對象有不同的定義，本片文章不專門介紹各個具體對象類型的結構體定義，只講述一些公共的對象管理機制。
至于各個具體對象類型的結構體定義，后文逐步會有詳細介紹。
?
所有內核對象都遵循統一的使用模式：
第一步：先創建對象；
第二步：打開對象，得到句柄（可與第一步合并在一起，表示創建時就打開）
第三步：通過API訪問對象；
第四步，關閉句柄，遞減引用計數；
第五步：句柄全部關完并且引用計數降到0后，銷毀對象。
句柄就是用來維系對象的把柄，就好比N名纖夫各拿一條繩，同拉一艘船。每打開一次對象就可拿到一個句柄，表示拿到該對象的一次訪問權。
內核對象是全局的，各個進程都可以訪問，比如兩個進程想要共享某塊內存來進行通信，就可以約定一個對象名，然后一個進程可以用CreatFileMapping（”SectionName”）創建一個section，而另一個進程可以用OpenFileMapping（”SectionName”）打開這個section，這樣這個section就被兩個進程共享了。
（注意：本篇說的都是內核對象的句柄。像什么hWnd、hDC、hFont、hModule、hHeap、hHook等等其他句柄，并不是指內核對象，因為這些句柄值不是指向進程句柄表中的索引，而是另外一種機制）
各個對象的結構體雖然不同，但有一些通用信息記錄在對象頭中，看下面的結構體定義
typedef struct _OBJECT_HEADER
{
? ? LONG PointerCount;//引用計數
? ? union
? ? {
? ? ? ? LONG HandleCount;//本對象的打開句柄計數（每個句柄本身也占用一個對象引用計數）
? ? ? ? volatile VOID* NextToFree;//下一個要延遲刪除的對象
? ? };
? ? OBJECT_TYPE* Type;//本對象的類型，類型本身也是一種內核對象，因此我習慣叫‘類型對象’
? ? UCHAR NameInfoOffset;//對象名的偏移（無名對象沒有Name）
? ? UCHAR HandleInfoOffset;//各進程的打開句柄統計信息數組
? ? UCHAR QuotaInfoOffset;//對象本身實際占用內存配額(當不等于該類對象的默認大小時要用到這個)
? ? UCHAR Flags;//對象的一些屬性標志
? ? union
? ? {
? ? ? ? OBJECT_CREATE_INFORMATION* ObjectCreateInfo;//來源于創建對象時的OBJECT_ATTRIBUTES
? ? ? ? PVOID QuotaBlockCharged;
? ? };
? ? PSECURITY_DESCRIPTOR SecurityDescriptor;//安全描述符（對象的擁有者、ACL等信息）
? ? QUAD Body;//通用對象頭后面緊跟著真正的結構體（這個字段是后面真正結構體中的第一個成員）
} OBJECT_HEADER, *POBJECT_HEADER;
如上，Body就是對象體中的第一個字段，頭部后面緊跟具體對象類型的結構體定義
typedef struct _OBJECT_HEADER_NAME_INFO
{
? ? POBJECT_DIRECTORY Directory;//對象目錄中的父目錄（不一定是文件系統中的目錄）
? ? UNICODE_STRING Name;//相對于Directory的路徑或者全路徑
ULONG QueryReferences;//對象名查詢操作計數
…
} OBJECT_HEADER_NAME_INFO, *POBJECT_HEADER_NAME_INFO;
typedef struct _OBJECT_HEADER_CREATOR_INFO
{
? ? LIST_ENTRY TypeList;//用來掛入所屬‘對象類型’中的鏈表（也即類型對象內部的對象鏈表）
PVOID CreatorUniqueProcess;//表示本對象是由哪個進程創建的
…
} OBJECT_HEADER_CREATOR_INFO, *POBJECT_HEADER_CREATOR_INFO;
對象頭中記錄了NameInfo、HandleInfo、QuotaInfo、CreatorInfo這4種可選信息。如果這4種可選信息全部都有的話，整個對象的布局從低地址到高地址的內存布局為：
QuotaInfo-> HandleInfo->NameInfo->CreatorInfo->對象頭->對象體;這4種可選信息的相對位置倒不重要，但是必須記住，他們都是在對象頭中的上方（也即對象頭上面的低地址端）。以下為了方便，不妨叫做“對象頭中的可選信息”、“頭部中的可選信息”。
于是有宏定義：
//由對象體的地址得到對象頭的地址
#define OBJECT_TO_OBJECT_HEADER(pBody) ? ?CONTAINING(pBody,OBJECT_HEADER,Body)
//得到對象的名字
#define OBJECT_HEADER_TO_NAME_INFO(h)
? ?h->NameInfoOffset?(h - h->NameInfoOffset):NULL
//得到對象的創建者信息
#define OBJECT_HEADER_TO_CREATOR_INFO(h)
h->Flags & OB_FLAG_CREATOR_INFO?h-sizeof(OBJECT_HEADER_CREATOR_INFO):NULL
所有有名字的對象都會進入內核中的‘對象目錄’中，對象目錄就是一棵樹。內核中有一個全局指針變量ObpRootDirectoryObject，就指向對象目錄樹的根節點，根節點是一個根目錄。
對象目錄的作用就是用來將對象路徑解析為對象地址。給定一個對象路徑，就可以直接在對象目錄中找到對應的對象。就好比給定一個文件的全路徑，一定能從磁盤的根目錄中向下一直搜索找到對應的文件。
如某個設備對象的對象名（全路徑）是”\Device\MyCdo”,那么從根目錄到這個對象的路徑中：
Device是根目錄中的子目錄，MyDevice則是Device目錄中的子節點。
對象有了名字，應用程序就可以直接調用CreateFile打開這個對象，獲得句柄，沒有名字的對象無法記錄到對象目錄中，應用層看不到，只能由內核自己使用。
內核中各種類型的對象在對象目錄中的位置：
目錄對象：最常見，就是對象目錄中的目錄節點（可以作為葉節點）?
普通對象：只能作為葉節點
符號鏈接對象：只能作為葉節點
注意文件對象和注冊表中的鍵對象看似有文件名、鍵名，但此名非對象名。因此，文件對象與鍵對象是無名的，無法進入對象目錄中
根目錄也是一種目錄對象，符號鏈接對象可以鏈接到對象目錄中的任何節點，包括又鏈向另一個符號鏈接對象。
對象目錄中，每個目錄節點下面的子節點可以是
1、 普通對象節點
2、 子目錄
3、 符號鏈接
該目錄中的所有子節點對象都保存在該目錄內部的目錄項列表中。不過，這個列表不是一個簡單的數組，而是一個開式hash表，用來方便查找。根據該目錄中各個子對象名的hash值，將對應的子對象掛入對應的hash鏈表中，用hash方式存儲這些子對象以提高查找效率
目錄本身也是一種內核對象，其類型就叫“目錄類型”，現在就可以看一下這種對象的結構體定義：
typedef struct _OBJECT_DIRECTORY
{
? ? struct _OBJECT_DIRECTORY_ENTRY* ?HashBuckets[37];//37條hash鏈
? ? EX_PUSH_LOCK Lock;
? ? struct _DEVICE_MAP *DeviceMap;
? ? …
} OBJECT_DIRECTORY, *POBJECT_DIRECTORY;
如上，目錄對象中的所有子對象按hash值分門別類的安放在該目錄內部不同的hash鏈中
其中每個目錄項的結構體定義為：
typedef struct _OBJECT_DIRECTORY_ENTRY
{
? ? struct _OBJECT_DIRECTORY_ENTRY * ChainLink;//下一個目錄項（即下一個子節點）
? ? PVOID Object;//對象體的地址
? ? ULONG HashValue;//所在hash鏈
} OBJECT_DIRECTORY_ENTRY, *POBJECT_DIRECTORY_ENTRY;
看到沒，每個目錄項記錄了指向的對象的地址，同時間接記錄了對象名信息
下面這個函數用來在指定的目錄中查找指定名稱的子對象
VOID*
ObpLookupEntryDirectory(IN POBJECT_DIRECTORY Directory,
? ? ? ? ? ? ? ? ? ? ? ? IN PUNICODE_STRING Name,
? ? ? ? ? ? ? ? ? ? ? ? IN ULONG Attributes,
? ? ? ? ? ? ? ? ? ? ? ? IN POBP_LOOKUP_CONTEXT Context)
{
? ? BOOLEAN CaseInsensitive = FALSE;
? ? PVOID FoundObject = NULL;?
? ? //表示對象名是否嚴格大小寫匹配查找
? ? if (Attributes & OBJ_CASE_INSENSITIVE) CaseInsensitive = TRUE;
HashValue=CalcHash(Name->Buffer);//計算對象名的hash值
? ? HashIndex = HashValue % 37;//獲得對應的hash鏈索引
? ? //記錄本次是在那條hash中查找
? ? Context->HashValue = HashValue;
? ? Context->HashIndex = (USHORT)HashIndex;
? ? if (!Context->DirectoryLocked)
? ? ? ? ObpAcquireDirectoryLockShared(Directory, Context);//鎖定目錄，以便在其中進行查找操作
? ??
? ? //遍歷對應hash鏈中的所有對象
? ? AllocatedEntry = &Directory->HashBuckets[HashIndex];
? ? LookupBucket = AllocatedEntry;
? ? while ((CurrentEntry = *AllocatedEntry))
? ? {
? ? ? ? if (CurrentEntry->HashValue == HashValue)
? ? ? ? {
? ? ? ? ? ? ObjectHeader = OBJECT_TO_OBJECT_HEADER(CurrentEntry->Object);
? ? ? ? ? ? HeaderNameInfo = OBJECT_HEADER_TO_NAME_INFO(ObjectHeader);
? ? ? ? ? ? if ((Name->Length == HeaderNameInfo->Name.Length) &&
? ? ? ? ? ? ? ? (RtlEqualUnicodeString(Name, &HeaderNameInfo->Name, CaseInsensitive)))
? ? ? ? ? ? {
? ? ? ? ? ? ? ? break;//找到對應的子對象
? ? ? ? ? ? }
? ? ? ? }
? ? ? ? AllocatedEntry = &CurrentEntry->ChainLink;
? ? }
? ? if (CurrentEntry)//如果找到了子對象
? ? {
? ? ? ? if (AllocatedEntry != LookupBucket)
? ? ? ? ? ? 將找到的子對象掛入鏈表的開頭，方便下次再次查找同一對象時直接找到；
? ? ? ? FoundObject = CurrentEntry->Object;
? ? }
? ? if (FoundObject) //如果找到了子對象
? ? {
? ? ? ? ObjectHeader = OBJECT_TO_OBJECT_HEADER(FoundObject);
? ? ? ? ObpReferenceNameInfo(ObjectHeader);//遞增對象名字的引用計數
? ? ? ? ObReferenceObject(FoundObject);//注意遞增了對象本身的引用計數
? ? ? ? if (!Context->DirectoryLocked)
? ? ? ? ? ? ObpReleaseDirectoryLock(Directory, Context); ? ??
? ? }
? ? //檢查本次函數調用前，查找上下文中是否已有一個先前的中間節點對象，若有就釋放
? ? if (Context->Object)
? ? {
? ? ? ? ObjectHeader = OBJECT_TO_OBJECT_HEADER(Context->Object);
? ? ? ? HeaderNameInfo = OBJECT_HEADER_TO_NAME_INFO(ObjectHeader);
? ? ? ? ObpDereferenceNameInfo(HeaderNameInfo);
? ? ? ? ObDereferenceObject(Context->Object);
? ? }
? ? Context->Object = FoundObject;
? ? return FoundObject;//返回找到的子對象
}
如上，hash查找子對象，找不到就返回NULL。
注意由于這個函數是在遍歷路徑的過程中逐節逐節的調用的，所以會臨時查找中間的目錄節點，記錄到Context中。
......
五 windows內核情景分析---進程線程
本篇主要講述進程的啟動過程、線程的調度與切換、進程掛靠
進程的啟動過程：
BOOL CreateProcess
(
? LPCTSTR lpApplicationName, ? ? ? ? ? ? ? ? //
? LPTSTR lpCommandLine, ? ? ? ? ? ? ? ? ? ? ?// command line string
? LPSECURITY_ATTRIBUTES lpProcessAttributes, // SD
? LPSECURITY_ATTRIBUTES lpThreadAttributes, ?// SD
? BOOL bInheritHandles, ? ? ? ? ? ? ? ? ? ? //?
? DWORD dwCreationFlags, ? ? ? ? ? ? ? ? ? ?// creation flags
? LPVOID lpEnvironment, ? ? ? ? ? ? ? ? ? ? // new environment block
? LPCTSTR lpCurrentDirectory, ? ? ? ? ? ? ? // current directory name
? LPSTARTUPINFO lpStartupInfo, ? ? ? ? ? ? ? // startup information
? LPPROCESS_INFORMATION lpProcessInformation // process information
);
這個Win32API在內部最終調用如下:
CreateProcess(…)
{
? ?…
? ?NtCreateProcess(…);//間接調用這個系統服務，先創建進程
? ?NtCreateThread(…);//間接調用這個系統服務，再創建該進程的第一個線程（也即主線程）
? ?…
}
進程的4GB地址空間分兩部分,內核空間+用戶空間
看下面幾個定義:
#define MmSystemRangeStart ?0x80000000 //系統空間的起點
#define MM_USER_PROB_ADDRESS ?MmSystemRangeStart-64kb ?//除去高端的64kb隔離區
#define MM_HIGHEST_USER_ADDRESS ? MmUserProbAddress-1 //實際的用戶空間中最高可訪問地址
#define MM_LOWEST_USER_ADDRESS ?64kb ?//實際的用戶空間中最低可訪問地址
#define KI_USER_SHARED_DATA ?0xffdf0000 ? //內核空間與用戶空間共享的一塊區域
由此可見，用戶地址空間的范圍實際上是從 ?64kb---->0x80000000-64kb 這塊區域。
（訪問NULL指針報異常的原因就是NULL（0）落在了最前面的64kb保留區中）
內核中提供了一個全局結構變量，該結構的類型是KUSER_SHARED_DATA。內核中的那個結構體變量所在的虛擬頁面起始地址為：0xffdf0000，大小為一個頁面大小。這個內核頁面對應的物理內存頁面也映射到了每個進程的用戶地址空間中，而且是固定映在同一處：0x7ffe0000。這樣，用戶空間的程序直接訪問用戶空間中的這個虛擬地址，就相當于直接訪問了內核空間中的那個公共頁面。所以，那個內核頁面稱之為內核空間提供給各個進程的一塊共享之地。（事實上，這個公共頁面非常有用，可以在這個頁面中放置代碼,應用程序直接在r3層運行這些代碼，如在內核中進行IAT hook）
......
六 Windows內核情景分析 --APC
明白了APC大致原理后，現在詳細看一下APC的工作原理。
APC分兩種，用戶APC、內核APC。前者指在用戶空間執行的APC，后者指在內核空間執行的APC。
先看一下內核為支持APC機制提供的一些基礎結構設施。
Typedef struct _KTHREAD
{
? ?…
? ?KAPC_STATE ?ApcState;//表示本線程當前使用的APC狀態（即apc隊列的狀態）
? ?KAPC_STATE ?SavedApcState;//表示保存的原apc狀態，備份用
? ?KAPC_STATE* ApcStatePointer[2];//狀態數組，包含兩個指向APC狀態的指針
? ?UCHAR ApcStateIndex;//0或1，指當前的ApcState在ApcStatePointer數組中的索引位置
? ?UCHAR ApcQueueable;//指本線程的APC隊列是否可插入apc
? ?ULONG KernelApcDisable;//禁用標志
//專用于掛起操作的APC（這個函數在線程一得到調度就重新進入等待態,等待掛起計數減到0）
? ?KAPC SuspendApc;
? ?… ??
}KTHREAD;
?
Typedef struct _KAPC_STATE //APC隊列的狀態描述符
{
? ?LIST_EBTRY ?ApcListHead[2];//每個線程有兩個apc隊列
? ?PKPROCESS Process;//當前線程所在的進程
? ?BOOL KernelApcInProgress;//指示本線程是否當前正在 內核apc
? ?BOOL KernelApcPending;//表示內核apc隊列中是否有apc
? ?BOOL UserApcPending;//表示用戶apc隊列中是否apc
}
Typedef enum _KAPC_ENVIRONMENT
{
? ?OriginalApcEnvironment,//0，狀態數組索引
? ?AttachedApcEnvironment;//1，狀態數組索引
? ?CurrentApc Environment;//2，表示使用當前apc狀態
? ?CurrentApc Environment;//3，表示使用插入apc時那時的線程的apc狀態
}
七 Windows內核情景分析---線程同步
基于同步對象的等待、喚醒機制：
一個線程可以等待一個對象或多個對象而進入等待狀態（也叫睡眠狀態），另一個線程可以觸發那個等待對象，喚醒在那個對象上等待的所有線程。
一個線程可以等待一個對象或多個對象，而一個對象也可以同時被N個線程等待。這樣，線程與等待對象之間是多對多的關系。他們之間的等待關系由一個隊列和一個‘等待塊’來控制，等待塊就是線程與等待目標對象之間的紐帶。
WaitForSingleObject可以等待那些“可等待對象”，哪些對象是‘可等待’的呢？進程、線程、作業、文件對象、IO完成端口、可等待定時器、互斥、事件、信號量等，這些都是‘可等待’對象，可用于WaitForSingleObject等函數。
‘可等待’對象又分為‘可直接等待對象’和‘可間接等待對象’
互斥、事件、信號量、進程、線程這些對象由于內部結構中的自第一個字段是DISPATCHER_HEADER結構（可以看成是繼承了DISPATCHER_HEADER），因此是可直接等待的。而文件對象不帶這個結構，但文件對象內部有一個事件對象，因此，文件對象是‘可間接等待對象’。
比如：信號量就是一種可直接等待對象,它的結構如下:
Struct KSEMAPHORE
{
? ?DISPATCHER_HEADER Header;//公共頭
? ?LONG Limit;//最大信號量個數
}
Struct DISPATCHER_HEADER
{
? ?…
? ?LONG SignalState;//信號狀態量（>0表示有信號，<=0表示無信號）
? ?LIST_ENTRY WaitListHead;//等待塊隊列
? ?…
}
WaitForSingleObject內部最終調用下面的系統服務
NTSTATUS
NtWaitForSingleObject(IN HANDLE ObjectHandle,//直接或間接可等待對象的句柄
? ? ? ? ? ? ? ? ? ? ? IN BOOLEAN Alertable,//表示本次等待操作是否可被吵醒(即被強制喚醒)
? ? ? ? ? ? ? ? ? ? ? IN PLARGE_INTEGER TimeOut ?OPTIONAL)//超時
{
? ? PVOID Object, WaitableObject;
? ? KPROCESSOR_MODE PreviousMode = ExGetPreviousMode();
? ? LARGE_INTEGER SafeTimeOut;
? ? NTSTATUS Status;
? ? if ((TimeOut) && (PreviousMode != KernelMode))
? ? {
? ? ? ? _SEH2_TRY
? ? ? ? {
? ? ? ? ? ? SafeTimeOut = ProbeForReadLargeInteger(TimeOut);
? ? ? ? ? ? TimeOut = &SafeTimeOut;
? ? ? ? }
? ? ? ? _SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER)
? ? ? ? {
? ? ? ? ? ? _SEH2_YIELD(return _SEH2_GetExceptionCode());
? ? ? ? }
? ? ? ? _SEH2_END;
? ? }
? ? Status = ObReferenceObjectByHandle(ObjectHandle,SYNCHRONIZE,NULL,PreviousMode,
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?&Object,NULL);
? ? if (NT_SUCCESS(Status))
{
? ? //得到那個對象的‘可直接等待對象’DefaultObject
? ? ? ? WaitableObject = OBJECT_TO_OBJECT_HEADER(Object)->Type->DefaultObject;
? ? ? ? if (IsPointerOffset(WaitableObject))//if DefaultObject是個偏移，不是指針
? ? ? ? {
? ? ? ? ? ? //加上偏移值，獲得內部的‘可直接等待對象’
? ? ? ? ? ? WaitableObject = (PVOID)((ULONG_PTR)Object + (ULONG_PTR)WaitableObject);
? ? ? ? }
? ? ? ? _SEH2_TRY
? ? ? ? {
? ? ? ? ? ? Status = KeWaitForSingleObject(WaitableObject,//這個函數只能等待‘直接等待對象’
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?UserRequest,PreviousMode,Alertable,TimeOut);
? ? ? ? }
? ? ? ? _SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER)
? ? ? ? {
? ? ? ? ? ? Status = _SEH2_GetExceptionCode();
? ? ? ? }
? ? ? ? _SEH2_END;
? ? ? ? ObDereferenceObject(Object);
? ? }
? ? return Status;
}
#define IsPointerOffset(Ptr) ((LONG)(Ptr) >= 0)
如上，每個對象的對象類型都有一個默認的可直接等待對象，要么直接指向對象，要么是個偏移值。
如果是個偏移值，那么DefaultObject值的最高位為0，否則為1。
......
八 windows內核情景分析--窗口消息
消息與鉤子
眾所周知,Windows系統是消息驅動的,現在我們就來看Windows的消息機制.
早期的Windows的窗口圖形機制是在用戶空間實現的,后來為了提高圖形處理效率,將這部分移入內核空間,在Win32k.sys模塊中實現。這個模塊作為一個擴展的內核模塊，提高了一個擴展額系統服務表，專用于窗口圖形操作，相應的，這個模塊中添加了一個擴展系統調用服務表Shadow SSDT，以及一個擴展的系統調用服務表描述符表：KeServiceDescriptorTableShadow.（系統中 不僅有兩張SSDT，還有兩張系統服務表描述符表）。當一個線程首次調用這個模塊中的系統服務函數時，這個線程就自然變成了GUI線程。GUI線程結構的ServiceTable指向的就是這個shadow描述符表。
指向這個表的系統服務號的bit12位（也即第13位）為1，如0x1XXX表示使用的是shadow服務表。
每個線程創建時都是普通線程，但是只要那個線程在運行的過程中發起了一次對win32k.sys模塊中的系統調用，就會轉變成GUI線程，下面的函數就是這個用途。
NTSTATUS ?PsConvertToGuiThread(VOID)
{
? ? ULONG_PTR NewStack;
? ? PVOID OldStack;
? ? PETHREAD Thread = PsGetCurrentThread();
? ? PEPROCESS Process = PsGetCurrentProcess();
? ? NTSTATUS Status;
? ? if (KeGetPreviousMode() == KernelMode) return STATUS_INVALID_PARAMETER;
? ? ASSERT(PspW32ProcessCallout != NULL);//確保win32k.sys模塊已加載到內存
? ? if (Thread->Tcb.ServiceTable != KeServiceDescriptorTable)
? ? ? ? return STATUS_ALREADY_WIN32;//表示先前已經轉換為GUI線程了
? ? if (!Thread->Tcb.LargeStack)//if 尚未換成大內核棧
? ? {
? ? ? ? NewStack = (ULONG_PTR)MmCreateKernelStack(TRUE, 0);//分配一個64KB的大內核棧
? ? ? ? //更為大內核棧
? ? ? ? OldStack = KeSwitchKernelStack(NewStack, (NewStack - KERNEL_STACK_SIZE));
? ? ? ? MmDeleteKernelStack(OldStack, FALSE);//銷毀原來的普通內核棧
? ? }
? ? if (!Process->Win32Process)//if 尚未分配W32PROCESS結構（也即if是該進程中的第一個GUI線程）
? ? ? ? Status = PspW32ProcessCallout(Process, TRUE);//分配Win32Process結構（表示GUI進程）
Thread->Tcb.ServiceTable = KeServiceDescriptorTableShadow;//關鍵。更改描述符表
//為當前線程分配一個W32THREAD結構
? ? Status = PspW32ThreadCallout(Thread, PsW32ThreadCalloutInitialize);
? ? if (!NT_SUCCESS(Status)) Thread->Tcb.ServiceTable = KeServiceDescriptorTable;//改為原來的
? ? return Status;
}
如上，每個線程在轉換為GUI線程時，必須換用64KB的大內核棧，因為普通的內核棧只有12KB大小，不能支持開銷大的圖形任務。然后分配一個W32PROCESS結構，將進程轉換為GUI進程，然后分配W32THREAD結構，更改系統服務表描述符表。上面的PspW32ProcessCallout和PspW32ThreadCallout函數都是回調函數，分別指向win32k.sys模塊中的Win32kProcessCallback、Win32kThreadCallback函數。
......
?
總結
以上是生活随笔為你收集整理的windows 内核情景分析的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Bing地图REST服务
- 下一篇： 虚拟仪器软件LabView使用初步了解