Nombre magique (programmation) - Définition

Introduction

En programmation informatique, le terme magic number (en français « nombre magique ») peut référer à :

• une constante numérique ou un ensemble de caractères utilisé pour désigner un format de fichier ou un protocole ;
• une constante numérique non-nommée ou mal documentée ;
• un ensemble de valeurs ayant un sens particulier (par exemple, les GUID).

Indicateur de format

Origine

Ce type de magic number est apparu dans les premières versions du code source de la version 7 d'Unix (en). Bien qu'il ait perdu son sens originel, le terme a subsisté dans le lexique de l'informatique.

Quand Unix fut porté sur le premier DEC PDP-11/20s, celui-ci n'avait pas de mécanisme de protection de la mémoire (en) et utilisait des références mémoires re-allouables (en). Ainsi, les versions avant la version 6 d'Unix (en) lisent un fichier exécutable dans la mémoire en sautant à l'offset 0. Avec le développement de la pagination, les versions suivantes d'Unix ont vu le développement des headers précisant les composants d'un fichier exécutable. Une instruction de saut placée au début du header a été developpée pour permettre d'exécuter le programme directement (sans lire le header) ; ce qui permet de choisir entre exécuter le programme en utilisant l'ancien mode utilisant des références mémoires réallouables (regular mode) ou en passant par la pagination. Avec le développement des formats d'exécutables, de nouvelles constantes de saut ont été ajoutées en incrémentant l'offset.

Dans le Lions' Commentary on UNIX 6th Edition, with Source Code (en) de la version 6 d'Unix, la fonction exec() lit l'image binaire d'un exécutable à partir du système de fichier. Les huit premiers octets forment le header qui contient la taille du programme (segment text) et les variables initialisées (segment global). Le premier mot de seize bits de ce header est comparé à deux constantes pour déterminer si l'exécutable utilise des références mémoires réallouables, le système de page en lecture seule récemment développé ou des pages séparées pour les instructions et les données. Dans les sixième et septième versions d'Unix, le double rôle de cette constante du début du header n'était pas précisé mais le bit de poids fort de cette constant était l'opcode de l'instruction de saut sur un PDP-11 (octal 000407 ou hex 0107). Si on ajoute sept au compteur de programme d'un programme exécuté, celui-ci va utiliser le service exec() pour se lancer.

Le service exec() lit le header du fichier exécutable (méta) depuis un buffer de l'espace noyau mais l'image exécutable est lue dans l'espace utilisateur et donc sans pouvoir utiliser la constante de saut. Les magic number ont alors été implémentés dans l'éditeur de liens et le chargeur d'Unix ; ils ont du être utilisés par la suite dans les programmes de test livrés avec les versions 6 et 7 d'Unix.

Dans la version 7, la constante n'est pas lue directement ; elle est d'abord assignée à la variable ux_mag et fut par la suite désignée par l'expression magic number. Sachant qu'il y avait alors dans cet Unix environ 10 000 lignes de code et beaucoup de constantes utilisées, ce nom est plutôt curieux pour une constante, au moins autant que le commentaire laissé dans la partie concernant le changement de contexte de la version 6 du gestionnaire d'applications d'Unix. C'est probablement pour cela que le terme a ensuite désigné le type d'exécutable, puis étendu aux systèmes de fichiers et étendu encore pour désigner un exécutable utilisant un typage fort.

Dans les données

Plusieurs de ces nombres sont issus d'un typage fort des données ou de leur multiplexage. Ils permettent aux programmes traitant l'information d'identifier les données qui suivent et notamment de distinguer le format de données utilisé.

Exemples

• Les fichiers binaires .class de Java commencent toujours par CAFEBABE. Décompressé avec Pack200 (en), le code se transforme en CAFED00D.
• Les images gif utilisent le code ASCII GIF89a (47 49 46 38 39 61) ou GIF87a (47 49 46 38 37 61).
• Les images JPEG commencent par FF D8 et finissent par FF D9. Les images JPEG/JFIF contiennent le code ASCII pour JFIF (4A 46 49 46) et se terminent par une chaîne de caractères vide. Les images JPEG/Exif contiennent le code ASCII pour Exif (45 78 69 66) et se terminent aussi par une chaîne nulle suivie d'autres métadonnées.
• Les images png commencent par une signature de huit octets : \211 P N G \r \n \032 \n(89 50 4E 47 0D 0A 1A 0A). Cette signature permet la détection de problèmes de transmission : vu qu'elle contient des sauts de ligne (« \n »), cela permet de détecter par exemple les sauts de fin de ligne ajoutés automatiquement lors d'un transfert en mode ASCII par ftp (au lieu d'utiliser le mode binaire).
• Les fichiers MIDI standards commencent par MThd (4D 54 68 64) suivi d'autres métadonnées.
• Les scripts Unix commencent toujours par un shebang « #! » (23 21) suivi par l'adresse de l'interpréteur de commandes à exécuter.
• Les fichiers et le programme PostScript commencent par « %! » (25 21).
• Les anciens exécutables .exe de DOS et les nouveaux portable executable de Microsoft Windows commencent par la chaîne MZ (4D 5A) ; ce sont les initiales du concepteur de ces formats, Mark Zbikowski (en). Le code ZM (5A 4D) est aussi possible mais il est plus rare.
• Dans le système de fichier UFS, les données des superblocks (en) sont repérées par les codes 19 54 01 19 ou 01 19 54 selon la version utilisée. Tous deux correspondent à la date de naissance de leur concepteur, Marshall Kirk McKusick.
• Le Master boot record des périphériques amorçables de toutes les machines IA-32 Compatible PC finit par AA 55.
• Les exécutables pour consoles portables Game Boy et Game Boy Advance commencent par une séquence de 48 et respectivement 156 octets qui correspond à l'encodage bitmap du logo de Nintendo.
• Les archives zip commencent par « PK » (50 4B), les initiales de Phil Katz qui est l'auteur de l'utilitaire de compression DOS PKZIP.
• Les exécutables pour Amiga (les Amiga Hunk (en)) exécutables sur Amiga classic 68000 commencent par la chaîne hexadécimale « $000003f3 » surnommée « Magic cookie ».
• Les premières versions de l'écran noir de la mort des Amiga – appelés aussi Guru Meditation qui surviennent lors d'une erreur non identifiable – affichent le code 48454C50 qui correspond en ASCII à « HELP » (48=H, 45=E, 4C=L, 50=P).
• La seule adresse absolue d'un système Amiga est $0000 0004 (emplacement adresse 4) qui contient le système d'amorçage « Sysbase », un pointeur vers exec.library, le noyau du système.
• Les exécutables PowerPC PEF (en) utilisés sur Mac OS et BeOS commencent par la chaîne ASCII de « Joy! » : 4A 6F 79 21.
• Les images TIFF commencent par II ou MM suivi par « 42 » (2A en hexadécimale) – en référence au livre de Douglas Adams La grande question sur la vie, l'univers et le reste – comme entier encodé sur deux octets en petit ou en gros-boutiste selon le type de processeur. « II » est utilisé sur Intel (petit-boutiste) ce qui donne le code 49 49 2A 00. « MM » est utilisé sur Motorola (gros-boutiste) : 4D 4D 00 2A.
• Les fichiers textes Unicode encodés en UTF-16 commencent généralement par une marque d'ordre des octets pour détecter l'endianness (FE FF pour les big-endian et FF FE pour les little-endian). Les fichiers UTF-8 commencent le plus souvent par EF BB BF.
• Les bytecodes pour LLVM commencent par BC (42 43).
• Les fichiers wad, utilisés par les jeux basés sur le moteur id Tech 2, commencent par WAD2 (Quake et dérivés) ou WAD3 (Quake II et dérivés).

Détection

Sous unix, la commande file permet de repérer le format d'un fichier à partir d'une signature. Il existe plusieurs projets tentant de les énumérer.

Dans les protocoles

• Le protocole OSCAR (en) utilisé par AIM/ICQ préfixe les requêtes par 2A.
• Dans le protocole RFB utilisé par VNC, le programme client commence par envoyer RFB (52 46 42) suivi par le numéro de version du protocole utilisé par le client.
• Dans le protocole SMB utilisé par Windows, chaque requête et chaque réponse du serveur commencent par FF 53 4D 42, c'est-à-dire en convertissant l'hexadécimal en ASCII : \xFFSMB.
• Dans le protocole MSRPC (en) de Windows, chaque requête TCP commence par 05 pour « Microsoft DCE/RPC Version 5 », suivi par 00 ou 01 pour le numéro de version mineur. Les requêtes UDP commencent toujours par 04.
• Les interfaces COM et DCOM sérialisées comme OBJREF (en) commencent toujours par « MEOW » (4D 45 4F 57). Les extensions de debugage utilisées par DCOM commencent par « MARB » (4D 41 52 42).
• Une requête non-cryptée d'un trackeur Bittorrent (en) commence par 13 (qui représente la longueur de l'entête), suivi par la phrase « BitTorrent protocol ».
• Les paquets eDonkey2000 et eMule ne faisant qu'un octet contiennent la version du client utilisée : à l'heure actuelle E3 représente un client eDonkey, C5 un client eMule et D4 un client eMule utilisant la compression.
• Les transactions SSL commencent toujours par le message « client hello ». Le schéma d'encapsulation des paquets SSL réserve deux ou trois octets pour l'entête. Généralement, un « client hello » d'un client SSL version 2 commence par 80 et la réponse d'un serveur version 3 à un client commence par 16 (mais cela peut varier).
• Les paquets DHCP utilisent un magic cookie 63 82 53 63 au début de la section option de tous les paquets. Ce nombre magique correspond à la séquence ASCII « ?R5? » (en traitant les valeurs hexadécimales comme des valeurs décimales), est défini dans la révision 5 du protocole BOOTP précurseur du DHCP.