初探Windows调试原理和反附加手段
0x00 前言
最近粗浅的研究了一下Windows应用层相关调试API和对应调试原理,以达到实现反附加的功能。本文内容主要参考《软件调试》和网络上相关优秀文章,并且主要侧重在应用层调试附加方面,关于内核层面因为水平有限本文没有详细展现。
0x01 用户态调试基本流程
首先我们先用调试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;
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的反反附加检测等问题,还需要进一步学习研究。因为本人水平有限,如果存在错误还望各位前辈指正。