同事遇到了一个问题(在DllMain函数之前抢控制权)

同事有个需求,他的进程会加载一个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。

转载于:https://www.cnblogs.com/suanguade/p/11495254.html

你可能感兴趣的:(同事遇到了一个问题(在DllMain函数之前抢控制权))