js-reverse-ops
Skill17 starsChanged 6 days agoMITView on GitHub
Execute advanced JavaScript reverse-engineering workflows for modern web applications, including signature recovery, runtime instrumentation, deobfuscation, bundle analysis, anti-debug bypass, environment rebuild, and replay validation. Use when an agent needs to analyze obfuscated or minified frontend code, trace request-signing logic, recover crypto flows, hook browser runtime behavior, rebuild browser-only logic in Node/Python, or produce evidence-backed reverse-engineering reports. Do not use it for writing new crawlers from scratch, general frontend development, or binary/APK reverse engineering.
1 other project uses a version of this.
Adopted by
Most recently taken up by
- TaiMaBenJi/taima-skillsword for word, first seen Oct 11, 2026
Other versions1 project uses a version of this.
Word for word · 1
- TaiMaBenJi/taima-skills★ 1100% same
Edited · 0
None found.
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repositoryOne other file it gives its agents.
- AGENTS.mdAGENTS.md
The file
We split this skill into the rules it gives an agent
9 rules. About 0 are common, 6 are distinctive, and 3 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈6
Distinctive · estimate
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 14
Use this skill as a structured reverse-engineering workflow, not an ad hoc debugging session.
- Distinctive: line 18
Do NOT use this skill for:
- Very specific: line 26
When in doubt, triage first (node scripts/js_reverse_ops.js <target> --json) and let the router say whether this skill owns the task.
- Distinctive: line 53
Start from the smallest reliable context:
- Very specific: line 88
verify response looks noisy or pessimistic while data requests still succeed: treat the data endpoint as the acceptance oracle, and use …
- Distinctive: line 104
Use built-in scripts for routing, evidence, artifacts, and repeatability.
- Distinctive: line 112
Do not let external deobfuscators replace evidence.
- Very specific: line 118
Before publishing this public skill, run bash scripts/check_public_release.sh from the public repository root.
- Distinctive: line 125
Keep private corpora and local validation bundles in the private workspace.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
JS Reverse Ops
Use this skill as a structured reverse-engineering workflow, not an ad hoc debugging session.
When NOT to Use
Do NOT use this skill for:
- writing new crawlers or scrapers from scratch (no reverse-engineering objective)
- general frontend development, framework debugging, or performance tuning
- binary / APK / iOS / firmware reverse engineering (use a binary-RE skill)
- log/disk forensics or standalone crypto challenges (unless reversing the implementation is the actual blocker)
- pure network-protocol analysis without a JavaScript component
When in doubt, triage first (node scripts/js_reverse_ops.js <target> --json)
and let the router say whether this skill owns the task.
Start Here
NOW: classify the request (signature recovery, offline deobfuscation, runtime tracing, environment rebuild, ...) and load only the referenced files for that task type.NOW: if the work involves running browser JS locally, readreferences/env-rebuild-recipes.mdfirst — 10 recipe cards (native-masked classes, class-tag probes, no-host-builtins, real timers, inline proxy, calibration oracles) that prevent the most expensive sandbox mistakes.NOW: if dependencies or tooling are in doubt, followreferences/toolchain-bootstrap.mdbefore writing probes.NEXT: if a rebuilt flow "almost works" (valid first token, later failures, 200-but-wrong-answers, unexplained key divergence), stop probing and readreferences/misdiagnosis-patterns.md.ACT: enter the matching stage of the Core Workflow and execute — do not stop at confirmation.
Scope
This public release keeps:
- stage-based routing for
Locate,Runtime,Recover, andReplay - reusable scripts for extraction, runtime capture normalization, replay scaffolding, and artifact generation
- generic references, rules, and templates for browser-driven JavaScript reverse engineering
This public release intentionally excludes:
- private or site-specific case libraries
- captured test fixtures and validation corpora
- concrete benchmark targets, credentials, and replay notes tied to named sites
Core Workflow
Start from the smallest reliable context:
- unknown target: run
node scripts/js_reverse_ops.js <target-url-or-file> [--json] - existing notes, hook logs, or failure summaries: run
node scripts/map_case_to_pattern.js <notes.md>and pass--notes <notes.md>toscripts/js_reverse_ops.js - actionable playbook run: run
node scripts/run_playbook.js <target> --notes <notes.md> --out runs/currentto emit a runbook, route plan, bootstrap claim/provenance/risk/replay artifacts, and hook scaffold - next operator command: run
node scripts/recommend_next_action.js runs/current --jsonwhen a run directory exists but runtime, replay, or readiness blockers make the next step unclear - local JS or HTML target: run
scripts/triage_js.sh <path>and then the smallest extractor that matches the target family - browser-backed target: verify browser and bridge health before collecting runtime evidence
- anti-analysis symptoms: run
node scripts/select_anti_detection_profile.js --symptoms "<symptoms>"before changing hook or browser strategy; profile selection changes observation strategy only and must still be followed by runtime/replay verification - public quality check: run
node scripts/run_public_benchmarks.jsbefore publishing or after changing router, pattern memory, examples, or playbooks - public release risk audit: run
node scripts/explain_public_release_risk.js --json --strictto explain tracked-file, secret, path, capture, and generated-artifact risk before pushing - public capability summary: run
node scripts/generate_capability_scorecard.jswhen comparing this skill against other reverse-engineering packages - market-gap summary: run
node scripts/generate_market_gap_scorecard.jswhen deciding how to improve this skill against advanced reverse-engineering skills and MCP toolchains - external regression matrix: run
node scripts/compare_external_skill_matrix.js --jsonto compare this skill against browser MCP, static decompiler, agentic JS reverse, and cross-domain RE profiles - browser MCP smoke planning: run
node scripts/plan_browser_mcp_smoke.js --server-family chrome_devtools_mcp --jsonbefore executing adapter-specific browser smoke checks - browser MCP smoke verification: run
node scripts/verify_browser_mcp_smoke_record.js --record <mcp-execution.json> --jsonbefore claiming adapter smoke observations - browser MCP delivery loop: run
node scripts/run_mcp_delivery_loop.js <target> --record <mcp-execution.json> --out runs/current --jsonto scaffold, verify, promote, validate, and assess readiness in one pass - replay failure diagnosis: run
node scripts/diagnose_replay_failure.js --run-dir runs/current --jsonor pass--replay-record <record.json>before changing signer code - replay client generation: run
node scripts/generate_replay_delivery_client.js --record <accepted-replay.json> --out runs/current/replay-client --jsonto produce sanitized Node and Python replay clients - replay client validation: run
node scripts/validate_replay_delivery_client.js runs/current/replay-client --jsonbefore treating generated clients as handoff artifacts - static truth gate: run
node scripts/assess_static_recovery_truth.js --original <input.js> --recovered <output.js> --jsonbefore promoting readable static output - source-map-first static planning: if a bundle has
sourceMappingURL,sourceURL, inline maps, orX-SourceMapnotes, runnode scripts/plan_static_toolchain.js <bundle.js> --jsonbefore AST cleanup - domain handoff validation: run
node scripts/validate_domain_handoff_record.js --record <handoff-record.json> --json --strictbefore merging WASM, packet, mobile, native, or debugger findings back into JS evidence - CLI wrapper: use
node scripts/jsro.js <command>or thejsropackage bin for route, run, validate, next, benchmark, scorecard, marketgap, releaserisk, externalmatrix, mcpsmoke, mcpsmokeverify, mcploop, replaydiagnose, replayclient, replayclientcheck, statictruth, handoff, handoffcheck, install, and publish commands - one-command install or release: use
bash scripts/install_local.shandbash scripts/publish_release.sh
<!-- BEGIN PLAYBOOK_CORE_WORKFLOW -->- accepted response plus confusing browser-visible values: inspect page-side render and suppression logic before escalating into signer recovery, and use
playbooks/accepted-response-hidden-dom.md - accepted response plus page-local embedded font or glyph entities: extract the current response font, solve the glyph map at page scope, and use
playbooks/embedded-runtime-font-mapping.md - replay still fails even after one accepted digest is recovered: inspect bootstrap-time cookie write order, digest collectors, and wrapped-cookie assembly, then use
playbooks/bootstrap-digest-ladder.md - one endpoint keeps returning JavaScript first and only returns arrays after the script is executed and replayed against the same path: treat it as an iterative warmup chain instead of hunting for a second hidden endpoint, and use
playbooks/iterative-script-warmup-same-endpoint.md - signer depends on one server-issued time and one wasm or module helper: freeze the time source, prove the exact signer input shape, and use
playbooks/server-time-gated-wasm-signer.md - digest helper name looks standard, but browser output diverges from both the standard library and the raw local helper: isolate the smallest runtime patch surface first, and use
playbooks/patched-runtime-digest-branch.md - one large bundle hides a tiny runtime helper you actually need for replay: extract that helper first instead of emulating the whole page, and use
playbooks/runtime-bundle-signer-extraction.md - global token helpers are absent or misleading, but
XMLHttpRequest.openrewrites the protected URL with the signer field: treat the rewritten URL as the signer output, preserve script order and runtime state, and useplaybooks/xhr-open-url-rewrite-runtime-replay.md - visible request contract is stable but different HTTP clients diverge: escalate through a transport ladder before inventing more signer state, and use
playbooks/transport-profile-ladder.md - verify response looks noisy or pessimistic while data requests still succeed: treat the data endpoint as the acceptance oracle, and use
playbooks/lenient-verify-data-gate.md - page exposes one simple request or one helper field, but later pages fail with a token-shaped gate: prove whether the visible request is a decoy before widening into full VM recovery, and use
playbooks/decoy-page-request-hidden-token-gate.md - one challenge image is a fixed small grid with one glyph or symbol per cell: solve the grid-assignment path first, and use
playbooks/grid-challenge-template-matching.md - multi-stage challenge needs fresh reload, one seeded signer proof, and then uses one accepted stage value as the next key: validate the first baseline request before solving downstream decrypts, and use
playbooks/fresh-reload-seeded-signer-step-key-ladder.md - one replay path works for round one, but later rounds only regain parity after prior-round replay: preserve the explicit same-page round ladder, and use
playbooks/same-page-prior-round-signer-replay.md - desktop HTML is unstable but a mobile or app request profile lands on a shell page with later JSON hydration: recover the shell request wrapper and route map first, then use
playbooks/mobile-shell-api-pivot.md - For bundled crypto libraries whose primitives are environment-gated (browser versus sandbox branches, modified base64 alphabets or hash constants, sandbox tokens rejected while browser tokens pass), route to
playbooks/env-gated-crypto-differential.md. - For stateful VM signers whose captured token URLs replay successfully, route to
playbooks/browser-assisted-token-replay.mdbefore attempting VM semantic recovery. - For custom-VM signers that need a browser-free local oracle, route to
playbooks/jsdom-native-vm-differential.mdand diff instruction and constant streams against one instrumented browser ground truth. - For short-TTL tokens, route to
playbooks/short-ttl-inline-proxy.md: send the real request from inside the token-computing harness via a Promise-based resource interceptor.
<!-- END PLAYBOOK_CORE_WORKFLOW -->- packed or VM-like code: preserve the original artifact, recover structure incrementally, and label verified semantics
- replay handoff: export a stable artifact bundle before writing Node or Python delivery code
Best-Tool Baseline
Use built-in scripts for routing, evidence, artifacts, and repeatability. Use specialist tools only for the narrow job they are good at:
- source maps or original modules first, before any deobfuscation pass
webcrackfor common obfuscator.io, webpack-like bundles, string arrays, and first-pass unbundlingwakarufor modern minified output where syntax normalization and readability matter more than runtime truthast-grep, Babel, orrecastfor small targeted structural transformshumanifyor another LLM renamer only after sanitizing code and only when identifier recovery is worth sending snippets outside the workspace
Do not let external deobfuscators replace evidence. Every recovered field, cookie, signer input, or replay helper still needs a verified browser observation or a local replay artifact.
For broader comparison against adjacent reverse-engineering skills and tools, use references/external-skill-comparison-2026-06-04.md.
Publication Safety Gate
Before publishing this public skill, run bash scripts/check_public_release.sh from the public repository root. The public package must not contain:
- private site notes, live captures, credentials, cookies, tokens, or customer-specific paths
- generated
tmp/, cache,__pycache__,.pyc, or local benchmark output tracked by git - absolute local user paths, bearer tokens, GitHub tokens, cloud keys, JWTs, or private keys
- unsanitized snippets that identify a live target beyond generic examples
Keep private corpora and local validation bundles in the private workspace. Publish only generic playbooks, scripts, templates, and sanitized examples.
Primary References
references/env-rebuild-recipes.mdreferences/misdiagnosis-patterns.mdreferences/toolchain-bootstrap.mdreferences/standard-workflow-cookbook.mdreferences/stage-gates.md— hard entry/exit conditions, time-boxes, fallback chainreferences/decision-handoff.md— delta-only handoff protocol between stages/sessionsreferences/task-types.mdexamples/case-walkthrough-combinatorial-gates.md— sanitized narrative: combinatorial env gates + calibration oraclesexamples/case-walkthrough-timer-selfcheck-and-fake-200s.md— sanitized narrative: timer self-checks, time-derived keys, 200-fake-data maze
Note: the verbatim-harness scaffolding generator referenced in the full
edition is distributed with the private workspace only; this public package
documents the equivalent rules in references/env-rebuild-recipes.md.
references/stages/locate.mdreferences/stages/runtime.mdreferences/stages/recover.mdreferences/stages/replay.mdreferences/rules/evidence-rules.mdreferences/rules/runtime-first.mdreferences/rules/routing-rules.mdreferences/rules/replay-rules.md
Publishing Note
This public variant is intended for sharing as a reusable skill package. Keep private fixtures, live captures, and customer- or site-specific notes in a separate private workspace or repository.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

