☰

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で何が起こっているのかは、lower_pt_loadがlibcベースアドレスと同じであるため、互いにキャンセルすることです。

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

ベースアドレス

実行可能ファイルと共有オブジェクトファイルには、プログラムオブジェクトファイルのメモリイメージに関連付けられている最も低い仮想アドレスであるベースアドレスがあります。ベースアドレスの用途の1つは、ダイナミック接続中にプログラムのメモリイメージを再配置することです。

実行可能ファイルまたは共有オブジェクトファイルのベースアドレスは、実行中のメモリロードアドレス、最大ページサイズ、プログラムロード可能セグメントの最も低い仮想アドレスなど、3つの値から計算されます。プログラムヘッダの仮想アドレスは、プログラムメモリイメージの実際の仮想アドレスを表さなくてもよい。 「プログラムのロード（プロセッサ別）」を参照してください。

ベースアドレスを計算するには、PT_LOADセグメントの最も低いp_vaddr値に関連するメモリアドレスを決定する必要があります。次に、メモリアドレスを最大ページサイズの最も近い倍数に切り捨てて、ベースアドレスを得る。メモリにロードされるファイルの種類によっては、メモリアドレスがp_vaddr値と一致しない場合があります。

おすすめ記事