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

原创 2005年04月24日 10:15:00
  所谓调试器实际上是一个很宽泛的概念,凡是能够以某种形式监控其他程序执行过程的程序,都可以泛称为调试器。在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 (ntos/ps/create.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函数(ntos/dll/dlluistb.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函数(ntos/ps/psdelete.c:1202)将调试端口加入到当前线程控制块的终止端口列表(ETHREAD->TerminationPortList)中。在线程结束的之前,会激活此列表中的端口,给调试器一个清理的机会。

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

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

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

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

    在被调试进程启动了调试支持后,调试器调用WaitForDebugEvent函数等待调试事件的发生。此函数实际上是对DbgUiWaitStateChange函数(ntos/dll/dlluistb.c:93)的一个简单包装,通过等待DbgUiConnectToDbg函数获得的调试事件信号灯来完成实际功能。如果成功获得调试事件,还会通过NtRequestWaitReplyPort函数(ntos/lpc/lpcsend.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

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

[2] 调试事件

    前面说到 Win32 下的用户态调试器实际上就是一个while循环,循环体内先等待一个调试事件,然后处理之,最后将控制权交还给调试服务器,就好像一个窗口消息循环一样。调试事件的核心实际上就是一个DEBUG_EVENT结构,在WinBase.h文件中定义如下:

    typedef struct _DEBUG_EVENT {
        DWORD dwDebugEventCode;
        DWORD dwProcessId;
        DWORD dwThreadId;
        union {
            EXCEPTION_DEBUG_INFO Exception;
            CREATE_THREAD_DEBUG_INFO CreateThread;
            CREATE_PROCESS_DEBUG_INFO CreateProcessInfo;
            EXIT_THREAD_DEBUG_INFO ExitThread;
            EXIT_PROCESS_DEBUG_INFO ExitProcess;
            LOAD_DLL_DEBUG_INFO LoadDll;
            UNLOAD_DLL_DEBUG_INFO UnloadDll;
            OUTPUT_DEBUG_STRING_INFO DebugString;
            RIP_INFO RipInfo;
        } u;
    } DEBUG_EVENT, *LPDEBUG_EVENT;

    dwDebugEventCode字段给出此调试事件的类型,dwProcessId和dwThreadId字段分别给出调试事件发生的进程和线程ID号。

    调试事件一般有以下几类:

    #define EXCEPTION_DEBUG_EVENT       1
    #define CREATE_THREAD_DEBUG_EVENT   2
    #define CREATE_PROCESS_DEBUG_EVENT  3
    #define EXIT_THREAD_DEBUG_EVENT     4
    #define EXIT_PROCESS_DEBUG_EVENT    5
    #define LOAD_DLL_DEBUG_EVENT        6
    #define UNLOAD_DLL_DEBUG_EVENT      7
    #define OUTPUT_DEBUG_STRING_EVENT   8
    #define RIP_EVENT                   9

    CREATE_PROCESS_DEBUG_EVENT事件在创建一个新的进程的第一个线程时被引发;相应的EXIT_PROCESS_DEBUG_EVENT事件在被调试的进程结束最后一个线程运行时被引发;每次新建/退出一个线程时会有CREATE_THREAD_DEBUG_EVENT/EXIT_THREAD_DEBUG_EVENT事件被引发;每次载入/卸载一个DLL时会有LOAD_DLL_DEBUG_EVENT/UNLOAD_DLL_DEBUG_EVENT事件被引发;被调试程序使用OutputDebugString函数输出一个调试字符串时调试器会接受到一个OUTPUT_DEBUG_STRING_EVENT事件;异常被引发时调试器会接受到一个第一时间的EXCEPTION_DEBUG_EVENT事件,如果调试器不处理此异常,则进入被调试程序的正常SEH调用链,如果被调试进程也不处理,则会再次引发此事件;RIP_EVENT则一般用于报告错误事件。
    一般来说程序的调试事件按照如下顺序被引发:

    CREATE_PROCESS_DEBUG_EVENT

    LOAD_DLL_DEBUG_EVENT x n                            // 静态载入的DLL

    CREATE_THREAD_DEBUG_EVENT & EXIT_THREAD_DEBUG_EVENT // 多线程程序中成对出现

    LOAD_DLL_DEBUG_EVENT & UNLOAD_DLL_DEBUG_EVENT       // 动态载入 DLL 时成对出现

    EXCEPTION_DEBUG_EVENT x n                           // 随机出现

    OUTPUT_DEBUG_STRING_EVENT x n                       // 程序写调试信息时出现

    EXIT_PROCESS_DEBUG_EVENT

    接下来我们详细分析每种调试事件被引发的原因和时机。具体的调试事件内容这里就不罗嗦了,有兴趣写调试器的朋友可以参考MSDN和<Debugging Applications>中相关内容。

    首先是建立进程的CREATE_PROCESS_DEBUG_EVENT事件和建立线程的CREATE_THREAD_DEBUG_EVENT事件。这两个事件都是由DbgkCreateThread函数(ntos/dbgk/dbgkproc.h:211)引发的。此函数首先检查当前线程是否是具有调试端口的活动线程;然后检查当前线程是否是进程的创建的第一个线程;如果不是第一个线程,或者调试器是挂接(attach)到一个活动进程上(判断依据是此进程是否占用过用户态的CPU时间),则向调试子系统的调试服务器引发CREATE_THREAD_DEBUG_EVENT事件;否则转而报告CREATE_PROCESS_DEBUG_EVENT事件。

    DbgkCreateThread函数伪代码如下:

    VOID DbgkCreateThread(PVOID StartAddress)
    {
      if(!PsGetCurrentProcess()->DebugPort || PsGetCurrentThread()->DeadThread)
      {
        return;
      }

      PsLockProcess(Process,KernelMode,PsLockWaitForever); // 锁定进程中所有线程

      if(PsGetCurrentProcess()->Pcb.UserTime &&
         PsGetCurrentProcess()->CreateProcessReported == FALSE)
      {
        PsGetCurrentProcess()->CreateProcessReported = TRUE;

        // 引发 CREATE_PROCESS_DEBUG_EVENT 事件
      }
      else
      {
        // 引发 CREATE_THREAD_DEBUG_EVENT 事件
      }

      PsUnlockProcess(PsGetCurrentProcess());
    }

    Win32在创建用户态线程的时候,大致流程如下:

    CreateThread (kernel32.dll)
    CreateRemoteThread (kernel32.dll)
    NtCreateThread (ntoskrnl.exe)
    PspCreateThread (ntos/ps/create.c:237)

    PspCreateThread函数在创建用户态线程时,使用PspUserThreadStartup函数(ntos/ps/create.c:1639)作为线程入口函数,因此线程被创建后直接进入此函数。PspUserThreadStartup函数对非僵死线程和没有结束的线程初始化其APC;然后调用DbgkCreateThread函数通知调试器采取相应动作;最后将进程的用户态CPU时间设置为1,以标示此进程已启动。对一种特殊线程,非僵死线程但线程启动时已经停止,则直接调用DbgkCreateThread然后立刻调用PspExitThread,以通知调试器采取相应动作。PspUserThreadStartup函数伪代码如下:

    VOID PspUserThreadStartup(IN PKSTART_ROUTINE StartRoutine, IN PVOID StartContext)
    {
      if(!PsGetCurrentThread()->DeadThread && !PsGetCurrentThread()->HasTerminated)
      {
        // 初始化线程 APC
      }
      else
      {
        if(!PsGetCurrentThread()->DeadThread)
        {
          DbgkCreateThread(StartContext);
        }
        PspExitThread(STATUS_THREAD_IS_TERMINATING);
      }

      DbgkCreateThread(StartContext);

      if(PsGetCurrentProcess()->Pcb.UserTime == 0)
      {
        PsGetCurrentProcess()->Pcb.UserTime = 1;
      }
    }

    与DbgkCreateThread函数对应的是DbgkExitThread函数(ntos/dbgk/dbgkproc.c:384)和DbgkExitProcess函数(ntos/dbgk/dbgkproc.c:439),分别向调试服务器引发EXIT_THREAD_DEBUG_EVENT和EXIT_PROCESS_DEBUG_EVENT事件。
    这两个函数由系统内核退出线程的PspExitThread函数(ntos/ps/psdelete.c:622)在合适的时候调用。PspExitThread函数检测当前进程PCB的线程列表是否只有当前线程一个线程,如果没有其他线程则调用DbgkExitProcess函数,否则调用DbgkExitThread函数。

    Win32 系统中载入和卸载DLL,实际的函数调用流程如下:

    LoadLibrary (kernel32.dll)
    LoadLibraryEx (kernel32.dll)
    BasepLoadLibraryAsDataFile (kernel32.dll)
    NtMapViewOfSection (ntos/mm/mapview.c:204)
    MmMapViewOfSection (ntos/mm/mapview.c:699)

    NtMapViewOfSection函数在调用MmMapViewOfSection函数(ntos/mm/mapview.c:699)完成实际的内存文件映射之后,会根据映射节的标记位以及目标进程是否是当前进程,判断是否要调用DbgkMapViewOfSection函数(ntos/dbgk/dbgkproc.c:495),通知调试服务器有新的映象文件被加载。与之对应MmUnmapViewOfSection函数(ntos/mm/umapview.c:88)也在判断标志位和目标进程是否是当前进程后,在函数末尾调用DbgkUnMapViewOfSection函数(ntos/dbgk/dbgkproc.c:567)通知调试服务器有映象文件被卸载。

    与前面的几种事件不同,OutputDebugString函数(kernel32.dll)实际上是通过异常实现的。而且有趣的是,这个函数是为数不多的W后缀Unicode版本实现上转而调用A后缀Ansi版本,完成实际功能的例子。OutputDebugStringA函数(kernel32.dll)实际上使用RaiseException函数引发了一个异常号为0x40010006的软件异常,并将字符串的指针和长度作为异常参数传递。

    DbgkForwardException函数(ntos/dbgk/dbgkport.c:96)作为实际引发EXCEPTION_DEBUG_EVENT调试事件的函数,在系统的异常分发KiDispatchException函数(ntos/ke/i386/exceptn.c:797)中被调用。KiDispatchException函数根据异常被引发时的状态,分别完成核心和用户态的异常处理工作。

    对核心态异常,首先给核心调试程序一个处理机会,然后试图分发到基于帧的SEH异常链去,没有被处理的话则再给核心调试程序一个机会,如果还是没被处理,就只能调用KeBugCheckEx函数(ntos/ke/bugcheck.c:157)蓝屏了,呵呵。
    对用户态异常,还是首先试图让核心调试器处理,如果不行才调用DbgkForwardException函数分发,没有被处理的话则多次尝试,如果还是没被处理,就停止线程并报告异常给用户。KiDispatchException函数伪代码如下:

    VOID KiDispatchException (IN PEXCEPTION_RECORD ExceptionRecord, IN PKEXCEPTION_FRAME ExceptionFrame,
                              IN PKTRAP_FRAME TrapFrame, IN KPROCESSOR_MODE PreviousMode, IN BOOLEAN FirstChance)
    {
      CONTEXT ContextFrame;

      KeContextFromKframes(TrapFrame, ExceptionFrame, &ContextFrame); // 从核心异常帧(Frame)构造异常上下文(Context)

      if (ExceptionRecord->ExceptionCode == STATUS_BREAKPOINT) // 处理调试断点 int 3
      {
        ContextFrame.Eip--;
      }

      if (PreviousMode == KernelMode)
      {
        if (FirstChance == TRUE)
        {
          if (KiDebugRoutine && KiDebugRoutine(..., FALSE) != FALSE) goto Handle1

          if(RtlDispatchException(ExceptionRecord, &ContextFrame) == TRUE) goto Handled1;
        }

        if (KiDebugRoutine && KiDebugRoutine(..., TRUE) != FALSE) goto Handle1

        KeBugCheckEx(...); // 核心错误,以可控方式崩溃 -_-b 说白了就是Deadth Blue Screen,呵呵
      }
      else // PreviousMode = UserMode
      {
        if (FirstChance == TRUE)
        {
          if (KiDebugRoutine && KiDebugRoutine(..., FALSE) != FALSE) goto Handle1

          if (DbgkForwardException(ExceptionRecord, TRUE, FALSE)) goto Handled2;

          // 将异常信息转换到用户模式,并尝试分发
        }

        if (DbgkForwardException(ExceptionRecord, TRUE, TRUE))
        {
            goto Handled2;
        }
        else if (DbgkForwardException(ExceptionRecord, FALSE, TRUE))
        {
            goto Handled2;
        }
        else
        {
            ZwTerminateThread(NtCurrentThread(), ExceptionRecord->ExceptionCode);
            KeBugCheckEx(...);
        }
      }

    Handled1:
      KeContextToKframes(TrapFrame, ExceptionFrame, &ContextFrame,
                         ContextFrame.ContextFlags, PreviousMode);

    Handled2:
    }

    DbgkForwardException函数分别针对DebugException和SecondChance参数的三种组合被调用。DebugException为True时向调试端口发送信息,否则向异常端口发送。

    至此,我们对几种常见的调试事件的引发机制就大概有了一个了解,下一节将介绍将这些调试事件和最终用户态调试器关联起来的Win32中调试子系统的实现思路。

Win32 核心 DPC 设计思想和实现思路浅析

Win32 核心 DPC 设计思想和实现思路浅析 http://www.blogcn.com/user8/flier_lu/index.html?id=1397656&run=.09D4C2F ...
  • wzsy
  • wzsy
  • 2011年08月26日 16:01
  • 922

动态链接库全面浅析(一)-----Win32 动态链接库

言前:由于最近复习了下动态链接库,所以决定写一个动态链接库专题。动态链接库网上各种达人已近写过很多了,资料也是一大把一大把的。但是我还是想写一份,因为网上讲的都很分散,讲的不是很系统,而且很多问题没有...

MongoDb win32 下 C++驱动 浅析

最近需要在win32系统下用C++编译器测试MongoDb的性能,所以花了近一周的时间对MongoDb进行了初步的研究。   这里对于MongoDb的优势和一些规则就不细说了,详见 MongoD...

Android智能指针浅析(win32 debug)

Android智能指针浅析(win32 debug) ============= 目录结构:=========== (一)引言 (二)摘录class RefBase的定义 (三)摘录class R...

动态链接库全面浅析(一)-----Win32 动态链接库

转载地址:http://blog.csdn.net/lh844386434/article/details/6734528 言前:由于最近复习了下动态链接库,所以决定写一个动态链接库专题。动态链接库...

CVE-2016-0095浅析-Win32k.sys特权提升漏洞

本文转载自SSCTF pwn450 Windows Kernel Exploitation Writeup 本文首先简单分析一下POC,随后分析这个漏洞的形成原因,最后我们来看一下这个漏洞的利用点并...

[Win32]一个调试器的实现(五)调试符号

一个调试器应该可以跟踪被调试程序执行到了什么地方,显示下一条将要执行的语句,显示各个变量的值,设置断点,进行单步执行等等,这些功能都需要一个基础设施的支持,那就是调试符号。   什么是调试符号 ...

[Win32]一个调试器的实现(二)调试事件的处理

上一篇文章说到了调试循环的写法,这回讲一下调试器应该如何处理各种调试事件。   RIP_EVENT 关于这种调试事件的文档资料非常少,即使提到也只是用“系统错误”或者“内部错误”一笔带过。既然如...

[Win32]一个调试器的实现(一)调试事件与调试循环

来源网址:http://www.cnblogs.com/zplutor/archive/2011/03/04/1971279.html 作者:Zplutor's   前言 程序员离不开调试器,...

[Win32]一个调试器的实现(一)调试事件与调试循环

前言 程序员离不开调试器,它可以动态显示程序的执行过程,对于解决程序问题有极大的帮助。如果你和我一样对调试器的工作原理很感兴趣,那么这一系列文章很适合你,这些文章记录了我开发一个调试器雏形的过程...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:Win32 调试接口设计与实现浅析
举报原因:
原因补充:

(最多只允许输入30个字)