web-reverse

Web Reverse Engineering Skill (WEB)

Core principles: classify before toolchain; facts before inference; unpack before analysis; Chinese reports must be delivered.

§ Objectives and Triggers

This skill is used for Web front-end reverse engineering and signature/encryption reproduction。
For trigger scenarios, see the preceding description; if not satisfied, do not trigger.

§ Task Input (supplement if missing)

Four fields must be collected:target、objective、requirements、boundaries。

General Fields

Field	Description
`target`	URL or file path; type: WEB
`objective`	Key recovery / authentication bypass / protocol reconstruction / API signature reverse engineering / CTF flag / WASM devirtualization / JS-VM devirtualization
`requirements`	Depth: quick / standard / deep; output format; time budget
`boundaries`	Active triggering Y/N; rate limit; prohibited operations

WEB-specific Fields

Field	Description
`url scope`	Base URL, page list, login state, required roles
`interface scope`	Target API endpoints, HTTP method/path, API version
`runtime constraints`	Active triggering Y/N; rate limit; prohibited operations
`evidence requirements`	Headers Y/N; payload samples Y/N; timing waterfall Y/N; token/cookie tracing Y/N
`js protection type`	Minification only / variable renaming / string encryption / CFG flattening / ob-fuscator.io / JSFuck / eval-pack / JS-VMP / custom VM / unknown
`bundle system`	Webpack / Vite / Rollup / Parcel / Browserify / ESBuild / unknown
`wasm present`	Y/N; if Y: standalone .wasm / emscripten / wasm-pack / AssemblyScript
`source map available`	Y/N; inline / external .map / hidden in Header
`anti-debug in browser`	DevTools detection Y/N; timing detection Y/N; debugger statement Y/N

CTF-specific Fields

Field	Description
`CTF type`	web / crypto / rev
`flag format`	FLAG{...} / CTF{...} / custom regex
`known hints`	Challenge description/hints
`solver output`	flag string / usable exploit / signature replay script

§ Security and Authorization Boundaries

Perform reverse analysis only within the authorized scope; do not exceed privileges or expand the scope.
It is prohibited to execute payload samples, trigger online vulnerability exploitation, or export credentials outside the sandbox.
Permission boundaries of external platforms/environments must be confirmed upon request.

§ Output Requirements (mandatory)

Must produce:web_replay.js、Reverse_Report_CN.md。
Append as appropriate:deobf_clean.js、vm_opcodes.txt、wasm_analysis.wat、solver.py、crypto_params.json、token_flow.md。

§ Evidence and Conclusion Rules

High-confidence conclusions require cross-validation by ≥2 independent pieces of evidence.
Single-tool conclusions must be marked LOW CONFIDENCE。
Each conclusion must be accompanied by evidence anchors: bundle chunk/line number, network request URL, JS function name, xref.
Output must be partitioned:FACTS、INFERENCES、UNKNOWNS。

§ Protection Levels (T0–T7) and Handling Strategies

Level	Mode	Primary methods
T0	Minification only	Beautification + static reading
T1	Variable renaming / dead code injection	AST renaming + static reading
T2	ob-fuscator.io / string encryption / CFG flattening	Deobfuscator + runtime hook
T3	eval-packing / JSFuck / JJencode / aaencode	Unpack → T1/T2 processing
T4	JS-VMP / custom VM	VM dispatcher mapping + opcode tracing
T5	WASM core	wasm-dis + IDA/Ghidra + runtime hook
T6	T4+T5 hybrid	Order: JS-VM devirtualization → WASM reverse engineering
T7	Multiple nesting (T2+T4+T5)	Layered stripping: outer obfuscation → VM → WASM

Mandatory: Complete T0–T7 grading before selecting the toolchain; no conclusions may be drawn without unpacking/deobfuscation/devirtualization.

§ Automatic triage (JS Protection Triage)

DevTools → Sources: list all .js/.mjs bundles
Single bundle >500KB → suspected Webpack/Rollup
Spot-check readability: readable variable names = minification only; _0x... = obfuscation/renaming
Search patterns: debugger loop/JSFuck/eval pack/CFG flattening
Check .wasm fetch / WebAssembly.instantiate
Check large switch + opcode array → JS-VMP/custom VM
Look for sourceMappingURL
Identify framework fingerprints: React/Vue/Angular
Check Service Worker registration
Check WebSocket binary frames

§ Tool orchestration

Preferred: chrome-devtools-mcp

Network capture, JS source mapping, API replay, storage/token/WebSocket tracing, DevTools hook injection

Preferred chain

WEB basics:chrome-devtools-mcp → 静态JS美化 → API重放
WEB obfuscation:chrome-devtools-mcp → 反混淆 → 运行时hook → 静态验证
Webpack/Vite：chrome-devtools-mcp → bundle拆分 → chunk映射 → 入口点追踪
JS-VMP/VM：chrome-devtools-mcp → VM调度器定位 → opcode映射 → AST变换 → 运行时追踪
WASM：chrome-devtools-mcp → wasm-dis/wasm2c → IDA/Ghidra → 运行时hook
Suspected challenge statement/server-side drift：线上资源指纹 → 历史题解入口对照 → 真实点击流验证 → 协议流验证

Fallback

DevTools unavailable: declare blocked → request proxy logs/HAR.

§ Standard workflow (6 steps)

Step 1 — Context breakdown: Scoring route (feasibility/signal/risk 0-3) → choose primary path + fallback. Step 2 — Environment check: DevTools availability, scope/login state/rate limit confirmation. Step 3 — Global triangle: Grade T0–T7, identify bundle, enumerate API, check source map/WASM/SW/framework fingerprint. Step 4 — Critical path: Page load JS → initialization → auth/encryption module → sign() call site. Step 5 — Deep analysis: Data flow and parameter generation logic after deobfuscation/devirtualization. Step 6 — Dynamic verification: hooks capture + replay script to verify signature consistency.

§ Special workflow: Drift Check

When the user provides historical solutions, historical script paths, or you find that "current online behavior clearly differs from public solutions", you must first run a drift verification before deciding whether to continue digging into the client.

Drift Check minimum action set

Capture current challenge page HTML fingerprint
Enumerate currently loaded script/link/API resources
Directly request common entry points and old resource paths from historical solutions
Compare whether current resource paths match historical article/script paths
Run real click flow and protocol flow to confirm the actual current online failure point

Drift Check outputs

Current challenge page URL and HTML hash
Current script/API resource list
Old entry point availability matrix:200 / 404 / 500 / redirect
Conclusion grading:
- NO DRIFT SIGNAL
- POSSIBLE DRIFT
- HIGH PROBABILITY DRIFT

Drift Check decision rules

If the old entry point returns 404/500, and the real clickstream is inconsistent with the expectations of historical public solutions, mark at least POSSIBLE DRIFT
If the client-side explicit state has been compressed to the minimum and still cannot explain the failure, while the old entry point is invalid, mark HIGH PROBABILITY DRIFT

§ References (load on demand)

references/hooks.md: network/storage/anti-debugging/WebCrypto/CryptoJS hook code
references/deobf.md: T1–T3 deobfuscation and unpacking workflow
references/vm_wasm.md: JS-VM / WASM devirtualization steps
references/replay.md: protocol reconstruction and web_replay.js template
references/ctf.md: CTF quick triangle and deliverable requirements

§ Deliverable templates

Reverse_Report_CN.md structure

Task summary
Key findings (≤5 items)
Evidence table
Call chain
Risks and impact
FACTS / INFERENCES / UNKNOWNS
Next actions
Deliverables list
Reproduction steps

web_replay.js requirements

Can be directly node web_replay.js
Includes signature algorithm restoration and request replay
Note the sources of key parameters (key/token/nonce/ts)

§ Reusable experiment templates

1. Signer Export + Minimal Trace

Applicable: the runtime signer has already been located, but it is uncertain exactly which inputs it reads.

Actions:

For eval / dynamic bundle, make a minimal patch
Export the signer entry point and a small number of helpers
Record only:
- signer input
- signer output
- cookie / URL / a small number of dynamic globals before the request is sent
Do not start with full opcode logging; prioritize lightweight tracing

Artifacts:

trace_*.py
trace_*.out.json

2. Dynamic Global Injection Experiment

Applicable: the server response delivers k / nonce / dynamic global names; suspect these values affect the next request.

Actions:

Collect the dynamic values delivered in each page response in the real clickstream
Inject candidate values separately
Regenerate a fresh URL
Record the request result matrix

Artifacts:

experiment_*_variants.py
experiment_*_variants.out.json

3. Scope Snapshot Diff

Applicable:window / storage / cookie have all been examined; suspect module state or closure state still exists.

Actions:

Inject a minimal snapshot interface at runtime
Snapshot scope:
- Summaries of accessible module-level primitives / strings / arrays
- Summaries of key closure return values
Capture snapshots only before key requests
Automatically compare diffs between adjacent pages or adjacent requests

Artifacts:

trace_scope_snap.py
trace_scope_snap.out.json

4. Browser / Protocol Consistency Matrix

Applicable: suspect "success in the browser, failure at the protocol layer" or "the automation stack and the real clickstream are inconsistent."

Actions:

Compare at least three chains:
- real clickstream
- browser-native fetch
- protocol-layer replay
If the three are consistent, prioritize ruling out the "network stack difference" branch

Conclusion requirements:

Must explicitly state which chains are consistent and which are inconsistent
Must not draw conclusions based on a single chain alone

§ Result declaration rules

Write unconfirmed items into UNKNOWNS; provide the next action.
Empty result within the time budget: declare the empty result + what was checked + the next-best route.

§ Quality gate (completion conditions)

Protection rating complete; the critical layer has been unpacked/deobfuscated/de-virtualized.
The replay script is consistent with the browser signature.
Evidence anchors are complete and reproducible.
If historical solutions or old entry points exist, one Drift Check has been explicitly completed and a graded conclusion has been given.

About this skill

§ Objectives and Triggers

§ Task Input (supplement if missing)

General Fields

WEB-specific Fields

CTF-specific Fields

§ Security and Authorization Boundaries

§ Output Requirements (mandatory)

§ Evidence and Conclusion Rules

§ Protection Levels (T0–T7) and Handling Strategies

§ Automatic triage (JS Protection Triage)

§ Tool orchestration

§ Standard workflow (6 steps)

§ Special workflow: Drift Check

Drift Check minimum action set

Drift Check outputs

Drift Check decision rules

§ References (load on demand)

§ Deliverable templates

Reverse_Report_CN.md structure

web_replay.js requirements

§ Reusable experiment templates

1. Signer Export + Minimal Trace

2. Dynamic Global Injection Experiment

3. Scope Snapshot Diff

4. Browser / Protocol Consistency Matrix

§ Result declaration rules

§ Quality gate (completion conditions)