Bases picoCTF 2019 Solution

Description

1. Step 1

   Decode the Base64 string

   Observation

   I noticed the string 'bDNhcm5fdGgzX3IwcDM1' uses only letters, digits, and symbols from the A-Za-z0-9+/= alphabet and its length is a multiple of 4, which are the defining properties of Base64 encoding and suggested piping it through base64 -d to recover the flag.

   The string looks like Base64 - it uses only letters, digits, +, /, and = for padding. Pipe it through base64 -d to decode it directly in the terminal.

   bash

   echo "bDNhcm5fdGgzX3IwcDM1" | base64 -d

   Copied!

   Expected output

   picoCTF{l3arn_th3_r0p35}

   What didn't work first

   Tried: Decode the string as hex by running echo "bDNhcm5fdGgzX3IwcDM1" | xxd -r -p

   xxd -r -p expects pairs of hex digits (0-9, a-f only), but this string contains uppercase letters like D, N, and characters outside the hex alphabet. The command outputs garbled bytes or exits with an error. Base64 uses a 64-character alphabet (A-Za-z0-9+/=) while hex uses only 16 characters (0-9, a-f), so the non-hex characters in this string immediately rule out hex encoding.

   Tried: Try decoding with base32 using echo "bDNhcm5fdGgzX3IwcDM1" | base32 -d

   Base32 uses only uppercase A-Z and digits 2-7, and its encoded output is always a multiple of 8 characters with = padding. This string contains lowercase letters and is 20 characters long (not a multiple of 8), so base32 -d rejects it with an invalid input error. The presence of lowercase letters in the encoded string is the key indicator that this is Base64, not Base32.

   Learn more

   Base64 is an encoding scheme that represents arbitrary binary data using only 64 printable ASCII characters: uppercase A-Z, lowercase a-z, digits 0-9, plus + and /. An = character is used for padding when the input length is not a multiple of 3 bytes. Because it produces only printable characters, Base64 is widely used wherever binary data must travel through text-only channels such as email, JSON APIs, and HTML data URIs.

   The encoding works by taking 3 input bytes (24 bits) at a time and splitting them into four 6-bit groups. Each 6-bit value (0-63) maps to one of the 64 characters. The result is always 4 characters per 3 bytes of input - a 33% size overhead. Decoding simply reverses this process.

   Identifying Base64 in CTF challenges is a core skill. Key indicators include:

   • Length is a multiple of 4 (possibly with trailing = padding)
   • Only uses the characters A-Za-z0-9+/=
   • Length is roughly 4/3 of the original data size

   Base64 is not encryption - it provides zero confidentiality. Anyone who recognizes the encoding can decode it instantly. Do not confuse encoding (a reversible representation change) with encryption (which requires a secret key). In real-world security, Base64 appears in JWTs, X.509 certificates (PEM format), and HTTP Basic Authentication headers.

   Base64 variants exist for different contexts. Standard Base64 uses + and /, but these characters are not URL-safe. Base64url replaces them with - and _ and is used in JSON Web Tokens (JWTs) and OAuth tokens. Base32 uses only uppercase letters and digits 2-7 (32 characters total), producing less compact output but with a character set that avoids confusion between similar-looking glyphs - useful in environments where case-insensitivity or human transcription matters. Base85 and ASCII85 achieve better compression ratios than Base64 and appear in PDF files and Git bundle formats.

   Recognizing Base64 quickly is a valuable CTF reflex. If a string looks like random alphanumeric characters and its length is divisible by 4 (possibly ending in one or two = signs), it is almost certainly Base64. The absence of spaces, punctuation, or patterns typical of natural language is a strong indicator. One common beginner mistake is to try to read Base64 as hex - hex strings use only 0-9 and A-F, while Base64 uses the full A-Z, a-z, 0-9 range. Tools like CyberChef's "Magic" operation or file --mime-encoding can help identify encoding automatically.

   In penetration testing, Base64 is used to bypass naive content filters. Payloads encoded in Base64 may slip past simple pattern-matching rules that look for keywords like eval or script. Web application firewalls and intrusion detection systems must therefore decode Base64 in request bodies and headers before inspecting the content. Defenders building detection rules should always normalize and decode common encodings before matching, or attackers will trivially evade detection by wrapping payloads in a layer of encoding.

Flag

Base64 encodes binary data using 64 printable ASCII characters. The trailing = padding is optional when the input length is a multiple of 3 bytes.