Я хотел бы знать, какие библиотеки используются исполняемыми файлами в моей системе. Более конкретно, я хотел бы определить, какие библиотеки используются чаще всего, наряду с двоичными файлами, которые их используют. Как я могу это сделать?
Я хотел бы знать, какие библиотеки используются исполняемыми файлами в моей системе. Более конкретно, я хотел бы определить, какие библиотеки используются чаще всего, наряду с двоичными файлами, которые их используют. Как я могу это сделать?
Ответы:
lddдля отображения общих библиотек для каждого исполняемого файла.Чтобы найти ответ для всех исполняемых файлов в каталоге "/ bin":
find /bin -type f -perm /a+x -exec ldd {} \; \
| grep so \
| sed -e '/^[^\t]/ d' \
| sed -e 's/\t//' \
| sed -e 's/.*=..//' \
| sed -e 's/ (0.*)//' \
| sort \
| uniq -c \
| sort -n
Измените "/ bin" выше на "/", чтобы найти все каталоги.
Вывод (только для каталога / bin) будет выглядеть примерно так:
1 /lib64/libexpat.so.0
1 /lib64/libgcc_s.so.1
1 /lib64/libnsl.so.1
1 /lib64/libpcre.so.0
1 /lib64/libproc-3.2.7.so
1 /usr/lib64/libbeecrypt.so.6
1 /usr/lib64/libbz2.so.1
1 /usr/lib64/libelf.so.1
1 /usr/lib64/libpopt.so.0
1 /usr/lib64/librpm-4.4.so
1 /usr/lib64/librpmdb-4.4.so
1 /usr/lib64/librpmio-4.4.so
1 /usr/lib64/libsqlite3.so.0
1 /usr/lib64/libstdc++.so.6
1 /usr/lib64/libz.so.1
2 /lib64/libasound.so.2
2 /lib64/libblkid.so.1
2 /lib64/libdevmapper.so.1.02
2 /lib64/libpam_misc.so.0
2 /lib64/libpam.so.0
2 /lib64/libuuid.so.1
3 /lib64/libaudit.so.0
3 /lib64/libcrypt.so.1
3 /lib64/libdbus-1.so.3
4 /lib64/libresolv.so.2
4 /lib64/libtermcap.so.2
5 /lib64/libacl.so.1
5 /lib64/libattr.so.1
5 /lib64/libcap.so.1
6 /lib64/librt.so.1
7 /lib64/libm.so.6
9 /lib64/libpthread.so.0
13 /lib64/libselinux.so.1
13 /lib64/libsepol.so.1
22 /lib64/libdl.so.2
83 /lib64/ld-linux-x86-64.so.2
83 /lib64/libc.so.6
Редактировать - убрал "grep -P"
ldd -v
lddвиду, что на самом деле исполняемый файл запускается со специальной переменной среды, и динамический компоновщик Linux распознает этот флаг и просто выводит библиотеки, а не запускает исполняемый файл. Посмотрите на источник ldd; в моей системе это скрипт bash. Если исполняемый файл статически связан и использует системные вызовы и указывает другой загрузчик, он может совершать произвольные злые действия. Так что не используйте lddна исполняемый файл, которому вы не доверяете.
У меня не было ldd на моем ARM toolchain, поэтому я использовал objdump:
$ (CROSS_COMPILE) objdump -p
Например:
objdump -p /usr/bin/python:
Dynamic Section:
NEEDED libpthread.so.0
NEEDED libdl.so.2
NEEDED libutil.so.1
NEEDED libssl.so.1.0.0
NEEDED libcrypto.so.1.0.0
NEEDED libz.so.1
NEEDED libm.so.6
NEEDED libc.so.6
INIT 0x0000000000416a98
FINI 0x000000000053c058
GNU_HASH 0x0000000000400298
STRTAB 0x000000000040c858
SYMTAB 0x0000000000402aa8
STRSZ 0x0000000000006cdb
SYMENT 0x0000000000000018
DEBUG 0x0000000000000000
PLTGOT 0x0000000000832fe8
PLTRELSZ 0x0000000000002688
PLTREL 0x0000000000000007
JMPREL 0x0000000000414410
RELA 0x0000000000414398
RELASZ 0x0000000000000078
RELAENT 0x0000000000000018
VERNEED 0x0000000000414258
VERNEEDNUM 0x0000000000000008
VERSYM 0x0000000000413534
lddкоторое не должно использоваться на ненадежных исполняемых файлах.
obbjdump -pпоказывает дополнительную информацию, такую как RPATH, которая может быть полезна при исследовании проблем динамического связывания с вашим исполняемым файлом.
musl-gccрегулярно создаются двоичные файлы, так что вызов lddдвоичного файла просто выполняет двоичный файл , поэтому в настоящее время мне регулярно напоминают о том, насколько небезопасно ldd).
В Linux я использую:
lsof -P -T -p Application_PID
Это работает лучше, чем lddкогда исполняемый файл использует загрузчик не по умолчанию
Проверьте зависимости общей библиотеки исполняемого файла программы
Чтобы узнать, от каких библиотек зависит конкретный исполняемый файл, вы можете использовать команду ldd. Эта команда вызывает динамический компоновщик для определения библиотечных зависимостей исполняемого файла.
> $ ldd / path / to / program
Обратите внимание, что НЕ рекомендуется запускать ldd с любым ненадежным сторонним исполняемым файлом, потому что некоторые версии ldd могут напрямую вызывать исполняемый файл для определения его библиотечных зависимостей, что может представлять угрозу безопасности.
Вместо этого, более безопасный способ показать зависимости библиотеки неизвестного двоичного файла приложения - использовать следующую команду.
$ objdump -p / path / to / program | ГРЕП НУЖЕН
readelf -d рекурсия
redelf -dпроизводит аналогичный вывод, objdump -pкоторый был упомянут по адресу: https://stackoverflow.com/a/15520982/895245
Но имейте в виду, что динамические библиотеки могут зависеть от других динамических библиотек, которые вам придется использовать.
Пример:
readelf -d /bin/ls | grep 'NEEDED'
Образец выхода:
0x0000000000000001 (NEEDED) Shared library: [libselinux.so.1]
0x0000000000000001 (NEEDED) Shared library: [libacl.so.1]
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
Затем:
$ 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
Выберите один и повторите:
readelf -d /lib/x86_64-linux-gnu/libselinux.so.1 | grep 'NEEDED'
Образец вывода:
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]
И так далее.
/proc/<pid>/maps для запуска процессов
Это полезно, чтобы найти все библиотеки, которые в данный момент используются исполняемыми файлами. Например:
sudo awk '/\.so/{print $6}' /proc/1/maps | sort -u
показывает все загруженные в данный момент динамические зависимости 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
Этот метод также показывает библиотеки, открытые с dlopenпомощью этой минимальной установки, взломанной с помощью sleep(1000)Ubuntu 18.04.
Смотрите также: /superuser/310199/see-currently-loaded-shared-objects-in-linux/1243089
На OS X по умолчанию нет ldd, objdumpили lsof. В качестве альтернативы попробуйте otool -L:
$ otool -L `which openssl`
/usr/bin/openssl:
/usr/lib/libcrypto.0.9.8.dylib (compatibility version 0.9.8, current version 0.9.8)
/usr/lib/libssl.0.9.8.dylib (compatibility version 0.9.8, current version 0.9.8)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)
В этом примере использование which opensslзаполняет полный путь для данной исполняемой и текущей пользовательской среды.
В системе UNIX предположим, что двоичное (исполняемое) имя - test. Затем мы используем следующую команду для просмотра списка библиотек, используемых в тесте:
ldd test
С помощью lddвы можете получить библиотеки, которые используют инструменты. Чтобы оценить использование библиотек для набора инструментов, вы можете использовать что-то вроде следующей команды.
ldd /bin/* /usr/bin/* ... | sed -e '/^[^\t]/ d; s/^\t\(.* => \)\?\([^ ]*\) (.*/\2/g' | sort | uniq -c
(Здесь sedудаляются все строки, которые не начинаются с вкладки, и отфильтровываются только актуальные библиотеки. С sort | uniq -cкаждой библиотекой вы получаете счетчик, показывающий, сколько раз это происходило.)
Возможно, вы захотите добавить sort -gв конце, чтобы получить библиотеки в порядке использования.
Обратите внимание, что вы, вероятно, получите строки две небиблиотечные строки с помощью вышеуказанной команды Один из статических исполняемых файлов («не динамический исполняемый файл») и один без какой-либо библиотеки. Последнее является результатом того, linux-gate.so.1что в вашей файловой системе есть не библиотека, а «поставляемая» ядром.
Еще один вариант можно просто прочитать файл, расположенный на
/proc/<pid>/maps
Например, если идентификатор процесса равен 2601, то команда
cat /proc/2601/maps
И вывод как
7fb37a8f2000-7fb37a8f4000 r-xp 00000000 08:06 4065647 /usr/lib/x86_64-linux-gnu/libproxy/0.4.15/modules/network_networkmanager.so
7fb37a8f4000-7fb37aaf3000 ---p 00002000 08:06 4065647 /usr/lib/x86_64-linux-gnu/libproxy/0.4.15/modules/network_networkmanager.so
7fb37aaf3000-7fb37aaf4000 r--p 00001000 08:06 4065647 /usr/lib/x86_64-linux-gnu/libproxy/0.4.15/modules/network_networkmanager.so
7fb37aaf4000-7fb37aaf5000 rw-p 00002000 08:06 4065647 /usr/lib/x86_64-linux-gnu/libproxy/0.4.15/modules/network_networkmanager.so
7fb37aaf5000-7fb37aafe000 r-xp 00000000 08:06 4065646 /usr/lib/x86_64-linux-gnu/libproxy/0.4.15/modules/config_gnome3.so
7fb37aafe000-7fb37acfd000 ---p 00009000 08:06 4065646 /usr/lib/x86_64-linux-gnu/libproxy/0.4.15/modules/config_gnome3.so
7fb37acfd000-7fb37acfe000 r--p 00008000 08:06 4065646 /usr/lib/x86_64-linux-gnu/libproxy/0.4.15/modules/config_gnome3.so
7fb37acfe000-7fb37acff000 rw-p 00009000 08:06 4065646 /usr/lib/x86_64-linux-gnu/libproxy/0.4.15/modules/config_gnome3.so
7fb37acff000-7fb37ad1d000 r-xp 00000000 08:06 3416761 /usr/lib/x86_64-linux-gnu/libproxy.so.1.0.0
7fb37ad1d000-7fb37af1d000 ---p 0001e000 08:06 3416761 /usr/lib/x86_64-linux-gnu/libproxy.so.1.0.0
7fb37af1d000-7fb37af1e000 r--p 0001e000 08:06 3416761 /usr/lib/x86_64-linux-gnu/libproxy.so.1.0.0
7fb37af1e000-7fb37af1f000 rw-p 0001f000 08:06 3416761 /usr/lib/x86_64-linux-gnu/libproxy.so.1.0.0
7fb37af1f000-7fb37af21000 r-xp 00000000 08:06 4065186 /usr/lib/x86_64-linux-gnu/gio/modules/libgiolibproxy.so
7fb37af21000-7fb37b121000 ---p 00002000 08:06 4065186 /usr/lib/x86_64-linux-gnu/gio/modules/libgiolibproxy.so
7fb37b121000-7fb37b122000 r--p 00002000 08:06 4065186 /usr/lib/x86_64-linux-gnu/gio/modules/libgiolibproxy.so
7fb37b122000-7fb37b123000 rw-p 00003000 08:06 4065186 /usr/lib/x86_64-linux-gnu/gio/modules/libgiolibproxy.so
в пакетах печати Ubuntu, связанных с исполняемым файлом
ldd executable_name|awk '{print $3}'|xargs dpkg -S |awk -F ":" '{print $1}'
Я нашел этот пост очень полезным, так как мне нужно было исследовать зависимости от сторонней библиотеки (32 или 64-битные пути выполнения).
Я собрал рекурсивный bash-скрипт Q & D, основанный на предложении 'readelf -d' для дистрибутива RHEL 6.
Он очень простой и будет проверять каждую зависимость каждый раз, даже если она была проверена ранее (то есть очень многословно). Выход тоже очень простой.
#! /bin/bash
recurse ()
# Param 1 is the nuumber of spaces that the output will be prepended with
# Param 2 full path to library
{
#Use 'readelf -d' to find dependencies
dependencies=$(readelf -d ${2} | grep NEEDED | awk '{ print $5 }' | tr -d '[]')
for d in $dependencies; do
echo "${1}${d}"
nm=${d##*/}
#libstdc++ hack for the '+'-s
nm1=${nm//"+"/"\+"}
# /lib /lib64 /usr/lib and /usr/lib are searched
children=$(locate ${d} | grep -E "(^/(lib|lib64|usr/lib|usr/lib64)/${nm1})")
rc=$?
#at least locate... didn't fail
if [ ${rc} == "0" ] ; then
#we have at least one dependency
if [ ${#children[@]} -gt 0 ]; then
#check the dependeny's dependencies
for c in $children; do
recurse " ${1}" ${c}
done
else
echo "${1}no children found"
fi
else
echo "${1}locate failed for ${d}"
fi
done
}
# Q&D -- recurse needs 2 params could/should be supplied from cmdline
recurse "" !!full path to library you want to investigate!!
перенаправить вывод в файл и grep для «найдено» или «не удалось»
Используйте и изменяйте, на свой страх и риск, конечно, по своему желанию.
dlopen.