Comment afficher toutes les bibliothèques partagées utilisées par les exécutables sous Linux ?
https://stackoverflow.com/questions/50159
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
J'aimerais 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?
La solution
- Utiliser
lddpour lister les bibliothèques partagées pour chaque exécutable. - Nettoyer la sortie
- Trier, calculer les décomptes, trier par décompte
Pour trouver la réponse pour tous les exécutables du 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 dans tous les répertoires.
La sortie (pour le répertoire /bin uniquement) 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
Modifier - Suppression de "grep -P"
Autres conseils
Je n'avais pas de 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
pour savoir quelles bibliothèques un binaire utilise, utilisez ldd
ldd path/to/the/tool
Vous devrez écrire un petit script shell pour accéder à la répartition de votre système.
Sous Linux j'utilise :
lsof -P -T -p Application_PID
Cela fonctionne mieux que ldd lorsque l'exécutable utilise un chargeur non par défaut
Vérifier les dépendances de la bibliothèque partagée d'un exécutable de programme
Pour savoir de quelles bibliothèques dépend un exécutable particulier, vous pouvez utiliser la commande ldd.Cette commande appelle l'éditeur de liens dynamique pour connaître 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é.
Au lieu de cela, 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 / path / to / programme | Grep nécessaire
readelf -d récursivité
redelf -d produit un résultat similaire à objdump -p qui a été mentionné à: https://stackoverflow.com/a/15520982/895245
Mais attention, les bibliothèques dynamiques peuvent dépendre d'autres bibliothèques dynamiques, il faut donc récurer.
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]
Alors:
$ 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]
Et ainsi de suite.
/proc/<pid>/maps pour exécuter des processus
Ceci est utile pour trouver toutes les bibliothèques actuellement utilisées par l'exécution des 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 affiche également les bibliothèques ouvertes avec dlopen, testé avec cette configuration minimale piraté avec un sleep(1000) sur Ubuntu 18.04.
Voir également: https://superuser.com/questions/310199/see-currently-loaded-shared-objects-in-linux/1243089
Sur le système UNIX, supposons que le nom binaire (exécutable) soit test.Ensuite, nous utilisons la commande suivante pour lister les bibliothèques utilisées dans le test :
ldd test
Sur OS X, par défaut, il n'y a pas ldd, objdump ou 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, en utilisant which openssl remplit le chemin complet de l'exécutable donné et de l'environnement utilisateur actuel.
Avec ldd vous pouvez obtenir les bibliothèques utilisées par les outils.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 sed supprime toutes les lignes qui ne commencent pas par un onglet et filtre uniquement les bibliothèques réelles.Avec sort | uniq -c vous obtenez chaque bibliothèque avec un décompte indiquant le nombre de fois où cela s'est produit.)
Vous voudrez peut-être ajouter sort -g à la fin pour classer les bibliothèques par ordre d'utilisation.
Notez que vous obtenez probablement 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.1 qui n'est pas une bibliothèque dans votre système de fichiers mais une bibliothèque "fournie" par le noyau.
sur les packages d'impression Ubuntu liés à un exécutable
ldd nom_exécutable|awk '{print $3}'|xargs dpkg -S |awk -F ":" '{print $1}'
Une autre option peut être simplement de lire le fichier situé à l'adresse
/proc/<pid>/maps
Par exemple, si l'identifiant du processus est 2601, la commande est
cat /proc/2601/maps
Et le résultat 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
J'ai trouvé cet article 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 contre 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 si elle a pu être testée 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 rechercher "trouvé" ou "échec"
Utilisez et modifiez, à vos risques et périls bien entendu, comme vous le souhaitez.
