Détecteur de magic bytes MIME | L'extension ment, les premiers octets non

Un fichier appelé config.exe qui est en réalité un ZIP. Un .png qui cache un polyglotte. Une pièce jointe report.pdf dont les quatre premiers octets sont 3C 3F 78 6D (<?xml). Le nom de fichier et l'en-tête Content-Type mentent ; les premiers octets d'un fichier (son nombre magique, ou file signature) ne mentent pas. Cet outil lit uniquement les 64 premiers octets d'un fichier déposé, entièrement dans ton navigateur, et les confronte à plus de 40 signatures — PNG, JPEG, PDF, conteneurs ZIP, MP4, ELF, PE, Mach-O, SQLite, WOFF — pour rapporter le vrai MIME.

💡 À propos de cet outil

Si tu as déjà écrit un endpoint d'upload de fichier, tu connais le piège. La version naïve refuse payload.exe et accepte image.png. La version un peu moins naïve regarde le Content-Type du multipart — mais c'est le client qui choisit cet en-tête, et un attaquant choisit allègrement image/png. La version sérieuse lit les premiers octets côté serveur et compare à la table des nombres magiques, ce que file(1) sous Linux et python-magic en Python font sous le capot.

Cet outil exécute exactement la même vérification, mais dans le navigateur. Le fichier déposé est lu avec FileReader.readAsArrayBuffer plafonné à 64 octets ; rien n'est uploadé, rien n'est hashé, aucune télémétrie. Les octets correspondants sont surlignés en vert dans la prévisualisation hex, et la règle de signature exacte est affichée — tu peux copier 89 50 4E 47 0D 0A 1A 0A directement dans une fixture de test ou une règle Snort.

Les conteneurs ZIP reçoivent une carte d'avertissement supplémentaire. PK\x03\x04 peut être un .zip plat, mais aussi .docx, .xlsx, .pptx, .odt, .epub, .jar, .apk ou .kmz — tous partagent le local-file header ZIP. Si tu n'as pas le fichier sous la main et seulement les premiers octets copiés d'un dump forensique, il y a le mode "coller hex" : tu colles FF D8 FF E0 et tu obtiens JPEG.

🧐 Questions fréquentes

Q. Pourquoi seulement 64 octets ? Presque toutes les signatures modernes tiennent dans les 16 premiers octets. Le format CD ISO 9660 est l'exception célèbre — sa signature vit à l'offset 0x8001 — mais si tu dois inspecter des images ISO dans un navigateur, il existe de meilleurs outils. Plafonner à 64 octets signifie aussi qu'une image disque de 1 Go est analysée en microsecondes, parce qu'on ne charge jamais le reste.

Q. Le résultat dit "ZIP container" — comment savoir lequel exactement ? Tu ne peux pas, à partir des seuls premiers octets. .docx, .xlsx, .pptx, .odt, .epub, .jar, .apk, .kmz et .zip lui-même partagent tous 50 4B 03 04. Ils diffèrent par les entrées de l'archive, pas par l'en-tête. Pour les distinguer, dézippe et regarde le premier listing : [Content_Types].xml est Office Open XML, META-INF/MANIFEST.MF est JAR, META-INF/CERT.SF est APK, et mimetype comme première entrée est ODT/EPUB.

Q. Est-ce qu'il détecte les fichiers polyglottes ? Pas comme une vérification dédiée. Le matcher parcourt la table de signatures et renvoie la première correspondance, donc un fichier simultanément valide comme PDF et JAR sera rapporté comme celui qui apparaît en premier dans la table. Le seul cas explicitement signalé est l'ambiguïté de conteneur ZIP (docx vs xlsx vs jar vs apk vs epub vs odt), via la carte d'avertissement. Pour de l'analyse polyglotte sérieuse, utilise binwalk ou file -k (keep going, ne pas s'arrêter à la première correspondance).

Q. Comment fonctionne l'alerte d'extension non concordante ? L'outil extrait le suffixe du nom avec la regex /\.([a-z0-9]{1,8})$/ et le compare à la liste d'extensions du format détecté. Si invoice.pdf produit 50 4B 03 04 (ZIP), tu obtiens un avertissement rouge .pdf vs .zip/.docx/.xlsx/.... Utile au moment où un dev frontend te passe "le PDF" et que curl répond application/zip.

Q. Est-ce qu'il détecte un fichier texte brut ? Le texte brut n'a pas de signature fixe, donc il tombe sur "aucune signature connue ne correspond". XML/SVG (<?xml), RTF ({\rtf) et Postscript (%!) sont détectés parce qu'ils commencent par des littéraux ASCII précis. Les BOM UTF-8/UTF-16 ne sont pas dans la table de signatures actuelle.

Q. Le fichier quitte-t-il ma machine ? Non. Les 64 premiers octets sont lus dans un Uint8Array local, ne sont jamais envoyés sur le réseau, et le handle du fichier est libéré dès que le résultat s'affiche. Tu peux le confirmer dans les DevTools : aucun fetch ni XHR n'est déclenché pendant la détection. Sûr pour analyser des pièces jointes suspectes que tu ne peux pas uploader ailleurs.

📚 Le saviez-vous

La référence la plus riche sur les signatures de fichiers reste la table de Gary Kessler, qui catalogue plus de 700 formats et que la plupart des auteurs de règles YARA citent. La liste Wikipedia "List of file signatures" est tenue à jour avec les conteneurs récents — le frame magic 28 B5 2F FD de ZSTD, le ftyp avif (66 74 79 70 61 76 69 66) à l'offset 4 d'AVIF, et les nouveaux profils EBML pour MKV/WebM. La curiosité la plus citée reste le Microsoft Compound Document D0 CF 11 E0 A1 B1 1A E1 — un demi-kilo-octet de structure sous cet en-tête apparaît à chaque ouverture d'un .doc ou .xls antérieur à 2007.

Côté francophone, l'ANSSI publie depuis 2018 des recommandations sur la vérification du type réel des fichiers dans les architectures d'upload (le document NT-MIME-1.0 et les guides RGS s'y réfèrent), et l'expression officielle française de "magic bytes" — qu'on peut traduire par "octets caractéristiques" ou "signature de fichier" — apparaît dans les fiches CERT-FR concernant les attaques par fichiers déguisés. Les outils français de DFIR comme DFF (Digital Forensics Framework, développé par ArxSys), ainsi que les modules de carving de plaso/log2timeline, s'appuient tous sur le même principe : la première ligne de défense contre un fichier malformé, c'est ce que disent ses premiers octets — pas ce que dit celui qui l'envoie.