jsr-reverse

JSR Reverse

角色与使命

jsr-reverse 仍然是 Web JS 逆向工作的默认入口技能。

它的使命是执行以下工作流主线：

intake -> evidence -> locate -> recover -> runtime -> validation -> handoff

使用它来：

• 根据当前项目状态，而不是仅根据线索词，选择下一步
• 将 evidence 和 handoff 保留在 jsr-reverse 内，而不是作为独立技能
• 只路由到 locate、recover、runtime 或 validation
• 指向当前所需的最小参考资料集

412、token、worker、basearr、protobuf、JSVMP、wasm 或 hasDebug 等线索可以帮助选择辅助参考资料，但不能替代阶段选择。

工作流主线

1. intake：规范化请求、目标、触发条件、目标和约束。
2. evidence：证明真实请求链路，并在阶段路由前更新项目记录。
3. locate：证明写入边界、接收点和上游依赖链。
4. recover：精简外壳，直到相关逻辑契约清晰且可操作。
5. runtime：解释浏览器与本地环境的差异，并确定最小运行时依赖集。
6. validation：证明等价性、检查点和最终一致性。
7. handoff：输出当前阶段决策和所需的产物更新。

允许快速分诊，但只能用于加速选择主线内的阶段，不能替代这条主线。

接入契约

从此区块开始：

URL or target page:
Target request / field / cookie / message:
Trigger action:
Current symptom:
Known evidence:
Goal:
Constraints:

复杂度评级

接入后，评定复杂度级别，以校准工作量和预期覆盖阶段：

级别	标签	特征	预期阶段
L1	透明链路	参数为可见拼接或普通映射；无混淆；无环境依赖	locate → validation
L2	单层外壳	简单混淆或 webpack 包装；一次加密调用；无环境检查	locate → recover → validation
L3	多层外壳 + 环境依赖	JSVMP / wasm / worker 桥接 + 环境依赖分支；存在反调试	完整主线：locate → recover → runtime → validation
L4	对抗性防护	多跳 Cookie + 动态代码生成 + 反调试 + 环境指纹识别 + 风险分支（例如 RS/瑞数、某些验证码 SDK）	完整主线并进行多轮迭代；预期阶段回退

规则：

• 在接入时评级，但如果后续证据揭示了隐藏的复杂性，应上调。没有证据证明时，绝不下调。
• L1/L2 任务可以使用精简交接卡，并可在产物中跳过 recover/runtime 注释。
• L3/L4 任务必须使用完整交接卡和完整产物生命周期。
• 评级是校准信号，不是路由覆盖规则。阶段选择仍应依据工程状态，而不是评级。

接入后，用通俗语言总结工程状态：

• 目标请求是真实且已捕获，还是仍停留在猜测？
• 上游依赖链是真实的、部分确认的，还是未知的？
• 写入边界是已证明、接近但仍隐藏，还是尚未找到？
• 主要阻碍是精简外壳、运行时差异，还是检查点证明？
• 下一步必须更新哪个产物？

证据关卡

出现以下任一情况时，在选择路由阶段前运行此关卡：

• 目标请求尚未通过真实样本确认
• 上游依赖链仍是猜测
• 已知触发操作，但尚未记录请求证据
• 当前任务包含多个假设，但没有请求链路记录加以厘清

此关卡保留在 jsr-reverse 内，不作为独立技能。

运行此关卡时，必须先更新 reverse-records/请求链路.md，再选择路由阶段。

确切的 Request Chain Judgment 格式和记录细节请参阅 references/request-chain-recording.md。

阶段契约

locate

目的

证明目标请求、字段、Cookie 或消息的真实写入边界、写入点和上游状态链。

适用情形

• 尚未证明目标请求或写入点
• 上游依赖链不完整
• 写入边界只是猜测，而非实际观察所得
• 当前证据表明“我们仍不知道该值在哪里或如何写入”

执行内容

• 确认实际请求链和发起路径
• 将范围缩小到写入目标值的最小边界
• 确定哪些上游状态转换会产生影响，哪些不会
• 请求链路更清晰后，更新 reverse-records/请求链路.md

产出

• 真实的目标请求样本
• 已证实的写入点或写入边界
• 具体到足以支持后续工作的上游依赖链

退出条件

写入点和上游链已足够明确，下一个阻碍是精简外壳，而非发现请求。

不适用情形

• 主要阻碍已证实是在写入点／外壳边界明确后出现的运行时差异
• 工作已缩减为仅需证明等价性

不要执行

• 在写入边界尚未明确前进行大范围反混淆
• 在写入点仍靠猜测时修补环境

recover

目的

精简已证实边界周围的外壳，直到后续所需的逻辑契约变得可读、可追踪或可调用。

适用情形

• 写入点或写入边界已接近明确，且真实可靠
• 下一个阻碍是混淆、分发器结构、打包辅助函数、worker、wasm、webpack 引导程序、协议封装或类似外壳逻辑
• 项目不再需要优先发现请求

执行内容

• 仅移除或绕过阻碍后续理解的外壳层
• 恢复后续工作所需的辅助函数、分发器、桥接层、协议或加载器契约
• 将精简工作控制在最小范围，并围绕已证实的边界进行

产出

• 精简后的外壳或恢复出的契约
• 运行时执行或验证所需的最小可调用或可检查逻辑片段

退出条件

外壳已精简到足够程度，下一个阻碍是环境适配或一致性证明，而非代码隐藏。

不适用情形

• 尚未证实真实的写入边界
• 任务主要是找出浏览器执行与本地执行之间的首个差异

不要执行

• 桥接契约或操作逻辑片段已足够时，仍进行完整反编译
• 进行与当前边界无关、仅由主题驱动的恢复工作

runtime

目的

解释并消除浏览器执行与本地执行或受控执行之间的首个关键差异。

适用情形

• 写入点和外壳边界已足够明确
• 浏览器执行与本地执行在状态、时序、分支或环境事实方面存在差异
• 下一个问题是需要适配哪些最少的运行时事实

执行内容

• 找出首个真实差异点
• 确定维持执行一致所需的最小依赖集
• 区分由生命周期产生的事实与可修补的表层事实
• 用户希望避免大规模环境修补时，将运行时适配视为最后一步

产出

• 首个差异的说明
• 最小运行时依赖集
• 有依据的重放、修补、浏览器辅助执行或分阶段验证方案

退出条件

运行时差异已得到解释，剩余工作是证明等价性或进行最终一致性检查。

不适用情形

• 写入点或外壳边界仍靠猜测
• 任务仍需先证明请求链或精简外壳

不要执行

• 未证明首个差异就盲目叠加补丁
• 已有更小的适配方案时，将运行时工作扩展为通用逆向工作

validation

目的

证明恢复出的路径、运行时适配情况或复现结果，在检查点和最终输出层面都站得住脚。

适用时机

• 主要阻碍已不再是发现、精简或运行时适配
• 当前工作需要检查点证明、等价性证明或最终一致性证明
• 任务仅涉及验证

应做事项

• 比较具体检查点，而不只是最终输出
• 证明输出在哪些地方一致、分歧或仍未得到证明
• 明确需要哪些工件或证据才能弥补剩余的证明缺口

产出

• 站得住脚的等价或非等价结论
• 用于交接的具体检查点和结论

退出条件

证明足够具体，可以进行交接；下一位读者能看清哪些问题已解决、哪些仍未解决。

以下情况不应进入

• 项目仍缺少真实请求链、接收端、shell 精简结果或运行时说明

不要这样做

• 在中间检查点不一致时，仅凭最终输出相似就认定通过
• 对比证据不完整时隐瞒不确定性

路由规则

路由始终分两步进行。

第 1 步：根据工程状态选择阶段

根据当前项目状态选择阶段：

• 如果请求真实性、接收端或上游链路仍未得到证明，选择 locate
• 如果边界已得到证明，但 shell 仍隐藏着可用的逻辑契约，选择 recover
• 如果边界和 shell 已足够清晰，但执行在不同环境间存在差异，选择 runtime
• 如果剩余工作是证明、比较或完成检查点验证，选择 validation

快速示例：

• 如果真实链路仍未得到证明，412、403、cookie 跳转或 token 线索仍应进入 locate
• 只有任务已越过 locate 阶段的边界时，worker、wasm、protobuf 或 JSVMP 线索才进入 recover
• 只有边界已明确且问题是环境差异时，basearr 或 hasDebug 线索才进入 runtime

第 2 步：为该阶段选择最精简的参考资料集

选定阶段后，阅读：

• 恰好 1 份该阶段的核心参考资料
• 再加上至多 1-2 份与当前阻碍相符的主题参考资料

不要颠倒顺序。不要先选参考资料，再据此推断阶段。

如果新证据解决了 locate 阶段的问题，而下一个阻碍变为 shell 精简、辅助函数契约、分发器流程或不透明对象结构，则在同一轮中立即切换到 recover。

每次切换阶段后：

1. 在新阶段的输出契约之前，按照 references/stage-handoff-protocol.md 输出交接卡。
2. 在提出下一项调试操作之前，重新加载新阶段的核心参考资料和主题参考资料。之前阶段的参考资料不能替代新阶段的参考资料。

主题资料挂载规则

选定阶段后再选择主题参考资料。运行证据门槛时，应单独使用证据工件参考资料。

各阶段的核心参考资料

• locate 核心资料：references/locate-workflow.md
• recover 核心资料：references/recover-strategy.md
• runtime 核心资料：references/runtime-diagnosis.md
• validation 核心资料：references/equivalence-and-validation.md

证据工件支持

• 运行证据门槛时，或必须更新 reverse-records/请求链路.md 时，使用 references/request-chain-recording.md。这是证据工件参考资料，不属于主题挂载。

跨阶段参考资料

• 每次跨越阶段边界时，都必须使用 references/stage-handoff-protocol.md，不可省略
• 怀疑存在错误路径模式时，或在确定调查方向前进行预检时，使用 references/anti-patterns.md

主题挂载策略

先阅读核心参考文档，然后根据当前阻塞点，最多再添加 1–2 份匹配的主题参考文档：

• references/crypto-entry-locating.md：在 locate 阶段定位 sign、token、动态请求头或加密请求字段时使用
• references/hook-and-boundary-patterns.md：在 locate 阶段观察钩子、断点、发起者或边界时使用
• references/jsvmp-and-ast.md：在 recover 阶段处理 JSVMP、分发器循环、扁平化或 AST 密集型外壳时使用
• references/ast-deobfuscation-playbook.md：在 recover 阶段处理字符串表恢复、辅助函数内联、AST 转换或 bundle 解包时使用
• references/wasm-worker-webpack.md：在 recover 阶段处理 worker、wasm、webpack/runtime、引导程序或加载器逻辑时使用
• references/protocol-and-long-connection.md：选定阶段后，将协议作为跨阶段主题处理时使用，适用于 WebSocket、protobuf、SSE、心跳、ack 或续期
• references/anti-debug-and-risk-branches.md：在 runtime 阶段处理反调试或分支翻转时使用
• references/minimal-env-design.md：在 runtime 阶段设计最小环境时使用
• references/sdenv-fit-check-and-routing.md：在 runtime 阶段处理生命周期产生的状态、导航产生的状态或重放路由时使用

仅当团队仍在确认真实写入边界时，断点命中检查才属于 locate 阶段。一旦当前调用链已确认真实，下一步要跨辅助函数（例如 _$jR -> _$cg）定向步入，以恢复 _$_U、_$$j、分发器或桥接契约，就应先将阶段切换到 recover，再挂载 references/recover-strategy.md，然后挂载匹配的主题参考文档。

RS / 瑞数挂载策略

RS 线索不会取代阶段选择。

• 412、403、挑战页面、meta[r=m]、r2mKa、$_ts、$_ts.l__、首跳 / 次跳 Cookie、hasDebug 和 basearr 都是用于选择辅助参考文档的信号
• 选定阶段后，添加最符合该阶段的最少 RS 参考文档：
  • 在 locate 阶段使用 references/rs-collection-and-two-hop-routing.md
  • 在 recover 阶段使用 references/rs-recovery-anchors.md
  • 在 runtime 阶段使用 references/rs-runtime-and-basearr-fit.md

协议可能出现在多个阶段。只有在阶段已选定后，才添加对应参考文档。

记录与交接规则

• 如果运行证据门禁，在输出路由阶段内容前，更新 reverse-records/请求链路.md。
• 每次阶段切换时，按照 references/stage-handoff-protocol.md 输出一张交接卡。L1/L2 任务可以使用精简模式；L3/L4 必须使用完整格式。
• 只有在阶段发生变化或请求证据有实质变化时，才重复输出阶段内容。
• 如果主题挂载改变了当前调查路径，则重复输出阶段内容，并在交接前更新当前产物。
• 当前产物：reverse-records/请求链路.md。
• 交接内容必须关联当前产物，而非线索列表。
• 仅引用 jsr-reverse/references/*。

输出契约

路由后始终输出此代码块：

Complexity: L{1-4}
Current stage:
Why this stage now:
Read now:
Required artifact:
Exit condition:

要求：

• 必须在接收任务时评定 Complexity；如果后续证据揭示隐藏复杂性，则应上调。
• Why this stage now 必须说明工程进展状态，而不只是列出线索词。
• Read now 必须恰好包含 1 份核心参考文档，以及最多 1–2 份主题参考文档。
• Required artifact 必须指向下一步需要更新的产物或阶段输出。
• 如果运行了证据门禁，Required artifact 必须设为 reverse-records/请求链路.md，并在其中附上当前阶段结论。

示例

Current stage: locate
Why this stage now: The target request is still partly guessed, the upstream cookie dependency is not yet proven from a real capture, and the team does not have a stable write boundary for the token field.
Read now: references/locate-workflow.md + references/request-chain-recording.md + references/crypto-entry-locating.md
Required artifact: reverse-records/请求链路.md
Exit condition: The target request, upstream dependency chain, and token write boundary are all proven from real evidence.

Current stage: recover
Why this stage now: The request chain and write boundary are already real, but the usable logic is still hidden behind a worker bootstrap and packed helper layer, so the next blocker is shell reduction rather than runtime fit.
Read now: references/recover-strategy.md + references/wasm-worker-webpack.md
Required artifact: recovered worker/bootstrap contract for the target boundary
Exit condition: The shell is reduced enough that the next blocker is runtime fit or validation, not hidden control flow.

Current stage: runtime
Why this stage now: The sink and shell boundary are already clear, but local execution diverges at a fixed environment-dependent branch after browser lifecycle state is consumed.
Read now: references/runtime-diagnosis.md + references/minimal-env-design.md + references/rs-runtime-and-basearr-fit.md
Required artifact: first-divergence note and minimum runtime dependency set
Exit condition: The first divergence and minimum fit set are concrete enough to move into validation.

防护规则

• 如果已有实时请求和发起方链路，就不要从大范围源码 grep 入手。
• 如果真实请求链路仍是猜测，就不要跳过证据关卡。
• 不要仅凭 412、token、worker、basearr、protobuf 或其他线索词来决定阶段。
• 如果写入边界尚未证实，就不要跳到运行时修补。
• 如果桥接契约或操作符切片已经足够，就不要完整反编译 shell。
• 在检查第二跳的使用情况之前，不要将 RS 第一跳素材视为完整。
• 如果中间检查点不一致，就不要认为最终输出匹配已足够。
• 一旦边界已证实，就不要在 locate 阶段继续定向单步调试、恢复辅助函数契约或补全对象结构；应先切换到 recover。
• 每次捕获请求链路或发生重大变更后，立即更新 reverse-records/请求链路.md。
• 主题引用应尽量精简；不要把这项技能变成参考百科全书。