初探Windows调试原理和反附加手段

最近粗浅的研究了一下Windows应用层相关调试API和对应调试原理，以达到实现反附加的功能。本文内容主要参考《软件调试》和网络上相关优秀文章，并且主要侧重在应用层调试附加方面，关于内核层面因为水平有限本文没有详细展现。

1

用户态调试基本流程

首先我们先用调试API编写一个最简单的附加调试器：

int main(int argc,TCHAR *argv[])
{
    DWORD dwPID;
       BOOL waitEvent = TRUE;
    if (argc > 1) {
        dwPID = atoi(argv[1]);
    }
    else {
        printf("usage: MyDebugger.exe dwPID\n");
        exit(0);
    }

    DebugActiveProcess(dwPID);
    while (waitEvent)
    {
        DEBUG_EVENT MyDebugInfo;
        waitEvent = WaitForDebugEvent(&MyDebugInfo, INFINITE); // Waiting
        switch (MyDebugInfo.dwDebugEventCode)
        {
            case EXIT_PROCESS_DEBUG_EVENT:
                waitEvent = FALSE
                break;
        }
        if (waitEvent) {
            ContinueDebugEvent(debugEvent.dwProcessId, debugEvent.dwThreadId, DBG_CONTINUE);
        }
    }
    return 0;
}

上文主要用到的就是 DebugActiveProcess 这个调试API对目标PID进程进行调试附加操作，如果我们要在程序创建的时候就对程序进行调试可以在Debugger中执行CreateProcess并将第6个参数传入DEBUG_ONLY_THIS_PROCESS，这样设置之后，子进程发生的调试事件会通知给父进程处理。

CreateProcess(path, // 可执行模块路径
    NULL, // 命令行
    NULL, // 安全描述符
    NULL, // 线程属性是否可继承
    FALSE, // 否从调用进程处继承了句柄
    DEBUG_ONLY_THIS_PROCESS, // 以“只”调试的方式启动
    NULL, // 新进程的环境块
    NULL, // 新进程的当前工作路径（当前目录）
    &stcStartupInfo, // 指定进程的主窗口特性
    &stcProcInfo)) // 接收新进程的识别信息

DEBUG_EVENT中的dwDebugEventCode表示调试信息的种类，对于DEBUG_EVENT详细的介绍可以查看MSDN，简单来说就是用共用体来存储具体的数据。

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;

2

用户态 DebugActiveProcess 实现

我们通过查找NT5的源码可以看到DebugActiveProcess 具体实现代码，主要就是调用了DbgUiConnectToDbg ，ProcessIdToHandle和DbgUiDebugActiveProcess这三个函数。

DbgUiConnectToDbg

首先判断TEB->DbgSsReserved[1]是否保存着调试对象的句柄，如果存在则直接返回函数如果不存在就进行初始化并调用NtCreateDebugObject创建调试对象。

ProcessIdToHandle

如果是伪句柄则调用CsrGetProcessId获取csrss.exe的PID，然后调用NtOpenProcess获得对应进程句柄，给后续调用做准备。

DbgUiDebugActiveProcess

此函数首先传入进程和调试对象的句柄进入内核，然后调用DbgUiIssueRemoteBreakin函数创建线程开始地址为DbgUiRemoteBreakin的远程线程让被调试进程断下来，如果远程线程设置失败则调用DbgUiStopDebugging停止调试。 这个地方创建了远程线程是在将来反附加检测的主要检测点。

全览图

3

调试子系统

Windows的调试子系统使用调试事件驱动，这个和窗体的消息驱动是很类似的。在调试子系统中使用WaitForDebugEvent在用户态等待调试事件，当调试器处理调试事件时，被调试进程会被挂起，所以调试器处理完毕后要调用ContinueDebugEvent使被挂起的被调试进程继续运行。

下图是张银奎老师在软件调试纵横谈中的调试模型，在用户空间部分就是我们此前通过源码分析的用户态附加调试API DebugActiveProcess 的基本流程，在系统空间维护着一个DebugObject的链表并且通过Dbgk*例程采集和传递调试事件。

4

反附加手段

根据此前内容知道，当调试器附加一个进程的时候是调用DebugActiveProcess函数，该函数内部调用了DbgUiDebugActiveProcess，此函数内部会调用DbgUiIssueRemoteBreakin函数，最后内部则会通过RtlCreateUserThread在被调试进程内创建一个线程，线程的起始地址是DbgUiRemoteBreakin。

在被调试进程内DbgUiRemoteBreakin会判断PEB中的BeingDebugged标志位，如果在调试则调用DbgBreakPoint函数，调试器附加后被调试进程就中断在DbgBreakPoint函数内。

根据上述流程我们可以知道在被调试进程（我们的程序）会创建新线程，线程起始函数是DbgUiRemoteBreakin。所以我们可以Hook DbgUiRemoteBreakin 直接调用 ExitProcess 结束我们的程序。

5

反反附加插件

本文以ScyllaHide为例子，因为ScyllaHide是开源项目可以直接分析源码，插件加载后我们此前设置的HOOK会被还原。

对于SharpOD，他会在插件加载的时候Hook调试器的DebugActiveProcess和CreateProcessInternalW，在DebugActiveProcessDetour 会在被调试进程中添加ShellCode，并HOOK LdrInitializeThunk 跳转到ShellCode中断，并在附加进程的调试事件到达后还原LdrInitializeThunk 。

6

x64dbg的Titan Engine

对于新版x64dbg会内嵌Titan Engine（2020年11月12日版本后添加），所以SharpOD插件对于反反附加对新版本x64dbg起不到作用。在Titan Engine内部自己实现了DebugActiveProcess一套流程。

并且没有调用DbgUiIssueRemoteBreakin让程序被调试器附加的时候断下。

7

总结

本文初步学习了Windows用户层基本的调试原理和模型，并给出了一个简单的反附加方案，同时分析了目前常见的反反附加插件。不过同时存在不知道如何绕过SharpOD的反反附加检测等问题，还需要进一步学习研究。因为本人水平有限，如果存在错误还望各位前辈指正。

参考链接：

（1）Windows 调试原理学习

（2）调试器原理

（3）软件调试纵横谈