Uphack · an interactive walkthrough
This is not a secret.
Strings like the one below sit in authorization headers, cookies and page source everywhere. They look encrypted. They are not. They are ordinary bytes wearing a 64-character costume, and by the end of this page you will be able to see straight through it.
Hover or tap it. Nothing was decrypted, because nothing was encrypted.
01Where you will meet it
Base64 exists for one reason: some channels only carry text, and data is not always text. An image in an HTML page, credentials in an HTTP header, a JSON object inside a token. All of them ride the same trick. Hover each specimen to see what it carries.
Authorization: Basic YWRtaW46aHVudGVyMg==
admin:hunter2
Not hashed, not encrypted. Over plain HTTP these credentials travel in the clear.
<img src="data:image/gif;base64,R0lGODlhAQABAIAAAP8AAAAAACH5…">
43 bytes of binary GIF, inlined into markup
Binary data inside a text document. This is the problem Base64 was invented to solve.
eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMDIiLCJyb2xlIjoidXNlciJ9.<sig>
{"sub":"102","role":"user"}
Tokens use the url-safe variant: + and / become - and _, and the padding is dropped.
02Text is already numbers
Before any encoding happens, the text is gone. The word Cat reaches
the wire as three bytes, 67, 97 and 116, and each byte is eight bits. Hover a character below
and its bits light up; hover a bit and it points back at its character.
Every encoding question is a question about these bits. Base64 never touches the characters at all.
03The recut is the entire trick
Here is the same stream of bits read two ways. Above the lane, the bits are cut every eight: three bytes. Below it, the same bits are cut every six: four groups, each worth a number from 0 to 63, each mapped to one printable character. Hover either side.
The brackets do not line up, and they never will: 8 and 6 first agree at 24. That is why Base64 works in blocks of three bytes in, four characters out, and why encoded data grows by a third. Two facts you can now derive instead of memorise.
04Drive the encoder yourself
This is a working encoder with the lid off. The read head is fixed; the tape moves. Pull it through by hand, or press play and watch the six-bit buffer fill and flush. The sentence under the machine always describes exactly what is happening at the head.
05When the bytes run out
Hi is two bytes: sixteen bits. The first two groups take twelve.
The third gets the last four bits and is topped up with two zeros that carry no data. The fourth
gets nothing at all, and nothing is what = means. Pull the tape to
the end and watch it happen.
The padding is not decoration. It tells the decoder exactly how many real bytes to rebuild, which is why a tampered token with mangled padding often fails before anything else does.
06Reading it back
Decoding is the same tape pulled through the same head, read in the other direction: each character surrenders its six bits, an eight-bit register collects them, and every full register is one byte of the original. The zeros the encoder invented are recognised and thrown away.
07Now break it
Plaintext above, Base64 below: two live views of the same bytes. Edit either one. Better, click any single bit and watch both worlds react. The challenges are worth your time; each one teaches a fact about ASCII that security work quietly relies on.
08What to keep
- Encoding is not encryption. Everything on this page reversed without a key. Treat Base64 as a costume, never as a lock.
- It grows by a third. Three bytes become four characters, always.
=is length information. It marks how far short of a three-byte block the data fell.- Tokens use base64url. Same alphabet with
-and_, padding usually dropped, so it survives a URL.
One command checks anything you meet in the wild:
echo -n 'SGVsbG8h' | base64 -d
The next time you meet one of these strings it will be inside a request that matters. The labs are where you practise that part.