R3获取kernel32地址

获取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地址，