当程序使用动态链接库中的函数时，由于链接器无法确定动态链接函数的地址信息，所以会将动态链接函数的绑定过程拖到运行期再进行操作，这一过程被称作是动态链接。

动态链接分成启动期链接和调用期链接两种，启动期链接指的是动态链接器LD运行时就将全部的动态链接函数地址解析好，调用期链接指的是动态链接函数首次调用时再进行解析，调用期链接的做法也被称作是延迟绑定。

在启动过程中，lazy变量是会决定是否在启动时对动态链接函数的地址进行解析，该变量的数值是根据.dynamic动态链接节中是否存在BIND_NOW标志进行设置的。

当程序不需要延迟绑定时，elf_machine_runtime_setup函数内部根据lazy变量的提示不会做任何的操作，紧接着会直接通过ELF_DYNAMIC_DO_XXX函数解析全部的动态链接函数。

当程序需要延迟绑定时，elf_machine_runtime_setup函数修改.plt节中首表项内的信息为解析函数的信息，使得首次调用时程序可以根据解析函数完成动态链接函数的解析操作，而ELF_DYNAMIC_DO_XXX函数则不会进行任何操作。

下面展示了调用期链接具体使用的解析函数。

从上面可以看到程序会根据0x404000中的地址信息决定调用的函数是什么，当解析函数完成解析工作后，0x404000中的地址一定会被修改为动态链接函数的所在地址，因此我们可以在0x404000地址上设置监测点，查看解析函数的真身是谁。

当监测点发现地址上的数据发生变动后，就会自动中断下来，通过查看调用栈可以知道_dl_runtime_resolve_fxsave负责解析动态链接函数。

_dl_runtime_resolve_fxsave函数的顺利工作，依赖ELF中动态链接节和重定位节信息，下面会先对这些相关的节进行分析。

.dynamic动态链接节是极为重要的，因为它里面存放着程序进行动态链接的全部所需信息，所以程序只需要一个.dynamic节，就可以检索到所有的相关信息。

.dynamic节可以看作是一张表，表中有各种各样的表项，表项信息通过Elf64_Dyn结构体进行描述。

在/usr/include/elf.h头文件中，可以找到Elf64_Dyn结构体的定义，d_tag成员用于标明表项对应的动态链接属性，d_un成员表示属性对应的具体数值。

d_tag的有非常多的种类，下面只列出了部分，完整的列表和解释可以在/usr/include/elf.h头文件中找到。

当动态链接属性是DT_FLAGS或DT_FLAGS_1时，d_val成员的数值会是DF_xxx或DF_1_xxx的中的某一个。

比如前面提到的BIND_NOW标志就是通过DT_FLAGS和DT_FLAGS_1进行描述的。

通过readelf工具的-d选项可以轻松的将动态链接节中的信息解析出来，这是非常方便且利于人类阅读的信息，它这里做了两大操作，一是找到.dynamic节的位置，而是将.dynamic节中的二进制信息解析成人类可读的信息。

接下来会演示如何手动找到.dynamic节的位置。

第一步查看ELF头信息，获得节头表的位置0x3720、节头表中表项大小0x40以及节头表中表项数量0x24。

找到节头表的位置后，可以非常轻松的将.dynamic节找出来（此处是21号表项），并根据节头表中表项的定义，将.dynamic节头的信息解析出来。

查看.dynamic节中内容，可以发现结果和上方readelf工具的-d选项的解析内容一致。

程序使用的函数和全局变量往往被称作是符号，.symtab节中会存储着全部的符号信息，而.dynsym节则会专门存储与动态链接相关的符号信息，.dynsym节与.symtab节共用同一个结构描述信息。

.dynstr节是专门为st_name成员设立的，作为索引值辅助.dynsym节匹配符号名。

GLibC通过.gnu.hash节加快符号的查找过程，关于.gnu.hash节是如何进行工作的问题，这里暂时不会进行解析。

在ELF文件中，重定位节分成.rela.dyn和.rela.plt两类，它们的区别在于重定位时修正地址的位置不同，其中.rela.dyn修正的信息位于.got节，.rela.plt节修正的信息位于.got.plt节。

至于.got节和.got.plt节，它们的区别在于完成重定位工作后，是否会被GNU_RELRO段设置为只读状态。

重定位节的作用可以从下面结构体的定义中略窥一二，其中r_offset成员指示出了需要修改的重定位信息位置，r_info成员则指示出了重定位类型和符号索引值，这里的索引值用于在.dynsym节内检索符号，r_addend成员显示的将加数指了出来（Elf64_Rel中使用隐式加数），r_addend和r_offset共同指明了待修改的重定位信息位置。

在上面我们介绍了与动态链接相关的各种节信息，但是目前我们只是知道它们会辅助动态链接函数调用的顺利进行，但是还并不知道它们之间是如何协同工作的，下面就会对此进行解析。

首次调用动态链接函数时，PLT中首条指令jmp会带我们前往第二条指令push，push会将符号在.rela.plt中的索引值压入栈内，最后一条jmp指令会带我们前往.plt节中的首表项。

.plt节中的首表项中存储着_dl_runtime_resolve_fxsave函数的地址，该函数进行重定位操作的关键函数。

push指令会将当前link_map信息所在地址压入栈内。

0x403ff0中保存的link_map信息地址和0x403ff8中保存的_dl_runtime_resolve_fxsave函数地址位于.got节，并由LD在启动时修改。

_dl_runtime_resolve_fxsave函数的反汇编如下所示，同时下方也写明了对汇编代码的解释。

从汇编代码中可以看到，函数由序言、获取动态链接函数、结语、调用动态链接函数四大部分组成。

首先看到的是序言部分，它的主要作用是分配栈空间。

在之前的PLT中，两个push指令先后向栈上压入了符号索引值以及link_map信息的地址，它们会提供给_dl_fixup函数使用，不将它们交给调用者寄存器传递，是因为调用者寄存器已经被用于放置动态链接函数的形参了。

这里会先将旧的rsp保存到rbx内，以便_dl_fixup函数获取参数。

动态链接函数最多接收六个参数作为形参，它们通过调用者寄存器进行保存，但由于接下来会使用_dl_fixup函数获取动态链接函数，该函数会使用新的形参，动态链接函数也需要在_dl_fixup函数运行后操作，所以这里会先将调用者寄存器中的参数保存到栈上，等到动态链接函数真被调用时再从栈上放出来。

这里还有一个特殊的寄存器rax，它并不在传递形参的寄存器范围之内，但它也是一个特殊的寄存器，会被用于存储返回值，同时也会被用于存储系统调用号。

保存好动态链接函数的参数后，就会从rbx中取出符号索引值以及link_map信息的地址，交给_dl_fixup函数，最后对_dl_fixup函数进行调用。

当函数返回之后，因为rax在后面会被使用，所以它会将返回值交给r11。

函数结语的作用是恢复栈空间和寄存器空间数据。

恢复好栈空间和寄存器数据后，动态链接函数有了正确被调用的基础，最后就是通过r11中保存的动态链接函数地址进行跳转，实现动态链接函数的调用。

从上面分析的反汇编结果中可以看到，_dl_runtime_resolve_fxsave函数的主要操作就是调用_dl_fixup函数，然后根据_dl_fixup函数的返回值进行跳转，那么接下来就让我们将视线转移到_dl_fixup函数的内部。

进入到_dl_fixup函数后，就会开始修正重定位信息。

函数内部首先出现的就是函数序言，其主要作用在于分配栈空间。

其中rbx、r12、r13、r14、r15位于被调用者寄存器范围内，它们的数值放入栈内，寄存器空间留给其他被调用者使用。

rdi中存储的是link_map的地址，这里会在rbx内再保存一份。

完成设置栈空间的操作后，首先会准备参数，其中r8寄存器中存储着.dynsym的地址，不过它是怎么取到的呢？

程序及动态链接库所需的链接信息由link_map结构体进行管理，在该结构体内存在着一个名为l_info的成员，该成员的作用是动态链接信息（根据.dynamic节获取），我们知道.dynamic节是一张表，每个表项都会占据一段空间，l_info中存储的就是表项的内存地址信息。

l_info成员位于偏移0x40处，大小为0x280，此处偏移0x70是为了寻找SYMTAB表项（.dynsym节）。

检索到SYMTAB表项的地址后，然后根据表项的定义，偏移0x8处就是.dynsym节的地址。

参与比较运算的数值分别是0x20和rdi+0x356地址上存储的数据，这里GLibC中使用了一个特别的用法，就是在变量名后添加:和数字，作用是指定变量占用的比特位，其中rdi+0x356对应着link_map中的l_audit_any_plt到l_find_object_processed成员，0x20就是用于判断l_find_object_processed成员的值是否为1。

test指令和je指令是较为常见的比较运算指令，其中的也逻辑并不复杂，test指令在进行完与运行后，会根据运算结果设置eflags标志位寄存器中的ZF标志位（Zero Flag），je指令会根据ZF标志位决定是否跳转（ZF为1时跳转），下面展示了test指令运行前后的eflags寄存器信息。

这里如果判断l_find_object_processed为1，就代表lt_library不需要处理，反之则进行处理，一般情况下都是不需要进行处理的。

rdx存储着link_map结构体中存储的基地址l_addr成员，之前mov (%rdi),%rdx操作将l_addr赋给rdx。

获得.dynsym节的真实地址后，就会再获取.dynstr节的真实地址，r9经过函数序言内的xor %r9d,%r9d后已经被置零，不管l_find_object_processed将是不是修正值交给了r9，程序使用r9进行加法运行产生的结果始终是正确的。

STRTAB表项位于l_info成员的0x68位置，这里取出STRTAB表项后，会将表项中存放的.dynstr节的地址放入rdi内。

获取完.dynstr节后，会接着按照上面的套路获取.rela.plt节信息。

rsi寄存器中存放的是_dl_runtime_resolve_fxsave函数寄过来的符号索引值，符号索引值值会先后通过lea指令扩张24倍。

l_info偏移0xf8处是JMPREL表项，该表项对应着.rela.plt节，偏移0x8可以获取.rela.plt节的地址，因为.rela.plt节也可以被看作是一张表，每个表项通过Elf64_Rela结构体描述，所以想要使用符号索引值检索重定位符号信息，就相当于索引值乘Elf64_Rela结构体大小。

不难知道Elf64_Rela结构体大小是24，此时就解开了lea指令将符号索引值扩张24倍的原因。

.rela.plt节的基地址加上索引偏移数值后，就可以得到指定重定位信息的地址，该地址位于r13寄存器内。

找到重定位信息中，可以在偏移0x0处找到r_offset成员，偏移0x8处找到r_info成员。

r_info表述的数值分成符号索引值和重定位类型两部分，高位是符号索引值，低位是重定位类型，shr指令右移32位取出符号索引值给rax，随后会利用lea指令将符号索引值乘24倍，24是Elf64_Sym结构体的大小。

r8中存储的是.dynsym节基地址，基地址加符号索引值乘符号表大小，就可以获取动态链接符号的信息了。

接下来cmp指令会将r_info的低位字节与0x7进行比较，定位方式ELF_MACHINE_JMP_SLOT对应的数值就是0x7，jne指令如果发现运行结果不是0（ZF为0），那么就会跳转到偏移0x663的位置，执行退出动作。

得到待重定位的符号信息后，会从符号信息中取出st_other成员（偏移0x5，st_name占4字节，st_info占1字节），然后st_other成员将与0x3进行比较，判断符号是否被导致，如果符号是导出的，那么就需要执行查找操作。

如果符号是未导出的，那么它对我们来讲就是已知的，就会直接跳转到偏移0x624处，不会执行查找操作。

执行符号查找操作时，会先从l_info成员中偏移0x208处取出VERSYM表项，如果发现符号信息为空就会跳转到0x199处，不对符号信息进行处理，反之则会进行处理。

当程序不进行跳转时，就会根据VERSYM表项地址偏移0x8找到.gnu.version节的地址。

然后再偏移6字节（前面lea (%rax,%rax,1),%rcx，先扩大了3倍）得到vd_cnt成员给edx，最后与0x7fff进行与运算，可以发现该数值就是重定位符号的版本信息索引值。

在此之后，会从l_info偏移0x320的位置取出l_versions成员（记录了所有的版本信息），借助刚刚找到的版本信息索引值（乘8是因为当前单位是字节，占8比特），可以将重定位符号对应的版本信息找出来。

最后如果发现版本信息中哈希值是控制，就会直接将清空整个版本信息。

设置完版本信息后，程序会从fs寄存器偏移0x18处取出数值给ecx，fs是为了保存局部线程信息而存在的，其中偏移0x18对应着multiple_threads，显然这里使用判断程序是否是多线程，如果发现multiple_threads为0，就会跳转到0x233的位置，不针对多线程进行设置。反之，则会设置偏移0x1c处的gscope_flag成员，避免不同线程间发生冲突。

确保多线程不会惹来麻烦的前提下，程序会开始通过_dl_lookup_symbol_x函数寻找符号，首先要做的是准备_dl_lookup_symbol_x函数需要的形参。

从汇编代码中可以看出函数接收8个参数，前6个通过寄存器传递，后2个通过栈空间传递，首先第一个参数rdi内存放的是之前通过.dynstr获得的重定位符号名，第二个参数rsi内存放是之前一直使用的link_map基地址，第三个参数rdx存储的是.dynsym节中的动态链接符号信息，第四个参数rcx是刚刚从link_map偏移0x3c8处取出的l_scope_mem成员，第五个参数r8是动态链接符号的版本信息，第六个参数r9存放1，第七个参数rsp+0x0存放的是1（它是前面根据多线程属性设置的数值），第八个参数rsp+0x8存放的是0。

_dl_lookup_symbol_x函数内部具体的操作暂时不从汇编代码的角度进行解析，这里暂时只需要知道它会根据符号名进行检索，返回对应动态链接库的基地址，并修改提供的动态链接符号信息。

找到动态链接的基地址后，首先做的从TLS中取出gscope_flag，判断是否是多线程，如果是多线程就会跳转到0x424处，反之则会继续执行。

由于当前程序是单线程的，所以会继续前往0x292处执行。

当程序在0x292处继续执行时，会先从rbp-0x40处取出.dynsym节中的动态链接符号信息，然后判断它是否为空值，为空值就前往0x496处。

当程序继续正常运行时，会在偏移0x6的位置的st_shndx成员，并于SHN_ABS进行比较，如果相等就跳转到0x536的位置，SHN_ABS代表符号是绝对的。

接下来做的是判断_dl_lookup_symbol_x函数返回的动态链接库基地址（r15存储）是否为空，如果为空也会跳转到0x536的位置。

上面做的判断主要是为了下面的操作，首先会将r15存储的libc.so.6基地址加上.dynsym节中puts符号信息的偏移值（这里偏移值已经被_dl_lookup_symbol_x函数修改），得到puts函数的最终地址，该最终地址会存储在rbp-0x38位置。

在完成取到puts函数真实地址的任务后，程序会对符号信息中的st_info成员跟STT_GNU_IFUNC0xa进行判断，如果相等就跳转到0x648的位置。

接下来要判断的是偏移0x378的l_reloc_result成员，只有当模块提供la_symbind时才会生效，当然这是小概率情况（0x367-0x387的区域会暂时忽略），所以它会先跳转到0x520，到达0x520后，会先将puts函数地址放入rax内，然后再跳回0x391的位置。

此时解析函数进入最后阶段，首先会判断_dl_bind_not的数值，确定PLT是应该更新的，最后将rax中的puts函数地址返回，由于r14中存放的一直是PLT的地址，所以mov %rax,(%r14)操作就相当于修改PLT中的地址为puts函数的地址，使得下次调用时可以之间前往puts函数。

从0x419到0x689之间存在着上面各种判断异常然后跳转的地址，由于这部分是小概率的情况，所以在这里不会进行解析。

回到_dl_runtime_resolve_fxsave首先做的就是将puts函数地址交给r11，然后对之前占用的寄存器数值进行恢复，然后就是调用r11中的地址，实现puts函数的调用。

首先_dl_runtime_resolve_fxsave函数是解析的第一步，它的作用是调用实际进行解析的_dl_fixup函数，并等待_dl_fixup函数返回，由于_dl_fixup函数返回的就是动态链接函数的地址，所以可以直接根据返回值进行调用，实现先解析后调用的操作。

负责解析的_dl_fixup函数依赖.dynamic节，.dynamic节内含有.dynsym节、.dynstr节以及.rela.plt节等动态链接所需的信息，因此只要包含一个.dynamic节就可以了，在link_map结构体中含有l_info成员，这个成员涵括.dynamic节中各个表项的地址。

不管是.dynsym节、.dynstr节还是.rela.plt节中的任意一个，它们都可以看作是一张表，里面可能具有非常多的表项，因此PLT阶段的push xxx会将索引值压入栈内，等待后续使用，该索引值是专门为PLT准备的，所以根据该索引值可用从.rela.plt节中检索到正确的表项，此时可以获取需要重定位的符号，由于.rela.plt节中的r_info高字节（右数4字节），存储着.dynsym节中符号的索引值，因此重定位符号的具体信息也有了，.dynsym节中的st_name成员存储的索引值可以从.dynstr节内检索到符号对应的字符串。

.dynsym节、.dynstr节以及.rela.plt节中的信息已经足够程序知道如何对符号进行重定位，但是符号的所在地还是未知的，只有在正确的动态链接库中找到符号才可以完成动态链接。在.dynamic节还保存着NEEDED和VERSYM信息，NEEDED指明了程序依赖的动态链接库，动态link_map结构体通过l_version成员专门保存这些信息，.gnu.version节提供了抓专门的索引值用于检索正确的动态链接库。

此时进入收尾阶段，首先会准备参数交给_dl_lookup_symbol_x函数用于检索符号所在动态链接库的基地址，并修改动态链接符号信息，然后获取动态链接函数的地址并修改PLT，最后对函数进行调用。

在延迟绑定的过程中，_dl_lookup_symbol_x函数的操作至关重要的，它查找符号的依据是.dynstr中的符号名，如果我们可以控制.dynstr节，那么就可以劫持_dl_runtime_resolve到我们期望的函数内部。

因为.dynstr节始终都是只读的，不能进行篡改，所以我们不得不将主意打到.dynamic节中，当程序是No RelRO属性时，.dynamic节就是可写可读的，如果我们修改.dynamic节中存储的.dynstr节地址，并且在新地址上构造假的.dynstr节，那么我们就可以完成劫持。

虽然.dynamic动态链接节变得不可写了，但是我们还有_dl_fixup函数接收的两个参数link_map l和int reloc_arg可以控制，这两个变量较为特殊，动态链接函数的调用占用了全部的调用者寄存器，使得它们只能通过栈进行保存，这对于我们是十分有利的，因为不再需要通过pop指令向栈上传输数据了。

首先我们要寻找一块空闲的可写可读内存（.bss段的上方是十分合适的，这一点在栈迁移中进行过解释），在这段内存区域中，我们需要向其中填充构造的重定位信息（参考.rela.plt定义）、符号信息（参考.dynsym定义）、字符串信息。

_dl_fixup函数首先会通过reloc_arg检索重定位信息，基地址是.rela.plt的起始地址，因此reloc_arg等价于假重定位信息起始地址减去.rela.plt的起始地址再除以24（单个表项对应的Elf64_Rela的大小），重定位信息中的r_info可用于检索符号信息，符号信息中的st_name可用于检索字符串，参考reloc_arg就可以构造出这些偏移值。

此时_dl_fixup函数会通过“坏的”reloc_arg一步步的逼迫函数需要从我们构造的“坏”数据中检索重定位相关的信息（Elf64_Rela、Elf64_Sym结构体内的其他信息则需要按需填充）。

检索到我们构造的假信息后，_dl_fixup函数会对版本信息进行检查，这个检查是可有可无的，因此这里我们需要泄露link_map的地址，将link_map上记录版本信息的数值设置为空值。

最后我们就可以让_dl_lookup_symbol_x函数根据我们指定的信息检索符号了。

_dl_fixup函数一共只依赖两个参数，而且这两个参数都是我们可以控制的，那么我们把这两个参数全部都伪造了不就可以吗，不一定需要泄露地址啊！

理想是很丰满的，但现实是更残酷的，_dl_fixup函数的内部虽然只用link_map的一小部分，但是借助_dl_lookup_symbol_x函数检索符号时，也会用到link_map中不少的内容，link_map是一个非常庞大的结构体，想要把它完全伪造好并不是一个简单的事情。

上面解析_dl_fixup函数时，我们发现当函数发现符号未导出时，就会采用已知符号地址加上修正值l_addr对符号进行检索，这种方式有一种好处，就是不需要大量使用link_map中的信息，减少了我们伪造的难度。

这时我们只需要构造link_map中的SYMTAB、STRTAB、JMPREL、l_addr几个部分。

由于代码比较简单，这里不会从反汇编的角度进行分析，下面直接给出了源代码。

通过上面的分析我们可以构造出下方所示的exploit。

此处利用的gadget是_libc_csu_init函数提供的，但我当前使用的GLibC版本是2.36，已经超出了2.33，GLibC不会再向ELF文件中插入_libc_csu_init函数。

为了使用_libc_csu_init函数提供的gadget，这里手动编译了GLibC的2.31版本，因为_libc_csu_init函数位于libc_nonshared.a的内部，所以可以利用ar工具解包静态链接库，得到保护_libc_csu_init函数的elf-init.oS文件，当可执行程序编译时将该文件加入链接，就可以得到_libc_csu_init函数了。

如果想要查看GCC在编译过程的详细信息，可以添加--verbose参数进行查看。

运行上电的exploit后，就可以成功获取Shell了。

假如上方exploit中的payload的占位字符不使用\x00进行填充，而是使用普通字符填充，那么当exploit运行时，我们就会可能无法获取Shell，因为这个时候程序就崩溃了。

程序崩溃的原因是，ret指令取出一个异常地址进行返回，进而导致崩溃。

这一问题出现的根源在于，GLibC通过__clone_internal函数创建进行时返回了错误码，这个错误码是内核返回的（syscall指令后出现），是内核出现错误了，还是我们的payload出现错误了呢？

要知道Linux内核是经过千锤百炼的，创建进程更是被大量使用的功能，出错的概率非常小，那么问题在我们这边？

如果仔细观察__clone_internal接收的参数可以知道，它的参数依赖于__spawnix函数接收的参数。

__spawnix函数接收的参数中，有一个非常特别的参数envp，它是程序的环境变量参数，被放置在栈上，因此它是非常容易被我们的payload影响的。

观察envp参数可以确认这一猜想，它里面的数据的确是payload里面用来填充的普通字符，但如果我们用\x00进行填充，那么envp就会被视作是空值，不会产生问题。

[培训]Windows内核深度攻防：从Hook技术到Rootkit实战！