第八章 Android 原生程序开发与逆向分析（三）（原生程序文件格式）（字符串表、符号表、got 表、plt 表、地址重定位表）_定位到.shstrtab

字符串表

• 观察 ELF 文件格式，会发现其中包含 .dynstr、.shstrtab、.strtab 三张字符串表
• .dynstr 表位于 .dynstr 节区（dynstr 即 Dynamic String 的缩写），存放的是 .dynamic 节区使用的字符串，如 DT_NEEDED 类型的依赖库的名称字符串和 DT_SONAME 类型的动态库名称字符串
• .shstrtab 表位于 .shstrtab 节区（shstrtab 即 Section Header String Table 的缩写），它是节区头信息字符串表，存放的是 Section Header Table 结构体使用的字符串信息，典型的有 Section 的名称索引字段 sh_name，所有 Section 的节区名称字符串都存放在 .shstrtab 表中
• .strtab 位于 .strtab 节区（strtab 即 String Table 的缩写），它是字符串表，存放的是 ELF 中引用的字符串信息，如 ELF 中导出的函数名、编译器添加的调试符号名称和源代码文件名等
• 用 aarch64-linux-android-readelf 可查看 ELF 中字符串表信息。先执行 $READELF -t 列出所有 Section，找到字符串表的索引，然后执行 $READELF -p，传入索引参数，即可输出其字符串信息：
  
• 用 $READELF 也可定位某个字符串索引代表的字符串值。如，知道 Elf64_Shdr 结构体中的 sh_name 字段的值为 0x37，可执行如下命令查看其对应的字符串：
  
• 由输出可知，0x37 对应的 Section 为 .gnu.hash

符号表

• 共享的目标文件与原生可执行文件通常都包含 .symtab 和 .dynsym 两张符号表
• .symtab 表位于 .symtab 节区，.dynsym 表位于 .dynsym 节区
• dynsym 表相当于 .symtab 表的简化版，在前者中存在的符号，必定存在于后者中，既如此，何须两张表呢？
• 先要了解 ELF 中的可分配内存与不可分配内存的 Section 间的区别。Section Header Table 中的 Section，有些虽是供链接器、调试器或其他工具用的，但它们并不是 ELF 运行时必需的，这些 Section 将被设置为不可分配内存；另一些 Section，如 .text、.data，它们是 ELF 运行时必需的，编译器会为这类 Section 的 Elf64_Shdr 结构体的 sh_flags 字段添加 SHF_ALLOC 标志位，将其设置为可分配内存，链接器在链接 ELF 时就会将其加载到内存（没设置 SHF_ALLOC 的 Section 则不会，它在内存中将不可访问）
• 观察 .symtab 节区的 Elf64_Shdr 结构体的 sh_flags 字段，会发现它没设置 SHF_ALLOC，.dynsym 节区则设置了，这表明链接器在链接 ELF 时只会使用 .dynsym 节区，不会使用 .symtab 节区
• 这就是需要两张表的原因：.symtab 节区保存了 ELF 中所有的符号信息，但这张符号表中的很多符号并非 ELF 运行时必需，若将其全部加载到内存，会造成内存浪费，因此，ELF 在编译程序的链接阶段会将 .symtab 符号表中运行时要用的符号复制一份放到 .dynsym 节区中，以后运行时只使用 .dynsym 节区即可
• 既然 .symtab 节区对 ELF 运行非必需，就可用 ELF 优化工具 aarch64-linux-android-stri