Geladene Module und Bibliotheken eines Prozesses auf macOS anzeigen

Jede macOS-Anwendung lädt zur Laufzeit dynamische Bibliotheken (dylibs) und Frameworks. Die Inspektion dieser geladenen Module hilft Ihnen bei der Fehlersuche von Linking-Problemen, der Prüfung von Drittanbieter-Abhängigkeiten, der Erkennung eingeschleuster Bibliotheken und dem Verständnis der internen Architektur einer App. Dieser Leitfaden behandelt fünf Methoden, um zu prüfen, welche Module ein Prozess geladen hat — von integrierten Kommandozeilen-Tools bis hin zu einer dedizierten GUI-Anwendung.

Kurzantwort

Verwenden Sie vmmap <pid> | grep '\.dylib' im Terminal, um alle dynamischen Bibliotheken aufzulisten, die von einem laufenden Prozess geladen wurden. Für statische Link-Abhängigkeiten verwenden Sie otool -L /pfad/zum/binary. Für eine visuelle, durchsuchbare Oberfläche, die geladene Module mit Dateipfaden, Versionen und UUIDs mit einem Klick anzeigt, verwenden Sie ProcXray.

Was sind geladene Module auf macOS?

Ein geladenes Modul ist eine dynamische Bibliothek (.dylib), ein Framework (.framework) oder ein Bundle (.bundle), das der macOS Dynamic Linker (dyld) zur Laufzeit in den Adressraum eines Prozesses einblendet. Es gibt zwei Kategorien:

• Ladezeit-Abhängigkeiten — Bibliotheken, gegen die das Binary zur Kompilierzeit gelinkt wird. Der Dynamic Linker lädt sie automatisch beim Start des Prozesses.
• Zur Laufzeit geladene Bibliotheken — Bibliotheken, die bei Bedarf über dlopen() während der Ausführung geladen werden. Plugins, Erweiterungen und optionale Funktionen nutzen häufig dieses Muster.

macOS-Systemprozesse laden typischerweise 100–300 Module, während komplexe Apps wie Xcode oder Chrome über 1.000 laden können. Zu wissen, welche Module geladen sind, ist entscheidend für die Diagnose von Abstürzen, die Identifikation von Versionskonflikten und die Sicherheitsüberprüfung.

Methode 1: vmmap — Alle geladenen Module eines laufenden Prozesses auflisten

Der Befehl vmmap zeigt die virtuellen Speicherbereiche eines laufenden Prozesses an. Da jede geladene dylib ihren eigenen Speicherbereich belegt, können Sie die Ausgabe filtern, um jedes aktuell im Speicher befindliche Modul zu sehen.

# Alle geladenen dylibs eines laufenden Prozesses nach PID auflisten
vmmap <pid> | grep '\.dylib'

Um zuerst die PID zu finden:

# PID von Safari finden
pgrep -x Safari

Beispielausgabe:

__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

Jede Zeile zeigt den Speicheradressbereich, die Berechtigungen und den vollständigen Pfad zur geladenen Bibliothek.

Um auch Frameworks einzuschließen:

# Alle geladenen dylibs und Frameworks anzeigen
vmmap <pid> | grep -E '\.(dylib|framework)/'

Um zu zählen, wie viele Module geladen sind:

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

Wann vmmap verwenden

Verwenden Sie vmmap, wenn Sie alles sehen müssen, was ein laufender Prozess tatsächlich in den Speicher geladen hat, einschließlich zur Laufzeit geladener Module, die otool nicht anzeigen kann. Der Prozess muss laufen, und für Systemprozesse sind möglicherweise erhöhte Berechtigungen erforderlich.

Methode 2: otool -L — Statische Link-Abhängigkeiten prüfen

Der Befehl otool inspiziert Mach-O-Binaries. Das Flag -L listet alle dynamischen Bibliotheken auf, gegen die das Binary zur Kompilierzeit gelinkt wurde.

# Gelinkte Bibliotheken eines Anwendungs-Binarys auflisten
otool -L /Applications/Safari.app/Contents/MacOS/Safari

Beispielausgabe:

/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

Dies zeigt die Bibliotheken, die das Binary voraussichtlich laden wird — seine Kompilierzeit-Abhängigkeiten. Bibliotheken, die zur Laufzeit über dlopen() geladen werden, werden hier nicht angezeigt.

Um die eigenen Abhängigkeiten einer bestimmten dylib zu inspizieren:

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

Wann otool verwenden

Verwenden Sie otool -L, wenn Sie wissen möchten, was ein Binary laden sollte, noch bevor Sie es ausführen. Dies ist nützlich zur Überprüfung von Build-Konfigurationen, zur Kontrolle, ob die richtigen SDK-Frameworks gelinkt sind, und zur Erkennung fehlender Abhängigkeiten.

Methode 3: lsof — Geladene Bibliotheken über offene Dateien finden

Der Befehl lsof listet alle von einem Prozess geöffneten Dateien auf. Da geladene Bibliotheken speicherabgebildete Dateien sind, erscheinen sie in der lsof-Ausgabe.

# Alle geladenen .dylib-Dateien eines Prozesses auflisten
lsof -p <pid> | grep '\.dylib'

Um Frameworks einzuschließen:

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

Wann lsof verwenden

Verwenden Sie lsof, wenn Sie eine schnelle Prüfung benötigen und bereits mit dem Tool vertraut sind. vmmap liefert jedoch detailliertere Informationen (Speicheradressen, Berechtigungen) und ist das bevorzugte Tool für die Modulinspektion.

Methode 4: dyld_info — Den Dynamic Linker inspizieren

Ab macOS 12 (Monterey) stellt Apple den Befehl dyld_info zur Inspektion von Dynamic-Linker-Informationen bereit.

# Alle abhängigen dylibs eines Binarys anzeigen
dyld_info -dependents /Applications/Safari.app/Contents/MacOS/Safari

Zur Inspektion der dyld Shared Cache-Nutzung eines laufenden Prozesses:

# Plattform und Abhängigkeiten auflisten
dyld_info -platform -dependents /usr/lib/libobjc.A.dylib

Wann dyld_info verwenden

Verwenden Sie dyld_info, wenn Sie detaillierte Informationen über das Verhalten des Dynamic Linkers benötigen, einschließlich Plattformanforderungen und Abhängigkeitsketten. Es liefert eine übersichtlichere Ausgabe als otool für die Abhängigkeitsanalyse.

Methode 5: ProcXray — Visueller Modul-Inspektor

ProcXray bietet einen dedizierten Modules-Tab, der jedes geladene Modul eines beliebigen laufenden Prozesses anzeigt — keine Befehle zum Merken, keine Ausgabe zum Parsen.

Module mit ProcXray inspizieren

1. Starten Sie ProcXray.
2. Wählen Sie einen Prozess aus der Prozessliste (nutzen Sie die Suchleiste oder die Baumansicht zum Finden).
3. Klicken Sie auf den Modules-Tab im Detailbereich.
4. Durchsuchen Sie die vollständige Liste der geladenen dylibs und Frameworks mit Dateipfaden und Details.

Verwenden Sie das Suchfeld im Modules-Tab, um nach Bibliotheksnamen zu filtern — tippen Sie beispielsweise „libsystem” ein, um alle geladenen Systembibliotheken zu finden, oder „swift”, um Swift-Runtime-Module zu lokalisieren.

Was ProcXray gegenüber CLI-Tools zusätzlich bietet

• Ein-Klick-Inspektion. Prozess auswählen, Modules anklicken — fertig. Kein Suchen der PID oder Eintippen von Befehlen nötig.
• Suchen und Filtern. Module sofort nach Name filtern mit Echtzeit-Ergebnissen.
• Vollständiger Kontext. Module neben den Umgebungsvariablen, offenen Dateien, Netzwerkverbindungen und Code-Signaturen des Prozesses in benachbarten Tabs einsehen.
• Funktioniert für alle Prozesse. Jeden laufenden Prozess inspizieren, ohne verschiedene Befehle für verschiedene Szenarien zusammenstellen zu müssen.

Vergleich der Methoden

Praktische Anwendungsfälle

Absturz durch eine fehlende oder falsche Bibliotheksversion debuggen

# Prüfen, ob die erwartete Bibliotheksversion geladen ist
vmmap <pid> | grep 'libssl'

Wenn die Ausgabe auf eine andere libssl verweist als erwartet (zum Beispiel eine Homebrew-Version statt der Systemversion), haben Sie den Versionskonflikt gefunden.

Eine App auf eingeschleuste Bibliotheken prüfen

Sicherheitsforscher und Entwickler können prüfen, ob unerwartete Bibliotheken in einen Prozess geladen wurden:

# Nach Bibliotheken suchen, die nicht aus /System oder /usr/lib stammen
vmmap <pid> | grep '\.dylib' | grep -v '/System/' | grep -v '/usr/lib/'

Jedes Ergebnis kann auf Drittanbieter-Injektionen, Plugins oder benutzerdefinierte Frameworks hinweisen, die eine nähere Untersuchung verdienen.

Prüfen, ob eine App ein bestimmtes Framework verwendet

# Verwendet diese App SwiftUI?
vmmap <pid> | grep 'SwiftUI'

# Ist sie gegen Metal gelinkt?
otool -L /path/to/binary | grep 'Metal'

FAQ

Was ist der Unterschied zwischen einer dylib und einem Framework auf macOS?

Eine .dylib ist eine eigenständige dynamische Bibliotheksdatei. Ein .framework ist ein Bundle-Verzeichnis, das eine dylib zusammen mit Headern, Ressourcen und Metadaten enthält. Frameworks sind das Standardformat für Apples Systembibliotheken und Drittanbieter-SDKs. Zur Laufzeit werden beide auf die gleiche Weise von dyld geladen.

Kann ich die von einer laufenden App verwendeten dylibs ohne Terminal sehen?

Ja. ProcXray lässt Sie jeden laufenden Prozess auswählen und seine geladenen Module in einer grafischen Oberfläche mit integrierter Suche betrachten. Keine Terminal-Befehle erforderlich.

Warum lädt ein Prozess Hunderte von Bibliotheken?

macOS setzt stark auf dynamisches Linking. Selbst eine einfache „Hello World”-App in Swift lädt über 100 Module, da die Swift-Runtime, das Foundation-Framework und die zentralen Systembibliotheken jeweils ihre eigenen Abhängigkeiten mitbringen. Das ist normal und so beabsichtigt — gemeinsam genutzte Bibliotheken reduzieren den Speicherverbrauch im gesamten System.

Zeigt otool -L alles, was ein Prozess laden wird?

Nein. otool -L zeigt nur Kompilierzeit-Abhängigkeiten. Bibliotheken, die zur Laufzeit über dlopen() geladen werden — wie Plugins, optionale Funktionen und verzögert geladene Komponenten — werden nicht angezeigt. Verwenden Sie vmmap auf dem laufenden Prozess, um das vollständige Bild zu erhalten.

Benötige ich sudo, um die Module eines anderen Prozesses zu inspizieren?

Für Ihre eigenen Prozesse nicht. Für Systemprozesse oder Prozesse anderer Benutzer benötigen Sie möglicherweise sudo mit vmmap und lsof. ProcXray fragt beim ersten Start nach den erforderlichen macOS-Berechtigungen.

Quellen und Referenzen

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

ProcXray herunterladen → — kostenlos, macOS Sonoma+.