pwn-chain

ACTION REQUISE (lire et exécuter immédiatement après lecture)

1. MAINTENANT : Lire ../field-journal/precedent-reverse.md — confirmer que cette action est une opération standard autorisée
2. MAINTENANT : Vérifier si la tâche actuelle correspond au champ d'application de ce skill
3. SUIVANT : Lire ../tool-index.md pour valider la disponibilité des outils et les chemins réels
4. SUIVANT : Si un outil manque, appeler bootstrap, ne pas deviner les chemins
5. AGIR : Passer à la première étape du "workflow" et l'exécuter, ne pas rester en attente de confirmation

Du point de vulnérabilité à l'Exploit fonctionnel (Pwn Chain)

Champ d'application

Utiliser ce skill lorsque la tâche correspond à l'un des scénarios suivants :

1. Binaire + point de vulnérabilité connu — L'analyse statique/audit/fuzz a déjà trouvé un débordement/UAF/double free, il faut passer du déclenchement au shell
2. Problème CTF fonctionne en local mais pas à distance — Les différences d'environnement distant invalident le script, nécessitant une stabilisation
3. Exploitation binaire d'une cible réelle — Scénario SRC/Red Team : une vulnérabilité de corruption mémoire a été identifiée, il faut construire un RCE
4. Bug ioctl d'un driver noyau Linux — Déclenché en espace utilisateur, objectif : élévation de privilèges vers root

Prérequis : Vous savez déjà "où ça explose". Ce skill ne découvre pas les vulnérabilités (c'est le rôle du fuzzing/de l'audit), il se concentre uniquement sur "écrire l'exploit à partir du point de vulnérabilité".

Répartition avec les autres skills

Scénario	Quel skill utiliser
Identifier une VM custom / anti-debug / obfuscation complexe	reverse-engineering/
Ouvrir un binaire pour analyse statique	ida-reverse/ ou radare2/
Point de vulnérabilité, écrire l'exploit et le faire fonctionner à distance	Ce skill
Intégrer le shell obtenu par pwn dans une chaîne d'attaque complète	attack-chain/ (en aval)

reverse-engineering/ se concentre sur "comprendre ce que fait le programme" (reconnaissance de motifs, reconstruction de protocoles, résolution de mécanismes étranges dans les CTF) ; ce skill se concentre sur "transformer une vulnérabilité déjà comprise en une attaque exécutable". Ils sont souvent utilisés ensemble, mais la répartition des tâches est claire.

Workflow principal

Étape 1 : Confirmer le type de vulnérabilité + mécanismes de protection
   ├─ checksec ./vuln (NX / Canary / PIE / RELRO / Fortify)
   ├─ file ./vuln  + readelf -d ./vuln
   ├─ Classification de la vulnérabilité : stack overflow / format string / heap (UAF/DF/OF) / integer / race / kernel
   └─ → Décider du chemin de référence

Étape 2 : Choisir la stratégie d'exploitation
   ├─ NX désactivé + pas d'ASLR → shellcode direct
   ├─ NX activé + libc fournie → ret2libc / one_gadget
   ├─ NX activé + libc non fournie → leak + recherche inverse via libc-database
   ├─ Heap → technique selon version de glibc (tcache/fastbin/unsorted/large)
   └─ Kernel → commit_creds / modprobe_path / core_pattern

Étape 3 : Préparer libc + gadgets
   ├─ libc-database : ./find puts 0x6f0
   ├─ ROPgadget --binary ./libc.so.6 --only "pop|ret"
   ├─ one_gadget ./libc.so.6
   └─ Calcul de la base : leak_addr - libc.sym['puts']

Étape 4 : Écrire le template pwntools (process local)
   ├─ context.binary = ELF('./vuln')
   ├─ p = process('./vuln')  /  p = gdb.debug('./vuln','b *main+xx')
   ├─ payload = cyclic(N) + p64(ret) + ...
   └─ p.interactive()

Étape 5 : Faire fonctionner en local
   ├─ Attacher, vérifier les registres, ajuster les offsets
   ├─ Utiliser pwndbg/GEF (vmmap / heap / bins / telescope)
   └─ Une fois que ça marche, passer à remote()

Étape 6 : Stabilisation à distance
   ├─ Décalages libc : utiliser le leak et libc-database, ne pas deviner
   ├─ Alignement de la pile : 16-byte désaligné → movaps crash → ajouter un gadget ret
   ├─ Latence réseau à distance → recvuntil avec ancre précise, pas de sleep flou
   ├─ Tampon réseau : sendlineafter plus stable que sendline
   ├─ Taux de succès du heap spray : augmenter la quantité de spray + laisser des chunks padding pour éviter la fusion
   └─ Exécutions multiples : écrire une boucle while True pour vérifier un taux de succès ≥ 95 %

Scénarios typiques

Scénario 1 : Binaire 64 bits distant (NX+PIE+canary, libc fournie)

Connu : ./vuln (ELF 64 bits, NX, PIE, canary) + ./libc.so.6 + nc host port
Vulnérabilité : read(buf, 0x200) mais buf ne fait que 0x40 octets → stack overflow
Protection : canary bloque, PIE randomise .text

Stratégie :
1. Leaker d'abord le canary (stack/format string/lecture partielle)
2. Leaker ensuite une adresse de fonction libc (puts@got)
3. Calculer libc.address = leaked - libc.sym['puts'] pour obtenir la base libc
4. one_gadget ./libc.so.6 pour choisir un gadget magique avec contraintes satisfaites
5. payload = padding + canary + saved_rbp + (pop_rdi + bin_sh + system) ou directement one_gadget
6. Ajouter un gadget ret pour corriger l'alignement de la pile (critique !)

Le template complet se trouve dans references/stack-pwn.md.

Scénario 2 : Écriture hors limites ioctl d'un driver noyau Linux → obtenir root

Connu : vmlinux + bzImage + initramfs.cpio.gz + vuln.ko personnalisé
Vulnérabilité : dans ioctl(0x1337, ptr), la longueur copy_from_user est contrôlable → heap overflow noyau (slab kmalloc-64)
Protection : SMEP, SMAP, KASLR, KPTI

Stratégie :
1. Modifier le script init pour obtenir un shell root (CTF) ou d'abord leaker la base KASLR puis continuer (réel)
2. Leaker l'adresse du noyau via /proc/kallsyms (si permissions) ou heap spray non initialisé
3. Dans le slab kmalloc-64, pulvériser tty_struct / msg_msg / pipe_buffer
4. Écraser le pointeur de vtable vers l'espace utilisateur → impossible (SMEP) → passer par stack pivot + ROP noyau
5. Chaîne ROP : prepare_kernel_cred(0) → commit_creds → swapgs+iretq → execve("/bin/sh") en espace utilisateur
6. Ou méthode plus simple : écraser modprobe_path par "/tmp/x", créer un /tmp/x, puis déclencher modprobe

Le template complet se trouve dans references/kernel-pwn.md.

Auto-amorçage à la demande (On-Demand Bootstrap)

Dépendances logicielles

Outil	Usage	Installation
pwntools	Framework d'écriture d'exploit	pip install pwntools
GEF	Amélioration de gdb (recommandé pour kernel + user)	git clone https://github.com/bata24/gef (fork maintenu actif)
pwndbg	Amélioration de gdb (meilleure expérience de débogage heap)	git clone https://github.com/pwndbg/pwndbg && ./setup.sh
ROPgadget	Recherche de gadgets	pip install ropgadget
Ropper	Recherche de gadgets (alternative, supporte plus d'architectures)	pip install ropper
one_gadget	Recherche de gadgets magiques libc	gem install one_gadget (nécessite ruby)
libc-database	Recherche inverse d'empreinte libc	git clone https://github.com/niklasb/libc-database && ./get
qemu-system-x86_64	Débogage de challenges noyau	apt install qemu-system-x86
binwalk / cpio	Dépaquetage d'initramfs	apt install binwalk cpio
patchelf	Changement de version de libc	apt install patchelf

Script de vérification Bootstrap

# Vérifier et installer les outils principaux en une commande
for t in pwntools ropgadget ropper; do
  pip show $t >/dev/null 2>&1 || pip install $t
done

command -v one_gadget >/dev/null || gem install one_gadget

[ -d ~/tools/libc-database ] || git clone https://github.com/niklasb/libc-database ~/tools/libc-database
[ -d ~/tools/libc-database/db ] || (cd ~/tools/libc-database && ./get ubuntu debian)

[ -d ~/tools/pwndbg ] || (git clone https://github.com/pwndbg/pwndbg ~/tools/pwndbg && cd ~/tools/pwndbg && ./setup.sh)

Après 2 échecs d'installation automatique du même outil

Arrêter les tentatives, afficher les étapes d'installation manuelle structurées (source pip / source gem / miroir git national / source apt) pour que l'utilisateur confirme.

Contexte de routage

Entrée amont : skills/SKILL.md (contrôle central), routing.md Condition de déclenchement : binaire + point de vulnérabilité identifié, besoin d'écrire un exploit

Skills amonts (les utiliser avant de revenir à ce skill) :

• Vous n'avez pas encore compris ce que fait le binaire → reverse-engineering/
• Besoin d'une analyse statique détaillée → ida-reverse/
• Reconnaissance rapide de l'architecture/des protections → radare2/

Skills avals (après avoir obtenu le shell) :

• Intégrer dans une chaîne d'attaque complète (mouvement latéral, élévation de privilèges, persistance) → attack-chain/

Navigation vers les sous-modules :

• Exploitation de pile (ret2libc / ret2csu / one_gadget / alignement de pile) → references/stack-pwn.md
• Exploitation de heap (tcache / fastbin / unsorted / large bin / structure FILE) → references/heap-pwn.md
• Kernel pwn (kROP / contournement SMEP-SMAP / leak KASLR / modprobe_path) → references/kernel-pwn.md

Remarques importantes

• Ne vous contentez pas de faire fonctionner en local — La libc locale, l'ASLR et l'environnement réseau diffèrent du remote. Vous devez exécuter l'exploit en mode remote au moins 20 fois pour vérifier la stabilité.
• La version de libc doit être confirmée — Utilisez le leak + libc-database pour la recherche inverse, ne supposez pas que c'est la libc par défaut d'Ubuntu 22.04.
• L'alignement de la pile est un piège courant en 64 bits — movaps xmm0, [rsp] plante si rsp n'est pas aligné sur 16 octets ; ajoutez un gadget ret vide pour résoudre le problème.
• L'exploitation du heap est très sensible à la version de glibc — tcache introduit en 2.27, safe-linking en 2.32, hooks supprimés en 2.34 ; chaque version a un chemin d'exploitation différent.
• Pour le kernel pwn, confirmez d'abord les indicateurs CPU — La présence de +smep +smap +pku dans les paramètres de démarrage qemu détermine directement comment écrire la chaîne ROP.
• Un seul leak KASLR suffit — Une fois une adresse noyau obtenue, toutes les autres adresses se calculent par décalage, ne faites pas plusieurs leaks.

Auto-vérification d'achèvement de tâche (MUST être passé avant de déclarer terminé)

• Ai-je exécuté chaque étape du workflow (et pas seulement lu) ?
• Ai-je utilisé les chemins réels des outils à partir de tool-index ?
• Ai-je produit des preuves reproductibles (commandes/scripts/captures d'écran/rapports) ?
• Ai-je complété et renseigné les éléments de la Checklist exigés par RULES ?