SOS Raid 2/2 (Forensics) - 404CTF2022

Principe:
Corriger le fichier PNG corrompu (0x0A, CRC32, chunck lengts) issu du challenge 1/2 pour y trouver le flag

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

Le challenge

0x0A vs 0x00 ?

En affichant un PNG non-corrompu et le corrompu via `xxd`, on voit que des `0d0a` (CRLF) sont devenus `0d00`

IHDR

Si l'IHDR n'avait pas été similaire au PNG "Capture d'écran", sa longueur n'aurait pas été bonne et on aurait donc dû compter les octets pour respecter la spécification du W3C pour le format PNG

CRC32

pngcheck étant assez sympa, il nous dit le CRC attendu. On va donc considérer que les données sont correctes, et que le CRC32 dans le fichier est faux. On remplace donc (sed) le CRC32 erroné par le CRC32 correct que pngcheck nous donne

On peut aussi patcher le fichier à la main comme avant

Le problème, c'est que l'image plantera encore ensuite. En effet, il faut inverser l'approche: le CRC32 est correct, mais les données du IHDR sont corrompues. Le champ f288 indique la largeur de l'image, qui semble bien trop grande!

En brute-force ou en calcul, on trouve une valeur correspondant au CRC32: `0288` soit 648 pixels

EOF

En relançant `pngcheck` on a encode une error: un EOF dans le chunck IEND

Dans le fichier PNG, le chunck `IEND` est précédé de `00 0000 ad`

D'après la spec, ce nombre représente la longueur du chunk, qui (pour ce IEND) est de `0` puisque le chunck ne contient aucune donnée. Donc, on patch `00 0000 00`

Flag

Apparemment, Ubuntu n'a pas de problème à ouvrir le PNG même avec un IEND corrompu. On aurait donc pu se passer du dernier patch, mais bon, autant faire propre!

Flag: 404CTF{L4_C0rr_pt10N_s3_r_p4r_}