Comment afficher toutes les bibliothèques partagées utilisées par les exécutables sous Linux?

225

Je voudrais savoir quelles bibliothèques sont utilisées par les exécutables sur mon système. Plus précisément, j'aimerais classer les bibliothèques les plus utilisées, ainsi que les binaires qui les utilisent. Comment puis-je faire ceci?

linux  shared-libraries 
— Alan Szlosek
source
Vous ne pourrez probablement pas obtenir un nombre exact si les exécutables utilisent dlopen.
— jxh

Réponses:

271
  1. Permet lddde répertorier les bibliothèques partagées pour chaque exécutable.
  2. Nettoyer la sortie
  3. Trier, calculer les nombres, trier par nombre

Pour trouver la réponse pour tous les exécutables dans le répertoire "/ 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

Remplacez «/ bin» ci-dessus par «/» pour rechercher tous les répertoires.

La sortie (uniquement pour le répertoire / bin) ressemblera à ceci:

  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

Édition - Suppression de "grep -P"

— John Vasileff
source
2
C'est une excellente réponse (j'ai voté pour elle), mais pouvez-vous expliquer la commande "grep -P '\ t. * So'"? Selon man, cela interprète le modèle comme une expression rationnelle perl, mais ma version de grep ne le prend pas en charge (l'homme indique qu'il s'agit d'un problème général). Quelle partie de l'expression rationnelle est spécifique à Perl?
— Bobby Jack, le
2
Je pense que vous devrez peut-être utiliserldd -v
— MountainX
58
Sachez qu'en lddfait exécute l'exécutable avec une variable d'environnement spéciale, et l'éditeur de liens dynamique Linux reconnaît cet indicateur et sort simplement les bibliothèques plutôt que d'exécuter l'exécutable. Regardez la source pour ldd; sur mon système, c'est un script bash. Si l'exécutable est lié statiquement et utilise des appels système et spécifie un chargeur différent, il peut faire des choses arbitraires. Ne l'utilisez donc pas lddsur un exécutable auquel vous ne faites pas confiance.
— Barry Kelly
'ldd' ne fonctionne pas pour moi sur les binaires compilés de manière croisée. La question est de trouver les bibliothèques utilisées par les programmes sur le système actuel (qui seraient des programmes natifs, tels que formulés). C'est une bonne réponse à cela. Cependant, je pensais que je mentionnerais que vous devez utiliser autre chose si vous recherchez les bibliothèques partagées pour des programmes pour un système différent ('readelf' mentionné dans une autre réponse, a fonctionné pour moi)
— Tim Bird
68

Je n'avais pas ldd sur ma chaîne d'outils ARM, j'ai donc utilisé objdump:

$ (CROSS_COMPILE) objdump -p

Par exemple:

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
source
2
Cela devrait également être sûr, contrairement à lddce qui ne devrait pas être utilisé sur les exécutables non approuvés.
— PSkocik
Affiche également obbjdump -pdes informations supplémentaires telles que le RPATH, qui peuvent être utiles lors de l'examen des problèmes de liaison dynamique avec votre exécutable.
— sitaktif
+1 pour la méthode qui est en fait sûre et fiable (j'ai en quelque sorte un système qui musl-gccproduit régulièrement des binaires tels que l'appel lddau binaire exécute simplement le binaire , donc de nos jours je me rappelle régulièrement à quel point il lddest dangereux ).
— mtraceur
48

pour savoir quelles bibliothèques un binaire utilise, utilisez ldd

ldd path/to/the/tool

Vous devrez écrire un petit script shell pour arriver à votre panne à l'échelle du système.

— pilif
source
19

Vérifier les dépendances de bibliothèque partagée d'un exécutable de programme

Pour savoir de quelles bibliothèques un exécutable particulier dépend, vous pouvez utiliser la commande ldd. Cette commande appelle l'éditeur de liens dynamique pour découvrir les dépendances de bibliothèque d'un exécutable.

> $ ldd / chemin / vers / programme

Notez qu'il n'est PAS recommandé d'exécuter ldd avec un exécutable tiers non fiable car certaines versions de ldd peuvent appeler directement l'exécutable pour identifier ses dépendances de bibliothèque, ce qui peut constituer un risque pour la sécurité.

À la place, un moyen plus sûr d'afficher les dépendances de bibliothèque d'un binaire d'application inconnu consiste à utiliser la commande suivante.

$ objdump -p / chemin / vers / programme | grep BESOIN

pour plus d'informations

— kayle
source
14

readelf -d récursivité

redelf -dproduit une sortie similaire à objdump -pcelle mentionnée sur: https://stackoverflow.com/a/15520982/895245

Mais sachez que les bibliothèques dynamiques peuvent dépendre d'autres bibliothèques dynamiques, vous devez donc recurse.

Exemple:

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

Exemple de sortie:

 0x0000000000000001 (NEEDED)             Shared library: [libselinux.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libacl.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]

Ensuite:

$ 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

Choisissez-en un et répétez:

readelf -d /lib/x86_64-linux-gnu/libselinux.so.1 | grep 'NEEDED'

Exemple de sortie:

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]

Etc.

/proc/<pid>/maps pour exécuter des processus

Ceci est utile pour trouver toutes les bibliothèques actuellement utilisées par les exécutables. Par exemple:

sudo awk '/\.so/{print $6}' /proc/1/maps | sort -u

affiche toutes les dépendances dynamiques actuellement chargées de 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

Cette méthode montre également les bibliothèques ouvertes avec dlopen, testées avec cette configuration minimale piratée avec un sleep(1000)sur Ubuntu 18.04.

Voir également: /superuser/310199/see-currently-loaded-shared-objects-in-linux/1243089

— Ciro Santilli 郝海东 冠状 病 六四 事件 法轮功
source
8

Sur OS X par défaut, il n'y a pas de ldd, objdumpou lsof. Comme alternative, essayez 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)

Dans cet exemple, l'utilisation which opensslremplit le chemin d'accès complet pour l'environnement utilisateur exécutable et actuel donné.

— bluebadge
source
6

Sur le système UNIX, supposons que le nom binaire (exécutable) soit test. Ensuite, nous utilisons la commande suivante pour répertorier les bibliothèques utilisées dans le test est

ldd test
— Raghwendra
source
4

Avec lddvous pouvez obtenir les bibliothèques que les outils utilisent. Pour classer l'utilisation des bibliothèques pour un ensemble d'outils, vous pouvez utiliser quelque chose comme la commande suivante.

ldd /bin/* /usr/bin/* ... | sed -e '/^[^\t]/ d; s/^\t\(.* => \)\?\([^ ]*\) (.*/\2/g' | sort | uniq -c

(Ici sedsupprime toutes les lignes qui ne commencent pas par un onglet et filtre uniquement les bibliothèques réelles. Avec sort | uniq -cvous obtenez chaque bibliothèque avec un décompte indiquant le nombre de fois où elle s'est produite.)

Vous voudrez peut-être ajouter sort -gà la fin pour obtenir les bibliothèques par ordre d'utilisation.

Notez que vous obtenez probablement des lignes deux lignes non-bibliothèque avec la commande ci-dessus. Un des exécutables statiques ("pas un exécutable dynamique") et un sans aucune bibliothèque. Cette dernière est le résultat de linux-gate.so.1ce qui n'est pas une bibliothèque dans votre système de fichiers mais une bibliothèque "fournie" par le noyau.

— mweerden
source
2

Une autre option peut être simplement lire le fichier situé à

/proc/<pid>/maps

Par exemple, l'ID de processus est 2601, puis la commande est

cat /proc/2601/maps

Et la sortie est comme

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
source
2

sur les paquets d'impression ubuntu liés à un exécutable

ldd executable_name|awk '{print $3}'|xargs dpkg -S |awk -F  ":"  '{print $1}'
— Shimon Doodkin
source
0

J'ai trouvé ce message très utile car j'avais besoin d'étudier les dépendances d'une bibliothèque fournie par un tiers (chemin (s) d'exécution 32 vs 64 bits).

J'ai mis en place un script bash récursif Q&D basé sur la suggestion 'readelf -d' sur une distribution RHEL 6.

Il est très basique et testera chaque dépendance à chaque fois même s'il a pu être testé auparavant (c'est-à-dire très détaillé). La sortie est également très basique.

#! /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!!

rediriger la sortie vers un fichier et grep pour «trouvé» ou «échoué»

Utilisez et modifiez, à vos risques et périls bien sûr, comme vous le souhaitez.

— Anders Domeij
source
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.