0xhexforgeCTF utility layer
hexforge / guides / evidence-notes

GUIDE 14 / WORKFLOW

A Reproducible CTF Evidence Notes Workflow

A flag proves that a path worked once. Good notes explain why it worked, preserve the input, and let a teammate repeat the result without guessing.

Separate observation from interpretation

Write what you can directly observe before writing what you think it means. “The first bytes are 50 4b 03 04” is an observation. “The file is a normal ZIP archive” is a hypothesis that still needs container validation. This small distinction prevents an early guess from silently becoming a fact in later steps.

Use four labels consistently: source, observation, hypothesis, and action. Source identifies where an artifact came from. Observation records stable properties. Hypothesis states a testable interpretation. Action records exactly what was done and what output it produced.

Capture the minimum reproducible record

For text transformations, preserve the original input, operation and direction, relevant options, output, and reason for the next step. For files, include source, filename, byte size, SHA-256, working-copy name, command or tool version, and hashes of important derivatives. For web challenges, record the lab scope, request method, path, relevant headers, body, response status, and timestamp without copying real credentials into shared notes.

source: authorized challenge download
artifact: evidence.bin
sha256: <complete 64-character value>
observation: starts with 50 4b 03 04
hypothesis: ZIP-compatible container
action: list members without extraction
result: note.txt, image.png
next: hash and inspect each extracted member

Record transformations as a chain

Encoding puzzles become difficult to audit when intermediate values disappear. Give every step an index. Store the exact input and output, not only the operation name. If Base64 decoding produces percent-encoded text, the record should show both states before URL decoding. That makes an incorrect branch reversible and lets another solver compare one layer at a time.

A useful rule is that each step should answer one question. “Does this value decode as valid Base64?” is better than “try several decoders.” When output becomes less structured, stop and return to the last supported state.

Keep concise dead-end notes

Deleting failed attempts causes teams to repeat them. Record the hypothesis, exact test, and decisive reason it failed. A single line such as “ROT13 tested; output remains unstructured and round trip adds no evidence” is enough. Do not keep pages of speculative output that obscure the successful path.

Protect sensitive material

CTF flags may be shareable only within a team until an event ends. Real session tokens, credentials, private URLs, and personal data should not enter screenshots, public repositories, analytics, or issue trackers. Redact shared examples while retaining enough structural detail to reproduce the method. Hexforge stores challenge records locally, but exported JSON becomes an ordinary file and must be handled accordingly.

Local storage is not a backup

Browser data can be cleared, corrupted, or isolated by profile. Export important challenge records and protect the export according to the sensitivity of its contents.

Finish with independent verification

After solving, replay the shortest supported path from the preserved original. Confirm file hashes, transformation directions, parameters, and the final flag. Ideally, ask a teammate who did not perform the first solve to follow the notes. Every place they need to guess marks missing context.

Then write a short explanation of why the result is correct: the decoded structure, matching signature, accepted challenge response, or independent test vector. A list of commands without reasoning is reproducible but not educational; an explanation without exact inputs is educational but not reproducible. Strong notes provide both.

How this guide was verified

A sample multi-step decoding case and a small ZIP fixture were documented in the Hexforge challenge workspace, exported, and replayed from the original inputs in a fresh browser profile. The replay required complete intermediate values and hashes; notes that depended on browser history or unstated options were treated as incomplete.

Reusable checklist

  1. Define authorized scope and source.
  2. Preserve original text or file identity.
  3. Separate observations from hypotheses.
  4. Record one action and one output per step.
  5. Keep concise reasons for rejected branches.
  6. Redact secrets before sharing.
  7. Replay the path from the original.
  8. Export important notes and verify the backup.