[ctf wiki pwn] stackoverflow：ret2dlresolve系列2（_dl_runtime_resolve glibc源码解析实践）
Posted 漫小牛
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了[ctf wiki pwn] stackoverflow：ret2dlresolve系列2（_dl_runtime_resolve glibc源码解析实践）相关的知识，希望对你有一定的参考价值。
文章目录
1 _dl_runtime_resolve入口
_dl_runtime_resolve在glibc中是采用汇编实现的，其中32位的入口点在/sysdeps/i386/dl-trampoline.S，64位的入口点在/sysdeps/x86_64/dl-trampoline.S。本文主要分析32位源码，版本为2.23。
从glibc在线源码网站https://elixir.bootlin.com/glibc/glibc-2.23/source/sysdeps/i386/dl-trampoline.S可看到该文件的汇编代码：
.text
.globl _dl_runtime_resolve
.type _dl_runtime_resolve, @function
cfi_startproc
.align 16
_dl_runtime_resolve:
cfi_adjust_cfa_offset (8)
pushl %eax # Preserve registers otherwise clobbered.
cfi_adjust_cfa_offset (4)
pushl %ecx
cfi_adjust_cfa_offset (4)
pushl %edx
cfi_adjust_cfa_offset (4)
movl 16(%esp), %edx # Copy args pushed by PLT in register. Note
movl 12(%esp), %eax # that `fixup' takes its parameters in regs.
call _dl_fixup # Call resolver.
popl %edx # Get register content back.
cfi_adjust_cfa_offset (-4)
movl (%esp), %ecx
movl %eax, (%esp) # Store the function address.
movl 4(%esp), %eax
ret $12 # Jump to function address.
cfi_endproc
.size _dl_runtime_resolve, .-_dl_runtime_resolve
汇编代码中通过L16的call _dl_fixup执行主要的resolver功能。在/sysdeps/i386/dl-machine.h可查看函数_dl_fixup的原型：
extern ElfW(Addr) _dl_fixup (struct link_map *l,
ElfW(Word) reloc_offset)
该函数共有两个参数，对应L14和L15的两条movl指令，一个是eax寄存器中存储的link_map，edx是GOT表中关于PLT重定位的索引值。
2 _dl_fixup函数
2.1 函数源码
该函数的位置在/elf/dl-runtime.c
DL_FIXUP_VALUE_TYPE
attribute_hidden __attribute ((noinline)) ARCH_FIXUP_ATTRIBUTE
_dl_fixup (
# ifdef ELF_MACHINE_RUNTIME_FIXUP_ARGS
ELF_MACHINE_RUNTIME_FIXUP_ARGS,
# endif
struct link_map *l, ElfW(Word) reloc_arg)
const ElfW(Sym) *const symtab
= (const void *) D_PTR (l, l_info[DT_SYMTAB]);
const char *strtab = (const void *) D_PTR (l, l_info[DT_STRTAB]);
const PLTREL *const reloc
= (const void *) (D_PTR (l, l_info[DT_JMPREL]) + reloc_offset);
const ElfW(Sym) *sym = &symtab[ELFW(R_SYM) (reloc->r_info)];
void *const rel_addr = (void *)(l->l_addr + reloc->r_offset);
lookup_t result;
DL_FIXUP_VALUE_TYPE value;
/* Sanity check that we're really looking at a PLT relocation. */
assert (ELFW(R_TYPE)(reloc->r_info) == ELF_MACHINE_JMP_SLOT);
/* Look up the target symbol. If the normal lookup rules are not
used don't look in the global scope. */
if (__builtin_expect (ELFW(ST_VISIBILITY) (sym->st_other), 0) == 0)
const struct r_found_version *version = NULL;
if (l->l_info[VERSYMIDX (DT_VERSYM)] != NULL)
const ElfW(Half) *vernum =
(const void *) D_PTR (l, l_info[VERSYMIDX (DT_VERSYM)]);
ElfW(Half) ndx = vernum[ELFW(R_SYM) (reloc->r_info)] & 0x7fff;
version = &l->l_versions[ndx];
if (version->hash == 0)
version = NULL;
/* We need to keep the scope around so do some locking. This is
not necessary for objects which cannot be unloaded or when
we are not using any threads (yet). */
int flags = DL_LOOKUP_ADD_DEPENDENCY;
if (!RTLD_SINGLE_THREAD_P)
THREAD_GSCOPE_SET_FLAG ();
flags |= DL_LOOKUP_GSCOPE_LOCK;
#ifdef RTLD_ENABLE_FOREIGN_CALL
RTLD_ENABLE_FOREIGN_CALL;
#endif
result = _dl_lookup_symbol_x (strtab + sym->st_name, l, &sym, l->l_scope,
version, ELF_RTYPE_CLASS_PLT, flags, NULL);
/* We are done with the global scope. */
if (!RTLD_SINGLE_THREAD_P)
THREAD_GSCOPE_RESET_FLAG ();
#ifdef RTLD_FINALIZE_FOREIGN_CALL
RTLD_FINALIZE_FOREIGN_CALL;
#endif
/* Currently result contains the base load address (or link map)
of the object that defines sym. Now add in the symbol
offset. */
value = DL_FIXUP_MAKE_VALUE (result,
sym ? (LOOKUP_VALUE_ADDRESS (result)
+ sym->st_value) : 0);
else
/* We already found the symbol. The module (and therefore its load
address) is also known. */
value = DL_FIXUP_MAKE_VALUE (l, l->l_addr + sym->st_value);
result = l;
/* And now perhaps the relocation addend. */
value = elf_machine_plt_value (l, reloc, value);
if (sym != NULL
&& __builtin_expect (ELFW(ST_TYPE) (sym->st_info) == STT_GNU_IFUNC, 0))
value = elf_ifunc_invoke (DL_FIXUP_VALUE_ADDR (value));
/* Finally, fix up the plt itself. */
if (__glibc_unlikely (GLRO(dl_bind_not)))
return value;
return elf_machine_fixup_plt (l, result, reloc, rel_addr, value);
这个函数开始有一段儿注释：
/* This function is called through a special trampoline from the PLT the first time each PLT entry is called. We must perform the relocation specified in the PLT of the given shared object, and return the resolved function address to the trampoline, which will restart the original call to that address. Future calls will bounce directly from the PLT to the function. */
大致解读一下：
在每个PLT入口第一次被调用时，会通过一种**trampoline机制(got表指向plt的下一条指令，push plt的index后，转向公共的plt表项)**来调用这个函数_dl_fixup。这个时候，要做的就是针对给定共享库（如libc.so）的重定位操作，并返回共享库中的真实地址，程序使用重定位后的地址并执行库中original调用。以后再调用该函数时，就会直接定位到共享库中的位置。
不管是32位还是64位都会通过这个函数实现查找和重定位操作，具体通过一些宏定义操作来区分位宽。可通过第二个参数的宏定义的相关代码看到这一点：
/* We use this macro to refer to ELF types independent of the native wordsize.
`ElfW(TYPE)' is used in place of `Elf32_TYPE' or `Elf64_TYPE'. */
#define ElfW(type) _ElfW (Elf, __ELF_NATIVE_CLASS, type)
2.2 _dl_fixup的两个参数
接下来，来看一下该函数对应的两个参数，第一个是struct link_map *l，第二个是ElfW(Word) reloc_arg。
2.2.1 参数1 link_map
第一个参数在/include/link.h
/* Structure describing a loaded shared object. The `l_next' and `l_prev'
members form a chain of all the shared objects loaded at startup.
These data structures exist in space used by the run-time dynamic linker;
modifying them may have disastrous results.
This data structure might change in future, if necessary. User-level
programs must avoid defining objects of this type. */
struct link_map
/* These first few members are part of the protocol with the debugger.
This is the same format used in SVR4. */
ElfW(Addr) l_addr; /* Difference between the address in the ELF
file and the addresses in memory. */
char *l_name; /* Absolute file name object was found in. */
ElfW(Dyn) *l_ld; /* Dynamic section of the shared object. */
struct link_map *l_next, *l_prev; /* Chain of loaded objects. */
/* All following members are internal to the dynamic linker.
They may change without notice. */
/* This is an element which is only ever different from a pointer to
the very same copy of this type for ld.so when it is used in more
than one namespace. */
struct link_map *l_real;
/* Number of the namespace this link map belongs to. */
Lmid_t l_ns;
struct libname_list *l_libname;
/* Indexed pointers to dynamic section.
[0,DT_NUM) are indexed by the processor-independent tags.
[DT_NUM,DT_NUM+DT_THISPROCNUM) are indexed by the tag minus DT_LOPROC.
[DT_NUM+DT_THISPROCNUM,DT_NUM+DT_THISPROCNUM+DT_VERSIONTAGNUM) are
indexed by DT_VERSIONTAGIDX(tagvalue).
[DT_NUM+DT_THISPROCNUM+DT_VERSIONTAGNUM,
DT_NUM+DT_THISPROCNUM+DT_VERSIONTAGNUM+DT_EXTRANUM) are indexed by
DT_EXTRATAGIDX(tagvalue).
[DT_NUM+DT_THISPROCNUM+DT_VERSIONTAGNUM+DT_EXTRANUM,
DT_NUM+DT_THISPROCNUM+DT_VERSIONTAGNUM+DT_EXTRANUM+DT_VALNUM) are
indexed by DT_VALTAGIDX(tagvalue) and
[DT_NUM+DT_THISPROCNUM+DT_VERSIONTAGNUM+DT_EXTRANUM+DT_VALNUM,
DT_NUM+DT_THISPROCNUM+DT_VERSIONTAGNUM+DT_EXTRANUM+DT_VALNUM+DT_ADDRNUM)
are indexed by DT_ADDRTAGIDX(tagvalue), see <elf.h>. */
ElfW(Dyn) *l_info[DT_NUM + DT_THISPROCNUM + DT_VERSIONTAGNUM
+ DT_EXTRANUM + DT_VALNUM + DT_ADDRNUM];
const ElfW(Phdr) *l_phdr; /* Pointer to program header table in core. */
ElfW(Addr) l_entry; /* Entry point location. */
ElfW(Half) l_phnum; /* Number of program header entries. */
ElfW(Half) l_ldnum; /* Number of dynamic segment entries. */
/* Array of DT_NEEDED dependencies and their dependencies, in
dependency order for symbol lookup (with and without
duplicates). There is no entry before the dependencies have
been loaded. */
struct r_scope_elem l_searchlist;
/* We need a special searchlist to process objects marked with
DT_SYMBOLIC. */
struct r_scope_elem l_symbolic_searchlist;
...
;
篇幅有限省略了部分代码，下面简单解读一下：
- link_map是一个用于描述可加载共享目标文件(.so)的结构，l_next和l_prev用于连接程序启动时加载的所有.so，该结构是一个双向链表，主要用于运行时动态链接器（run-time dynamic linker）。说得直白一点儿，一个link_map就对应一个.so，当加载多个.so时，可通过指针使之成为链表。
- l_info是.dynamic seciton的首地址，可通过该结构获取.dynsym节、.dynstr节、.rel.plt节等的地址，也可取得一些与动态链接相关的一些值。
2.2.2 参数2 reloc_arg
第二个参数是reloc_arg，即重定位索引，函数中使用了reloc_offset，从如下的宏定义可看出两者的值相同：
#ifndef reloc_offset
# define reloc_offset reloc_arg
# define reloc_index reloc_arg / sizeof (PLTREL)
#endif
这个值也是二进制程序中，plt节中相应plt表项push进去的一个索引值：
2.3 _dl_fixup的执行流程
_dl_fixup函数的流程图为：
从图中可知，实施查找的核心函数是_dl_lookup_symbol_x，执行该函数前是在准备所需的数据结构，这些数据结构有link_map的符号表dynsym（symtab）、字符串表dynstr（strtab）、重定位表rel.plt（reloc），以及重定位索引reloc_offset(reloc_arg)。
由于_dl_lookup_symbol_x是在这些数据结构的基础上进行的查找，因此，有必要深入分析这些数据结构和数据结构之间的关系。
3 主要数据结构及关系解析（从实例中分析）
3.1 主要数据结构
以wiki中ret2dlresolve中no-relro 32位程序（2015-xdctf-pwn200）进行分析。
使用readelf的-d选项查看.dynamic动态节区(.dynamic是动态链接可执行文件所特有的，包含了动态链接器所必须的一些信息)的内容：
giantbranch@ubuntu:~/Desktop/ret2dlresolve/2015-xdctf-pwn200/32/no-relro$ readelf -d main_no_relro_32
Dynamic section at offset 0x7c4 contains 24 entries:
Tag Type Name/Value
0x00000001 (NEEDED) Shared library: [libc.so.6]
0x0000000c (INIT) 0x804832c
0x0000000d (FINI) 0x8048634
0x00000019 (INIT_ARRAY) 0x80497bc
0x0000001b (INIT_ARRAYSZ) 4 (bytes)
0x0000001a (FINI_ARRAY) 0x80497c0
0x0000001c (FINI_ARRAYSZ) 4 (bytes)
0x6ffffef5 (GNU_HASH) 0x804818c
0x00000005 (STRTAB) 0x804824c
0x00000006 (SYMTAB) 0x80481ac
0x0000000a (STRSZ) 107 (bytes)
0x0000000b (SYMENT) 16 (bytes)
0x00000015 (DEBUG) 0x0
0x00000003 (PLTGOT) 0x80498b8
0x00000002 (PLTRELSZ) 40 (bytes)
0x00000014 (PLTREL) REL
0x00000017 (JMPREL) 0x8048304
0x00000011 (REL) 0x80482ec
0x00000012 (RELSZ) 24 (bytes)
0x00000013 (RELENT) 8 (bytes)
0x6ffffffe (VERNEED) 0x80482cc
0x6fffffff (VERNEEDNUM) 1
0x6ffffff0 (VERSYM) 0x80482b8
0x00000000 (NULL) 0x0
其中的JMPREL segment，对应于.rel.plt section，是用来保存运行时重定位表的。
ps：ELF中的section主要提供给Linker使用， 而segment提供给Loader用，Linker需要关心.text, .rel.text, .data, .rodata等等，关键是Linker需要做relocation。而Loader只需要知道Read/Write/Execute的属性。
.rel.plt与.rel.dyn类似，只不过.rel.plt是用于函数重定位，.rel.dyn是用于变量重定位。下面使用readelf的-r选项查看与重定位相关的信息：
giantbranch@ubuntu:~/Desktop/ret2dlresolve/2015-xdctf-pwn200/32/no-relro$ readelf -r main_no_relro_32
Relocation section '.rel.dyn' at offset 0x2ec contains 3 entries:
Offset Info Type Sym.Value Sym. Name
080498ac 00000306 R_386_GLOB_DAT 00000000 __gmon_start__
080498b0 00000706 R_386_GLOB_DAT 00000000 stdin@GLIBC_2.0
080498b4 00000806 R_386_GLOB_DAT 00000000 stdout@GLIBC_2.0
Relocation section '.rel.plt' at offset 0x304 contains 5 entries:
Offset Info Type Sym.Value Sym. Name
080498c4 00000107 R_386_JUMP_SLOT 00000000 setbuf@GLIBC_2.0
080498c8 00000207 R_386_JUMP_SLOT 00000000 read@GLIBC_2.0
080498cc 00000407 R_386_JUMP_SLOT 00000000 strlen@GLIBC_2.0
080498d0 00000507 R_386_JUMP_SLOT 00000000 __libc_start_main@GLIBC_2.0
080498d4 00000607 R_386_JUMP_SLOT 00000000 write@GLIBC_2.0
可以看到，.rel.plt里包含5个条目。在.dynamic section中的PLTRELSZ的值为40字节，即.rel.plt的总大小；PLTREL则指明这些条目的类型为REL；RELENT指明了每个REL类型条目的大小，8bytes。于是40/8=5即为条目个数。
从.plt section也可以看到，.plt与.rel.plt相对应：
Disassembly of section .plt:
08048350 <setbuf@plt-0x10>:
8048350: ff 35 bc 98 04 08 push DWORD PTR ds:0x80498bc
8048356: ff 25 c0 98 04 08 jmp DWORD PTR ds:0x80498c0
804835c: 00 00 add BYTE PTR [eax],al
...
08048360 <setbuf@plt>:
8048360: ff 25 c4 98 04 08 jmp DWORD PTR ds:0x80498c4
8048366: 68 00 00 00 00 push 0x0
804836b: e9 e0 ff ff ff jmp 8048350 <_init+0x24>
08048370 <read@plt>:
8048370: ff 25 c8 98 04 08 jmp DWORD PTR ds:0x80498c8
8048376: 68 08 00 00 00 push 0x8
804837b: e9 d0 ff ff ff jmp 8048350 <_init+0x24>
08048380 <strlen@plt>:
8048380: ff 25 cc 98 04 08 jmp DWORD PTR ds:0x80498cc
8048386: 68 10 00 00 00 push 0x10
804838b: e9 c0 ff ff ff jmp 8048350 <_init+0x24>
08048390 <__libc_start_main@plt>:
8048390: ff 25 d0 98 04 08 jmp DWORD PTR ds:0x80498d0
8048396: 68 18 00 00 00 push 0x18
804839b: e9 b0 ff ff ff jmp 8048350 <_init+0x24>
080483a0 <write@plt>:
80483a0: ff 25 d4 98 04 08 jmp DWORD PTR ds:0x80498d4
80483a6: 68 20 00 00 00 push 0x20
80483ab: e9 a0 ff ff ff jmp 8048350 <_init+0x24>
这些条目的类型是Elf32_Rel，其定义如下
typedef uint32_t Elf32_Addr;
typedef uint32_t Elf32_Word;
typedef struct
Elf32_Addr r_offset; /* Address */
Elf32_Word r_info; /* Relocation type and symbol index */
Elf32_Rel;
#define ELF32_R_SYM(val) ((val) >> 8) #define ELF32_R_TYPE(val) ((val) & 0xff)
我们以.rel.plt第二条，即read的条目为例，来对比调试器显示的结果。.rel.plt的首地址为0x8048304，第二条为0x8048304+8=0x804830c，gdb打印出该处的read条目：
gdb-peda$ x/2x 0x804830c
0x804830c: 0x080498c8 0x00000207
可看到，前4个字节的0x080498c8刚好是read entry的offset（Elf32_Rel结构中的r_offset）；0x00000207为Info（Elf32_Rel结构中的r_info），r_info的最后一个字节表示类型(0x07，对应R_386_JUMP_SLOT)，前三个字节为符号的索引symbol index(0x000002)，也就是第二个符号（第一个是setbuf）。
看到这里，有些人可能会提出一个疑问：readelf -r中的每个条目是8个字节，已经被前两个字段占满了，那么为什么会显示出Sym.Value和Sym. Name两项多余的信息呢？
解答：这些信息正是通过symbol index找到的，具体的，.dynamic section中的SYMTAB，即.dynsym section，保存的便是相关的符号信息。每一条symbol信息的大小在SYMENT中体现，为16 bytes。
符号表的定义为：
/* Symbol table entry. */
typedef struct
Elf32_Word st_name; /* Symbol name (string tbl index) */
Elf32_Addr st_value; /* Symbol value */
Elf32_Word st_size; /* Symbol size */
unsigned char st_info; /* Symbol type and binding */
unsigned char st_other; /* Symbol visibility */
Elf32_Section st_shndx; /* Section index */
Elf32_Sym;
可通过readelf -s来打印出这些信息：
giantbranch@ubuntu:~/Desktop/ret2dlresolve/2015-xdctf-pwn200/32/no-relro$ readelf -s main_no_relro_32
Symbol table '.dynsym' contains 10 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 00000000 0 NOTYPE LOCAL DEFAULT UND
1: 00000000 0 FUNC GLOBAL DEFAULT UND setbuf@GLIBC_2.0 (2)
2: 00000000 0 FUNC GLOBAL DEFAULT UND read@GLIBC_2.0 (2)
3: 00000000 0 NOTYPE WEAK DEFAULT UND __gmon_start__
4: 00000000 0 FUNC GLOBAL DEFAULT UND strlen@GLIBC_2.0 (2)
5: 00000000 0 FUNC GLOBAL DEFAULT UND __libc_start_main@GLIBC_2.0 (2)
6: 00000000 0 FUNC GLOBAL DEFAULT UND write@GLIBC_2.0 (2)
7: 00000000 0 OBJECT GLOBAL DEFAULT UND stdin@GLIBC_2.0 (2)
8: 00000000 0 OBJECT GLOBAL DEFAULT UND stdout@GLIBC_2.0 (2)
9: 0804864c 4 OBJECT GLOBAL DEFAULT 16 _IO_stdin_used
Symbol table '.symtab' contains 70 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 00000000 0 NOTYPE LOCAL DEFAULT UND
...
ps：
1、注意我们这里只看.dynsym，因为它是运行时所需的。诸如export/import的符号信息全在这里。而.symtab是编译时的符号信息，这部分在strip之后会被删除掉。
2、.dynsym节保存了从共享库导入的动态符号信息，该节保存在text段中，节类型被标记为SHT_DYNSYM。
可以看到，之前所说的read函数的符号信息条目index确实为2。我们通过调试器来看看其实际内容。.dynsym节的地址为0x80481ac，index值为2的地址为0x80481ac+0x10*2 = 0x80481cc。gdb打印的结果为：
gdb-peda$ x/4x 0x80481cc
0x80481d8: 0x00000012 0x0000005c 0x00000000 0x00000000
对比Elf32_Sym的定义，可以得到这些值：
st_name = 0x00000027;
st_value = 0x00000000;
st_size = 0x00000000;
st_info = 0x00;
st_other = 0x00;
st_shndx = 0x0012;
st_shndx 是定义该符号的 section 在 section header table 中的索引 (section number)，该值为0x0012，目前存疑，待解决。
st_name保存的是该符号在STRTAB，即.dynstr中的地址，STRTAB section的首地址为0x804824c，gdb中打印的结果为：
gdb-peda$ x/s 0x804824c+0x27
0x8048273: "read"
3.2 穿针引线(_dl_runtime_resolve/_dl_fixup)
在搞清楚上面一系列数据结构后，利用_dl_runtime_resolve/_dl_fixup的过程把这些内容串起来。
请读者按1-7的流程自己走一遍。
4 通过.dynamic查找特定节的地址
.dynamic的首地址可通过readelf -S查找，确定首地址后，其他各个部分的地址通过索引来查找。
link_map结构中引用.dynamic各个位置的定义的代码为：
/* Indexed pointers to dynamic section.
[0,DT_NUM) are indexed by the processor-independent tags.
[DT_NUM,DT_NUM+DT_THISPROCNUM) are indexed by the tag minus DT_LOPROC.
[DT_NUM+DT_THISPROCNUM,DT_NUM+DT_THISPROCNUM+DT_VERSIONTAGNUM) are
indexed by DT_VERSIONTAGIDX(tagvalue).
[DT_NUM+DT_THISPROCNUM+DT_VERSIONTAGNUM,
DT_NUM+DT_THISPROCNUM+DT_VERSIONTAGNUM+DT_EXTRANUM) are indexed by
DT_EXTRATAGIDX(tagvalue).
[DT_NUM+DT_THISPROCNUM+DT_VERSIONTAGNUM+DT_EXTRANUM,
DT_NUM+DT_THISPROCNUM+DT_VERSIONTAGNUM+DT_EXTRANUM+DT_VALNUM) are
indexed by DT_VALTAGIDX(tagvalue) and
[DT_NUM+DT_THISPROCNUM+DT_VERSIONTAGNUM+DT_EXTRANUM+DT_VALNUM,
DT_NUM+DT_THISPROCNUM+DT_VERSIONTAGNUM+DT_EXTRANUM+DT_VALNUM+DT_ADDRNUM)
are indexed by DT_ADDRTAGIDX(tagvalue), see <elf.h>. */
ElfW(Dyn) *l_info[DT_NUM + DT_THISPROCNUM + DT_VERSIONTAGNUM
+ DT_EXTRANUM + DT_VALNUM + DT_ADDRNUM];
l_info[0]的地址就是.dynamic的首地址，我们所关注的.dynstr，.dynsym，.rel.plt均在DT_NUM以内，数组的每个元素为如下的Elf32_Dyn结构：
typedef struct
Elf32_Sword d_tag; /* Dynamic entry type */
union
Elf32_Word d_val; /* Integer value */
Elf32_Addr d_ptr; /* Address value */
d_un;
Elf32_Dyn;
Elf32_Dyn结构占用8个字节，前四个字节为类型，后四个字节为整数值或地址。不同的section具有不同的索引：
/* Legal values for d_tag (dynamic entry type). */
#define DT_NULL 0 /* Marks end of dynamic section */
#define DT_NEEDED 1 /* Name of needed library */
#define DT_PLTRELSZ 2 /* Size in bytes of PLT relocs */
#define DT_PLTGOT 3 /* Processor defined value */
#define DT_HASH 4 /* Address of symbol hash table */
#define DT_STRTAB 5 /* Address of string table */
#define DT_SYMTAB 6 /* Address of symbol table */
#define DT_RELA 7 /* Address of Rela relocs */
#define DT_RELASZ 8 /* Total size of Rela relocs */
#define DT_RELAENT 9 /* Size of one Rela reloc */
#define DT_STRSZ 10 /* Size of string table */
#define DT_SYMENT 11 /* Size of one symbol table entry */
#define DT_INIT 12 /* Address of init function */
#define DT_FINI 13 /* Address of termination function */
#define DT_SONAME 14 /* Name of shared object */
#define DT_RPATH 15 /* Library search path (deprecated) */
#define DT_SYMBOLIC 16 /* Start symbol search here */
#define DT_REL 17 /* Address of Rel relocs */
#define DT_RELSZ 18 /* Total size of Rel relocs */
#define DT_RELENT 19 /* Size of one Rel reloc */
#define DT_PLTREL 20 /* Type of reloc in PLT */
#define DT_DEBUG 21 /* For debugging; unspecified */
#define DT_TEXTREL 22 /* Reloc might modify .text */
#define DT_JMPREL 23 /* Address of PLT relocs */
#define DT_BIND_NOW 24 /* Process relocations of object */
#define DT_INIT_ARRAY 25 /* Array with addresses of init fct */
#define DT_FINI_ARRAY 26 /* Array with addresses of fini fct */
#define DT_INIT_ARRAYSZ 27 /* Size in bytes of DT_INIT_ARRAY */
#define DT_FINI_ARRAYSZ 28 /* Size in bytes of DT_FINI_ARRAY */
#define DT_RUNPATH 29 /* Library search path */
#define DT_FLAGS 30 /* Flags for the object being loaded */
#define DT_ENCODING 32 /* Start of encoded range */
#define DT_PREINIT_ARRAY 32 /* Array with addresses of preinit fct*/
#define DT_PREINIT_ARRAYSZ 33 /* size in bytes of DT_PREINIT_ARRAY */
#define DT_NUM 34 /* Number used */
...
以查找.dynstr section地址保存在.dynamic段的位置为例，若.dynamic的首地址为a，由于.dynstr的索引为5，因此.dynstr的地址保存在.dynamic段的位置为a+5*8+4=a+0x2c。
以上是关于[ctf wiki pwn] stackoverflow：ret2dlresolve系列2（_dl_runtime_resolve glibc源码解析实践）的主要内容，如果未能解决你的问题，请参考以下文章
[ctf wiki pwn] stackoverflow：hctf2016-brop wp
[ctf wiki pwn] stackoverflow：hctf2016-brop wp
[CTF Wiki Pwn]Stackoverflow Lab002: ret2shellcode
[CTF Wiki Pwn]Stackoverflow Lab003: ret2syscall