Skip to content
shellcodes

Les octets nuls cassent encore les exploits en 2026

Pourquoi 0x00 coupe les chaînes, comment il se glisse dans les structs reverse TCP et comment contrôler les encodeurs.

Publié le 3 min de lecture

contraintes 0x00, troncature façon strcpy, scan des bad chars et effets secondaires des encodeurs ne sont pas des sujets abstraits. Ils apparaissent quand un lab autorisé sort de la démo propre et touche un vrai binaire cible, avec un vrai parser, un vrai chemin réseau et un rapport qui sera relu deux mois plus tard.

L'erreur fréquente consiste à faire confiance à un encodeur parce qu'il retire un nul alors qu'il introduit un retour ligne ou dépasse la taille disponible. Elle est banale, donc elle survit. Elle ressemble à une hypothèse non vérifiée dans le builder, une valeur reprise de l'interface VPN d'hier, ou une séquence d'octets copiée à travers un outil qui réécrit du texte.

Pourquoi ça compte dans un vrai lab

Le shellcode se joue à l'octet. L'exploit ne sait pas que l'interface avait l'air correcte. Il exécute les octets arrivés en mémoire. Si le payload traverse un shell, un formulaire web, un corps JSON, le scrollback du terminal ou un ticket, le problème n'est plus seulement le payload. C'est le payload plus chaque parser sur le trajet.

Je préfère les contrôles explicites à la confiance : taille attendue, octets interdits, OS cible, architecture, famille de payload, format d'export et hash final. Quand ça casse, les notes doivent réduire la recherche au lieu de créer un nouveau débat.

Un workflow qui résiste aux outils

Start from the smallest thing that proves the primitive. Then add constraints.


python3 check-null-bytes.py payload.bin

Cette commande n'est pas tout le workflow. C'est un point d'ancrage. Autour, conserve un blob connu, son SHA-256, et les réglages exacts du builder. Si tu changes LHOST, LPORT, l'ordre des encodeurs, la liste de bad chars ou le format d'export, considère le résultat comme un nouvel artefact.

Pannes à tester

Le motif de panne à surveiller est un payload exécuté seulement jusqu'au premier zéro, une longueur fausse dans le rapport, ou un exploit qui change après copier-coller. Teste-le avant l'intégration si possible. Un payload qui échoue dans un harness minimal coûte moins cher qu'un échec bruyant dans un environnement surveillé. Ne saute pas les contrôles de longueur. Les erreurs de taille sont discrètes : le payload ressemble encore à du shellcode, il ne rentre simplement plus dans la primitive disponible.

Ce que les défenseurs doivent voir

Côté défense, le générateur est rarement le signal principal. Le comportement l'est. Cherche les sorties réseau inattendues, parentés de processus étranges, transitions mémoire exécutables, buffers de taille payload et crashs répétés autour du même offset.

Notes de runbook

Stocke la configuration séparément des octets bruts quand la politique l'impose, mais garde assez de détail pour régénérer exactement. Un runbook utile contient la référence de scope, le contexte cible, les contraintes, le hash et une note courte sur le choix de la famille de payload. Pas de magie. Juste moins d'endroits où cacher les erreurs.

Articles associés

Des exemples de shellcode annotés pour Linux x86 et x64 — execve /bin/sh et reverse TCP — avec les octets, le désassemblage et les pièges.
Comment fonctionne un shellcode Linux — syscalls, registres et code indépendant de la position — et comment l'assembler, l'encoder et le tester sans risque.
Le shellcode expliqué : ce que c'est, pourquoi les exploits l'utilisent, comment il s'écrit et s'encode, et comment le générer et le tester sans risque dans ton navigateur.