-
-
[原创]初探Windows调试原理和反附加手段
-
2021-8-19 21:31
-
0x00 前言
最近粗浅的研究了一下Windows应用层相关调试API和对应调试原理，以达到实现反附加的功能。本文内容主要参考《软件调试》和网络上相关优秀文章，并且主要侧重在应用层调试附加方面，关于内核层面因为水平有限本文没有详细展现。
0x01 用户态调试基本流程
首先我们先用调试API编写一个最简单的附加调试器
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 | 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，这样设置之后，子进程发生的调试事件会通知给父进程处理。
1 2 3 4 5 6 7 8 9 10 | CreateProcess(path, // 可执行模块路径 NULL, // 命令行 NULL, // 安全描述符 NULL, // 线程属性是否可继承 FALSE, // 否从调用进程处继承了句柄 DEBUG_ONLY_THIS_PROCESS, // 以“只”调试的方式启动 NULL, // 新进程的环境块 NULL, // 新进程的当前工作路径（当前目录） &stcStartupInfo, // 指定进程的主窗口特性 &stcProcInfo)) // 接收新进程的识别信息 |
DEBUG_EVENT中的dwDebugEventCode表示调试信息的种类，对于DEBUG_EVENT详细的介绍可以查看MSDN，简单来说就是用共用体来存储具体的数据。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | 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; |
0x02 用户态 DebugActiveProcess 实现
我们通过查找NT5的源码可以看到DebugActiveProcess 具体实现代码，主要就是调用了DbgUiConnectToDbg ，ProcessIdToHandle和DbgUiDebugActiveProcess这三个函数
DbgUiConnectToDbg
首先判断TEB->DbgSsReserved[1]是否保存着调试对象的句柄，如果存在则直接返回函数如果不存在就进行初始化并调用NtCreateDebugObject创建调试对象
ProcessIdToHandle
如果是伪句柄则调用CsrGetProcessId获取csrss.exe的PID，然后调用NtOpenProcess获得对应进程句柄，给后续调用做准备。
DbgUiDebugActiveProcess
此函数首先传入进程和调试对象的句柄进入内核，然后调用DbgUiIssueRemoteBreakin函数创建线程开始地址为DbgUiRemoteBreakin的远程线程让被调试进程断下来，如果远程线程设置失败则调用DbgUiStopDebugging停止调试。这个地方创建了远程线程是在将来反附加检测的主要检测点。
全览图
0x03 调试子系统
Windows的调试子系统使用调试事件驱动，这个和窗体的消息驱动是很类似的。在调试子系统中使用WaitForDebugEvent在用户态等待调试事件，当调试器处理调试事件时，被调试进程会被挂起，所以调试器处理完毕后要调用ContinueDebugEvent使被挂起的被调试进程继续运行。
下图是张银奎老师在软件调试纵横谈中的调试模型，在用户空间部分就是我们此前通过源码分析的用户态附加调试API DebugActiveProcess 的基本流程，在系统空间维护着一个DebugObject的链表并且通过Dbgk*例程采集和传递调试事件。
0x04 反附加手段
根据此前内容知道，当调试器附加一个进程的时候是调用DebugActiveProcess函数，该函数内部调用了DbgUiDebugActiveProcess，此函数内部会调用DbgUiIssueRemoteBreakin函数，最后内部则会通过RtlCreateUserThread在被调试进程内创建一个线程，线程的起始地址是DbgUiRemoteBreakin。
在被调试进程内DbgUiRemoteBreakin会判断PEB中的BeingDebugged标志位，如果在调试则调用DbgBreakPoint函数，调试器附加后被调试进程就中断在DbgBreakPoint函数内。
根据上述流程我们可以知道在被调试进程（我们的程序）会创建新线程，线程起始函数是DbgUiRemoteBreakin。所以我们可以Hook DbgUiRemoteBreakin 直接调用 ExitProcess 结束我们的程序。
0x05 反反附加插件
本文以ScyllaHide为例子，因为ScyllaHide是开源项目可以直接分析源码，插件加载后我们此前设置的HOOK会被还原。
对于SharpOD，他会在插件加载的时候Hook调试器的DebugActiveProcess和CreateProcessInternalW，在DebugActiveProcessDetour 会在被调试进程中添加ShellCode，并HOOK LdrInitializeThunk 跳转到ShellCode中断，并在附加进程的调试事件到达后还原LdrInitializeThunk 。
0x06 x64dbg的Titan Engine
对于新版x64dbg会内嵌Titan Engine（2020年11月12日版本后添加），所以SharpOD插件对于反反附加对新版本x64dbg起不到作用。在Titan Engine内部自己实现了DebugActiveProcess一套流程。
并且没有调用DbgUiIssueRemoteBreakin让程序被调试器附加的时候断下。
0x07 总结及参考链接
本文初步学习了Windows用户层基本的调试原理和模型，并给出了一个简单的反附加方案，同时分析了目前常见的反反附加插件。不过同时存在不知道如何绕过SharpOD的反反附加检测等问题，还需要进一步学习研究。因为本人水平有限，如果存在错误还望各位前辈指正。
[培训]二进制漏洞攻防（第3期）；满10人开班；模糊测试与工具使用二次开发；网络协议漏洞挖掘；Linux内核漏洞挖掘与利用；AOSP漏洞挖掘与利用；代码审计。
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
