Decrypt the Ransom Note: Single-Byte XOR under 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
- Recognise base64 as the outer transport layer of a dropped artifact
- Identify a single-byte XOR and reason about its 256-key space
- Recover plaintext by XOR-ing with the key byte 0x42
- Peel two stacked transforms in the correct inverse order
- Explain why single-byte XOR offers no real confidentiality
Compétences testées
Prérequis
- Comfort with base64
- Understanding that XOR is its own inverse
- Knowing that a byte has 256 possible values
Comment ça marche
A single-byte XOR applies the same one-byte key to every byte of the data. It is the simplest 'cipher' there is, and its weakness is its key space: there are only 256 possible keys, so an analyst can try all of them in a fraction of a second and keep whichever result reads as text. Ransomware and droppers use it not for security but to keep their note out of a casual strings dump, then base64-wrap the result so the bytes survive being written to a file.
Peel the layers in reverse. The dropped note is printable base64, so decode that first to get the raw XOR-scrambled bytes. Then XOR every byte with the key. XOR is symmetric, so the same operation with the same key undoes it, because A XOR B XOR B = A. Here the decryptor sample reveals the key is 0x42, the ASCII letter B. Even without that hint, a single-byte brute force would surface it immediately.
In the workbench, add From Base64, then XOR with the key B (or 0x42), and the note resolves live in the output. The remaining operations (hex, ROT, atbash, reverse, Vigenere, URL-decode) are decoys whose input formats never match the data at any stage.
Erreurs fréquentes
- XOR-ing the base64 text directly. Base64 is the outer layer; decode it before XOR-ing the bytes.
- Assuming a multi-byte key. The brief and the data point to a single byte - typing a long key will not decode it.
- Mistyping the key. 0x42 is the letter 'B'; enter it as the byte the workbench expects.
- Adding decoys. ROT and Vigenere act on letters, not raw bytes - check the data shape first.
Comment s'en protéger
For defenders, the lesson is that single-byte XOR is the weakest obfuscation in the book - it should be the first thing you try (or brute-force) when triaging a dropped artifact, and it should never appear where you need real protection. If your own code 'encrypts' anything with a single XOR byte, treat that data as plaintext.
- During triage, brute-force all 256 single-byte XOR keys against suspicious blobs to surface hidden notes and config.
- Decode base64 wrappers automatically before scanning the underlying bytes.
- Never protect secrets with single-byte (or any static) XOR - use authenticated encryption with a managed key.
- Score detections on behavior and file drops, not only on readable strings an attacker can trivially hide.