附录C 练习题
附录C 练习题
十五道题覆盖后半本（第 06 到 11 章），按基础、进阶、思考三档排列，每题标注涉及章节与验收标准，附提示不给答案。研究对象全部合规：自编译程序、开源软件、公开 CTF 样本。建议做完基础档再做进阶档；思考档适合写成一页纸论述。配套的纪律要求：凡产出结论，一律按第 11.1 节四列证据链记录。
基础档
C-1 双引擎首航（第 06 章）
任选一个自己写的或开源的小型 Web 项目（许可证允许），分别用 semgrep 自动规则与 p/owasp-top-ten 规则集各扫一遍。
验收：两张告警清单；挑出三条告警，写出「为什么我认为它是误报（或真问题）」的判断依据；全程命令入证据链。
提示：误报判断的依据要落到代码事实上（参数来源、有无净化），不要只写「看起来没事」。
C-2 三行规则起步（第 6.1 节）
为自己的代码库写一条 semgrep 自定义规则：检测团队约定禁止的写法（如裸 eval、调试打印、内部危险封装）。
验收：规则 YAML 三到十行；在自己仓库跑出至少一处命中；给规则写一行 message 说明危害。
提示：先从最简单的单 pattern 起步，命中为零时用 metavariable 打印调试，确认模式真的匹配了目标语法。
C-3 Joern 导入与危险调用（第 7.2 节）
导入一个中小型开源 C 项目，列出危险函数调用清单并按文件分组统计。
验收：导入成功的规模三数字（函数数、调用数、标识符数）；危险调用热点文件前三名；一句话说明为什么 Joern 不需要构建环境。
提示：importCode 后先跑 cpg.method.size 确认图不是空的；统计分组可参考 7.2 节第二条查询。
C-4 angr 解自编 crackme（第 8.1 节）
按 8.1 节源码编译并 strip 一个 crackme，用 angr 解出口令。
验收：口令与源码 key 一致；explore 的 find 与 avoid 谓词写出并解释为什么用输出串而不是地址做目标。
提示：如果 explore 空手而归，先检查两件事：符号输入长度是否够、成功与失败字符串是否与二进制里的完全一致（大小写与换行）。
C-5 调试器三动作（第 8.3 节）
用 pwndbg 对 C-4 的 crackme 做断点、对照、单步三动作，验证「check 逐字节比较」这一静态结论。
验收：一次会话记录：断点地址、第一个参数寄存器值、key 常量地址处的内存内容、单步后观察到的跳转方向。
提示：stripped 样本没有符号，断点地址从你的静态分析（第 01 章工具）获取；对照值抄进证据链时带上进制前缀。
进阶档
C-6 污点规则进阶（第 6.1 节）
在 C-2 基础上把规则升级为 taint 模式：从 request 参数到 open，并写出 sanitizer 消警的正反例各一。
验收：同一规则在未净化版本报 ERROR、加 secure_filename 后告警消失；解释 sanitizer 与 pattern-not 的区别。
提示：正反例只改一行净化调用，其余不动——单一变量才能证明是 sanitizer 起了作用。
C-7 改写污点查询（第 6.2 节）
把 6.2 节的 CodeQL 查询骨架改写：source 换成另一种入口（如 JSON 请求体读取），sink 换成文件写入。
验收：改写后的 .ql 在建好的库上跑通；结果为空时能说明是「无数据流」还是「查询写错」（用一条已知存在的链路做阳性对照）。
提示：阳性对照是评测查询的基本功——先造一个必命中的小函数放进库里，查询能抓到它再谈扫描全库。
C-8 参数流追踪（第 7.2 节）
在 C-3 的项目里选一个处理外部输入的函数，用 reachableBy 追它的参数能否到达危险 sink，并用 CFG 信息检查路径上有无净化检查。
验收：查询与结果入证据链；结论按已证、已证伪、待验证三档标注，空结果不写成「安全」。
提示：记住 reachableBy 的精度边界（7.2 节的提醒）——「未发现数据流」与「不存在数据流」是两句话。
C-9 假设验证闭环（第 8.2 节）
对 C-4 的 crackme 完整跑一遍 8.2 节闭环：LLM 只看伪代码提假设，模板渲染脚本，运行后 VERIFIED 或 REFUTED 回填。
验收：假设 JSON、生成的脚本、运行输出三样齐备；若首轮 REFUTED，附第二轮修正记录。
提示：伪代码喂给模型前先删掉无关函数与字符串表噪声；模型输出任何散文解释都视为格式违规，重问。
C-10 qemu-user 仿真调试（第 8.3 节）
找一个公开 CTF 的 ARM 或 RISC-V 样本（或交叉编译自己的程序），用 qemu-user 加 gdb-multiarch 远程调试。
验收：完整会话记录：仿真启动、远程连接、断点命中、寄存器查看；标注结论为「仿真口径」并说明为什么。
提示：交叉编译自己的程序是最省事的合规样本来源；注意 qemu-user 是用户态仿真，涉及系统调用的行为要在报告里说明翻译层差异。
C-11 命名恢复流水线（第 9.2 节）
对 C-4 的 stripped crackme 跑命名流水线：LLM 按线索建议命名，行为验证（复用 C-5 会话），确认后用 binsync 提交。
验收：建议 JSON（含 confidence）、验证记录、binsync 提交历史各一份；至少一条建议因验证失败被拒绝转正。
提示：被拒绝的建议最有复盘价值——记下模型当时的依据（哪条线索误导了它），这是提示词迭代的原料。
思考档
C-12 榜单五问（第 10.2 节）
选一份 AI 安全基准的论文或榜单（CyberGym、Cybench、EnIGMA 任一），用五问框架写一页分析。
验收：五问每问有答案与出处；结尾回答「这套基准的结论能多大程度迁移到我的场景」，给出你自己场景的三个特征。
提示：工具配置那一问最容易被忽略——查清智能体带没带调试器、能不能联网，成绩差一个量级是常事。
C-13 方法论迁移（第 10.1 节）
把 VulnHuntr 五段式编排迁移到你熟悉的语言与项目：写出每段的提示词草案与预期输出格式。
验收：五段提示词全文；标注哪一段你会用第 06、07 章的引擎替换模型自查；引用 VulnHuntr 时带上停滞标注。
提示：重点设计第三、四段的「出处要求」——每跳引用真实代码行，是全链路证明不塌方的关键约束。
C-14 进制闸门制度化（第 11.1、11.2 节）
基于 int_convert 的思路，为你的团队（或假想团队）设计数值断言规范：何时必须走闸门、入链格式、违规如何被评审拦下。
验收：一页规范文档加两条示例（一条通过、一条被拦），说明闸门嵌在工作流的哪两个位置。
提示：规范能否落地取决于「被拦的成本」——把闸门做成证据链模板的必填列，比事后抽查有效得多。
C-15 SOP 定稿与演练（第 11.3 节）
把 11.3 节的 SOP 清单按你的实际环境裁剪定稿，并用一个公开 CTF 样本或自编程序走完全流程计时。
验收：裁剪后的 SOP（注明每步工具与责任人角色）；一次完整演练的耗时记录；演练中发现的两条流程改进建议。
提示：演练时让没读过本书的同事照单执行——他们卡住的地方就是 SOP 写得不够明白的地方。
合规声明：本节内容仅用于授权范围内的安全研究与教育目的；未经授权对他人软件进行逆向工程可能违反法律与许可协议。