GCC编译器允许使用下面的选项将RELRO全部开启.

开启以后检测ELF文件的安全属性可以看到RELRO的属性从Partial RELRO变成了Full RELRO。

不过我们现在还对RELRO一无所知，它为什么要存在，又能干什么呢？

1. 何为RELRO

1.1 消失的节

首先观察RELRO开启前后的节信息。

对比上面的信息可以发现，当RELRO全部开启时.got.plt节消失了，要知道该节位于可读可写段内，是为了延迟加载而存在的，当被调用函数位于动态链接库内且尚未被加载时，.plt节中首表项会发挥作用，因为它里面存储着_dl_runtime_resolve_fxsave函数的位置，_dl_runtime_resolve_fxsave函数会对动态链接库中的函数进行解析，然后修改.got.plt节中表项。.plt节中其余表项的首条jmp指令会指向.got.plt节中对应表项，如果函数尚未被解析，那么.got.plt节中对应表项存放的就是.plt节中表项的第二条push指令，继续运行第三条jmp指令时，该指令会指向.plt节中首表项，程序会开始运行_dl_runtime_resolve_fxsave函数，然后它解析调用动态链接库中的函数并让主程序调用。当函数再次被调用时，.got.plt节中对应表项存放的就是该函数的地址了，程序会使用该地址直接对函数进行调用。

此时.got.plt节的消失，是否也标志着延迟绑定的功能不在存在了呢？

1.2 延迟绑定的取消

添加-z relro -z now参数编译出来的程序，在其动态链接节中会出现BIND_NOW标志位。

将程序挂到GDB上后发现，当程序首次调用动态链接库LibC中的printf函数时，.plt节会直接指向printf函数的所在位置，进而直接对函数进行调用。

显然这时候已经没有延迟绑定了。在上面展示的信息中仍可以看到.got.plt的身影存在，它为什么会存在呢？

通过在_start函数设置断点可以发现，LD的_start函数被命中时，got.plt中内容还尚未被解析，但当主程序的_start函数被命中时，got.plt中的内容已经变成了printf函数的地址，因此这里猜测重定位的工作在程序正式运行前就由LD完成了。

对0x555555557fd0地址设置观察点后，发现该地址上的数据对被elf_dynamic_do_Rela函数改变（下面展示了完整的调用栈）。

dl_main函数是LD的主要组成部分，其主要作用是完成动态链接库的解析及管理任务。

在dl_main函数内部首先判断的是user_entry，由于LD本身可以作为程序运行并支持通过LD运行程序，所以当发现user_entry就是LD自身的入口地址时，就说明此时运行的程序是LD，后续会对传给LD的参数进行处理。如果允许的程序不是动态链接器自身，那么LD接下来就会开始对指定程序进行处理。

程序地址0x0000555555555050与起始地址0x555555554000的偏移是0x1050，LD地址0x00007ffff7fe5740与起始地址0x7ffff7fc9000的偏移是0x1c740，刚好可以和ELF头信息中记录的入口点对应上。

接下来继续将视线转移到程序独立执行时的代码部分，此时代码会对main_map进行设置，这个变量属于link_map结构体，用于记录程序的信息，其中main_map是链表头，用于记录程序本身的信息，而链表上的其他节点则会记录动态链接信息。

下面代码展示了main_map的创建及设置段头信息的过程。

之后代码会通过rtld_is_main判断LD是否作为独立的程序运行，如果不是，就会处理主程序中的动态链接信息。

从下面的信息中可以看到，elf_get_dynamic_info函数的主要作用就是从程序的ELF文件内提取动态链接节信息，用于后续访问。

完成.dynamic节信息的提取后，就是设置vDSO。

接下来继续设置link_map的链表，建立主程序和LD间的关系。

紧接着，LD会处理预加载信息。Linux中提供动态链接库预加载机制，使得用户可以自定义动态链接库，当自定义的动态链接库中存在与默认动态链接库中相同的函数时，会优先使用预加载库中的函数。

从下面可以看到检测是否存在预加载库的方式有三种，一是解析配置文件/etc/ld.so.preload，二是解析LD_PRELOAD环境变量，三是检测--preload参数。

处理好预加载信息后，就会通过_dl_map_object_deps函数将动态链接库加载进入内存，再设置线程信息。进行_dl_map_object_deps之前，会发现处理程序相关的动态链接库（vDSO、LD除外）都还没有被加载进入内存。

当程序运行的所需信息都完成加载后，接下来要进行的就是重要的重定位操作。

首先见到与延迟绑定相关的就是下面两条语句，它要求程序被分析时必须进行延迟重定位，GCC编译器中可以使用-pg选项开启分析功能，然后使用gprof工具对生成的分析信息进行解析。

当分析功能开启时，程序必须进行延迟重定位。重定位的具体操作是由_dl_relocate_object函数负责的，它会根据dl_lazy的数值决定是否进行延迟重定位。

进入_dl_relocate_object函数内观察link_map可以发现，程序所有需要的动态链接信息均已经是设置还好的，每次重定位元素都是当前指针指向的链表元素。

重定位过程中，首先需要修正的是DT_TEXTREL，这是因为ELF文件内可能存在使用绝对地址的情况，当LD检测到DT_TEXTREL标志位时，就会先修正那些编译时确立的绝对地址（编译器无法预知运行时的状况，原本的地址可能是无法使用的）。

这段代码算是历史遗留，因为现在基本是看不到直接使用绝对地址的情况了。

再之后，要进行重定位的就是GOT表，GOT表中使用的地址都是相对地址，所以运行在运行期通过ELF_DYNAMIC_RELOCATE进行修改。

在这段宏定义中，elf_machine_runtime_setup适用于判断是否需要延迟加载的，而宏ELF_DYNAMIC_DO_REL、ELF_DYNAMIC_DO_RELA是非常相近似的，它们分别对应不同的重定位表，从实际上来讲，这些实际对应的仍是_ELF_DYNAMIC_DO_RELOC。

从下面的宏中可以看到，ranges变量定义两项，该变量会记录需要重定位信息，最后一位区分是否进行延迟重定位。该变量会从重定位节中获取数据，元素0中记录重定位信息表.rela.dyn的信息，元素1记录重定位链接表.rela.plt的信息。

宏读取完重定位信息后，会调用elf_dynamic_do_Rela函数正式开始改写数据。

完成重定位之后，就会运行LibC的早期初始化函数以及进行清理信息等等操作，dl_main负责的启动任务也告一段落。

1.3 无效的Full-Relro？

通过对比查找动态链接库函数的地址0x6347e3701fc8和程序的起始地址0x6347e36fe000，可以发现其偏移值为3fc8，它位于.got节中，该节又位于可读可写段中。

.plt节中的push指令根据函数在.rela.plt节中的索引值压入栈内。

从上面可以看到，尽管当full reloro开启时，使得程序不再进行延迟绑定以及.got.plt节也随之消失，但是动态链接库只是从调用时加变成了运行前加载，.got.plt节也只是融入到.got内，实际函数调用时还是先通过.plt节中的jmp指令到.got内查找地址。

.got既然始终可写，那这开不开full reloro好像没有意义啊！

经过进一步排查，会发现ELF文件中的确是如此定义，但当运行时就会从5个段变成4个段，增加了一个不可写的段，查询的被调用函数地址也位于该段中。

这个段是什么时候添加上去的呢？

通过在_start处设置断点，可以发现当LD准备开始运行时，还是遵照ELF文件的约定保持4个段。当主程序准备开始运行时，最后一个段就会分裂出一个不可写的段。

前面说过重定位操作是dl_main函数中的_dl_relocate_object操作的，查看代码可以知道，在_dl_relocate_object函数的最后会检查l_relro_size变量的数值，如果不为0就调用_dl_protect_relro函数。

_dl_protect_relro函数会根据受保护地址的偏移值l->l_relro_addr重新划分出一个新段，这个新段的属性是只读的。

主程序的l_relro_size和l_relro_addr是由dl_main中的rtld_setup_main_map函数设置的，该函数内部会遍历ELF的段，其中就包含根据PT_GNU_RELRO段。

所有只读的重定位信息都会位于PT_GNU_RELRO段内，PT_GNU_RELRO段会将可读可写的LOAD段分配出一段只读空间，内当Full RELRO开启时，被调用函数的查询地址会被编译器分配到.got节内，.got节位于只读段的范围内，但当程序只是Partial RELRO时，被调用函数的查询地址会被编译器分配到.got.plt中，.got.plt节则位于可读可写段的范围内。

1.4 总结

RELRO的开启标志着重定位信息是否只读，Partial RELRO为了延迟绑定而存在，它允许.got.plt节存在且可读，保障运行时进行重定位可以改写被查找的调用函数地址。Full RELRO则将全部的重定位信息设置为只读状态，在编译阶段，仍会将待运行时重定位的函数放入可可段内，但会添加BIND_NOW标志进行标识，在运行阶段，LD会在程序正式运行前将函数重定位好，并从可写段中将重定位信息划分到只读段内，保障重定位信息后续不会被修改。

不管是静态链接的函数还是动态链接的函数，其具体实现都会位于可执行段中，区别在于调用它们的方式会有所差别，静态链接的函数会根据相对地址直接进行调用，而动态链接函数则需要根据PLT指示查找对应函数然后调用。当程序的重定位信息只是部分只读Partial RELRO时，程序会使用延迟重定位，此时保持函数解析方式或所在地址的.got.plt节是可写，仍具备掉包动态链接函数的可能性。而当重定位信息变成全部只读Full RELRO时，函数地址会被解析在.got节内，就无法对动态链接函数进行掉包了。

2. 绕过思路

2.1 预加载库

首先前面提到过dl_main函数在初始化时会检查当前是否设置了预加载库，当预加载库存在时，程序会优先使用预加载库中的函数，此时就可以实现动态链接的函数掉包。

2.2 信息泄露

当存在程序中存在自定义格式化字符串及设置缓冲区变量内容的机会时，可以将金丝雀及LibC的基地址泄露出来，并在栈上构造Shellcode，此时无需改写重定位信息，也可以借助函数的正常返回逻辑达到利用的效果。

2.3 穷途末路？

首先让我们回忆一下PWN一路以来都发生过什么。

首先是没有任何保护的程序，所有的利用点都对我们开放，这时候可以肆无忌惮的完成PWN。

当数据执行保护开启后，栈上的Shellcode已经不能运行了，但此时ASLR尚未开启，在内存布局情况已知的情况下，PWN难度仍算太高，我们既可以直接改写.got.plt，也可以函数的返回逻辑及LibC中可执行代码构造ROP，并调用Shell。

当金丝雀开启时，我们已经无法直接对栈上的数据进行覆盖，这个时候需要在泄露金丝雀数值或改写金丝雀数值上下一番功夫，才可以构造ROP调用Shell。当然想忽视金丝雀也可以，在程序调用动态链接的函数前提下，对.got.plt进行改写。

随着ASLR的全面启用，就逼着我们利用格式化字符串漏洞对信息进行泄露，否则就无法成功进行PWN。

当重定位信息变成完全只读后（此时所有保护全部打开），留给我们的路就只剩了借助预加载机制调包动态链接的函数，以及利用格式化字符串漏洞泄露信息后在进行PWN。

成功PWN的道路眼见着越来越窄，可以利用的点也只剩下了零星的几个，在真实环境中，这些苛刻的利用条件真能全部满足吗？此时如同来到了悬崖一般，前方似乎看不到前进的道路。

难道这就是终点吗？没有其他更加高级的突破方式了吗？

3. 示例讲解

3.1 预加载库

在示例程序的反汇编结果内可以发现，程序会调用LibC中的printf函数，因此我们可以自定义一个printf函数，并进行预加载，掉包LibC中的printf函数，示例动态链接库如下所示。

前面分析dl_main函数时，得到想要预加载机制运行有三种途径，一是借助LD提供的--preload参数，二是借助环境遍历LD_PRELOAD，三是借助配置文件/etc/ld.so.preload，下面会对1、2两种方式进行演示。

借助LD的--preload参数：

借助环境变量LD_PRELOAD：

使用环境变量时需要注意它的有效范围，通过export声明的环境变量只对当前Shell有效。比如上面的示例，只要新打开一个Shell，再运行./example就会发现它是会调用正确的printf函数。

将export声明的环境变量放入用户目录下~的.bashrc和.bash_profile时，也只能对对应用户的Shell生效，这是因为用户每打开一个Shell都会运行上面的文件，这样对应用户的Shell环境变量就一定会声明。Linux下通常会都会使用用户目录下~区分不同用户的配置，它都会作为隐藏目录.xxx存在，比如VIM的编辑信息.viminfo，用户登录时的自动启动程序.config/autostart/，以及设置信息.config/dconf/user（设置程序的信息会以数据库的形式保存）等等。

想要声明的环境变量永久生效时，则应该借助Linux通用的配置文件目录/etc中的profile文件，这样因为/etc下面设置是对整个系统生效的。比如上方提到的自动启动程序，也可也通过/etc/xdg/autostart目录设置所有用户都需要的自动启动程序。

3.2 信息泄露

通过将PWN入门-4-大闹ASLR中的示例程序添加-z relro -z now的链接选项，再次运行exploit，就会发现仍然是可以正常获取到Shell的。

这是当然的，毕竟原本也没有去改写.got.plt表，而是借助函数的返回逻辑构造ROP，运行栈上的Shellcode。

关于如何利用格式化字符串漏洞进行绕过的方式，PWN入门-4-大闹ASLR中已经进行过描述，在此就不过多赘述了。