web-js-reverse-master-flow

Web JS Reverse Master Flow

Role

This skill is the master control entry point for complex Web/JS reverse engineering projects.

It does not replace specialized skills; instead, it is responsible for:

Normalizing the current task stage
Selecting the most appropriate specialized skill for the next step
Constraining the switching order to avoid misoperations like "patching the environment before the request chain has been firmly established"
Outputting the current stage, blocking points, and the next tool that must be updated

By default, complex site restoration always starts from this skill, rather than directly triggering multiple master control skills in parallel.

Responsibility boundaries:

This skill is always macro-level master control and does not sink down into a case library for a specific vendor, a specific site, or a specific kind of shell.
Even if there appears Akamai/Kasada/PX/reese84/同盾/a_bogus/腾讯滑块/阿里滑块/JSVMP/227/226/wasm/protobuf/rid/fuid/fs/bx-pp/run_js/storage.estimate/animationend such a strong clue, it only helps with pre-routing and does not change its master control role of "first determine the stage, then select the specialized skill".
Specific sites, vendors, and technical experience should be provided by $1997-pro-web-reverse-casebook or other specialized skills.

If the on-site clues already clearly match a certain type of public case, $1997-pro-web-reverse-casebook should be loaded at the same time for case pre-routing, but stage selection is still determined by this skill.

MCP Stack

This skill uses three-MCP collaboration by default and does not treat them as optional:

chrome-devtools-mcp Responsible for browser takeover, page-level debugging, Network/DOM/Runtime/CDP breakpoints and call stack observation; it is the most direct on-site evidence-gathering surface.
js-reverse Responsible for reverse engineering workflow-level source search, Hook, breakpoints, code collection, runtime evidence deposition, and WebSocket/Storage/Session state analysis.
jshook Responsible for heavier JS reverse engineering analysis, deobfuscation, Stealth, Hook, browser automation, debugger and code comprehension enhancement.

Usage rules:

First use chrome-devtools-mcp and js-reverse to obtain real samples and on-site evidence.
When entering the heavy obfuscation, semantic layer recovery, or advanced Hook/Stealth stage, explicitly introduce jshook。
It is not allowed to skip browser on-site evidence based only on static reading.
It is not allowed to directly discuss Node migration without a browser baseline sample.

Input Block

Start from the following inputs:

URL 或目标页面：
目标请求 / 字段 / cookie / 消息：
触发动作：
当前现象：
已有证据：
目标：
约束：

First complete the inputs, then determine the stage.

General Principles

Hook-first, Breakpoint-second, Full-dump-last。
First prove the real request chain, then discuss pure computation, environment patching, or replay.
First restore the semantic layer, then migrate the runtime; do not do it the other way around.
Runtime differential takes priority over blind environment patching.
Expand only one variable at a time: one hook point, one sample, one patch, one branch decision.
Any conclusion must be accompanied by runtime evidence or intermediate-state checkpoints.
Case anchors can only help with pre-routing and cannot replace evidence gates and stage determination.

Anti-Spiral Protocol

One of the primary goals of this skill is to prevent getting trapped in a "deep-dive vortex with no evidence increment for a long time" on difficult sites.

Any of the following situations is considered to have already started spinning in place:

Multiple consecutive rounds of similar operations at the same layer, but with no new request chain, write boundary, state carrier, or checkpoint
Continuously adding Hook / breakpoints / patches, yet unable to explain the first real fork
Spent a lot of time on beautify / AST transformation, but still haven't tied the logic back to the real sink.
The local environment shim keeps growing bigger, yet it's unclear which object or state is actually affecting the result.
Only looking at the final value, no longer comparing intermediate states.

Mandatory rules:

If two consecutive rounds in the same phase produce no new evidence, you must switch actions; a third repetition of the same type of operation is not allowed.
If the same problem still hasn't converged after six consecutive rounds, you must stop the current approach and escalate to the next-level strategy.
Any escalation must state clearly: why the current approach failed, what the next step plans to verify, and which assumptions have been abandoned.

The only allowed escalation directions are these:

locate Stuck: expand the real trigger scope, switch to capturing the initiator, or switch to using breakpoint stacks or browser-side invocation.
recover Stuck: reduce the recovery depth, fall back to locate re-establish the boundary, or switch to black-box reuse.
runtime Stuck: roll back to the first stable browser snapshot, rebuild the fork table, and then patch only one state surface.
env-patch Stuck: stop adding more objects and switch to browser-assisted execution, remote invocation, or a minimal proxy approach.

Prohibited:

Continuing to expand the dump scope without new evidence.
Performing full decompilation before proving the builder / writer boundary.
Performing full browser environment migration before proving the first fork point.
Using "this site is hard" as a substitute for phase judgment and stop-depth judgment.

Case anchor pre-routing

When the following clues appear, don't guess the algorithm first; first map them to the more likely phase:

Vendor / product anchors:
- Akamai、Kasada、PX、PX3、reese84、Incapsula、同盾、BlackBox、a_bogus
- Default suspicion:Phase 1 's request chain + Phase 3 's risk control / fingerprint / challenge fork.
Field / protocol anchors:
- rid、protobuf、x-s3-s4e、desc、bx-pp
- Default suspicion:Phase 1 's builder / writer boundary; if necessary, enter Phase 2 to look at wasm / the wrapper bridge.
Captcha / business anchors:
- 腾讯滑块、阿里滑块、_rand、fuid、fs
- Default suspicion: the location chain and the encryption chain coexist on two lines, and usually simultaneously trigger Phase 1、Phase 3
Shell layer anchors:
- JSVMP、227、226、while(true)+switch、dispatcher、basearr
- Default suspicion is directly Phase 2
Runtime anchors:
- run_js、storage.estimate、animationend、postMessage、worker
- By default, first do Phase 3 's runtime diff, then decide whether to enter Phase 4

If these clues appear simultaneously, the priority order is fixed as:

证据门 -> 写入边界 -> 壳层恢复(必要时) -> 运行时差分 -> Node 迁移

Main flow

Phase 0: Evidence gate

Goal:

Prove that the target request, fields, and trigger action all come from real samples, not guesses.

To do:

First run the minimal chain according to $mcp-js-reverse-playbook .
Mandatorily use chrome-devtools-mcp or $js-reverse to establish a browser baseline sample.
Create or refresh reverse-records/总览.md。
If the request chain, state chain, and sample chain are still incomplete, immediately create or refresh reverse-records/请求链路.md。

Exit conditions:

There is at least one real sample chain.
The target field or message has been proven by a real request.

Prohibited:

Starting to shim the environment before the target request has been established.
Doing algorithm recovery directly before the target field has been established.

Stuck signals:

You can only say "I suspect it's some parameter / some script," but cannot produce a real request sample.
The trigger action is unstable; repeating the operation does not yield the same chain

Required action switch:

Return to the minimal trigger action and capture a clean sample again
If the page scripts are too messy, prioritize using chrome-devtools-mcp 's Network / call stack scene, rather than reading the source code first

Phase 1: Write boundary and request chain

Primary skill:

$find-crypto-entry
$jsr-locate
If you cannot find it, you can add $js-reverse-trace-hook

MCP priority:

chrome-devtools-mcp: Network, DOM trigger points, call stack, and breakpoint scene
js-reverse: request initiator, Hook, code collection, storage/session/websocket
jshook: when ordinary search/breakpoints are insufficient for stable localization, supplement with heavier Hook and reverse engineering analysis

Goal:

Find the real sink,entry -> builder -> writer relationships, and the upstream dependency chain.

Applicable:

The parameter names are clear.
The request chain is not fully closed yet.
Suspect there is Set-Cookie, challenge, session, and response-driven dependencies.

Exit conditions:

The final write boundary has been confirmed.
The current blocker has changed from "finding the chain" to "the code is unreadable / the shell is too heavy / runtime branching".

Signals to switch to Phase 2:

while(true) + switch
A large number of junk instructions, true and false branches
JSVMP
227/226/basearr/opcode/ip/g
worker/wasm/webpack runtime
_0x string table, dynamic eval/Function
LL()[XX(XX)](), multiple string decryptors, dynamic string backfilling
Akamai/Kasada/PX dynamic strings and bridge shell
bx-pp、rid、protobuf builder 's real builder is obscured by the dispatcher
Only the dispatcher can be seen; the real builder cannot be seen

Stuck signals:

The target value can be seen, but it is impossible to tell who wrote it last
The Hook hits many functions, but none can stably return to the real request
Repeatedly searching keywords in the same bundle, without binding the field to the request boundary

Required action switch:

Switch to capturing the request initiator and call stack; do not continue blindly searching the source code
Narrow the problem down to entry -> builder -> writer three stages; no longer discuss the full chain
If the builder is obscured by the shell, immediately switch to Phase 2

Phase 2: Shell layer recovery and re-obfuscation compression

Primary skill:

$jsr-recover

Supplementary skill:

$js-controlflow-truth-sampling-prune
$js-ast-binding-alias-deobf

MCP priority:

js-reverse: collect_code, trace, breakpoints, Hook, source-level evidence
jshook: deobfuscation, Stealth, complex Hook, debugger control, script-level semantic compression
chrome-devtools-mcp: preserve the browser scene and verify the execution path of the dispatcher/bridge in the real page

Goal:

Compress the shell to the extent that it is sufficient to continue locate / runtime / replay, rather than fully restore it all at once.

What to do:

Identify the container, dispatcher, state carrier, bridge, core operator, and write-back layer.
Perform real sample trimming on flat flow or the dispatcher.
Only restore the minimal slice needed for the current task.
For JSVMP/227/226 , at least complete: entry point, state variables, key opcode family, bridge contract.
For wasm , at least complete: download point, instantiation method, imports, exports, JS-to-wasm call bridge.
For Akamai/Kasada/PX -type re-obfuscation, first freeze the sample, then extract the string decryption mapping and the minimal execution fragment.

Exit condition:

Downstream work does not need to re-strip the same layer of shell.
Already able to return to $jsr-locate to confirm the sink, or enter $jsr-runtime to handle runtime forking.

Iron rule:

Recover first, then runtime.
Do not blindly patch while the dispatcher and state carrier are still unclear. window/document/navigator。

Stuck signals:

The code is becoming more readable, but it still cannot explain the target field
Continuously adding cases / opcodes, but not binding them to the target write-back path
Deobfuscation output is growing larger, but no new verifiable checkpoints are added

Mandatory switch actions:

Reduce recovery depth; keep only the key opcode family or bridge first
If sink relevance weakens, fall back to Phase 1
If the bridging contract is already clear but the results are still inconsistent, switch to Phase 3

Stop discipline:

By default, only go as deep as 'enough to continue'; do not automatically escalate to a minimal interpreter just because the code is dirty
worker/wasm/JSVMP/227/226 In composite shell scenarios, if black-box reuse can already support downstream work, do not continue full lifting

Phase 3: Browser and Local Differential Diagnosis

Primary skill:

$jsr-runtime

Supplementary skill:

$js-runtime-diff-env-patching
Add when anti-debugging is present $js-reverse-env-antidebug

MCP priority:

chrome-devtools-mcp: establish the browser normal path and runtime scene
js-reverse: capture storage/session/network/websocket/hook intermediate states
jshook: anti-debugging, Stealth, environment countermeasures, supplementary runtime behavior verification

Goal:

Explain why it runs in the browser but not locally, and output a minimal runtime dependency list.

Prioritized classification:

Missing object
Missing state
Anti-debugging
Fingerprint/risk-control branch
Time/random number/seed drift
sign lane and token lane mixed
Browser feature channels:storage.estimate、animationend、postMessage、worker
Automation friction:run_js, formatting detection, drift as soon as DevTools is opened

Exit condition:

The first real mismatch checkpoint has been found.
It has been made clear which dependencies must be migrated and which dependencies cannot be migrated.

Iron rule:

Compare intermediate states first, then final values.
Patch state first, then patch object.
First prove that the browser feature channel is actually consumed, then patch the browser object surface.

Stuck signals:

Continuously patching objects, but the first fork point is still unclear
The final value remains inconsistent, but there is no intermediate-state comparison table
Every change affects many surfaces, and it is impossible to know which one took effect

Mandatory switch actions:

Return to the browser normal state and rebuild the 'first fork point comparison table'
Patch only one state surface at a time:cookie/storage/channel/style/time/random
If the fork cannot be explained within six rounds, stop patching the environment and switch to browser-assisted execution or proxy reuse

Phase 4: Minimal Node Migration

Primary skill:

$env-patch

MCP priority:

chrome-devtools-mcp: freeze the browser baseline sample
js-reverse: extract migratable entry points, intermediate states, and dependencies
jshook: assist local migration decisions when heavier Hook/Stealth/analysis is needed

Goal:

Move the dependencies that the browser actually needs to Node, and only move the minimal set.

Entry conditions:

The entry point is known.
The dispatcher / builder / bridge are basically clear.
The differences between the browser and local have been attributed.

Exit conditions:

Locally, it can reliably reach the target builder.
The intermediate state can be aligned with the browser.

Iron rules:

env-patch is migrating the runtime, not replacing recover。
Do not move the entire browser environment all at once.

Stuck signals:

The list of local patches keeps getting longer, but the intermediate state is not getting any closer to the browser
You can only keep the code from throwing errors by piling on objects, yet you still cannot get into the real builder
Every time you fix one object, it brings out more objects, but there is no evidence that they are consumed

Mandatory actions:

Stop patching objects, go back to Phase 3 and look only at states and forks
If the entry point is known but it still does not run stably locally, switch to browser remote invocation / browser-assisted replay
If the cost of migrating to Node is clearly higher than the benefit, keep browser-side black-box reuse and do not force localization

Phase 5: Stable reproduction and regression

Main skill:

$js-reverse-sign-replay

MCP priority:

chrome-devtools-mcp: compare against real browser results
js-reverse: verify whether the intermediate state and state dependencies are closed
jshook: perform supplementary analysis on complex obfuscation or advanced algorithm sections

Goal:

Solidify the chain into a maintainable, regressable local reproduction script.

To do:

Split normalize -> concat -> hash/encrypt -> encode
Solidify the input contract and stage checkpoints
Provide baseline and regression

Exit conditions:

Fixed inputs are stable and consistent
Variant input behavior is explainable
When later versions drift, breakpoints can be located quickly

Stuck signals:

The final value matches, but it cannot explain which intermediate states must be consistent
It drifts with a slight input change, but there is no record of which stage drifted first

Mandatory actions:

Break the regression back down into stage checkpoints, and stop looking only at the final value
If the drift comes from runtime dependencies, go back to Phase 3/4

Complex scenario branches

Branch A: Ordinary parameter site

Characteristics:

Parameter names are clear
There is no obvious VM or dispatcher shell
The code can still be traced directly

Flow:

Phase 0
Phase 1
Phase 5

Branch B: Heavy obfuscation / junk instructions / flattened control flow / JSVMP

Characteristics:

Large switch
dispatcher
JSVMP
227/226
basearr/opcode/ip/g
A large number of true and false branches
worker/wasm/runtime shell
Vendor shell:Akamai/Kasada/PX/reese84

Flow:

Phase 0
Phase 1
Phase 2
Return to Phase 1 to firmly establish the sink
Phase 3
Phase 4
Phase 5

Branch D: CAPTCHA / browser feature channel challenges

Characteristics:

腾讯滑块、阿里滑块
_rand、fuid、fs
animationend, CSS animations, style final-state value extraction
run_js, automation detection, differences between browser and local behavior

Flow:

Phase 0
Phase 1
Phase 3
If necessary, return to Phase 2 to restore the bridging layer
Phase 4
Phase 5

Branch E: Risk-control fingerprinting / vendor challenge problems

Characteristics:

Akamai、Kasada、PX、reese84、Incapsula
同盾、BlackBox、a_bogus
abck、sensor_data、bm_sz、TLS/JA4
The browser can pass, locally 403 or the challenge keeps jumping

Flow:

Phase 0
Phase 1
Phase 3
If necessary, Phase 2
Phase 4
Phase 5

Branch F: Protocol encapsulation / Wasm / Builder problems

Characteristics:

protobuf、jspb
rid、x-s3-s4e、desc、bx-pp
wasm、compileStreaming、imports/exports
builder / writer obscured by VM or wasm bridge

Flow:

Phase 0
Phase 1
Phase 2 when necessary
Phase 3
Phase 4
Phase 5

Branch G: Hard Site composite scenarios

Characteristics:

Simultaneously present JSVMP/平坦流/worker/wasm
Simultaneously present run_js/storage.estimate/animationend a category of browser feature channels
Simultaneously has Akamai/Kasada/PX/reese84/同盾/a_bogus a category of risk-control branches
Node and the browser differ greatly, and local patches diverge rapidly

Flow:

Phase 0
Phase 1
Phase 2, restore only the minimal bridging slice
Return to Phase 1 to re-establish the sink
Phase 3, first find the first fork point
Phase 4, enter only when the dependency list is already stable
Phase 5

Additional discipline:

In this scenario, it is forbidden to jump directly from Phase 2 to "full local restoration"
At any time, once the boundary anchor is lost, retreat first to Phase 1

Hard-Site Escalation Ladder

Advance difficult sites uniformly according to this escalation ladder; jumping around is not allowed:

Browser minimal sample
- Establish the real request, trigger action, target field
Write boundary
- Establish entry -> builder -> writer
Minimal shell restoration
- Restore only the dispatcher / bridge / imports / opcode that are blocking the way
First fork point diagnosis
- Make a browser vs local comparison table
Minimal runtime migration
- Migrate only dependencies proven to affect the result
Browser-assisted execution or black-box reuse
- Accept a browser-side solution when localization cost is too high
Stable regression
- Then do pure computation, proxy, or replay solidification

Escalation conditions:

The previous layer has already produced a stable tool, but it still cannot support the next step

Skipping levels is prohibited:

Doing step 5 without step 2
Claiming the local environment is already sufficient without step 4
Forcing the pursuit of "must be purely local" without the step 6 evaluation

Branch C: The browser and Node differ greatly

Characteristics:

Normal in the browser, failing locally
Locally it can generate a value, but the server continuously 403
It drifts as soon as debugging is enabled
Fingerprint, time, random numbers, risk-control sensitive

Flow:

Phase 0
Phase 1
Phase 3
Phase 4
Phase 5

Switching rules quick reference

Parameter names are clear and not heavily obfuscated: go through Phase 1 first.
Seeing JSVMP/227/226/平坦流/basearr/opcode: switch to Phase 2 first.
Seeing wasm/bx-pp/protobuf builder/动态字符串壳: usually go through Phase 1 first, then switch to Phase 2 depending on the degree of obfuscation.
Seeing run_js/storage.estimate/animationend/postMessage/worker: prioritize Phase 3.
Seeing Akamai/Kasada/PX/reese84/同盾/a_bogus: prioritize checking the mixed blockage of Phase 1 and Phase 3.
Seeing 腾讯滑块/阿里滑块/_rand/fuid/fs: prioritize handling it as a captcha dual-chain and browser feature channels.
The first real fork between the browser and Node appears: switch to Phase 3.
The diff has been attributed and local execution is being prepared: switch to Phase 4.
The chain is stable and delivery is being prepared: switch to Phase 5.

MCP execution discipline

chrome-devtools-mcp is responsible for the "real page scene"; without it there is no reliable browser baseline.
js-reverse Responsible for "reverse engineering workflow evidence"; without it, there is no stable Hook/code/state record.
jshook Responsible for "advanced reverse engineering and adversarial hardening"; included by default for heavy obfuscation, anti-debugging, stealth, and complex Hooks.
If at any stage one of the three does not provide incremental evidence, explicitly state why it is not needed at this stage rather than silently skipping it.

Deliverables

At minimum, maintain these files for each round:

reverse-records/总览.md
reverse-records/请求链路.md
reverse-records/恢复记录.md
reverse-records/运行时依赖.md
reverse-records/验证记录.md
reverse-records/状态载体卡.md
reverse-records/环境依赖清单.md
reverse-records/升级记录.md

When these tools are unavailable, do not continue digging deep for a long time.

At minimum, clearly write:

Current phase
Current blocker
Current strongest anchor
New evidence from the most recent round
If there is no new evidence, which layer to switch to next

One-sentence version

Unified workflow for restoring complex websites:

证据门 -> locate -> recover(必要时) -> runtime diff -> env-patch -> sign-replay

Where:

If the packer is heavy, recover early
If the divergence is obvious, do runtime diff first
For Node migration, only use env-patch to wrap up
Enter sign-replay only for the final delivery

About this skill

Role

MCP Stack

Input Block

General Principles

Anti-Spiral Protocol

Case anchor pre-routing

Main flow

Phase 0: Evidence gate

Phase 1: Write boundary and request chain

Phase 2: Shell layer recovery and re-obfuscation compression

Phase 3: Browser and Local Differential Diagnosis

Phase 4: Minimal Node Migration

Phase 5: Stable reproduction and regression

Complex scenario branches

Branch A: Ordinary parameter site

Branch B: Heavy obfuscation / junk instructions / flattened control flow / JSVMP

Branch D: CAPTCHA / browser feature channel challenges

Branch E: Risk-control fingerprinting / vendor challenge problems

Branch F: Protocol encapsulation / Wasm / Builder problems

Branch G: Hard Site composite scenarios

Hard-Site Escalation Ladder

Branch C: The browser and Node differ greatly

Switching rules quick reference

MCP execution discipline

Deliverables

One-sentence version