DLL, Dylib, ELF, KO, EFI, SYS : les formats binaires système selon l'OS et le niveau de privilège

Ces six formats partagent un même rôle générique (du code binaire chargé par autre chose qu’un simple double-clic utilisateur) mais se distinguent par le système d’exploitation ciblé et surtout par le niveau de privilège auquel ils s’exécutent, du programme utilisateur ordinaire jusqu’au micrologiciel lancé avant même le système d’exploitation.

Format	OS	Conteneur binaire	Niveau d'exécution	Rôle typique
DLL	Windows	Portable Executable ("MZ")	Espace utilisateur	Bibliothèque partagée
Dylib	macOS	Mach-O	Espace utilisateur	Bibliothèque partagée
ELF (.so)	Linux/Unix	ELF ("\x7FELF")	Espace utilisateur	Exécutable et bibliothèque partagée
KO	Linux	ELF ("\x7FELF")	Noyau (anneau 0)	Module noyau (pilote)
SYS	Windows	Portable Executable ("MZ")	Noyau (mode noyau)	Pilote
EFI	UEFI (pré-OS)	Portable Executable ("MZ")	Avant le système d'exploitation	Bootloader

La DLL est la bibliothèque partagée standard de Windows : du code et des ressources chargés à la demande par un ou plusieurs programmes, au format Portable Executable, rigoureusement le même conteneur qu’un EXE, la seule différence se logeant dans un bit interne de l’en-tête PE plutôt que dans la signature de tête. Le Dylib joue exactement ce rôle sous macOS, mais avec un format binaire totalement différent : Mach-O, reconnaissable à son propre nombre magique, qui peut aussi encoder un binaire « universel » embarquant plusieurs architectures de processeur (Intel, Apple Silicon) dans un seul fichier.

L’ELF est à la fois le format des exécutables et des bibliothèques partagées (.so) sous Linux et la plupart des systèmes Unix : un même en-tête sert plusieurs sous-types de fichiers (exécutable, bibliothèque, fichier objet), distingués par un champ interne plutôt que par l’extension, souvent absente sur un binaire Linux. Le KO réutilise ce même conteneur ELF pour un usage radicalement différent : un module chargeable dynamiquement dans le noyau Linux lui-même (insmod/modprobe), qui ne se distingue pas par sa signature de tête, identique à celle de n’importe quel exécutable Linux. Le type ET_REL (fichier objet relogeable) ne suffit pas non plus, puisqu’un simple .o le porte aussi : ce sont les sections propres aux modules qui l’identifient, .modinfo (licence, auteur, dépendances, lue par modinfo) et .gnu.linkonce.this_module, que le noyau exige au chargement.

Le SYS est l’équivalent Windows du KO : un pilote qui, depuis Windows NT, est structurellement un exécutable PE partageant la même signature “MZ” qu’une DLL ou un EXE ordinaires. Comme le KO, il s’exécute avec les privilèges les plus élevés du système, ce qui explique l’exigence croissante de Microsoft en matière de signature numérique des pilotes depuis Windows 10.

L’EFI occupe un niveau à part : c’est le format du bootloader lui-même (bootmgfw.efi sous Windows, grubx64.efi pour GRUB), lancé directement par le micrologiciel UEFI avant même que Windows, Linux ou tout autre système d’exploitation ne démarre. Il reprend pourtant le même conteneur Portable Executable que la DLL et le SYS, avec la même signature “MZ” : seul le sous-système ciblé dans l’en-tête PE, et le jeu d’API des services de démarrage UEFI, le distinguent structurellement d’un exécutable Windows classique.

Le conteneur binaire ne dit donc presque rien du niveau de privilège réel d’un fichier système : DLL, SYS et EFI partagent tous les trois la signature “MZ” du Portable Executable malgré des rôles allant de la bibliothèque utilisateur au bootloader pré-démarrage, et ELF sert indifféremment à un exécutable Linux ordinaire ou à un module noyau. C’est cette ambiguïté qui rend un outil d’identification par signature binaire insuffisant à lui seul pour ces formats : seule une inspection plus poussée de la structure interne révèle le rôle exact du fichier.