Windows反调试技术：过滤OpenProcess

一、前言

前一阵子我一直在研究与SYSTEM权限有关的技术，本周我想暂时休息一下，把目光转到一些反调试技术上。现在许多漏洞奖励计划中都会包含客户端应用程序方面内容，而许多安全产品（以及游戏中的反作弊引擎）会使用各种技术阻止用户调试核心组件，本文中我们介绍了某一种反调试技术以及相应的规避方法。

显而易见的是，本文中介绍的技术并不属于漏洞范畴，如果攻击者已经掌握系统的访问权限，那么就不用费那么多事，他们很有可能已经在系统中装上了rootkit，完成攻击过程。

在本文中我测试的是AVG安全产品，但其他许多AV解决方案及安全产品也使用了完全相同的技术，因此本文介绍的方法也可以在这些产品上使用。

 

二、具体问题

如果你之前曾经尝试使用x64dbg调试工具附加（attach）到某个AV组件上，你经常会看到如下画面，这一点已经见惯不怪：

实际结果是调试器无法成功attach到该进程上，我们只能茫然地盯着屏幕，不知下一步该干啥。另外，如果我们不attach，而是选择在调试器中启动该进程，会看到如下画面：

还是得到一样的结果，当程序即将启动时我们就已被踢出局。最后，像其他逆向分析师一样，我们尝试使用WinDBG来分析，结果会得到如下错误信息：

为了理解调试器的工作原理，也为了让我们更好地了解到底哪里出了问题，我们可以分析一下x64dbg的代码（实际上我们需要分析的是TitanEngine的代码，TitanEngine是x64dbg使用的调试引擎），看看我们无法attach进程背后的具体原因。

__declspec(dllexport) bool TITCALL AttachDebugger(DWORD ProcessId, bool KillOnExit, LPVOID DebugInfo, LPVOID CallBack)
{
...
if(ProcessId != NULL && dbgProcessInformation.hProcess == NULL)
{
    if(engineEnableDebugPrivilege)
    {
        EngineSetDebugPrivilege(GetCurrentProcess(), true);
        DebugRemoveDebugPrivilege = true;
    }
    if(DebugActiveProcess(ProcessId))
    {
    ...
    }
}
}

这里我们可以看到，x64dbg使用的是DebugActiveProcess.aspx)这个API函数，该API为KernelBase.dll提供的Win32 API。

 

三、DebugActiveProcess的工作原理

DebugActiveProcess 负责启动针对目标进程的调试会话，以进程的PID值作为参数。如果我们在MSDN.aspx)上查找这个函数，我们可以得到如下信息：

“调试器必须具备目标进程的合适权限，必须能够以PROCESS_ALL_ACCESS方式打开目标进程。

如果目标进程创建时使用了安全描述符（security descriptor），使调试器无法获得完全访问权限，那么调用DebugActiveProcess时可能会失败。如果调试进程具备SE_DEBUG_NAME权限，那么它就可以调试任何进程。”

这段话给了我们第一个提示信息，提示我们究竟是什么导致我们的调试会话无法正常建立。从上述代码片段中，我们可以看到调试器正在调用EngineSetDebugPrivilege，那么我们来看看这个函数的具体内容：

DWORD EngineSetDebugPrivilege(HANDLE hProcess, bool bEnablePrivilege)
{
    DWORD dwLastError;
    HANDLE hToken = 0;
    if(!OpenProcessToken(hProcess, TOKEN_ADJUST_PRIVILEGES | TOKEN_QUERY, &hToken))
    {
        ...
    }
        ...
    if(!LookupPrivilegeValue(NULL, SE_DEBUG_NAME, &luid))
    {
        ...
    }
    tokenPrivileges.PrivilegeCount = 1;
    tokenPrivileges.Privileges[0].Luid = luid;
    if(bEnablePrivilege)
        tokenPrivileges.Privileges[0].Attributes = SE_PRIVILEGE_ENABLED;
    else
        tokenPrivileges.Privileges[0].Attributes = 0;
    AdjustTokenPrivileges(hToken, FALSE, &tokenPrivileges, sizeof(TOKEN_PRIVILEGES), NULL, NULL);
    ...
}

在上述代码中，我们的进程具备SE_DEBUG_NAME权限，也就是说我们满足了上述要求，可以从调试器中调用DebugActiveProcess函数。

接下来我们需要看一下我们是否拥有目标进程的PROCESS_ALL_ACCESS访问权限。

 

四、DebugActiveProcess内部工作流程

DebugActiveProcess这个API仅接受一个参数，那就是目标进程的进程ID，函数内部会调用ProcessIdToHandle，利用这个值获得目标进程的句柄。

如果我们跳转到ProcessIdToHandle函数，我们会发现该函数只是NtOpenProcess API的封装函数：

对于NtOpenProcess函数，其DesiredAccess参数的传入值为C3Ah。查阅相关文档.aspx)后，我们发现这个值为一些标志的组合值，这些标志为：

• PROCESS_CREATE_THREAD
• PROCESS_VM_OPERATION
• PROCESS_VM_WRITE
• PROCESS_VM_READ
• PROCESS_SUSPEND_RESUME
• PROCESS_QUERY_INFORMATION

使用这个值后，函数就可以拥有所需的所有权限，开始调试目标进程。

现在，我们已经知道调试器具备SE_DEBUG_NAME权限，并且DebugActiveProcess调用也拿到了目标进程的正确的访问权限。那么，到底是什么在阻止我们调试目标进程？

 

五、ObRegisterCallbacks登场

当我加入游戏以及游戏修改（modding）社区时，我才第一次见到ObRegisterCallbacks的身影，社区爱好者在绕过反作弊及DRM驱动时，经常使用该函数在游戏中修改或注入其他功能。

根据微软的说法，ObRegisterCallbacks.aspx)是“一个例程，负责为线程、进程以及桌面句柄操作注册一系列回调例程”。这一过程在内核模式下完成，借助这一功能，当调用OpenProcess函数以及当OpenProcess函数返回时，驱动程序可以获得相关通知信息。

但为什么这个函数可以阻止调试器访问AV进程呢？想要阻止程序成功调用DebugActiveProcess的一种方法就是过滤掉在NtOpenProcess调用期间所请求的访问权限。阻止调试器请求目标进程的PROCESS_ALL_ACCESS权限后，我们自然就失去调试该进程的能力。这一方法也顺便解释了我们之前在WinDBG中看到的错误现象。

但是我们还需要确定这是否就是我们当前问题的症结所在。现在让我们使用内核调试器，看一下Ring-0状态下系统如何处理已注册的回调函数。

（我不会在本文中介绍如何设置内核调试器，大家可以查看我之前发表的文章了解具体细节）。

 

六、ObRegisterCallback内部流程

建立内核调试器连接后，首先我们可以使用nt!ProcessType来获得一些信息：

kd> dt nt!_OBJECT_TYPE poi(nt!PsProcessType)
+0x000 TypeList         : _LIST_ENTRY [ 0xffffcb82`dee6cf20 - 0xffffcb82`dee6cf20 ]
+0x010 Name             : _UNICODE_STRING "Process"
+0x020 DefaultObject    : (null) 
+0x028 Index            : 0x7 ''
+0x02c TotalNumberOfObjects : 0x26
+0x030 TotalNumberOfHandles : 0xe8
+0x034 HighWaterNumberOfObjects : 0x26
+0x038 HighWaterNumberOfHandles : 0xea
+0x040 TypeInfo         : _OBJECT_TYPE_INITIALIZER
+0x0b8 TypeLock         : _EX_PUSH_LOCK
+0x0c0 Key              : 0x636f7250
+0x0c8 CallbackList     : _LIST_ENTRY [ 0xffffa002`d31bacd0 - 0xffffa002`d35d2450 ]

该符号提供了指向_OBJECT_TYPE对象的一个指针，该对象定义了“Process”类型，其中我们最感兴趣的是CallbackList属性。这个属性定义了由ObRegisterCallbacks.aspx)注册的一系列回调函数，随后，当有程序尝试获取进程句柄时内核就会调用这些回调函数。知道这些信息后，我们可以遍历回调函数列表，查找有哪些已注册的回调会干扰我们调用OpenProcess。

CallbackList是指向CALLBACK_ENTRY_ITEM结构的一个LIST_ENTRY。微软文档中并没有公开这个结构，感谢“DOUGGEM’S GAME HACKING AND REVERSING NOTES”这个网站，我们最终可以得知该结构的具体定义，如下所示：

typedef struct _CALLBACK_ENTRY_ITEM {
LIST_ENTRY EntryItemList;
OB_OPERATION Operations;
CALLBACK_ENTRY* CallbackEntry;
POBJECT_TYPE ObjectType;
POB_PRE_OPERATION_CALLBACK PreOperation;
POB_POST_OPERATION_CALLBACK PostOperation;
__int64 unk;
}CALLBACK_ENTRY_ITEM, *PCALLBACK_ENTRY_ITEM;

这里我们关心的是该结构中的PreOperation属性。

我们可以使用如下WinDBG命令来遍历CALLBACK_ENTRY_ITEM列表：

!list -x ".if (poi(@$extret+0x28) != 0) { u poi(@$extret+0x28); }" (poi(nt!PsProcessType)+0xc8)

在我的测试环境中，我总共发现了4个驱动使用ObRegisterCallbacks注册了PreOperation回调函数。我们可以使用WinDBG获得驱动名称，以便后续分析：

!list -x ".if (poi(@$extret+0x28) != 0) { lmv a (poi(@$extret+0x28)) }" (poi(nt!PsProcessType)+0xc8)

上面列出的4个驱动中，有一个非常值得怀疑，那就是avgSP.sys：

“AVG自我保护模块（AVG self protection module）”这个驱动会限制我们使用调试器来附加到相关进程（其实该驱动最大的作用很有可能是防止恶意软件篡改反病毒引擎）。让我们深入分析这个驱动，看是否有任何蛛丝马迹表明该驱动的确会修改我们的OpenProcess调用。

首先，搜索ObRegisterCallbacks后，我们可以找到某个处理程序的注册过程，如下所示：

如果我们检查已注册的处理程序，我们很快就能看到如下类似信息：

上图显示的汇编代码中，A0121410这个魔术值实际上对应的是如下权限：

• PROCESS_VM_READ
• PROCESS_QUERY_INFORMATION
• PROCESS_QUERY_LIMITED_INFORMATION
• READ_CONTROL
• SYNCHRONIZE

如果只设置了这些权限，那么驱动就不会执行后续检查过程，因而就不会过滤OpenProcess调用。然而，除了这几个白名单权限以外，如果程序请求其他权限，驱动会进一步执行一些检查过程，最终在调用返回前过滤掉相应的权限：

这里我不会详细介绍驱动的工作细节，因为本文的目的是介绍如何识别并移除各种产品所使用的这种hook的通用方法，根据前面已知的这些信息，我们已经找到了干扰并修改OpenProcess调用的那个驱动。

找到幕后黑手后，现在我们可以从内核中去掉已绑定的这个处理程序。

 

七、解开OpenProcess过滤器

如果想解开OpenProcess过滤器，我们首先需要找到与过滤器函数对应的PreOperation属性的地址。我们可以使用如下WinDBG命令完成这一任务：

!list -x ".if (poi(@$extret+0x28) != 0) { .echo handler at; ?? @$extret+0x28; u poi(@$extret+0x28); }" (poi(nt!PsProcessType)+0xc8)

识别出正确的地址后，我们可以清空这个指针，禁用掉处理函数，具体命令如下：

eq 0xffffa002`d31bacf8 0

此时，如果我们重新attach调试器，我们可以看到如下画面：

非常好，看上去我们已经打败了这个反调试技术！

好吧，其实结果并不完美。经过一些交互操作后，我们注意到调试器中会出现一些错误信息，事情并没有那么顺利。即使是在上一张图中，我们也可以发现寄存器的值全部为0，并且出现了访问冲突（access violation）问题，肯定还有一些细节我们没有注意到。

 

八、解开线程过滤器

根据前文描述，我们已经知道ObRegisterCallbacks可以用来hook OpenProcess，但这个函数还有其他用途吗？如果我们回头查一下官方文档.aspx)，就会知道该函数也可以用来hook OpenThread调用：

幸运的是，最难的那一部分工作我们已经完成了，现在我们所需要做的就是找到线程回调函数所存储的具体位置，该位置对应的是nt!PsThreadType。

我们可以修改前面用过的那条WinDBG命令，查看这个驱动是否hook了OpenThread：

!list -x ".if (poi(@$extret+0x28) != 0) { .echo handler at; ?? @$extret+0x28; u poi(@$extret+0x28); }" (poi(nt!PsThreadType)+0xc8)

果不其然，我们找到了这个hook。与进程hook类似，我们可以使用类似的eq命令解开这个过滤器：

eq 0xffffc581`89df32e8 0

再次启动调试器：

现在，我们终于得到了完美的调试器会话。

 

九、总结

许多安全产品会使用这种反调试方法，希望阅读本文后，大家对这种方法有所了解。如果大家对此感兴趣，可以探索一下相关的漏洞奖励项目，比如bugcrowd上有一些安全产品的漏洞奖励计划，这些产品包括AVG、Cylance、Sophos等（但我并没有将本文介绍的这种方法以漏洞内容提交，因为DKOM（Direct Kernel Object Manipulation，直接操作内核对象）技术很有可能不属于漏洞奖励范畴）。

 

十、参考资料

• TitanEngine
• DOUGGEM’S GAME HACKING AND REVERSING NOTES
• AVG Bug Bounty
• x64Dbg GitHub