ตรวจสอบการอ้างอิงวัตถุที่ใช้ร่วมกันโดยตรงของไบนารี Linux?


170

ฉันจะค้นหาการพึ่งพาวัตถุที่ใช้ร่วมกันโดยตรงของไบนารี Linux ในรูปแบบ ELF ได้อย่างไร

ฉันรู้เครื่องมือ ldd แต่ดูเหมือนว่าจะส่งออกการอ้างอิงทั้งหมดของไบนารีรวมถึงการพึ่งพาของวัตถุที่ใช้ร่วมกันใด ๆ ที่ไบนารีขึ้นอยู่กับ


คำตอบ:


262

คุณสามารถใช้readelfเพื่อสำรวจส่วนหัวของ ELF readelf -dจะแสดงรายการการพึ่งพาโดยตรงเป็นNEEDEDส่วนต่างๆ

 $ readelf -d elfbin

Dynamic section at offset 0xe30 contains 22 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libssl.so.1.0.0]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000000c (INIT)               0x400520
 0x000000000000000d (FINI)               0x400758
 ...

20
มันเยี่ยมมาก ซึ่งแตกต่างจาก ldd ผู้อ่านสามารถตรวจสอบไบนารีข้ามแพลตฟอร์ม (เช่นตรวจสอบ ARM ที่ปฏิบัติการได้จาก x86-64 linux)
Robert Calhoun

86

หากคุณต้องการค้นหาการพึ่งพาซ้ำ ๆ (รวมถึงการพึ่งพาการพึ่งพาการพึ่งพาของการพึ่งพาและอื่น ๆ ) ...

คุณอาจใช้lddคำสั่ง ldd - พิมพ์พึ่งพาห้องสมุดที่ใช้ร่วมกัน


5
คำสั่ง ldd ทำงานจากการขึ้นต่อกันของการพึ่งพาซึ่งไม่ใช่สิ่งที่ฉันต้องการ
ฟรี Wildebeest

11
สำหรับฉันมันใช้งานได้ดี และมันยังบอกคุณว่ามีห้องสมุดใดบ้างที่ไม่สามารถพบได้
ฟิลิปป์ F

2
ldd จะไม่ทำงานกับแฟ้มที่ปฏิบัติการได้ - สำหรับการค้นหาการพึ่งพาของไลบรารีที่ใช้ร่วมกันเท่านั้นซึ่งเป็นประโยชน์
Tuxdude

2
Tuxdude ทำไมคุณคิดอย่างนั้น อะไรคือสาเหตุของความไม่สามารถใช้งานของ ldd สำหรับ ELF executables ได้?
Vitaly Isaev

สิ่งนี้ยอดเยี่ยมสำหรับ copiyng ที่ต้องการ libs ที่ใช้ร่วมกันจากเครื่องพัฒนาจนถึงการปรับใช้การเก็บถาวร
Tomáš Zato - Reinstate Monica

30

objdumpเครื่องมือที่สามารถบอกคุณได้ข้อมูลเหล่านี้ หากคุณวิงวอนobjdumpด้วย-xตัวเลือกเพื่อให้ได้ส่วนหัวทั้งหมดแล้วคุณจะพบการพึ่งพาวัตถุที่ใช้ร่วมกันได้ทันทีที่จุดเริ่มต้นใน "ส่วนแบบไดนามิก"

ตัวอย่างเช่นทำงานobjdump -x /usr/lib/libXpm.so.4บนระบบของฉันให้ข้อมูลต่อไปนี้ใน "ส่วนไดนามิก":

Dynamic Section:
  NEEDED               libX11.so.6
  NEEDED               libc.so.6
  SONAME               libXpm.so.4
  INIT                 0x0000000000002450
  FINI                 0x000000000000e0e8
  GNU_HASH             0x00000000000001f0
  STRTAB               0x00000000000011a8
  SYMTAB               0x0000000000000470
  STRSZ                0x0000000000000813
  SYMENT               0x0000000000000018
  PLTGOT               0x000000000020ffe8
  PLTRELSZ             0x00000000000005e8
  PLTREL               0x0000000000000007
  JMPREL               0x0000000000001e68
  RELA                 0x0000000000001b38
  RELASZ               0x0000000000000330
  RELAENT              0x0000000000000018
  VERNEED              0x0000000000001ad8
  VERNEEDNUM           0x0000000000000001
  VERSYM               0x00000000000019bc
  RELACOUNT            0x000000000000001b

การขึ้นต่อกันของวัตถุที่แชร์โดยตรงนั้นแสดงรายการเป็นค่า 'NEEDED' ดังนั้นในตัวอย่างข้างต้นlibXpm.so.4ในระบบของฉันเพียงแค่ต้องการlibX11.so.6และlibc.so.6และ

เป็นเรื่องสำคัญที่จะต้องทราบว่าสิ่งนี้ไม่ได้หมายความว่าสัญลักษณ์ทั้งหมดที่ต้องการโดยไบนารีจะถูกส่งไปยังobjdumpจะปรากฏในไลบรารี แต่อย่างน้อยก็แสดงให้เห็นว่าห้องสมุดใดที่ตัวโหลดจะพยายามโหลดเมื่อโหลดไบนารี


13

ldd -v พิมพ์แผนภูมิการพึ่งพาภายใต้ส่วน "ข้อมูลเวอร์ชัน: 'บล็อกแรกในส่วนนั้นเป็นการอ้างอิงโดยตรงของไบนารี

ดูลำดับชั้น ldd (1)


ความแตกต่างระหว่างสิ่งนี้กับobjdump -x <binary> | grep "NEEDED"อะไร? ผมหมายถึงทั้งสองเกือบจะตรงเดียวกันฉันแค่ได้รับหนึ่ง.soไฟล์มากขึ้นด้วยกว่าldd objdumpแต่ความจริงแล้วผลลัพธ์ไม่เหมือนกันทำให้ฉันสงสัยว่าวิธีใดมีความแม่นยำมากกว่า
m4l490n
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.