Prequals NDH 2k13 – Fappers Gonna Fap – Crypto 200 pts

Voici le write-up d'une des épreuves de crypto des prequals de la NDH 2k13. Au menu, du XOR, du format BMP et du Python ! 

Description

On nous fournit le fichier dafuq.bmp et un script python encrypt.py.

L'épreuve va consister à décoder l'image Bitmap qui a apparemment été chiffrée en utilisant le script python.

Analyse du script

On va regarder d'un peu plus près encrypt.py histoire de voir si on peut le reverse pour récupérer l'image d'origine.

Une classe BitmapFile est définie dans laquelle on trouve une fonction très intéressante :

On remarque que les données binaires de l'image sont xorées avec une clé de longueur 337 dont les valeurs des octets sont pris aléatoirement entre 0 et 255. L'algorithme n'est donc pas réversible mais il doit être possible de récupérer la clé en utilisant les caractéristiques du format BMP.

Récupération de la clé

La structure d'une image Bitmap est composée de plusieurs en-têtes et options en plus des données de l'image. On trouve notamment le Bitmap File Header et le DIB Header qui vont permettre de stocker des informations sur l'image.

On va alors pouvoir recomposer le File Header de l'image d'origine en utilisant notamment le fait que plusieurs champs sont communs à toutes les images BMP. Ensuite comme il s'agit d'un simple XOR il suffira de xorer les octets trouvés avec ceux de dafuq.bmp pour avoir le début de la clé (le File Header fait 14 octets).

Par exemple, on sait déjà que l'en-tête va commencer par les octets 42 4D qui sont en fait les caractères B et M. Le champ suivant qui occupe 4 octets contient la taille du fichier qui sera donc la même que dafuq.bmp c'est-à-dire 2993058 octets soit 2DABA2 en héxadécimal. Par ailleurs les données étant stockées en Little Endian on obtient A2AB2D00 pour ces 4 octets du File Header.

Les 4 octets suivants sont réservés et généralement à 0 et les 4 d'après représentent l'adresse de départ des données de l'image qui commencent habituellement après le File Header (14 octets) et le DIB Header (40 octets). On obtient donc la valeur 54 soit 36 en héxadécimal stockées sous la forme 36000000.

On arrive ensuite sur le premier champ du DIB Header qui est en fait invariable puisqu'il s'agit de la taille du Header soit 40 octets. On a donc la valeur héxadécimale 28 stockées sur 4 octets : 28000000.

Pour le moment, nous avons reconstruit les 18 premiers octets de l'image :

424DA2AB2D00000000003600000028000000

Nous pouvons donc d'ores et déjà les xorer avec les 18 premiers octets de l'image chiffrée pour obtenir le début de la clé.

Après avoir xoré tout ça, on obtient le début de clé suivant :

C31AD80D5C84E09149D9E19A79164A18338B

A ce stade, on sait que ça ne sert à rien de continuer à reconstruire les en-têtes car la clé est censé faire 337 octets ce qui est largement supérieur à la taille des en-têtes (54 octets).

Il va donc falloir utiliser le début de la clé pour en déduire le reste.

On peut légitimement supposer que les données de l'image d'origine contiennent par endroit des séquences de 0 qui une fois xorées avec la clé donneront des parties de la clé dans l'image chiffrée.

On va donc rechercher dans les données de l'image chiffrée toutes les occurrences de la séquence C31AD80D5C84E09149D9E19A79164A18338B.

On trouve de nombreuses occurrences de cette séquence dont 2 sont montrées au-dessus.

On constate qu'à chaque fois ces séquences sont séparées de 319 octets identiques ce qui nous donne des blocks de 337 octets soit la longueur de la clé utilisé lors du XOR.

On dirait bien qu'on vient juste de récupérer notre fameux « keystream ».

Décodage

On a tout ce qu'il faut pour décoder le fichier dafuq.bmp et obtenir l'image de départ.

On fait un petit script python qui va xorer les données binaires de dafuq.bmp avec la clé de 337 octets ci-dessous :

C31AD80D5C84E09149D9E19A79164A18338B1E78446DB8B8D25431071C320DE6231EBB0E882351217666AAB9209DD00AD142B10F45DE0AA522B3459A14523A5F01DC5ECC67F62584FB7064B7832AC9FC43CA8A299189F5818B8BE7970034600C3317A44883F7CB77060460FFE8048DF4CBF6AA60DCB73229BD0444504715614F43CE360B852B846D43B606B69F257672E02DAF7BC40554B5121A8A6D9AB933F28F8A9D95858CA7AFE947D63C979445B645DE920E9A7EE5F6F065AB7529E6DE1EDE9DFFA50F32632E4C9EE30E088238C106E385EA6C8B2296D7F485A171E7A8EE163B24E6BDCEF979490BF1839EA5773275D83D8583AFF2E6A5279A7DB36CBD1914B91389820E6576B84E832FFEC4184846E59980096FEBE28ED66FB08637D40530DCBE3AC481F38EEB04E00FB4F60F13B047343BC230F200C2419F4271E2584508BE3B56164F522060DA23D0DDCD97055C

On obtient alors l'image suivante :

On valide l'épreuve avec le flag : ecb_mode_is_weak_mofo

Liens

http://en.wikipedia.org/wiki/BMP_file_format