Aujourd'hui on s'attaque au challenge "Mistake" de pwnable.kr. Disponible ici.

Comprendre le code

Composition du code

Comme on peut le voir, le code est composé de 4 parties distinctes.

- En rouge: La fonction en charge de récupérer le password dans le fichier éponyme.

- En jaune: La fonction en charge de vérifier que la lecture du password c'est effectuée correctement.

- En cyan: La fonction en charge de récupérer l'entrée utilisateur.

- En bleu: La fonction en charge de faire un XOR avec notre entrée et le comparer avec le password récupéré dans la fonction en rouge.

A la recherche d'indices

Si on fait attention aux entêtes du début du code, on remarque quelques indices, comme la clé utilisé dans le xor et la longueur du password à trouver
On doit donc chercher une erreur de programmation en relation avec la priorité des opérateurs

La fonction coupable

On pourrait logiquement penser qu'à première vue, le problème réside dans le code de la fonction XOR mais il n'en est rien.

La gestion de l'ouverture d'un fichier. D'ailleurs si l'on fait attention à l'exécution du programme on peut remarquer quelque chose d'étrange.

$ ./mistake 
do not bruteforce...
my_input1
input password : my_input_2
Wrong Password
Comme vous pouvez le voir, il demande deux fois des informations, hmmmm.

Le problème réside dans le second bout de code, celui qu'on ne pense jamais à vérifier:

Le code fautif

En se documentant un peu sur la priorité des opérateurs, on apprend que l'opérateur < et prioritaire sur l'opérateur =.
Ce qui implique dans ce code que, puisque open() renverra forcément une valeur positive représentant le plus petit nombre non utilisé comme file descriptor, alors la comparaison vaudra toujours 0. Ce qui veut dire que le fichier lu par le programme sera toujours le clavier (puisque le stdin = 0).

Le code se poursuit avec ces lignes:

Le programme copie donc l'entrée depuis stdin dans le buffer pw_buf. Ensuite pour chaque caractère de la seconde entrée (pw_buf2) on fait un XOR avec 1 comme clé.
Enfin les 2 buffers sont comparés.

Donc si on trouve une combinaison où le premier caractère XORed avec 1 , sera égale au second, alors on sera capable de bypasser cette protection.

NB: Les valeurs à entrées seront converties en leur équivalent ASCII.

On va donc utiliser 1 et 0 qui ont pour équivalent ASCII 61 et 60.

Et voila un challenge de résolu !

Social et Media

Comme toujours je suis disponible sur Twitter et cie, si vous avez des questions, des remarques, des suggestions etc. N’hésitez pas !

Twitter: @GhostAgs

Discord: hackraw