Libtree: ldd yang menjelaskan penemuan library dalam bentuk pohon

 (github.com/haampie)
3 poin oleh GN⁺ 2024-06-10 | 2 komentar | Bagikan ke WhatsApp
  • libtree adalah alat yang mengubah output ldd menjadi bentuk pohon, sekaligus menjelaskan bagaimana shared library ditemukan atau mengapa tidak dapat ditemukan
  • Pada output default, sebagian dependensi standar disembunyikan; dengan -v, -vv, -vvv, Anda bisa melihat secara bertahap library yang disembunyikan hingga dependensi dari library yang sudah pernah ditemui
  • --path atau -p menampilkan path alih-alih soname, dan --max-depth dapat membatasi kedalaman penelusuran rekursif
  • Instalasi tersedia melalui binary prebuilt v3.1.1, Fedora/RHEL/CentOS, Ubuntu 22.04+, dan GNU Guix
  • Untuk build dari source diperlukan compiler C yang memahami C99, dan saat menggunakan make disarankan memakai LDFLAGS=-static

Apa yang dilakukan libtree

  • libtree adalah alat yang mengubah ldd menjadi bentuk pohon
  • Menjelaskan bagaimana shared library ditemukan, atau mengapa lokasinya tidak dapat ditemukan
  • README menyertakan screenshot doc/screenshot.png

Opsi output

  • Pada output default, sebagian dependensi standar tidak ditampilkan
  • Output yang lebih detail dikendalikan dengan opsi verbosity
    • libtree -v: menampilkan library yang secara default dilewati
    • libtree -vv: juga menampilkan dependensi dari library yang secara default dilewati
    • libtree -vvv: juga menampilkan dependensi dari library yang sudah pernah ditemui
  • Flag --path atau -p menampilkan path alih-alih soname
    • Contoh: libtree -p $(which tar)
  • --max-depth membatasi kedalaman rekursi

Cara instalasi

Build dari source

  • libtree memerlukan compiler C yang memahami C99
  • Prosedur build dasar adalah meng-clone repository lalu menjalankan make
  • Saat menggunakan make, disarankan memakai LDFLAGS=-static
  • README juga menyediakan perintah unsafe quick install untuk mengambil libtree.c dengan curl lalu mengompilasinya, dalam bagian terpisah yang dapat dilipat

Bacaan terkait

2 komentar

 
GN⁺ 2024-06-10
Pendapat Hacker News

  • Apakah alat ini juga mengikuti perilaku tak terduga ldd, yaitu benar-benar mengeksekusi sebagian library yang sedang diperiksa?
    https://catonmat.net/ldd-arbitrary-code-execution

    • Belakangan ini, kira-kira versi ldd yang sudah lebih dari 5 tahun tidak mengeksekusi binary target
      Referensi: https://manpages.debian.org/unstable/manpages/ldd.1.en.html#...
    • Setelah sekilas meninjau kodenya di ponsel, sepertinya tidak begitu
      Tampaknya ia sebenarnya mem-parse file ELF secara langsung, dan juga mem-parse dependensi secara rekursif, jadi cukup keren
    • Saya pernah membuat sesuatu yang samar-samar mirip untuk Python, tetapi akhirnya tidak bisa menghindari masalah ini https://github.com/google/importlab/issues/69
    • Jika memakai objdump, data akan ditampilkan apa adanya seperti yang dienkode dalam file ELF
      Termasuk juga daftar library yang akan dicari oleh vdso

  • Ada alat serupa bernama lddtree
    https://github.com/gentoo/pax-utils/tree/master

  • Harus menelusuri dependensi yang hilang secara rekursif berulang-ulang dengan ldd itu cukup membosankan
    Jadi ini terlihat seperti peningkatan yang bagus, dan lain kali saya menemui not found yang membingungkan, saya berniat mencobanya

  • Pada dasarnya seperti depends.exe versi Linux CLI

    • Tool tertentu itu sudah tidak lagi bekerja dengan baik di versi Windows modern
      Sebaiknya pakai https://github.com/lucasg/Dependencies sebagai gantinya. Itu juga tidak sepenuhnya mutakhir, tapi…
      Jika Anda memasang Visual Studio dan memilih x64/x86 build tools (latest) di installer, menjalankan dumpbin /dependents dari VS Developer Command Prompt masih menjadi opsi paling dapat diandalkan
    • Benar, itu juga yang langsung terpikir oleh saya
      [1] https://www.dependencywalker.com/

  • Untuk yang penasaran arti warnanya, saya tidak menemukannya di manpage/README
    Magenta: ada di daftar pengecualian, hanya ditampilkan dengan -v[v[v]]
    Biru: item yang sudah pernah dilihat sebelumnya, sehingga Anda bisa menemukan dependensi yang muncul berkali-kali

  • Apa maksudnya “alasan library ditemukan atau tidak ditemukan”? Bukankah cuma dua kemungkinan: ada di LD_LIBRARY_PATH atau tidak?
    Dari screenshot saja saya tidak begitu paham apa yang dimaksud

    • Saya tidak tahu persis dalam konteks alat ini, tetapi pencarian library jauh lebih kompleks daripada satu environment variable
      Ada beberapa cara berbeda untuk mencari direktori, seperti jalur pencarian sistem, runpath, rpath, LD_LIBRARY_PATH, dan lain-lain
      Library biasanya di-link dengan nama pendek seperti foo.so, tetapi juga bisa di-link secara dinamis dengan path lengkap library tersebut
      Selain itu, secara umum lebih baik menghindari pengaturan LD_LIBRARY_PATH jika memungkinkan. Memang tidak selalu bisa, tetapi ketika disetel, ia naik ke prioritas pencarian paling atas untuk semua eksekusi. Bahkan jika sesuatu di-link secara dinamis dengan path lengkap library, LD_LIBRARY_PATH tetap diprioritaskan, dan membuat mekanisme pencarian menjadi benar-benar datar
    • Library tidak harus berada di dalam LD_LIBRARY_PATH agar bisa ditemukan
      Inti judulnya adalah libtree memudahkan menemukan jalur dari executable ke semua dependensi langsung maupun tidak langsungnya. Salah satu kegunaannya adalah membantu mengidentifikasi masalah dependensi yang hilang
      Dalam praktiknya, kalau Anda memakai sistem paket, dependensi biasanya jarang hilang, jadi kemungkinan Anda akan memakai libtree untuk alasan lain
    • Bukan cuma ada atau tidak ada di LD_LIBRARY_PATH; ada juga RPATH yang dievaluasi saat pemuatan untuk masing-masing library
      Poin yang lebih besar adalah dependensi membentuk graf, dan ini bisa ditampilkan seperti pohon. Mengetahui library mana yang membutuhkan suatu library sehingga library tertentu tidak ditemukan itu berguna
    • Library tidak hanya dicari lewat LD_LIBRARY_PATH. Loader juga mempertimbangkan beberapa sumber lain untuk menemukan library
      Dalam konfigurasi yang normal, ini merupakan kombinasi antara field ELF umum dari tiap binary yang dimuat dan jalur lain yang diketahui loader
      Pada sistem yang memiliki beberapa versi dari library yang sama atau beberapa library bernama sama, bergantung pada LD_LIBRARY_PATH bisa sangat picik. Loader akan mencari jalur di LD_LIBRARY_PATH secara berurutan untuk setiap binary, lalu memilih library pertama yang cocok. Jika Anda belum mengatur jalur berprioritas lebih tinggi dengan cara lain, library itu mungkin bukan yang sebenarnya Anda inginkan, dan bisa menyebabkan error tak terduga saat runtime
      Cara yang lebih baik adalah mengatur RPATH ke lokasi library yang dibutuhkan binary tersebut
      Jika environment dan pengaturan RPATH tidak konsisten, Anda juga bisa memuat beberapa versi dari library yang sama secara bersamaan. Alat ini membantu mengetahui apakah ada masalah dan mengapa itu terjadi
    • Setidaknya ada RPATH, RUNPATH, dan LD_LIBRARY_PATH
      Karena alat ini berbasis ldd, mungkin ia juga menafsirkan DYLD_LIBRARY_PATH, DYLD_FALLBACK_FRAMEWORK_PATH, DYLD_FALLBACK_LIBRARY_PATH, @executable_path, @loader_path, dan @rpath

  • Sangat berguna. Biasanya saya membaca section dengan readelf untuk mencari tahu apa kebutuhan sebenarnya

  • Apakah LD_DEBUG=libs tidak cukup?

    • Itu adalah flag debug loader, bukan evaluasi statis terhadap dependensi library, jadi tidak sepenuhnya sama

  • Saya tidak tahu apakah ini bug, tetapi pada contoh vim, ldd dan libtree menampilkan library yang berbeda
    Misalnya linux-vdso.so.1 muncul di bagian paling atas daftar ldd, tetapi sama sekali tidak muncul di libtree

    • linux-vdso.so.1 bukan library nyata yang bisa ditemukan di suatu tempat dalam filesystem dan juga tidak dirujuk di dalam file ELF, jadi libtree tidak bisa mengetahuinya
      Sebagai gantinya, kernel secara otomatis memetakannya ke ruang alamat proses yang baru dimulai. Ini adalah optimisasi untuk menghindari overhead system call pada fungsi seperti gettimeofday. Referensi: https://man7.org/linux/man-pages/man7/vdso.7.html

  • Saya pernah membuat skrip kecil yang berantakan untuk menjalankan ldd secara rekursif demi mencari tahu apa saja yang harus disertakan agar bisa menjalankan binary closed-source di NixOS
    Kalau harus melakukan hal seperti itu lagi, saya akan mencoba alat ini
 
kayws426 2024-06-11

Kelihatannya bagus!!