Was ist das SO-Dateiformat?
Eine .so-Datei enthält eine dynamisch geladene Shared Library für Unix- und Linux-Anwendungen. .so ist eine Binärdatei, die gemeinsam genutzten Code und Daten bereitstellt, die ein oder mehrere Programme beim Start verwenden können. Die Erweiterung steht für Shared Object und spiegelt die Tatsache wider, dass die Objekte der Bibliothek - Funktionen und Daten - nach dem Laden in den Speicher von mehreren Prozessen gleichzeitig genutzt werden können. Der registrierte MIME-Typ für .so-Dateien ist application/x-sharedlib.
.so-Bibliotheken sind ELF-Objekte (kurz für Executable and Linkable Format), das Standard-Binärformat, das unter Linux und vielen Unix-ähnlichen Systemen für ausführbare Dateien, kompilierte Objekte, gemeinsam genutzte Bibliotheken und Core-Dumps verwendet wird. Jede gültige ELF-Datei - einschließlich .so-Dateien - beginnt mit der 4-Byte-Magic Number \x7FELF bei Offset 0. Die Dateistruktur umfasst:
- ELF-Header - definiert Architektur, Byte-Reihenfolge und Bitbreite (32-Bit oder 64-Bit) sowie die Anzahl der Einträge in den Segment- und Sektionstabellen,
- Programm-Header-Tabelle - beschreibt Speichersegmente, die zur Ladezeit verwendet werden,
- Sektions-Header-Tabelle - beschreibt einzelne Sektionen, die vom Linker und Debugger verwendet werden,
- Daten, auf die diese Header verweisen.
Segmente werden während der Programmausführung verwendet und können aus mehreren Sektionen bestehen; Sektionen werden beim Linking-Vorgang verwendet. .so-Dateien können zur Kompilierzeit mit einem Programm verknüpft oder zur Laufzeit über dlopen() geladen werden.
.so-Dateinamen folgen einer Namenskonvention, bei der dem Bibliotheksnamen ein lib-Präfix vorangestellt wird - eine Bibliothek namens abc hat beispielsweise den Dateinamen libabc.so, und beim Linken dagegen wird das Flag -labc verwendet. Das .so-Suffix kann von einer Versionsnummer gefolgt werden, z. B. libabc.so.3 für die Hauptversions-Datei oder libabc.so.3.1.2 für ein vollständig versioniertes Build. In der Praxis ist libabc.so oft nur ein symbolischer Link, der auf die eigentliche versionierte Datei zeigt, und libabc.so.3 kann selbst ein Symlink auf die neueste kompatible Version sein. Die im dynamischen Eintrag DT_SONAME gespeicherte Version ist das, was der Laufzeit-Linker ld.so aufzeichnet und prüft. Einige Low-Level-Systembibliotheken - wie ld.so selbst - folgen nicht der lib-Präfix-Konvention.
Unter Windows ist das Äquivalent eine .DLL-Datei; unter macOS ist es eine .dylib-Datei. Statische Alternativen unter Linux werden in .a-Dateien archiviert.
Sicherheit
RISIKO: MEDIUMEine .so ist ausführbarer nativer Code, der im Prozess läuft, der sie lädt - eine bösartige Shared Library kann also alles tun, was das Host-Programm kann. Die realen Risiken: (1) Library-Hijacking - eine bösartige .so, die dort platziert wird, wo der Loader zuerst sucht, oder der Missbrauch von LD_PRELOAD/LD_LIBRARY_PATH, kann Code in ein legitimes Programm einschleusen; (2) das Herunterladen einzelner .so-Dateien von beliebigen Websites zur Behebung eines Fehlers - diese können bösartig oder ABI-inkompatibel sein und das System beschädigen oder kompromittieren. Installiere Bibliotheken immer aus den signierten Paket-Repositories deiner Distribution. Das Löschen von System-.so-Dateien (in /lib, /usr/lib) kann das Betriebssystem oder Anwendungen nicht mehr startfähig machen.
Formatdetails
kurz gefasstProgramme zum Öffnen von SO-Dateien
macOS1 app
binutils / file / Ghidra
Open Source macOS verwendet nativ .dylib-Dateien, aber Linux-.so-Dateien können mit Cross-Binutils oder Ghidra inspiziert werden. 'file lib.so' bestätigt, dass es sich um ein ELF-Shared-Object handelt. 
Linux4 apps
System dynamic linker (ld.so) + package manager
Integriert Du „öffnest“ eine .so nicht - der Loader verwendet sie automatisch. Um eine fehlende zu beheben, installiere das Paket, das sie bereitstellt: 'apt install libfoo' / 'dnf install foo' / 'pacman -S foo'. Verwende 'ldconfig', um den Cache zu aktualisieren.
binutils (nm / objdump / readelf)
Open Source Eine .so über die Befehlszeile inspizieren: 'nm -D lib.so' listet Symbole auf, 'readelf -d lib.so' zeigt SONAME/Abhängigkeiten, 'objdump -d lib.so' disassembliert.
ldd
Integriert 'ldd ./program' oder 'ldd lib.so' listet benötigte Shared Objects und ob jedes aufgelöst wird - das Erste, was man bei einem „fehlenden .so“-Fehler ausführen sollte.
Ghidra
Open Source Die .so für vollständige Disassemblierung/Dekompilierung beim Reverse-Engineering von nativem Code importieren (läuft auch unter Windows/macOS). Technische Details
technische Spezifikation| MIME-Typ | application/x-sharedlib |
| Magic Bytes | 7F 45 4C 46 („\x7FELF“) bei Dateioffset 0 - identische Magic wie alle ELF-Dateien; das e_type-Feld unterscheidet Shared Objects |
| ELF e_type-Wert | ET_DYN (0x0003) - unterscheidet ein Shared Object von einer ausführbaren Datei (ET_EXEC = 0x0002) oder einem verlagerbaren Objekt (ET_REL = 0x0001) |
| Bitbreite | EI_CLASS-Byte bei Offset 4: 1 = 32-Bit (Elf32), 2 = 64-Bit (Elf64); beide Varianten sind unter Linux weit verbreitet |
| Byte-Reihenfolge | EI_DATA-Byte bei Offset 5: 1 = Little-Endian (ELFDATA2LSB), 2 = Big-Endian (ELFDATA2MSB); architekturspezifisch |
| Positions-unabhängiger Code | Muss mit -fPIC kompiliert werden, damit die Bibliothek an eine beliebige virtuelle Adresse gemappt werden kann, ohne Relokationskonflikte zwischen Prozessen |
| Dynamische Symboltabelle | .dynsym-Sektion exportiert und importiert zur Laufzeit sichtbare Symbole; .dynstr enthält die entsprechenden Namenszeichenketten |
| PLT / GOT | Procedure Linkage Table und Global Offset Table ermöglichen verzögerte (Standard) oder sofortige (-z now) Symbolauflösung zur Ladezeit |
| Soname (DT_SONAME) | Kanonischer Bibliotheksname, eingebettet in den dynamischen ELF-Abschnitt; ld.so zeichnet diesen Namen beim Linken eines Programms auf und ermöglicht so ABI-Versionsverfolgung unabhängig vom Dateinamen |
| Symbol-Versionierung | .gnu.version- und .gnu.version_r-Sektionen ermöglichen mehrere Symbolversionen innerhalb einer Datei und unterstützen rückwärtskompatible ABI-Entwicklung |
| Laufzeit-Linker | Geladen durch ld.so / ld-linux-x86-64.so.2; Suchpfad gesteuert durch LD_LIBRARY_PATH, DT_RUNPATH oder /etc/ld.so.conf + ldconfig-Cache |
| Namenskonvention | lib<name>.so[.major[.minor.patch]]; libabc.so ist typischerweise ein Entwicklungs-Symlink → libabc.so.3 → libabc.so.3.1.2 |
| Eingebetteter Suchpfad | DT_RPATH- oder DT_RUNPATH-dynamische Einträge baken Bibliothekssuchpfade zur Link-Zeit in die Datei ein; DT_RUNPATH wird bevorzugt, da es durch LD_LIBRARY_PATH überschrieben werden kann |
| Inspektionswerkzeuge | readelf -a, objdump -d, nm --dynamic (binutils); ldd zur Abhängigkeitsliste; file-Befehl identifiziert ELF-Typ und Architektur |
| Veröffentlicht | ELF format 1990s (System V Release 4); .so shared libraries are core to Linux/Unix |
| Offener Standard | Ja · lizenzgebührenfrei |
| Spezifikation | refspecs.linuxfoundation.org |
SO-Konvertierungen
Community Q&A
von Nutzern gefragtNoch keine Fragen - stellen Sie die erste Frage zu SO-Dateien.
