Crypto — The Layered Cipher

Category: Crypto · Difficulty: Easy

Scenario

An old backup script left a "secret" hardcoded in a config file. Whoever wrote it clearly thought stacking two encoding layers would make it secure. It won't stop you — but it's a genuinely useful exercise in recognizing encoding formats by sight and peeling them apart methodically, a skill that comes up constantly in real forensics and CTF work.

Provided data

UkhaT1pMSntqNGx6NHlfNHVrX2k0emw2NF9zNGZseXp9

Your task

Recover the original flag. You'll need to identify and reverse two separate layers of encoding, in the correct order.

Hint 1 — identifying the outer layer

Look at the character set: only letters, numbers, and possibly = padding at the end. That specific alphabet is a strong signal for one very common, easily reversible encoding. It's not encryption at all — just a different way of representing bytes as text.

Hint 2 — decoding the outer layer

Any online base64 decoder, or a single command-line tool, reverses this instantly: echo "UkhaT1pMSntqNGx6NHlfNHVrX2k0emw2NF9zNGZseXp9" | base64 -d. What you get back won't be readable English yet — that's the second layer underneath.

Hint 3 — identifying the inner layer

After decoding the base64, you should see something like RHZOZLJ{j4lz4y_...} — note that the curly braces are still in the same place as a real flag would be, and the text has a consistent "shifted" pattern (compare where { lands versus a real KASHSEC{ flag). This is the signature of a classic substitution cipher taught back in Path 10/07's cryptography-adjacent material: each letter is shifted a fixed number of places through the alphabet, non-letters (digits, punctuation) left untouched.

Hint 4 — cracking the shift

You know the flag must start with KASHSEC{ — every challenge in this section uses that exact prefix. Compare R (first letter of the shifted text) to K (first letter it should decrypt to) to work out the exact shift amount, then apply that same shift backward to every letter in the string. Digits and symbols (the underscores, braces, the "4"s) don't shift — only letters do.

Show full answer

Layer 1 — Base64: The string uses only letters, digits, and clean padding — the classic signature of Base64, which is an encoding (freely reversible, no secret key) rather than encryption. Decoding it gives: RHZOZLJ{j4lz4y_4uk_i4zl64_s4flyz}.

Layer 2 — Caesar cipher: Comparing R → K shows a shift of 7 places forward was applied to encode it (R is 7 letters after K in the alphabet), so decoding requires shifting every letter back by 7, leaving digits/symbols untouched. Applying that: R→K, H→A, V→O... wait — walking the full string through a −7 shift on every letter yields the original flag below.

The flag

KASHSEC{c4es4r_4nd_b4se64_l4yers}

Why this matters beyond the CTF

Recognizing encoding formats on sight — Base64's clean alphanumeric-plus-padding look, hex's 0-9a-f pairs, URL-encoding's %XX sequences — is a skill you'll use constantly in real work: reading captured HTTP traffic, analyzing malware configuration strings, or parsing log data. Layered "obfuscation" like this (stacking a trivial substitution cipher under a standard encoding) is also a real pattern seen in unsophisticated malware and poorly designed applications — it slows down casual inspection but provides essentially no real security against anyone who methodically peels back each layer, exactly as you just did.

Bonus round — spot the encoding by eye, no decoding needed

A genuinely useful drill for building instant pattern recognition: without decoding anything, just identify which encoding each string below most likely uses, based purely on its character set and shape.

A) 4b4153485345437b737065656472756e7d
B) KASHSEC%7Bfast%5Frecon%7D
C) S0FTSFNFQ3tsYXllcmVkX2VuY29kaW5nfQ==

Hint

Look at the alphabet each one uses: does it only contain 0-9a-f? Does it contain % followed by two characters? Does it end in = padding with a mixed-case alphanumeric body?

Show answer

A is hex — only characters 0-9 and a-f appear, always in pairs (each pair represents one byte). B is URL encoding — the %7B/%7D/%5F sequences are percent-encoded special characters ({, }, _), exactly the format from Path 05's HTTP lessons for safely transmitting special characters in a URL. C is Base64 — mixed-case letters and digits with trailing = padding. All three decode to a real KASHSEC{...} flag if you want to confirm it yourself — but the actual point of this drill is recognizing the format instantly, without needing to decode first, since in real forensic or bug bounty work you'll often triage dozens of encoded strings and need to know at a glance which decoder to reach for.

Base64 has no secret key and no security property at all — anyone can decode it instantly. Confusing "encoded" with "encrypted" is a genuinely common and dangerous mistake: teams sometimes base64-encode sensitive data and mistakenly believe it's now "protected." It isn't. Real confidentiality requires actual encryption (AES, etc.) with a properly managed secret key — a distinction worth internalizing permanently.

Next up → Forensics — The Log Hunt