Déchiffrer la note de rançon : XOR un octet sous base64
Le défi
Un rançongiciel a déposé un fichier de « note » en base64 sur un poste infecté. L'échantillon du déchiffreur montre que la note a été brouillée par un XOR à un seul octet avant d'être encodée en base64. Trouvez l'octet, retirez les deux couches, et soumettez le flag récupéré (HDNA{...}).
Ce que tu vas apprendre
- Reconnaître le base64 comme couche de transport externe d'un artefact déposé
- Identifier un XOR à un seul octet et raisonner sur son espace de 256 clés
- Récupérer le texte en clair en appliquant un XOR avec l'octet clé 0x42
- Retirer deux transformations empilées dans le bon ordre inverse
- Expliquer pourquoi un XOR à un seul octet n'offre aucune confidentialité réelle
Compétences testées
Prérequis
- À l'aise avec le base64
- Comprendre que le XOR est sa propre inverse
- Savoir qu'un octet a 256 valeurs possibles
Comment ça marche
Un XOR à un seul octet applique la même clé d'un octet à chaque octet des données. C'est le « chiffrement » le plus simple qui soit, et sa faiblesse tient à son espace de clés : il n'existe que 256 clés possibles, donc un analyste peut toutes les essayer en une fraction de seconde et garder celle dont le résultat ressemble à du texte. Les rançongiciels et les droppers l'utilisent non pas pour la sécurité, mais pour que leur note échappe à un simple dump strings, puis encapsulent le résultat en base64 pour que les octets survivent à l'écriture dans un fichier.
Retirez les couches dans l'ordre inverse. La note déposée est du base64 imprimable, donc décodez-la d'abord pour obtenir les octets bruts brouillés par le XOR. Appliquez ensuite un XOR sur chaque octet avec la clé. Le XOR est symétrique, donc la même opération avec la même clé l'annule, car A XOR B XOR B = A. Ici, l'échantillon du déchiffreur révèle que la clé est 0x42, la lettre ASCII B. Même sans cet indice, une recherche exhaustive sur un seul octet la révélerait immédiatement.
Dans l'atelier, ajoutez From Base64, puis XOR avec la clé B (ou 0x42), et la note se résout en direct dans la sortie. Les autres opérations (hex, ROT, atbash, reverse, Vigenere, URL-decode) sont des leurres dont les formats d'entrée ne correspondent jamais aux données, à aucune étape.
Erreurs fréquentes
- Appliquer le XOR directement sur le texte base64. Le base64 est la couche externe ; décodez-le avant d'appliquer le XOR sur les octets.
- Supposer une clé multi-octets. L'énoncé et les données indiquent un seul octet, taper une clé longue ne décodera rien.
- Se tromper en saisissant la clé. 0x42 est la lettre « B » ; saisissez-la comme l'octet attendu par l'atelier.
- Ajouter des leurres. ROT et Vigenere agissent sur des lettres, pas sur des octets bruts, vérifiez d'abord la forme des données.
Comment s'en protéger
Pour les défenseurs, la leçon est qu'un XOR à un seul octet est l'obfuscation la plus faible qui soit : c'est la première chose à essayer (ou à forcer par brute force) lors du triage d'un artefact déposé, et elle ne devrait jamais apparaître là où une vraie protection est nécessaire. Si votre propre code « chiffre » quoi que ce soit avec un seul octet XOR, traitez ces données comme du texte en clair.
- Lors du triage, forcez les 256 clés XOR à un octet contre les blobs suspects pour faire apparaître notes cachées et configurations.
- Décodez automatiquement les enveloppes base64 avant d'analyser les octets sous-jacents.
- Ne protégez jamais de secrets avec un XOR à un octet (ni aucun XOR statique) ; utilisez un chiffrement authentifié avec une clé gérée.
- Basez la détection sur le comportement et les dépôts de fichiers, pas uniquement sur des chaînes lisibles qu'un attaquant peut trivialement dissimuler.