每道题至少记录五类信息
- 上下文：题目名称、分类、附件、题目描述和 Flag 格式。
- 原始证据：未经修改的字符串、文件哈希、截图和日志片段。
- 假设：为什么认为它是 Base64、JWT、文件容器或某种时间戳。
- 动作：使用的工具、参数、命令和清理规则。
- 结果：输出、错误、结论以及下一步。
只记录成功步骤会丢失重要信息。失败尝试同样有价值，因为它能说明哪些方向已经被排除，避免队友重复消耗时间。
一个可复用的记录模板
题目：Example Token
分类：Web
原始输入：eyJ...
观察：三段以点号分隔，前两段符合 Base64URL
假设：JWT，先读取 Header 与 Payload，不验证签名
动作：JWT Decoder，本地解析
结果：alg=HS256，exp=1767225600
下一步：转换 exp 并与题目时间线比对这个模板强迫你区分“观察到的事实”和“尚未验证的推测”。例如，三段结构支持 JWT 假设，但仅解码 Payload 不能证明令牌有效。
始终保留原始输入
清理空格、补齐 Base64、修改文件头或调整正则前，先复制原始值。记录转换后的结果时，也要说明具体改动。否则一旦方向错误，你很难判断问题来自题目还是自己早期的处理。
文件类题目还应记录大小和 SHA-256。每次生成关键中间文件时，使用新名称保存，不要覆盖原件。
工具链如何记录
多层编码题不要只写“解了几次”。应记录每一层的输入特征、使用工具和输出判断。例如：
1. URL decode：出现连续 Hex 字节
2. Hex to text：得到 Base64 字符集，长度为 4 的倍数
3. Base64 decode：得到 flag{...}Hexforge 工具链会显示每一步的执行轨迹。确认结果可信后，可以把输出存入题目工作区，并通过导出功能保存 JSON 备份。
让队友能在三分钟内接手
- 把当前结论写在最上方，而不是埋在长聊天记录里。
- 明确哪些事实已验证、哪些只是猜测。
- 附上可以直接运行的命令和最小输入。
- 标注失败原因，而不是只写“没用”。
- 记录下一步和当前阻塞点。
从解题笔记整理 Writeup
赛后整理时，删除与结论无关的重复尝试，但保留关键判断依据。推荐结构是：题目背景、线索识别、核心原理、可复现步骤、Flag、常见误区和防御启示。截图应辅助说明，不应代替文字步骤。
不要把敏感凭据写进公开 Writeup
公开前移除真实 Token、账号、内部地址和未经授权获得的数据。本文流程仅适用于合法 CTF、靶场和自有环境。
提交前检查
- 原始输入和关键附件是否仍可找到。
- 关键转换是否能由另一名队友复现。
- Flag 来源是否有明确证据，而不是猜测。
- 是否清理了公开内容中的敏感信息。
- 工作区是否已导出备份。