Préfixes Base64 courants : reconnaître un fichier à son début

Tableau des préfixes

Chaque ligne a été vérifiée en encodant les vrais octets magiques du format. Le « préfixe stable » est la partie qui ne change jamais pour ce format. Les caractères qui suivent dépendent du reste du fichier.

Quelques lignes méritent une remarque :

• RIFF est un conteneur. Le nom du format se trouve aux octets 8 à 11, et les octets 9 à 11 s’encodent dans les caractères 13 à 16 : RUJQ pour WebP (EBP), QVZF pour WAV (AVE), Vkkg pour AVI (VI ). La première lettre du nom du format partage un groupe de 3 octets avec la taille du fichier : elle ne produit donc pas de caractère stable.
• zlib n’a pas de préfixe unique. Le second octet indique le niveau de compression : eJ pour le niveau par défaut, eN pour les niveaux 7 à 9, eF pour 2 à 5, eA pour 0 et 1 (tels que les écrit le module zlib de Python).
• JSON ne commence par eyJ que si les deux premiers caractères sont {" sans espace. { "a": 1 } commence par eyAi, un { formaté suivi d’un saut de ligne commence par ewo, et un tableau [ commence par W.
• Les structures DER commencent par une balise SEQUENCE 30, qui donne toujours M. Une longueur sur deux octets (30 82) donne MII, et le caractère suivant dépend de la longueur : une clé publique RSA 2048 donne MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA, un certificat typique MIIC, MIID ou MIIE. Les structures courtes utilisent une longueur sur un octet : une clé privée Ed25519 commence par MC4C, une clé publique P-256 par MFkw.
• Les clés publiques SSH commencent par une longueur big-endian de 4 octets : le blob commence donc par AAAA. Les caractères suivants épellent le type de clé : AAAAC3NzaC1lZDI1NTE5 correspond à ssh-ed25519, AAAAB3NzaC1yc2E à ssh-rsa, AAAAE2VjZHNh à ecdsa. En dehors de SSH, une suite de A signifie des octets nuls.
• Les fichiers MP3 sans balise ID3 commencent directement par un en-tête de trame. Ses bits de synchronisation FF Fx donnent un // en tête, par exemple //uQ pour FF FB 90.
• Base64URL remplace + et /, et le préfixe JPEG devient donc _9j_. Les autres préfixes du tableau ne contiennent aucun de ces caractères et sont identiques dans les deux alphabets.

Pourquoi le préfixe est stable

Base64 travaille par groupes de 3 octets. Chaque groupe de 3 octets devient exactement 4 caractères, et ces 4 caractères ne dépendent que de ces 3 octets. Rien de ce qui vient plus loin dans le fichier ne rejaillit en arrière. Si un format commence toujours par les mêmes 3 octets, son Base64 commence donc toujours par les mêmes 4 caractères.

bytes:   FF       D8       FF
bits:    11111111 11011000 11111111
groups:  111111 111101 100011 111111
index:   63     61     35     63
chars:   /      9      j      /

Quand la signature fixe ne fait pas un multiple de 3 octets, le dernier groupe mélange des bits connus avec des bits du reste du fichier. Prenons %PDF- et ses 5 octets. Les 3 premiers octets donnent 4 caractères stables (JVBE). Les 2 suivants en donnent 2 de plus (Ri), et le septième caractère mélange les 4 derniers bits de - avec les 2 premiers bits du chiffre de version. Tout chiffre commence par les bits 00 : en pratique, ce caractère vaut donc toujours 0. Après JVBERi0, la version transparaît : JVBERi0xLjQ correspond à %PDF-1.4, JVBERi0xLjc à %PDF-1.7, JVBERi0yLjA à %PDF-2.0.

La signature PNG fait 8 octets, ce qui donne 10 caractères stables. Le onzième mélange le dernier octet de la signature avec le premier octet de la longueur du bloc IHDR, qui vaut toujours 0 : iVBORw0KGgo tient donc. Comme tout PNG continue avec ce bloc IHDR, les vrais PNG partagent un préfixe encore plus long : iVBORw0KGgoAAAANSUhEUg.

Quand le préfixe se décale

Le préfixe ne fonctionne que si les octets magiques se trouvent à la position 0, 3, 6, etc. Ajoutez un octet devant et tous les groupes se décalent : les caractères changent complètement.

Avec 3 octets de plus, l’alignement est rétabli et le préfixe familier réapparaît 4 caractères plus loin. Causes fréquentes d’un préfixe décalé ou absent :

• Une marque d’ordre des octets (BOM). Du texte UTF-8 avec BOM commence par 77u/ (EF BB BF). Le BOM fait 3 octets : du JSON placé après montre donc toujours eyJ, soit 77u/eyJ…. Du texte UTF-16 avec BOM commence par //4 ou //5 (little-endian) ou par /v8 (big-endian).
• Du texte UTF-16. Du texte enregistré en UTF-16LE place un octet nul après chaque caractère ASCII, ce qui produit beaucoup de A : Hello devient SABlAGwAbABvAA==. Le -EncodedCommand de PowerShell ressemble à cela. Utilisez le décodeur PowerShell ou Base64 en UTF-16.
• Une compression ou un chiffrement. Un PNG compressé en gzip commence par H4sI ; un fichier chiffré n’a aucun préfixe reconnaissable.
• Une data URI. data:image/png;base64, est un en-tête ; le Base64 commence après la virgule. L’analyseur de data URI sépare les deux pour vous.
• Des sauts de ligne et des espaces. Ils ne décalent pas les octets, mais une recherche de préfixe avec startswith échouera si la chaîne commence par un saut de ligne ou un guillemet. Nettoyez d’abord, ou passez-la dans Réparer du Base64.

Vérifier un préfixe dans le code

Vous pouvez comparer les premiers caractères comme des chaînes, mais comparer les octets décodés est moins sujet aux erreurs : les nombres magiques viennent directement de la spécification de chaque format, et vous n’avez jamais à calculer quels caractères sont stables. Décoder seulement les 12 premiers caractères donne les 9 premiers octets, ce qui suffit pour la plupart des signatures :

import base64

SIGNATURES = {
    b"\x89PNG\r\n\x1a\n": "png",
    b"\xff\xd8\xff": "jpeg",
    b"%PDF-": "pdf",
    b"PK\x03\x04": "zip",
    b"\x1f\x8b": "gzip",
}

def sniff(b64: str) -> str:
    head = base64.b64decode(b64.strip()[:12])
    for magic, name in SIGNATURES.items():
        if head.startswith(magic):
            return name
    return "unknown"

print(sniff("iVBORw0KGgoAAAANSUhEUgAAAAEAAAAB"))  # png
print(sniff("JVBERi0xLjcKJcfsj6IK"))              # pdf

L’outil Base64 en fichier fait la même vérification avec une liste plus longue et affiche un aperçu quand le navigateur sait afficher le format. Pour voir comment les groupes de 6 bits correspondent aux caractères, consultez le fonctionnement de Base64 et la table de l’alphabet.

FAQ