competition-websocket-runtime

Analyzes WebSocket and SSE handshakes, frames, and subscription flows to trace realtime state changes.

7|4|Updated Jun 22, 2026
One-click install
npx skills add https://github.com/dbx0/skills --skill competition-websocket-runtime-dbx0
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: competition-websocket-runtime
Source: https://github.com/dbx0/skills/tree/main/skills/web-appsec/initial-access/competition-websocket-runtime
Command: npx skills add https://github.com/dbx0/skills --skill competition-websocket-runtime-dbx0

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Realtime behavior in CTF and sandbox challenges is often hidden in WebSocket or SSE traffic rather than plain HTTP requests, making it hard to identify which handshake parameters, auth material, or frames actually drive the decisive state change. ## Core Features & Use Cases - Handshake Mapping: Records upgrade requests, headers, cookies, tokens, query params, origin checks, and negotiated subprotocols for WebSocket and SSE endpoints. - Frame Flow Decoding: Separates subscribe, ack, heartbeat, server push, reconnect, and terminal frames while recovering message schemas and channel identities. - Decisive Path Reduction: Compresses findings into the smallest replayable handshake-plus-frame sequence that proves the state change. - Use Case: During a CTF web challenge, you suspect a flag unlock is triggered by a realtime subscription. Use this Skill to map the handshake, isolate the auth frame, and reproduce the minimal frame sequence that unlocks the route. ## Quick Start Ask the agent to inspect the WebSocket handshake and decode the frame flow that changes application state, after the ctf-sandbox-orchestrator has established sandbox assumptions.

Frequently Asked Questions about competition-websocket-runtime

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I analyze WebSocket traffic in a CTF challenge?

Start by mapping the handshake: path, query, cookies, auth headers, origin, and negotiated subprotocol. Then decode the frame flow into subscribe, ack, heartbeat, push, and reconnect messages, and tie each frame to a rendered or persisted state change.

How to find which WebSocket frame changes application state?

Record every frame's type, topic, payload schema, and order, then correlate each with UI updates, storage mutations, or server actions. Reduce the result to the smallest handshake-plus-frame sequence that reproduces the decisive state change.

Does this skill work with Server-Sent Events as well as WebSockets?

Yes, it covers SSE setup paths, auth carriers, retry directives, event names, and last-event IDs alongside WebSocket handshakes. The same checklist applies for separating keepalive traffic from business messages.

When should I not use this realtime analysis workflow?

Avoid it when the challenge behavior is carried by one-shot HTTP requests rather than realtime frames, or when the hard part is generic protocol reassembly without UI or app-state linkage. In those cases a tighter protocol-level skill is more appropriate.

Why is my WebSocket reproduction failing after reconnect?

Reconnect and resubscribe behavior is often required to reproduce the issue, and ignoring it breaks the sequence. Capture the full connection lifecycle including open, subscribe, heartbeat, reconnect, and close frames.