聊聊Linux动态链接中的PLT和GOT(3)——公共GOT表项
来源:互联网 发布:数据库系统由什么构成 编辑:程序博客网 时间:2024/04/30 10:47
前文(聊聊Linux动态链接中的PLT和GOT(2)——延迟重定位)提到所有动态库函数的plt指令最终都跳进公共plt执行,那么公共plt指令里面的地址是什么鬼?
把test可执行文的共公plt贴出来:
080482a0 <puts@plt-0x10>: 80482a0: pushl 0x80496f0 80482a6: jmp *0x80496f4 ...
第一句,pushl 0x80496f0,是将地址压到栈上,也即向最终调用的函数传递参数。
第二句,jmp *0x80496f4,这是跳到最终的函数去执行,不过猜猜就能想到,这是跳到能解析动态库函数地址的代码里面执行。
0x80496f4里面住着是何方圣呢?下面使用gdb调试器将它请出来:
$ gdb -q ./test...(gdb)x/xw 0x80496f40x80496f4 <_GLOBAL_OFFSET_TABLE_+8>: 0x00000000(gdb) b mainBreakpoint 1 at 0x80483f3(gdb) rStarting program: /home/ivan/test/test/testBreakpoint 1, 0x80483f3 in main ()(gdb) x/xw 0x80496f40x80496f4 <_GLOBAL_OFFSET_TABLE_+8>: 0xf7ff06a0
从调试过程可以发现,0x80496f4属于GOT表中的一项,进程还没有运行时它的值是0x00000000,当进程运行起来后,它的值变成了0xf7ff06a0。如果做更进一步的调试会发现这个地址位于动态链接器内,对应的函数是_dl_runtime_resolve。
嗯,是不是想到了什么呢。所有动态库函数在第一次调用时,都是通过XXX@plt -> 公共@plt -> _dl_runtime_resolve调用关系做地址解析和重定位的。
谈到这里,其实还有谜底是没有解开的,以printf函数为例:
- _dl_runtime_resolve是怎么知要查找printf函数的
- _dl_runtime_resolve找到printf函数地址之后,它怎么知道回填到哪个GOT表项
- 到底_dl_runtime_resolve是什么时候被写到GOT表的
前2个问题,只需要一个信息就可以了知道,这个信息就在藏在在函数对应的xxx@plt表中,以printf@plt为例:
printf@plt>: jmp *0x80496f8 push $0x00 jmp common@plt
第二条指令就是秘密所在,每个xxx@plt的第二条指令push的操作数都是不一样的,它就相当于函数的id,动态链接器通过它就可以知道是要解析哪个函数了。
真有这么神吗?这不是神,是编译链接器和动态链接器故意安排的巧合罢了。
使用readelf -r test命令可以查看test可执行文件中的重定位信息,其中.rel.plt这一段就大有秘密:
$ readelf -r test....Relocation section '.rel.plt' at offset 0x25c contains 3 entries: Offset Info Type Sym.Value Sym. Name 080496f8 00000107 R_386_JUMP_SLOT 00000000 puts 080496fc 00000207 R_386_JUMP_SLOT 00000000 __gmon_start__ 08049700 00000407 R_386_JUMP_SLOT 000000000 __libc_start_main
再看看各函数plt指令中的push操作数:
printf对应push 0x0
gmon_start对应push 0x8
__libc_start_main对应push 0x10
这3个push操作数刚好对应3个函数在.rel.plt段的偏移量。在_dl_runtime_resolve函数内,根据这个offset和.rel.plt段的信息,就知道要解析的函数。再看看.rel.plt最左边的offset字段,它就是GOT表项的地址,也即_dl_runtime_resolve做完符号解析之后,重定位回写的空间。
第三个问题:到底_dl_runtime_resolve是什么时候被写到GOT表的。
答案很简单,可执行文件在Linux内核通过exeve装载完成之后,不直接执行,而是先跳到动态链接器(ld-linux-XXX)执行。在ld-linux-XXX里将_dl_runtime_resolve地址写到GOT表项内。
事实上,不单单是预先写_dl_runtime_resolve地址到GOT表项中,在i386架构下,除了每个函数占用一个GOT表项外,GOT表项还保留了3个公共表项,也即got的前3项,分别保存:
got[0]: 本ELF动态段(.dynamic段)的装载地址
got[1]:本ELF的link_map数据结构描述符地址
got[2]:_dl_runtime_resolve函数的地址
动态链接器在加载完ELF之后,都会将这3地址写到GOT表的前3项。
其实上述公共的plt指令里面,还有一个操作数是没有分析的,其实它就是got[1](本ELF的link_map)地址,因为只有link_map结构,结合.rel.plt段的偏移量,才能真正找到该elf的.rel.plt表项。
有兴趣的读者可以使用gdb,在执行到main函数时,将GOT表的这3项数据看一下,验证一下。
好了,谈到这里是否对PLT和GOT机制有个更清晰认识了呢?最后一篇会使用图文结构将整个PLT/GOT机制串起来。
- 聊聊Linux动态链接中的PLT和GOT(3)——公共GOT表项
- 聊聊Linux动态链接中的PLT和GOT(1)——何谓PLT与GOT
- 聊聊Linux动态链接中的PLT和GOT(2)——延迟重定位
- 聊聊Linux动态链接中的PLT和GOT(4)—— 穿针引线
- Linux动态链接之GOT与PLT
- Linux动态链接之GOT与PLT
- Linux动态链接之GOT与PLT
- Linux动态链接之GOT与PLT
- 理解got和plt
- ELF文件动态链接时 GOT,PLT 的变化过程
- ELF文件动态链接时 GOT,PLT 的变化过程
- ELF文件动态链接时 GOT,PLT 的变化过程
- ELF文件动态链接时 GOT,PLT 的变化过程
- 理解ELF动态链接中GOT与PLT表
- 动态链接库中函数的地址确定---PLT和GOT
- 动态链接库中函数的地址确定---PLT和GOT
- 动态链接库中函数的地址确定---PLT和GOT
- 动态链接库中函数的地址确定---PLT和GOT
- Solving state function of continuous-time LTI system
- 让你痛苦的5个心理陷阱
- 笔试模拟题 中兴---单词接龙
- memccpy
- 第一篇博客,试水 关于开发板挂载u盘的问题
- 聊聊Linux动态链接中的PLT和GOT(3)——公共GOT表项
- 没解锁的一加手机刷Recovery的方法
- ubuntu-14.04.3-server-amd64下源码安装mysql-5.6.27-linux-glibc2.5-x86_64
- 乐学成语实现之四:显示所有动物类成语的列表
- Linux进程同步之POSIX信号量(非原创)
- 加载时的动画效果
- 1、AngularJs的简介和MVC模式
- HDU 1087 Super Jumping! Jumping! Jumping!
- 6.2输入一行字符,分别统计出其中英文字母、空格、数字和其他字符的个数。