R3获取kernel32地址

本文介绍了在代码注入和PE重构中如何动态获取Kernel32.dll中LoadLibrary()和GetProcAddress()函数的地址,以避免导入表暴露调用。通过FS寄存器、TEB、PEB_LDR_DATA等结构,详细解释了一个在R3层获取Kernel32基地址的可靠方法,并提供了C++测试代码。这种方法适用于不同系统和版本,但在产品上线前需要进行全面测试。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

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

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值