前言：

逆一些东西，有点收获，就写篇随笔记录一下。因为写的随便，就不发看雪了。
今天一个朋友给我发了一个说是可以过TP的注入驱动，希望我逆一下看看是什么套路。

正文：

接收过来压缩包，看了一下

loadddll32和64分别是用在32和64的驱动，MemOpe和dnf.exe都是测试用例（不过我是用自己写的123.exe进行测试）。

先跑起来，看看线程和模块上有没有什么特别的地方

有一个线程Pchunter标红，而且“模块”那里没有，很可疑，先记下。
进程模块这里出现了注入的MemOpe.dll，看来不是内存加载。

为了减小干扰，先试试把“驱动级别的dll注入器.exe”进程强关了，看驱动还有没有效果。
测试了下仍可以正常注入。说明整个注入过程全由驱动完成，其加载驱动的exe不参与。

由于是x86sys程序，x64dbg用不上，只好拿IDA
（顺便吐槽一下，之前尝试用windbg动态调试看看。那用的叫一个难受，单步1步，windbg的反汇编窗口卡1秒。watch窗口也看不了一些[ebp-xx]之类的变量数据，可能是我还不会用）

代码很干净，函数很少。先看看输入表。
注意框起来的API，看到这几个api。我想到了ssdt，attach进程，创建线程，设置模块加载回调，申请r3内存空间。
接下来看看都有什么操作。
1.和加载驱动的exe通信，获取目标进程名和要注入的dll路径
2.设置模块加载回调

再看看回调里面有什么东西

3.判断LoadImage的进程是不是目标进程>>判断加载的模块是不是ntdll.dll>>开一个内核线程
注意这个ntdll

再来看看内核线程执行的函数里面有什么

4.Attach到目标进程（之前Pchunter看到的标红线程应该就是这个原因）
取R3和R0的ZwProtectVirtualMemory，ZwWriteVirtualMemory，ZwReadVirtualMemory，ZwQueryVirtualMemory，LdrLoadDll（无R0），ZwTestAlert（无R0） 地址
5.往目标进程申请一片full_access内存放shellcode，并对其用到的API地址进行重定位，同时对ntdll!ZwTestAlert下了一个HOOK，用来跳转到自己的shellcode
（一个进程被Create，ntdll最先加载，再由其加载kernel，user等其他系统DLL。由于ntdll上的线程会经过ntdll!ZwTestAlert这个API，所以对其下Hook来跳转执行自己的shellcode实现DLL加载）

效果图：

总结一下大致流程：

1.目标进程创建>>

2.驱动通过Load_Image回调发现目标进程及其Ntdll>>

3.对其Ntdll线程必经的ntdll!ZwTestAlert下Hook，同时写入shellcode>>

4.Ntdll线程经过ntdll!ZwTestAlert并跳转到shellcode>>

5.执行LdrLoadDll加载目标DLL>>

6.DLL注入完成

尾声：

感谢xjun前辈的指点

（小声bb一句，这全是破绽的驱动注入能过TP，我觉得TP真是放水了。。。）
说实话，一开始逆的时候。逆到那个Shellcode操作的地方，怎么都看不明白，还以为注入是靠的内核线程attach了目标进程，然后亲自调用了什么API才注入的。这里看不懂，就只能先看其他函数，全部看遍了也没有相关的API和操作。没办法，试试windbg，动态看看对shellcode的操作。。。结果怎么样，前面也吐槽了。
最后还是配合着看线程环境（看到注入dll的是ntdll模块上的线程），看目标进程里的shellcode才分析出来具体原理。

虽然很想发到看雪，不过拙文一篇，就不去献丑了。权当是自娱自乐了