如何显示Linux中可执行文件使用的所有共享库?

linux shared-libraries

289229 观看

12回复

1291 作者的声誉

我想知道我的系统上的可执行文件使用了哪些库。更具体地说,我想对使用最多的库以及使用它们的二进制文件进行排序。我怎样才能做到这一点?

作者: Alan Szlosek 的来源 发布者: 2008 年 9 月 8 日

回应 (12)


47

11758 作者的声誉

要了解二进制文件使用的库,请使用ldd

ldd path/to/the/tool

您必须编写一个小的shell脚本来进行系统崩溃。

作者: pilif 发布者: 08.09.2008 05:04

249

4274 作者的声誉

决定
  1. 使用ldd列出每个可执行文件共享库。
  2. 清理输出
  3. 排序,计算计数,按计数排序

要查找“/ 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”

作者: John Vasileff 发布者: 08.09.2008 05:21

4

8098 作者的声誉

有了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不是文件系统中的库,而是由内核“提供”的库。

作者: mweerden 发布者: 08.09.2008 05:35

6

61 作者的声誉

在UNIX系统上,假设二进制(可执行)名称是test。然后我们使用以下命令列出测试中使用的库

ldd test
作者: Raghwendra 发布者: 20.04.2011 08:07

45

1561 作者的声誉

在Linux上我使用:

lsof -P -T -p Application_PID

这比ldd可执行文件使用非默认加载器时效果更好

作者: Fabiano Tarlao 发布者: 17.11.2011 11:54

62

3257 作者的声誉

我没有在我的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
作者: smichak 发布者: 20.03.2013 10:28

7

599 作者的声誉

在OS X上默认情况下没有lddobjdumplsof。作为替代方案,请尝试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填充给定可执行文件和当前用户环境的完全限定路径。

作者: bluebadge 发布者: 27.01.2015 12:29

18

753 作者的声誉

检查程序可执行文件的共享库依赖项

要找出特定可执行文件所依赖的库,可以使用ldd命令。此命令调用动态链接器以查找可执行文件的库依赖项。

> $ ldd / path / to / program

请注意,不建议使用任何不受信任的第三方可执行文件运行ldd,因为某些版本的ldd可能会直接调用可执行文件来识别其库依赖项,这可能存在安全风险。

相反,显示未知应用程序二进制文件的库依赖关系的更安全的方法是使用以下命令。

$ objdump -p / path / to / program | 需要grep

了解更多信息

作者: kayle 发布者: 24.04.2015 04:53

8

164991 作者的声誉

readelf -d 递归

redelf -d产生类似的输出objdump -p,如下所述:https//stackoverflow.com/a/15520982/895245

但要注意动态库可以依赖于其他动态库,你必须递归。

例:

readelf -d /bin/ls | grep 'NEEDED'

示例ouptut:

 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。

另见:https//superuser.com/questions/310199/see-currently-loaded-shared-objects-in-linux/1243089

作者: Ciro Santilli 新疆改造中心996ICU六四事件 发布者: 26.03.2017 08:57

2

2870 作者的声誉

在与可执行文件相关的ubuntu打印包上

ldd executable_name|awk '{print $3}'|xargs dpkg -S |awk -F  ":"  '{print $1}'
作者: Shimon Doodkin 发布者: 04.04.2017 12:41

0

1 作者的声誉

我发现这篇文章非常有用,因为我需要调查第三方提供的库(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!!

将输出重定向到文件,grep为'found'或'failed'

当然,您可以根据自己的风险使用和修改。

作者: Anders Domeij 发布者: 19.10.2017 02:20

1

46 作者的声誉

还有一个选项可以是读取位于的文件

/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
作者: SoSen 发布者: 30.11.2018 09:43
32x32