web-reverse-env

Web reverse engineering environment patching

Overview

When using this skill, do not understand "environment patching" as casually filling in a few values for window/document/navigator .

First treat the task as one of four types of problems:

1. Missing object or missing property, code directly throws undefined
2. Object exists, but prototype chain, descriptors, getter/setter,toString exposure
3. Basic objects can run, but are further detected by fingerprints, stacks, async objects, communication objects
4. The cost of environment patching is too high; should switch to in-browser execution or JsRpc/WebSocket alternative route

By default, prioritize the "diagnosis-driven" environment patching route, rather than completing the entire browser in one go.

Quick triage

Based on task characteristics, prioritize reading the corresponding reference documents:

• The user first wants to understand the overall process or does not know where to start: read 01-workflow.md
• The user wants modular design, patch generation, or module boundary definition: read 02-module-contracts.md
• The user is stuck on document.all、native toString, stack, anti-detection,WebRTC/AudioContext/Worker: read 03-special-cases.md
• The user wants to know what the current draft is still missing: read 04-missing-points.md
• The user wants to continue expanding the external reading pool or find more non-major-site sources: read 05-diversified-reading.md
• The user wants to do regression verification, module acceptance, or judge whether the patch is stable enough: read 06-validation.md
• The user wants to understand existing GitHub frameworks, source mapping, and code-level patterns: read 07-source-map.md

Standard workflow

1. First determine the target route

First determine which category the current task belongs to:

• Only need the minimal patch to make the sample run
• Need to make it into a reusable module
• Need to consolidate it into a skill / framework
• Need to complete high-intensity detection points
• Need to switch to in-browser execution or JsRpc

If it is the last type, do not force patching to the end.

2. Collect first, then diagnose

If the user does not yet have a real browser sample:

• Prioritize using collect-browser-env.js
• Collect navigator、document、location、history、screen
• Collect cookie、localStorage、sessionStorage
• Collect basic canvas/webgl fingerprints

If the user already has run logs or error reports:

• Prioritize using observe-runtime.js
• Let missing paths, descriptor probes, prototype chain probes, and call errors surface first

Do not hard-patch a large area of objects without diagnostic information.

3. Patch by module, not randomly by page

When patching the environment, prioritize advancing by module:

1. prototype-builder
2. descriptor-guard
3. native-protector
4. Browser object module
5. performance-module
6. crypto-module
7. fingerprint-module
8. audio-fingerprint-module
9. webrtc-module
10. worker-module
11. proxy-observer
12. math-precision-module
13. stack-clean-module
14. document-all-module

If the site dies right at the start on document.all, put special object priority first.

4. First patch the gaps that allow "continued execution"

The default patch priority is as follows:

1. undefined or a missing object causes the main flow to be interrupted
2. getter / setter / method Illegal invocation
3. Prototype chain and descriptors are inconsistent
4. native toString exposure
5. Fingerprint anomaly
6. Async objects, communication objects, high-intensity detection points

5. Look at high-intensity detection points separately

When encountering the following objects, do not handle them as "ordinary BOM/DOM value patching":

• document.all
• window.crypto.getRandomValues
• performance.timing
• RTCPeerConnection
• AudioContext / OfflineAudioContext
• Worker / SharedWorker
• Math precision differences

For such objects, prioritize referring to:

• 03-special-cases.md
• 02-module-contracts.md

Resource Usage Rules

scripts

Prefer using existing scripts rather than rewriting them every time.

• collect-browser-env.js
  • Browser-side collection of environment seeds
• observe-runtime.js
  • Proxy environment output and gap aggregation
• protect-native.js
  • Function.prototype.toString, getter, setter protection
• build-plugin-graph.js
  • Build plugins/mimeTypes/enabledPlugin graph structure
• build-navigator-module.js
  • Generate Navigator/navigator/plugins/mimeTypes/getBattery module patch draft
• build-document-module.js
  • Generate Document/HTMLDocument/document/cookie/query API module patch draft
• build-storage-module.js
  • Generate Storage/localStorage/sessionStorage module patch draft
• build-fingerprint-module.js
  • Generate screen/canvas/WebGL/battery/windowMetrics module patch draft
• build-crypto-module.js
  • Generate crypto/msCrypto/getRandomValues/subtle module patch draft
• build-performance-module.js
  • Generate performance.now/timeOrigin/timing module patch draft
• build-webrtc-module.js
  • Generate RTCPeerConnection/RTCDataChannel module patch draft
• build-worker-module.js
  • Generate Worker/SharedWorker/MessagePort/BroadcastChannel module patch draft
• analyze-gap-log.js
  • Merge Proxy environment output logs into module priorities and next actions
• merge-storage-state.js
  • Merge cookie / storage runtime state
• scaffold-module.js
  • Generate module skeleton

references

When the task is complex or needs explanation, read the detailed documents again; do not load all references into context at once.

Prefer reading only the 1 to 2 that are directly relevant to the current stage.

assets

Prefer putting runtime data into assets samples, rather than hardcoding them into scripts.

Samples already prepared:

• fingerprint-seed.example.json
• navigator-sample.example.json
• document-sample.example.json
• plugin-graph.example.json
• storage-state.example.json
• crypto-sample.example.json
• performance-sample.example.json
• webrtc-sample.example.json
• worker-sample.example.json

Output Requirements

When this skill is used for an actual task, the default output should include as much as possible:

• Which type of environment patching problem the current task belongs to
• Which modules are recommended to be patched first
• Which references need to be read
• Which scripts need to be run
• If the user wants code, provide a modular patch rather than one whole messy script
• If the risk is high, clearly point out the parts that are difficult to fully simulate in pure JS

Special Rules

document.all

Clearly treat document.all as a special object.

Do not easily claim that pure JS can fully equivalently simulate it.

Prefer to explain:

• This is a native-addon / V8 API / fallback one-of-three problem
• If there is only pure JS, residual risk must be clearly stated

Proxy Anti-Detection

Do not assume by default that "the more proxies, the better."

If the user's target site detects proxies:

• First use proxy diagnostics
• Then decide whether to remove some proxies or switch to a more complete trap

JsRpc / in-browser execution

When the cost of environment patching is clearly too high, you may suggest:

• Execution inside a real browser
• JsRpc
• WebSocket return the results

This is an alternative route allowed by the skill, not off-topic.