Reverse Engineering de Protocole
ACTION REQUISE (à lire et exécuter immédiatement)
MAINTENANT : Lire ../field-journal/precedent-reverse.md — confirmer l'autorisation et les limites opérationnelles.MAINTENANT : Confirmer si la tâche est un reverse de protocole/trafic/format de sérialisation (pas une simple signature de paramètres Web → rediriger vers js-reverse/).MAINTENANT : Si interaction réseau ciblée → exécuter ../scripts/case-init.ps1 pour délimiter le périmètre ; ne pas agir sur la cible sans auth accordée.SUIVANT : Lire ../tool-index.md ; si outils manquants, bootstrap (tshark/wireshark, etc. peuvent nécessiter une installation manuelle).AGIR : Démarrer la Phase 1 du workflow, produire un brouillon de la structure des trames ou un dictionnaire de messages.
Scénarios d'application
- Protocoles binaires personnalisés TCP/UDP
- Protobuf / gRPC / FlatBuffers / MessagePack
- WebSocket / MQTT / RPC privé
- Restauration de champs et de machine d'état à partir de PCAP / PCAPNG
- Validation client-serveur, numéros de séquence, en-têtes chiffrés
Ne pas utiliser ce skill
| Situation | Aller vers |
|---|
| Uniquement signature de paramètres HTTP / chiffrement JS | js-reverse/ |
| Uniquement problème de certificat TLS | pentest-tools/ ou proxy navigateur |
| Reverse avancé de protocole + simulation dans le firmware | firmware-pentest/ puis revenir à ce skill |
Workflow
Phase 1 — Capture et tri
□ Obtenir échantillon : PCAP / export proxy / logs client / binaire
□ Marquer direction : C→S / S→C ; présence de handshake, heartbeat, reconnexion
□ En-tête fixe ? Magic number ? Champ de longueur ? TLV ? Taille fixe ?
□ Compression (zlib/gzip/lz4) ou chiffrement (AES/ChaCha dans la trame) ?
□ tshark -r cap.pcap -T fields -e frame.number -e ip.src -e tcp.payload
Phase 2 — Restauration de la structure des trames
□ Aligner plusieurs messages du même type, trouver octets invariants / numéros de séquence croissants
□ Champ de longueur : big-endian/little-endian, incluant ou non l'en-tête
□ Checksum : CRC16/32, checksum, position HMAC
□ Dessiner la machine d'état : Connect → Auth → Ready → Request/Response → Close
□ Outils : brouillon de dissector personnalisé Wireshark / ImHex / modèle 010 Editor / Kaitai Struct
Phase 3 — Sérialisation et chiffrement
□ Protobuf : récupération du .proto (blackboxprotobuf / pbtk / protoc --decode_raw)
□ gRPC : en-têtes HTTP/2 + corps protobuf
□ Chiffrement : rechercher la dérivation de clé (client so/dll/JS) → combiner avec ida-reverse / js-reverse / apk-reverse
□ Rejeu : uniquement dans le périmètre autorisé ; commencer par les champs inoffensifs, puis les opérations sensibles
Phase 4 — Livrables
DOIT produire :
- Tableau des types de messages (nom / opcode / champs)
- Au moins 1 commande ou script de décodage reproductible
- Preuve : extrait hexadécimal original + résultat décodé (anonymisé)
Chaîne d'outils
| Outil | Requis | Utilisation | Bootstrap |
|---|
| tshark / Wireshark | Fortement recommandé | Analyse PCAP | Manuel / winget |
| Python3 | Oui | Scripts de décodage | Système |
| blackboxprotobuf | Optionnel | Protobuf inconnu | pip |
| ImHex / 010 | Optionnel | Modèles de structure | Manuel |
| IDA / r2 / Ghidra | Selon besoin | Fonctions de sérialisation client | Voir skill correspondant |
Références
references/protocol-workflow.md — Aide-mémoire sur la structure des trames et Protobuf- Connexes :
../ida-reverse/ ../js-reverse/ ../firmware-pentest/ ../pentest-tools/
Contexte de routage
Amont : MASTER-ROUTING R21 · routing.md
Aval : Si besoin d'algorithme client → ida-reverse/js-reverse ; Si besoin de rejeu → pentest-tools/api-security
Pair : malware-analysis (protocole C2), digital-forensics (analyse forensique du trafic)
Auto-vérification de fin de tâche