同事有个需求，他的进程会加载一个DLL，他需要在那个DLL的DllMain函数执行之前控制DLL，修改DLL的内存。
以上工作要求全部在应用层执行。
这个其实有点悲剧。
因为这个需求其实有点坑，因为需要在应用层来做，而且好多事情都是高难度事情。
最后我给提了几种解决方案。
1：HOOK LoadLibraryA/W，然后发现如果是目标DLL，那么使用LoadLibraryEx不执行DllMain加载，然后等加载成功了之后，先处理DLL，最后创建线程执行DllMain。
优点：简单方便，工作量少。
缺点：DllMain线程环境、调用栈是伪造的，可能会被检测发现。
2：为了规避上面的问题，就不能用其他函数来做了，只能乖乖使用LoadLibrary族正统的函数，刚好，有一个。
当LoadLibraryA/W抓到了目标DLL之后，可以根据文件解析它的入口点，然后再在入口点处写入一个“C3”，即“ret”，是写入文件中，
然后再调用真实的LoadLibraryA/W函数加载，之后再去找这个入口点，修复C3，最后创建线程执行DllMain。
优点：比上面还简单。只是按位置写文件即可。
缺点：工作量比较大，需要修改原模块，可能导致原模块在其他进程中无法启动，DllMain线程环境、调用栈是伪造的，可能会被检测发现。
3：如果不想那么麻烦的话，还有个办法。
当LoadLibraryA/W抓到了目标DLL之后，拷贝一份目标DLL的文件，到其他的地方，比如Temp目录，
硬编码修改DLL文件的入口点内容，到本地内存中的一个函数里面，然后直接放行加载即可，这样，在模块加载之后，立刻就会从DllMain入口跳转到我们的函数中。而且不会有副作用。
但是为了它，我们实际上是模拟了整个一套API的接口，来让它以为自己是运行在正确的环境中的。
优点：对原模块没有修改，DLL启动之后，入口点会直接调用我们的函数。
缺点：工作量很大，路径被替换了，所以要多HOOK几个其他的函数，如GetModuleHandleA/W、GetModuleFileName、GetModuleFileNameEx等，在LoadLibraryA/W中，也需要判断模块是否已经加载，如果已经加载，则直接返回已经加载的模块handle。