Win32 调试接口设计与实现浅析 [1] 用户态调试器结构初探

Win32 调试接口设计与实现浅析 [1] 用户态调试器结构初探

http://www.blogcn.com/user8/flier_lu/index.html?id=1307208&run=.002A442

Win32 调试接口设计与实现浅析

     所谓调试器实际上是一个很宽泛的概念，凡是能够以某种形式监控其他程序执行过程的程序，都可以泛称为调试器。在Windows平台上，根据调试器的实现原理大概可以将之分为三类：内核态调试器、用户态调试器和伪代码调试器。
     内核态调试器直接工作在操作系统内核一级，在硬件与操作系统之间针对系统核心或驱动进行调试，常见的有SoftICE、WinDbg、WDEB386和i386KD等等；用户态调试器则通过操作系统提供的调试接口，在操作系统和用户态程序之间针对用户态程序进行调试，常见的有各种开发环境如VC/Delphi自带的调试器，OllyDbg等等；伪代码调试器则使用目标系统自定义的调试接口，调试由用户态程序支持的脚本语言或虚拟机代码，常见的如JVM/CLR的调试工具、VB的pcode调试器、Active Script调试器等等。
     因为伪代码调试器跟具体系统实现相关性太强，不具备原理层面的通用性，本系列文章尽量不涉及其内容，以后如果有机会可以再讨论一下JVM/CLR/Active Script提供的调试接口；用户态调试器应用最广泛，参考资料也较为完整，我会花较大精力和大家探讨；核心态调试器则跟操作系统结合较为紧密，加上我也不是太熟悉，只能尽力而为了，呵呵。欢迎大家提出批评指正意见和建议 :)
     此外强烈推荐John Robbins在MSDN的Bugslayer专栏，以及其所著的<Debugging Applications>一书（中文版《应用程序调试技术》），此书中对调试器从原理到应用都有很全面的讲解。

 [1] 用户态调试器结构初探

     用户态调试器直接使用Win32 API提供的调试接口，遵循Win32的事件驱动的设计思想，其实现思路非常简单，基本框架伪代码如下：
 

以下为引用：

 //启动要调试的进程或挂接调试器到已运行的进程上
 CreateProcess(..., DEBUG_PROCESS, ...) or DebugActiveProcess(dwProcessId)

 DEBUG_EVENT de;
 BOOL bContinue = TRUE;
 DWORD dwContinueStatus;

 while(bContinue)
 {
   bContinue = WaitForDebugEvent(&de, INFINITE);

   switch(de.dwDebugEventCode)
   {
   ...
   default:
     {
       dwContinueStatus = DBG_CONTINUE;
       break;
     }
   }

   ContinueDebugEvent(de.dwProcessId, de.dwThreadId, dwContinueStatus);
 }
 

     在调试器开始调试的时候，会启动被调试程序的新进程或者挂接(attach)到一个已运行进程上，此时Win32系统会启动调试接口的服务器端；然后调试器调用WaitForDebugEvent函数等待调试服务器端的调试事件被引发；调试器根据调试事件进行相应的处理；最后调用ContinueDebugEvent函数请求调试服务器继续执行被调试进程，以等待并处理下一个调试事件。

     首先我们大致看看调试接口的服务器端的实现思路：调试服务的服务器端接口实际上是存在于被调试进程的调试端口(Debug Port)，此核心对象实现上跟Win32的完成端口类似，都是通过一个核心队列实现的LPC端口。启动调试服务器实际上就是挂接Win32的调试子系统到被调试进程，并在被调试进程内构造调试端口。调试器通过调试端口与Win32的调试子系统通讯；调试子系统响应系统操作所引发的调试事件，并通过调试端口将调试事件分发给核心态/用户态调试器。

     建立被调试程序的新进程时，需要在CreateProcess函数的dwCreationFlags参数设置DEBUG_ONLY_THIS_PROCESS或DEBUG_PROCESS标志位，以表示新建的进程需要被调试。CreateProcess函数的调用路径如下
 

以下为引用：

 CreateProcessA/CreateProcessW (kernel32.dll)
 CreateProcessInternalW (kernel32.dll)
 NtCreateProcessEx (ntoskrnl.dll)
 PspCreateProcess (ntospscreate.c:969)
 

     CreateProcessInternalW函数根据传入的dwCreationFlags参数，决定是否要构造端口核心对象用于调试端口，并设置PEB的相应调试标志；PspCreateProcess会根据传入参数的调试选项和端口对象句柄，选择是否创建目标进程的调试端口；如果要创建则将传入的端口句柄转换成内核对象引用，保存在被调试程序进程的EPROCESS->DebugPort字段里。
     Win32 API提供的IsDebuggerPresent函数就是通过判断CreateProcessInternalW函数在PEB中设置的标志位来判断当前进程是否被调试的。IsDebuggerPresent函数伪代码如下：
 

以下为引用：

 BOOL IsDebuggerPresent(void)
 {
   return NtCurrentTeb()->ProcessEnvironmentBlock->BeingDebugged;
 }
 

     TEB和PEB的结构可在http://www.ntinternals.net 上找到。

     不过此种方法很容易被调试器直接修改PEB内存结构所欺骗，故而有另外一种直接通过检查EPROCESS->DebugPort字段是否被使用，来判断此进程是否正在被调试的方法。以前水木上也有过几次讨论，如blowfish的《检测debugger的方法补遗》一文给出的代码。Windows XP/2003开始由Win32 API提供的 CheckRemoteDebuggerPresent 函数也是使用相同的思路，通过调用 NtQueryInformationProcess 函数查询调试端口实现的，伪代码如下：
 

以下为引用：

 BOOL CheckRemoteDebuggerPresent(HANDLE hProcess, PBOOL pbDebuggerPresent)
 {
   enum PROCESS_INFO_CLASS { ProcessDebugPort = 7 };

   if(hProcess && pbDebuggerPresent)
   {
     HANDLE hPort;

     *pbDebuggerPresent = NT_SUCCESS(NtQueryInformationProcess(hProcess, ProcessDebugPort, &hPort, sizeof(hPort), NULL)) ? TRUE : FALSE;

     return *pbDebuggerPresent;
   }
   return FALSE;
 }
 

     与直接创建被调试程序的新进程不同，调试已启动进程的 DebugActiveProcess 函数首先连接到Win32 系统调试服务器的端口上，然后激活当前正在运行的被调试进程的调试端口。DebugActiveProcess的伪代码如下：
 

以下为引用：

 BOOL DebugActiveProcess(DWORD dwProcessId)
 {
   if(DbgUiConnectToDbg())
   {
     HANDLE hProcess = ProcessIdToHandle(dwProcessId);

     if(hProcess)
     {
       DbgUiDebugActiveProcess(hProcess);
       NtClose(hProcess);
     }
   }
   return FALSE;
 }
 

     DbgUiConnectToDbg函数(ntosdlldlluistb.c:27)尝试连接核心提供的调试子系统端口(名为"DbgUiApiPort")，如果成功连接会获得一个端口对象(保存在DbgUiApiPort NtCurrentTeb()->DbgSsReserved[1])，和一个调试状态转换的信号灯句柄(保存在DbgStateChangeSemaphore NtCurrentTeb()->DbgSsReserved[0])用于等待调试事件。伪代码如下：
 

以下为引用：

 #define DbgStateChangeSemaphore (NtCurrentTeb()->DbgSsReserved[0])
 #define DbgUiApiPort (NtCurrentTeb()->DbgSsReserved[1])

 NTSTATUS DbgUiConnectToDbg( VOID )
 {
   NTSTATUS st = NtConnectPort(&DbgUiApiPort, L"\DbgUiApiPort", ..., &DbgStateChangeSemaphore);

   if(NT_SUCCESS(st))
   {
     NtRegisterThreadTerminatePort(DbgUiApiPort);
   }
   else
   {
     DbgUiApiPort = NULL;
   }
   return st;
 }
 

     如果连接调试子系统成功，则调用NtRegisterThreadTerminatePort函数(ntospspsdelete.c:1202)将调试端口加入到当前线程控制块的终止端口列表(ETHREAD->TerminationPortList)中。在线程结束的之前，会激活此列表中的端口，给调试器一个清理的机会。

     DbgUiDebugActiveProcess函数完成具体的激活被调试进程的调试服务器的功能。伪代码如下：
 

以下为引用：

 #define DbgUiApiPort (NtCurrentTeb()->DbgSsReserved[1])

 void DbgUiDebugActiveProcess(HANDLE hProcess)
 {
   return NtDebugActiveProcess(DbgUiApiPort) &&
          DbgUiIssueRemoteBreakin(hProcess) &&
          DbgUiStopDebugging(hProcess);
 }
 

     至于这几个函数的具体实现，等后面章节详细分析Win32调试子系统时再详细讲解，呵呵

     在被调试进程启动了调试支持后，调试器调用WaitForDebugEvent函数等待调试事件的发生。此函数实际上是对DbgUiWaitStateChange函数(ntosdlldlluistb.c:93)的一个简单包装，通过等待DbgUiConnectToDbg函数获得的调试事件信号灯来完成实际功能。如果成功获得调试事件，还会通过NtRequestWaitReplyPort函数(ntoslpclpcsend.c:717)向调试服务器通报DbgUiWaitStateChangeApi消息。

     在处理完调试事件后，调试器调用的ContinueDebugEvent函数是DbgUiContinue函数的一个简单包装，也是使用NtRequestWaitReplyPort函数向调试服务器通报DbgUiContinueApi消息。

     在完成调试功能后，WinXP/2003还提供了DebugActiveProcessStop函数停止调试。伪代码如下：
 

以下为引用：

 BOOL DebugActiveProcessStop(DWORD dwProcessId)
 {
   HANDLE hProcess = ProcessIdToHandle(dwProcessId);

   if(hProcess)
   {
     CloseAllProcessHandles(dwProcessId);
     DbgUiStopDebugging(hProcess);
     if(NtClose(hProcess))
       return TRUE;
   }
   return FALSE;
 }
 

     DbgUiStopDebugging函数(ntdll.dll)调用ZwRemoveProcessDebug函数(ntoskrnl.exe)关闭指定进程的调试端口，实现上是传入端口句柄和进程句柄，调用0xC7号系统服务完成最终功能。这个暂时就不深入讨论了，就此打住 :P

     在了解这些后，对用户态调试器的实现应该就有了一个框架性的了解：其结构就是一个基于事件的模型，然后通过向调试子系统请求调试事件并完成具体操作。