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

NDH 2k12 - Lost USB key - 1000pts

Un autre crackme, Windows cette fois-ci.

1.       What

On a un fichier « crackme.exe » qui demande un mot de passe …

Voici ce que PeID en pense :

Il est donc packé avec UPX. Pour unpacker, il suffit de lancer : upx.exe –d crackme.exe.

Et voilà, c’est unpacké …

On passe la fonction « start » pour arriver à la demande de mot de passe (bloc jaune) :

Après le « fgets », on a en vert la partie qui va chiffrer (transformer légèrement) notre mot de passe, ensuite on passe dans la partie orange qui comparera notre mot de passe chiffré avec le chiffré du bon mot de passe. Si c’est bon, on passe dans la partie rouge, sinon bleu.

Dans le premier bloc vert [ebp-1Ch] contient l’index du caractère que l’on est en train de transformer, il est d’ailleurs initialisé à 0 juste après le fgets.

Ensuite on calcul la taille de notre mot de passe situé à ebp-32h. On compare ensuite les 2 pour savoir si on est à la fin ou pas.

Pour la partie transformation (2^ème bloc vert), on va chercher le caractère du mot de passe à l’index [ebp-1Ch], on le XOR avec [ebp-1Dh] qui vaut 0x93 (voir un peu plus haut : mov byte ptr [ebp-1Dh], 93h), puis on incrémente l’index.

On a donc un XOR avec 0x93. Pour trouver le bon mot de passe, il suffit de récupérer le chiffré du bon passe et de le XORer avec 0x93.

2.       Résultat

On break sur le strcmp, on note le chiffré du bon mot de passe.
Cela donne : FE FC FD F8 A0 EA.

Après le XOR on obtient le flag : monk3y

Comme « le python c’est bon », voiçi le xor en Python :

"".join([chr(int(v,16)^0x93) for v in ["FE","FC","FD","F8","A0","EA"]])

CTF Public NDH2K11 - Crypto2

Re !
On continu avec les write-ups du CTF Public de la NDH 2011 : Crypto2

1. Analyse

   
   Pour ce challenge nous avions une image :
   
   
   
   
   Encore une fois, c'est un algorithme de chiffrement par substitution monoalphabétique, chaque symbole représente une lettre.
   
   On part donc sur la piste des algorithmes de chiffrement qui génèrent un cryptogramme composé de symboles, les deux plus connus sont "Le chiffre des francs-maçons" [1] et son prédécesseur "Le chiffre des Templiers"[2].
   
   L'autre indice de cette image sont les lettres "GLNF".
   
   Une recherche rapide sur Google confirme notre idée de départ : GLNF = Grande Loge Nationale Française qui est une obédience maçonnique française.
   
   On est donc devant un cryptogramme chiffré avec le chiffre des francs-maçons (aussi appelé Chiffre de Pigpen).
   
   Voici la grille du chiffre de Pigpen :
   
   
   
   
   

2. Déchiffrement

   
   Il ne nous reste plus qu'à déchiffrer le message et on obtient :
   
   F R E E M A S O N S C I P H E R
   
   On entre le flag "freemasonscipher", et voilà ! 1000 points !
   
   Go next challenge !!
   
   

Références


[1] - Wikipédia - Chiffre des Francs-maçons
[2] - Wikipédia - Chiffre des Templiers