Inject dll to process in driver
本来是叫用APC的机制在驱动注入应用层DLL到应用层的工程。
发现APC有很多缺点，不容易控制，如：触发，因而导致不支持卸载。
还有函数未公开，尽管导出了。
唯一的优点：系统的机制，不会轻易被干掉。
其实内核也可以创建进程的，从XP都有这个函数，且导出了，只不过后来变为以序数的形式导出的，而非导出名字了。
你我期望的注入的特点：
- 无硬编码，无特征码。
- 不使用汇编（包括机器码，shellcode等）。
- 不申请应用层的内存，特别是可执行的。
那思路是搜索PE的可写间隙。 - 可卸载。
是指驱动，而非被注入的DLL。
其实，被注入的DLL可卸载会更简单。不用暴力的遍历进程强制卸载，只需DLL留一个可卸载的IPC接口即可。 - 尽可能多的注入。
详细的见下。 - 预防多次注入。
- 注入的时机。
理论需要是越早越好，实际需求是只要能注入都好。
其实注入的实际越早，越不好处理，有很多的限制。
如：TLS的处理。 - 支持在操作系统启动的时候开启注入的功能。
- 其他。如：优化，快速等。
被注入的DLL的功能在乎你的想象，如：加入HOOK引擎（如微软的Detours等）。
对被注入进程的处理：
- Minimal processes。
这类进程没有用户态的空间，如：Secure System, Registry, System Idle Process, System, Interrrupts, Memory Compression等。
所以，这类进程不注入。 - Pico processes。
如：WSL1.0，不能在原生的Linux程序中注入DLL，要注入也是so，再一个注入的机制（加载模块）的方式也不一定一样。
所以，这类进程不注入。 - Protected processes。
保护进程的目的是保护自己禁止别人破坏，被注入了，都违背了保护进程的目的。
所以，这类进程不注入。
尽管也可以强制注入（用一些猥亵的手段）。 - Native processes。
这类进程的是子系统是Native的用户态EXE，造成的结果是：只有Ntdll.dll和自身。
如果注入了这类进程，那都破坏了Native processes的效果，变为非Native processes了。
所以，这类进程不注入。
这个需要被注入的DLL的子系统起码也是Native。你是吗？如果是那个这个DLL的功能不强大，有很多的限制。
本方案暂不支持。 - 支持WOW64进程.
无需多解释，必须支持。 - 托管的进程。
如：.net(APP),Java等，甚至是脚本引擎，虚拟机引擎等。
必须支持。 - 挂起的进程。
建议放过。
因为你注入即使成功了，也运行不起来的。
你变为运行状态了，在加载模块的时机还是可以注入你的。
注入的实际效果：
winlogon.exe, lsass.exe, 大部分的svchost.exe, msedge.exe(需要签名)，fontdrvhost.exe(需要签名)等进程都能注入。
设计思路：
1.
2.
3.
优化思路：
1.
2.
3.