# Find Crypto Entry

> 定位 JS 加密参数的生成入口（函数位置+调用链+加密类型）。 TRIGGER when: 用户提到请求中的加密字段、签名参数、token生成、加密入口，或要求分析请求头/URL/Body中某个参数怎么来的。包括但不限于"找加密入口"、"xxx在哪生成"、"请求头里的xxx"、"签名怎么算的"、"这个token哪来的"、"定位加密函数"、"WebSocket消息加密"、"ws协议签名"。 DO NOT TRIGGER when: 用户只是想看请求内容、抓包、或分析非加密的普通参数。

- Skill: `zxzvsdcj/find-crypto-entry` (Agent Skill)
- Install (CLI): `npx skillmds@latest add zxzvsdcj/find-crypto-entry`
- Raw SKILL.md: https://api.skillmd.com/api/skills/zxzvsdcj/find-crypto-entry/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: zxzvsdcj (https://skillmd.com/u/zxzvsdcj)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/zxzvsdcj/find-crypto-entry

---


# find-crypto-entry

定位加密参数 **$ARGUMENTS** 的生成入口。

**目标**：找到生成该参数的函数位置（脚本 URL + 行列号 + 函数名 + 调用路径 + 加密类型）。

---

## 策略选择

根据信号选择策略，不要按固定顺序执行：

### 策略 A: 请求发起栈（最快路径）

直接获取目标请求的 JS 调用栈，从栈中定位加密逻辑：

```
1. list_network_requests → 找到目标请求的 reqid
2. get_request_initiator(reqid) → 获取发起该请求的完整 JS 调用栈
3. 分析栈帧：跳过底层框架（axios/fetch），在中上层找业务代码
4. 在可疑帧处设断点验证
```

**适用场景**: 已知目标请求、能复现触发。这是 js-reverse-mcp 提供的最高效路径——一次调用直接拿到完整调用栈，无需手动设断点。

### 策略 B: 静态搜索

用 `search_in_sources` 搜参数名（带 `excludeMinified=false`）。大多数情况下直接找到赋值位置，然后读上下文追溯来源。

**适用场景**: 参数名是明文字符串，未被混淆。

### 策略 C: XHR/Fetch 断点

`break_on_xhr` 设在请求 URL 特征上，触发后从调用栈中找业务代码帧：

```
1. break_on_xhr(url_pattern) → 设置 XHR 断点
2. 触发请求（刷新页面或操作界面）
3. get_paused_info() → 获取调用栈 + 作用域变量
4. evaluate_script(expression, frameIndex) → 在指定帧检查变量
```

**适用场景**: 静态搜索无结果，需要从请求倒推。

### 策略 D: 函数追踪（无断点监控）

用 `trace_function` 追踪可疑函数的调用：

```
1. 通过策略 B/C 找到可疑函数位置
2. trace_function(scriptId, lineNumber) → 设置 logpoint 追踪
3. 触发请求 → 观察函数调用参数和频率
4. 不中断执行，适合追踪高频调用的加密函数
```

**适用场景**: 需要观察函数调用模式（参数、频率），或断点会影响执行流（如有反调试检测时）。

### 策略 E: 预注入拦截

在页面加载前注入拦截脚本，捕获加密函数调用：

```
1. inject_before_load(script) → 注入 Hook 脚本
2. 脚本示例：劫持 XMLHttpRequest.prototype.setRequestHeader / fetch
3. 刷新页面 → 拦截脚本在所有 JS 执行前生效
4. list_console_messages() → 读取拦截到的信息
```

**适用场景**: 加密在页面初始化阶段完成，普通断点来不及；或需要 Hook 原生 API（setRequestHeader/fetch）来全量捕获。

### 策略 F: WebSocket 消息分析

定位 WebSocket 协议中的加密参数：

```
1. get_websocket_messages() → 列出 WebSocket 连接和消息概览
2. get_websocket_messages(wsId) → 获取特定连接的消息详情
3. 分析消息模式（JSON? 二进制? Protobuf?）
4. 在 WebSocket 构造/send 处设断点追溯加密逻辑
```

**适用场景**: 目标不是 HTTP 请求而是 WebSocket 消息中的加密字段。

**多策略组合**: A/B/C 可以组合使用——先 A 快速获取调用栈定位范围，再 B 静态搜索确认代码，最后 D 追踪验证。

---

## 领域知识

agent 在逆向分析中容易踩的坑，这些是无法通过推理得出的经验：

### 加密参数的 3 种常见架构

1. **业务代码直接赋值** — 在请求函数中 `headers["x-sign"] = encrypt(data)`。静态搜索直接找到。
2. **请求拦截器统一加签** — axios interceptor 或 fetch wrapper 中统一添加。搜参数名可能只在拦截器中出现一次。
3. **外部安全 SDK** — 独立 JS 文件（通常混淆）挂载全局对象（如 `window.h5sign`），业务代码调用其方法。静态搜索能找到调用处，但 SDK 内部代码全被混淆。

### OB 混淆的影响

当加密逻辑在 OB 混淆的文件中（特征：`_0x` 前缀、大型字符串数组、RC4 解密函数），**所有字符串都被加密**，静态搜索在该文件内无法匹配任何明文。但调用该文件的业务代码通常未混淆，从业务代码侧搜索更高效。

### XHR 断点命中时的堆栈特点

XHR 断点命中在 `send()` 调用处，调用栈底部通常是框架代码（axios/fetch wrapper）。加密逻辑在栈的中上层。直接跳过底部框架帧，关注业务代码帧。

### 反检测环境下的注意事项

js-reverse-mcp 内置了 Patchright 反检测引擎，但某些场景仍需注意：

- **动态加密代码**：部分站点的加密代码从 API 动态下发（不在页面 JS 中），需要先通过网络请求找到加密代码的下发接口。
- **iframe 隔离**：加密逻辑可能在 iframe 中执行。用 `select_frame` 切换到目标 frame 再搜索/断点。
- **Service Worker**：签名可能在 SW 中生成。检查 `list_scripts` 中是否有 SW 脚本。

---

## 反模式

- **不要反复 step_into** — 容易掉进框架响应式系统（Vue reactivity、React fiber）。用 `evaluate_script` 直接检查变量比单步跟踪高效得多。
- **不要在 OB 混淆文件中搜字符串** — 所有明文都被加密了，搜不到。从非混淆的调用方搜。
- **不要频繁刷新页面** — 每次刷新所有 scriptId 失效。设好断点再刷新，一次到位。
- **断点命中时优先用 evaluate_script 指定帧** — 传入 `frameIndex` 参数可以在指定调用帧执行表达式，检查该帧的局部变量。
- **不要忽略 get_request_initiator** — 这是定位加密入口最快的路径，一次调用直接获取完整 JS 调用栈，优先于手动设断点。

---

## 完成标准

找到以下信息即为完成：

```
入口位置：
- 参数：$ARGUMENTS
- 脚本：https://example.com/static/js/main.abc123.js
- 位置：第 X 行，第 Y 列
- 函数：functionName (或 anonymous)
- 调用路径：request → addSign → encrypt
- 加密类型：[标准算法名 | 外部SDK | WASM | VM保护 | 未知/需解混淆]

下一步建议：
- 标准算法 → /ast-deobfuscate 还原后用 Python 实现
- 外部 SDK → /env-patch 补环境运行
- WASM → /wasm-reverse 分析 WASM 模块
- VM 保护 → /env-patch 补环境 + 直接调用
```

只找入口，不做算法还原。