Réparation d'en-tête : trouver l'octet erroné dans une signature PNG

Rétro-ingénierie & Exploitation Binaire Niveau 3/4 ~4 min 5 septembre 2026

Le défi

Un fichier récupéré sur un disque effacé porte un nom de PNG et est presque certainement un PNG, mais tous les décodeurs refusent de l'ouvrir. Le reste de la structure est intact : vous voyez les noms de blocs IHDR, gAMA et cHRM dans la colonne ASCII, les dégâts se limitent donc au tout début. Exactement un octet de la signature de huit octets a été altéré pendant la récupération. Comparez les premiers octets du fichier avec la référence des octets magiques, et trouvez l'octet qui ne correspond pas. Soumettez cet octet en hexadécimal : la valeur erronée que le fichier contient actuellement ou la valeur correcte qu'il devrait contenir sont toutes deux acceptées, car nommer l'une ou l'autre prouve que vous avez localisé la corruption. Ce qui n'est pas accepté, c'est la position.

Ce que tu vas apprendre

  • Comparer un en-tête de fichier à une signature d'octets magiques connue, position par position
  • Utiliser la colonne ASCII pour lire plus rapidement une signature imprimable
  • Comprendre que les octets magiques constituent un contrat de correspondance exacte, pas une heuristique
  • Distinguer un en-tête endommagé d'une corruption globale du fichier grâce à la structure qui suit
  • Retrouver la valeur d'origine d'un octet endommagé plutôt que de se contenter de le localiser

Compétences testées

Analyse de dump hexadécimalSignatures de formats de fichiersRaisonnement en récupération de données

Prérequis

  • Lecture de valeurs d'octets en hexadécimal
  • Savoir que les fichiers commencent par une signature de type

Comment ça marche

Presque tous les formats binaires commencent par une signature fixe, et un décodeur la traite comme un contrat. Il compare les octets exactement et refuse le fichier au moindre écart. Cette rigueur est une qualité, car elle empêche un analyseur de mal interpréter avec assurance un mauvais type de données, mais elle signifie aussi qu'un seul octet endommagé peut rendre inaccessible un fichier par ailleurs parfaitement intact.

La signature PNG fait huit octets : 89 50 4E 47 0D 0A 1A 0A. Elle est volontairement surdimensionnée. 0x89 a le bit de poids fort activé pour détecter un transfert qui supprimerait le huitième bit, 50 4E 47 épelle PNG en ASCII pour qu'un humain puisse le lire, et la fin 0D 0A 1A 0A détecte les conversions de fin de ligne et une gestion prématurée de la fin de fichier.

Ce fichier contient 89 51 4E 47 0D 0A 1A 0A. Sept octets correspondent. L'octet à la position 0x01 vaut 0x51 alors que 0x50 est requis, ce qui correspond à un seul bit inversé transformant P en Q, et la colonne ASCII l'affiche comme .QNG au lieu de .PNG. Tout ce qui suit la signature est intact, c'est pourquoi IHDR, gAMA et cHRM restent lisibles plus bas. Le fichier est bien un PNG : seule sa porte d'entrée est cassée. L'octet corrigé est 0x50.

Erreurs fréquentes

  • Soumettre la position au lieu de la valeur. L'octet endommagé se trouve à la position 0x01, mais la question demande la valeur qui doit s'y trouver, à savoir 50.
  • Comparer avec la mauvaise ligne de référence. La signature ZIP 50 4B 03 04 commence elle aussi par 50, un survol de la table peut donc vous ancrer sur le mauvais format. Comparez la ligne PNG complète.
  • Répondre PNG. Le type est déjà donné dans l'énoncé. Ce défi est une tâche de réparation, pas d'identification.
  • Suspecter 0x89. Il paraît anormal car il n'est pas imprimable, mais c'est bien le premier octet correct d'une signature PNG.
  • Supposer que tout le fichier est corrompu. Les noms de blocs plus loin prouvent que les dégâts se limitent à la signature.

Comment s'en protéger

Pour quiconque conçoit des outils qui ingèrent des fichiers, la leçon est que la vérification de signature doit être stricte à la frontière et informative dans les journaux.

  • Validez la signature complète et rejetez le fichier au moindre écart. Ne vous rabattez jamais sur l'extension du fichier quand les octets magiques ne correspondent pas.
  • Journalisez la position de l'octet fautif et la valeur attendue, pour qu'un ingénieur en récupération puisse réparer un en-tête sans diff manuel.
  • Stockez une somme de contrôle à côté des fichiers archivés pour détecter la corruption à l'écriture plutôt que des années plus tard lors d'une restauration.
  • Conservez dans vos outils des copies vérifiées des signatures de format au lieu de coder en dur des préfixes partiels, car une vérification PNG sur quatre octets aurait accepté plusieurs variantes endommagées.
  • N'oubliez pas le revers de la médaille : comme les signatures ne portent que sur les premiers octets, un attaquant peut préfixer un en-tête valide à un contenu hostile. Une vérification de signature établit le format, pas l'innocuité.

Solution complète

Les membres Pro et Max débloquent la solution complète étape par étape.

Passer Pro

Statistiques de la communauté

138 résolutions
87% taux de réussite
Hodanalo Premier sang

Hacks du jour associés

28 000+ Hackers 100+ Labs & Cours Gratuit
Commencer Gratuitement