Monitored SubtleCrypto Routines

Binary Serialization Protocol

JavaScript cryptographic APIs operate on binary buffers (ArrayBuffer, Uint8Array) and opaque CryptoKey handles. Because these types cannot be passed directly across JSON IPC boundaries, webcrypto-interceptor normalizes them using structured envelopes:

{
  "__t": "Uint8Array",
  "len": 16,
  "hex": "f3a19b88210344c8b291845199201a4e",
  "utf8": "..."
}

{
  "__t": "CryptoKey",
  "type": "secret",
  "extractable": true,
  "algorithm": { "name": "AES-GCM", "length": 256 },
  "usages": ["encrypt", "decrypt"]
}

Nonces and getRandomValues Rate Limiting

Initialization vectors (IVs) and cryptographic nonces are frequently generated via crypto.getRandomValues() immediately prior to encryption.

To prevent terminal flooding from WebGL canvases or math libraries calling random functions thousands of times per second, the interceptor applies a token-bucket rate limiter that selectively logs cryptographic-length buffers (12 bytes for AES-GCM IVs, 16 bytes for AES-CBC IVs).

HLS Envelope Encryption Mechanism

HLS streams frequently protect media segments using envelope encryption (METHOD=AES-128 or METHOD=SAMPLE-AES). The player fetches a playlist manifest containing key tags:

#EXT-X-KEY:METHOD=AES-128,URI="https://stream.target.local/keys/key_01.bin",IV=0x00000000000000000000000000000001
#EXTINF:6.000,
segment_001.ts
#EXTINF:6.000,
segment_002.ts

When video players use JavaScript libraries (like hls.js, shaka-player, or video.js), segment decryption is delegated to the browser's crypto.subtle.decrypt() routine, often inside a dedicated Web Worker thread.

Worker Thread Interception

Because Puppeteer's standard console output does not capture background worker contexts by default, webcrypto-interceptor registers automatic CDP listeners on every created Web Worker target (Target.attachedToTarget).

When a worker calls crypto.subtle.importKey() to load the 16-byte raw AES key and then calls crypto.subtle.decrypt() to unpack media segments, the interceptor logs the exact key bytes and initialization vectors.

Offline Correlation Utility

node scripts/extract-keys.js session_capture_1730000000.jsonl

url:  https://media.example.local/stream/segment_001.ts
key:  f3a19b88210344c8b291845199201a4e
iv:   00000000000000000000000000000001
cmd:  openssl enc -d -aes-128-cbc -K f3a19b88210344c8b291845199201a4e -iv 00000000000000000000000000000001 -in segment_001.ts -out segment_001_decrypted.ts

Bytecode Interception Hooks

Target applications frequently embed compiled C/Rust/Go cryptography routines inside WebAssembly binaries to defeat pure JavaScript deobfuscation.

webcrypto-interceptor instruments the standard WebAssembly lifecycle APIs in src/page/stealth.js:

• WebAssembly.compile(bytes)
• WebAssembly.instantiate(bytes, importObject)
• WebAssembly.compileStreaming(responsePromise)
• WebAssembly.instantiateStreaming(responsePromise, importObject)

Payload Chunking & Reassembly

Large WebAssembly modules can exceed individual CDP IPC string length limits. The in-page hook splits large bytecode buffers into 32KB hex-encoded chunks tagged with sequence numbers (seq, of, hash).

In Node.js, src/cdp/events.js reassembles the chunks in order, verifies the hash integrity, and writes the reconstructed binary to:

wasm_modules/module_<hash>.wasm

Export Function Wrapping

When an instantiated WebAssembly instance exposes exported functions (e.g., instance.exports.encryptBlock), the toolkit wraps each export function to log its pointer arguments and return values across the JavaScript/WASM boundary:

[00:00.820] [WASM COMPILE] WebAssembly.compile called with 14,280 bytes
[00:00.825] [WASM DUMPED] Saved bytecode to wasm_modules/module_d41d8cd9.wasm
[00:00.831] [WASM HOOK] Wrapped exports: ["encryptBlock", "deriveSecret", "memory"]

Command Synopsis

node capture_server.js <URL> [options]

Options & Flags

Environment Variables

The Clean-Room Verification Loop

When reverse-engineering proprietary client-side signers, token generators, or custom obfuscators, researchers frequently rewrite the logic into a standalone library.

scripts/verify-reimpl.js provides an automated oracle that proves whether your candidate implementation produces mathematically identical outputs across all recorded real-world inputs:

Record Ground Truth -> Write Clean-Room Candidate -> verify-reimpl.js -> VERIFIED

1. Recording Input/Output Pairs

node capture_server.js "https://target.local" --hook-return "window.signPayload" --gui

2. Executing the Oracle

node scripts/verify-reimpl.js --session session_capture_1730000000.jsonl --candidate ./my_signer.js --label "window.signPayload"

3. Sandboxed Execution Security

• Network Isolation: The oracle executes candidate code inside an isolated headless browser page loaded to about:blank with zero network privileges.
• No Target Access: The candidate cannot communicate with the target website or exfiltrate session data.
• Strict Deep Equality: Compares candidate outputs against captured ground truth using type-strict, order-aware array checks and key-set-aware object diffing.