背景

因为之前装了某绒，某绒又有一个比较好用的ark工具某绒🗡，想着应该有机会利用一下它的驱动。

接着在driver下面找到了它的驱动，简单分析了一下，发现有可以利用的ioctl。这里有duphandle，操作和之前的procexp利用一样复制system的物理内存句柄就行了。

 问题

好歹是安全公司写的代码怎么可能没有校验呢，直接打开\\\\.\\Sysxxxx::SysUtils返回失败。接着继续看一看是哪里返回的失败，动态调试之后发现是这里返回的失败，其中sub_FFFFF807117C9060函数通过pid返回的是它自己记录的进程的相关结构体，+0x538标志的是当前进程有没有操作驱动的权限，为0调用返回才会成功。

 

 那对应的进程数据又是在哪里填写的呢，这里利用ida的search Immediate查找0x538，只有sub_FFFFF807117B3CF0赋值的eax，才有可能是0，下面的赋值为-1明显不符合要求。

这里的值是CheckProcess_FFFFF807117D61B0传出来的

 这里在进入看看函数的内部情况，很明显读取文件，目测是检验签名以及其他东西

 

 

 比如对比了pe的某段数据是否包含HRBR，其中sub_FFFFF807117A72E0中对比的是一段加密的数据，里面函数很多，具体对比的加密在哪我也不想找（有懒人！）。

 

利用

既然对比了pe文件的内容，那我用你自己的进程不就行了，这里测试注入到对应的进程，很明显安全软件都不会让你那么任意的注入。

 接着尝试傀儡进程（这里利用的是CrashDump.exe有签名并且没有dll依赖比较好操作），会发现在调用SetThreadContext失败。

 那怎么解决呢，其实也很简单，既然你不让我修改入口的，就把入口点设置到和你进程一样就行了，之前的代码用nop填充。

然后你会发现这里+538之后返回的值居然还是1，那他是什么时候被赋值的呢？

 经过简单的调试之后发现，sub_FFFFF807117A72E0的调用不通过，但是计数器+1了。

 后来点了点它的相关进程，发现只有HRSword.exe和sysdiagPoc.exe（x64）才会和驱动通信，所以这里选择HRSword在试试看，由于入口点在11A64d，所以一开始我也不想选它，写个nop文件都要写100多万行，vs编辑还任意崩溃，这里还是用notepad++编辑比较给力。

 最后成功复制到了物理内存的句柄，接下来就和procexp的利用一样了。