获取Kernel32地址
如果是搞PE变形或者PE重构,再或者代码注入,很多时候我们要动态获取Loadlibrary()以及GetPeocAddress()两个函数的地址,通过这两个函数再动态获取其他函数地址,这样就可以免导入了。不然导入表里会暴露自己的调用。
对于静态PE文件重组来说,可以通过查看原有的PE文件是不是调用了这两个,或者加载了Kernell32.dll(通常都是已经加载了的),然后获取原来的地址,再自己调用。
而对于代码注入这种内存里跑的,通常是在注入程序里自己获取了相关函数的地址(同一一个运行的系统中,多个进程获取到的这两个函数的地址是一样的)so....
这次是直接通过其他方法获取kernel32的地址,通常用在PE文件变形中。主要还是处理内嵌机器码对导入表的依赖问题。
Ok就在刚刚搜索相关资料的时候,我发现有人通过类似姿在R3层隐藏DLL的调用。一会总结完这个再学习下那个东西。
获取Kernel32的地址网上也有很多姿势,我总结一个我觉得靠谱的,之前一直在研究驱动相关,想在R0搞一些事情,很多时候都要通过统配标识符来定位相关地址,比如Hook SSDT,64位里很多东西都要通过寻找特征码来找,要么就通过回调,但是因为是要搞事情,很多时候回调搞不定。So...,但是面临的问题就是寻找特征码这个姿势并不稳定,很容易就出问题。你分析了XP win7 win10 那么写了个代码,测试OK敢上线吗?一个问题是不同系统之间可能不一样,同一个系统之间不同版本也可能不同,没有公开的东西,微软有权利随便更改结构(虽然通常不会改,以为没必要)。最后导致的不兼容等蓝屏问题,这个锅当然也是自己背,尤其是做产品,很多时候我们要记住,自己是产品,不是什么外挂和小众软件。很多时候,用户并不懂,蓝屏了的话就是你产品不行,不管你采取了多底层的保护方式,所以很多安全厂商也不想在自己的产品上做减法。这也是为什么如果你搞对抗,就会发现64位出来之后,很多杀软都变得低调了很多,经过测试,在R0里的话,90%的杀软你直接一个基本结束线程的函数就能KO掉服务进程了。好了就这样,废话说多了。回来找kernel32地址。
大体姿势是这样:
FS--->TEB--->PEB---> PEB_LDR_DATA.InInitialzationOrderModuleList
1.FS寄存器指向的是TEB的地址。
2.TEB的偏移[0x30]处是PEB地址。
3.PEB里面偏移[0xc]处是PEB_LDR_DATA地址。
4.PEB_LDR_DATA结构体里面偏移[0xc]是InLoadOrderModuleList地址,