Windows內(nèi)核調(diào)試器原理淺析(一)

WinDBG和用戶調(diào)試器一點很大不同是內(nèi)核調(diào)試器在一臺機(jī)器上啟動，通過串口調(diào)試另一個相聯(lián)系的以Debug方式啟動的系統(tǒng)，這個系統(tǒng)可以是虛擬機(jī)上的系統(tǒng)，也可以是另一臺機(jī)器上的系統(tǒng)(這只是微軟推薦和實現(xiàn)的方法，其實象SoftICE這類內(nèi)核調(diào)試器可以實現(xiàn)單機(jī)調(diào)試)。很多人認(rèn)為主要功能都是在WinDBG里實現(xiàn)，事實上并不是那么一回事，windows已經(jīng)把內(nèi)核調(diào)試的機(jī)制集成進(jìn)了內(nèi)核，WinDBG、kd之類的內(nèi)核調(diào)試器要做的僅僅是通過串行發(fā)送特定格式數(shù)據(jù)包來進(jìn)行聯(lián)系，比如中斷系統(tǒng)、下斷點、顯示內(nèi)存數(shù)據(jù)等等。然后把收到的數(shù)據(jù)包經(jīng)過WinDBG處理顯示出來。    

    在進(jìn)一步介紹WinDBG之前，先介紹兩個函數(shù)：KdpTrace、KdpStub，我在《windows異常處理流程》一文里簡單提過這兩個函數(shù)?，F(xiàn)在再提一下，當(dāng)異常發(fā)生于內(nèi)核態(tài)下，會調(diào)用KiDebugRoutine兩次，異常發(fā)生于用戶態(tài)下，會調(diào)用KiDebugRoutine一次，而且第一次調(diào)用都是剛開始處理異常的時候。

    當(dāng)WinDBG未被加載時KiDebugRoutine為KdpStub，處理也很簡單，主要是對由int 0x2d引起的異常如DbgPrint、DbgPrompt、加載卸載SYMBOLS(關(guān)于int 0x2d引起的異常將在后面詳細(xì)介紹)等，把Context.Eip加1，跳過int 0x2d后面跟著的int 0x3指令。

    真正實現(xiàn)了WinDBG功能的函數(shù)是KdpTrap，它負(fù)責(zé)處理所有STATUS_BREAKPOINT和STATUS_SINGLE_STEP(單步)異常。STATUS_BREAKPOINT的異常包括int 0x3、DbgPrint、DbgPrompt、加載卸載SYMBOLS。DbgPrint的處理最簡單，KdpTrap直接向調(diào)試器發(fā)含有字符串的包。DbgPrompt因為是要輸出并接收字符串，所以先將含有字符串的包發(fā)送出去，再陷入循環(huán)等待接收來自調(diào)試器的含有回復(fù)字符串的包。SYMBOLS的加載和卸載通過調(diào)用KdpReportSymbolsStateChange，int 0x3斷點異常和int 0x1單步異常(這兩個異?；旧鲜莾?nèi)核調(diào)試器處理得最多的異常)通過調(diào)用KdpReportExceptionStateChange，這兩個函數(shù)很相似，都是通過調(diào)用KdpSendWaitContinue函數(shù)。KdpSendWaitContinue可以說是內(nèi)核調(diào)試器功能的大管家，負(fù)責(zé)各個功能的分派。這個函數(shù)向內(nèi)核調(diào)試器發(fā)送要發(fā)送的信息，比如當(dāng)前所有寄存器狀態(tài)，每次單步后我們都可以發(fā)現(xiàn)寄存器的信息被更新，就是內(nèi)核調(diào)試器接受它發(fā)出的包含最新機(jī)器狀態(tài)的包；還有SYMBOLS的狀態(tài)，這樣加載和卸載了SYMBOLS我們都能在內(nèi)核調(diào)試器里看到相應(yīng)的反應(yīng)。然后KdpSendWaitContinue等待從內(nèi)核調(diào)試器發(fā)來的包含命令的包，決定下一步該干什么。讓我們來看看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;

 

--------------------------------------------------------------------------------