本文同时发表在https://github.com/zhangyachen/zhangyachen.github.io/issues/147
最近在研究缓冲区溢出攻击的试验，发现其中有一种方法叫做ret2plt。plt？这个词好熟悉，在汇编代码里经常见到，和plt经常一起出现的还有一个叫got的东西，但是对这两个概念一直很模糊，趁着这个机会研究一下。
可以先说一下结论 : plt和got是动态链接中用来重定位的。
GOT
我们知道，一般我们的代码都需要引用外部文件的函数或者变量，比如#include<stdio.h>里的printf，但是由于我们代码中用到的共享对象是运行时加载进来的，在虚拟地址空间的位置并不确定，所以代码里call <addr of printf>的addr of printf不确定，只有等运行时共享对象被加载到进程的虚拟地址空间里时，才能最终确定printf的地址，再进行重定位地址。
看一个最简单的例子：
#include <stdio.h>
int main(){
printf("Hello World");
return 0;
}
用GDB调试一下(关于GDB调试汇编可以参考之前写的GDB 单步调试汇编 )：
(gdb) ni
0x000000000040054e in main ()
=> 0x000000000040054e <main+14>: e8 71 fe ff ff callq 0x4003c4 <printf@plt>
可以看出，call <addr of printf>被callq 0x4003c4代替，而这个0x4003c4并不是真正的printf函数的地址。
可能有人已经想到了，为什么不能直接在printf函数地址确定后，直接将call <addr of printf>修改为call <real addr of printf>，像静态链接那样呢（静态链接是在链接阶段进行重定位，直接修改的代码段）？有两个原因：
- 现代操作系统不允许修改代码段，只能修改数据段。
- 如果上面的代码片段是在一个共享对象内，修改了代码段，那么它就无法做到系统内所有进程共享同一个共享对象，因为代码段被修改了。而动态库的主要一个优点就是多个进程共享同一个共享对象的代码段，节省内存空间，但是进程拥有数据段的独立副本。
所以，我们很容易的想到，既然不能修改代码段，能修改数据段，我们可以在共享对象加载完成后，将真实的符号地址放到数据段中，代码中直接读取数据段内的地址就行，这里开辟的空间就叫做GOT(图有点挫)。
- 为每一个需要重定位的符号建立一个GOT表项。
- 当动态链接器装载共享对象时查找每一个需要重定位符号的变量地址，填充GOT。
- 当指令需要访问变量或者函数的地址时，从对应的GOT表项中读出地址，再访问即可。对应的指令可能是
callq *(addr in GOT)或者movq offset(%rip) %rax(%rax就是全局变量的地址，可以用(%rax)解引用)。
但是这样有一个问题，一个动态库可能有成百上千个符号，但是我们引入该动态库可能只会使用其中某几个符号，像上面那种方式就会造成不使用的符号也会进行重定位，造成不必要的效率损失。我们知道，动态链接比静态链接慢1% ~ 5%，其中一个原因就是动态链接需要在运行时查找地址进行重定位。
所以ELF采用了延迟绑定的技术，当函数第一次被用到时才进行绑定。实现方式就是使用plt。
PLT
我们可以先自己独立思考如何实现延迟绑定。
- 上文描述的是动态链接器主动将确定好的符号地址放到GOT中，延迟绑定需要我们自己主动告诉一个模块：我现在需要该符号的确定地址。假设该模块叫做
_dl_runtime_resolve()。 - 我们需要告诉
_dl_runtime_resolve()需要寻找的符号，也就是函数参数。可以放到栈中或者寄存器传递。 _dl_runtime_resolve()寻找完符号的特定地址后，放到寄存器上，比如%rax，供调用者使用。
所以初步的实现步骤是：
callq plt_printf <printf@plt>
......
......
plt_printf:
pushq %rbp ## allocate stack frame
movq %rsp,%rbp
pushq iden_of_printf ## 告诉_dl_runtime_resolve()找printf函数地址，即_dl_runtime_resolve()的参数>
callq _dl_runtime_resolve()
callq %rax ## %rax存放printf真实地址
leaveq ## deallocate stack frame
retq
上面的步骤可以实现通过一段小代码(plt)实现延迟绑定，但是存在一个问题：每一次调用printf的时候都需要走一遍这个步骤，然而printf的地址一旦确定就不会变了，所以我们需要一个缓存机制，将查找好的printf地址缓存起来。
PLT与GOT
上面说过_dl_runtime_resolve会将确定好的符合地址放到GOT中，那么在需要延迟加载的情况下，GOT里存放什么地址？上面说过需要我们需要将确定好的符号地址缓存起来，那么ELF是如何通过PLT与GOT的配合做到延迟加载的？我们直接看一个真实的例子就行：
#include <stdio.h>
int main(){
printf("Hello World");
printf("Hello World Again");
return 0;
}
gdb调试一下：
One 调用printf的plt
第一次调用printf，会调用printf对应的plt代码片段，与上面我们自己分析实现延迟加载的步骤一样：
(gdb) ni
0x000000000040054e in main ()
=> 0x000000000040054e <main+14>: e8 71 fe ff ff callq 0x4003c4 <printf@plt>
Two 调到printf对应的GOT里存储的地址
进到<printf@plt>看看：
(gdb) si
0x00000000004003c4 in printf@plt ()
=> 0x00000000004003c4 <printf@plt+0>: ff 25 56 05 20 00 jmpq *0x200556(%rip) # 0x600920 <printf@got.plt>
这里跳到了printf对应的GOT里存储的地址。（elf对got做了细分：got存放全局变量引用的地址，got.plt存放函数引用的地址）
看看动态链接在将确定的符号地址放到GOT前，GOT里存放的是什么地址：
(gdb) x 0x600920
0x600920 <printf@got.plt>: 0x004003ca
(gdb) disas 0x4003c4
Dump of assembler code for function printf@plt:
0x00000000004003c4 <+0>: jmpq *0x200556(%rip) # 0x600920 <printf@got.plt>
=> 0x00000000004003ca <+6>: pushq $0x0
0x00000000004003cf <+11>: jmpq 0x4003b4
End of assembler dump.
有意思的是jmp到了下一条指令的地址。其实这个时候我们已经可以猜出来了：延迟加载之前，got.plt里存放的是下一条指令地址，延迟加载之后，got.plt里存放的就是真实的符号地址，就可以直接jmp到printf函数里了。
Three 将printf对应的标识压到栈中，并跳到plt[0]
(gdb) ni
0x00000000004003ca in printf@plt ()
=> 0x00000000004003ca <printf@plt+6>: 68 00 00 00 00 pushq $0x0
(gdb) ni
0x00000000004003cf in printf@plt ()
=> 0x00000000004003cf <printf@plt+11>: e9 e0 ff ff ff jmpq 0x4003b4
(gdb) si
0x00000000004003b4 in ?? () ## 这里应该是plt[0]，但是gdb不知道为什么没有显示出来
=> 0x00000000004003b4: ff 35 56 05 20 00 pushq 0x200556(%rip) # 0x600910 <_GLOBAL_OFFSET_TABLE_+8>
Four 在plt[0]中调用_dl_runtime_resolve查找符合真实地址
说明这个是什么地址？？0x600910
(gdb)
0x00000000004003b4 in ?? ()
=> 0x00000000004003b4: ff 35 56 05 20 00 pushq 0x200556(%rip) # 0x600910 <_GLOBAL_OFFSET_TABLE_+8>
(gdb)
0x00000000004003ba in ?? ()
=> 0x00000000004003ba: ff 25 58 05 20 00 jmpq *0x200558(%rip) # 0x600918 <_GLOBAL_OFFSET_TABLE_+16>
(gdb)
_dl_runtime_resolve () at ../sysdeps/x86_64/dl-trampoline.S:34
34 subq $56,%rsp
=> 0x00007ffff7deef30 <_dl_runtime_resolve+0>: 48 83 ec 38 sub $0x38,%rsp
我们不用管_dl_runtime_resolve是怎么处理的，直接看_dl_runtime_resolve处理完成后printf对应的GOT的值：
(gdb)
56 jmp *%r11 # Jump to function address.
=> 0x00007ffff7deef8e <_dl_runtime_resolve+94>: 41 ff e3 jmpq *%r11
0x00007ffff7deef91: 66 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 data32 data32 data32 data32 data32 nopw %cs:0x0(%rax,%rax,1)
(gdb)
0x00007ffff7a7b5d0 in printf () from /lib64/libc.so.6
=> 0x00007ffff7a7b5d0 <printf+0>: 48 81 ec d8 00 00 00 sub $0xd8,%rsp
(gdb)
......
......
(gdb) x 0x600920
0x600920 <printf@got.plt>: 0xf7a7b5d0
与之前猜测的一样，printf对应的GOT表项目前已经存放了printf真实的虚拟地址。那么在下次调用时就避免再重定位，直接跳到printf地址了。
Five 第二次调用printf
(gdb) si
0x00000000004003c4 in printf@plt ()
=> 0x00000000004003c4 <printf@plt+0>: ff 25 56 05 20 00 jmpq *0x200556(%rip) # 0x600920 <printf@got.plt>
(gdb) x 0x600920
0x600920 <printf@got.plt>: 0xf7a7b5d0
(gdb) si
0x00007ffff7a7b5d0 in printf () from /lib64/libc.so.6
=> 0x00007ffff7a7b5d0 <printf+0>: 48 81 ec d8 00 00 00 sub $0xd8,%rsp
直接跳到printf的虚拟地址。
下面这张图可以总结上面的五步过程：
