L'exploitation binaire peut sembler de la magie noire jusqu'au moment où l'on réalise qu'il s'agit simplement d'un débogage rigoureux et d'un modèle mental clair de la mémoire. Ce guide approfondi décompose les fondamentaux en s'appuyant sur des leçons tirées de projets de style CTF réels (Over-Ride, Rainfall et Snow-Crash) ainsi que sur des références classiques concernant la pile, les conventions d'appel x86, les chaînes de format et le ret2libc.

Introduction

Avez-vous déjà vu un programme planter et vous être demandé : « Pourquoi est-il mort là ? » Cette question est le point de départ de l'exploitation binaire. Une fois que l'on comprend la pile, les registres et la disposition de la mémoire, les plantages deviennent des comportements explicables, corrigeables et testables.

À la fin de ce guide, vous comprendrez les concepts fondamentaux de l'exploitation binaire, les classes de vulnérabilités les plus courantes, et comment les défenses modernes façonnent la stratégie d'exploitation. Vous obtiendrez également un parcours d'apprentissage sûr et pratique basé sur des défis structurés.

Si vous débutez, commencez par les débordements de pile et les flux de travail de base du débogueur avant de passer au tas et aux chaînes de format.

Comment les frames de pile et les conventions d'appel expliquent les plantages.
Les principales classes de vulnérabilités à l'origine des exploits réels.
Comment les défenses telles que NX et ASLR modifient votre approche.

Fondamentaux de l'Exploitation Binaire (10 Idées Clés)

1) La Pile N'est Que de la Mémoire (LIFO)

La pile est une région mémoire qui croît vers le bas. Elle stocke les arguments des fonctions, les variables locales et les adresses de retour.

Conseil pratique : Inspectez toujours le pointeur de pile et le pointeur de base après un plantage.

Exemple : Dans les premiers niveaux d'Over-Ride, un plantage à une adresse inattendue signifie souvent que l'adresse de retour a été écrasée.

Conseil actionnable : Entraînez-vous à lire les frames de pile dans un débogueur jusqu'à ce que la disposition vous semble naturelle.

2) Les Registres et les Conventions d'Appel Expliquent la Plupart des Plantages

Les registres comme EIP, ESP et EBP définissent le flux de contrôle et les limites des frames. Connaître la convention d'appel vous indique où se trouvent les arguments et les adresses de retour.

Conseil pratique : Suivez EIP/RIP, ESP/RSP et EBP/RBP à chaque plantage.
Exemple : Le prologue x86 (push ebp; mov ebp, esp) ancre les variables locales et les adresses de retour.
Conseil actionnable : Dessinez un diagramme de frame rapide pour chaque fonction que vous analysez.

3) La Disposition de la Mémoire Est Votre Carte

Comprendre où se trouvent le code, les données, le tas et la pile vous aide à déterminer où une entrée atterrit et ce qu'elle peut affecter.

Conseil pratique : Demandez-vous toujours « pile, tas ou global ? »
Exemple : Rainfall passe des débordements de pile à la corruption du tas, forçant une stratégie différente.
Conseil actionnable : Esquissez la carte mémoire de chaque défi avant de tenter quoi que ce soit.

4) Les Débordements de Tampon de Pile Sont la Porte d'Entrée

Les débordements se produisent lorsqu'un programme écrit plus de données qu'un tampon de pile ne peut en contenir. Ces données supplémentaires peuvent atteindre l'adresse de retour sauvegardée.

Conseil pratique : Recherchez les fonctions non sécurisées comme gets, strcpy ou scanf sans vérification.
Exemple : Les premiers niveaux de Rainfall montrent comment une entrée trop grande écrase le pointeur de retour.
Conseil actionnable : Mesurez l'offset exact entre le début du tampon et l'adresse de retour.

5) Les Bugs de Chaîne de Format Fuient et Écrivent en Mémoire

Un appel direct comme printf(buffer) donne aux attaquants le contrôle sur la façon dont la pile est lue et même écrite avec %n.

Conseil pratique : Traitez les chaînes de format contrôlées par l'utilisateur comme des bugs critiques.
Exemple : Rainfall utilise des chaînes de format pour altérer l'état global sans toucher la frame de pile.
Conseil actionnable : Entraînez-vous à trouver l'offset d'argument en utilisant des marqueurs de pile (ex. : AAAA).

Tous les exploits ne consistent pas à écraser directement la mémoire. Parfois, le bug réside dans la logique arithmétique et de validation.

6) Les Bugs Entiers Sont des Exploits Déguisés

Les conversions signées/non signées, les débordements et les erreurs de limite peuvent contourner les vérifications et créer des tailles de copie non sécurisées.

Conseil pratique : Toute multiplication ou cast utilisé dans les vérifications de longueur est un signal d'alarme.
Exemple : Les défis bonus de Rainfall illustrent le bouclage des entiers menant à des copies surdimensionnées.
Conseil actionnable : Testez des valeurs négatives et extrêmes dans tout chemin de validation de taille.

7) La Corruption du Tas Change la Stratégie

Les bugs de tas nécessitent souvent de comprendre l'ordre d'allocation, la disposition des objets et la façon dont les métadonnées peuvent être corrompues.

Conseil pratique : Suivez la taille d'allocation et l'adjacence lors de l'exploration des problèmes de tas.
Exemple : Les niveaux avancés de Rainfall montrent le flux de contrôle basé sur le tas via la corruption d'objets et de pointeurs.
Conseil actionnable : Reproduisez la disposition du tas de manière fiable avant de tenter une analyse plus approfondie.

8) ret2libc Est une Réponse à NX

Lorsque la pile est non exécutable, vous pouvez rediriger le flux de contrôle vers du code exécutable existant dans libc.

Conseil pratique : Étudiez comment les arguments sont placés sur la pile pour les appels de fonctions.
Exemple : ret2libc construit une frame de pile qui appelle system("/bin/sh") sans shellcode.
Conseil actionnable : Associez les défenses (NX, ASLR, canaries) à la technique qu'elles vous forcent à apprendre.

Une fois que les mécaniques de base ont du sens, les CTF structurés sont le moyen le plus rapide de développer l'intuition.

9) Les CTF Enseignent la Progression

La véritable compétence vient de défis progressifs qui construisent l'intuition par couches.

Over-Ride : débordements de pile, chaînes de format, manipulation GOT.
Rainfall : exploits de pile, de tas, d'entiers et d'objets C++.
Snow-Crash : artefacts mixtes (binaires, scripts, pcaps) et failles logiques.

Conseil actionnable : Traitez chaque niveau comme un rapport de laboratoire. Enregistrez le type de bug, la région mémoire et l'impact sur le flux de contrôle.

10) Transformez les Plantages en Connaissance

L'objectif n'est pas « obtenir un shell ». C'est comprendre pourquoi le programme se comporte de cette façon.

Conseil pratique : Après chaque plantage, rédigez un résumé en 3 lignes :
1) Type de vulnérabilité, 2) région mémoire, 3) impact sur le flux de contrôle. Conseil actionnable : Cette habitude transforme les tentatives aléatoires en véritable compétence.

Conclusion

L'exploitation binaire est moins une question de trucs que de fondamentaux : mécanique de la pile, conventions d'appel, disposition de la mémoire et raisonnement rigoureux. Une fois ces éléments clairs, chaque plantage raconte une histoire.

Over-Ride, Rainfall et Snow-Crash offrent une progression claire des débordements de base vers une corruption mémoire plus profonde. Utilisez-les comme des laboratoires structurés et documentez chaque leçon apprise.

Explorer les Projets

Plongez plus profondément avec les dépôts complets : Over-Ride, Rainfall et Snow-Crash.