PNG: Toujours obèse 3/4 (Stéganographie) - 404CTF2022

Principe:
Décompresser un chunk IDAT pour récupérer une nouvelle image PNG avec le flag

Infos (cf menu latéral):
🚩 Flaggué! +991 points gagnés — 💾 Téléchargez les fichiers du challenge
404CTF{z71ll_0b3z3_&_st1ll_h4d_s3cr3tz_4_U}

Le challenge

On continue: il y a encore des données cachées dans l'image

Gros IDAT

Via pngsplit on voit que des chunk IDAT sont assez gros: la plupart font 8192 octets, l'un fait 2213 et un autre 312240
En comparant avec un PNG quelconque (ici, un de mes screens du challenge), il est cohérent d'avoir des chunks de 8192 bytes sauf le dernier, plus petit

On peut donc suspecter que les données excédentaires sont dans le chunk IDAT le plus gros, de 312240 bytes

Décoder le chunk

On prend alors ce chunk (extrait par pngsplit) et on cherche ce qu'il peut être

J'avais oublié de supprimer les 8 premiers bytes du chunk, qui sont sa taille et le IDAT

Je me suis demandé s'il s'agissait directement d'un IDAT utilisable dans un autre PNG, j'ai donc reconstruit un PNG avec sa signature, son IHDR, le IDAT et un IEND: rien

Si l'image résultante est grise, on notera quand même que le lecteur PNG n'a pas planté: on n'est donc pas trop loin de la vérité et le IDAT trouvé est un IDAT valide syntaxiquement

Je me suis aussi demandé s'il s'agissait d'un code type César, puisque 5B pouvait devenir MZ marquant un fichier exécutable, mais non

zlib

C'est alors que je me suis rappelé que les données d'un `IDAT` sont compressées : si je veux travailler avec, mieux vaut d'abord les décompresser (avec `pigz` par exemple)
En jetant un oeil aux données une fois décompressées, on repère immédiatement un IEND: aurait-on décompressé ce qui serait de nouveau un PNG?
En cherchant dans les données extraites, on retrouve en effet une signature PNG: il ne reste plus qu'à garder les données depuis la signature PNG jusqu'au IEND
Et on obtient un autre PNG valide

Flag: 404CTF{z71ll_0b3z3_&_st1ll_h4d_s3cr3tz_4_U}