方法论主线来自 Devansh 的 Needle in the Haystack，工具细节来自公开文档，实战数据来自我们自己的授权测试台账。数据截至 2026-09-20，适用范围：已书面授权的安全测试。

怎么从一台空机器把这套东西搭起来，搭的过程会撞上什么，Web、小程序和 APP 分别怎么下手，以及最后那一步——话该怎么跟模型说。

给管理层的三句话

1. 一次性投入约五个人日。之后每接一个新目标都吃这份红利，冷启动从天级掉到小时级。

2. AI 接管的是通读、枚举、重放、起草这些体力活。什么算漏洞、影响多大、什么时候必须停，仍然是人签字，而且流程强制要求人签字。

3. 合规写在配置里而不是靠自觉。授权白名单、写操作禁令、速率上限、数据打码，全程留日志，比纯人工测试更可审计。

00 · 摘要：一页看懂

把 Claude Code 这类编程智能体套上四层工程设施——规则、记忆、能力、台账——变成一条能对授权目标持续产出可定级报告的流水线。它不是一句更好的提示词，是一套目录结构加一组约定。

四个数

它解决什么

把仓库丢进去说"找出所有漏洞"，拿回来的是一张看着专业、实际没法用的表。换更强的模型也没用——我们拿 Opus 5 和 GLM-5.3 各跑过同一个目标，产出质量差别不大，都不能用。问题出在方法不在模型。裸用有四个结构性缺陷，工作台的四层设施是一一对应补上去的：

搭完长什么样

一个可复制的目录骨架、一页纸规则文件、一组按目标形态装的工具，外加一本记录每个假设及其结果的台账。三种形态共用同一套骨架，只在能力层换工具：

一条贯穿全文的尺子

Devansh 在 Needle in the Haystack 里给了个很好用的分配比例：脚手架不超过 10%，切片审计占 60 到 80，剩下 20 到 30 留给验证。

比例本身不神圣，它的用处是当你发现脚手架超了 10%，就该砍规则文件而不是加窗口。这条贯穿本文所有章节——规则文件为什么要控制在一页、大文件为什么必须走索引、为什么每条结论都要人复核，都可以用它来解释。

第一部分：裸用 AI 为什么不行

大多数人拿到 Claude Code 的第一件事，是把整个仓库丢进去说"找出所有漏洞"。这条路走不通，原因有四个：前两个是模型行为，后两个是工程缺失。四个都不是换更强的模型能解决的。

1.1 没有威胁模型时，模型做的是检索

你不说攻击者是谁、信任边界在哪、攻击者能控制什么，模型就没有"影响"这个概念。它能凭训练数据猜出一些通用 CWE，但猜得很差。结果是一长串"理论上可能存在 XSS"“建议检查 SQL 拼接”，没有优先级，你也没法从噪音里挑出值得跟进的。

技术上的原因值得说透，因为后面几乎所有设计都是冲着它去的。在没有约束的情况下，LLM 做的是模式召回，不是可达性分析。它从训练分布里检索"这类代码通常有什么漏洞"，输出的是一个先验分布。而真正的漏洞判定要回答的是另一个问题：

写成条件概率大概是 P(可利用 | 代码, 信任边界, 攻击者能力, 可达路径)。后面三个条件项你不给，模型手里就只剩 P(可利用 | 代码)——一个脱离语境的无条件先验。它输出的那堆"理论漏洞"，本质上是把训练集里这类代码的平均风险念了一遍。

Devansh 那篇文章里有句话可以直接抄进规则文件：威胁建模是安全审计的终极压缩算法。一页纸的威胁模型能替代几十页的通用规则，因为它填的是条件项，不是增加信息量。这两件事在 token 账上的差别极大：通用规则是往上下文里加噪声，条件项是把搜索空间砍掉几个数量级。

1.2 宽问题把推理预算摊薄

这个更隐蔽，因为它的产出看起来很丰盛。广问题引出广回答，模型会去匹配它见过的常见模式，哪怕在你的上下文里根本不可能触发。你最终在审一些没有任何攻击者能到达的路径，花几万 token 买回一堆不可复现的清单。原文管这叫 breadth-first hallucination。

机制有两层，拆开看才好对症：

▪ 推理预算被摊薄。 一个覆盖整个仓库的宽问题，让模型把有限的推理分到每个文件上，每个文件只够做表层匹配。注意力是有限资源，你给的范围越大，单位代码上分到的越少。

▪ 输出策略在优化错误的目标。 宽问题下，“列了 20 个方向"看起来比"深挖了 1 个方向"更像回答了"所有漏洞"这个问题。所以模型倾向于给覆盖面——它在优化它以为你要的东西，而不是你真正要的东西。

还有一个叫 context rot 的现象叠加在上面：上下文越长，模型的可靠性越下降，而且不是到窗口上限才突然崩，是一路缓慢劣化。所以"把更多材料塞进去"这个动作本身就是反向操作。标称 20 万 token 的窗口，实际能稳定推理的有效部分远小于这个数——工程上要按有效窗口规划，不能按标称窗口规划。

1.3 会话无状态，重复劳动烧两份钱

每个新会话都从零开始。上一轮已经测过并否定的假设，这一轮换个说法又跑一遍；上个项目总结的模式，这个项目完全用不上。

代价是双份的。token 在烧，目标请求配额也在烧，后者更值钱，因为它受目标侧风控限制，是硬约束——token 花完可以充钱，IP 被封了就得等。

多人协作时这个问题会放大。三个人各跑各的会话，同一个接口被测三遍，既浪费预算，也真实地增加了触发风控的概率。我们在一个 OTA 目标上吃过这个亏：两个人分别测了订单查询的越权，用词不同、结论一致，多出来的那一遍请求没产生任何新信息，但确确实实进了目标的风控计数器。

1.4 没有边界意识，这是风险不是效率

AI 没有法律意识。给它一个域名，它会顺手去探旁站；让它验证一个下单接口的越权，它可能真的下一单；让它测短信接口，它会把验证码打给真人。

这些不是模型的 bug，是它没有被告知边界。边界是人写进文件它才知道的，没写，它会自己判断，而且通常判错——它的判断依据是"这样做对完成任务有帮助”，不是"这样做会不会越界"。

前三条是效率问题，这一条是风险问题。对内部汇报来说它也是最该强调的一点：工作台的规则层不只是让 AI 跑得更准，它把合规约束从"靠测试人员自觉"变成了"写进配置、全程留痕"。第三部分会给出三层 scope 护栏的具体配置。

1.5 三个反例：别人是怎么挖出来的

Needle in the Haystack 的作者在两个月里用这套方法报了 30 多个漏洞。挑三个能说明问题的：

Parse Server　CVE-2026-29182 / 30228 / 30229

先翻历史 CVE，发现全是权限校验不完整。据此让模型生成聚焦"权限边界执行"的威胁模型，然后盯住一个具体边界：只读管理员 key。模型发现多个路由 handler 只查了 isMaster 没查 isReadOnly。这是一个模式而不是一个点，于是用更窄的提示词让它枚举所有符合这个模式的 handler——三个 CVE 同一个根因。

ElysiaJS　cookie 签名校验

切片选的是 cookie 签名校验。找到的问题是一行初始化写反了，let decoded = true 本该是 false，导致密钥轮换期间无效 cookie 不会被拒。这种 bug 静态扫描器基本抓不到，因为语法完全合法，错的是语义——而语义恰好是 LLM 相对扫描器的唯一优势所在。

harden-runner　CVE-2026-25598

威胁模型只有一句话：攻击者能不能绕过出站管控把数据传出去。然后做系统调用覆盖度分析，发现 UDP 那几个（sendto / sendmsg / sendmmsg）没被监控。同样的问题问另一个项目 BullFrog，因为它用网络层防火墙而不是系统调用插桩，切片就完全不同：DNS 解析、IP 到域名的绑定、提权路径。

注意这三个的共同点：没有 20 页的 Agent.md，没有庞大的 Skill 库，没有全量扫描。做的是四件事——选好切片、从历史反推威胁模型、让模型找不变量违反、跟进信号。

Anthropic 用 Claude 审 Firefox 也是这个顺序：先从 JavaScript 引擎切入，跑通流程之后才扩到约 6000 个 C++ 文件，最终提交 112 份报告，大部分修复进了 Firefox 148.0，API 花费约四千美元。先窄后宽、先跑通闭环再放大规模，是这几个案例唯一的共同结构。

1.6 顺带说清楚模型的几个已知偏好

这几条会在第七部分变成具体的提问技巧，这里先摆出来，因为后面很多设计是冲着它们去的：

▪ 首尾位置效应。 放在上下文窗口两端的信息被用得更好，埋在中间的最容易被忽略。所以关键约束要么放最前，要么在任务书里重申一遍。

▪ 默认顺从。 不特别提示时，模型倾向于说代码是安全的。“整体看起来没问题，有一些小的关注点"是阻力最小的答案。

▪ 完整性前置。 它最有把握的发现排在最前面，细微的 bug 要靠追问才出来。所以"还有别的吗"这句话要多问几轮。

▪ 抽象指令吃不住，具体边界吃得住。 给它"注意安全性"没用，给它"只读 key 不能触发写操作"它能顺着查。

▪ 倾向于把代码合理化。 看到一段可疑写法，它的默认假设是"作者这么写有他的道理”，然后开始替作者圆。这条在 7.3 的技巧 07 里被专门针对。

这五条里，前两条决定了规则文件怎么放、放多长，后三条决定了话该怎么问。它们不是缺陷清单，是这套方法的设计输入。

第二部分：架构

工作台是六层东西叠起来，让模型能看见目标、动手操作、记住结论、守住边界。每一层可以独立替换，这是整套设计里最值钱的性质——不是因为它优雅，是因为 2026 年这一行里价格、可用性、合规要求每个季度都在变。

2.1 六层结构

L1 和 L2 是买来的，L3 和 L4 是写出来的，L5 是装出来的，L6 是跑出来的。一次性投入主要花在 L3 和 L5，长期价值沉淀在 L4 和 L6。汇报的时候这句话可以直接用：你付的五个人日买的是 L3 和 L5，你留下的资产是 L4 和 L6。

2.2 数据流：假设是一等公民

整条流程的核心对象不是"代码"也不是"漏洞"，是假设——一条形如"只读 key 不能触发写操作"的、可以被证实或证伪的断言。每个假设有编号、状态、证据。围绕假设组织，流程就自然闭环了。

关键在最后那段回流：台账反过来喂给下一轮的假设环节。没有这条回流，整条流程是开环的，每一轮都在重复上一轮。很多团队搭到一半就上线，跑几周之后发现成本没降，根因基本都在这里。

假设的状态机

台账之所以能起作用，是因为假设的状态是有限的、可判定的。我们只允许这几个状态，多一个都不行：

没有"待定"。待定的东西留在 journal/ 里，不进 tested.md。这个限制看着教条，但它是台账能被模型可靠使用的前提：状态枚举一旦开放，模型就会开始创造"部分命中"“疑似"这类无法过滤的值，台账立刻退化成散文。

什么是不变量

不变量是代码声称永远成立的事。几个例子：

▪ 只读 key 不能触发写操作

▪ JWT 的 issuer 必须等于配置值

▪ 这个字段必须从服务端会话取，不能从请求体取

▪ 分发器转发给下游的身份，必须来自网关校验后的上下文

▪ preload 暴露的特权接口，只能被自有域名的页面调用（第五部分那个案例，根因就是这条不成立）

找不变量有个必须遵守的细节：把"列假设"和"判断假设是否被违反"拆成两步问。模型单独做"列出这个模块所有隐含安全假设"很在行，单独判断"假设 X 在这条路径上是否成立"也推理得很深。两件事塞进同一个提示词，结果通常很浅——它试图同时做两件事，会早早满足于一个及格答案。第七部分把这条做成了模板。

2.3 分层换来的三件事

第一条在 2026 年尤其实在。这一年我们换过两次主力模型，一次是因为涨价，一次是因为客户要求数据不出境。两次切换的实际工作量都是改两个环境变量加跑一遍探活，规则文件、记忆层、台账、MCP 配置一个字没动。如果当初把方法写死在某家的 Skill 体系里，这两次每次都是一周。

2.4 脚手架多少算刚好

这是最容易做反的一条。很多团队的第一反应是写一份事无巨细的规则文档、预加载一个庞大的知识库，结果效果比什么都不写还差。

脚手架的作用是把注意力锚定到正确的地方，一页纸足够。二十页的规则文件反而把注意力稀释了：模型要花 token 理解你的规矩，留给分析代码的推理空间就少了。

这可以直接算。一份 20 页的规则文件大约吃掉一万五到两万 token。按 10% 的上限倒推，只有当你的有效工作窗口在二十万 token 以上时它才勉强合规——而有效窗口远小于标称窗口，这正是 context rot 的含义。更别提规则文件不是唯一的常驻开销：MCP 的工具定义、系统提示、目录列表都要占位置，这些加起来经常比规则文件本身还大。

第三部分：搭建

七个步骤，从接模型一直到最小闭环验收。每步给出可直接抄的配置和这一步特有的坑。按顺序做完大约五个人日。三种目标形态的专用工具在第四到第六部分，这里只搭与形态无关的骨架。

3.0 接模型

先说结论：做一主一备，别二选一。兼容接口让切换成本接近于零，不用它是浪费。

决策的四个变量

2026-09 的牌面

Artificial Analysis 的智能体指数（2026-09-18）排下来是这个次序：Claude Fable 5.1 与 GPT-6 Astra 并列 60，Claude Opus 5 是 59，GPT-5.6 Sol 55，GLM-5.3 54，Kimi K3 52，Qwen3.8-Max 与 DeepSeek V4 Pro 同为 43。差 10 分不是不能用，是复杂重构和长任务的一次通过率低一些，多来一轮通常也能做完。

API 输出价是大头。国外第一梯队 25 到 50 美元每百万 token，国内 GLM-5.3 和 DeepSeek 只要 4 美元左右，差六到十二倍。订阅方面：Claude Pro 20 美元 / Max 100 / Max 20x 200；GLM Coding Plan ¥118‒1078；Kimi Code ¥49‒699；DeepSeek 纯按量。

国外模型的四个坎

主备双模怎么配

GLM 和 Kimi 都提供 Anthropic 兼容接口，意思是 Claude Code 这个终端可以直接指过去，改两个环境变量的事。这是整个工作台里性价比最高的一个设计：终端层不变，模型层随时切。

主：Anthropic 官方

wb-main() {

unset ANTHROPIC_BASE_URL ANTHROPIC_AUTH_TOKEN

export ANTHROPIC_API_KEY="$(security find-generic-password -s wb-anthropic -w)"

export ANTHROPIC_MODEL=“claude-opus-5”

}

备：GLM 兼容接口，同一个 Claude Code 终端

wb-backup() {

unset ANTHROPIC_API_KEY

export ANTHROPIC_BASE_URL=“https://open.bigmodel.cn/api/anthropic"

export ANTHROPIC_AUTH_TOKEN=”$(security find-generic-password -s wb-glm -w)"

export ANTHROPIC_MODEL=“glm-5.3”

}

探活：切换后先打一发，别在半个任务中间才发现挂了

注意必须包含一次真实工具调用，只测对话查不出兼容层的问题

wb-ping() {

claude -p “用 Read 工具读 ./CLAUDE.md 第一行，只回这一行原文” –max-turns 3

}

密钥走系统钥匙串而不是明文写进 rc 文件。工作区目录经常被打包带走，明文密钥跟着走出去是很现实的风险。

兼容层的已知差异

这里值得多说两句根因，因为踩坑的时候知道根因能省很多时间。Anthropic 的 Messages API 把工具调用表达成消息里的 tool_use / tool_result 内容块，OpenAI 系是 function_call 那一套，两边的参数容器、ID 关联方式、并行调用的表达都不一样。兼容接口做的是字段映射，简单调用映射得很干净，复杂的就未必。

三套推荐配置

人民币按 1 美元 = 7.1 元折算。价格每月都在变，动手前核一遍官方定价页。

3.1 目录骨架

可直接复制。新目标改配置不改流程，这是把一次性经验变成可复用资产的关键一步。

workbench/

├── CLAUDE.md # L3 常驻 · 一页纸 · 红线写死在这

├── .mcp.json # L5 MCP 服务器声明

├── .env.example # 真 .env 不进版本库

│

├── memory/ # L4 跨目标复用 · 只进不退

│ ├── patterns.md # 漏洞模式：哪类地方容易坏

│ ├── techniques.md # 技术手法：怎么测、怎么绕

│ └── tools.md # 工具与命令：环境怎么配、版本对应关系

│

├── targets//

│ ├── scope.md # 授权书摘要：白名单、时间窗、联系人

│ ├── threat-model.md # 一页威胁模型

│ ├── assets/ # 观测的结构化结果

│ │ ├── routes.md # 接口路由表

│ │ ├── identity.md # 身份字段：服务端下发 vs 客户端自报

│ │ └── invariants.md # 不变量清单，假设的来源

│ ├── capture/

│ │ ├── flows/ # 原始流

│ │ └── index.jsonl # 结构化索引 —— AI 检索用这个

│ ├── decompiled/

│ │ ├── INDEX.tsv # 文件清单 + 大小 + 首行

│ │ └── INDEX-keywords.md # 关键词热力，决定先读哪几个文件

│ ├── journal/.md # L6 按天流水

│ ├── tested.md # L6 假设矩阵 —— 防重复核心

│ ├── findings.md # L6 命中项 + 证据三件套

│ └── report/

│

└── tools/

├── mitm-addons/ # 落盘为结构化 jsonl

├── unpack/ # 小程序 / asar 解包

└── frida/ # hook 脚本库

那两个 INDEX 文件值得单独点一句。capture/index.jsonl 和 decompiled/INDEX-keywords.md 不是原始数据，是为模型准备的检索入口。直接让它读 mitmproxy 的二进制流或几千个反编译 Java 文件，是上下文爆炸的头号原因。先建索引、再按需取片段，能把单次任务的 token 降一个数量级。做法见 3.4。

3.2 规则层：CLAUDE.md 怎么写

常驻的只放红线，方法放任务书。这样常驻部分才能稳定控制在一页以内。

必须写死的六条

1. 目标白名单　域名 / AppID / 包名的明确列表，出列表禁止。不写这条，模型会顺手探旁站和关联域名。

2. 只读优先　下单、改密、删除、支付、发消息、催单，一切写操作默认禁止，需要显式豁免。

3. 速率与批量上限　每请求间隔 ≥ 1.2 秒、单批 ≤ 500、全程留日志。模型不懂刷太快会被封。

4. 验证码类接口禁触发　短信 / 邮件 / 语音验证码一律禁止。对真人构成骚扰，性质上已经不是技术问题。

5. 第三方数据验证性读取 ≤ 2 条　证明越权成立只需要一条记录。命中即停，报告内打码。

6. 凭证与 PII 不落正文　不进报告正文、不粘进对话、不进版本库、不传第三方模型。

措辞方式直接决定行为

“注意不要误触写操作"是一条建议，模型会在它认为必要时权衡后越过。“所有写操作默认禁止，除非本任务书显式列出豁免端点"是一条规则，模型会当硬约束执行，并且在想做写操作时来问你。同一件事，前者的违规率明显高于后者。规则层的措辞不是文风问题。

授权范围

本工作区仅用于已书面授权的安全测试。授权书：targets//scope.md

白名单以 scope.md 为准；任何不在白名单内的主机、域名、AppID，禁止发起任何请求。

红线（默认禁止，需任务书显式豁免）

1. 写操作：下单 / 支付 / 改密 / 删除 / 发消息 / 催单 / 提交表单 —— 一律禁止

2. 验证码类接口（短信 / 邮件 / 语音） —— 一律禁止触发

3. 速率：请求间隔 >= 1.2s；单批 <= 500 次；超出须停下来问

4. 第三方数据：验证性读取 <= 2 条，命中即停，报告内打码

5. 凭证与 PII：不写入 findings.md 正文，不粘贴进对话，不出工作区

6. 破坏性动作：rm / drop / 批量写文件 —— 禁止

工作约定

• 开工前必读：targets//tested.md，memory/patterns.md

• 结论即写：每验证完一个假设立刻追加 tested.md，不要攒到最后

• 大文件不整读：先读 INDEX，再按需取片段（单次 <= 400 行）

• 命中即停：证实一个假设后停止扩大，转人工复核

• 不确定是否越界时：停下来问，不要自行判断

输出格式

• 假设结论写成：ID | 面 | 假设 | 状态 | 证据路径 | 日期

• 命中项必须附证据三件套：原始请求 / 原始响应 / 复现步骤

• 状态只能是 hit / miss / blocked 三者之一

3.3 记忆层：知识怎么沉淀与召回

这是长期价值的来源。第一个目标你只是在用工具，从第三个目标开始，你在用前两个目标的经验。

条目格式：带命中历史和反例

格式不是形式主义。命中历史让你知道这条模式的可信度，命中三次和命中一次权重不同。反例防止记忆层污染——一条被过度泛化的错误模式会误导后续所有项目，而且因为它写在记忆里、每次都被读，错误会被反复强化。

P-012 分发器信任请求体自报身份

形态 网关 / 分发器把请求体里的 userId / userName 当可信身份，

转发给下游时直接透传，下游不再复验。

触发条件 微服务架构 + 网关统一鉴权 + 下游以"内网可信"为前提设计。

单体应用或下游独立校验的，不成立。

检测步骤 1) 从流量里找同时含 token 和自报身份字段的请求

2) 保持 token 不变，只改自报字段

3) 调一个返回用户私有数据的查询接口

4) 看返回是否为他人数据

命中历史 OTA-A（2026-08，高危） OTA-B（2026-09，高危）

反例 金融类目标 F-1：网关用 HMAC 把 userId 绑进签名，改字段签名即失效。

凡是请求里带签名字段的，先逆签名算法，不要直接试改。

优先级 高 —— 新目标若命中触发条件，建议排进前三个测试面

读 memory/patterns.md 和 targets//threat-model.md。

基于这个目标的架构特征，从 patterns 里挑出最可能命中的 5 条，

按触发条件吻合度排序。每条给出：

• 模式编号与名称

• 为什么认为本目标吻合（指向 threat-model 里的具体依据）

• 在本目标上的第一个验证动作是什么

• 反例条件在本目标上是否成立（若成立，降级或排除）

不要输出泛泛的安全建议，只输出这 5 条的排序和依据。

这一步是冷启动从天级掉到小时级的直接原因。以 P-012 为例，在一个 OTA 目标上成立之后，下一个同类目标直接把它排进前三个测试面，第一天就复现了同类问题。省掉的是原本需要一两天的摸架构、猜薄弱面。

第五部分那个 Electron 案例也进了记忆层，条目大意是"preload 全域注入 + 外链应用内打开 = UXSS 可升级为 RCE”，触发条件写的是"Electron 客户端 + 应用内浏览器 + 有社交外链入口”。这条在后面两个桌面端目标上都被优先排查过，一次命中、一次否定——否定的那次同样有价值，它让我们把触发条件收窄了。

3.4 能力层：MCP、索引策略、三层护栏

这一层决定模型有没有手。MCP 把工具包装成模型可以直接调用的原子能力。没有它，模型只能写脚本给你、你去执行、再把结果贴回来，人是瓶颈，一轮循环几分钟。有了它，它自己调、自己看结果、自己决定下一步，一轮几秒钟。在"枚举 200 个 handler 逐个验证"这类任务上，这是质变。

MCP 到底是什么，以及它的隐性成本

说穿了就是一个约定好的 JSON-RPC 2.0 通道：终端（客户端）启动你声明的服务器进程，走 stdio 或 HTTP 通信，先 initialize 握手，再 tools/list 把工具清单和每个工具的 JSON Schema 拉回来，之后模型每次用工具就是一次 tools/call。服务器可以是二十行 Python，也可以是一整个 Burp 扩展。

要紧的是那份工具清单的位置——它是常驻上下文的一部分。每个工具的名字、描述、参数 schema 加起来，少则几十 token，带复杂参数的能到两三百。装一个暴露 30 多个工具的服务器，光工具定义就可能吃掉四到八千 token，而且每一轮对话都在那儿占着。这就给了"该装哪些 MCP"一个定量判据：

与形态无关的最小配置只有两个服务器：

{

“mcpServers”: {

“capture-query”: {

“command”: “python3”,

“args”: [“tools/mitm-addons/query_server.py”],

“env”: { “INDEX”: “targets/${TARGET}/capture/index.jsonl” }

},

“code-search”: {

“command”: “python3”,

“args”: [“tools/search/rg_server.py”],

“env”: { “ROOT”: “targets/${TARGET}/decompiled” }

}

}

}

一个查抓包索引，一个查代码，都只返回片段不返回全量。形态专用的 MCP（浏览器、jadx、Frida 等）在第四到第六部分分别给出。

三层 scope 护栏

1.4 说过，边界靠提示词守不住。能在工具层拦的就别只写进规则文件。授权范围应该同时落在三个地方，任何一层单独失效都还有兜底：

第 2 层：只处理白名单主机，其余直接放行不落盘

mitmdump –listen-port 8080 \

–set allow_hosts=’^(.*\)?target\.example\.com$’ \

–set anticomp=true \

–set hardump=session.har \

-s ./tools/mitm-addons/index_dump.py

第 3 层：出站硬断，写进 addon

from mitmproxy import ctx

SCOPE = {“api.example.com”, “m.example.com”}

def server_connect(data):

if data.server.address[0] not in SCOPE:

data.server.error = “out of scope” # 连接直接被杀

ctx.log.warn(f"BLOCKED {data.server.address[0]}”)

第 3 层是兜底，它拦的是"配置写错了"和"模型绕过了上层"这两种情况。实际跑起来它触发得不多，但触发的那几次都是真事故——有一次是我们自己在 allow_hosts 正则里漏了转义，. 匹配到了别的域名，第 3 层把它挡下来了。

抓包落盘要结构化

装 CA、配代理是基础操作。真正影响效率的是落盘格式。直接让模型读 mitmproxy 的 flow 文件是灾难：二进制、体量大、一次读进去上下文就满了。正确做法是用 addon 在抓包时就把每条流压成一行 JSON，模型用检索的方式去查。

tools/mitm-addons/index_dump.py 要点

import json, hashlib, pathlib

from mitmproxy import http

SCOPE = {“api.example.com”, “m.example.com”}

OUT = pathlib.Path(“capture/index.jsonl”).open(“a”)

REDACT = (“authorization”, “cookie”, “x-token”, “set-cookie”)

def response(flow: http.HTTPFlow):

if flow.request.pretty_host not in SCOPE:

return # 范围外不落盘

body = flow.request.get_text(strict=False) or "”

rec = {

“ts”: flow.request.timestamp_start,

“method”: flow.request.method,

“host”: flow.request.pretty_host,

“path”: flow.request.path.split("?")[0],

参数只留 key，value 不落盘，避免 PII 进索引

“q_keys”: sorted(flow.request.query.keys()),

“b_keys”: sorted(json.loads(body).keys())

if body.startswith("{") else [],

凭证只留指纹，用于判断是否同一身份，不留原文

“auth_fp”: {h: hashlib.sha256(

flow.request.headers[h].encode()).hexdigest()[:12]

for h in REDACT if h in flow.request.headers},

“status”: flow.response.status_code,

“len”: len(flow.response.content or b""),

原始流单独存，索引里只给路径，需要时才取

“raw”: f"flows/{flow.id}.raw",

}

OUT.write(json.dumps(rec, ensure_ascii=False) + “\n”); OUT.flush()

三个设计要点，每一个都对应一类真实事故：

▪ 白名单在落盘时生效。 范围外的流量根本不落盘，从源头杜绝"测试数据里混进无关目标"这个合规问题。

▪ 参数只留 key 不留 value。 模型要的是"这个接口收哪些字段"，不是字段的值。值里混着手机号、身份证、订单号，不落盘就不会泄露。

▪ 凭证留指纹不留原文。 判断"这两个请求是不是同一身份发的"只需要指纹相等，不需要看到 token 本身。

索引策略

这一条是能力层最重要的实践，也是最容易被跳过的。反编译一个中型 APP 会出几千个 Java 文件、几百 MB；解包一个小程序会出几百个 JS 文件。整份喂进去，上下文瞬间爆掉，而且模型会淹没在无关代码里。

算一笔账就明白了。一条抓包索引记录压成 JSON 大约 150 到 250 token，一千条流量就是二十万 token 上下——整读一次索引就把窗口占满了，更别说原始流。反编译产物更夸张：一个中型 APP 出来的 Java 源码通常在千万 token 量级，比任何模型的窗口都大三个数量级。所以这里没有"塞进去"这个选项，只有"检索"这一个选项。

▪ 先建索引，让模型看目录。 生成文件路径、大小、包名、首若干行摘要，以及关键词命中统计。这份索引通常只有几百行，几千 token。

▪ 让模型自己决定读哪个，按片段取。 它读完索引后说"我要看 com/x/net/SignUtil.java 的 40 到 120 行"，检索工具只返回这一段。单次任务的 token 能降一个数量级。

文件清单 + 大小 + 首行

fd -e java . decompiled/ -x sh -c \

‘printf “%s\t%s\t%s\n” “$1” “$(wc -c <”$1")" “$(sed -n 2p “$1”)”’ _ {} \

decompiled/INDEX.tsv

关键词热力：决定先看哪几个文件

for kw in http encrypt sign token secret exported WebView \

addJavascriptInterface setAllowUniversalAccessFromFileURLs; do

echo “## $kw”; rg -l –no-heading “$kw” decompiled/ | head -30

done > decompiled/INDEX-keywords.md

关键词热力这一步别小看，实战中不止一次靠 INDEX-keywords.md 里"某类关键词命中数明显多于 manifest 里声明的路由数"这种异常热力，直接定位到隐藏路由。

3.5 台账层：假设矩阵

最容易被当成文档工作而跳过的一步，实际上是省钱第一手段。我们一个目标累计 88 个测试节点，其中约六成是否定结果。

格式必须是固定列的表，不能是自由散文。模型要能可靠地解析它、追加它、按状态过滤它。

| ID | 面 | 假设 | 状态 | 证据 | 日期 |

|——-|———–|———————————|———-|——————|——-|

| H-001 | 订单查询 | orderId 可遍历，无归属校验 | hit | ev/H-001/ | 09-12 |

| H-002 | 订单查询 | 改 userId 自报字段可越权 | miss | 网关签名绑定 | 09-12 |

| H-003 | 分发器 | 下游不复验网关身份 | hit | ev/H-003/ | 09-13 |

| H-004 | 文件上传 | 扩展名校验可绕（大小写/双扩展） | miss | 服务端白名单 | 09-13 |

| H-005 | 文件上传 | 上传路径可穿越 | blocked | WAF 拦截，未穿透 | 09-13 |

| H-006 | 用户中心 | 头像 URL 可 SSRF | miss | 仅取白名单域 | 09-14 |

3.6 并行子 agent

单线程跑测试浪费了智能体八成的价值。但并行的收益上限不由本地算力决定，由目标侧风控决定。

主控负责判断和整合：读台账、选面、拆任务、复核结论、决定停或继续。子 agent 负责执行：在一个窄范围里枚举、验证、回报。每个子 agent 有独立上下文和独立请求预算，用完即弃。

上下文隔离才是并行的主要价值，比"同时跑得更快"重要得多。主控会话如果自己去枚举 200 个 handler，工具返回会把上下文撑爆，到后面它已经不记得自己在找什么了——这就是"AI 开始失忆"的典型成因。换成子 agent，那几万 token 的探索垃圾留在子 agent 的上下文里，回到主控的只有一张几百 token 的结论表。主控的上下文因此能一直保持清醒，跑一整天也不迷路。

任务书的四个要素

目标

targets//assets/routes.md 中标记为 [order-family] 的 6 个端点。

只测这 6 个，不得扩展到任何其他端点。

红线（本任务适用，不得违反）

• 只读。禁止任何写操作，包括但不限于下单、取消、修改

• 请求间隔 >= 1.2s，本任务请求上限 120 次，用完即停

• 第三方数据命中后立即停止，最多读取 2 条

已否定，不要重复测

• H-002 改 userId 自报字段（网关签名绑定，改即失效）

• H-004 上传扩展名绕过（服务端白名单）

步骤

1. 用 capture-query 取这 6 个端点的真实请求模板

2. 对每个端点，列出所有客户端可控的参数（对照 assets/identity.md）

3. 对每个可控参数，构造一次"改为他人可能值"的请求

4. 比对响应：状态码、长度、是否含他人标识字段

命中判据

响应中出现不属于当前测试账号的业务标识（订单号 / 手机号 / 姓名）即为命中。

命中后立即停止本任务，回报以下内容，不要继续测剩余端点。

回报格式

| 端点 | 参数 | 结论 hit/miss/blocked | 证据文件 | 已用请求数 |

外加一段 100 字以内的判断说明。不要给安全建议，不要给修复方案。

分片原则

▪ 按业务线切（火车一个、酒店一个）或按攻击面切（分发器一个、存储类一个）。两种切法不要混用，混用会出现同一个端点被两个分片覆盖。

▪ 分片之间不能有重叠端点。同端点并发会互相踩响应，两边都拿到污染数据、得出错误结论，同时更容易触发风控。派发前把各分片的端点列表求交集，非空就拒绝派发——这一步可以脚本化，十行代码的事。

▪ 并发度受目标侧限制，经验值 3 到 5 路。判据是全局请求速率是否仍在红线内：5 个子 agent 各自守 1.2 秒间隔，合起来就是 4 请求每秒，很可能已经超了目标能容忍的阈值。速率红线按全局算，不是按单个 agent 算，这一条我们靠一次封 IP 才记住。

两个必须防住的失败模式

3.7 验收清单

搭完不要直接上真实目标。先逐条验，每一条都是一个可观测的行为，不是"装好了没有"。

1. 主备模型各跑通一次真实工具调用。不是对话通了就算，要让它实际调用一次 Read 或 MCP 工具并返回正确结果。兼容层的坑几乎都出在工具调用上。

2. 新会话里让模型复述红线。问"本工作区禁止哪些操作"，它应该能准确列出六条。列不全说明规则文件没被读进去，或者写得太长被稀释了。

3. 代理能抓到目标明文，且白名单生效。访问一个非目标站点，检查它没有落盘。

4. 三层护栏各验一次。让模型去访问一个范围外域名，确认它在客户端层就被拦住；关掉第 1 层再试一次，确认第 2、3 层能兜住。

5. 模型能从索引里检索出指定接口。给它一个接口名，让它返回请求模板和参数列表。这验证的是索引可用性，不是抓包可用性。

6. 模型能读 memory 并输出模式预测。用 3.3 的冷启动提示词，看它能否给出 5 条排序和依据。空泛的输出说明记忆层条目写得不够具体。

7. 一次子 agent 派发能回收结构化结论。派一个最小任务，检查回报是否符合任务书要求的表格格式、是否守住了请求上限。

8. 台账能影响行为。 在 tested.md 里塞一条假的 miss 记录，让模型规划下一轮，它应该主动说"H-00X 已否定，本轮跳过"。

9. 大文件不被整读。给一个 5000 行的文件，看它是先读索引还是直接整读。

第 8 条最重要。其余各条验证的是零件装好了，只有这一条验证回路接通了。台账写了但没被读，机制就是开环的，前面所有投入都收不回来。

第四部分：Web 端

三种形态里最好下手的。浏览器本身就是最好的调试器，工具链最成熟，模型的接入点也最多。核心思路是让它自己驾驶浏览器：自己点、自己填、自己读结果、自己判断，人只在最后复核证据。

4.1 Chrome DevTools MCP

Google 官方出的 MCP 服务器，底层用 Puppeteer 驱动 Chrome、用 DevTools 前端做分析，通信走 CDP。它的设计原则里有两条对安全测试很关键：返回语义摘要而不是原始数据流，重资产（截图、trace）返回文件路径而不是内容。这意味着它天然不是一个"把完整 HTTP 报文喂给你"的工具。

{

“mcpServers”: {

“chrome-devtools”: {

“command”: “npx”,

“args”: ["-y", “chrome-devtools-mcp@latest”,

“–isolated=true”,

“–allowedUrlPattern=https://.target.example.com/”,

“–proxyServer=http://127.0.0.1:8080”,

“–acceptInsecureCerts”,

“–redactNetworkHeaders”,

“–no-performance-crux”,

“–no-usage-statistics”]

}

}

}

一行装的版本是 claude mcp add chrome-devtools –scope user npx chrome-devtools-mcp@latest，但授权测试建议用上面这份带参数的，原因见本节末尾的默认行为清单。

常用工具

为什么 snapshot 比 screenshot 重要

这是装完 MCP 之后最容易忽略的效率差，而且差得不小。

截图是像素。模型要先做视觉识别才知道登录按钮在哪，图像 token 按尺寸算，一张 1500×960 的截图就是一两千 token，认错了还得重来。snapshot 是无障碍树，模型直接拿到元素的角色、可访问名和引用 ID，下一步可以精确地说"点 uid=42 这个按钮"——同样一个页面，结构树通常只要几百 token，而且没有歧义。

实践约定：每步操作前 snapshot 确认状态，操作后再 snapshot 确认结果，截图只在需要留证据时用。真要截图，记得图像 token 随尺寸而非文件字节数增长，用 JPEG 或 WebP 比 PNG 小三到五倍。

它不能改包

这是把它用于安全测试时最大的坑，也是官方明确记录的限制：目前没有任何自动化途径通过 Chrome DevTools MCP 拦截和修改网络请求。

底层其实做得到——CDP 有 Fetch 域，Puppeteer 也有请求拦截 API——但这套能力没有被这个 MCP 暴露成工具。社区有 PR 在做，截至该 issue 没有维护者表态。所以别指望它，架构上必须分工：

把它们当成一个工具用，结果就是两头都做不好。

几个必须知道的默认行为

▪ 性能工具会外发 URL。 trace 可能被发给 Google 的 CrUX API。授权测试里务必加 –no-performance-crux，否则目标 URL 会流出去。

▪ 遥测默认开启，且与 Chrome 浏览器自己的遥测独立，退出一个不影响另一个。加 –no-usage-statistics。

▪ 不能以 root 运行。 Chrome 以 root 身份会立即退出，容器和 CI 镜像里常踩。镜像里建个非特权用户切过去。

▪ 沙箱会冲突。 启用了 macOS Seatbelt 或 Linux 容器沙箱时它起不了 Chrome，变通办法是连一个沙箱外手动启动的 Chrome（–browser-url=http://127.0.0.1:9222）。

▪ 开远程调试端口有风险。 官方明确警告：机器上任何应用都能连这个端口并控制浏览器。用完关掉。

4.2 改包这一半交给谁

三个选项，按"是否官方 + 可审计性"排序。

Burp Suite：有官方 MCP

PortSwigger 自己出的扩展，BApp Store 上架，Professional 和 Community 都能用，只有 Collaborator 相关的两个工具限 Pro。构建后在 Extensions 里加载 JAR，默认监听 127.0.0.1:9876。

Caido：官方没做，社区版能力更全

Caido 官方博客明确说自己没有官方 MCP，博客介绍的是社区实现，通过 GraphQL 和本地实例通信，README 列了 66 个工具。能力覆盖请求重放、会话管理、fuzzing、findings、拦截、改包规则、WebSocket，还有 caido_is_in_scope 这类让模型自己做范围校验的工具。

Caido 官方博客里有个论点值得直接搬进内部规范：agent 干的活会落进 Caido 的 History、Sitemap 和 Replay collection 并持久化，团队可以事后审阅，而不是只剩一段聊天记录。对授权测试的可审计性来说，这比多几个工具重要。

mitmproxy：轻量、可编程、适合自建

社区有 mitmproxy 的 MCP 实现，工具包括 set_scope、search_traffic、replay_flow、add_interception_rule、export_openapi_spec（从流量反推 OpenAPI）、detect_auth_pattern。但更常见的做法是不用 MCP，直接按 3.4 那样写 addon 落盘成 jsonl，再用自己的检索服务暴露给模型。可控性更好，而且护栏是自己写的。我们内部用的就是这条路。

4.3 前端 JS 白盒：把压缩代码变成两张表

现代 SPA 的路由表、权限判断、加密逻辑全在前端。这是黑盒测试里最接近白盒的材料，而且不需要任何逆向。三条路径，按产出质量排序。

一、source map 还原

很多线上应用会把 .map 一起发出来。source map 本身就是一个 JSON：sources 是原始文件路径列表，sourcesContent 直接内联了原始源码，mappings 是 Base64 VLQ 编码的位置映射。只要 sourcesContent 在，还原出来的就是打包前的真实源码，连注释都在。

go install github.com/denandz/sourcemapper@latest

sourcemapper -output ./src -url https://target/assets/app.js.map

sourcemapper -output ./src -jsurl https://target/assets/app.js # 自动跟进 .map 引用

sourcemapper -output ./src -dir ./maps # 批量

带鉴权 / 走代理留痕

sourcemapper -output ./src -jsurl https://target/app.js \

-header “Cookie: session=…” -proxy http://127.0.0.1:8080

还原出来是带原始文件名和目录结构的源码。到这一步就回到普通白盒审计了，可以直接套 4.5 那套三阶段流程。

二、AST 提取（没有 map 时的主力）

jsluice 用 tree-sitter 解析语法树，去找 URL 已知会被使用的位置，比如赋给 document.location、传给 fetch() 或 window.open()。

它和正则工具的本质差别是理解字符串拼接：无法静态求值的表达式会被替换成 EXPR 占位符。一句拼接模板字符串的 fetch("/api/v2/users/" + id + “/roles”) 会被还原成 /api/v2/users/EXPR/roles。重建 API 路由表时这一点价值极大，纯正则做不到——正则看到的是一堆模板字符串碎片，AST 看到的是一条路由。

go install github.com/BishopFox/jsluice/cmd/jsluice@latest

jsluice urls –resolve-paths https://target app.js # 结构化 JSON：url / queryParams / method / type / source

jsluice secrets app.js

三、正则兜底与交叉验证

LinkFinder 用四条正则分别匹配完整 URL、绝对路径、带斜杠和不带斜杠的相对路径。对压缩混淆后的拼接路径几乎无效、噪声大，但作为交叉验证的第二来源还是有用的——jsluice 漏掉的偶尔能被它捞到。Burp 侧对应的是 JS Miner 扩展，能被动扫描并主动猜测 .map 文件，误报较多，需要人工复核。

这一步真正要产出的是两张表

第二张表是后续所有越权类假设的来源，也是 3.3 那条 P-012 模式的检测入口。做完这两张表，后面的测试就从"不知道从哪下手"变成了"按表逐行验证"。

4.4 一条完整的越权验证链路

把前面三节拼起来，一个真实形状的闭环长这样：

①到⑤模型自己走完，人只做⑥。第 ⑥ 步的"立即停"是规则层强制的：证明越权成立只需要一条记录，继续拉取就从测试变成了数据获取，这是定性差别不是程度差别。

第 ③ 步值得单独说一句，因为它是压误报的关键。静态结论说"这个字段是客户端自报的"，动态确认"它确实存在且值可改"，两边对上了才进入第 ④ 步。只有静态结论就直接去改包，误报率会高很多——打包工具留下的死代码、被 feature flag 关掉的分支，静态看都像真的。

4.5 别让模型自己判断有没有漏洞

这一节讲的是 token 预算里那 20% 到 30% 的验证环节。Web 端是三种形态里最容易把验证做扎实的，因为浏览器能给出确定性答案。

确定性验证：XBOW 的做法

XBOW 在 2025 年 6 月成为 HackerOne 美国区排行榜第一名，是首个登顶的自主 AI。它公开的架构细节不多，但验证环节说得很清楚：自建了一组 validator，逐条确认每个发现。

XSS 的验证方式是让一个无头浏览器访问目标，确认 JavaScript payload 是否真的被执行了。不是让模型判断"这里看起来能 XSS"，而是让浏览器给出一个二值答案。

把这个思路搬到工作台上：凡是能写成"确定性检查"的判据，就不要留给模型判断。

这些都能写进任务书的命中判据里，写成可判定的条件而不是"看起来可疑"。

对抗性自审：让同一个模型去证伪自己

Andrew Hoffman 用 Claude Code 做白盒审计时的三阶段方法值得直接抄，尤其是第二阶段：

他在 WordPress 4.7 上跑出了 CVE-2017-6818（tags-box.js 里的 DOM XSS），置信度中等，CVSS 估 5.4，CWE-79 归类正确。但他同时记录了一个更有价值的失败：Claude 引用了据称存在于 4.7 的缓解过滤器，而那些过滤器只存在于后续版本。这是"自信的错误分析"的教科书例子。他初始报告的三个发现里，有两个在对抗性复审中被自己证伪。

对抗性自审之所以有效，利用的正是 1.6 里那条"默认顺从"。正着问"这个发现对吗"，模型顺着你确认；反着问"请证明这个发现是错的"，同一个倾向就变成了对自己结论的攻击。代价只是多一轮 token，收益是误报率显著下降。建议换不同措辞多跑几次。

一个可以随便打的靶场

XBOW 开源了它的 validation-benchmarks：104 个 CTF 式 Web 挑战，每个有隐藏 flag，Docker Compose 一键起，flag 在构建时注入而不是硬编码。仓库自己警告只在隔离环境使用。

这东西对内部落地很有用：现成的、合法的、可自托管的靶场，用来评估自己的 agent 流程、调提示词、练手感，全程不用碰真实目标。PentestGPT 在 2025 年 12 月的实验里对这套 benchmark 拿到 86.5% 的成功率（90/104），可以作为参照基线。需要注意的是这套 benchmark 截至 2026 年中已被标记为过时，性能基本饱和——它现在适合练手，不适合用来证明谁更强。

4.6 优缺点与红线

第五部分：客户端：小程序与 Electron

这类目标处在 Web 和 APP 之间：代码打包在本地，但不编译成机器码，提取出来就是能读的 JS。它们还有一个共同特点——鉴权往往比 Web 端更弱，因为开发者默认"客户端是我写的、用户改不了"。这个假设在 Web 上大家已经不敢做了，在小程序和 Electron 上还相当普遍。本部分最后那个案例，根因说到底就是这个假设。

5.1 wxapkg 的结构与解密

格式很简单，全文件大端序，14 字节固定头加一个索引区，数据区是明文未压缩的原始内容。

PC 微信落盘的包在这之外多一层加密：文件头 6 字节是 V1MMWX 标志，随后 1024 字节走 AES-256-CBC，其余部分是单字节 XOR。

密钥派生 key = PBKDF2(password = AppID, salt = b’saltiest’,

dkLen = 32, count = 1000, hmac = SHA1)

IV b’the iv: 16 bytes’ # 固定 16 字节字符串

XOR key AppID 倒数第二个字符的 ASCII

拼接 originData[0:1023] + xorData # 注意是 1023 不是 1024

最后那个 1023 是实现上的经典坑：AES 段解出来是 1024 字节，但拼接时只取前 1023 字节，写成 1024 整个包就解不开。所有能跑通的解包器都是这么写的，照抄就行。AppID 就是 {wxid} 目录名，解密所需的全部素材都在路径里。

包在哪

微信 4.0 是个分水岭，PC 端的路径从文档目录搬到了 AppData。

Windows < 4.0

C:\Users\<用户>\Documents\WeChat Files\Applet\<wxid>\<n>\__APP__.wxapkg

Windows >= 4.0

C:\Users\<用户>\AppData\Roaming\Tencent\xwechat\radium\Applet\packages\<wxid>\<n>\__APP__.wxapkg

macOS >= 4.0

~/Library/Containers/com.tencent.xinWeChat/Data/Documents/app_data/radium/Applet/packages/<wxid>/<n>/

Android

/data/data/com.tencent.mm/MicroMsg/<userHash>/appbrand/pkg/

解包时最容易漏的一件事：分包

同一个 <wxid>/<n>/ 目录下常有多个 .wxapkg。主包有 2MB 上限，开发者会把低频但敏感的功能——后台管理、支付、实名认证——塞进分包。只解主包会得出"这个小程序几乎没有接口"的错误结论，而恰好分包里放的才是值钱的东西。

老的 wxappUnpacker 需要先解主包、再带 -s 指向主包输出目录解分包，因为 $gwx、公共样式和 app-config.json 都在主包里。新工具（wedecode、unveilr）会自动合并，但要求把主包和分包放在同一目录。

5.2 解包工具与代码还原

npm i wedecode -g

wedecode # 交互式，自动扫描本机小程序

wedecode ./ –out output_path –clear –open-dir

wedecode ./name.wxapkg –unpack-only # 只解包不反编译

npm i unveilr -g

unveilr wx /path/to/wxapkg/ -i wx11aa22bb33cc44dd -f

解出来是什么

小程序是双线程架构：WXML 和 WXSS 在渲染层（WebView），JS 在逻辑层（JSCore），两者经微信客户端中转。编译产物就按这个分成两大块。

路由表和签名函数藏在哪

▪ 路由表在三处：app-config.json 的 pages / subPackages；一个集中的 config.js 或 api.js（找 baseURL / BASE_API 这类常量）；各页面的 wx.request({url: …}) 调用点。

▪ 签名函数不要挨个文件翻。先 grep 关键词（sign / hmac / CryptoJS / nonce / timestamp / appSecret），然后找 wx.request 的统一封装层——签名基本都在那里往 header 里塞，顺着调用链回溯就能定位。

▪ 还原出来的典型形状是参数字典序拼接加时间戳加固定盐再 MD5。这类算法还原是模型很擅长的活，第七部分有对应的提问模板，关键是那句"无法确定的部分必须标注，不要用常见做法补全"。

5.3 抓包：为什么要上 Proxifier

PC 微信的小程序渲染进程 WeChatAppEx.exe 不走 Windows 系统代理。只设系统代理，Burp 里什么都看不到。需要 Proxifier 在系统层面按进程强制把流量推进代理。

1. 定位进程　任务管理器找 WeChatAppEx，右键打开文件位置拿完整路径。主进程是 Weixin.exe（旧版 WeChat.exe），连主进程一起加进规则更稳。

2. Proxifier 规则　Proxy Servers 里填 127.0.0.1:8080，协议选 HTTPS；Proxification Rules 里新建一条，Applications 填上一步的 exe，Action 指向该代理，默认规则保持 Direct。

3. 证书　Burp 的 cacert.der 改名 .cer，用 certmgr.msc 导入受信任的根证书颁发机构，不是"个人"。

小程序有没有证书固定

微信官方文档写得很明确：小程序只能与配置在后台的合法域名通信，仅支持 https 和 wss，服务器证书必须由受信任 CA 签发、域名匹配、在有效期内、证书链完整，iOS 不支持自签名。这是标准 CA 校验，不是 SSL Pinning。所以只要 Burp 的 CA 进了系统受信任根，PC 端小程序流量就能解密。

开发者工具里那个"不校验合法域名、TLS 版本以及 HTTPS 证书"的开关是开发期用的，只在开发者工具和真机调试模式下生效。我们没有找到权威资料证明小程序运行时做了额外的 pinning。但要注意另一回事：不少业务方会在小程序 JS 层做应用层加密，请求体加密加签名，抓到包也读不懂。那是 5.2 说的签名还原问题，和传输层 pinning 是两码事，别混为一谈。

开调试模式

三条路线，都是社区方案，没有官方支持，而且都强依赖微信版本。

5.4 自动化：UIA 是唯一通路

想在真实小程序里自动操作（登录、翻页、走业务流程），第一反应通常是合成鼠标键盘事件。这条路走不通。但原因和常见说法不太一样，值得说准确一点，因为它决定了对策。

所以准确的说法是：不是"微信过滤了 SendInput"，而是微信可以通过 LLKHF_INJECTED 区分合成输入，且 4.1.5+ 默认对未识别的 UIA 客户端隐藏控件树。因此坐标式合成输入不可靠，要走 UIA，而且得先让微信认出你是无障碍客户端。公开的做法有三种：写一个最小 C# UIA 客户端正确引入那两个 DLL 并 attach；先启动讲述人再跑脚本（兼容性差）；或在启动自动化框架前做进程级配置。

UIA 怎么用

UIA 的关键在于它不模拟输入，而是直接调用控件自己暴露的 provider 接口——InvokePattern.Invoke() 相当于替按钮执行它的"被点击"逻辑，全程不产生鼠标事件，所以前面那些检测都不适用。

1. 定位窗口 —— 用类名而不是标题，标题会随页面变

win = auto.WindowControl(searchDepth=1, ClassName=‘Chrome_WidgetWin_0’)

2. 等渲染 —— 小程序异步渲染，控件树会迟到

不要 sleep 固定时长，轮询目标控件出现

btn = win.ButtonControl(Name=‘我的订单’)

if not btn.Exists(maxSearchSeconds=8, searchIntervalSeconds=0.3):

raise RuntimeError(‘控件未出现，页面可能未加载完’)

3. 点击 —— 用 InvokePattern，不要用坐标

btn.GetInvokePattern().Invoke()

4. 输入 —— ValuePattern 比模拟键盘可靠

win.EditControl(Name=‘搜索’).GetValuePattern().SetValue(‘测试关键词’)

两条稳定性经验，都是修脚本修出来的：

▪ 控件命名不稳定。 同一个按钮在不同版本里 Name 可能变。用相对定位加文本模糊匹配：先定位到稳定的父容器，再在其中按文本片段找。写死的绝对路径在小程序上基本活不过一次版本更新。

▪ 分层查找，别从根遍历。 uiautomation 从根搜一个深层控件可能要几百次匹配，逐层缩小 searchDepth 只要几次。写脚本前先用库自带的 automation.py -t 0 把控件树和每个控件支持的 Pattern 打出来。

官方 SDK 为什么用不上

微信有官方自动化方案 miniprogram-automator，能力不弱：控制跳转、读页面数据、触发元素事件、往 AppService 注入代码、callWxMethod 调用任意 wx 接口、mockWxMethod 打桩。

但它要求 projectPath 指向一个能在开发者工具里正常编译的小程序工程，也就是含 project.config.json 的源码目录。所以测自己的小程序，官方 SDK 是最佳方案；测别人的小程序只有 wxapkg，官方 SDK 用不了，除非先反编译出可编译工程再导入，而那时 AppID 不匹配，云函数、支付、授权类接口都会失败。腾讯还有个 Python 方案 Minium，支持原生控件（授权弹窗、地图、相机），但同样从开发者工具驱动。

5.5 Electron

本质是打包的 Chromium。找到安装目录里的 app.asar 解开就是全部前端源码。格式极简，无压缩、支持随机访问：一个 8 字节的 Pickle 头给出 header 长度，header 本身是一段 JSON，剩下是数据区。

npx asar list app.asar

npx asar extract app.asar ./unpacked

npx asar extract-file app.asar main.js # 只取一个

注意 app.asar.unpacked/ 目录也要看：

打包时用 –unpack 排除的文件放在这，原生 .node 模块一定在这里

header JSON 里每个文件有 offset 和 size。offset 是字符串形式的 UINT64——因为 JS 的 Number 是双精度浮点，安全整数上限 2^53，大包会溢出，所以只能用字符串传。它还是相对数据区的偏移，算真实位置得加上头长度加 header 长度。另外内容相同的文件只存一份，多个条目指向同一 offset，统计文件数的时候别被骗了。

关注点一：webPreferences

这部分是结构化程度很高的检索任务，模型做得很准。让它在解包产物里直接找 BrowserWindow 的构造参数：

最后那一行是本部分案例的根因，值得单独记住：contextIsolation 开着不等于安全，它只隔离了对象，没隔离能力。 真正决定攻击面的是 preload 暴露了什么、暴露给谁。

关注点二：fuses

fuses 是打包时烧进二进制、签名前生效、烧完不可逆的开关。几个和测试直接相关的：

主进程是漏审角落

厂商常把敏感逻辑——本地加密、证书处理、自动更新、本地服务端口——放在主进程，因为"用户看不到”。这部分代码体积大、无人审查，是高产区。package.json 的 main 字段指向的就是它。

方法 A：不改包，加启动参数（首选，打包应用也有效）

open /Applications/YourApp.app –args –remote-debugging-port=8315 # macOS

YourApp.exe –remote-debugging-port=8315 # Windows

然后浏览器开 http://localhost:8315/ 或 chrome://inspect

主进程要用 V8 inspector，窗口内的 DevTools 只能调渲染进程

electron –inspect=9229 your/app

electron –inspect-brk=9229 your/app # 在第一行 JS 断下

方法 B：走代理

electron ./app –proxy-server=127.0.0.1:8080 –ignore-certificate-errors

方法 C：electron-inject，连调试端口后用 CDP 注入，不改包

pip install electron-inject

electron_inject -d -t 60 - /path/to/application # -d 启用 F12 / F5

要让 Electron 应用被 UIA 看见，启动时必须加 –force-renderer-accessibility。这条对 Chrome 也一样。

Electronegativity

Doyensec 出的静态检查工具，基于 AST 和 DOM 解析找安全相关配置，共 38 项检查。可以直接吃 .asar 文件，不用先解包。项目已不再积极维护，官方指向商业版。

npm install @doyensec/electronegativity -g

electronegativity -i app.asar -o out.sarif # SARIF 可接 CI / GitHub code scanning

electronegativity -i /path/to/app -s HIGH -c HIGH

输出里带 GLOBAL 的是跨文件关联检查，比如 HTTP_RESOURCES_WITH_NODE_INTEGRATION_GLOBAL_CHECK 要"加载 HTTP 资源"和"开了 nodeIntegration"两个事实同时成立才报。这类才是高价值发现，让模型读 SARIF 时优先看它们。

5.6 MCP 与优缺点

小程序方向已经有几个现成的 MCP，都是个人项目不是官方：wxapkg-mcp（7 个工具，从 list_wechat_apps 发现 AppID 到 decrypt_and_extract_appid 一步到位）、MCP-WEDECODEMCP（基于 wedecode，scan_local_miniapps → decompile_scanned_miniapp → read_output_file 的对话式流程）、e0e1-wx（带 MCP 的 GUI，包监控、自动反编译、CDP、云函数扫描，配置里列了覆盖的小程序版本号）。

Electron 这边没有专用 MCP。可行的组合是 asar extract 落盘，用文件系统类 MCP 或直接让 Claude Code 读目录，再把 Electronegativity 的 SARIF 喂给模型做风险排序。5.7 那个案例走的就是这条路，没用任何专用工具。

第六部分：APP 端

攻击面最大的一种：本地存储、导出组件、WebView、原生 so、通信加密全都能碰。代价是环境最重，一台 root 的安卓机或模拟器是起步配置。也正因为如此，建议放在最后做。

6.1 静态：jadx 和 apktool 各管一段

两个都要跑，分工很清楚：jadx 用来读懂和定位，apktool 用来改和回编。

先花十秒判断有没有加固

不要一上来就等全量反编译。先只出资源，或者直接 unzip -l 看 lib/ 和 assets/ 的文件名。主流商业加固都有明显的文件名特征（libDexHelper.so、ijiami.、libshell-.so、libjiagu*.so、libxloader.so、libegis.so 这类）。识别出加固就直接跳到 6.5，别浪费半小时。

jadx -s -d out_res target.apk # 只出资源 + manifest，秒级

unzip -l target.apk | grep -E ’lib/|assets/’

jadx 的几个关键 flag

加固 / 混淆包的实战组合

jadx -d out –show-bad-code –deobf –no-imports –no-inline-methods -j 8 target.apk

jadx 官方明确声明：对混淆或加固的 APK 不保证能完整反编译。这是官方立场不是社区吐槽，规划时间时按这个预期算。

MobSF 当基线扫描器

它的价值是筛选不是结论。一键出基线报告，让模型从报告里挑值得深挖的点，比让它从零开始通读省很多。Docker 起，静态分析不需要连设备：

docker run -it –rm -p 8000:8000 opensecurity/mobile-security-framework-mobsf:latest

默认 mobsf/mobsf，API key 在实例自己的 /api_docs 页面

curl -F ‘file=@target.apk’ http://localhost:8000/api/v1/upload -H “Authorization: KEY”

curl -X POST http://localhost:8000/api/v1/scan –data “hash=” -H “Authorization: KEY”

curl -X POST http://localhost:8000/api/v1/report_json –data “hash=” -H “Authorization: KEY”

动态分析要连一台 adb 设备，官方说明只支持到 Android 11（API 30），12 以上不支持。另外它把两件麻烦事 API 化了，接自动化管道时很省事：/api/v1/android/root_ca（装/卸系统 CA）和 /api/v1/android/global_proxy（设/取消全局代理）。还有一组 /api/v1/frida/* 端点，可以把 MobSF 当 Frida 编排器用。

6.2 MCP：xref 才是模型要的东西

这条链上最成熟的一块。jadx-ai-mcp 是跑在 jadx-gui 里的 Java 插件（默认端口 8650），jadx-mcp-server 是 Python 侧的 MCP 服务器（默认 8651）连过去。

jadx plugins –install “github:zinja-coder:jadx-ai-mcp”

uv run jadx_mcp_server.py –http –jadx-host 127.0.0.1 –jadx-port 8650

暴露三十多个工具，按价值排：

设计上有个关键点：它和运行中的 jadx-gui 实例通信，不是重新跑一遍反编译。好处是有 xref、有已加载的符号表；坏处是要先人工把 APK 在 GUI 里打开，而且项目自述还在早期阶段，会崩。

同一作者还有 apktool-mcp-server，13 个工具。注意它包含 modify_smali_file() 和 build_apk()，意味着模型可以直接改 smali 并重打包。接入时要在权限层面做约束，别让它无声地改了你的样本。

6.3 Frida：server 还是 gadget

静态分析只能告诉你"代码里有这么一段判断"，不能告诉你"它在运行时走没走到、参数是什么"。APP 里大量逻辑有多条分支、被开关控制，或者干脆是废弃代码。Frida 把静态的"可能"变成运行时的"确实"，这一步是 APP 形态误报率的主要控制点。

Gadget 有四种交互模式，其中 Script 模式对自动化最有用：自动加载并执行一个独立 JS 文件，不需要 host 端连接。Listen 是默认模式，会阻塞直到有人 attach。

常用 API

Java 层，前两个是日常，后两个是加固包的救命稻草：

const libc = Process.getModuleByName(’libc.so’);

Interceptor.attach(libc.getExportByName(‘read’), {

onEnter(args) { this.fd = args[0].toInt32(); },

onLeave(retval){ if (retval.toInt32() > 0) console.log(‘read’, this.fd); }

});

// 算 so 内偏移的 hook 点

const base = Module.findBaseAddress(’libnative.so’);

Interceptor.attach(base.add(0x1234), { … });

// 脚本用 send() 输出结构化 JSON，host 侧收集 —— 这是接模型的标准接法

send({ type: ‘sign’, input: argStr, output: retStr });

新版 Frida 官方示例已从 Module.findExportByName() 改用 Process.getModuleByName().getExportByName()，过渡期两种都能用。写脚本前先确认目标设备上的 frida 版本——这是"从网上抄的脚本跑不起来"最常见的原因，没有之一。

为什么 Frida 只能改方法边界

这一条直接决定了第七部分那个 APP 提问模板的形状，值得说清楚机制。

Java 层的 hook 是替换方法实现：Frida 拿到目标方法的 ArtMethod，把入口指向自己的桥接代码，原方法整体被接管。Native 层的 Interceptor.attach 是在函数入口处改指令、跳到 trampoline，onEnter / onLeave 分别在进入和返回时插入。两种机制的粒度都是一次调用的边界——参数进来、返回值出去。

方法内部的某一行 if，既不是入口也不是出口，Frida 没有插入点。想改它只能去改指令，那已经是 patch 而不是 hook 了。

所以找 hook 点时要找方法边界：理想的点是一个返回布尔值的独立校验方法，而不是嵌在大函数中间的一个 if。让模型读 jadx 输出时，必须明确要求输出类全名 + 方法名 + 参数签名 + overload + 返回类型，而不是"这里有个校验"。前者可以直接生成 Java.use(…).method.overload(…).implementation = …，后者你还得自己回去翻一遍。

JNI 动态注册的定位

很多商业 APP 的 native 方法通过 RegisterNatives 动态注册，jadx 里只看到 native 声明、看不到实现地址。两个工具解决这件事：

▪ hook RegisterNatives（lasting-yang/frida_hook_libart）。输出直接给出 so 内偏移，拿去 Ghidra 或 IDA 定位。

▪ jnitrace。jnitrace -l libnative-lib.so ，显示 jni.h 里的方法名、参数、buffer hexdump、返回值。-o 出 JSON，这点对接模型很关键，可以直接进索引。

6.4 抓包三件事：CA、NSC、pinning

这三件事经常被混为一谈，但它们是三个独立的问题，解法也不同。

改 NSC 这条路的代价

apktool d -f -o work target.apk

1. 编辑 work/res/xml/network_security_config.xml，加 <certificates

src=“user” />

2. 在 上加

android:networkSecurityConfig="@xml/network_security_config"

apktool b work -o patched.apk

zipalign -p -f 4 patched.apk aligned.apk

apksigner sign –ks my.keystore aligned.apk

重打包会破坏原签名，代价是：触发签名校验类防护、掉 Play Integrity、App Links 的 assetlinks.json 失配。优先选装系统 CA，只有在无 root 设备上才走这条。

objection 到底 hook 了什么

android sslpinning disable 不是"装证书"，是用 Frida 把校验函数改成恒真或空实现。它打七个点，值得知道，因为遇到打不过的情况你得知道漏了哪层：

三层覆盖不同实现路径：换信任源、跳过链校验、跳过 pin 比对，所以要全打。工程化程度更高的是 httptoolkit 那套脚本，它的设计有两点值得学：native-tls-hook.js 改 BoringSSL 让它信任你配置的证书，而不是整个关掉校验（不容易触发应用的异常分支）；以及一个 fallback 脚本，检测到证书校验失败时自动为混淆过的未知 pinning 实现生成补丁。

Flutter 走 BoringSSL 不走系统 CA，必须单独处理。

6.5 加固与脱壳

先分清代际，因为每一代的解法完全不同，投入产出也差很远。

判断代际的第一步是看 6.1 那个文件名特征，第二步是脱完之后用 –show-bad-code 看方法体是不是还空着。

脱壳产物怎么用

▪ 一代壳出一堆完整 DEX。可以直接 jadx -d out dump_dir/.dex，但更好的做法是把它们替换回原 APK 里的 classes.dex 再 zip 回去——这样资源、manifest、R 类都还在，jadx 能正确解析 @string/xxx 引用。

▪ dump 里会混着壳自己的类和大量重复类。先按大小和类数量排序，丢掉明显是壳的那几个。

▪ 二代壳出的是 DEX 加分散的 CodeItem，要按 method_idx 回填合并。这一步高度依赖具体壳和工具产物格式，没有跨工具的通用方案。

验证合并成功与否有两个办法：用 jadx –show-bad-code 打开看关键方法体是不是还是空的或者只有 throw new UnsupportedOperationException；以及运行时用 Java.enumerateLoadedClasses() 对照，确认脱壳产物的类名集合与运行时实际加载的一致。如果大量方法体仍为空，说明是二代壳没回填成功，或者已经是三代了。

反调试与反 Frida

常见检测手法七种，按对抗难度从低到高：

1. 扫默认端口 27042 并做 D-Bus 握手确认

2. 扫 /proc//maps 找 LIBFRIDA、frida-agent 这类字符串

3. 枚举线程名找 gum-js-loop、gmain、pool-frida

4. 读 /proc//fd/* 找 frida 注入时创建的命名管道

5. 读 TracerPid

6. fork 子进程 ptrace 父进程占位，别的调试器就 attach 不上了

7. 把内存里的 .text 段与磁盘上的 so 对比

前六种都能靠改端口、改进程名、重编译去特征（strong-frida 那套 patch 就是干这个）来绕。第七种不行——detectfrida 的作者明确指出这种检测是 frida agnostic 的，改特征字符串绕不过去。评估对抗难度时，看目标有没有做这一种，是判断"值不值得投入"的分界线。

6.6 攻击面清单

这部分是结构化检索，让模型跑在 jadx 输出上效率很高。按产出概率排序。

Manifest

查 deeplink scheme

adb shell dumpsys package | sed -n ‘/Schemes:/,/Non-Data Actions:/p’

触发，然后确认真的跳过去了 —— “Starting Intent” 这一行不够

adb shell am start -a android.intent.action.VIEW -c android.intent.category.BROWSABLE \

-d ‘:///web?url=https://example.com’

adb shell dumpsys activity activities | grep mResumedActivity

显式启动非导出或隐藏的 Activity

adb shell am start -n /.SomeActivity

典型的 deeplink 问题形状是 xxx://host/web?url=<攻击者可控>，把 URL 参数直接喂给 WebView。6.8 那个案例是它的变体，而且更隐蔽——路由压根没在 manifest 里声明。

WebView

致命组合是 setJavaScriptEnabled(true) 加 setAllowUniversalAccessFromFileURLs(true) 再加载外部可控 URL，尤其是从 deeplink 参数来的。

grep -rnE “addJavascriptInterface|setAllowUniversalAccessFromFileURLs|setAllowFileAccessFromFileURLs|setAllowFileAccess|onReceivedSslError|shouldOverrideUrlLoading|loadDataWithBaseURL” out/sources/

onReceivedSslError 里调 handler.proceed() 等于无条件接受任何证书。setAllowFileAccess 在 API 30 起默认从 true 改成了 false，老应用要看 targetSdk。

本地存储与 native

6.7 闭环、优缺点与三形态横评

模型是串起这三个工具的那根线：读反编译结果形成假设、写 hook 脚本验证假设、读抓包结果判定结论。人负责注入、复核和叫停。

现成的 AI 封装

2025 到 2026 年已经形成了几条清楚的路线，都值得先看一眼再决定自己造不造：

/compare-versions 那个值得单独说一句：版本 diff 是模型很擅长、人很痛苦的任务。拿两个版本的 jadx 输出做语义 diff，定位新增或修改的安全相关逻辑，往往能直接指出"厂商最近在改什么”，而这通常就是最新引入问题的位置。

三形态横评

第七部分：提示词

切片选对了、威胁模型建好了，只是进了正确的邻域。到了之后，话怎么说直接决定你拿到的是一堆泛泛观察还是一条能用的发现。这一部分的十条技巧来自 Needle in the Haystack，我们在实战里验证过其中几条，效果差异比预想的大。

7.1 一个原则：搜索模式，不是评估模式

所有技巧都指向同一件事：把模型从评估模式推向搜索模式。

同一段代码，问法不同拿到的东西完全不是一个量级。这不是玄学，是你把它的优化目标改了：分类任务有一个低成本的默认答案，生成任务没有。

7.2 先把威胁模型问出来

在用任何技巧之前先做这一步。它对应 token 预算里那不到 10% 的脚手架，也是后面所有提问的锚点。做法是让模型基于历史 CVE 生成，而不是你自己拍脑袋写。

以下是 [项目名] 的历史 CVE 描述：

[粘贴 GitHub Security Advisories / NVD / 厂商公告里的描述文本]

基于这些漏洞的类型和模式，输出一页纸的威胁模型，必须包含：

1. 最常见的漏洞类别，按历史出现频次排序

2. 最薄弱的信任边界是哪几条，依据是什么

3. 入口点清单：HTTP 路由 / RPC handler / 消息队列 / 文件上传 / 反序列化

4. 攻击者模型：他是谁、有什么凭证、能控制哪些输入

5. 高危操作清单：哪些操作一旦被越权触发后果最严重

不要写通用安全建议。每一条都要能指回上面的 CVE 描述。

输出控制在一页以内。

这一步的产出直接写进 targets//threat-model.md。它的价值在于把后面所有提问的语境补齐——1.1 说过，模型缺的就是这个条件项。

历史 CVE 都是堆溢出和整数溢出，威胁模型就围绕内存损坏建；都是权限绕过，就围绕权限模型建。往同一个方向挖，找到的东西大概率也被维护者接受，因为那本来就是这个项目的薄弱结构。

另一个高产入口：审修复补丁

找到修复某个历史漏洞的 commit，让模型分析那个 patch 能不能绕过。修复代码经常只堵了报告里提到的那个入口，同一根因的其他路径还开着。Anthropic 审 Firefox 的 CVE 时就这么干过：拿 fix commit，让 Claude 看有没有遗漏。

这个入口的好处是范围天然就窄——一个 commit 改了几个文件，切片是现成的。

7.3 十条技巧

按效果排序，前三条是最该先学会的。

01　断言漏洞存在

效果最明显的一条。直接说"这里肯定有两到三个安全问题"，比问"有没有漏洞"的分析质量高一个档次。

模型有很强的顺从和确认倾向。你问"有没有"，它走阻力最小的路；你断言存在，它的优化目标就反过来了——不再评估有没有 bug，而是去搜它被告知存在的 bug。读码方式从扫一眼变成逐行排查。

✗ 这个函数有没有安全问题？

✓ 这个函数里确定存在 2 到 3 个安全问题。逐行找出来，

每个给出：所在行、触发条件、攻击者需要控制什么。

02　要利用路径，不要安全评级

别让模型给"安全性评分"或"风险等级"，让它给一段可执行的验证步骤或完整的利用链。

输出格式变了，思考方式就变了。它开始想攻击者实际能拿到什么、前置条件是什么、这个发现是真的还是理论上的。还有个副作用是好的：对抗性框架让它更愿意说"这个认证机制从根本上就是坏的"，而不是软化成"这里可以改进"。安全结论需要的是前者那种明确程度。

✗ 这里的输入校验是否充分？给个风险等级。

✓ 写一段能绕过这个校验的 PoC。

给出：完整请求、需要的前置条件、预期响应特征。

如果你认为绕不过，说明是哪一条检查挡住了，以及挡住的具体机制。

03　对抗性角色

把"审查代码的安全审计员"换成"被雇来找可利用漏洞的红队"。审计员的优先级是覆盖全面，红队的优先级是打得进去。角色一换，它汇报的东西从"清单"变成"路径"。

✗ 你是一名安全审计员，请审查以下代码。

✓ 你是一名红队，按结果付费，只有可利用的漏洞才算数。

理论问题和最佳实践建议不算交付物，不要写。

04　假锚点

“我已经在这个模块里找到一个漏洞了，但还有没找到的。它们是什么？”

制造一种社会证明压力。模型推断既然一个人类都已经找到一个了，代码确实有问题，它得更使劲找。适合在它倾向于草率收工的时候用：代码很长、前面已经看了很多文件、上下文接近饱和。

✓ 这个模块里我已经确认了一个漏洞，不告诉你是哪个。

还有至少一个我没找到的。找出来。

05　问题反转

把"这个安全吗"换成"你会怎么打破它"。前者要的是一个是非判断，后者要的是攻击导向的生成。同一段代码，后者会逼出前者根本不会提的路径。这条和 01 的差别在于它不预设漏洞数量，适合你自己也不确定有没有东西的场景。

实战中一个有效的问题形态是：不是"这个短链展开器安全吗"，而是"这条展开器还能到达哪些路由"。

✗ 这个会话管理实现安全吗？

✓ 你要打破这个会话管理，从哪下手？按成功概率列出前三条路径。

06　不变量分解

把"列假设"和"判断假设是否被违反"拆成两步问。2.2 讲过原理，这里给操作形式。模型单独做第一步很在行，单独做第二步推理得很深；合在一起问结果通常很浅——它试图同时做两件事，会早早满足于一个及格答案。

✓ 第一步（只做这一件事）

列出这个模块所有隐含的安全假设。只列，不判断是否成立。

每条一行，编号。

✓ 第二步（逐条追问）

假设 #3「只读凭证不能触发写操作」。

在哪条代码路径上这个假设可能被违反？

给出具体函数和行号，以及攻击者需要的前置条件。

07　假设开发者犯了错

“假设开发者在写这个函数时引入了一个 bug，它是什么？”

这跟 01 不同。断言技巧告诉模型 bug 在哪；这条告诉模型代码本身是不完美的，改变的是它对代码质量的先验。LLM 有把代码合理化的倾向：看到一段模式，它倾向于假设这是有意的，然后从设计意图出发去推理。让它假设开发者犯了错，它就会从"这行代码的意图可能和实际行为不符"的角度看——而绝大多数漏洞恰恰就是意图和行为不符。

它连续几次都回"看起来没问题"的时候，用这条重置先验。

08　与标准实现对比

“这个实现和标准的安全实现有什么不同？”

借力它训练数据里的正确模式。它对"标准的 JWT 校验该长什么样"“标准的 Electron 安全配置该长什么样"有很扎实的先验，让它做差异比对，比让它凭空判断对错容易得多。自研加密、自研会话管理、自研签名这类地方尤其有效。第五部分那三张根因卡就是这么出来的。

✓ 把这段 JWT 校验和标准实现逐项对比，列出缺失的检查。

格式：标准做什么 | 这里做了什么 | 缺失的后果。

09　逐层追问

拿到第一批发现之后接着问"还有更隐蔽的吗”，多问几轮。对应 1.6 那条"完整性前置"——模型最有把握的发现排在最前面，细微的 bug 要靠追问才出来。第一轮给的往往是教科书级别的问题，第三轮才开始出真正值钱的东西。

✓ 这些都是比较明显的。还有更隐蔽的吗？

特别关注：边界条件、初始化顺序、异常路径、并发窗口。

10　显式攻击者建模

把攻击者的能力约束写死。这条直接消灭误报：大量"理论漏洞"之所以是理论的，就是因为它需要攻击者已经拿到本地文件读权限、或者已经是管理员。把约束写明，模型就不会再往那些方向跑，同时还会被逼着在更窄的条件下动脑子。

✓ 攻击者模型：远程、未认证、只有 HTTP 访问权限，

不能读本地文件，不能控制服务端环境变量。

在这个约束下重新评估上面每一条发现，划掉不成立的。

7.4 怎么组合

十条不是每次都用。按场景挑，通常两到三条叠加就够：

7.5 形态专用的提问模板

前面三部分各自有一个最关键的提问形态，单独列出来。

Web：把前端 JS 变成两张表

这是目标站点的前端打包产物（已美化）。只做两件事，不要给安全建议。

一、API 清单。逐条输出：

方法 | 路径（无法静态求值的段用 EXPR 占位）| 参数名 | 调用它的页面或模块

二、身份字段分类。把请求里出现的所有身份相关字段分成两类：

A. 服务端下发的（来自登录响应、Set-Cookie、服务端渲染的初始状态）

B. 客户端自报的（来自 localStorage / 表单 / URL 参数 / 前端计算）

对 B 类的每一个，指出它被用在哪些接口上。

输出为两个 markdown 表格。不确定归类的标注"存疑"，不要猜。

小程序：签名算法还原

这是从小程序解包产物里提取的请求封装代码（变量名已被压缩）。

假设这段代码里包含一个请求签名的实现。还原它，给出：

1. 参与签名的字段，以及它们的拼接顺序

2. 用到的常量（盐值、固定前缀、版本号）—— 原样给出，不要改写

3. 摘要算法与编码方式（大小写、是否 base64）

4. 一段可独立运行的 Python 复现代码

对任何无法从代码中确定的部分，明确标注"无法确定"，不要用常见做法补全。

最后那句很重要。签名还原是模型最容易"帮你补全"的地方，补出来的东西看着对、跑起来错，排查起来非常费时间——你会以为是自己抄错了，反复检查代码，其实是那几个字节的盐值它编的。

APP：要可 hook 的方法边界

这是 jadx 反编译产物中与证书校验相关的类。

找出可以被 Frida hook 的方法边界。每个候选给出：

类全名 | 方法名 | 完整参数签名 | 是否有 overload | 返回类型

以及：hook 掉它之后预期的行为变化

只输出独立的、返回值决定分支走向的方法。

嵌在大函数中间的 if 判断不要列 —— Frida 改不了方法内部的单行逻辑。

如果这个类里没有合适的方法边界，明确说没有，

并指出调用链上游哪个方法可能是更好的 hook 点。

这个模板直接对应 6.3 那条机制限制。不加最后两段约束，模型会给你一堆"这里有校验"的位置，你还得自己回去翻一遍。

7.6 反面清单

这些不是风格问题，是会实际降低产出质量的写法。

“不要给修复建议"这条要写进去

模型默认会在每个发现后面附一段修复方案，这部分 token 是纯浪费——授权测试阶段你要的是发现和证据，修复建议在报告阶段由人按厂商模板写。

更麻烦的是连带效应：它一旦进入"给建议"的模式，语气会同步软化成咨询口吻。“这里可以改进"这种表述会掩盖掉"这个机制根本是坏的”。子 agent 任务书模板里那句"不要给安全建议，不要给修复方案"就是干这个的。

还有一条：别让它自己决定范围

“顺便看看相关模块"这种措辞会直接触发 1.2 那个广度优先的毛病，而且在授权测试里还可能越界。任务书里的目标必须精确到端点或文件，并且明写"不得扩展到任何其他端点”。

模型在范围问题上不会保守，只会热心。

第八部分：坑

形态专用的坑已经写在第四到第六部分了，这里只收跨形态的。按现象、根因、解法写，方便后来者对号入座。分四类：模型行为、工程设计、成本、合规。

8.1 模型类

这类坑不会消失，只能用流程持续压制。理解成因比记住解法重要。

上下文爆掉，开始失忆

现象　跑到中后期，它开始重复之前做过的事，或者给出跟前面矛盾的判断，问"我们在找什么"答不上来。

根因　工具返回结果把上下文占满，早期的目标和约束被挤出有效注意力范围。这就是 context rot 的直接表现。

解法　三条一起上：结论即写台账，不依赖上下文记忆；大文件只喂片段走索引；子 agent 用完即弃，把探索垃圾隔离在主控之外。分别对应 3.5、3.4、3.6。

幻觉结论，复现不出来

现象　报了一个"确认的高危漏洞”，人去复现发现根本不存在，或者响应被它误读了。

根因　确认倾向，尤其在你已经暗示"这里应该有问题"之后。子 agent 上下文窄、压力大，幻觉率更高。

解法　证据三件套缺一不可：原始请求、原始响应、复现步骤。没有三件套的一律不进 findings.md。主控必须独立复核每条 hit，复核不过降级为 miss 并记原因——降级记录本身也是有价值的台账条目。再加一道 4.5 的对抗性自审。

问"有没有"，答"整体安全"

现象　问"这个函数有没有漏洞"，得到"整体看起来安全，有一些小的关注点"，然后是一串理论问题。

根因　默认顺从。开放式提问下这是阻力最小的答案。

解法　第七部分那十条，重点是 01 断言存在和 03 对抗性角色。

长会话后期红线被淡忘

现象　跑到第三小时，它开始做第一小时绝不会做的事，比如探一个不在白名单里的子域名。

根因　首尾位置效应。开头那份规则对当前注意力的影响随上下文增长而衰减。

解法　任务书重申关键红线；子 agent 任务书自带红线；长会话主动切段。但这三条都只是缓解。真正拦得住的是 3.4 那三层工具级护栏——能用配置拦的就别只靠提示词拦。

8.2 工程类

这类坑的特点是不会立刻暴露，往往跑了几周才发现成本没降、效率没提升。

重复测试烧钱

现象　第二轮、第三轮的成本没有下降，甚至更高。

根因　台账写了但没被读，或者只记了 hit 没记 miss。后者更常见，而只记命中的台账防不住任何重复。

解法　否定也记台账并写明原因；新会话开局强制读；用 3.7 那条验收——让它说出"本轮不测什么"，说不出来就是没闭环。

台账写成流水账，模型读不了

现象　台账越写越长，但读完之后还是会重复测，或者引用错误的历史结论。

根因　写成了自由散文。模型能读懂散文，但没法可靠地按状态过滤和结构化追加。

解法　固定列的表格 + 固定的状态枚举 + 假设编号。过程叙述留在 journal/，别混进 tested.md。

记忆层污染

现象　某个模式在新目标上反复不命中，但因为写在记忆里，每次都被优先安排，持续浪费预算。

根因　把一次偶然的发现过度泛化成了模式。因为写进了长期记忆，错误会被反复强化——这是记忆层最危险的失败方式，它会自我加固。

解法　每条模式带命中历史和反例；只在项目收尾、经过复核之后才写入；每季度回看，命中历史为 0 且三个项目未验证的降级或删除。

工具版本漂移

现象　上个目标能用的解包脚本、Frida 脚本、CA 安装方案，这个目标全不好使。

根因　移动端工具链对目标环境版本极度敏感。微信 4.1.x 改了解密、Android 14 改了信任库位置、新版 Frida 改了 API 写法。

解法　memory/tools.md 里存的不是"用什么工具"，是「目标环境版本 ↔ 可用方案」的对应表。这是记忆层里最省时间的一部分，因为这类问题重现率极高而排查成本又不低。

分片重叠，两边都拿到脏数据

现象　两个子 agent 对同一个端点得出相反结论。

根因　分片时端点列表有交集，并发请求互相踩响应。

解法　派发前对各分片端点列表求交集，非空拒绝派发。这一步脚本化，别靠人看。

8.3 成本

一轮跑下来 token 花超，或目标请求配额提前用光

根因　没设硬预算；大文件整读；重复测试。

解法　每个子 agent 独立请求上限，用完必停；索引策略；台账去重。

还有一条优先级判断值得单独说：纯静态清洗最划算。 零目标请求、只烧 token，而 token 比请求配额便宜得多，也不触发风控。能在静态阶段排除的假设就别拿到动态阶段去试。我们现在的习惯是，一个假设进入动态验证之前，先问一句"这个能不能光读代码就否掉"。

规模差两个数量级，但单位产出的成本结构是接近的。

8.4 合规

这一类的每一条，后果都比技术问题严重。

误触写操作

现象　验证越权时真的下了一单、改了一条数据，或者给真人发了短信验证码。

根因　规则没写死，或者任务书没写明"本任务的非目标"，模型自行判断为"验证需要"。

解法　规则层黑名单（默认禁止加显式豁免）；任务书写明非目标；措辞用"禁止"不用"注意"，原因见 3.2。

第三方数据读过头

现象　证明了越权之后，它"为了确认范围"继续拉取了大量他人数据。

根因　没写命中即停，它把"确认影响面"理解成了"枚举影响面"。

解法　验证性读取不超过两条，命中即停，报告内打码。证明越权成立只需一条记录；继续拉取的性质已经从测试变成数据获取，这是定性差别不是程度差别。

凭证与 PII 外流

现象　token 被粘进对话等于发给了模型厂商；明文密钥跟目录被打包带走；真实手机号进了报告正文；截图里的 Cookie 忘了打码。

根因　没有在落盘环节做脱敏，指望人工筛选。

解法　落盘时只存 key 不存 value、凭证只存指纹；密钥走系统钥匙串；.gitignore 第一天配好；报告正文和截图强制打码。

几个容易漏的外发通道值得单独列出来：Chrome DevTools MCP 的性能工具会把 trace URL 发给 Google 的 CrUX API（加 –no-performance-crux），它的遥测默认开启且独立于 Chrome 自身设置；PentestGPT 之类工具也默认开匿名遥测。脱敏要在源头做，人工筛选不可靠——不止一次出现报告写完了才发现有截图漏打码、需要重新处理的情况。

挖到的洞别人已经报过

根因　没做提交前的重复性检查。

解法　提交前搜厂商公开报告、历史公告、CVE 库比对。历史 CVE 本来就是威胁模型的来源（7.2），这一步和开局用的是同一批材料，顺手的事。

第九部分：收益、路线、红线

汇报的落点。跟纯人工和裸用 AI 比好在哪，收益能不能量化，以及同样重要的——哪些事它做不了、不该指望它做。

9.1 三种做法横评

汇报时最该点出来的是倒数第二行。纯人工的知识沉淀在个人身上，人走了就带走了；裸用 AI 根本不沉淀。工作台把"某某很会挖某类洞"这件事，变成了团队可以共同维护、新人可以直接继承的资产。这个性质比"快多少"更有长期价值，也更难被复制。

9.2 量化收益

三条可对外说的结论：

▪ 冷启动从天级掉到小时级。 来源是记忆层的模式复用。P-012 在一个 OTA 目标上成立后，下一个同类目标第一天就复现了同类问题。

▪ 第二轮起成本约降一半。 来源是台账去重，那六成否定结果每一条都省掉了一次重复投入。

▪ 覆盖度可证明。 客户问"测没测 SSRF"，能直接指出假设编号、结论和日期。这一条在交付环节的价值超出我们一开始的预期——它解决的是信任问题，不是效率问题。

9.3 边界

这部分建议在汇报时讲完整，因为它决定了这套东西该被怎么定位：它是放大器，不是替代品。以下四件事流程上强制要求人来做，不是"最好人来做"。

AI 把挖洞从体力活变成了编排活。通读代码、枚举端点、重放请求、起草报告，这些被接管了。剩下的竞争力在三件事上：判断哪个假设值得跑、哪个结果值得信、哪个点必须停。这三件事永远是人的。工作台的全部设计，就是把人的时间从前者腾出来，集中到后者。

9.4 三周路线

第一周　搭环境

▪ 接模型，配好主备切换和探活

▪ 写 CLAUDE.md，六条红线抄 3.2

▪ 建目录骨架，配 .gitignore

▪ 装代理和证书，配三层 scope 护栏

▪ 拿 XBOW 的 validation-benchmarks 起一个本地靶场练手，别碰真实目标

验收：3.7 清单前八条全过。

第二周　第一个真实目标

▪ 选 Web 形态，理由见 6.7

▪ 按 7.2 让模型从历史 CVE 生成威胁模型

▪ 白盒提取两张表，人工挑三个最可疑的自报字段

▪ 黑盒验证 → 对抗性自审 → 人复核

▪ 让它按厂商模板出报告草稿，人只改定级和措辞

验收：一个能走完的闭环，比十个半途而废的深挖有用。

第三周起　沉淀与放大

▪ 项目收尾写 patterns.md，带命中历史和反例

▪ tools.md 记下环境版本对应关系

▪ 开始用子 agent 并行，学会看预算叫停

▪ 扩到小程序形态

验收：3.7 那条"台账能影响行为"通过。

9.5 合规红线

本文讨论的全部方法，适用前提只有一个：已获得书面授权、范围明确、全程可审计。

这些不是建议，是默认禁止，需要豁免就在任务书里显式写明并留痕。模型没有法律意识，边界是人写进配置它才知道。没写，它会自己判断，通常判错。

附录 A：可直接抄的模板

把正文里的模板集中在这里，方便打印后直接用。

A.1 目录骨架（最小集）

workbench/

├── CLAUDE.md # 一页纸红线

├── .mcp.json # MCP 声明

├── memory/ # patterns / techniques / tools

└── targets//

├── scope.md # 授权书摘要

├── threat-model.md # 一页威胁模型，从历史 CVE 生成

├── assets/ # routes / identity / invariants

├── capture/index.jsonl # 结构化流量索引

├── decompiled/INDEX* # 文件清单 + 关键词热力

├── journal/ # 按天流水

├── tested.md # 假设矩阵 ← 防重复核心

└── findings.md # 命中项 + 证据三件套

A.2 tested.md 表头

| ID | 面 | 假设 | 状态 | 证据 | 日期 |

|—-|—-|——|——|——|——|

状态只允许三个值：

hit 命中

miss 已测且否定（必须写否定原因）

blocked 测了但被拦 / 无法判定

A.3 子 agent 任务书四要素

回报格式里记得写：不要给安全建议，不要给修复方案。

A.4 三条常用提示词

① 冷启动：从记忆层预测本目标的薄弱面

读 memory/patterns.md 和 targets//threat-model.md。

从 patterns 里挑出最可能命中的 5 条，按触发条件吻合度排序。

每条给出：编号名称 / 吻合依据 / 第一个验证动作 / 反例是否成立。

不要输出泛泛的安全建议。

② 威胁模型：从历史 CVE 生成

以下是 [项目名] 的历史 CVE 描述：[粘贴]

输出一页纸威胁模型，必须包含：最常见的漏洞类别（按频次）、

最薄弱的信任边界及依据、入口点清单、攻击者模型、高危操作清单。

每一条都要能指回上面的 CVE 描述。不要写通用安全建议。

③ 不变量：拆两步问

第一步：列出这个模块所有隐含的安全假设。只列，不判断。每条一行，编号。

第二步：假设 #N「…」。在哪条代码路径上它可能被违反？

给出具体函数和行号，以及攻击者需要的前置条件。

A.5 最小闭环自检

1. 主备模型各跑通一次真实工具调用

2. 新会话里模型能准确复述六条红线

3. 代理能抓到目标明文，且白名单外不落盘

4. 三层 scope 护栏各验一次，关掉上层后下层能兜住

5. 模型能从索引检索出指定接口的请求模板

6. 模型能读 memory 输出 5 条模式预测及依据

7. 一次子 agent 派发能回收结构化结论且守住请求上限

8. 台账能影响行为：模型能主动说出"本轮跳过哪些已否定项"

9. 大文件走索引，不被整读

A.6 十条提示词技巧速查

A.7 证据三件套与案例证据模板

命中项进 findings.md 的最低要求：

客户端 / APP 类案例另加四环（取自 6.8）：触发源、进程内回显、会话凭据、收件端落地。缺一环不定级。

附录 B：来源清单

按主题分组。工具版本和平台接口每月都在变，动手前先跑通最小链路再投入。

方法论

Web

小程序与 Electron

APP

价格与能力数据

几处本文明确存疑、未采信的说法

写进内部材料时请一并保留这几条，它们比结论更能防止后来者踩坑：

1. 微信 4.1.x 之后 wxapkg 加密的具体变更没有公开文档，只有"某工具已适配"的说法。

2. 没有任何公开资料证明微信专门过滤了 SendInput；可证实的是 OS 级注入标志和 4.1.5 隐藏 UI 树两件事。

3. –disable-gpu 不是微信调试开关，它是 Chromium 禁用硬件加速的标准参数。

4. 没有权威资料表明小程序运行时做了 SSL Pinning，官方文档描述的是标准 CA 校验。

5. ffuf 和 nuclei 都没有官方 MCP，能搜到的全是社区封装。

6. 跨工具的通用 DEX 合并方案不存在，各脱壳工具产物格式各不相同。

使用声明

本文档为内部技术分享材料，所述方法仅适用于已获书面授权、范围明确、全程可审计的安全测试场景。

文中所有工具与手法均引自公开资料，文档的价值在于把它们编排成一条可复用的工程流程。

未获授权的目标，本文没有一条方法是适用的。

AI 编程智能体工作台 · 搭建与实战