Comment vérifier les modules et bibliothèques chargés par un processus sur macOS

Chaque application macOS charge des bibliothèques dynamiques (dylibs) et des frameworks au moment de l’exécution. Inspecter ces modules chargés vous aide à déboguer les problèmes de liaison, auditer les dépendances tierces, détecter les bibliothèques injectées et comprendre l’architecture interne d’une application. Ce guide couvre cinq méthodes pour vérifier quels modules un processus a chargés — des outils en ligne de commande intégrés à une application graphique dédiée.

Réponse rapide

Utilisez vmmap <pid> | grep '\.dylib' dans le Terminal pour lister toutes les bibliothèques dynamiques chargées par un processus en cours d’exécution. Pour les dépendances de liaison statique, utilisez otool -L /chemin/vers/binaire. Pour une interface visuelle et consultable qui affiche les modules chargés avec leurs chemins de fichiers, versions et UUID en un seul clic, utilisez ProcXray.

Que sont les modules chargés sur macOS ?

Un module chargé est une bibliothèque dynamique (.dylib), un framework (.framework) ou un bundle (.bundle) que l’éditeur de liens dynamique de macOS (dyld) mappe dans l’espace d’adressage d’un processus au moment de l’exécution. Il existe deux catégories :

• Dépendances au chargement — bibliothèques liées au binaire lors de la compilation. L’éditeur de liens dynamique les charge automatiquement au démarrage du processus.
• Bibliothèques chargées à l’exécution — bibliothèques chargées à la demande via dlopen() pendant l’exécution. Les plugins, extensions et fonctionnalités optionnelles utilisent couramment ce mécanisme.

Les processus système macOS chargent typiquement entre 100 et 300 modules, tandis que les applications complexes comme Xcode ou Chrome peuvent en charger plus de 1 000. Savoir quels modules sont chargés est essentiel pour diagnostiquer les plantages, identifier les conflits de versions et auditer la sécurité.

Méthode 1 : vmmap — Lister tous les modules chargés d’un processus en cours

La commande vmmap affiche les régions de mémoire virtuelle d’un processus en cours d’exécution. Comme chaque dylib chargée occupe sa propre région mémoire, vous pouvez filtrer la sortie pour voir chaque module actuellement en mémoire.

# List all loaded dylibs for a running process by PID
vmmap <pid> | grep '\.dylib'

Pour trouver le PID au préalable :

# Find the PID of Safari
pgrep -x Safari

Exemple de sortie :

__TEXT   7FF80B2A0000-7FF80B2C1000  r-x/r-x  /usr/lib/system/libsystem_kernel.dylib
__TEXT   7FF80B2C1000-7FF80B2FD000  r-x/r-x  /usr/lib/system/libsystem_c.dylib
__TEXT   7FF80B300000-7FF80B365000  r-x/r-x  /usr/lib/libobjc.A.dylib

Chaque ligne affiche la plage d’adresses mémoire, les permissions et le chemin complet vers la bibliothèque chargée.

Pour inclure également les frameworks :

# Show all loaded dylibs and frameworks
vmmap <pid> | grep -E '\.(dylib|framework)/'

Pour compter le nombre de modules chargés :

vmmap <pid> | grep '\.dylib' | awk '{print $NF}' | sort -u | wc -l

Quand utiliser vmmap

Utilisez vmmap lorsque vous avez besoin de voir tout ce qu’un processus en cours a réellement chargé en mémoire, y compris les modules chargés à l’exécution que otool ne peut pas afficher. Cela nécessite que le processus soit en cours d’exécution et peut requérir des privilèges élevés pour les processus système.

Méthode 2 : otool -L — Vérifier les dépendances de liaison statique

La commande otool inspecte les binaires Mach-O. L’option -L liste toutes les bibliothèques dynamiques auxquelles le binaire est lié lors de la compilation.

# List linked libraries for an application binary
otool -L /Applications/Safari.app/Contents/MacOS/Safari

Exemple de sortie :

/Applications/Safari.app/Contents/MacOS/Safari:
    /System/Library/Frameworks/WebKit.framework/Versions/A/WebKit
    /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
    /usr/lib/libSystem.B.dylib
    /usr/lib/libc++.1.dylib

Cela montre les bibliothèques que le binaire s’attend à charger — ses dépendances de compilation. Cela n’affiche pas les bibliothèques chargées à l’exécution via dlopen().

Pour inspecter les dépendances propres d’une dylib spécifique :

otool -L /usr/lib/libobjc.A.dylib

Quand utiliser otool

Utilisez otool -L lorsque vous voulez savoir ce qu’un binaire devrait charger avant même de l’exécuter. C’est utile pour vérifier les configurations de build, s’assurer que les bons frameworks du SDK sont liés et détecter les dépendances manquantes.

Méthode 3 : lsof — Trouver les bibliothèques chargées via les fichiers ouverts

La commande lsof liste tous les fichiers ouverts par un processus. Comme les bibliothèques chargées sont des fichiers mappés en mémoire, elles apparaissent dans la sortie de lsof.

# List all loaded .dylib files for a process
lsof -p <pid> | grep '\.dylib'

Pour inclure les frameworks :

lsof -p <pid> | grep -E '\.(dylib|framework)'

Quand utiliser lsof

Utilisez lsof lorsque vous avez besoin d’une vérification rapide et que vous êtes déjà familier avec cet outil. Cependant, vmmap fournit des informations plus détaillées (adresses mémoire, permissions) et reste l’outil privilégié pour l’inspection des modules.

Méthode 4 : dyld_info — Inspecter l’éditeur de liens dynamique

À partir de macOS 12 (Monterey), Apple fournit la commande dyld_info pour inspecter les informations de l’éditeur de liens dynamique.

# Show all dependent dylibs of a binary
dyld_info -dependents /Applications/Safari.app/Contents/MacOS/Safari

Pour inspecter l’utilisation du cache partagé dyld par un processus en cours :

# List platform and dependencies
dyld_info -platform -dependents /usr/lib/libobjc.A.dylib

Quand utiliser dyld_info

Utilisez dyld_info lorsque vous avez besoin d’informations détaillées sur le comportement de l’éditeur de liens dynamique, y compris les exigences de plateforme et les chaînes de dépendances. Cet outil fournit une sortie plus propre que otool pour l’analyse des dépendances.

Méthode 5 : ProcXray — Inspecteur visuel de modules

ProcXray propose un onglet Modules dédié qui affiche chaque module chargé pour n’importe quel processus en cours d’exécution — aucune commande à retenir, aucune sortie à analyser.

Comment inspecter les modules avec ProcXray

1. Lancez ProcXray.
2. Sélectionnez un processus dans la liste des processus (utilisez la barre de recherche ou la vue arborescente pour le trouver).
3. Cliquez sur l’onglet Modules dans le panneau de détails.
4. Parcourez la liste complète des dylibs et frameworks chargés, avec les chemins de fichiers et les détails.

Utilisez le champ de recherche de l’onglet Modules pour filtrer par nom de bibliothèque — par exemple, tapez « libsystem » pour trouver toutes les bibliothèques système chargées, ou « swift » pour localiser les modules du runtime Swift.

Ce que ProcXray apporte par rapport aux outils CLI

• Inspection en un clic. Sélectionnez un processus, cliquez sur Modules — c’est fait. Pas besoin de trouver le PID ni de taper des commandes.
• Recherche et filtrage. Filtrez instantanément les modules par nom avec des résultats en temps réel.
• Contexte complet. Consultez les modules aux côtés des variables d’environnement du processus, des fichiers ouverts, des connexions réseau et des signatures de code dans les onglets adjacents.
• Fonctionne pour tous les processus. Inspectez n’importe quel processus en cours sans avoir à construire différentes commandes pour différents scénarios.

Comparaison des méthodes

Cas d’utilisation pratiques

Déboguer un plantage lié à une bibliothèque manquante ou à une mauvaise version

# Check if the expected library version is loaded
vmmap <pid> | grep 'libssl'

Si la sortie pointe vers un libssl différent de celui attendu (par exemple, une version Homebrew au lieu de la version système), vous avez identifié le conflit de versions.

Auditer une application pour détecter les bibliothèques injectées

Les chercheurs en sécurité et les développeurs peuvent vérifier si des bibliothèques inattendues ont été chargées dans un processus :

# Look for libraries not from /System or /usr/lib
vmmap <pid> | grep '\.dylib' | grep -v '/System/' | grep -v '/usr/lib/'

Tout résultat peut indiquer des injections tierces, des plugins ou des frameworks personnalisés qui méritent une investigation.

Vérifier si une application utilise un framework spécifique

# Does this app use SwiftUI?
vmmap <pid> | grep 'SwiftUI'

# Does it link against Metal?
otool -L /path/to/binary | grep 'Metal'

FAQ

Quelle est la différence entre une dylib et un framework sur macOS ?

Un .dylib est un fichier de bibliothèque dynamique autonome. Un .framework est un répertoire de type bundle qui contient une dylib accompagnée d’en-têtes, de ressources et de métadonnées. Les frameworks sont le format d’empaquetage standard des bibliothèques système d’Apple et des SDK tiers. Au moment de l’exécution, les deux sont chargés de la même manière par dyld.

Puis-je voir quelles dylibs utilise une application en cours sans le Terminal ?

Oui. ProcXray vous permet de sélectionner n’importe quel processus en cours et de visualiser ses modules chargés dans une interface graphique avec recherche intégrée. Aucune commande terminal n’est nécessaire.

Pourquoi un processus charge-t-il des centaines de bibliothèques ?

macOS repose fortement sur la liaison dynamique. Même une simple application « Hello World » écrite en Swift charge plus de 100 modules, car le runtime Swift, le framework Foundation et les bibliothèques système fondamentales entraînent chacun leurs propres dépendances. C’est normal et voulu — les bibliothèques partagées réduisent l’utilisation de la mémoire à l’échelle du système.

Est-ce que otool -L affiche tout ce qu’un processus va charger ?

Non. otool -L affiche uniquement les dépendances de liaison à la compilation. Les bibliothèques chargées à l’exécution via dlopen() — comme les plugins, les fonctionnalités optionnelles et les composants chargés à la demande — ne sont pas affichées. Utilisez vmmap sur le processus en cours pour obtenir une vue complète.

Ai-je besoin de sudo pour inspecter les modules d’un autre processus ?

Pour vos propres processus, non. Pour les processus système ou les processus appartenant à d’autres utilisateurs, vous aurez peut-être besoin de sudo avec vmmap et lsof. ProcXray demandera les autorisations macOS nécessaires lors du premier lancement.

Sources et références

• Apple : vmmap man page
• Apple : otool man page
• Apple : dyld — Dynamic Link Editor
• Apple : lsof man page

Télécharger ProcXray → — gratuit, macOS Sonoma+.