Hex Back to Text: Recognising and Decoding Hex
The challenge
A flag was written out as a long run of hex digits, using only the characters 0-9 and a-f. That is a tell for one specific encoding. Recognise it, tap the matching decoder, and submit the flag.
What you'll learn
- Recognise hex encoding by its limited 0-9a-f character set and even length
- Understand that each pair of hex characters represents one byte
- Decode a hex string with the matching decoder button in one step
- Tell hex encoding apart from base64 by character set and padding
- Understand why hex offers no confidentiality, only a different way to write bytes
Skills tested
Prerequisites
- The idea that text can be written as a sequence of byte values
- Comfort comparing a short string against an expected character set
How it works
Hexadecimal, or hex, is a way of writing bytes using sixteen digits: 0-9 for the values zero to nine and a-f for ten to fifteen. Every byte takes exactly two hex characters, so a hex string is always an even length and never contains any letter past f. That tight character set is the easiest way to recognise hex on sight: if you see only 0-9 and a-f and an even count of characters, it is almost certainly hex.
Decoding is mechanical. The decoder reads the string two characters at a time, turns each pair into the byte it names, and then shows those bytes as text. There is no key and no secret involved - the mapping between a pair like 48 and its byte is fixed and public. Anyone can reverse hex with a single click, which is why hex, like base64 and ROT13, is encoding rather than encryption.
Telling hex apart from base64 is the real skill being tested. base64 uses upper and lower case letters, digits, and often ends with = padding, so it carries characters such as G-Z that hex never does. The string here has none of those, only 0-9a-f, so base64 is the wrong tool. The ROT13, URL, and reverse buttons also expect different shapes and would not produce readable text, so they are decoys.
Common mistakes
- Trying base64 first. base64 would carry letters past
fand often=padding. A string of only0-9a-fis hex, not base64. - Splitting the pairs wrong. Hex is read two characters per byte. Reading single characters or odd groupings produces garbage; let the decoder handle the pairing.
- Believing hex protects the value. There is no key, so hex hides nothing. It is one click from plain text.
- Submitting the hex digits instead of the decoded flag. The answer is the readable flag after decoding, including its HDNA wrapper.
How to defend against it
The defensive point is the same across every encoding: hex is a transport and display format, never a security control. If a value needs to stay private it must be protected with real encryption that uses a managed secret key, or kept out of the artifact entirely. A run of hex around a value tells you how it is written, not that it is safe.
- Never treat a hex string as protection for passwords, tokens, or personal data.
- Use proper encryption with a managed key when data genuinely needs confidentiality.
- Treat any hex, base64, or URL layer in logs, configs, or responses as cosmetic and decode it during review.
- Decode every encoded value you find in your own systems to confirm nothing sensitive is sitting in plain view.