CTF逆向出题大师

逆向题设计的常见翻车现场

逆向题的出题很容易陷入“想象的设计”：作者在本地跑通了一条解法，写进程序后却发现选手根本接不上。常见事故包括：求解链路在某一步断链、关键常量是凭空出现的魔数、选手直接 strings 搜出 flag、或者 patch 掉校验函数就能白嫖。另一种极端是难度失衡——搜索空间过大导致无人能解，或逻辑过浅被秒破。

八阶段门禁式工作流

本技能把出题标准化为八个顺序阶段：需求采集、解题拓扑与预期解设计、方案规划、方案二次确认、内容制作、黑盒自测、PoC 打洞验证、成果审阅。每个阶段产出后必须等待用户确认，不能连跑。

核心方法叫“从解法倒推”：先锚定一条能在本地脚本化跑通的预期解，再把题目作为包裹套上去。Phase 2 需要画出完整求解拓扑，并逐条排查非预期解，必要时引入远程校验服务防止 patch 白嫖。

两道硬核验证关

真正区分本技能的是 Phase 6 和 Phase 7。Phase 6 派发一个只拿公开材料的独立求解子代理进行黑盒自测，它必须产出完整的求解记录与常量来源标注，任何“凭空出现”都会触发回退修正。Phase 7 则要求写出 poc/solve.py，所有常量必须由脚本从题目数据解析或推导，禁止硬编码答案，并且必须实跑证明能“打洞”——二进制回 Correct! 或 checker 回 PASS。

适用边界与注意点

这套流程纪律性极强，适合愿意逐阶段对齐、把自测当作正式环节的出题人。如果你想快速拼凑一道题并直接丢到赛场上，这套门禁机制会带来明显的沟通成本。另外，逆向题通常分发二进制给选手，而非开放 Web 端口；是否需要远程校验服务取决于你是否想阻止选手 patch 本地二进制。所有 flag 在交付物中均为占位串，真实值由部署平台注入。