通过硬件断点绕过hook检测

字数统计: 2k字   |   阅读时长≈ 7分

我们知道常见的注入方式有IAT hook、SSDT hook、Inline hook等，但其实大体上可以分为两类，一类是基于修改函数地址的hook，一类则是基于修改函数代码的hook。而基于修改函数地址的hook最大的局限性就是只能hook已导出的函数，对于一些未导出函数是无能为力的，所以在真实的hook中，Inline hook反而是更受到青睐的一方。

0x00 前言

我们知道常见的注入方式有IAT hook、SSDT hook、Inline hook等，但其实大体上可以分为两类，一类是基于修改函数地址的hook，一类则是基于修改函数代码的hook。而基于修改函数地址的hook最大的局限性就是只能hook已导出的函数，对于一些未导出函数是无能为力的，所以在真实的hook中，Inline hook反而是更受到青睐的一方。

0x01 hook测试

这里我用win32写了一个MessageBox的程序，当点击开始按钮就会弹窗，通过一个Hook_E9函数用来限制对MessageBoxA的hook，如果检测到了hook，则调用ExitProcess直接退出程序

image-20220406165822281.png

如下所示，这里我们的目的就是通过Inline hook来修改文本框中的内容

image-20220406165833227.png

这里使用常规方式修改5个字节的硬编码，通过E9跳转到我们自己的函数进行修改，这里将代码打包成dll

image-20220406170042141.png

通过远程线程注入，这里显示是注入成功了，但是会被我们的检测函数拦截，这里可以看到拦截的是E9这个硬编码

image-20220406165929083.png

然后我们这里对我们的程序的E9指令进行替换，修改为先用call短跳到没有被监控的区域，然后再跳到我们自己的函数

然而这里还是被拦截，这里显示的是被CRC检测拦截了

image-20220406170152970.png

我们知道Inline hook无论是通过E8还是E9跳转，肯定是要修改内存的，那么如果程序有CRC检测，那么我们这种使用汇编跳到自己的处理函数的方法是怎么都行不通的。这里就不能使用常规的方法去规避hook，而是通过CPU的dr0-dr7寄存器去触发异常，通过异常处理函数来修改文本框的值，这里我们首先需要了解的是硬件断点

0x02 硬件断点

简单说一下软件断点和内存断点，软件断点就是我们通常在OD里面通过F2下的断点，它的原理是将我们想要断点的一个硬编码修改为cc，内存断点就是通过VirtualProtect函数来修改PTE的属性来触发异常达到断点的效果，这两种断点都需要修改内存里面的数据。

与软件断点与内存断点不同，硬件断点不依赖被调试程序，而是依赖于CPU中的调试寄存器。调试寄存器有7个，分别为Dr0~Dr7。用户最多能够设置4个硬件断点，这是由于只有Dr0~Dr3用于存储线性地址。其中，Dr4和Dr5是保留的。

在OD里面也能够看到只能设置4个硬件断点

image-20220402185424231.png

设置硬件断点

Dr0~Dr3用于设置硬件断点，由于只有4个断点寄存器，所以最多只能设置4个硬件调试断点。在这7个寄存器里面，Dr7是最重要的寄存器

L0/G0 ~ L3/G3：控制Dr0~Dr3是否有效，局部还是全局；每次异常后，Lx都被清零，Gx不清零。

若Dr0有效，L0=1则为局部，G0=1则为全局，以此类推

image-20220402213248841.png

断点长度(LENx)：00(1字节)、01(2字节)、11(4字节)

通过DR7的LEN控制

image-20220402213410805.png

断点类型(R/Wx)：00(执行断点)、01(写入断点)、11(访问断点)

image-20220402213439641.png

流程

被调试进程

1.CPU执行时检测当前线性地址与调试寄存器（Dr0~Dr3）中的线性地址相等。 2.查IDT表找到对应的中断处理函数（nt!_KiTrap01） 3.CommonDispatchException 4.KiDispatchException 5.DbgkForwardException收集并发送调试事件

DbgkForwardException最终会调用DbgkpSendApiMessage(x, x)，第一个参数是消息类型，第二个参数则是选择是否挂起其它线程

调试器进程

1.循环判断 2.取出调试事件 3.列出信息：寄存器、内存 4.用户处理

0x03 思路

我们首先明确一下思路，我们知道硬件断点是基于线程的，因为每个线程的CONTEXT结构是不同的，这里首先就需要找到我们要修改dr寄存器的线程，也就是我们要hook的检测线程，找到线程之后我们通过OpenThread去获得线程的句柄，然后通过SetUnhandledExceptionFilter去注册一个异常处理函数，注册完成之后就可以更改dr寄存器的值来触发访问/写入/执行断点，然后再通过SetThreadContext放到CONTEXT结构里面即可

0x04 规避检测

那么这里先找到OpenThread和MessageBoxA在内存中的地址

g_fnOpenThread = (FNOPENTHREAD)::GetProcAddress(LoadLibrary("kernel32.dll"), "OpenThread");  
g_dwHookAddr = (DWORD)GetProcAddress(GetModuleHandle("user32.dll"),"MessageBoxA");

然后拍摄快照遍历线程

HANDLE hTool32 = CreateToolhelp32Snapshot(TH32CS_SNAPTHREAD, 0);

定位到我们要hook的线程

if (Thread32First(hTool32, &thread_entry32))  
{  
do  
{  
if (thread_entry32.th32OwnerProcessID == GetCurrentProcessId())  
{  
dwCount++;   
  if (dwCount == 1)

这里定位到线程之后我们把THREADENTRY32里面的进程ID和线程ID打印出来

char szBuffer[0x100];  
ZeroMemory(szBuffer,0x100);  
sprintf(szBuffer, "PID:%x - TID:%x\n", thread_entry32.th32OwnerProcessID, thread_entry32.th32ThreadID);  
OutputDebugString(szBuffer);

然后通过内存中定位的OpenThread得到线程的句柄

hHookThread = g_fnOpenThread(THREAD_SET_CONTEXT | THREAD_GET_CONTEXT | THREAD_QUERY_INFORMATION, FALSE, thread_entry32.th32ThreadID);

拿到线程句柄之后我们通过SetUnhandledExceptionFilter注册一个异常处理函数MyExceptionFilter

SetUnhandledExceptionFilter(MyExceptionFilter);

这里需要了解SEH异常，在SEH异常中有三个返回值

1.EXCEPTION_EXECUTE_HANDLER(1) 执行except代码  
  

2.EXCEPTION_CONTINUE_SEARCH(0) 寻找下一个   


3.EXCEPTION_CONTINUE_EXECUTION(-1) 重新执行

通过ExceptionRecord里面的ExceptionCode判断错误码是否为EXCEPTION_SINGLE_STEP即单步异常以及ExceptionAddress判断是否到我们设置hook的地址，然后通过ChangeContext修改CONTEXT，再修改EIP

LONG WINAPI MyExceptionFilter(PEXCEPTION_POINTERS pExceptionInfo)  
{  
if (pExceptionInfo->ExceptionRecord->ExceptionCode == EXCEPTION_SINGLE_STEP)  
{  
if((DWORD)pExceptionInfo->ExceptionRecord->ExceptionAddress == g_dwHookAddr)  
{  
PCONTEXT pContext = pExceptionInfo->ContextRecord;  
ChangeContext(pContext);  
pContext->Eip = (DWORD)&OriginalFunc;  
return EXCEPTION_CONTINUE_EXECUTION;  
}  
}  
  

return EXCEPTION_CONTINUE_SEARCH;
}

这里ChangeContext要实现的功能就是修改文本框中的内容，esp指向的是MessageBox，那么esp+8即为MessageBox的第二个参数

void ChangeContext(PCONTEXT pContext)  
{  
char szBuffer[0x100];  
DWORD dwOldProtect = 0;  
DWORD dwLength = 0;  
LPSTR lpOldText = NULL;  
  

char szNewText[] = “SEH Hook successfully”;
lpOldText = (LPSTR)((DWORD)(pContext->Esp + 0x8));
dwLength = strlen(lpOldText);  


VirtualProtect(lpOldText, dwLength, PAGE_EXECUTE_READWRITE, &dwOldProtect);
memcpy(lpOldText, szNewText, dwLength);
VirtualProtect(lpOldText, dwLength, dwOldProtect, 0);
}

然后就是Eip修改到hook+2的位置，我们知道一般API起始的位置都是mov edi,edi，不能从这个起始位置执行，否则会死循环

g_dwHookAddrOffset = g_dwHookAddr + 2;  
  

void __declspec(naked) OriginalFunc(void)
{
__asm
{
mov edi,edi
jmp [g_dwHookAddrOffset]
}
}

然后将hook的地址放到dr0寄存器里面，设置dr7的L0位为1即局部有效，断点长度设置为1即18、19位设置为0即可，断点类型设置为访问断点对应的值为0(20、21位设置为0)，这样dr7寄存器的1-31位都为0，32位为1，所以将dr7寄存器的值设置为1。然后通过SetThreadContext存入CONTEXT结构

threadContext.Dr0 = g_dwHookAddr;  
threadContext.Dr7 = 1;  
  

SetThreadContext(hHookThread, &threadContext);
CloseHandle(hHookThread);

0x05 实现效果

首先还是使用常规的Inline hook配合E8、E9跳转，被CRC检测拦截

image-20220406192150175.png

然后这里把dll打包一下

image-20220406192750242.png

使用Hook_SEH.dll注入成功，没有被拦截

image-20220406192244269.png

这里为了可以使用sprintf配合OutputDebugString来看一下CONTEXT结构里面寄存器的值

image-20220406192420541.png

如下所示，hook成功

image-20220406192336400.png


赏

谢谢你请我吃糖果

支付宝
微信

扫一扫，分享到微信

tag:

    缺失模块。
    1、请确保node版本大于6.2
    2、在博客根目录（注意不是yilia-plus根目录）执行以下命令：
    npm i hexo-generator-json-content --save

    3、在根目录_config.yml里添加配置： 

      jsonContent:
    meta: false
    pages: false
    posts:
      title: true
      date: true
      path: true
      text: false
      raw: false
      content: false
      slug: false
      updated: false
      comments: false
      link: false
      permalink: false
      excerpt: false
      categories: false
      tags: true

俗话说“好记性不如烂笔头”，各个安全社区各自为战，当我们想要搜索某一方面的文章的时候总是得在各个平台之间来回横跳，于是乎，一个平台文章聚合搜索的想法诞生了。
然后正好我想有一个自己的博客，于是乎两者融合在了一起。
下面简单介绍各个导航的区别：
个人文章：本人的笔记、复现、总结等或者本人参与的共同创作。
收集文章：手工从公众号收集保存的文章，更新频率看本人喜好所以比较慢。
聚合文章：从各大平台收集整理，由工具实现，每天更新。
很惭愧，只做了一点微小的工作。