competition-browser-persistence
Competition Browser Persistence
Use this skill only as a downstream specialization after $ctf-sandbox-orchestrator is already active and has established sandbox assumptions, node ownership, and evidence priorities. If that has not happened yet, return to $ctf-sandbox-orchestrator first.
Use this skill when the decisive branch lives in browser-held state rather than only in visible HTML or backend source.
Reply in Simplified Chinese unless the user explicitly requests English.
Quick Start
- Identify the active persistence surface first: cookie jar, localStorage, sessionStorage, IndexedDB, Cache Storage, or service worker.
- Record origin, scope, domain, path, expiry, and key names before mutating state.
- Tie stored state to one concrete effect: request header, rendered branch, cached response, offline behavior, or hidden route access.
- Separate boot-time state from runtime-mutated state.
- Reproduce the smallest stateful sequence that reaches the decisive branch.
Workflow
1. Map Browser State Surfaces
- Inspect cookies, storage buckets, service worker registrations, cache entries, and transient globals exposed during boot.
- Record which origin, host, route, or feature flag each state item actually applies to.
- Keep auth tokens, refresh material, CSRF state, cached responses, and feature toggles in separate evidence blocks.
2. Tie State To Runtime Behavior
- Show how stored state becomes request headers, role derivation, route visibility, cached API data, or offline fallback behavior.
- Compare clean-state and mutated-state runs with one variable changed at a time.
- Distinguish UI-only state from backend-accepted state.
3. Reduce To The Decisive Persistence Chain
- Compress the result to the smallest chain: initial page or login -> state persisted -> subsequent request or render branch -> resulting capability.
- Keep extracted storage, service worker scripts, and replay steps tied to the same origin and route.
- If the problem broadens into general web routing or worker behavior outside browser persistence, switch back to the broader web-runtime skill.
Read This Reference
- Load
references/browser-persistence.mdfor the browser-state checklist, service-worker checklist, and evidence packaging.
What To Preserve
- Cookie attributes, storage keys, database names, cache keys, service worker scopes, and origin boundaries
- The exact request or render effect caused by each decisive state item
- Clean-state vs mutated-state reproduction steps for the smallest working path
More from galiais/ctf-sandbox-orchestrator
competition-prompt-injection
Internal downstream skill for ctf-sandbox-orchestrator. CTF-sandbox workflow for prompt-injection, retrieval poisoning, memory contamination, planner drift, MCP or tool-boundary abuse, and agent exfiltration challenges. Use when the user asks to analyze prompt injection, retrieval poisoning, memory contamination, planner drift, tool-argument corruption, or secret exposure caused by an agent chain. Use only after `$ctf-sandbox-orchestrator` has already established sandbox assumptions and routed here.
10competition-forensic-timeline
Internal downstream skill for ctf-sandbox-orchestrator. CTF-sandbox workflow for DFIR chronology, cross-artifact correlation, persistence chains, and incident timeline reconstruction. Use when the user asks to build a forensic timeline, correlate EVTX, PCAP, registry, disk, memory, mailbox, or browser artifacts, explain the order of attacker actions, or pinpoint the stage where the decisive artifact appears. Use only after `$ctf-sandbox-orchestrator` has already established sandbox assumptions and routed here.
9competition-agent-cloud
Internal downstream skill for ctf-sandbox-orchestrator. CTF-sandbox workflow for AI-agent, prompt-injection, MCP or toolchain, cloud, container, CI/CD, and supply-chain challenges. Use when the user asks to analyze prompt-to-tool flows, retrieval poisoning, mounted secrets, deployment drift, runtime-vs-manifest mismatches, registry provenance, or CI-produced artifacts under sandbox assumptions. Use only after `$ctf-sandbox-orchestrator` has already established sandbox assumptions and routed here.
8competition-lsass-ticket-material
Internal downstream skill for ctf-sandbox-orchestrator. CTF-sandbox workflow for LSASS-resident secrets, Windows logon sessions, Kerberos ticket caches, DPAPI-backed material, SSP artifacts, and replayable credential extraction. Use when the user asks to inspect LSASS memory, recover tickets or logon sessions, trace DPAPI or SSP material, distinguish which credential artifacts are replayable, or connect host-resident credential material to an accepted pivot or privilege edge. Use only after `$ctf-sandbox-orchestrator` has already established sandbox assumptions and routed here.
8competition-reverse-pwn
Internal downstream skill for ctf-sandbox-orchestrator. CTF-sandbox workflow for reverse engineering, malware, DFIR, firmware, pwnable, and native exploit challenges. Use when the user asks to reverse a binary, unpack a sample, inspect a memory dump or PCAP, recover malware behavior, debug a crash, or build or verify an exploit chain under sandbox assumptions. Use only after `$ctf-sandbox-orchestrator` has already established sandbox assumptions and routed here.
8ctf-sandbox-orchestrator
Default entrypoint and master ctf-sandbox-orchestrator workflow for CTF, exploit, reverse engineering, DFIR, pwnable, crypto, stego, mobile, AI-agent, cloud, container, Active Directory, Windows-host, and identity challenges. Use first when the user presents challenge infrastructure, binaries, prompts, hosts, or identities that should be treated as sandbox-internal by default and Codex needs to choose, route, and load the right downstream analysis path with concise evidence.
8