Trop facile (Exp. Binaires) - 404CTF2022

Principe:
Débugger un exécutable pour trouver quelle entrée nous donnera un shell, et l'exploiter pour lire le flag

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

Le challenge

Le challenge nous demande d'exploiter un binaire pour en tirer le flag

edb

On lance le binaire dans un débuggeur, il nous demande une entrée, on met n'importe quoi

Dans edb, il vous faudra utiliser F8 pour avancer lorsque le programme se lance ("next instruction"). Si vous utilisez F9 ("Continue") alors l'exécution avancera jusqu'au fgets, attendra votre entrée, la lira et continuera immédiatement jusqu'au return, dépassant les deux cmp et vous louperez l'information essentielle.

Donc, favorisez le plus possible les "Step into" (utile en cas de call) et les step out si vous êtes déjà dans une lib.

On voit que l'entrée est comparée à deux valeurs binaires de 32 bits: 0xcafebebe et 0xdeadbeef

Ces valeurs m'ont fait marrer: Café bébé et Dead Beef! Ce sont d'ailleurs des valeurs qu'on retrouve dans des exemples sur internet

On prendra garde au endian, qui se voit dans le 0xefbeadde en dessous de la vue CPU!
On prendra aussi garde au fait que seule la fin de ce qu'on a entré est comparée à ce cafebebedeadbeef, les 5 lignes * 8chars précédents semblent ignorés

Script et exploit

On utilise ces valeurs dans un script, et on le teste sur notre exécutable local

On voit alors que le programme nous ouvre un /bin/bash (un shell) qu'on pourra exploiter pour lire le flag

On lance le script sur le challenge en ligne, et on obtient un shell qui nous permet de lire le flag

J'ai toujours galéré à livrer mes payloads pour les exploitations de binaires, car le shell se referme immédiatement généralement. Le pattern {cat payload.dat;cat} semble bien marcher pour éviter cela

Flag: 404CTF{C_7r0P_F4C113_D3_PWN_14_H411384rD3}