# 验证码模式

## 适用目的

在目标涉及滑块、点选、旋转、行为校验、PoW 或 challenge/verify 协议时，用这份文档拆解线路。

## 一、先拆成 5 条线

不要把所有内容都写成“验证码逻辑”。先拆成：

1. 初始化 / challenge 线
2. 图像或题面识别线
3. 参数 builder 线
4. 环境 / 指纹 / collect 线
5. 最终 verify 线

## 二、验证码常见字段

高频字段示例：

- `collect`
- `pow_answer`
- `pow_calc_time`
- `w`
- `fs`
- `ac_c`
- `Signature`
- `SignatureNonce`
- `captcha_collect`
- `behavior`
- `token`

判断它们是否真的重要，不看“像不像密文”，而看：

1. 删除后是否失败
2. 改动后是否失败
3. 是否与识别结果、时间戳、环境值强绑定

## 三、5 类高频题型

### 1. 纯图像 + 轻参数

特征：

- 参数层较薄
- 识别结果最关键

推荐顺序：

1. 保存原图和小图
2. 先打通识别
3. 再看 verify 如何装入识别结果

### 2. 图像 + 中等参数混合

特征：

- 既要识别，也要还原 builder
- 常见角度、距离、坐标和参数共同参与校验

推荐顺序：

1. 先拆图像线
2. 再跟最终 verify
3. 对齐 builder 输入和中间 payload

### 3. 纯算 / 半纯算题

特征：

- 图像难度不高
- 轨迹、PoW、collect、signature 更重

推荐顺序：

1. 先拆请求顺序
2. 明确 token / challenge 来源
3. 再分析签名或 PoW
4. 最后微调轨迹或识别结果

### 4. JSVMP / 补环境题

特征：

- 大数组、解释器、环境读取多
- 入口在浏览器能跑，在本地容易报错

推荐顺序：

1. 先从 verify 参数赋值点倒推
2. 判断是值不对，还是入口直接报错
3. 前者先插桩，后者先补环境

### 5. WebSocket / 分段协议题

特征：

- 不再是单条 XHR
- 请求和响应分多段
- 首包和验证包职责不同

推荐顺序：

1. 先数包
2. 标记首包、图片包、验证包
3. 再拆 key 派生和加解密

## 四、验证码的统一检查点

每题至少保留这些检查点：

1. 初始化请求参数
2. 图片接口或题面返回值
3. 识别结果
4. 轨迹明文
5. builder 输入对象
6. builder 输出对象
7. 浏览器发送值
8. 本地生成值

## 五、轨迹和识别的通用提醒

### 轨迹

重点检查：

- 总时长是否合理
- 时间戳是否单调递增
- y 轴是否完全不动
- 末尾是否机械地精确对齐

### 识别

重点动作：

1. 先把识别结果单独保存成中间值
2. 不要把识别和网络请求死耦合
3. 让识别输出作为 builder 的独立输入

## 六、什么时候不要急着做图像

如果 verify 失败的主因是：

- token/challenge 不对
- collect/signature 不对
- 环境值不对

先修参数链和环境链，再修图像线；否则容易在错误链路上重复调参。