能力值：
![]()
(RANK：410 )
|
-
-
2 楼
_lpGetModuleHandle是一个变量，当程序创建远程线程的时候，先用GetProcAddress函数获取本机计算机的GetModuleHandle函数的地址并保存到_lpGetModuleHandle变量中了，然后传给远程线程。所以在远程线程中已经可以直接调用_lpGetModuleHandle函数了（程序中的[ebp+_lpGetModuleHandle]只是在远程线程中重定_lpGetModuleHandle变量的地址而已，而在那之前_lpGetModuleHandle已经保存有GetModuleHandle函数的地址了）
|
能力值：
( LV2，RANK：10 )
|
-
-
3 楼
嗯,但创建远程线程时用GetProcAddress获得的只是系统映身到自已进程API入口线性地址,目标进程的这个涵数入口地址会是[ebx+创建进程的入口地址]吗?
|
能力值：
![]()
(RANK：410 )
|
-
-
4 楼
不是，用GetProcAddress获取的是实际系统中的Kernel32.dll里面的函数入口，这个入口是整个系统都能调用的。[ebp+xxx]只是重定到xxx的地址而已，其实远程线程的调用和在本地的调用是一样的，只是多了一个重定位地址而已。如本地和远程的对比：
首先用GetProcAddress取得函数的地址
invoke GetProcAddress,hWnd,ctext("GetModuleHandleA")
mov _GetModuleHandle,eax ;保存GetModuleHandle函数地址
invoke [_GetModuleHandle],NULL ;本地调用
;远程调用
call @f
@@:
pop ebp
sub ebp,offset @b ;取得远程线程代码的偏移址
invoke [ebp+_GetModuleHandle],NULL ;调用重定位后的_GetModuleHandle变量的地址
|
能力值：
( LV2，RANK：10 )
|
-
-
5 楼
即然GetProcAddress获取的是kernel32.dll函数的实际入口地址
那么,在注入代码中对API的调用,编译后的调用地址就是API的入口地址,应该是不需要重定位呀
比如:
invoke GetModulHandle,NULL 假设这个函数的实际入口地址是40000
编译之后就变成
call 40000
写入到目标进程时,也是把call 4000写进去,那么这个地址就应该是有效的,为什么还要重定位
|
能力值：
![]()
(RANK：410 )
|
-
-
6 楼
你的理解错了，“API函数的地址”是不用重定位，要重定位的是“保存API函数”地址的“变量地址（_GetModuleHandle）。
|
能力值：
( LV2，RANK：10 )
|
-
-
7 楼
哦哦,原来如此,我再去看看教程,谢谢小虾大侠....
向大虾靠齐 呵呵
|
能力值：
( LV2，RANK：10 )
|
-
-
8 楼
又出新问题啦
当在一个涵数中,定义一个局部变量后,编译
然后再用反汇编软件查看他的机器代码,发现,在地址中,根本就不在存这个变量的地址,只是函数入口处,利用
push ebp ;保存原ebp值
mov ebp,esp ;重新定义ebp的值
add esp,-4 ;分配4个字节的堆栈段用来临时存放局部变量
可以看出,这个地址是动态相对地址,应该不存在重定位问题...
不知道我的理解正不正确哦,小弟我很菜,大虾们可不要笑话俺呀
|
能力值：
![]()
(RANK：410 )
|
-
-
9 楼
局部变量不用重定位，因为他的存在只在于函数内部，是动态生成的。函数外部是无法使用的，不像全局变量地址是硬编码写入程序代码里面去的。
|
能力值：
( LV2，RANK：10 )
|
-
-
10 楼
呵呵,暂时弄通了一点点
1.对全局变量进行重定位
2.对API的调用换成 call API的实际地址
3.局部变量不存在地址的重定位
|
|
|
|
