Windows內(nèi)核調(diào)試器原理淺析(三)
——
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的陷阱處理程序中繼續(xù)處理。但事實上對這個int 0x3指令并沒有任何處理,僅僅是把Eip加1跳過它。所以這個int 0x3可以換成任何字節(jié)。
int 0x2d和int 0x3生成的異常記錄結(jié)(EXCEPTION_RECORD)ExceptionRecord.ExceptionCode都是STATUS_BREAKPOINT(0x80000003),不同是int 0x2d產(chǎn)生的異常的ExceptionRecord.NumberParameters>0且ExceptionRecord.ExceptionInformation對應(yīng)相應(yīng)的ServiceClass比如BREAKPOINT_PRINT等。事實上,在內(nèi)核調(diào)試器被掛接后,處理DbgPrint等發(fā)送字符給內(nèi)核調(diào)試器不再是通過int 0x2d陷阱服務(wù),而是直接發(fā)包。用M$的話說,這樣更安全,因為不用調(diào)用KdEnterDebugger和KdExitDebugger。
最后說一下被調(diào)試系統(tǒng)和內(nèi)核調(diào)試器之間的通信。被調(diào)試系統(tǒng)和內(nèi)核調(diào)試器之間通過串口發(fā)數(shù)據(jù)包進行通信,Com1的IO端口地址為0x3f8,Com2的IO端口地址為0x2f8。在被調(diào)試系統(tǒng)準備要向內(nèi)核調(diào)試器發(fā)包之前先會調(diào)用KdEnterDebugger暫停其它處理器的運行并獲取Com端口自旋鎖(當然,這都是對多處理器而言的),并設(shè)置端口標志為保存狀態(tài)。發(fā)包結(jié)束后調(diào)用KdExitDebugger恢復(fù)。每個包就象網(wǎng)絡(luò)上的數(shù)據(jù)包一樣,包含包頭和具體內(nèi)容。包頭的格式如下:
typedef struct _KD_PACKET {
ULONG PacketLeader;
USHORT PacketType;
USHORT ByteCount;
ULONG PacketId;
ULONG Checksum;
} KD_PACKET, *PKD_PACKET;
PacketLeader是四個相同字節(jié)的標識符標識發(fā)來的包,一般的包是0x30303030,控制包是0x69696969,中斷被調(diào)試系統(tǒng)的包是0x62626262。每次讀一個字節(jié),連續(xù)讀4次來識別出包。中斷系統(tǒng)的包很特殊,包里數(shù)據(jù)只有0x62626262。包標識符后是包的大小、類型、包ID、檢測碼等,包頭后面就是跟具體的數(shù)據(jù)。這點和網(wǎng)絡(luò)上傳輸?shù)陌芟嗨?。還有一些相似的地方比如每發(fā)一個包給調(diào)試器都會收到一個ACK答復(fù)包,以確定調(diào)試器是否收到。若收到的是一個RESEND包或者很長時間沒收到回應(yīng),則會再發(fā)一次。對于向調(diào)試器發(fā)送輸出字符串、報告SYMBOL情況等的包都是一接收到ACK包就立刻返回,系統(tǒng)恢復(fù)執(zhí)行,系統(tǒng)的表現(xiàn)就是會卡那么短短一下。只有報告狀態(tài)的包才會等待內(nèi)核調(diào)試器的每個控制包并完成對應(yīng)功能,直到發(fā)來的包包含繼續(xù)執(zhí)行的命令為止。無論發(fā)包還是收包,都會在包的末尾加一個0xaa,表示結(jié)束。
現(xiàn)在我們用幾個例子來看看調(diào)試流程。
記得我以前問過jiurl為什么WinDBG的單步那么慢(相對softICE),他居然說沒覺得慢?*$&$^$^(&(&(我ft。。?,F(xiàn)在可以理解為什么WinDBG的單步和從操作系統(tǒng)正常執(zhí)行中斷下來為什么那么慢了。單步慢是因為每單步一次除了必要的處理外,還得從串行收發(fā)包,怎么能不慢。中斷系統(tǒng)慢是因為只有等到時鐘中斷發(fā)生執(zhí)行到KeUpdateSystemTime后被調(diào)試系統(tǒng)才會接受來自WinDBG的中斷包?,F(xiàn)在我們研究一下為什么在KiDispatchException里不能下斷點卻可以用單步跟蹤KiDispatchException的原因。如果在KiDispatchException中某處下了斷點,執(zhí)行到斷點時系統(tǒng)發(fā)生異常又重新回到KiDispatchException處,再執(zhí)行到int 0x3,如此往復(fù)造成了死循環(huán),無法不能恢復(fù)原來被斷點int 0x3所修改的代碼。但對于int 0x1,因為它的引起是因為EFLAG寄存中TF位被置位,并且每次都自動被復(fù)位,所以系統(tǒng)可以被繼續(xù)執(zhí)行而不會死循環(huán)。現(xiàn)在我們知道了內(nèi)部機制,我們就可以調(diào)用KdXXX函數(shù)實現(xiàn)一個類似WinDBG之類的內(nèi)核調(diào)試器,甚至可以替換KiDebugRoutine(KdpTrap)為自己的函數(shù)來自己實現(xiàn)一個功能更強大的調(diào)試器,呵呵。
評論