JS Reverse

Front-End JavaScript Reverse Engineering

Overview

Modern web applications move security logic (request signing, anti-bot tokens, risk scoring) into the browser. Reversing that logic is a discipline with its own order of operations: observing traffic first, capturing the relevant code path, rebuilding the logic in a controlled local environment, and only then patching or decoding. Jumping straight to breakpoints or deobfuscation is how reversers burn hours on the wrong code.

This skill provides a five-phase workflow — Observe → Capture → Rebuild → Patch → Decode — plus the execution discipline (evidence-first, artifact per task, minimal patches) that keeps the process reproducible. It is tool-agnostic: the same workflow runs on Chrome DevTools, Playwright, puppeteer, or any CDP-capable driver, and on any runtime rebuilt in Node.js.

Source: cherry-picked and translated from zhaoxuya520/reverse-skill (skills/js-reverse, MIT license). MCP-specific tool bindings were generalized to standard browser/CDP tooling.

When to Use

Trigger phrases:

• "reverse the signing logic of this request"
• "how is this frontend token generated"
• "analyze obfuscated JS behavior"
• "rebuild a client-side algorithm in Node"
• "patch a JS function to verify a hypothesis"
• "deobfuscate control flow of a web SDK"

Use this skill when:

• A request carries a signature, token, or header you must reproduce or understand (for security review, testing, or interoperability).
• Obfuscated or minified client code hides the algorithm.
• You need to confirm behavior before writing a rewrite (verify the real runtime, never assume from source shape).

Prerequisites

• Chrome (or Chromium) with DevTools; Playwright/puppeteer if scripting.
• Node.js 18+ for local rebuilds.
• A beautifier (prettier or js-beautify) and a proficient code editor.

Workflow

Phase 1: Observe

• Open DevTools → Network, filter by the target request type; identify the target request URL.
• Open the initiator chain / call stack of that request to find the entry function.
• Locate the script that issues the request: find the JS file URL, then the function name and approximate line in the Sources panel.
• Take notes on the request header names you must reproduce and their current values.

Phase 2: Capture

• Break-on-XHR first: enable XHR breakpoints on the target URL so the stack lands at the exact call site — the most direct capture point.
• Use light runtime observation: console-log the arguments each step of the chain receives, not the whole call graph.
• Capture: the function name, the values in scope at the call site, and when the computed value is added to the request.

Phase 3: Rebuild

• Rebuild the captured call chain as a local Node.js script.
• Evidence-based only: never invent window, document, crypto, or localStorage behavior — introduce browser globals you actually saw being read (via the DevTools console or a strace of properties accessed).
• If the code needs a browser environment, run Playwright and evaluate the rebuilt logic inside the page context for parity.
• Structure the script so each step prints its output: this exposes the first divergence immediately.

Phase 4: Patch

• Apply one minimal patch per failure: on the first error or first divergence, patch the smallest thing that resolves it, retest, log.
• Never mass-edit the target logic before it runs locally.
• Patches are for verification (fix an undefined var, seed a needed value), not for finishing a half-rebuild.

Phase 5: Decode / DeepDive

• Only after the rebuild runs end-to-end does deobfuscation make sense: beautify the captured scope of the algorithm and restore control flow (switch dispatch → if/else) guided by the observed behavior.
• Extract the business logic: key derivation, signing steps, or token field semantics.
• Downgradeable: if the task only needs the signing result (not long-term reuse of the algorithm chain), phase 5 can stop at "locally reproduced the value" without full control-flow recovery.

Execution Rules

• Every task produces artifacts — the script, the capture log, the patch list. A task with no artifacts is not done.
• Final state per artifact: the runnable rebuilt script with the minimal patches and a list of every divergence observed and its resolution.
• No unexplained tool calls: every automation action must map to a step in this workflow.
• Fallbacks: when a capability has no implementation (e.g. deserializer missing), fall back to the documented generic mechanism instead of stopping.
• Evidence-first: any claim about what the code does requires a recorded run or a captured value.

Hands-On Example

Rebuild a captured signing function in Node and confirm the digest matches the traffic (Phase 3 — Rebuild). In a scratch directory, install the library with npm install crypto-js, then reproduce the observed hash:

node -e "const C=require('crypto-js'); console.log(C.MD5('a=1&t=1').toString())"
# 1f16f5f46ff3c3b478e870f6446cf656

node -e "const C=require('crypto-js'); console.log(C.HmacSHA256('data','k').toString())"
# 98755ce7a0d431b5...

Verified with Node 22 + crypto-js 4.2.0 (output above). A digest match between your rebuild and the recorded request proves you reproduced the exact computation — the same evidence used in Phase 4 to confirm a patched script preserves behavior.

Verification

Run this self-check before claiming completion:

• Target request URL and initiator chain are documented.
• Break-on-XHR or equivalent capture produced the full function chain with observed values.
• The rebuilt Node/Playwright script reproduces the target value without invented browser behavior.
• Each patch is minimal, logged, and justified (one error → one patch).
• The final value is compared live against a real page capture and matches.
• If the task needed control-flow recovery: the deobfuscated version recompiles/reruns and produces the same output.

When NOT to Use

• The logic is server-side only (no browser involvement) — protocol analysis is the right tool.
• The target is real WebAssembly — use WASM tooling and dsl-vm-reverse for JS VM targets separately.
• The JavaScript is malware (phishing pages, droppers, exploit kits) — use deobfuscating-javascript-malware instead; this skill targets legitimate app signing logic, not malicious payloads.
• You only need to call the endpoint, not reproduce its algorithm — a recorded replay may be sufficient, though context-bound tokens will break.

Anti-Rationalization Table