从请求到代码：JSReverser-MCP网络追踪与break_on_xhr定位签名参数来源完整指南

JSReverser-MCP 是一个面向 JavaScript 逆向分析的 MCP 工具，其中网络追踪与 XHR 断点（即break_on_xhr能力，对应工具xhr_breakpoint）是还原签名参数来源的核心组合：先在真实浏览器里找到目标请求，再在请求发出前暂停执行，直接"看到"签名参数的生成现场，最后把调用链沉淀为任务证据。本文带你走完这条"从请求到代码"的完整路径。

为什么要在请求发出前暂停？

抓包只能告诉你"参数长什么样"，回答不了"参数是怎么算出来的"。签名类参数（如a-bogus、h5st一类的风控签名）往往在请求发出前的瞬间由页面 JS 动态计算，普通 F12 抓包看到的可能已经是最终结果。

JSReverser-MCP 的方法论是Observe-first（先观察）→ Hook-preferred（优先 Hook）→ Breakpoint-last（断点兜底），完整阶段定义见 reverse-workflow.md。XHR 断点属于最后的重武器：当请求确实无法靠 Hook 复现时，直接在send前把执行暂停，是还原签名来源最直接的手段。

第一步：用 network_request 锁定目标请求

打开已登录的目标页面后，先用网络请求工具把目标请求找出来：

• action=list：列出当前页面的所有请求，支持按resourceTypes过滤（如xhr、fetch），也可以用urlFilter快速筛 URL；
• action=get+reqid：查看单个请求的完整详情，包括请求头、查询参数、载荷和响应体。

💡 技巧：签名参数通常藏在 URL query 或请求体里。先用list找到那条"参数特别长、每次都变"的请求，记下它的reqid和 URL 特征，这是后续设断点的依据。

该工具的入参与实现见 network.ts。

第二步：先试 get_request_initiator，能不用断点就不打断点

设置 XHR 断点之前，强烈建议先做一次"非暂停式"溯源：

• get_request_initiator：返回发起该请求的 JavaScript 调用栈（initiator stack），直接告诉你"是哪段代码、哪一行、哪个函数"发出的请求，异步调用还会附带父调用栈（Async Parent Stack）；
• trace_request_to_code：把请求追踪到 initiator 栈帧，并给出静态代码候选位置，进一步缩小候选范围。

如果 initiator 已经指向了明确的签名函数（例如sign、generateToken），就可以直接进入单步调试或 Hook 采样，完全不需要暂停页面。调用栈溯源的实现见 debugger.ts。

第三步：设置 break_on_xhr（xhr_breakpoint）暂停请求现场

当调用链是异步拼接、initiator 拿不到有效信息时，就轮到 XHR 断点登场。JSReverser-MCP 中对应的工具是xhr_breakpoint：

• action=set+url：按URL 子串匹配设置断点，例如只填接口路径的一段特征串（/api/v2/item），无需完整 URL；
• action=remove+url：用同样的 url 模式移除断点。

底层走的是 Chrome DevTools Protocol 的DOMDebugger.setXHRBreakpoint，断点会在匹配的 XHR/Fetch 请求发送前触发暂停。核心实现见 XHRBreakpointManager.ts 与 debugger.ts。

⚠️ 注意：断点、单步等低频手工调试工具默认被compact工具档隐藏。需要时请以--toolProfile full启动服务暴露全部工具：

node build/src/index.js --toolProfile full

第四步：暂停现场读取——谁在计算签名？

断点命中后页面处于暂停状态，按以下顺序"读现场"：

1. get_paused_info：查看当前调用栈、命中位置和作用域变量（支持控制变量展开深度），这是还原签名来源最关键的一步——本地变量里往往就有待签名的原始参数（时间戳、token、业务参数拼接串等）；
2. evaluate_on_callframe：在暂停的某个调用帧里执行表达式，直接查看任意变量的值；
3. step_into/step_over/step_out：单步进入签名函数内部，跟踪参数拼接与加密过程；
4. resume：读取完毕继续执行，避免页面卡死。

这一步回答的是"签名函数的输入是什么、中间怎么变换"。结合 reverse-workflow.md 中 Capture 阶段的要求，把关键观察随手记录，不要只留在对话里。

第五步：从暂停点反查源码，固化调用链

拿到调用栈帧后，把栈帧指向的代码固定下来：

• set_breakpoint_on_text：按代码文本（函数名、特征语句）自动定位并设置断点，混淆压缩的单行文件也能用；
• find_in_script：在指定脚本中搜索字符串/变量名，返回精确行列号与上下文；
• list_scripts/get_script_source：盘点页面脚本、继续阅读具体实现。

对函数级追踪，更推荐非暂停方案：trace_function用 logpoint（条件断点）按函数名记录每次调用的参数和返回值，不打断执行；hook_function/create_hook+inject_hook则把目标函数包装成采样探针，参数和返回值自动进入__hookStore，随时用get_hook_data读取。这正体现了项目 "Hook-preferred、Breakpoint-last" 的原则。

第六步：把证据沉淀为任务工件

定位到签名生成代码后，用任务工具把证据固定下来，避免"证据只留在对话里"：

• create_reverse_task_from_request：直接从捕获到的这条网络请求创建逆向任务，自动关联请求证据；
• record_reverse_evidence：把关键观察（参数特征、initiator、调用栈帧）写入artifacts/tasks/<taskId>/；
• 网络 HAR 导出：把选定请求导出为紧凑的 HAR 快照，供离线比对；
• export_rebuild_bundle：把入口脚本、补环境与证据材料导出为本地复现工程，进入 Node 侧的补环境阶段。

工具之间的读写契约（谁读哪个数据面、谁写 task artifact）完整列在 tool-io-contract.md，全量工具参数表见 tool-reference.md。

常见卡点与排查建议

浏览器连接与启动故障另有专门文档：troubleshooting.md、browser-connection.md。

小结：一条可复用的"请求→代码"路径

1. network_request（list/get）锁定目标请求，记下 reqid 与 URL 特征；
2. get_request_initiator/trace_request_to_code先做非暂停式溯源；
3. 溯源不足时，xhr_breakpoint（break_on_xhr能力）在请求发出前暂停现场；
4. get_paused_info+evaluate_on_callframe+ 单步，读取签名函数的输入与变换；
5. set_breakpoint_on_text/trace_function固化调用链；
6. create_reverse_task_from_request+record_reverse_evidence+export_rebuild_bundle沉淀证据并进入本地复现。

按这条路径走下来，签名参数不再是一个"每次都变的黑盒"，而是有明确来源函数、明确输入、可本地复现的完整证据链。