基本介紹
- 中文名：Windows核心調試器
- 過程：通過串口調試
- 先了解：KdpTrace、KdpStub
- 功能的函式：KdpTrap
WinDBG,SoftICE,
WinDBG
WinDBG和用戶調試器一點很大不同是核心調試器在一台機器上啟動，通過串口調試另一個相聯繫的以Debug方式啟動的系統，這個系統可以是虛擬機上的系統，也可以是另一台機器上的系統（這只是微軟推薦和實現的方法，其實象SoftICE這類核心調試器可以實現單機調試）。很多人認為主要功能都是在WinDBG里實現，事實上並不是那么一回事，windows已經把核心調試的機制集成進了核心，WinDBG、kd之類的核心調試器要做的僅僅是通過串列傳送特定格式數據包來進行聯繫，比如中斷系統、中斷點、顯示記憶體數據等等。然後把收到的數據包經過WinDBG處理顯示出來。
在進一步介紹WinDBG之前，先介紹兩個函式：KdpTrace、KdpStub，我在《windows異常處理流程》一文里簡單提過這兩個函式。現在再提一下，當異常發生於核心態下，會調用KiDebugRoutine兩次，異常發生於用戶態下，會調用KiDebugRoutine一次，而且第一次調用都是剛開始處理異常的時候。
當WinDBG未被載入時KiDebugRoutine為KdpStub，處理也很簡單，主要是對由int 0x2d引起的異常如DbgPrint、DbgPrompt、載入卸載SYMBOLS（關於int 0x2d引起的異常將在後面詳細介紹）等，把Context.Eip加1，跳過int 0x2d後面跟著的int 0x3指令。
真正實現了WinDBG功能的函式是KdpTrap，它負責處理所有STATUS_BREAKPOINT和STATUS_SINGLE_STEP（單步）異常。STATUS_BREAKPOINT的異常包括int 0x3、DbgPrint、DbgPrompt、載入卸載SYMBOLS。DbgPrint的處理最簡單，KdpTrap直接向調試器發含有字元串的包。DbgPrompt因為是要輸出並接收字元串，所以先將含有字元串的包傳送出去，再陷入循環等待接收來自調試器的含有回覆字元串的包。SYMBOLS的載入和卸載通過調用KdpReportSymbolsStateChange，int 0x3斷點異常和int 0x1單步異常（這兩個異常基本上是核心調試器處理得最多的異常）通過調用KdpReportExceptionStateChange，這兩個函式很相似，都是通過調用KdpSendWaitContinue函式。KdpSendWaitContinue可以說是核心調試器功能的大管家，負責各個功能的分派。這個函式向核心調試器傳送要傳送的信息，比如當前所有暫存器狀態，每次單步後我們都可以發現暫存器的信息被更新，就是核心調試器接受它發出的包含最新機器狀態的包；還有SYMBOLS的狀態，這樣載入和卸載了SYMBOLS我們都能在核心調試器里看到相應的反應。然後KdpSendWaitContinue等待從核心調試器發來的包含命令的包，決定下一步該乾什麼。讓我們來看看KdpSendWaitContinue都能幹些什麼：
case DbgKdReadVirtualMemoryApi:
KdpReadVirtualMemory(&ManipulateState,&MessageData,ContextRecord);
break;
case DbgKdReadVirtualMemory64Api:
KdpReadVirtualMemory64(&ManipulateState,&MessageData,ContextRecord);
break;
case DbgKdWriteVirtualMemoryApi:
KdpWriteVirtualMemory(&ManipulateState,&MessageData,ContextRecord);
break;
case DbgKdWriteVirtualMemory64Api:
KdpWriteVirtualMemory64(&ManipulateState,&MessageData,ContextRecord);
break;
case DbgKdReadPhysicalMemoryApi:
KdpReadPhysicalMemory(&ManipulateState,&MessageData,ContextRecord);
break;
case DbgKdWritePhysicalMemoryApi:
KdpWritePhysicalMemory(&ManipulateState,&MessageData,ContextRecord);
break;
case DbgKdGetContextApi:
KdpGetContext(&ManipulateState,&MessageData,ContextRecord);
break;
case DbgKdSetContextApi:
KdpSetContext(&ManipulateState,&MessageData,ContextRecord);
break;
case DbgKdWriteBreakPointApi:
KdpWriteBreakpoint(&ManipulateState,&MessageData,ContextRecord);
break;
case DbgKdRestoreBreakPointApi:
KdpRestoreBreakpoin(&ManipulateState,&MessageData,ContextRecord);
break;
case DbgKdReadControlSpaceApi:
KdpReadControlSpace(&ManipulateState,&MessageData,ContextRecord);
break;
case DbgKdWriteControlSpaceApi:
KdpWriteControlSpace(&ManipulateState,&MessageData,ContextRecord);
break;
case DbgKdReadIoSpaceApi:
KdpReadIoSpace(&ManipulateState,&MessageData,ContextRecord);
break;
case DbgKdWriteIoSpaceApi:
KdpWriteIoSpace(&ManipulateState,&MessageData,ContextRecord);
break;
case DbgKdContinueApi:
if (NT_SUCCESS(ManipulateState.u.Continue.ContinueStatus) != FALSE) {
return ContinueSuccess;
} else {
return ContinueError;
}
break;
case DbgKdContinueApi2:
if (NT_SUCCESS(ManipulateState.u.Continue2.ContinueStatus) != FALSE) {
KdpGetStateChange(&ManipulateState,ContextRecord);
return ContinueSuccess;
} else {
return ContinueError;
}
break;
case DbgKdRebootApi:
KdpReboot();
break;
case DbgKdReadMachineSpecificRegister:
KdpReadMachineSpecificRegister(&ManipulateState,&MessageData,ContextRecord);
break;
case DbgKdWriteMachineSpecificRegister:
KdpWriteMachineSpecificRegister(&ManipulateState,&MessageData,ContextRecord);
break;
case DbgKdSetSpecialCallApi:
KdSetSpecialCall(&ManipulateState,ContextRecord);
break;
case DbgKdClearSpecialCallsApi:
KdClearSpecialCalls();
break;
case DbgKdSetInternalBreakPointApi:
KdSetInternalBreakpoint(&ManipulateState);
break;
case DbgKdGetInternalBreakPointApi:
KdGetInternalBreakpoint(&ManipulateState);
break;
case DbgKdGetVersionApi:
KdpGetVersion(&ManipulateState);
break;
case DbgKdCauseBugCheckApi:
KdpCauseBugCheck(&ManipulateState);
break;
case DbgKdPageInApi:
KdpNotSupported(&ManipulateState);
break;
case DbgKdWriteBreakPointExApi:
Status = KdpWriteBreakPointEx(&ManipulateState,
&MessageData,
ContextRecord);
if (Status) {
ManipulateState.ApiNumber = DbgKdContinueApi;
ManipulateState.u.Continue.ContinueStatus = Status;
return ContinueError;
}
break;
case DbgKdRestoreBreakPointExApi:
KdpRestoreBreakPointEx(&ManipulateState,&MessageData,ContextRecord);
break;
case DbgKdSwitchProcessor:
KdPortRestore ();
ContinueStatus = KeSwitchFrozenProcessor(ManipulateState.Processor);
KdPortSave ();
return ContinueStatus;
case DbgKdSearchMemoryApi:
KdpSearchMemory(&ManipulateState,&MessageData,ContextRecord);
break;
讀寫記憶體、搜尋記憶體、設定/恢復斷點、繼續執行、重啟等等，WinDBG里的功能是不是都能實現了?呵呵。
每次核心調試器接管系統是通過調用在KiDispatchException里調用KiDebugRoutine(KdpTrace），但我們知道要讓系統執行到KiDispatchException必須是系統發生了異常。而核心調試器與被調試系統之間只是通過串口聯繫，串口只會發生中斷，並不會讓系統引發異常。那么是怎么讓系統產生一個異常呢?答案就在KeUpdateSystemTime里，每當發生時鐘中斷後在HalpClockInterrupt做了一些底層處理後就會跳轉到這個函式來更新系統時間（因為是跳轉而不是調用，所以在WinDBG斷下來後回溯堆疊是不會發現HalpClockInterrupt的地址的），是系統中調用最頻繁的幾個函式之一。在KeUpdateSystemTime里會判斷KdDebuggerEnable是否為TRUE，若為TRUE則調用KdPollBreakIn判斷是否有來自核心調試器的包含中斷信息的包，若有則調用DbgBreakPointWithStatus，執行一個int 0x3指令，在異常處理流程進入了KdpTrace後將根據處理不同向核心調試器發包並無限循環等待核心調試的回應。現在能理解為什麼在WinDBG里中斷系統後堆疊回溯可以依次發現KeUpdateSystemTime->RtlpBreakWithStatusInstruction，系統停在了int 0x3指令上（其實int 0x3已經執行過了，只不過Eip被減了1而已），實際已經進入KiDispatchException->KdpTrap，將控制權交給了核心調試器。
系統與調試器互動的方法除了int 0x3外，還有DbgPrint、DbgPrompt、載入和卸載symbols，它們共同通過調用DebugService獲得服務。
NTSTATUS DebugService(
ULONG ServiceClass,
PVOID Arg1,
PVOID Arg2
）
{
NTSTATUS Status;
__asm {
mov eax,ServiceClass
mov ecx,Arg1
mov edx,Arg2
int 0x2d
int 0x3
mov Status,eax
}
return Status;
}
ServiceClass可以是BEAKPOINT_PRINT(0x1）、BREAKPOINT_PROMPT(0x2）、BREAKPOINT_LOAD_SYMBOLS(0x3）、BREAKPOINT_UNLOAD_SYMBOLS(0x4）。為什麼後面要跟個int 0x3，M$的說法是為了和int 0x3共享代碼（我沒弄明白啥意思-_-），因為int 0x2d的陷阱處理程式是做些處理後跳到int 0x3的陷阱處理程式中繼續處理。但事實上對這個int 0x3指令並沒有任何處理，僅僅是把Eip加1跳過它。所以這個int 0x3可以換成任何位元組。
int 0x2d和int 0x3生成的異常記錄結（EXCEPTION_RECORD)ExceptionRecord.ExceptionCode都是STATUS_BREAKPOINT(0x80000003），不同是int 0x2d產生的異常的ExceptionRecord.NumberParameters>0且ExceptionRecord.ExceptionInformation對應相應的ServiceClass比如BREAKPOINT_PRINT等。事實上，在核心調試器被掛接後，處理DbgPrint等傳送字元給核心調試器不再是通過int 0x2d陷阱服務，而是直接發包。用M$的話說，這樣更安全，因為不用調用KdEnterDebugger和KdExitDebugger。
最後說一下被調試系統和核心調試器之間的通信。被調試系統和核心調試器之間通過串口發數據包進行通信，Com1的IO連線埠地址為0x3f8，Com2的IO連線埠地址為0x2f8。在被調試系統準備要向核心調試器發包之前先會調用KdEnterDebugger暫停其它處理器的運行並獲取Com連線埠自旋鎖（當然，這都是對多處理器而言的），並設定連線埠標誌為保存狀態。發包結束後調用KdExitDebugger恢復。每個包就象網路上的數據包一樣，包含包頭和具體內容。包頭的格式如下：
typedef struct _KD_PACKET {
ULONG PacketLeader;
USHORT PacketType;
USHORT ByteCount;
ULONG PacketId;
ULONG Checksum;
} KD_PACKET,*PKD_PACKET;
PacketLeader是四個相同位元組的標識符標識發來的包，一般的包是0x30303030，控制包是0x69696969，中斷被調試系統的包是0x62626262。每次讀一個位元組，連續讀4次來識別出包。中斷系統的包很特殊，包里數據只有0x62626262。包標識符後是包的大小、類型、包ID、檢測碼等，包頭後面就是跟具體的數據。這點和網路上傳輸的包很相似。還有一些相似的地方比如每發一個包給調試器都會收到一個ACK答覆包，以確定調試器是否收到。若收到的是一個RESEND包或者很長時間沒收到回應，則會再發一次。對於向調試器傳送輸出字元串、報告SYMBOL情況等的包都是一接收到ACK包就立刻返回，系統恢復執行，系統的表現就是會卡那么短短一下。只有報告狀態的包才會等待核心調試器的每個控制包並完成對應功能，直到發來的包包含繼續執行的命令為止。無論發包還是收包，都會在包的末尾加一個0xaa，表示結束。
現在我們用幾個例子來看看調試流程。
記得我以前問過jiurl為什麼WinDBG的單步那么慢（相對softICE），他居然說沒覺得慢?*$&$^$^(&(&；（我ft。現在可以理解為什麼WinDBG的單步和從作業系統正常執行中斷下來為什麼那么慢了。單步慢是因為每單步一次除了必要的處理外，還得從串列收發包，怎么能不慢。中斷系統慢是因為只有等到時鐘中斷發生執行到KeUpdateSystemTime後被調試系統才會接受來自WinDBG的中斷包。現在我們研究一下為什麼在KiDispatchException里不能下斷點卻可以用單步跟蹤KiDispatchException的原因。如果在KiDispatchException中某處下了斷點，執行到斷點時系統發生異常又重新回到KiDispatchException處，再執行到int 0x3，如此往復造成了死循環，無法不能恢復原來被斷點int 0x3所修改的代碼。但對於int 0x1，因為它的引起是因為EFLAG暫存中TF位被置位，並且每次都自動被復位，所以系統可以被繼續執行而不會死循環。現在我們知道了內部機制，我們就可以調用KdXXX函式實現一個類似WinDBG之類的核心調試器，甚至可以替換KiDebugRoutine(KdpTrap）為自己的函式來自己實現一個功能更強大的調試器，呵呵。
SoftICE
SoftICE的原理和WinDBG完全不一樣。它通過替換正常系統中的中斷處理程式來獲得系統的控制權，也正因為這樣它才能夠實現單機調試。它的功能實現方法很底層，很少依賴與windows給的接口函式，大部分功能的實現都是靠IO連線埠讀寫等來完成的。
SoftICE替換了IDT表中以下的中斷（陷阱）處理程式：
0x1：單步陷阱處理程式
0x2：NMI不可禁止中斷
0x3：調試陷阱處理程式
0x6：無效操作碼陷阱處理程式
0xb：段不存在陷阱處理程式
0xc：堆疊錯誤陷阱處理程式
0xd：一般保護性錯誤陷阱處理程式
0xe：頁面錯誤陷阱處理程式
0x2d：調試服務陷阱處理程式
0x2e：系統服務陷阱處理程式
0x31：8042鍵盤控制器中斷處理程式
0x33：串口2(Com2）中斷處理程式
0x34：串口1(Com1）中斷處理程式
0x37：並口中斷處理程式
0x3c：PS/2滑鼠中斷處理程式
0x41：未使用
（這是在PIC系統上更換的中斷。如果是APIC系統的話更換的中斷號有不同，但同樣是更換這些中斷處理程式）
其中關鍵是替換了0x3 調試陷阱處理程式和0x31 i8042鍵盤中斷處理驅動程式（鍵盤是由i8042晶片控制的），SoftICE從這兩個地方獲取系統的控制權。
啟動softICE服務後SoftICE除了更換了IDT里的處理程式，還有幾點重要的，一是HOOK了i8042prt.sys里的READ_PORT_UCHAR函式，因為在對0x60連線埠讀後，會改變0x64連線埠對應控制暫存器的狀態。所以在SoftICE的鍵盤中斷控制程式讀了0x60連線埠後並返回控制權給正常的鍵盤中斷控制程式後，不要讓它再讀一次。還有就是把物理記憶體前1MB的地址空間通過調用MmMapIoSpace映射到虛擬的地址空間裡，裡面包括顯存物理地址，以後重畫螢幕就通過修改映射到虛擬地址空間的這段顯存內容就行了。
如果顯示模式是彩色模式，那么顯存起始地址是0xb8000，CRT索引暫存器連線埠0x3d4，CRT數據暫存器連線埠0x3d5。如果顯示模式是單色模式，那么顯存起始地址是0xb0000，CRT索引暫存器連線埠0x3b4，CRT數據暫存器連線埠0x3b5。首先寫索引暫存器選擇要進行設定的顯示控制內部暫存器之一（r0-r17），然後將參數寫到其數據暫存器連線埠。
i8042鍵盤控制器中斷控制驅動程式在每按下一個鍵和彈起一個鍵都會被觸發。SoftICE在HOOK了正常的鍵盤中斷控制程式獲得系統控制權後，首先從0x60連線埠讀出按下鍵的掃描碼然後向0x20連線埠傳送通用EOI(0x20）表示中斷已結束，如果沒有按下激活熱鍵（ctrl+d），則返回正常鍵盤中斷處理程式。如果是按下熱鍵則會判斷控制台（就是那個等待輸入命令的顯示代碼的黑色螢幕）是否被激活，未被激活的話則先激活。然後設定IRQ1鍵盤中斷的優先權為最高，同時設定兩個8259A中斷控制器里的中斷禁止暫存器（向0x21和0xa1發中斷掩碼，要禁止哪箇中斷就把哪一位設為1），只允許IRQ1（鍵盤中斷）、IRQ2（中斷控制器2級聯中斷，因為PS/2滑鼠中斷是歸8259A-2中斷控制器管的，只有開放IRQ2才能回響來自8259A-2管理的中斷）、IRQ12(PS/2滑鼠中斷，如果有的話），使系統這時只回響這3箇中斷。新的鍵盤和滑鼠中斷處理程式會建立一個緩衝區，保存一定數量的輸入掃描信息。當前面的工作都完成後會進入一段循環代碼，負責處理鍵盤和滑鼠輸入的掃描碼緩衝區，同時不斷地更新顯存的映射地址緩衝區重畫螢幕（這段循環代碼和WinDBG里循環等待從串口發來的包的原理是一樣的，都是在後台循環等待用戶的命令）。這段循環代碼是在激活控制台的例程里調用的，也就是說當控制台已被激活的話正常流程不會再次進入這段循環代碼的（廢話，再進入系統不就死循環了）。當有一個新的鍵按下時，都會重新調用一遍鍵盤中斷處理程式，因為控制台已激活，所以它只是簡單地更新鍵盤輸入緩衝區內容然後iret返回。它並不會返回正常的鍵盤中斷處理程式，因為那樣會交出控制權（想證明這點也很簡單，在SoftICE里斷正常的鍵盤中斷處理程式，然後g，1秒後在這裡斷下，這是我們可以F10，如果SoftICE會把控制權交給正常的鍵盤中斷處理程式的話，在這裡早就發生死循環了）。滑鼠中斷驅動也是一樣。這個時候實際iret返回到的還是那段循環代碼裡面，所以被調試的代碼並不會被執行，除非按下了F10之類的鍵，它會指示退出循環返回最開始時的中斷處理程式，然後再iret返回最開始中斷的地方。當然，因為設定了EFLAG里的TF位，執行了一個指令又會通過單步的處理程式進入那段循環的代碼。
而處理int 0x3也差不多，若沒有激活控制台則先激活並禁止除了鍵盤、滑鼠及8259A-2中斷控制器外的所有中斷，然後進入那段循環代碼。
作為對比同樣來看一下在SoftICE里處理int 0x3和單步的過程。當執行到int 0x3時，激活控制台並禁止中斷，然後將int 0x3指令前後範圍的指令反彙編並寫入顯存映射地址空間，並把最新的暫存器值也寫進去，最後在後台循環等待鍵盤輸入命令。當命令是F10時，設定好EFLAG的TF位，清除8259A中斷控制器里的中斷禁止暫存器，開放所有中斷，將控制台清除，從循環代碼中返回新鍵盤（或int 0x3）中斷處理程式，然後再返回到正常鍵盤（或int 0x3）中斷處理程式，由這裡iret到被中斷代碼處執行。執行了一個指令後因為發生單步異常又進入後台循環代碼。
