CTF-Sandbox-Orchestrator Structure and Dispatch Mechanism Explained

The CTF-Sandbox-Orchestrator is a meta-skill that coordinates competition-style tasks through a three-part architecture: a skill definition that establishes sandbox models, a router matrix for evidence-driven dispatch to child skills, and domain-specific reference bundles loaded on demand.

The CTF-Sandbox-Orchestrator serves as the top-level entry point in the zhaoxuya520/reverse-skill repository. It handles web, reverse engineering, cryptography, cloud, and Windows identity challenges by dynamically routing tasks to specialized child skills based on real-time evidence analysis.

Three Core Components of the CTF-Sandbox-Orchestrator

Orchestrator SKILL Definition

Located at [CTF-Sandbox-Orchestrator/ctf-sandbox-orchestrator/SKILL.md](https://github.com/zhaoxuya520/reverse-skill/blob/main/CTF-Sandbox-Orchestrator/ctf-sandbox-orchestrator/SKILL.md), this file defines the default workflow, operational rules, and the complete list of downstream $competition-* skills. The orchestrator uses this definition to decide whether to remain in its generic flow or delegate control to a specialized child.

The SKILL.md establishes:

• Sandbox model creation protocols
• Evidence recording standards
• Child skill eligibility criteria

Router Matrix

The dispatch mechanism lives in [router-matrix.md](https://github.com/zhaoxuya520/reverse-skill/blob/main/CTF-Sandbox-Orchestrator/ctf-sandbox-orchestrator/references/router-matrix.md). This decision table maps dominant evidence types to concrete child skills through simple conditional rules.

Reference Bundles

Domain-specific cheat-sheets stored in the references/ directory provide investigative steps once a child skill activates. These include:

• web-api.md — API authentication and runtime analysis
• reverse-native.md — Binary exploitation and native code reversing
• crypto-mobile.md — Cryptographic implementation flaws
• agent-cloud.md — Cloud infrastructure assessment
• identity-windows.md — Active Directory and Windows identity attacks

Evidence-Driven Dispatch Flow

The CTF-Sandbox-Orchestrator dispatch mechanism follows a five-stage pipeline that maintains flexibility through continuous re-evaluation.

1. Automatic Entry Point Activation

When any challenge artifact is presented, the system instantiates ctf-sandbox-orchestrator without manual intervention.

2. Sandbox Model Construction

The orchestrator builds a minimal node map representing:

hosts → proxies → containers → persistence layers

It records the first observable attack path as baseline evidence.

3. Dominant Evidence Identification

The orchestrator continuously scans for a dominant evidence type — the first clear technical indicator that narrows the problem scope. Examples include:

• "The target exposes a REST API returning 500 errors"
• "Binary crashes at a specific memory offset"
• "JWT header contains malformed kid parameter"

4. Router Matrix Consultation

Upon identifying dominant evidence, the orchestrator queries router-matrix.md to select the narrowest matching child skill. The matrix uses exclusive mapping: each $competition-* skill is downstream-only and inaccessible without orchestrator confirmation.

Sample matrix entries:

### Web And Runtime

- General site, API, auth… → `$competition-web-runtime`
- Browser storage (IndexedDB, Service Workers) → `$competition-browser-persistence`
- WebSocket / SSE → `$competition-websocket-runtime`
- Host-header / vhost routing → `$competition-runtime-routing`
- SSR template / hydration → `$competition-template-render-path`

### Reverse Engineering

- Native binary / ELF / PE analysis → `$competition-reverse-native`
- Heap / stack corruption → `$competition-reverse-pwn`
- Firmware / embedded → `$competition-reverse-embedded`

5. Child Skill Activation and Reference Loading

The selected child skill loads internally — users never invoke it manually. Simultaneously, the orchestrator pulls the matching reference file to supply concrete investigation steps.

Dynamic Re-Routing Capabilities

The CTF-Sandbox-Orchestrator structure includes built-in backtracking through re-routing rules at the bottom of router-matrix.md.

Re-routing triggers:

• Child skill no longer matches the dominant blocker → return to orchestrator
• Narrow child expands into mixed-domain chain → full reset and route rebuild

This makes the dispatch reversible and evidence-adaptive.

Internal Dispatch Examples

Standard Dispatch Sequence

# Auto-generated by orchestrator during evidence evaluation

current_skill: ctf-sandbox-orchestrator
evidence:
  - type: web_api
    detail: "API returns 500 on unauthenticated POST"

# Router matrix lookup selects narrowest match

dispatch_to: $competition-web-runtime

# Reference bundle loaded automatically

load_reference: references/web-api.md

Re-Routing on Evidence Change

# Upon discovering JWT anomaly during API investigation

evidence:
  - type: jwt_header
    detail: "kid points to unknown key"

# Matrix rematches to cryptographic skill

dispatch_to: $competition-jwt-claim-confusion

# Later: JWT identified as red herring, real blocker is queue payload

re_route:
  to: ctf-sandbox-orchestrator      # Explicit backtrack

  then: $competition-queue-worker-drift

Agent Configuration

The orchestrator's reasoning engine is configured in [agents/openai.yaml](https://github.com/zhaoxuya520/reverse-skill/blob/main/CTF-Sandbox-Orchestrator/ctf-sandbox-orchestrator/agents/openai.yaml):

name: openai
model: gpt-4o
temperature: 0.2
max_tokens: 2000

This agent evaluates evidence against the router matrix and determines dispatch targets.

Key Source Files Reference

File Path	Purpose
CTF-Sandbox-Orchestrator/ctf-sandbox-orchestrator/SKILL.md	Core orchestrator workflow and child-skill registry
CTF-Sandbox-Orchestrator/ctf-sandbox-orchestrator/references/router-matrix.md	Evidence-to-skill dispatch table
CTF-Sandbox-Orchestrator/ctf-sandbox-orchestrator/references/web-api.md	Example domain reference (web runtime)
CTF-Sandbox-Orchestrator/ctf-sandbox-orchestrator/agents/openai.yaml	LLM agent for routing decisions
docs/ARCHITECTURE.md	Repository-wide platform documentation

Summary

• The CTF-Sandbox-Orchestrator operates as a dynamic meta-skill with three layers: skill definition, router matrix, and on-demand reference bundles.
• Dispatch is evidence-driven, not task-type预设, enabling precise child skill matching based on dominant technical indicators.
• The router matrix in router-matrix.md encodes exclusive downstream relationships — no child skill bypasses the orchestrator.
• Re-routing rules guarantee reversibility when evidence scopes shift during investigation.
• Reference bundles load only after dispatch, keeping the orchestrator core domain-agnostic and modular.

Frequently Asked Questions

How does the CTF-Sandbox-Orchestrator decide which child skill to dispatch?

The orchestrator consults router-matrix.md to match the current dominant evidence type against predefined patterns. When evidence like "WebSocket handshake anomaly" or "binary crash at offset" is detected, it selects the corresponding $competition-* skill and loads the associated reference file automatically.

Can I manually invoke a child skill without going through the orchestrator?

No. According to the SKILL.md definition, all $competition-* skills are downstream-only. The matrix enforces exclusive entry: child skills cannot activate until the orchestrator confirms sandbox assumptions and performs the dispatch internally.

What happens when the dominant evidence changes mid-investigation?

The orchestrator executes re-routing. Control returns to ctf-sandbox-orchestrator, which rebuilds the evidence profile, re-queries the router matrix, and potentially dispatches to a different child skill. The re-routing rules explicitly support mixed-domain chains and backtracking to earlier uncertain steps.

Where is the LLM agent configured for orchestrator reasoning?

Agent parameters reside in [agents/openai.yaml](https://github.com/zhaoxuya520/reverse-skill/blob/main/CTF-Sandbox-Orchestrator/ctf-sandbox-orchestrator/agents/openai.yaml). The current configuration uses gpt-4o with temperature: 0.2 for deterministic routing decisions and max_tokens: 2000 for evidence analysis output.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}