competition-runtime-routing
Competition Runtime Routing
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 question is which sandbox node, proxy rule, or header-derived branch actually serves the live request.
Reply in Simplified Chinese unless the user explicitly requests English.
Quick Start
- Assume every presented hostname, domain, and node belongs to the sandbox unless the challenge path disproves it.
- Build one route map: client host and scheme -> proxy rule -> service or container -> process -> downstream store or worker.
- Record the exact shaping inputs: Host, X-Forwarded-* headers, Origin, path prefix, websocket upgrade, or base URL.
- Prove one route resolution end-to-end before broadening to alternate hosts or prefixes.
- Re-run the same request with one routing input changed at a time.
Workflow
1. Map Route Inputs
- Inspect vhost rules, reverse proxies, forwarded headers, path-prefix rewrites, upstream pools, and websocket or SSE upgrades.
- Note which parts of the request influence routing or app behavior: host, scheme, port, path, prefix, cookie scope, or origin.
- Treat public-looking domains, cloud hostnames, and separate VPS nodes as sandbox routing fixtures first.
2. Trace Route To Live Consumer
- Map hostname to proxy rule to container or process to port to downstream service.
- Compare checked-in proxy intent against live listeners, mounted configs, runtime env, and observed traffic.
- Keep headers, proxy config, and live request traces tied together in one evidence chain.
3. Prove The Decisive Deviation
- Reduce the result to the smallest request shape that flips host-based routing, tenant selection, cookie scope, or upstream target.
- Distinguish route resolution from application auth logic; prove where each decision really happens.
- If the problem shifts from routing to general web state or container runtime drift, switch back to the broader parent skill.
Read This Reference
- Load
references/runtime-routing.mdfor the routing checklist, header matrix, and evidence packaging. - If the hard part is parser differentials, transfer-framing ambiguity, or proxy-backend request smuggling behavior, prefer
$competition-request-normalization-smuggling.
What To Preserve
- Hostnames, proxy snippets, header sets, path prefixes, listener ports, and route-specific cookies
- The exact request shape that reaches the decisive backend or branch
- One compact host -> proxy -> service -> process map for the active 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