Hiding data in Base64 padding: an RCTF crypto challenge

First published Nov 2015•Rewritten Nov 2026•CTF write-ups

Base64 turns binary data into text by grouping input into three-byte chunks and mapping each six bits to a printable character. When the final chunk of input is shorter than three bytes, the encoder pads the output with one or two = characters and fills the remaining bits of the last character with zeros.

The trick

This challenge started from a text file that looked like an ordinary Base64 dump of a known open-source script. Comparing it against a freshly re-encoded copy of the same script showed no difference in content, but a difference in the final character before each padding marker. A standard encoder always zero-fills those trailing bits; here, several lines did not.

Because a decoder ignores those padding bits completely, they make a convenient covert channel: an encoder can set them to anything without changing the decoded output at all. Each modified line was quietly carrying a few extra bits of hidden information.

Recovering the message

Solving the challenge meant walking every line that ended in one or two = signs, extracting the specific bits that should have been zero, and concatenating them in order across the file. Once collected, those bits formed a short ASCII string, revealing the flag.

Why it matters

The same idea generalises beyond CTFs. Any encoding scheme with structurally unused bits, padding, alignment, reserved fields, can be abused as a low-bandwidth covert channel. Defenders auditing file formats or network protocols for steganographic exfiltration should treat padding and reserved regions as worth inspecting, not as safe-to-ignore filler.

This note has been rewritten and checked for this edition; it is not a copy of the original post.