800 lines
20 KiB
Markdown
800 lines
20 KiB
Markdown
# JS 逆向补环境通用流程总结（中文版增强版）
|
||
|
||
这份文档讨论的不是“把 Node 里缺的对象补几个上去”这么简单。
|
||
|
||
真正成熟的补环境，目标是：
|
||
|
||
- 让目标代码在本地的执行路径尽量接近浏览器内的真实路径。
|
||
- 让对象的值、原型链、属性描述符、访问器、函数元信息、原生指纹都尽量接近浏览器。
|
||
- 让异常、堆栈、状态数据、指纹对象也尽量不暴露“这是 Node 假环境”。
|
||
- 最终恢复真实参数、真实 cookie、真实分支，而不是只做到“不报错”。
|
||
|
||
## 1. 先判断：这题到底该不该走补环境
|
||
|
||
常见信号：
|
||
|
||
- 本地运行直接报 `window is not defined`、`document is not defined`、`navigator is not defined`、`location is not defined`。
|
||
- 浏览器里结果正常，本地结果为空、报错、签名不一致、cookie 不一致。
|
||
- 目标代码明显在读浏览器对象、指纹对象、DOM/BOM、存储态。
|
||
- 目标代码依赖 `document.cookie`、`localStorage`、`sessionStorage`、`canvas`、`WebGL`、`WebSocket`、`Worker`、`meta` 标签等运行时对象。
|
||
- 代码切不干净，硬扣算法的成本已经高于“保留大部分原始逻辑 + 外围补环境”。
|
||
|
||
如果只是纯算法函数，不依赖浏览器环境，那么通常不值得补环境，直接还原算法更高效。
|
||
|
||
## 2. 永远先定位目标点，再决定补什么
|
||
|
||
不要一上来就补整套浏览器。
|
||
|
||
先定位：
|
||
|
||
- 目标参数或 cookie 是什么。
|
||
- 它最终写到了哪里。
|
||
- 是哪个函数返回的。
|
||
- 是通过 `document.cookie` 写入，还是通过请求头、请求体、query 参数发送。
|
||
- 它的上游依赖链是什么。
|
||
|
||
常见定位入口：
|
||
|
||
- Hook `document.cookie`
|
||
- 搜参数名、cookie 名
|
||
- 断在 `XMLHttpRequest`、`fetch`、`WebSocket.send`
|
||
- 沿请求调用链往上回溯
|
||
- webpack 站点先找模块入口、runtime、构造器
|
||
- JSVMP 站点先找对外调用入口，而不是一开始就死抠内部实现
|
||
|
||
补环境的本质不是“补对象”，而是“围绕真实执行入口，补它运行时真正依赖的对象和状态”。
|
||
|
||
## 3. 决定执行策略：手补、半框架、全浏览器
|
||
|
||
### 3.1 手动补环境
|
||
|
||
适合：
|
||
|
||
- 缺失对象不多
|
||
- 目标依赖链清晰
|
||
- 你已经把核心逻辑抽出来了
|
||
|
||
优点：
|
||
|
||
- 最干净
|
||
- 最容易理解真实依赖
|
||
- 最适合沉淀成可复用 skill
|
||
|
||
缺点：
|
||
|
||
- 遇到复杂 DOM、原型链检测、native 指纹检测时，维护成本高
|
||
|
||
### 3.2 模拟浏览器环境
|
||
|
||
常见工具：
|
||
|
||
- `jsdom`
|
||
- `vm`
|
||
- `vm2`
|
||
- `catvm`
|
||
- `qxVm`
|
||
- `sdenv`
|
||
- `node-sandbox`
|
||
|
||
适合：
|
||
|
||
- DOM/BOM 依赖较多
|
||
- 想保留更多原始页面代码
|
||
- 不想手写太多空对象
|
||
|
||
注意：
|
||
|
||
- 框架只是脚手架，不是魔法。
|
||
- 真正难的依然是：原型链、描述符、访问器、原生指纹、动态状态恢复。
|
||
|
||
### 3.3 真实浏览器执行
|
||
|
||
常见方式：
|
||
|
||
- Selenium
|
||
- Headless Chrome
|
||
- Playwright
|
||
|
||
适合：
|
||
|
||
- 本地补环境代价明显高于“直接在浏览器执行”
|
||
- 目标强依赖真实 DOM、事件流、浏览器内部实现、渲染对象、定时器行为
|
||
|
||
这个路线不一定是最终方案，但很适合作为“先跑通，再逆向简化”的过渡方案。
|
||
|
||
## 4. 第一层：先补最小可运行环境
|
||
|
||
第一批对象通常包括：
|
||
|
||
- `window`
|
||
- `self`
|
||
- `top`
|
||
- `parent`
|
||
- `frames`
|
||
- `globalThis`
|
||
- `document`
|
||
- `navigator`
|
||
- `location`
|
||
- `history`
|
||
- `screen`
|
||
|
||
第一层目标不是“完整仿真”，而是：
|
||
|
||
- 让代码先跑起来
|
||
- 让访问路径暴露出来
|
||
- 让缺失依赖快速浮现
|
||
|
||
典型第一步包括：
|
||
|
||
- 建立全局对象引用关系
|
||
- 给 `navigator.userAgent`、`language`、`platform` 等常用字段赋值
|
||
- 给 `location.href`、`host`、`hostname`、`origin`、`pathname` 等字段赋值
|
||
- 初始化 `document.cookie`
|
||
- 初始化 `document.referrer`、`document.head`、`document.documentElement`
|
||
|
||
但要明确一点：
|
||
|
||
这只是起步，不是终点。很多检测并不只看值，还看值在什么层级、怎么取到、是不是原生访问器。
|
||
|
||
## 5. 第二层：尽快让环境“自吐”
|
||
|
||
这是补环境里最重要的一步之一。
|
||
|
||
典型做法是给这些对象尽早套上 `Proxy`：
|
||
|
||
- `window`
|
||
- `document`
|
||
- `navigator`
|
||
- `location`
|
||
- `history`
|
||
- `screen`
|
||
- 高风险函数
|
||
|
||
重点监控：
|
||
|
||
- `get`
|
||
- `set`
|
||
- `has`
|
||
- `deleteProperty`
|
||
- 必要时监控函数调用
|
||
|
||
这样做的价值是：
|
||
|
||
- 把“盲猜缺什么”变成“脚本自己告诉你它读了什么”
|
||
- 把补环境任务转成一份可迭代的待补清单
|
||
- 让你知道哪些对象必须精细补，哪些对象只是路过
|
||
|
||
## 6. `undefined` 驱动补环境是主路线，但不是唯一标准
|
||
|
||
很多时候，确实是通过 Proxy 吐出来的 `undefined` 来判断“这里需要补环境”。
|
||
|
||
这是非常高效的主路线。
|
||
|
||
但它有边界：
|
||
|
||
- 某些值虽然不是 `undefined`，但值不真实，依然会算错。
|
||
- 某些检测根本不关心值是不是 `undefined`，而是看原型链、描述符、访问器。
|
||
- 某些逻辑依赖的是 cookie、`localStorage`、`sessionStorage` 里“已经存在的历史状态”。
|
||
- 某些检测通过异常、堆栈、`toString`、`instanceof` 路径触发，Proxy 不会直接提醒你。
|
||
|
||
所以正确理解应该是：
|
||
|
||
- Proxy 吐 `undefined` 是补环境的主入口。
|
||
- 但不是补环境完成度的唯一判断标准。
|
||
|
||
## 7. 第三层：补值，不如补结构
|
||
|
||
很多初学者会这样补：
|
||
|
||
```js
|
||
navigator = { userAgent: "..." };
|
||
document = {};
|
||
location = {};
|
||
```
|
||
|
||
这只能解决最基础的报错。
|
||
|
||
真正经常导致失败的是结构问题：
|
||
|
||
- 属性本该在实例上，你补到了对象本体上
|
||
- 属性本该在原型上，你补到了实例上
|
||
- 方法本来是访问器，你补成了普通值
|
||
- 属性本来不可枚举，你补成了可枚举
|
||
- 方法本来不可写或不可配置，你把描述符补错了
|
||
- 函数本来有固定 `name` / `length`，你写出来的不一致
|
||
|
||
所以补环境的关键思路，应该从“补字段”升级为“补对象结构”。
|
||
|
||
## 8. 第四层：先补原型链，再补实例值
|
||
|
||
这是真正的分水岭。
|
||
|
||
真实浏览器对象通常不是：
|
||
|
||
```js
|
||
window.navigator = { userAgent: "..." };
|
||
```
|
||
|
||
更接近的模型通常是：
|
||
|
||
- 存在 `Navigator` 构造器
|
||
- `navigator` 是某个原型链实例
|
||
- 属性可能在原型上，也可能通过 getter 暴露
|
||
- 方法通常在原型上
|
||
- 属性描述符与浏览器一致
|
||
|
||
因此更合理的顺序通常是：
|
||
|
||
1. 先建构造器
|
||
2. 再建 prototype
|
||
3. 再补 prototype 上的方法和属性
|
||
4. 再创建实例
|
||
5. 最后把实例挂到全局对象上
|
||
|
||
高价值对象包括：
|
||
|
||
- `Navigator`
|
||
- `History`
|
||
- `Location`
|
||
- `Screen`
|
||
- `Document`
|
||
- `HTMLDocument`
|
||
- `Storage`
|
||
- `WebSocket`
|
||
- `Worker`
|
||
- `EventTarget`
|
||
- `Node`
|
||
- `Element`
|
||
- `HTMLElement`
|
||
- `HTMLCanvasElement`
|
||
|
||
也就是说，补环境不是“给对象赋值”，而是“重建浏览器对象图”。
|
||
|
||
## 9. 第五层：保护原生方法的 `toString`
|
||
|
||
很多站点会检测：
|
||
|
||
- 方法是不是原生函数
|
||
- `Function.prototype.toString.call(fn)` 的返回值是否像浏览器原生实现
|
||
|
||
如果你手写：
|
||
|
||
```js
|
||
document.createElement = function () {}
|
||
```
|
||
|
||
那么很容易被看出来，因为它的 `toString()` 不会像：
|
||
|
||
```js
|
||
function createElement() { [native code] }
|
||
```
|
||
|
||
常见保护思路包括：
|
||
|
||
- 改写目标函数自身的 `toString`
|
||
- 统一 Hook `Function.prototype.toString`
|
||
- 给受保护函数打隐藏标记，再在 `Function.prototype.toString` 中按标记返回伪原生源码
|
||
|
||
高频需要保护的方法包括：
|
||
|
||
- `addEventListener`
|
||
- `removeEventListener`
|
||
- `createElement`
|
||
- `getAttribute`
|
||
- `setAttribute`
|
||
- `querySelector`
|
||
- `getContext`
|
||
- `Storage.prototype.getItem`
|
||
- `Storage.prototype.setItem`
|
||
|
||
## 10. `toString.toString` 这种深层检测也要考虑
|
||
|
||
成熟站点不只会检测：
|
||
|
||
- `fn.toString()`
|
||
- `Function.prototype.toString.call(fn)`
|
||
|
||
还会继续检测：
|
||
|
||
- `fn.toString.toString()`
|
||
- `Function.prototype.toString.toString()`
|
||
|
||
也就是说，它不只检查“你伪装的函数像不像原生”，还检查“你拿来做伪装的 `toString` 本身像不像原生”。
|
||
|
||
因此成熟方案通常要同时保护：
|
||
|
||
- 被伪装的目标函数
|
||
- 目标函数自己的 `.toString`
|
||
- `Function.prototype.toString`
|
||
- 与 `toString` 相关的 `name` / `length` / 描述符
|
||
|
||
## 11. 第六层：保护 getter / setter 访问器
|
||
|
||
真实浏览器里很多属性不是普通数据属性，而是访问器属性。
|
||
|
||
例如：
|
||
|
||
- `document.cookie`
|
||
- `location.href`
|
||
- `navigator.userAgent`
|
||
- 一些 DOM 节点属性
|
||
|
||
如果目标代码用了：
|
||
|
||
- `Object.getOwnPropertyDescriptor`
|
||
- `__lookupGetter__`
|
||
- 直接检测 getter / setter 的 `toString`
|
||
|
||
那么你补成普通值就会露馅。
|
||
|
||
更稳妥的补法应当是：
|
||
|
||
- 使用 `Object.defineProperty`
|
||
- 显式提供 `get`
|
||
- 必要时提供 `set`
|
||
- 对 getter / setter 本身也做 `toString` 保护
|
||
- 保持 `enumerable` / `configurable` 等标志尽量接近浏览器
|
||
|
||
另外还要注意异常路径：
|
||
|
||
- 某些 getter 在非法调用时应该抛异常
|
||
- 某些 setter 在类型不合法时不能静默通过
|
||
|
||
所以访问器不只是“能取到值”，还要尽量对齐：
|
||
|
||
- 返回值
|
||
- 报错时机
|
||
- 报错类型
|
||
- 报错信息形态
|
||
|
||
## 12. 第七层：保护属性描述符
|
||
|
||
很多补环境失败，不是值错了，而是描述符错了。
|
||
|
||
重点需要关注：
|
||
|
||
- `enumerable`
|
||
- `configurable`
|
||
- `writable`
|
||
- `get`
|
||
- `set`
|
||
|
||
还要注意：
|
||
|
||
- 某些属性本应定义在 prototype 上
|
||
- 某些属性本应定义在实例上
|
||
- 某些属性本应不出现在 `Object.keys`
|
||
- 某些属性本应能通过 `in` 访问，但不应是 own property
|
||
|
||
所以补环境时，经常要把下面这些检测一起纳入验证：
|
||
|
||
- `Object.getOwnPropertyDescriptor`
|
||
- `Object.getOwnPropertyDescriptors`
|
||
- `Object.keys`
|
||
- `Reflect.ownKeys`
|
||
- `hasOwnProperty`
|
||
- `propertyIsEnumerable`
|
||
- `in`
|
||
- `Object.getPrototypeOf`
|
||
- `constructor`
|
||
- `instanceof`
|
||
- `Symbol.toStringTag`
|
||
- `Object.prototype.toString.call(obj)`
|
||
|
||
## 13. 第八层：保护函数的 `name` 和 `length`
|
||
|
||
很多环境检测会直接看：
|
||
|
||
- `fn.name`
|
||
- `fn.length`
|
||
|
||
如果浏览器原生方法本来：
|
||
|
||
- 名字固定
|
||
- 参数个数固定
|
||
|
||
而你手写的函数不一致，就可能被识别。
|
||
|
||
补函数时要注意：
|
||
|
||
- 用命名函数而不是匿名函数
|
||
- 参数个数尽量与真实浏览器一致
|
||
- 必要时通过 `Object.defineProperty` 保护 `name` / `length`
|
||
- 如果统一封装安全函数或 native 模板，要确保封装后不会把这些信息破坏
|
||
|
||
还要注意：
|
||
|
||
- 包装函数之后，外层壳子很容易把原始 `name` / `length` 改掉
|
||
- getter / setter 函数自身也可能被检测 `name`
|
||
- 某些站点还会顺带看 `caller`、`arguments` 的访问行为
|
||
|
||
## 14. Node 环境检测必须单独考虑
|
||
|
||
很多站点真正先做的，不是浏览器对象检测，而是先识别“你是不是在 Node 里跑”。
|
||
|
||
常见检测点：
|
||
|
||
- `process`
|
||
- `global`
|
||
- `Buffer`
|
||
- `require`
|
||
- `module`
|
||
- `exports`
|
||
- Node 版本差异导致的内置对象行为差异
|
||
- Node 特有的全局痕迹
|
||
|
||
所以成熟流程里要考虑：
|
||
|
||
- 是否隐藏或清理 Node 痕迹
|
||
- 是否让全局对象更接近浏览器
|
||
- 是否避免把明显的 CommonJS / Node 运行特征暴露给目标代码
|
||
|
||
## 15. 错误异常检测也必须纳入流程
|
||
|
||
有些站点会主动触发错误，然后检查：
|
||
|
||
- 抛出的异常类型是否合理
|
||
- `message` 是否像浏览器
|
||
- `name` 是否正确
|
||
- 报错位置是否合理
|
||
|
||
这意味着补环境不能只补“正常路径”，还要补“异常路径”。
|
||
|
||
## 16. 堆栈检测也要考虑
|
||
|
||
错误一旦抛出，目标代码可能会检查：
|
||
|
||
- `error.stack`
|
||
- 栈中的函数名
|
||
- 栈中的文件路径格式
|
||
- 是否出现 `vm`、本地文件路径、Node 模块路径
|
||
|
||
因此成熟方案里常常还要考虑：
|
||
|
||
- 栈裁剪
|
||
- 栈伪装
|
||
- 避免在高风险函数中暴露本地包装层
|
||
|
||
## 17. 第九层：按对象类型拆分补环境策略
|
||
|
||
这一层很适合后面抽象成 skill 的模块能力。
|
||
|
||
### 17.1 BOM 对象
|
||
|
||
常见包括：
|
||
|
||
- `window`
|
||
- `self`
|
||
- `top`
|
||
- `parent`
|
||
- `frames`
|
||
- `navigator`
|
||
- `history`
|
||
- `location`
|
||
- `screen`
|
||
|
||
常见补法：
|
||
|
||
- 建立对象之间的引用关系
|
||
- 构造器 + prototype + 实例三层补齐
|
||
- 补属性描述符
|
||
- 补常见方法
|
||
- 补 `toString`
|
||
- 补 getter / setter
|
||
|
||
### 17.2 `navigator`
|
||
|
||
高频字段包括：
|
||
|
||
- `userAgent`
|
||
- `platform`
|
||
- `language`
|
||
- `languages`
|
||
- `webdriver`
|
||
- `plugins`
|
||
- `mimeTypes`
|
||
- `hardwareConcurrency`
|
||
- `deviceMemory`
|
||
- `cookieEnabled`
|
||
- `vendor`
|
||
- `appCodeName`
|
||
- `appName`
|
||
- `appVersion`
|
||
- `maxTouchPoints`
|
||
- `pdfViewerEnabled`
|
||
- `getBattery`
|
||
|
||
高风险点：
|
||
|
||
- `navigator.webdriver === false`
|
||
- `plugins` 不是简单数组，而是类数组结构
|
||
- `mimeTypes` 通常也不是简单数组
|
||
- `plugins` 和 `mimeTypes` 之间常有结构关联
|
||
- `navigator.getBattery()` 常常需要返回 `Promise`
|
||
- `userAgent`、`platform`、`language`、`languages` 之间需要自洽
|
||
- 原型归属、描述符、own property 与 prototype property 的差异
|
||
|
||
也就是说，`navigator` 不能只补几个字符串，还要补数据结构、返回类型、原型和描述符。
|
||
|
||
### 17.3 `history`
|
||
|
||
常见方法：
|
||
|
||
- `back`
|
||
- `forward`
|
||
- `go`
|
||
- `pushState`
|
||
- `replaceState`
|
||
|
||
很多时候不一定真需要逻辑，但需要：
|
||
|
||
- 原型上存在
|
||
- `name/length` 正确
|
||
- `toString` 像原生
|
||
|
||
### 17.4 `location`
|
||
|
||
重点：
|
||
|
||
- 许多字段应通过 getter 暴露
|
||
- `href` 变化可能联动 `host`、`hostname`、`origin`、`pathname`
|
||
- 有些站会检查 `location.toString()`
|
||
|
||
### 17.5 `screen`
|
||
|
||
常见字段：
|
||
|
||
- `width`
|
||
- `height`
|
||
- `availWidth`
|
||
- `availHeight`
|
||
- `colorDepth`
|
||
- `pixelDepth`
|
||
|
||
### 17.6 `document`
|
||
|
||
高频依赖包括：
|
||
|
||
- `cookie`
|
||
- `referrer`
|
||
- `readyState`
|
||
- `head`
|
||
- `body`
|
||
- `documentElement`
|
||
- `createElement`
|
||
- `addEventListener`
|
||
- `querySelector`
|
||
- `getElementById`
|
||
- `getElementsByTagName`
|
||
- `all`
|
||
|
||
高风险点：
|
||
|
||
- `document.cookie` 通常要做成访问器
|
||
- DOM 节点返回值不能永远是空对象
|
||
- `createElement("canvas")` 经常需要特殊返回
|
||
- `meta`、`script`、隐藏节点都可能参与补环境
|
||
|
||
`document.all` 需要单独拿出来说，因为它不是普通字段：
|
||
|
||
- 它是历史兼容对象
|
||
- 很多站会拿它做特殊检测
|
||
- 它在真假判断、相等判断、类型判断上的行为都比较特殊
|
||
|
||
所以在真正做 skill 时，`document.all` 最好做成一个独立能力模块，而不是普通属性赋值。
|
||
|
||
### 17.7 `localStorage` / `sessionStorage`
|
||
|
||
通常不是简单对象，而应尽量按 `Storage` 结构去补。
|
||
|
||
常见方法：
|
||
|
||
- `getItem`
|
||
- `setItem`
|
||
- `removeItem`
|
||
- `clear`
|
||
- `key`
|
||
|
||
高风险点：
|
||
|
||
- `length`
|
||
- 存取行为
|
||
- 原型归属
|
||
- 描述符
|
||
|
||
补这两个对象时还要注意：
|
||
|
||
- 业务逻辑可能真的依赖已有值，而不是只检测存在性
|
||
- 需要提前注入站点依赖的键值
|
||
- 某些参数生成逻辑会从 `localStorage` 或 `sessionStorage` 里读取种子值
|
||
|
||
所以补环境时不仅要补对象结构，还要补运行态数据。
|
||
|
||
### 17.8 `WebSocket`
|
||
|
||
如果代码只检测存在性，可能只需要：
|
||
|
||
- 构造器
|
||
- `prototype.send`
|
||
- `prototype.close`
|
||
- `prototype.addEventListener`
|
||
|
||
如果代码真在走链路，就要考虑：
|
||
|
||
- 实例属性
|
||
- 回调事件
|
||
- `readyState`
|
||
- 发送参数格式
|
||
- `binaryType`
|
||
- `bufferedAmount`
|
||
- `extensions`
|
||
- `protocol`
|
||
|
||
### 17.9 `Worker`
|
||
|
||
有些站并不真的依赖 Worker 干活，而是拿它做检测。
|
||
|
||
常见检查：
|
||
|
||
- `Worker` 是否存在
|
||
- 是否能 `new Worker()`
|
||
- 是否存在 `postMessage`
|
||
- 是否存在 `terminate`
|
||
|
||
复杂情况下还要考虑：
|
||
|
||
- `importScripts`
|
||
- `onmessage`
|
||
- 消息流
|
||
- `Worker.toString()`
|
||
- 原型链和实例行为
|
||
|
||
## 18. canvas / WebGL 指纹要作为独立模块考虑
|
||
|
||
高频指纹包括：
|
||
|
||
- canvas 指纹
|
||
- WebGL 指纹
|
||
- 音频指纹
|
||
- 屏幕指纹
|
||
- 插件 / MIME 类型指纹
|
||
|
||
这里尤其要注意：
|
||
|
||
- 不是所有题都要完整补，但流程上必须预留能力
|
||
- canvas 经常从 `createElement("canvas")`、`getContext()`、`toDataURL()` 进入
|
||
- WebGL 经常从 context、`getParameter()`、vendor / renderer 信息进入
|
||
|
||
也就是说，指纹对象补丁最好作为单独模块，而不是零散塞在 `document` 里。
|
||
|
||
## 19. Cookie 与存储态必须一起考虑
|
||
|
||
很多站点的参数生成，并不只依赖静态环境对象，还依赖运行态数据：
|
||
|
||
- `document.cookie`
|
||
- `localStorage`
|
||
- `sessionStorage`
|
||
- 页面初始化时种下的 token
|
||
- 某些前置请求返回的数据
|
||
|
||
因此补环境判断不能只看 Proxy 吐出来的 `undefined`。
|
||
|
||
还要看：
|
||
|
||
- 有没有读取已有 cookie
|
||
- 有没有读取已有 storage 值
|
||
- 是否依赖“浏览器中本来就存在的历史状态”
|
||
|
||
也就是说，补环境不仅是补“对象”，还要补“状态”。
|
||
|
||
## 20. 第十层：把“报错修复”升级成“检测对抗”
|
||
|
||
补环境不是只让脚本跑通。
|
||
|
||
你还要考虑它会不会检测：
|
||
|
||
- 原型链
|
||
- native code 指纹
|
||
- getter / setter
|
||
- 描述符
|
||
- `name`
|
||
- `length`
|
||
- 枚举行为
|
||
- own keys
|
||
- `instanceof`
|
||
- `constructor`
|
||
- `Symbol.toStringTag`
|
||
- `Object.prototype.toString.call(obj)`
|
||
- Node 痕迹
|
||
- 异常与堆栈
|
||
- 指纹对象
|
||
|
||
因此一份成熟的补环境流程，至少应包含三类验证：
|
||
|
||
1. 值验证
|
||
这个字段是不是存在，值对不对。
|
||
|
||
2. 结构验证
|
||
它在实例上还是原型上，描述符是否合理。
|
||
|
||
3. 指纹验证
|
||
`toString`、`toString.toString`、`name`、`length`、枚举性、原型链是否像真的。
|
||
|
||
## 21. 实操顺序建议：先粗补，再精补
|
||
|
||
推荐顺序如下：
|
||
|
||
1. 先定位目标参数、cookie、真实调用入口
|
||
2. 建最小全局对象
|
||
3. 给高风险对象套 `Proxy`
|
||
4. 先让代码跑起来
|
||
5. 根据 `get/set/has` 访问轨迹补缺失项
|
||
6. 把“直接赋值”逐步替换成“构造器 + prototype + 实例”
|
||
7. 把关键方法替换成 native 风格函数
|
||
8. 修正 getter / setter
|
||
9. 修正属性描述符
|
||
10. 修正 `name` / `length`
|
||
11. 修正 `toString` 及 `toString.toString` 路径
|
||
12. 修正 `Object.prototype.toString.call`
|
||
13. 修正 `instanceof` / `constructor`
|
||
14. 检查 Node 痕迹
|
||
15. 检查异常与堆栈
|
||
16. 检查 canvas / WebGL 等指纹对象
|
||
17. 检查 cookie / storage 是否需要预置真实值
|
||
18. 最后回到真实调用点校验结果
|
||
|
||
## 22. 补环境最终要验证什么
|
||
|
||
不是“没报错”就算完成。
|
||
|
||
至少要验证：
|
||
|
||
- 返回的参数值是否一致
|
||
- `document.cookie` 写入是否一致
|
||
- 结果长度、格式、字段名是否一致
|
||
- 后续请求是否成功
|
||
- 是否走了和浏览器相同的调用分支
|
||
- 是否触发了隐藏 fallback 逻辑
|
||
|
||
必要时还要验证：
|
||
|
||
- 描述符是否一致
|
||
- `toString` 是否一致
|
||
- `toString.toString` 是否一致
|
||
- `name/length` 是否一致
|
||
- `instanceof` 是否成立
|
||
- 原型链层级是否一致
|
||
- 异常类型、错误信息、堆栈是否暴露 Node 痕迹
|
||
- cookie / storage 是否与真实页面初始化状态一致
|
||
|
||
## 23. 对后续 skill 设计最有价值的能力模块
|
||
|
||
建议优先沉淀这些模块：
|
||
|
||
- 目标定位模块
|
||
- `document.cookie` Hook 模块
|
||
- Proxy 吐环境模块
|
||
- 最小全局环境模板
|
||
- BOM 对象模板
|
||
- DOM / `document` 模板
|
||
- `Storage` 模板
|
||
- `WebSocket` 模板
|
||
- `Worker` 模板
|
||
- 原型链构建模块
|
||
- native `toString` 保护模块
|
||
- `toString.toString` 保护模块
|
||
- getter / setter 保护模块
|
||
- 属性描述符保护模块
|
||
- `name` / `length` 对齐模块
|
||
- Node 痕迹清理模块
|
||
- 异常与堆栈伪装模块
|
||
- canvas / WebGL 指纹模块
|
||
- cookie / storage 预置状态模块
|
||
- 结果校验模块
|
||
|
||
## 24. 一句话总结
|
||
|
||
真正成熟的补环境流程，不是“给对象补几个字段”，而是：
|
||
|
||
先定位真实执行入口，再让环境自吐，再按访问路径逐步补齐对象图，并同时对原型链、原生指纹、访问器、属性描述符、函数元信息、Node 痕迹、异常堆栈、指纹对象、cookie 与 storage 状态做一致性修复，最后回到真实调用点校验结果。
|