0x00
AppInit_Dlls注入方法特别简便，日常注入测试首选，在win7上屡试不爽，具体原理如下：
support.microsoft.com/en-us/help/…
docs.microsoft.com/en-us/windo…windows-7-and-windows-server-2008-r2
但是最近使用win10系统之后发现，注入方法失效。在检查过所有的配置都正确之后，决定使用调试器看看原因是啥。
0x01
调试堆栈如下，具体是怎么找到这里的，我提供三种方法做参考：
1、 从原理上来说，注入的dll是被user32加载的，用IDA打开user32检查下是否有函数名与AppInit_Dlls相关的函数；
2、 在低版本的系统上在DllMain 的 DLL_PROCESS_ATTACH 处理处下断点，检查调用堆栈；
我使用的是第三种方法，之前在StackOverflow找问题是偶然发现的_。
IDA打开Kernel32.dll，看一下
LoadAppInitDllsImplementation。原因很简单，汇编见下图：
可以看到 对 0x67的Class进行
NtQuerySystemInformation后，检查ReturnLength与2相与，如果为0的话，不加载DLL直接返回。
Class 0x67在网络上很容易找到，这个链接的信息比较充足： www.geoffchappell.com/studies/win… 。
显然，0x2为 CODEINTEGRITY_OPTION_TESTSIGN。这个标志可以在bcdedit中设置，命令为 bcdedit.exe –set testsigning
on，用于设置系统的test mode，在驱动开发中比较有用，这里就不深入讨论。
但是测试bcdedit设置参数，一直提示没有权限啥啥的，谷歌大法发现BIOS中有个 secure boot设置，只有disable之后才能使用bcdedit设置这个Flag。
一切跑过一次以后，dll顺利注入。
0x02
后续搜AppInit_Dlls发现msdn中一直挂着这个主题，只是被我忽略了。。。
docs.microsoft.com/en-us/windo…
文档说的挺对，Secure Boot对AppInit_Dlls的限制合情合理，而且是从WIN8开始就已经出现的特性。