Qu'est-ce que le format de fichier SO ?
Un fichier .so contient une bibliothèque partagée chargée dynamiquement pour les applications Unix et Linux. .so est un fichier binaire utilisé pour fournir l'accès à du code et des données partagés qu'un ou plusieurs programmes peuvent utiliser lors de leur lancement. L'extension signifie « Shared Object » (objet partagé), reflétant le fait qu'une fois la bibliothèque chargée en mémoire, ses objets - fonctions et données - peuvent être consultés par plusieurs processus simultanément. Le type MIME enregistré pour les fichiers .so est application/x-sharedlib.
Les bibliothèques .so sont des objets ELF (abréviation de Executable and Linkable Format), le format binaire standard utilisé sur Linux et de nombreux systèmes de type Unix pour les exécutables, les objets compilés, les bibliothèques partagées et les vidages de mémoire (core dumps). Tout fichier ELF valide - y compris les fichiers .so - commence par le nombre magique de quatre octets \x7FELF à l'offset 0. La structure du fichier comprend :
- L'en-tête ELF - définit l'architecture, l'endianness et la taille des mots (32 bits ou 64 bits), ainsi que le nombre d'entrées dans les tables de segments et de sections,
- La table d'en-tête de programme - décrit les segments de mémoire utilisés au moment du chargement,
- La table d'en-tête de section - décrit les sections individuelles utilisées par l'éditeur de liens et le débogueur,
- Les données référencées par ces en-têtes.
Les segments sont utilisés pendant l'exécution du programme et peuvent être composés de plusieurs sections ; les sections sont utilisées pendant l'opération de liaison. Les fichiers .so peuvent être liés à un programme au moment de la compilation ou chargés à l'exécution via dlopen().
Les noms de fichiers .so suivent une convention de nommage où le nom de la bibliothèque est précédé du préfixe lib - par exemple, une bibliothèque nommée abc aura pour nom de fichier libabc.so, et le drapeau -labc est utilisé lors de la liaison. Le suffixe .so peut être suivi d'un numéro de version, tel que libabc.so.3 pour le fichier de version majeure ou libabc.so.3.1.2 pour une version complète. En pratique, libabc.so n'est souvent qu'un lien symbolique pointant vers le fichier versionné réel, et libabc.so.3 peut lui-même être un lien symbolique vers la version compatible la plus récente. La version stockée dans l'entrée dynamique DT_SONAME est ce que l'éditeur de liens dynamique ld.so enregistre et vérifie. Certaines bibliothèques système de bas niveau - comme ld.so lui-même - ne suivent pas la convention du préfixe lib.
Sur Windows, le concept équivalent est un fichier .DLL ; sur macOS, il s'agit d'un fichier .dylib. Les alternatives statiques sur Linux sont archivées dans des fichiers .a.
Sécurité et sûreté
RISQUE : MEDIUMUn .so est un code natif exécutable qui s'exécute à l'intérieur du processus qui le charge, donc une bibliothèque partagée malveillante peut faire tout ce que le programme hôte peut faire. Les risques réels : (1) détournement de bibliothèque - un .so malveillant placé là où le chargeur cherche en premier, ou l'abus de LD_PRELOAD/LD_LIBRARY_PATH, peut injecter du code dans un programme légitime ; (2) téléchargement de fichiers .so individuels depuis des sites web aléatoires pour corriger une erreur - ceux-ci peuvent être malveillants ou incompatibles avec l'ABI et peuvent casser ou compromettre le système. Installez toujours les bibliothèques à partir des dépôts de paquets signés de votre distribution. La suppression de fichiers .so système (dans /lib, /usr/lib) peut rendre l'OS ou les applications inutilisables.
Détails du format
en brefProgrammes qui ouvrent les fichiers SO
macOS1 app
binutils / file / Ghidra
Open-source macOS utilise nativement .dylib, mais les fichiers .so de Linux peuvent être inspectés avec cross-binutils ou Ghidra. « file lib.so » confirme qu'il s'agit d'un objet partagé ELF. 
Linux4 apps
System dynamic linker (ld.so) + package manager
Intégré Vous n'« ouvrez » pas un .so - le chargeur l'utilise automatiquement. Pour corriger un fichier manquant, installez le paquet correspondant : « apt install libfoo » / « dnf install foo » / « pacman -S foo ». Utilisez « ldconfig » pour rafraîchir le cache.
binutils (nm / objdump / readelf)
Open-source Inspectez un .so en ligne de commande : « nm -D lib.so » liste les symboles, « readelf -d lib.so » montre le SONAME/dépendances, « objdump -d lib.so » désassemble.
ldd
Intégré « ldd ./programme » ou « ldd lib.so » liste les objets partagés nécessaires et si chacun est résolu - la première chose à faire pour une erreur de « .so manquant ».
Ghidra
Open-source Importez le .so pour un désassemblage/décompilation complet lors de l'ingénierie inverse de code natif (fonctionne aussi sur Windows/macOS). Détails techniques
spécifications approfondies| Type MIME | application/x-sharedlib |
| Octets magiques | 7F 45 4C 46 (« \x7FELF ») à l'offset 0 - signature identique à tous les fichiers ELF ; le champ e_type distingue les objets partagés |
| Valeur ELF e_type | ET_DYN (0x0003) - distingue un objet partagé d'un exécutable (ET_EXEC = 0x0002) ou d'un objet relogeable (ET_REL = 0x0001) |
| Bitness | Octet EI_CLASS à l'offset 4 : 1 = 32 bits (Elf32), 2 = 64 bits (Elf64) ; les deux variantes sont largement déployées sur Linux |
| Endianness | Octet EI_DATA à l'offset 5 : 1 = little-endian (ELFDATA2LSB), 2 = big-endian (ELFDATA2MSB) ; spécifique à l'architecture |
| Code indépendant de la position | Doit être compilé avec -fPIC pour que la bibliothèque puisse être projetée à n'importe quelle adresse virtuelle sans conflits de relocalisation entre les processus |
| Table des symboles dynamiques | La section .dynsym exporte et importe les symboles visibles à l'exécution ; .dynstr contient les chaînes de caractères des noms correspondants |
| PLT / GOT | La Procedure Linkage Table et la Global Offset Table permettent une résolution de symboles paresseuse (par défaut) ou immédiate (-z now) au moment du chargement |
| soname (DT_SONAME) | Nom canonique de la bibliothèque intégré dans la section dynamique ELF ; ld.so enregistre ce nom lors de la liaison d'un programme, permettant le suivi de version ABI indépendamment du nom de fichier |
| Versionnage des symboles | Les sections .gnu.version et .gnu.version_r permettent plusieurs versions de symboles dans un seul fichier, autorisant une évolution de l'ABI rétrocompatible |
| Éditeur de liens dynamique | Chargé par ld.so / ld-linux-x86-64.so.2 ; chemin de recherche contrôlé par LD_LIBRARY_PATH, DT_RUNPATH, ou /etc/ld.so.conf + cache ldconfig |
| Convention de nommage | lib<nom>.so[.majeur[.mineur.correctif]] ; libabc.so est typiquement un lien symbolique de développement → libabc.so.3 → libabc.so.3.1.2 |
| Chemin de recherche intégré | Les entrées dynamiques DT_RPATH ou DT_RUNPATH figent les chemins de recherche de bibliothèques dans le fichier lors de la liaison ; DT_RUNPATH est préféré car il peut être surchargé par LD_LIBRARY_PATH |
| Outils d'inspection | readelf -a, objdump -d, nm --dynamic (binutils) ; ldd pour le listage des dépendances ; la commande file identifie le type ELF et l'architecture |
| Publié | ELF format 1990s (System V Release 4); .so shared libraries are core to Linux/Unix |
| Standard ouvert | Oui · libre de droits |
| Spécification | refspecs.linuxfoundation.org |
Conversions SO
Q&R de la communauté
posées par les utilisateursPas encore de questions - soyez le premier à poser une question sur les fichiers SO.
