Windows核心調試器原理淺析

Windows核心調試器原理淺析

文章作者：SoBeIt

  前段時間忽然對核心調試器實現原來發生了興趣，於是簡單分析了一下當前windows下主流核心調試器原理，並模仿原理自己也寫了個極其簡單的調試器:)

  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的原理和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到被中斷代碼處執行。執行了一個指令後因為發生單步異常又進入後台迴圈代碼。

  SoftICE裡的單步比WinDBG要快得多的原因很簡單，SoftICE只需要把反組譯碼出來的代碼和資料經過簡單處理再寫入顯存映射地址緩衝區裡重新整理螢幕就可以繼續執行了，省略了串列的發包收包，怎麼會不快。而中斷系統更快，按下鍵中斷就會發生，根本不用象WinDBG等時鐘中斷才能把系統斷下來。

後記：

 

  好象說得很簡單，其實一個核心調試器實現起來極其複雜，沒說得再詳細，一是因為題目就叫“淺析”，就是類似於科普的東西；二是水平和時間有限(主要原因^^)；三是真要詳細寫起來就不是這幾千字能說得明白的東西了。還有，反組譯碼ntice.sys真是一項艱巨的任務，比分析漏洞要複雜N倍，剛開始沒著門道時真看得我頭昏眼花。在此特別感謝Syser的作者，牛人就是牛人，在我對SoftICE工作原理的認識還處於混沌狀態時，幾句話點醒了我^^。因為水平有限難免有很多錯漏，還忘高手指出:)