How to recognize an encoding

02Check the note, then the decode

An alphabet check asks whether the symbols fit a proposed format. Hex permits 0–9 and a–f. Standard Base64 permits letters, digits, +, /, and its padding convention. The alphabets overlap: cafe can pass a hex-symbol check while also being a word.

Next, read the provenance. If the source declares Base64 of text, apply that decode and check that the bytes fit the promised kind of text. A valid decode supports that declared interpretation. It does not prove an unknown author was truthful, nor does it establish the origin of an undeclared string.

If the note is missing, state the plausible readings and the evidence you need. Do not add layers of decoding just because a tool accepts the input. A meaningful-looking result can be accidental.

deadbeef

No declared encoding or algorithm name supplied.

03Decide three blobs from their notes

The three fictional blobs have different source notes. Use the notes to decide what to do before consulting the hand results on the cards. These records describe authored examples, not values collected from a real system.

YanoSec / Code
Three authored blobs. Shape is a hypothesis until the provenance card agrees.

Blob A: bGFi
Alphabet fits standard Base64. No padding is required because the source length is a multiple of three bytes.
Declared job: Base64 of a desk label.
Hand decode: 6c 61 62, UTF-8 letters lab.
Supported conclusion: the declared Base64 decode succeeds. Shape alone did not prove it.

Blob B: 6c6162
Alphabet fits hexadecimal. Two digits per byte gives three bytes.
Declared job: hex of the same desk label.
Hand decode: 6c 61 62, the same bytes as blob A.
Supported conclusion: the declared hex decode succeeds.

Blob C: cafe
Alphabet fits hexadecimal, and it is also four ordinary letters.
No declared encoding and no algorithm name.
Two hypotheses: the letters c a f e, or the two bytes ca fe.
Neither hypothesis is proved. A hex-looking string is not a hash by shape.

YanoSec / Code
Original fictional provenance: notes about where the strings came from.
These notes did not come from a real system.

Blob A: stored by the desk as Base64 of a label.
Blob B: stored by the desk as hex of that same label.
Blob C: copied from a slide title. Origin of the characters is unknown.
No item names a hash algorithm, a key, or a signature.
Decode only the item whose note names an operation. Leave blob C as ambiguous.

1. Read provenance.txt. Record that A declares Base64 of a label, B declares hex of the same label, and C has no declared representation.
2. For A, match bGFi to the hand grouping 6c 61 62, the ASCII letters lab. Record that the declared operation and the expected kind of result agree.
3. For B, group 6c6162 into three pairs. Compare them with A: the bytes match despite a different representation.
4. For C, write both four ordinary letters and two hex bytes as possible readings of cafe. State the missing source declaration, then stop without assigning a hash algorithm.

04Representation module case

Use the separate representation case to combine byte counting, Unicode, and a declared decode. It is a self-review activity: explain each result using the rubric on the card. No program or external puzzle is needed.

YanoSec / Code
Representation module self-review case.
All transforms below are hand groupings, not observed tool output.

Item 1. Hex display: 52 55 4e
Bytes: 3
If those bytes are UTF-8/ASCII letters: R U N

Item 2. Declared code point U+00A9 COPYRIGHT SIGN, UTF-8 bytes c2 a9
Code points: 1
Bytes: 2
A successful decode recovers the declared character. It does not add a second meaning.

Item 3. Base64 UmVk, provenance says Base64 of a color name.
Operation: standard Base64 decode
Hand result: 52 65 64, UTF-8 letters Red
Record the operation. Do not call the step decryption.

Item 4. String 00ff, no provenance.
Hypothesis one: two hex bytes, 00 and ff.
Hypothesis two: four characters, 0 0 f f.
Missing evidence: a declared encoding or an algorithm name.
Hex digits do not prove a hash and do not prove a format.

Rubric: state the byte count, the operation you used, and the fact you still lack for item 4.

1. Count the pairs in 52 55 4e. Check: three bytes. Under the stated ASCII reading, they spell RUN.
2. Compare U+00A9 with its supplied UTF-8 bytes c2 a9. Check: one code point, two bytes.
3. Follow the declared Base64 operation for UmVk. Compare with the hand result Red, bytes 52 65 64. State the operation alongside the result.
4. For 00ff, record two bytes or four written characters as competing readings. Explain which source fact is missing. Stop when every conclusion has a reason and a limit.

05Optional challenge

Spend about ten extra minutes adding a third possibility for C: perhaps the characters were copied from the beginning of a longer value. Your self-review question is which extra source fact would distinguish a complete label from a partial copy. The card supplies no hidden fact that resolves it.

06Fresh cases for the checks

Use these fictional cases for the checks below. They have different inputs from the worked examples. Read them here or make notes; no installation or external service is needed.

Value P: 72756e. Provenance: exported as hexadecimal bytes of an ASCII label. Byte table: 72=r, 75=u, 6e=n.
Value Q: face. Provenance: unknown copied text. It might mean four letters or the two hex bytes fa ce.
Value R: 32 hex characters copied without any algorithm or generation record.

07Explain your prediction

Optional written self-check: Label interpretations as hypotheses until provenance selects an operation. Record what a successful decode supports and what remains unresolved about source, algorithm and authenticity.