文件取证基础流程

第一步：保留原件

下载题目附件后，保留只读副本，分析时对工作副本操作。立即记录文件名、大小、获取时间和 SHA-256。摘要以后可以证明分析前后的字节是否一致，也方便团队成员确认拿到的是同一份附件。

original/challenge.bin   只读保存
work/challenge.bin       分析副本
notes/hash.txt           SHA-256 与获取时间

第二步：不要相信扩展名

photo.jpg 可能实际是 ZIP，document.pdf 也可能在末尾附加其他数据。检查文件开头的魔数、MIME 判断和扩展名是否一致。

第三步：元数据和低成本线索

先做不会改变文件的检查：元数据、可打印字符串、压缩包目录、图片尺寸、颜色模式和尾部附加数据。CTF 的 Flag、密码提示和工具版本经常藏在注释、EXIF、文档属性或文件名中。

字符串结果需要上下文。一个看似域名的片段可能来自软件库，而不是题目线索；优先关注题目主题、异常路径、长编码串和 Flag 前缀。

第四步：把容器逐层拆开

Office 文档、APK、JAR、EPUB 和许多固件本质上都是容器。先列出目录结构，再提取到单独目录。每次展开都记录来源路径，避免多个同名文件混在一起。

第五步：根据证据选择专用方向

• 图片：检查色道、透明层、像素最低有效位、尾部数据和 OCR。
• 网络包：先看协议分布、会话和导出对象，再做内容搜索。
• 内存镜像：确认操作系统和采集方式，再选择匹配的分析框架。
• 磁盘镜像：保持只读挂载，关注分区、删除文件、时间线和浏览器痕迹。
• 音频：检查频谱、波形、元数据和是否存在不同声道信息。

最低限度记录

1. 原件 SHA-256。
2. 每个工具和关键参数。
3. 提取文件的来源偏移或容器路径。
4. 时间统一使用 UTC，并注明本地时区。
5. 结论与证据分开写，保留失败分支。

这个流程不是完整的司法取证规范，但足以让 CTF 分析更稳定，并减少“找到答案却无法复现”的情况。