☰

如何判断ELF程序头中的p_vaddr是真实内存地址还是只是相对于共享库基地址的偏移量？

tag-icon • tag-icon elf
如何判断ELF程序头中的p_vaddr是真实内存地址还是只是相对于共享库基地址的偏移量？

我试图通过读取程序头来定位 libc 程序段在程序内存中的位置。

在 Centos 6 上，当我对 libc.so.6 文件使用 readelf 时，VirtAddr 包含在进程内存中加载程序段的正确地址：

[user@centos6 src]$ readelf -l /lib64/libc.so.6 --wide

Elf file type is DYN (Shared object file)
Entry point 0x3032c1ee30
There are 10 program headers, starting at offset 64

Program Headers:
  Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
  PHDR           0x000040 0x0000003032c00040 0x0000003032c00040 0x000230 0x000230 R E 0x8
  INTERP         0x15aab0 0x0000003032d5aab0 0x0000003032d5aab0 0x00001c 0x00001c R   0x10
      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
  LOAD           0x000000 0x0000003032c00000 0x0000003032c00000 0x18a00c 0x18a00c R E 0x200000
  LOAD           0x18a700 0x0000003032f8a700 0x0000003032f8a700 0x004f58 0x009228 RW  0x200000
  DYNAMIC        0x18db40 0x0000003032f8db40 0x0000003032f8db40 0x0001f0 0x0001f0 RW  0x8
  NOTE           0x000270 0x0000003032c00270 0x0000003032c00270 0x000044 0x000044 R   0x4
  TLS            0x18a700 0x0000003032f8a700 0x0000003032f8a700 0x000010 0x000068 R   0x8
  GNU_EH_FRAME   0x15aacc 0x0000003032d5aacc 0x0000003032d5aacc 0x0065ec 0x0065ec R   0x4
  GNU_STACK      0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW  0x8
  GNU_RELRO      0x18a700 0x0000003032f8a700 0x0000003032f8a700 0x003900 0x003900 R   0x1

因此在本例中，DYNAMIC 段位于 0x0000003032f8db40

但在 Centos 7 上，VirtAddr 包含一个偏移量，我必须将 libc 基地址添加到该偏移量中才能找到该段在内存中的位置：

[user@centos7 src]$ readelf -l /usr/lib64/libc.so.6 --wide

Elf file type is DYN (Shared object file)
Entry point 0x22660
There are 10 program headers, starting at offset 64

Program Headers:
  Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
  PHDR           0x000040 0x0000000000000040 0x0000000000000040 0x000230 0x000230 R E 0x8
  INTERP         0x18eb00 0x000000000018eb00 0x000000000018eb00 0x00001c 0x00001c R   0x10
      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
  LOAD           0x000000 0x0000000000000000 0x0000000000000000 0x1c3170 0x1c3170 R E 0x200000
  LOAD           0x1c36f0 0x00000000003c36f0 0x00000000003c36f0 0x0051b0 0x009b10 RW  0x200000
  DYNAMIC        0x1c6b60 0x00000000003c6b60 0x00000000003c6b60 0x0001f0 0x0001f0 RW  0x8
  NOTE           0x000270 0x0000000000000270 0x0000000000000270 0x000044 0x000044 R   0x4
  TLS            0x1c36f0 0x00000000003c36f0 0x00000000003c36f0 0x000010 0x0000a0 R   0x10
  GNU_EH_FRAME   0x18eb1c 0x000000000018eb1c 0x000000000018eb1c 0x006aec 0x006aec R   0x4
  GNU_STACK      0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW  0x10
  GNU_RELRO      0x1c36f0 0x00000000003c36f0 0x00000000003c36f0 0x003910 0x003910 R   0x1

在这种情况下，动态段将位于 0x00000000003c6b60 + libc 基地址。

我猜测这可能是由于 Centos 7 上的 ASLR 导致 libc 库每次加载到不同的地址。在 Centos 6 上，libc 似乎总是加载到相同的地址。

有没有办法仅通过读取ELF头来确定我是否需要将libc基地址添加到VirtAddr中以获取程序段在内存中的实际位置？

答案1

我想我已经明白了，您需要检查所有 PT_LOAD 段并找到 p_vaddr 最低的段（我将其称为 lower_pt_load）。

然后计算出内存位置：libc_base + segment.p_addr - lowest_pt_load.p_vaddr

Centos 6 中发生的情况是，lowest_pt_load 等于 libc 基地址，导致它们相互抵消。

来源：https://docs.oracle.com/cd/E19683-01/816-1386/6m7qcoblk/index.html#chapter6-83432

基地址

可执行文件和共享目标文件具有基地址，它是与程序目标文件的内存映像关联的最低虚拟地址。基地址的一种用途是在动态链接期间重新定位程序的内存映像。

可执行文件或共享对象文件的基地址是在执行期间根据三个值计算得出的：内存加载地址、最大页面大小以及程序可加载段的最低虚拟地址。程序头中的虚拟地址可能不代表程序内存映像的实际虚拟地址。请参阅“程序加载（特定于处理器）”。

要计算基地址，您需要确定与 PT_LOAD 段的最低 p_vaddr 值关联的内存地址。然后，通过将内存地址截断为最接近的最大页面大小的倍数来获取基地址。根据加载到内存中的文件类型，内存地址可能与 p_vaddr 值不匹配。

相关内容