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

WinDBG和用戶調(diào)試器一點(diǎn)很大不同是內(nèi)核調(diào)試器在一臺(tái)機(jī)器上啟動(dòng)，通過串口調(diào)試另一個(gè)相聯(lián)系的以Debug方式啟動(dòng)的系統(tǒng)，這個(gè)系統(tǒng)可以是虛擬機(jī)上的系統(tǒng)，也可以是另一臺(tái)機(jī)器上的系統(tǒng)(這只是微軟推薦和實(shí)現(xiàn)的方法，其實(shí)象SoftICE這類內(nèi)核調(diào)試器可以實(shí)現(xiàn)單機(jī)調(diào)試)。很多人認(rèn)為主要功能都是在WinDBG里實(shí)現(xiàn)，事實(shí)上并不是那么一回事，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)、下斷點(diǎn)、顯示內(nèi)存數(shù)據(jù)等等。然后把收到的數(shù)據(jù)包經(jīng)過WinDBG處理顯示出來。    

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

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

    真正實(shí)現(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因?yàn)槭且敵霾⒔邮兆址韵葘⒑凶址陌l(fā)送出去，再陷入循環(huán)等待接收來自調(diào)試器的含有回復(fù)字符串的包。SYMBOLS的加載和卸載通過調(diào)用KdpReportSymbolsStateChange，int 0x3斷點(diǎn)異常和int 0x1單步異常(這兩個(gè)異?；旧鲜莾?nèi)核調(diào)試器處理得最多的異常)通過調(diào)用KdpReportExceptionStateChange，這兩個(gè)函數(shù)很相似，都是通過調(diào)用KdpSendWaitContinue函數(shù)。KdpSendWaitContinue可以說是內(nèi)核調(diào)試器功能的大管家，負(fù)責(zé)各個(gè)功能的分派。這個(gè)函數(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;

 

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