主页 / unix / 问题 / 669237
Accepted
jdkleuver
Asked: 2021-09-16 21:50:58 +0800 CST

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

  • 772

我试图通过读取程序头来定位 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

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

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

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

elf

1 个回答

  1. Best Answer

    我想我想通了，你需要检查所有的 PT_LOAD 段并找到 p_vaddr 最低的段（我称之为lowest_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 值不匹配。

    • 1

相关问题