# 第二轮补环境阅读笔记

这份文档记录本轮继续扩读后，新补进来的信息点。

这一轮的目标不是重复收集 Proxy 入门文，而是专门补当前草稿缺的方向：

- `window` / 原型链关系
- `window.crypto` / `performance`
- `WebRTC`
- `AudioContext` / `OfflineAudioContext`
- `Worker`
- 更复杂的国外风控 / 验证码环境检测

## 1. 本轮阅读后最明显的变化

如果把这批文章和前面的 GitHub 框架一起看，会发现一个很重要的分层：

### 第一层：基础补环境

- `window = globalThis`
- `document = {}`
- `navigator = {}`
- `location = {}`
- `history = {}`
- `screen = {}`
- `Proxy` 吐环境

这类内容很多，足够入门，但对 future skill 的增量已经有限。

### 第二层：工程化补环境

- 原型链
- `Symbol.toStringTag`
- native `toString`
- getter / setter / 描述符
- `plugins/mimeTypes`
- `document.all`

这类内容是现有 `codex` 草稿的核心骨架。

### 第三层：高强度检测

- `window.crypto.getRandomValues`
- `performance.timing`
- `RTCPeerConnection`
- `RTCRtpSender` / `RTCRtpReceiver`
- `OfflineAudioContext`
- `Worker` / `SharedWorker`
- 字体指纹
- `Math` 精度差异
- wasm + Promise 异步链

这一层才是后续最值得重点扩读和沉淀的方向。

## 2. 本轮最有价值的文章与新增信息

### 2.1 博客园：JS逆向之浏览器补环境详解

链接：
[https://www.cnblogs.com/spiderman6/p/16969391.html](https://www.cnblogs.com/spiderman6/p/16969391.html)

这篇文章的最大价值不是某个单独代码片段，而是把补环境明确拆成两条路线：

- 递归 Proxy 监控路线
- 纯 JS 原型链框架路线

对 future skill 最有价值的新增点：

- 明确提出“工程化项目结构”比单脚本更重要
- 明确提到事件处理是框架必须考虑的点
- 强调每个 BOM / DOM 对象应单文件组织
- 强调补环境框架要按原型链顺序拼接

这对我们前面已经写出的 `future-skill-blueprint` 是很强的佐证。

### 2.2 博客园：js补环境代码

链接：
[https://www.cnblogs.com/c-x-a/p/18702240](https://www.cnblogs.com/c-x-a/p/18702240)

这篇文章虽然代码不复杂，但有一个很实用的点：

- 它把 `performance`、`top`、`self`、`document` 一起纳入了 Proxy 监控清单

它提醒我们：

- `performance` 不应该只放在指纹模块里，也应该纳入 Proxy 观察默认目标
- `top/self` 这类 `window` 关系也应该是默认监控项

### 2.3 博客园：window.crypto.getRandomValues 模拟

链接：
[https://www.cnblogs.com/hotdog418/articles/14005518.html](https://www.cnblogs.com/hotdog418/articles/14005518.html)

这篇文章的价值在于给了一个很具体的 `getRandomValues` 模拟思路，并且点到了真实行为细节：

- 需要处理 `Uint8Array`
- 需要处理 `Uint16Array`
- 需要处理 `Uint32Array`
- 需要处理长度超过阈值时的异常

这对 future skill 的意义是：

- `crypto.getRandomValues` 不能只返回随机数
- 还要尽量模拟参数类型和错误行为

也就是说，`crypto-module` 已经值得单独立项。

### 2.4 验证码细节总结：补环境中可能用到的方法

链接：
[https://www.cnblogs.com/ocr12/p/18664716](https://www.cnblogs.com/ocr12/p/18664716)

这篇文章虽然主题更偏验证码，但里面有两个对补环境很重要的点：

- `window.crypto.getRandomValues`
- `window.performance.timing`

尤其是 `performance.timing`，说明我们前面的遗漏判断是对的：

- performance 不能只补 `performance.now`
- 很多场景会直接读 timing 结构

所以 future skill 至少应单独补：

- `performance.now`
- `performance.timeOrigin`
- `performance.timing`
- 时间序列一致性

### 2.5 博客园：修改浏览器指纹之 webrtc 指纹修改

链接：
[https://www.cnblogs.com/68xi/p/13344520.html](https://www.cnblogs.com/68xi/p/13344520.html)

这篇文章不是逆向框架文，但对 `WebRTC` 的价值很高：

- 明确给出了 `RTCPeerConnection` 探测本机 IP 的典型流程
- 涉及 `createDataChannel`
- 涉及 `createOffer`
- 涉及 `onicecandidate`

这说明 future skill 中的 `webrtc-module` 至少要考虑：

- 构造函数存在性
- `createDataChannel`
- `createOffer`
- ICE candidate 行为
- IP 泄漏与候选收集路径

### 2.6 CN-SEC：hCaptcha 无感逆向分析-补环境

链接：
[https://cn-sec.com/archives/4909845.html](https://cn-sec.com/archives/4909845.html)

这是这一轮最关键的文章。

它几乎直接把我们草稿里“高强度检测层”的缺口点出来了：

- `RTCPeerConnection`
- `RTCRtpSender`
- `RTCRtpReceiver`
- `OfflineAudioContext`
- `WebGL2RenderingContext`
- 描述符检测
- `AudioBuffer.prototype.getChannelData`
- `Math` 精度差异
- 字体指纹
- canvas 指纹
- `Worker`
- `SharedWorker`
- Promise / wasm 异步调用链

这篇文章对 future skill 的最大推动有三点：

1. 说明补环境已经不能只看 BOM / DOM
2. 说明“异步链 + wasm 交互 + 指纹一致性”是高阶核心
3. 说明验证模块必须能和浏览器日志对照

## 3. 本轮阅读后，future skill 应新增的模块

结合这一轮资料，最应该补进 blueprint 的新增模块有：

### 3.1 `crypto-module`

至少包含：

- `window.crypto`
- `window.msCrypto`
- `getRandomValues`
- `subtle`

### 3.2 `performance-module`

至少包含：

- `performance.now`
- `performance.timeOrigin`
- `performance.timing`
- 时间一致性

### 3.3 `webrtc-module`

至少包含：

- `RTCPeerConnection`
- `RTCRtpSender`
- `RTCRtpReceiver`
- ICE candidate 行为

### 3.4 `audio-fingerprint-module`

至少包含：

- `AudioContext`
- `OfflineAudioContext`
- `AudioBuffer`
- `getChannelData`

### 3.5 `worker-module`

至少包含：

- `Worker`
- `SharedWorker`
- `postMessage`
- `MessageEvent`

### 3.6 `math-precision-module`

至少包含：

- 精度差异检查
- 高风险数学函数差异记录
- 浏览器 / Node 结果对照能力

## 4. 对当前 codex 草稿最直接的修正建议

这一轮阅读后，我认为前面的遗漏优先级需要进一步收敛成：

1. `crypto-module`
2. `performance-module`
3. `webrtc-module`
4. `audio-fingerprint-module`
5. `worker-module`
6. `window` 关系一致性
7. 完整 Event / DOM 系统

原因很简单：

- 这些模块在高强度风控里更容易真正卡死流程
- 而且它们比基础 BOM/DOM 更难靠“临时补值”解决

## 5. 当前最稳的结论

这第二轮阅读已经说明：

- 我们现在不是资料不够多
- 而是资料分布不均

真正该继续扩读的，不是更多重复的 Proxy 入门文，而是：

- `crypto`
- `performance`
- `WebRTC`
- `AudioContext`
- `Worker`
- `Math` 精度
- wasm 交互与异步调用链

这会直接决定 future skill 后续有没有能力从“常规补环境”走向“国外高强度盾补环境”。