[Rootkit] 无痕 hook - 硬件断点

hook方式有多种，这里做了一个系统性的总结对比，如下：

https://www.cnblogs.com/theseventhson/p/14324562.html 之前这里做了接受消息的hook，用的就是最初级的hook方式: jmp到我们自己的处理逻辑。上面也分析了，这种方式缺点非常明显；最牛逼的神级hook：VT读写分离前面已经介绍过了，今天继续介绍高级的hook方式：硬件断点；

现代软件开发，尤其是大型软件开发，绝对不可能一步到位，开发期间肯定存在各种bug。为了方便找到这些bug，软件上有专门的调试机制，比如在某行代码下软件断点，然后步过、步进等。这里软件断点本质就是在用户指定的地址改写成0xCC，也就是int 3指令，cpu执行到这里后就产生异常，然后由中断向量表的3号routine来处理这个异常。除了软件断点，x86架构的cpu也支持设置硬件断点，整个图示图下：

和硬件调试相关的寄存器一共有7个：DR0-DR3分别设置需要断下的地址，DR7可以控制DR0-DR3是否有效。如果需要启用这4个调试寄存器，DR7要设置为0b01010101，也就是L0\L1L2\L3都要为1；

正式介绍代码前，先介绍一个重要的结构体：PCONTEXT，如下：

typedef struct DECLSPEC_NOINITALL _CONTEXT {
    
    

    //
    // The flags values within this flag control the contents of
    // a CONTEXT record.
    //
    // If the context record is used as an input parameter, then
    // for each portion of the context record controlled by a flag
    // whose value is set, it is assumed that that portion of the
    // context record contains valid context. If the context record
    // is being used to modify a threads context, then only that
    // portion of the threads context will be modified.
    //
    // If the context record is used as an IN OUT parameter to capture
    // the context of a thread, then only those portions of the thread's
    // context corresponding to set flags will be returned.
    //
    // The context record is never used as an OUT only parameter.
    //

    DWORD ContextFlags;

    //
    // This section is specified/returned if CONTEXT_DEBUG_REGISTERS is
    // set in ContextFlags.  Note that CONTEXT_DEBUG_REGISTERS is NOT
    // included in CONTEXT_FULL.
    //

    DWORD   Dr0;
    DWORD   Dr1;
    DWORD   Dr2;
    DWORD   Dr3;
    DWORD   Dr6;
    DWORD   Dr7;

    //
    // This section is specified/returned if the
    // ContextFlags word contians the flag CONTEXT_FLOATING_POINT.
    //

    FLOATING_SAVE_AREA FloatSave;

    //
    // This section is specified/returned if the
    // ContextFlags word contians the flag CONTEXT_SEGMENTS.
    //

    DWORD   SegGs;
    DWORD   SegFs;
    DWORD   SegEs;
    DWORD   SegDs;

    //
    // This section is specified/returned if the
    // ContextFlags word contians the flag CONTEXT_INTEGER.
    //

    DWORD   Edi;
    DWORD   Esi;
    DWORD   Ebx;
    DWORD   Edx;
    DWORD   Ecx;
    DWORD   Eax;

    //
    // This section is specified/returned if the
    // ContextFlags word contians the flag CONTEXT_CONTROL.
    //

    DWORD   Ebp;
    DWORD   Eip;
    DWORD   SegCs;              // MUST BE SANITIZED
    DWORD   EFlags;             // MUST BE SANITIZED
    DWORD   Esp;
    DWORD   SegSs;

    //
    // This section is specified/returned if the ContextFlags word
    // contains the flag CONTEXT_EXTENDED_REGISTERS.
    // The format and contexts are processor specific
    //

    BYTE    ExtendedRegisters[MAXIMUM_SUPPORTED_EXTENSION];

} CONTEXT;

typedef CONTEXT *PCONTEXT;

这个结构体保存了常用的所有寄存器，OD、x32dbg、x64dbg等常见的调试器都用了这个结构体读取某个时间点时进程的寄存器，分析人员也可以直接在调试器的界面更改寄存器的值，非常方便。这些功能都是通过读写PCONTEXT结构体实现的。那么问题来了，怎么才能得到PCONTEXT结构体了？

PCONTEXT为调试而生，为了得到这个结构体，就要想办法产生异常；windwos操作系统专门针对异常的处理有一整套完整的机制，这里为了理解，简单介绍一下：windwos下3环进程运行时，如果遇到异常(比如除0)，大致的处理顺序如下：

• 先看看有没有调试器(通过编译器运行exe也算)，如果有，就发消息给调试器让其处理；
• 如果没有调试器，或则调试器没处理，进入进程自己的VEH继续处理。VEH本质是个双向链表，存储了异常的handler代码，此时windwos会挨个遍历这个链表执行这些handler(感觉原理和vmp很像，估计vmp借鉴了这里的思路)
• 如果VEH还没处理好，接着由线程继续处理。线程同样有个异常接管的链表，叫SEH；windows同样会遍历SEH来处理异常
• 如果SEH还没处理好，继续给线程的UEH传递，UEH只有一个处理函数了
• 如果UEH还没处理好，就回到进程的VCH处理；

基于windwos开发的应用数以万计，微软绝对不可能出厂时就考虑到所有的异常，其各种handler不太可能处理所有的异常，所以微软又开放了接口，让开发人员自定义异常的handler；对于开发人员来说，肯定是越靠前越好，所以这里选择VEH来添加自定义的handler(调试器是最先收到异常通知的，但外挂在正常使用时不太可能有调试的功能，除非开发人员自己单独开发调试器的功能，这样成本太高了)。windwos开放了一个API，叫AddVectoredExceptionHandler，可以给VEH添加用户自定义的异常处理handler，如下：

AddVectoredExceptionHandler(1, PvectoredExceptionHandler