CK01

0x00  IopfCompleteRequest 函数 hook         1. 获取 nt 模块的加载基址 , 加上固定的 rva, 对 IopfCompleteRequest 函数的前 5 个字节 opcode 进  行 inline hook  2.MyIopfCompleteRequest 处理主要是判断 IoControlCode 是不是目标的 IoControlCode ，如果是的话则过滤需要的信息 ( 目  标 IoControlCode(g_IoCode), 返回地址 (retAddr), 目标驱动的加载基址 (BugSysBase), 返回地址 RVA(retAddr Rva))       0x01 IRP 处理函数 hook    1. 通过 ring3 层传进来的 IRP 处理函数 rva, 进行 inline hook      2. MyIrpFun 主要处理 : 设置了 int3 断点，方便调试 ; 过滤从 ring3 层传进来的 buffer 和 size 信息 , 在过滤函数中恢复回原来的指令，再执行回原本的 IRP 处  理函数 .                    2.1 在执行回原来的 IRP 处理函数之前，通过修改返回地址为挂钩函数的地址 (retHookA) ，当原来的 IRP 处理函数处理完后，返回时将跳到 retHookA 函数重新挂钩             0x02 实战 -HackSysTeam 项目池溢出        1. 漏洞分析时，一般都能获取到 poc( 这里我写了个 poc, 未溢出的 ; 溢出产生 BSOD 后打印不了信息 ; 实际分析时 , 可以改下 poc 代码 , 先确定 IRP 处理函数后 )         int main() { DWORD retLen; CHAR inputbuff[0x90] = { 0 }; DWORD intputLen; HANDLE hDevice = CreateFileW( L"\\\\.\\HacksysExtremeVulne

0x00  fuzz              1.https://www.watchdogdevelopment.com/ Download the latest version for testing       Software version ： 2.74.186.426       Driver version ： 2.74.0.259          2.Static analysis of the driver module to find the IRP processing function        3.Perform fuzz test on the 80002010 control code, and the system generates BSOD     0x01  Vulnerability analysis          1.Here I use the tools I wrote to assist analysis. IRP functions are hooked through the rva and drivers of the passed in IRP function.             2.Re-do fuzz, it will break into the MyIrpFun function, step by step here, through the help tool can be seen that the incoming buff is empty (the first fuzz fill 0x41, the second fuzz is filled with 0)         3.Keep single step and quickly reach the place where you refer to the null pointer       Since the buf passed in from the ring3 layer does not determine whether it is empty, the content

0x00 漏洞分析       参考： https://www.anquanke.com/post/id/86040       1. 运行 poc ， windbg 捕捉到崩溃异常，栈回溯，可以看出是 bGetRealizedBrush 函数里触发了异常         2. 分析下 bGetRealizedBrush 函数崩溃处的代码      2.1  ida 分析下可以看出 eax 引用的是 pEBRUSHOBJ 结构体偏移 0x34 处的结构再偏 移 1c 的数据从而访问无效地址           2.2 对 bGetRealizedBrush 下硬件执行断点 ,ebx = 96bd9af8 ,eax = fe8d8658, eax+1c = 0             3. poc 中的 FillRgn 函数调用内核 NtGdiFillRgn 函数 , 分析 NtGdiFillRgn           3.1 初始化 poc 中 hRgn 对象的数据          3.2  初始化 poc 中 hBrush 结构（ pEBRUSHOBJ ）        3.3  获取 poc 中 COLORREF 的值      3.4  到达 EngPaint 函数 , 可以知道大概传进的数据类型      3.5  _SURFOBJ  结构（ fe174250 ） , 而导致蓝屏的 pEBRUSHOBJ 结构（ 8a16eaf8 ） 偏移 0x34 是 fe174240,fe174240 偏移 0x1c 是 0;  也就是说    pEBRUSHOBJ 结构 偏移 0x34 中的值（ fe174240 ）再偏移 0x10 就是 _SURFOBJ  结构 ; 那么 _SURFOBJ  结构偏移 0xc 访问的是 hdev 字段 == （ pEBRUSHOBJ 结构（ 8a16eaf8 ） 偏移 0x34 （ fe174240 ） ,fe174240 偏移 0x1c ）    typedef struct _SURFOBJ {    DHSURF dhsurf;    HSURF  hsurf;    DHPD