Chcę znaleźć listę bibliotek dynamicznych ładowanych binarnie po uruchomieniu (wraz z ich pełnymi ścieżkami). Używam CentOS 6.0. Jak to zrobić?
Chcę znaleźć listę bibliotek dynamicznych ładowanych binarnie po uruchomieniu (wraz z ich pełnymi ścieżkami). Używam CentOS 6.0. Jak to zrobić?
Odpowiedzi:
Możesz to zrobić za pomocą ldd
polecenia:
NAME
ldd - print shared library dependencies
SYNOPSIS
ldd [OPTION]... FILE...
DESCRIPTION
ldd prints the shared libraries required by each program or shared
library specified on the command line.
....
Przykład:
$ ldd /bin/ls
linux-vdso.so.1 => (0x00007fff87ffe000)
libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007ff0510c1000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007ff050eb9000)
libacl.so.1 => /lib/x86_64-linux-gnu/libacl.so.1 (0x00007ff050cb0000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff0508f0000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ff0506ec000)
/lib64/ld-linux-x86-64.so.2 (0x00007ff0512f7000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ff0504ce000)
libattr.so.1 => /lib/x86_64-linux-gnu/libattr.so.1 (0x00007ff0502c9000)
otool -L <path-to-binary>
ldd
. Zobacz stronę podręcznika man .
readelf -d $executable | grep 'NEEDED'
Można go użyć, jeśli nie można uruchomić pliku wykonywalnego, np. Jeśli został on skompilowany krzyżowo lub jeśli mu nie ufasz:
W zwykłym przypadku ldd wywołuje standardowy dynamiczny linker (patrz ld.so (8)) ze zmienną środowiskową LD_TRACE_LOADED_OBJECTS ustawioną na 1, co powoduje, że linker wyświetla zależności bibliotek. Należy jednak pamiętać, że w niektórych okolicznościach niektóre wersje ldd mogą próbować uzyskać informacje o zależnościach przez bezpośrednie uruchomienie programu. Dlatego nigdy nie powinieneś używać ldd na niezaufanym pliku wykonywalnym, ponieważ może to spowodować wykonanie dowolnego kodu.
Przykład:
readelf -d /bin/ls | grep 'NEEDED'
Przykładowy ouptut:
0x0000000000000001 (NEEDED) Shared library: [libselinux.so.1]
0x0000000000000001 (NEEDED) Shared library: [libacl.so.1]
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
Zauważ, że biblioteki mogą zależeć od innych bibliotek, więc teraz musisz znaleźć zależności.
Naiwne podejście, które często się sprawdza, to:
$ locate libselinux.so.1
/lib/i386-linux-gnu/libselinux.so.1
/lib/x86_64-linux-gnu/libselinux.so.1
/mnt/debootstrap/lib/x86_64-linux-gnu/libselinux.so.1
ale dokładniejszą metodą jest zrozumienie ldd
ścieżki wyszukiwania / pamięci podręcznej. Myślę, że ldconfig
to dobra droga.
Wybierz jeden i powtórz:
readelf -d /lib/x86_64-linux-gnu/libselinux.so.1 | grep 'NEEDED'
Przykładowe dane wyjściowe:
0x0000000000000001 (NEEDED) Shared library: [libpcre.so.3]
0x0000000000000001 (NEEDED) Shared library: [libdl.so.2]
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
0x0000000000000001 (NEEDED) Shared library: [ld-linux-x86-64.so.2]
I tak dalej.
Zobacz też:
/proc/<pid>/maps
do uruchamiania procesów
Wspomniany przez Basile jest przydatny, aby znaleźć wszystkie biblioteki aktualnie używane przez uruchamiane pliki wykonywalne. Na przykład:
sudo awk '/\.so/{print $6}' /proc/1/maps | sort -u
pokazuje wszystkie aktualnie załadowane zależności dynamiczne init
(PID 1
):
/lib/x86_64-linux-gnu/ld-2.23.so
/lib/x86_64-linux-gnu/libapparmor.so.1.4.0
/lib/x86_64-linux-gnu/libaudit.so.1.0.0
/lib/x86_64-linux-gnu/libblkid.so.1.1.0
/lib/x86_64-linux-gnu/libc-2.23.so
/lib/x86_64-linux-gnu/libcap.so.2.24
/lib/x86_64-linux-gnu/libdl-2.23.so
/lib/x86_64-linux-gnu/libkmod.so.2.3.0
/lib/x86_64-linux-gnu/libmount.so.1.1.0
/lib/x86_64-linux-gnu/libpam.so.0.83.1
/lib/x86_64-linux-gnu/libpcre.so.3.13.2
/lib/x86_64-linux-gnu/libpthread-2.23.so
/lib/x86_64-linux-gnu/librt-2.23.so
/lib/x86_64-linux-gnu/libseccomp.so.2.2.3
/lib/x86_64-linux-gnu/libselinux.so.1
/lib/x86_64-linux-gnu/libuuid.so.1.3.0
Ta metoda pokazuje również biblioteki otwarte przy użyciu dlopen
, przetestowane przy użyciu tej minimalnej konfiguracji zhakowanej za pomocą sleep(1000)
Ubuntu 18.04.
Zobacz także: Jak wyświetlić aktualnie załadowane współdzielone obiekty w systemie Linux? | Super użytkownik
ldd i lsof pokazują biblioteki załadowane bezpośrednio lub w danym momencie . Nie uwzględniają bibliotek załadowanych przez dlopen
(lub odrzuconych przezdlclose
). Możesz uzyskać lepszy obraz tego, używając strace
np.
strace -e trace=open myprogram
(ponieważ dlopen
ostatecznie dzwoni open
- chociaż możesz oczywiście mieć system używający różnych nazw dla 64-bitowych otwarć ...).
Przykład:
strace -e trace=open date
pokazuje mi to:
open("/etc/ld.so.cache", O_RDONLY) = 3
open("/lib/x86_64-linux-gnu/librt.so.1", O_RDONLY) = 3
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY) = 3
open("/lib/x86_64-linux-gnu/libpthread.so.0", O_RDONLY) = 3
open("/usr/lib/locale/locale-archive", O_RDONLY) = 3
open("/etc/localtime", O_RDONLY) = 3
Wed Apr 12 04:56:32 EDT 2017
z którego można wstawić nazwy „.so”, aby zobaczyć udostępnione obiekty.
strace -e trace=open,openat myprogram
/proc/<pid>/maps
pokazuje również dlopen
libs btw: unix.stackexchange.com/questions/120015/... ltrace -S
wyjście jest jeszcze fajniejsze, ponieważ pokazuje zarówno wywołania systemowe, jak i wywołania biblioteki, takie jak dlopen
: unix.stackexchange.com/questions/226524/…
lsof może również pokazać, które biblioteki są używane dla jednego konkretnego procesu.
to znaczy
$ pidof nginx
6920 6919
$ lsof -p 6919|grep mem
nginx 6919 root mem REG 0,64 65960 43 /lib64/libnss_files-2.12.so
nginx 6919 root mem REG 0,64 19536 36 /lib64/libdl-2.12.so
nginx 6919 root mem REG 0,64 10312 1875 /lib64/libfreebl3.so
nginx 6919 root mem REG 0,64 1923352 38 /lib64/libc-2.12.so
nginx 6919 root mem REG 0,64 88600 1034 /lib64/libz.so.1.2.3
nginx 6919 root mem REG 0,64 1967392 1927 /usr/lib64/libcrypto.so.1.0.1e
nginx 6919 root mem REG 0,64 183080 1898 /lib64/libpcre.so.0.0.1
nginx 6919 root mem REG 0,64 40400 1217 /lib64/libcrypt-2.12.so
nginx 6919 root mem REG 0,64 142688 77 /lib64/libpthread-2.12.so
nginx 6919 root mem REG 0,64 154664 31 /lib64/ld-2.12.so
W przypadku procesu pid 1234 można również odczytać /proc/1234/maps
pseudoplik (tekstowy) (odczyt proc (5) ...) lub użyć pmap (1)
Daje to wirtualną przestrzeń adresową tego procesu, stąd pliki (w tym biblioteki współdzielone, nawet nawet dlopen (3) -ed), które są mapowane w pamięci
(oczywiście użyj ps aux
lub pgrep (1), aby znaleźć procesy uruchamiające dany program)
utwórz mały skrypt ( useslib
) i umieść w zmiennej PATH (lub określ pełną ścieżkę w poniższym poleceniu)
#! /bin/bash
ldd $1 | grep -q $2
exit $?
Użyj go w find
poleceniu, na przykład:
find /usr/bin/ -executable -type f -exec useslib {} libgtk-x11-2.0 \; -print
(libgtk-x11-2.0 wydaje się być biblioteką gtk2)
Możliwe jest użycie pmap
.
Na przykład rozpocznij proces: $ watch date
Uzyskaj pid: $ ps -ef | grep watch
Pokaż mapę pamięci: $ pmap <pid>
Pokaż z pełną ścieżką: $ pmap <pid> -p
$ pmap 72770
72770: watch date
00005613a32c9000 20K r-x-- watch
00005613a34cd000 4K r---- watch
00005613a34ce000 4K rw--- watch
00005613a4f6a000 264K rw--- [ anon ]
00007f2f3a7d5000 204616K r---- locale-archive
00007f2f46fa7000 1748K r-x-- libc-2.27.so
00007f2f4715c000 2048K ----- libc-2.27.so
00007f2f4735c000 16K r---- libc-2.27.so
00007f2f47360000 8K rw--- libc-2.27.so
00007f2f47362000 16K rw--- [ anon ]
00007f2f47366000 12K r-x-- libdl-2.27.so
00007f2f47369000 2044K ----- libdl-2.27.so
00007f2f47568000 4K r---- libdl-2.27.so
00007f2f47569000 4K rw--- libdl-2.27.so
00007f2f4756a000 160K r-x-- libtinfo.so.6.1
00007f2f47592000 2048K ----- libtinfo.so.6.1
00007f2f47792000 16K r---- libtinfo.so.6.1
00007f2f47796000 4K rw--- libtinfo.so.6.1
00007f2f47797000 232K r-x-- libncursesw.so.6.1
00007f2f477d1000 2048K ----- libncursesw.so.6.1
00007f2f479d1000 4K r---- libncursesw.so.6.1
00007f2f479d2000 4K rw--- libncursesw.so.6.1
00007f2f479d3000 148K r-x-- ld-2.27.so
00007f2f47bdb000 20K rw--- [ anon ]
00007f2f47bf1000 28K r--s- gconv-modules.cache
00007f2f47bf8000 4K r---- ld-2.27.so
00007f2f47bf9000 4K rw--- ld-2.27.so
00007f2f47bfa000 4K rw--- [ anon ]
00007ffd39404000 136K rw--- [ stack ]
00007ffd3959b000 12K r---- [ anon ]
00007ffd3959e000 8K r-x-- [ anon ]
ffffffffff600000 4K r-x-- [ anon ]
total 215692K
$ pmap 72770 -p
72770: watch date
00005613a32c9000 20K r-x-- /usr/bin/watch
00005613a34cd000 4K r---- /usr/bin/watch
00005613a34ce000 4K rw--- /usr/bin/watch
00005613a4f6a000 264K rw--- [ anon ]
00007f2f3a7d5000 204616K r---- /usr/lib/locale/locale-archive
00007f2f46fa7000 1748K r-x-- /usr/lib64/libc-2.27.so
00007f2f4715c000 2048K ----- /usr/lib64/libc-2.27.so
00007f2f4735c000 16K r---- /usr/lib64/libc-2.27.so
00007f2f47360000 8K rw--- /usr/lib64/libc-2.27.so
00007f2f47362000 16K rw--- [ anon ]
00007f2f47366000 12K r-x-- /usr/lib64/libdl-2.27.so
00007f2f47369000 2044K ----- /usr/lib64/libdl-2.27.so
00007f2f47568000 4K r---- /usr/lib64/libdl-2.27.so
00007f2f47569000 4K rw--- /usr/lib64/libdl-2.27.so
00007f2f4756a000 160K r-x-- /usr/lib64/libtinfo.so.6.1
00007f2f47592000 2048K ----- /usr/lib64/libtinfo.so.6.1
00007f2f47792000 16K r---- /usr/lib64/libtinfo.so.6.1
00007f2f47796000 4K rw--- /usr/lib64/libtinfo.so.6.1
00007f2f47797000 232K r-x-- /usr/lib64/libncursesw.so.6.1
00007f2f477d1000 2048K ----- /usr/lib64/libncursesw.so.6.1
00007f2f479d1000 4K r---- /usr/lib64/libncursesw.so.6.1
00007f2f479d2000 4K rw--- /usr/lib64/libncursesw.so.6.1
00007f2f479d3000 148K r-x-- /usr/lib64/ld-2.27.so
00007f2f47bdb000 20K rw--- [ anon ]
00007f2f47bf1000 28K r--s- /usr/lib64/gconv/gconv-modules.cache
00007f2f47bf8000 4K r---- /usr/lib64/ld-2.27.so
00007f2f47bf9000 4K rw--- /usr/lib64/ld-2.27.so
00007f2f47bfa000 4K rw--- [ anon ]
00007ffd39404000 136K rw--- [ stack ]
00007ffd3959b000 12K r---- [ anon ]
00007ffd3959e000 8K r-x-- [ anon ]
ffffffffff600000 4K r-x-- [ anon ]
total 215692K
lld
na Darwin, jak się wydaje, nie mogę go znaleźć poprzez homebrew.