Unwrap the Config Blob: Reversing XOR and Base64 Layers
The challenge
Recovered from a malware config file: the base64 blob below. The analyst's notes say it was XOR-encrypted with the key 'acme' before being base64-wrapped. Build the recipe in the workbench to reverse both layers, then submit the flag (HDNA{...}).
What you'll learn
- Reverse stacked transforms in the correct (inverse) order
- Recognise base64 as the outer transport layer by its character set and padding
- Apply a repeating-key XOR with a known key to recover plaintext
- Rule out decoy transforms by checking whether their input format fits
Skills tested
Prerequisites
- Comfort with base64
- Understanding that XOR is its own inverse
How it works
Malware authors rarely use strong cryptography to hide a config - they use cheap, reversible obfuscation, usually a repeating-key XOR wrapped in base64 so the bytes survive being stored as text. To an analyst, the job is to recognise the layers and peel them in the right order.
Layers come off in the reverse order they went on. Here the author took the plaintext config, XOR'd it with a short repeating key, and then base64-encoded the result. So you decode base64 first (turning the printable blob back into the raw XOR'd bytes), then undo the XOR. XOR is convenient for both sides: because A XOR B XOR B = A, re-applying the same key with the same operation cancels it out exactly - no separate 'decrypt' needed.
The workbench models this as a recipe: each operation feeds its output into the next, and the result updates live. Add From Base64, then add XOR and type the key acme, and the plaintext flag appears in the output panel. The other operations in the palette (ROT, Vigenere, hex, atbash, reverse) are decoys - part of the skill is noticing their input formats do not match what you are holding.
Common mistakes
- Peeling in the wrong order. Trying to XOR the printable base64 text directly. Base64 is the outer layer; decode it first.
- Guessing the key. The key was given (acme) - read the brief before brute-forcing.
- Reaching for decoys. ROT or Vigenere look crypto-ish but do not fit raw bytes; check the data shape before adding an operation.
- Forgetting XOR is symmetric. There is no separate decrypt step - the same XOR with the same key reverses it.
How to defend against it
For defenders, the takeaway is that XOR-plus-base64 is obfuscation, not encryption - it stops a casual strings but not an analyst. When hunting, normalise and decode suspicious blobs automatically; when building, never mistake this pattern for protection of your own secrets.
- Decode and XOR-scan suspicious base64 blobs during triage to surface hidden config and C2 data.
- Use real authenticated encryption with a managed key when data must actually be confidential.
- Treat any short repeating-key XOR as recoverable - including by your adversaries.
