如何显示 Linux 中可执行文件使用的所有共享库?
- 2024-10-14 08:39:00
- admin 原创
- 72
问题描述:
我想知道我的系统上的可执行文件使用了哪些库。更具体地说,我想对使用最多的库以及使用它们的二进制文件进行排名。我该怎么做?
解决方案 1:
用于
ldd
列出每个可执行文件的共享库。清理输出
排序、计算计数、按计数排序
要查找“/bin”目录中所有可执行文件的答案:
find /bin -type f -perm /a+x -exec ldd {} ; \n| grep so \n| sed -e '/^[^ ]/ d' \n| sed -e 's/ //' \n| sed -e 's/.*=..//' \n| sed -e 's/ (0.*)//' \n| sort \n| uniq -c \n| 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”
解决方案 2:
我的 ARM 工具链上没有 ldd,因此我使用了 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
解决方案 3:
在 Linux 上我使用:
lsof -P -T -p Application_PID
ldd
这比可执行文件使用非默认加载器时效果更好
解决方案 4:
要了解二进制文件使用了哪些库,请使用 ldd
ldd path/to/the/tool
您必须编写一个小的 shell 脚本才能找到整个系统的故障。
解决方案 5:
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
,并使用在 Ubuntu 18.04 上使用 破解的最小设置进行测试。sleep(1000)
另请参阅: https: //superuser.com/questions/310199/see-currently-loaded-shared-objects-in-linux/1243089
解决方案 6:
检查程序可执行文件的共享库依赖关系
要找出特定可执行文件所依赖的库,可以使用 ldd 命令。此命令调用动态链接器来找出可执行文件的库依赖关系。
>$ ldd /路径/到/程序
请注意,不建议使用任何不受信任的第三方可执行文件运行 ldd,因为某些版本的 ldd 可能会直接调用可执行文件来识别其库依赖项,这可能会带来安全风险。
相反,显示未知应用程序二进制文件的库依赖关系的更安全的方法是使用以下命令。
$ objdump -p /path/to/program | grep 需要
了解更多信息
解决方案 7:
在 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
填写给定可执行文件和当前用户环境的完整限定路径。
解决方案 8:
在 UNIX 系统上,假设二进制(可执行)名称为 test。然后我们使用以下命令列出测试中使用的库:
ldd test
解决方案 9:
还有一个选项可以只读取位于的文件
/proc/<pid>/maps
例如,进程 ID 为 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
解决方案 10:
您ldd
可以获取工具使用的库。要对一组工具的库使用情况进行排序,您可以使用类似以下命令。
ldd /bin/* /usr/bin/* ... | sed -e '/^[^ ]/ d; s/^ (.* => )?([^ ]*) (.*//g' | sort | uniq -c
(这里sed
删除所有不以制表符开头的行,并仅过滤出实际的库。sort | uniq -c
您将获得每个库的计数,表示其发生的次数。)
您可能希望sort -g
在最后添加以按使用顺序获取库。
请注意,使用上述命令,您可能会得到两行非库文件。一行是静态可执行文件(“不是动态可执行文件”),另一行没有任何库。后者的结果linux-gate.so.1
不是文件系统中的库,而是由内核“提供”的库。
解决方案 11:
如果你不关心可执行文件的路径-
ldd `which <executable>` # back quotes, not single quotes
解决方案 12:
在 ubuntu 上打印与可执行文件相关的软件包
ldd executable_name|awk '{print $3}'|xargs dpkg -S |awk -F ":" '{print $1}'
解决方案 13:
对于直接链接的库(您通常需要的):
objdump --private-headers [BINARY] | grep 'NEEDED' | cut --delimiter=' ' --fields=18-
对于所有人:
ldd [二进制] | cut --fields=2 | cut --delimiter=' ' --fields=1 | rev | cut --delimiter='/' --fields=1 | rev | sort --unique --version-sort
解决方案 14:
我发现这篇文章非常有用,因为我需要调查第三方提供的库的依赖关系(32 位与 64 位执行路径)。
我根据 RHEL 6 发行版上的“readelf -d”建议整理了一个 Q&D 递归 bash 脚本。
它非常基础,每次都会测试每个依赖项,即使以前可能已经测试过(即非常详细)。输出也非常基础。
#! /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!!
将输出重定向到文件并查找“found”或“failed”
当然,您可以自行承担风险,按照您的意愿使用和修改。
- 2024年20款好用的项目管理软件推荐,项目管理提效的20个工具和技巧
- 2024年开源项目管理软件有哪些?推荐5款好用的项目管理工具
- 项目管理软件有哪些?推荐7款超好用的项目管理工具
- 项目管理软件哪个最好用?盘点推荐5款好用的项目管理工具
- 项目管理软件有哪些最好用?推荐6款好用的项目管理工具
- 项目管理软件有哪些,盘点推荐国内外超好用的7款项目管理工具
- 2024项目管理软件排行榜(10类常用的项目管理工具全推荐)
- 项目管理软件排行榜:2024年项目经理必备5款开源项目管理软件汇总
- 2024年常用的项目管理软件有哪些?推荐这10款国内外好用的项目管理工具
- 项目管理必备:盘点2024年13款好用的项目管理软件