release: v1.0.1
This commit is contained in:
zhaoxuya520
@@ -0,0 +1,18 @@
|
||||
# 行尾规范：sh 脚本强制 LF（Linux/macOS/Kali 可执行）
|
||||
*.sh text eol=lf
|
||||
*.ps1 text eol=crlf
|
||||
*.bat text eol=crlf
|
||||
*.py text eol=lf
|
||||
*.js text eol=lf
|
||||
*.java text eol=lf
|
||||
*.json text eol=lf
|
||||
*.md text eol=lf
|
||||
*.yml text eol=lf
|
||||
*.yaml text eol=lf
|
||||
*.toml text eol=lf
|
||||
|
||||
# 二进制
|
||||
*.jar binary
|
||||
*.zip binary
|
||||
*.png binary
|
||||
*.keystore binary
|
||||
@@ -0,0 +1,3 @@
|
||||
# GitHub funding links
|
||||
custom:
|
||||
- "mailto:24781737@qq.com"
|
||||
@@ -0,0 +1,172 @@
|
||||
name: Auto-merge field-journal PRs
|
||||
|
||||
on:
|
||||
pull_request:
|
||||
types: [opened, synchronize]
|
||||
paths:
|
||||
- 'skills/field-journal/**'
|
||||
|
||||
jobs:
|
||||
validate-and-merge:
|
||||
runs-on: ubuntu-latest
|
||||
permissions:
|
||||
contents: write
|
||||
pull-requests: write
|
||||
env:
|
||||
PR_NUMBER: ${{ github.event.pull_request.number }}
|
||||
PR_TITLE: ${{ github.event.pull_request.title }}
|
||||
PR_SUBJECT: ${{ format('[field-journal] {0}', github.event.pull_request.title) }}
|
||||
|
||||
steps:
|
||||
- name: Checkout PR
|
||||
uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
|
||||
with:
|
||||
fetch-depth: 0
|
||||
|
||||
- name: Validate PR safety
|
||||
id: validate
|
||||
run: |
|
||||
set -e
|
||||
|
||||
# 1. 只允许修改 field-journal 目录下的 .md 文件
|
||||
CHANGED_FILES=$(gh pr diff "$PR_NUMBER" --name-only)
|
||||
echo "Changed files:"
|
||||
echo "$CHANGED_FILES"
|
||||
|
||||
# 严格白名单：只允许 field-journal 下的 .md 文件
|
||||
INVALID_FILES=$(echo "$CHANGED_FILES" | grep -v '^skills/field-journal/.*\.md$' || true)
|
||||
if [ -n "$INVALID_FILES" ]; then
|
||||
echo "❌ BLOCKED: PR 修改了非 field-journal 文件"
|
||||
echo "$INVALID_FILES"
|
||||
echo "valid=false" >> $GITHUB_OUTPUT
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# 不允许修改 CONTRIBUTE-BACK.md 和 _template.md（系统文件）
|
||||
SYSTEM_FILES=$(echo "$CHANGED_FILES" | grep -E '(CONTRIBUTE-BACK\.md|_template\.md)' || true)
|
||||
if [ -n "$SYSTEM_FILES" ]; then
|
||||
echo "❌ BLOCKED: 不允许修改系统文件"
|
||||
echo "$SYSTEM_FILES"
|
||||
echo "valid=false" >> $GITHUB_OUTPUT
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# 2. 文件数量限制（单次 PR 最多 5 个文件）
|
||||
FILE_COUNT=$(echo "$CHANGED_FILES" | wc -l)
|
||||
if [ "$FILE_COUNT" -gt 5 ]; then
|
||||
echo "❌ BLOCKED: 单次 PR 文件数超过 5 个（实际 $FILE_COUNT）"
|
||||
echo "valid=false" >> $GITHUB_OUTPUT
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# 3. 逐文件安全扫描
|
||||
for file in $CHANGED_FILES; do
|
||||
if [ ! -f "$file" ]; then
|
||||
continue
|
||||
fi
|
||||
|
||||
echo "--- Scanning: $file ---"
|
||||
|
||||
# 3a. Prompt injection 检测（宽模式）
|
||||
if grep -iE "(ignore previous|ignore all|you are now|forget (all|everything)|disregard|new instructions|system prompt|override|jailbreak|DAN mode|bypass safety)" "$file"; then
|
||||
echo "❌ BLOCKED: $file 包含 prompt injection 特征"
|
||||
echo "valid=false" >> $GITHUB_OUTPUT
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# 3b. HTML/JS 注入检测
|
||||
if grep -iE "(<script|<iframe|<object|<embed|<form|<input|javascript:|onerror=|onload=|onclick=|onmouseover=|onfocus=|data:text/html)" "$file"; then
|
||||
echo "❌ BLOCKED: $file 包含 HTML/JS 注入代码"
|
||||
echo "valid=false" >> $GITHUB_OUTPUT
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# 3c. 可执行代码/shell 命令伪装检测
|
||||
if grep -E "^(#!/|import os|import subprocess|require\('child_process|from os import|exec\(|eval\(|os\.system|subprocess\.|Runtime\.getRuntime|ProcessBuilder|powershell -e|cmd /c|curl .* \| (bash|sh)|wget .* -O- \| (bash|sh))" "$file"; then
|
||||
echo "❌ BLOCKED: $file 包含可执行代码/恶意命令"
|
||||
echo "valid=false" >> $GITHUB_OUTPUT
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# 3d. 编码绕过检测（base64 编码的命令）
|
||||
if grep -iE "(base64 -d|base64 --decode|atob\(|Buffer\.from\(.*base64|echo .* \| base64)" "$file"; then
|
||||
echo "❌ BLOCKED: $file 包含 base64 编码绕过特征"
|
||||
echo "valid=false" >> $GITHUB_OUTPUT
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# 3e. 未脱敏 token/key 检测（扩展模式）
|
||||
if grep -iE "(AKIA[0-9A-Z]{16}|sk-[a-zA-Z0-9]{20,}|ghp_[a-zA-Z0-9]{36}|gho_[a-zA-Z0-9]{36}|npm_[a-zA-Z0-9]{36}|xox[baprs]-[a-zA-Z0-9-]+|ya29\.[a-zA-Z0-9_-]+|AIza[a-zA-Z0-9_-]{35}|[0-9]+-[a-zA-Z0-9_]{32}\.apps\.googleusercontent\.com|sk_live_[a-zA-Z0-9]{24,}|rk_live_[a-zA-Z0-9]{24,}|sq0atp-[a-zA-Z0-9_-]{22})" "$file"; then
|
||||
echo "❌ BLOCKED: $file 包含疑似真实 API key/token"
|
||||
echo "valid=false" >> $GITHUB_OUTPUT
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# 3f. 真实 IP 地址检测（非 RFC1918 私有地址、非示例地址）
|
||||
# 允许: 10.x.x.x, 172.16-31.x.x, 192.168.x.x, 127.x.x.x, 0.0.0.0
|
||||
if grep -oE '\b([0-9]{1,3}\.){3}[0-9]{1,3}\b' "$file" | grep -vE '^(10\.|172\.(1[6-9]|2[0-9]|3[01])\.|192\.168\.|127\.|0\.0\.0\.0|255\.|224\.)' | grep -vE '^(198\.51\.100\.|203\.0\.113\.|192\.0\.2\.)' | head -5 > /tmp/real_ips; then
|
||||
if [ -s /tmp/real_ips ]; then
|
||||
echo "⚠️ WARNING: $file 可能包含未脱敏的真实 IP："
|
||||
cat /tmp/real_ips
|
||||
echo "❌ BLOCKED: 请将真实 IP 替换为 10.x.x.x 或 192.168.x.x"
|
||||
echo "valid=false" >> $GITHUB_OUTPUT
|
||||
exit 1
|
||||
fi
|
||||
fi
|
||||
|
||||
# 3g. 文件大小检查（单文件 50KB 上限）
|
||||
SIZE=$(wc -c < "$file")
|
||||
if [ "$SIZE" -gt 51200 ]; then
|
||||
echo "❌ BLOCKED: $file 超过 50KB（$SIZE bytes）"
|
||||
echo "valid=false" >> $GITHUB_OUTPUT
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# 3h. Markdown 结构验证（必须以 # 开头，证明是正常 journal）
|
||||
FIRST_CONTENT_LINE=$(grep -m1 -v '^$' "$file" || echo "")
|
||||
if [[ ! "$FIRST_CONTENT_LINE" =~ ^#\ ]]; then
|
||||
echo "❌ BLOCKED: $file 不是有效的 field-journal 格式（必须以 # 标题开头）"
|
||||
echo "valid=false" >> $GITHUB_OUTPUT
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# 3i. 链接/URL 安全检测（不允许外部可执行链接）
|
||||
if grep -iE "(https?://.*\.(exe|msi|bat|cmd|ps1|sh|py|rb|pl|vbs|js)(\?|$|[\"' ]))" "$file"; then
|
||||
echo "❌ BLOCKED: $file 包含指向可执行文件的外部链接"
|
||||
echo "valid=false" >> $GITHUB_OUTPUT
|
||||
exit 1
|
||||
fi
|
||||
|
||||
echo "✅ $file 通过安全检查"
|
||||
done
|
||||
|
||||
echo ""
|
||||
echo "✅ 所有文件通过安全审核"
|
||||
echo "valid=true" >> $GITHUB_OUTPUT
|
||||
env:
|
||||
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
|
||||
|
||||
- name: Auto-merge if valid
|
||||
if: steps.validate.outputs.valid == 'true'
|
||||
run: |
|
||||
gh pr merge "$PR_NUMBER" \
|
||||
--auto --squash \
|
||||
--subject "$PR_SUBJECT"
|
||||
env:
|
||||
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
|
||||
|
||||
- name: Comment on failure
|
||||
if: steps.validate.outputs.valid == 'false'
|
||||
run: |
|
||||
gh pr comment "$PR_NUMBER" \
|
||||
--body "❌ **自动审核未通过**
|
||||
|
||||
本 PR 未通过安全检查，无法自动合并。可能的原因：
|
||||
- 修改了 field-journal 以外的文件
|
||||
- 内容包含可疑的 prompt injection 特征
|
||||
- 内容包含未脱敏的 API key/token
|
||||
- 单个文件超过 50KB
|
||||
|
||||
请检查并修正后重新提交。"
|
||||
env:
|
||||
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
|
||||
@@ -0,0 +1,128 @@
|
||||
# reverse-skill CI：路由回归 + 结构一致性 + 供应链 pin gate + 冒烟
|
||||
# 矩阵：windows-latest（原生 powershell 5.1） + ubuntu-latest（pwsh + powershell shim）
|
||||
# 触发：所有分支（含 fork 的改进分支），PR 也触发
|
||||
name: CI
|
||||
|
||||
on:
|
||||
push:
|
||||
pull_request:
|
||||
|
||||
jobs:
|
||||
routing-tests:
|
||||
name: routing tests (${{ matrix.os }})
|
||||
strategy:
|
||||
fail-fast: false
|
||||
matrix:
|
||||
os: [windows-latest, ubuntu-latest]
|
||||
runs-on: ${{ matrix.os }}
|
||||
steps:
|
||||
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
|
||||
|
||||
# 脚本内部以 `powershell` 调用子进程；Linux runner 只有 pwsh，做个 shim
|
||||
- name: powershell shim (linux)
|
||||
if: runner.os == 'Linux'
|
||||
shell: bash
|
||||
run: sudo ln -sf "$(command -v pwsh)" /usr/local/bin/powershell
|
||||
|
||||
- name: Routing regression (163 cases)
|
||||
shell: pwsh
|
||||
run: ./skills/scripts/test-routing.ps1
|
||||
|
||||
- name: Routing coherence + supply-chain pin gate
|
||||
shell: pwsh
|
||||
run: ./skills/scripts/verify-routing-coherence.ps1
|
||||
|
||||
- name: Smoke (verify + parse + quick route)
|
||||
shell: pwsh
|
||||
run: ./skills/scripts/smoke.ps1
|
||||
|
||||
- name: INDEX.md up-to-date check
|
||||
shell: pwsh
|
||||
run: ./skills/scripts/extract-summaries.ps1 -Check
|
||||
|
||||
- name: All JSON manifests valid
|
||||
shell: pwsh
|
||||
run: |
|
||||
Get-Content skills/scripts/bootstrap-manifest.json -Raw -Encoding UTF8 | ConvertFrom-Json | Out-Null
|
||||
Get-Content kali/scripts/bootstrap-manifest.json -Raw -Encoding UTF8 | ConvertFrom-Json | Out-Null
|
||||
Get-Content skills/config/routing.json -Raw -Encoding UTF8 | ConvertFrom-Json | Out-Null
|
||||
Get-Content skills/tests/routing-benchmark.json -Raw -Encoding UTF8 | ConvertFrom-Json | Out-Null
|
||||
Write-Host "All JSON valid"
|
||||
|
||||
sh-syntax:
|
||||
name: shell script syntax check
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
|
||||
- name: bash -n all .sh
|
||||
shell: bash
|
||||
run: |
|
||||
set -e
|
||||
while IFS= read -r f; do
|
||||
bash -n "$f"
|
||||
echo "syntax OK: $f"
|
||||
done < <(git ls-files '*.sh')
|
||||
|
||||
- name: Structured routing parity (Bash)
|
||||
shell: bash
|
||||
run: |
|
||||
set -euo pipefail
|
||||
scratch="$(mktemp -d)"
|
||||
trap 'rm -rf "$scratch"' EXIT
|
||||
while IFS='|' read -r hint expected; do
|
||||
out="$scratch/$expected"
|
||||
bash skills/scripts/master-route.sh --hint "$hint" --out-dir "$out"
|
||||
grep -Eq "^- primary: ${expected}$" "$out/route-scope.md"
|
||||
done <<'CASES'
|
||||
apk reverse with jadx|R1
|
||||
js reverse signature|R3
|
||||
case review evidence graph|R40
|
||||
CASES
|
||||
|
||||
if bash skills/scripts/case-init.sh \
|
||||
--hint "offline apk" \
|
||||
--case-name "../case-escape" \
|
||||
--package-root "$scratch/project" \
|
||||
--preset offline-sample \
|
||||
--sample "$scratch/sample.apk"; then
|
||||
echo "case-init accepted an unsafe case name" >&2
|
||||
exit 1
|
||||
fi
|
||||
|
||||
if bash skills/scripts/case-init.sh \
|
||||
--hint "authorized web review" \
|
||||
--case-name "invalid-network" \
|
||||
--package-root "$scratch/project" \
|
||||
--auth-granted \
|
||||
--network-profile "internet" \
|
||||
--target-url "https://example.test/"; then
|
||||
echo "case-init accepted an unsupported network profile" >&2
|
||||
exit 1
|
||||
fi
|
||||
|
||||
bash skills/scripts/case-init.sh \
|
||||
--hint "authorized web review" \
|
||||
--case-name "network-default" \
|
||||
--package-root "$scratch/project" \
|
||||
--auth-granted \
|
||||
--target-url "https://example.test/"
|
||||
grep -Eq '^- mode: authorized_target_only$' "$scratch/project/work/network-default/scope.md"
|
||||
grep -Eq '^- ready_for_act: true$' "$scratch/project/work/network-default/scope.md"
|
||||
bash skills/scripts/case-guard.sh --case-root "$scratch/project/work/network-default"
|
||||
|
||||
bash skills/scripts/case-init.sh \
|
||||
--hint "pending review" \
|
||||
--case-name "guard-section" \
|
||||
--package-root "$scratch/project" \
|
||||
--target-url "https://example.test/"
|
||||
cat >> "$scratch/project/work/guard-section/scope.md" <<'FAKE_FIELDS'
|
||||
|
||||
## notes
|
||||
- status: granted
|
||||
- mode: authorized_target_only
|
||||
- ready_for_act: true
|
||||
FAKE_FIELDS
|
||||
if bash skills/scripts/case-guard.sh --case-root "$scratch/project/work/guard-section"; then
|
||||
echo "case-guard accepted fields outside their contract sections" >&2
|
||||
exit 1
|
||||
fi
|
||||
+73
@@ -0,0 +1,73 @@
|
||||
# Node modules
|
||||
node_modules/
|
||||
|
||||
# Python
|
||||
__pycache__/
|
||||
**/__pycache__/
|
||||
*.pyc
|
||||
*.pyo
|
||||
|
||||
# OS files
|
||||
Thumbs.db
|
||||
.DS_Store
|
||||
Desktop.ini
|
||||
|
||||
# IDE
|
||||
.vscode/
|
||||
.idea/
|
||||
*.swp
|
||||
*.swo
|
||||
*~
|
||||
|
||||
# Temp files
|
||||
*.tmp
|
||||
*.bak
|
||||
*.log
|
||||
|
||||
# User-specific config
|
||||
.claude/
|
||||
# Local Issue/PR review exports; do not commit GitHub discussion snapshots.
|
||||
issues.json
|
||||
issues-index.txt
|
||||
|
||||
# 测试案例（本地）
|
||||
测试案例/
|
||||
测试案例.zip
|
||||
|
||||
# 工具索引（每台机器不同）
|
||||
skills/tool-index.md
|
||||
skills/tool-index.json
|
||||
|
||||
# 编译产物
|
||||
*.exe
|
||||
*.dll
|
||||
*.so
|
||||
*.dylib
|
||||
work/
|
||||
|
||||
# 签名密钥（首次运行自动生成）
|
||||
skills/apk-reverse/debug.keystore
|
||||
*.keystore
|
||||
|
||||
# Build artifacts
|
||||
burp-mcp-full/build/classes/
|
||||
burp-mcp-full/build/libs/
|
||||
burp-mcp-full/lib/
|
||||
burp-mcp-full/.gradle/
|
||||
*.class
|
||||
*.jar
|
||||
!burp-mcp-full/build/libs/burp-mcp-full.jar
|
||||
!burp-mcp-full/gradle/wrapper/gradle-wrapper.jar
|
||||
|
||||
# 已弃用
|
||||
BOOTSTRAP.md
|
||||
|
||||
# 报告（防未脱敏泄漏）
|
||||
reports/
|
||||
|
||||
# 运行产物 / 实验垃圾
|
||||
master-route-*/
|
||||
**/master-route-*/
|
||||
mcps/
|
||||
# local experiment dirs (never ship)
|
||||
*-scope-*/
|
||||
@@ -0,0 +1,46 @@
|
||||
# reverse-skill — 平台无关项目入口
|
||||
|
||||
本仓库是一个**安全任务技能路由包**（逆向工程 / 渗透测试 / 安全分析）。`RULES.md` 是行为链唯一真相源。
|
||||
|
||||
## 路由
|
||||
|
||||
用户任务命中安全/逆向关键词时：
|
||||
|
||||
1. `skills/MASTER-ROUTING.md` 或 `powershell -NoProfile -ExecutionPolicy Bypass -File skills/scripts/master-route.ps1 -Hint "<任务>"` → PRIMARY
|
||||
2. 歧义时读 `skills/routing.md` 全矩阵（三轴：目标类型 / 用户意图 / 工具链）
|
||||
3. 路由规则唯一事实源：`skills/config/routing.json`（改路由只改这里）
|
||||
|
||||
## 授权门禁（硬性）
|
||||
|
||||
- 对任何目标动手前：`powershell -File skills/scripts/case-init.ps1 -Hint "<任务>"` 生成 `work/<case>/scope.md`
|
||||
- `auth.status=granted` + `network_profile` 就绪前**禁止 ACT**
|
||||
- 证据链：`skills/ops/evidence-finding-path.md`；角色：`skills/ops/role-map.md`
|
||||
|
||||
## 首次运行
|
||||
|
||||
`skills/tool-index.md` 是 gitignored 的生成文件，首次使用前运行：
|
||||
|
||||
```powershell
|
||||
powershell -NoProfile -ExecutionPolicy Bypass -File skills/scripts/refresh-tool-index.ps1
|
||||
```
|
||||
|
||||
缺工具 → `skills/scripts/bootstrap-reverse.ps1`（清单能力，禁止猜路径）。
|
||||
|
||||
## 测试（改动后必跑）
|
||||
|
||||
```powershell
|
||||
# 路由回归（162 用例，修改 routing.json 后必跑）
|
||||
powershell -NoProfile -ExecutionPolicy Bypass -File skills/scripts/test-routing.ps1
|
||||
|
||||
# 结构一致性 + 供应链 pin gate
|
||||
powershell -NoProfile -ExecutionPolicy Bypass -File skills/scripts/verify-routing-coherence.ps1
|
||||
|
||||
# 冒烟（verify + 脚本解析 + 快速路由）
|
||||
powershell -NoProfile -ExecutionPolicy Bypass -File skills/scripts/smoke.ps1
|
||||
```
|
||||
|
||||
## 客户端边界
|
||||
|
||||
- 路由核心、测试和工具清单必须与具体 AI 客户端解耦。
|
||||
- Claude Code、Codex、Cursor、OpenCode 等客户端只能通过各自适配层接入，不得成为仓库默认身份或核心配置依赖。
|
||||
- `skills/INDEX.md` 由 `extract-summaries.ps1` 从全部 `SKILL.md` 动态生成，不硬编码客户端或模块数量。
|
||||
+125
@@ -0,0 +1,125 @@
|
||||
# Changelog
|
||||
|
||||
All notable changes to **reverse-skill** are documented in this file.
|
||||
|
||||
Format follows [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
|
||||
Versioning follows [Semantic Versioning](https://semver.org/).
|
||||
|
||||
## [Unreleased]
|
||||
|
||||
## [1.0.1] — 2026-08-08
|
||||
|
||||
### Added
|
||||
|
||||
- **Routing single source of truth** — `skills/config/routing.json` (R0–R39 keyword rules with `must` / `mustAll` / `exclude` semantics). `master-route.ps1` now reads this file; hardcoded routing tables removed from scripts. Routing knowledge lives in one place.
|
||||
- **Routing regression benchmark** — `skills/tests/routing-benchmark.json` (162 bilingual cases, 40 quick) + `skills/scripts/test-routing.ps1` runner. Any routing change must keep the benchmark green.
|
||||
- **Routing keyword coverage expansion** (benchmark-driven): burp suite family, pcap/wireshark, root-detection/certificate-pinning, buffer overflow, `.so`/native/JNI, go binaries (中文), js-encrypt, webshell, privilege escalation, S3/object storage, memory dump, incident response, Bluetooth/BLE, USB, Unity/game reverse, security assessment, and more.
|
||||
- **Supply-chain pin gate** — `verify-routing-coherence.ps1` now fails on any auto-install capability lacking `pinnedVersion` / `pinnedCommit` / `pinPolicy` / asset hash. Pinned: frida-tools 14.10.4, pwntools 4.15.0, agent-browser 0.31.1, ida-pro-mcp @commit, SecLists/ProxyCat @commit, nuclei v3.9.0; winget sources annotated with `winget-latest` policy.
|
||||
- **Client-neutral integration contract** — routing, tests, manifests, and case workflows remain independent of Claude Code, Codex, Cursor, OpenCode, or any other client; client adapters are optional and must not define repository identity.
|
||||
- **Skill navigation index** — `skills/INDEX.md` auto-generated from SKILL.md frontmatter by `extract-summaries.ps1` (`-Check` mode for CI drift detection).
|
||||
- **CI pipeline** — `.github/workflows/ci.yml`: Windows + Ubuntu matrix (PowerShell shim for Linux) running test-routing / verify / smoke / INDEX check / JSON validation, plus `bash -n` syntax checks.
|
||||
- **Example case** — `examples/ctf-demo/` full workflow walkthrough (route → scope gate → timeline → evidence → report).
|
||||
- **frontmatter completion** — `dsl-vm-reverse/SKILL.md` gained name/description frontmatter (was the only module missing it).
|
||||
- **README refresh** — updated the multilingual project overview, release badge, current capabilities, and sponsor showcase layout.
|
||||
|
||||
### Fixed
|
||||
|
||||
- **Upstream mixed-EOL files** — 3 markdown files committed with CRLF while `.gitattributes` declares `*.md eol=lf`; normalized to LF so `git status` stays clean on fresh clones.
|
||||
|
||||
### Security
|
||||
|
||||
- Core scripts do not write client-global instruction files; client-specific integration remains outside the routing core.
|
||||
|
||||
### Fixed
|
||||
|
||||
- Routing: sigma vs malware, LLM 越狱 vs iOS 越狱, 完整渗透/打到域控 vs AD 域控, forensics vs OT ics; master-route.ps1 rewritten UTF-8 BOM for PS 5.1 CJK
|
||||
- Linux/macOS bootstrap: register PentestSwarm MCP with a verified executable path after Go install or when already installed
|
||||
|
||||
### Security
|
||||
|
||||
- Added `docs/PACKAGE-SECURITY-AUDIT.md`: static audit of package executables (no backdoor / no auto DB wipe found)
|
||||
- Pin supply-chain floating tags: jshook `@0.3.4`, pentestswarm `v0.1.0`
|
||||
- Bootstrap integrity: GitHub zip/jar downloads verify `assetSha256` (manifest) or GitHub API `digest`; mismatch deletes file and fails
|
||||
- Pin jadx `v1.5.6` and apktool `v3.0.2` with published SHA256
|
||||
- Remove shell evaluation from Kali user-home resolution and pass Frida hosts through argument arrays
|
||||
- Write the Burp MCP token atomically with owner-only permissions on POSIX filesystems
|
||||
- Reconnect the Burp MCP bridge when Burp starts after the bridge and parse one stdio message per line
|
||||
- Enable authentication for bootstrapped Anything Analyzer MCP servers and register the bearer token with supported clients
|
||||
- Stop each stale IDA MCP process individually before starting a replacement
|
||||
- Add Bash case initialization, authorization guard, and a structured router that reads the same `routing.json` as PowerShell
|
||||
- Verify Bash routing parity in CI without introducing a client-specific plugin manifest
|
||||
- Enforce immutable Kali/Windows bootstrap sources for Frida, IDA MCP, Agent Browser, ProxyCat, Nuclei, and pwntools
|
||||
- Reject path-like Bash case names and scope authorization checks to the contract's auth/network/signoff sections
|
||||
- Align Bash network defaults with PowerShell: authorized URLs use `authorized_target_only`, while offline readiness requires an explicit local sample
|
||||
- Pin GitHub Actions checkout to the immutable v4.2.2 commit and keep the CI case count synchronized
|
||||
- Create a functional Kali `proxycat` wrapper after installing the pinned source checkout
|
||||
- Scope PowerShell authorization fields to their contract sections and reject unsupported network modes in both guards
|
||||
- Reject unsupported network profiles during case initialization so invalid scopes are never emitted as ready
|
||||
- Generate `skills/INDEX.md` from tracked skills only, excluding ignored local modules so clean-clone CI stays reproducible
|
||||
- Fail routing coherence when a configured skill is missing or only exists as an untracked local file
|
||||
|
||||
|
||||
### Added
|
||||
|
||||
- `case-review/`: read-only Evidence Graph Review with scope, timeline, work item, Finding, Path, and optional SHA-256 fixity checks
|
||||
- Domain skills R21–R27, R29–R30: `protocol-reverse`, `ghidra-reverse`, `cloud-k8s`, `windows-ad`, `digital-forensics`, `code-audit`, `threat-hunting`, `wifi-wireless`, `browser-extension-reverse`
|
||||
- High-quality skills R28, R31–R38: `ot-ics`, `macos-reverse`, `thick-client`, `go-rust-reverse`, `hardware-security`, `database-security`, `email-security`, `identity-federation`, `radio-sdr`
|
||||
- Wired into `MASTER-ROUTING.md`, `master-route.ps1`, routing tables, domain map, role-map, coherence tests
|
||||
|
||||
### Removed
|
||||
|
||||
- `game-reverse/` (not a product focus; Unity/IL2CPP remains via `reverse-engineering` + seed-014)
|
||||
|
||||
## [1.0.0] — 2026-07-18
|
||||
|
||||
First **formal** public release of the reverse-skill skill-router pack.
|
||||
|
||||
### Added
|
||||
|
||||
#### Ops / combat contract layer (`skills/ops/`)
|
||||
|
||||
- `IDENTITY.md` — product identity: lightweight skill router + bootstrap + field-journal (not a Z3r0-style platform)
|
||||
- `scope-contract.md` — case scope + `network_profile`; **auth not granted → no ACT on target**
|
||||
- `evidence-finding-path.md` — Evidence → Finding → Path chain
|
||||
- `role-map.md` — lead / specialist role mapping and handoff
|
||||
- `timeline-workitem.md` — timeline + workitem coverage
|
||||
- `sandbox-profile.md` — tool profile mapping
|
||||
- `skill-supply-chain.md` — Agent Skill / MCP install gate (AST10-lite)
|
||||
|
||||
#### PRIMARY routing & case tooling (`skills/scripts/`)
|
||||
|
||||
- `master-route.ps1` — PRIMARY route from task hint
|
||||
- `case-init.ps1` / `case-guard.ps1` — case bootstrap + scope guard
|
||||
- `append-evidence.ps1` — structured evidence append
|
||||
- `smoke.ps1` — package smoke checks
|
||||
- `verify-routing-coherence.ps1` — routing / ops coherence verification
|
||||
- `test-p0-friction.ps1` — P0 client-side lab friction regression tests
|
||||
|
||||
#### Core skills & docs
|
||||
|
||||
- Full skill matrix: APK / IDA / radare2 / JS / .NET / mobile / malware / pwn / firmware / EDR / pentest / API / LLM / supply-chain / crypto / binary-diff / patch-diff / attack-chain / docs & diagrams
|
||||
- `MASTER-ROUTING.md` + `routing.md` / `routing_zh.md` three-axis matrix
|
||||
- Bootstrap + tool-index pipeline (`bootstrap-reverse.ps1` / `.sh`, `refresh-tool-index`)
|
||||
- `field-journal` precedent library + completion checklist
|
||||
- Multi-platform paths: Windows primary, Linux / macOS / Kali docs and scripts
|
||||
- CTF-Sandbox-Orchestrator competition sub-skills
|
||||
- Burp MCP extension package (`burp-mcp-full/`)
|
||||
|
||||
#### Quality / localization
|
||||
|
||||
- UTF-8 integrity for Chinese docs (`RULES_zh`, `routing_zh`, related guides)
|
||||
- Client-side lab playbook and recon pipeline references for authorized testing friction reduction
|
||||
|
||||
### Notes
|
||||
|
||||
- `skills/tool-index.md` / `tool-index.json` are **machine-local** and intentionally gitignored; generate via `refresh-tool-index` after clone.
|
||||
- This tag freezes the skill-router product surface at commit `9fc280b` plus this release metadata.
|
||||
|
||||
### Links
|
||||
|
||||
- Tag: `v1.0.0`
|
||||
- Repository: https://github.com/zhaoxuya520/reverse-skill
|
||||
|
||||
[Unreleased]: https://github.com/zhaoxuya520/reverse-skill/compare/v1.0.1...HEAD
|
||||
[1.0.1]: https://github.com/zhaoxuya520/reverse-skill/compare/v1.0.0...v1.0.1
|
||||
[1.0.0]: https://github.com/zhaoxuya520/reverse-skill/releases/tag/v1.0.0
|
||||
@@ -0,0 +1,42 @@
|
||||
# CLAUDE.md
|
||||
|
||||
This repository is a **task skill router** for authorized reverse engineering, mobile/security analysis, and pentest workflows.
|
||||
|
||||
## On Any Task
|
||||
|
||||
`RULES.md` is the single source of truth for behavior chain and authorization.
|
||||
|
||||
Routing order:
|
||||
|
||||
1. `skills/MASTER-ROUTING.md` or `skills/scripts/master-route.ps1 -Hint "..."`
|
||||
2. `skills/scripts/case-init.ps1` → current analysis project's `work/<case>/scope.md` (must grant auth before ACT)
|
||||
3. `skills/routing.md` when ambiguous; roles in `skills/ops/role-map.md`
|
||||
4. Open PRIMARY `SKILL.md` and execute ACTION REQUIRED
|
||||
5. Timeline/workitems + Evidence→Finding→Path (`skills/ops/`)
|
||||
6. `skills/tool-index.md` for real tool paths (never guess)
|
||||
7. Missing tool → `skills/scripts/bootstrap-reverse.ps1` (manifest capabilities only)
|
||||
|
||||
**Identity**: lightweight skill router — see `skills/ops/IDENTITY.md` (not a Z3r0 platform).
|
||||
|
||||
## First-Run Setup
|
||||
|
||||
`skills/tool-index.md` is not in fresh clones. Generate it:
|
||||
|
||||
```bash
|
||||
# Windows
|
||||
powershell -NoProfile -ExecutionPolicy Bypass -File skills/scripts/refresh-tool-index.ps1
|
||||
|
||||
# macOS / Linux
|
||||
bash skills/scripts/refresh-tool-index.sh
|
||||
|
||||
# Kali
|
||||
bash kali/scripts/refresh-tool-index.sh
|
||||
```
|
||||
|
||||
Read `README_AI.md` for full bootstrap sequence.
|
||||
|
||||
## Coherence check
|
||||
|
||||
```powershell
|
||||
powershell -NoProfile -ExecutionPolicy Bypass -File skills/scripts/verify-routing-coherence.ps1
|
||||
```
|
||||
@@ -0,0 +1,674 @@
|
||||
GNU GENERAL PUBLIC LICENSE
|
||||
Version 3, 29 June 2007
|
||||
|
||||
Copyright (C) 2007 Free Software Foundation, Inc. <https://fsf.org/>
|
||||
Everyone is permitted to copy and distribute verbatim copies
|
||||
of this license document, but changing it is not allowed.
|
||||
|
||||
Preamble
|
||||
|
||||
The GNU General Public License is a free, copyleft license for
|
||||
software and other kinds of works.
|
||||
|
||||
The licenses for most software and other practical works are designed
|
||||
to take away your freedom to share and change the works. By contrast,
|
||||
the GNU General Public License is intended to guarantee your freedom to
|
||||
share and change all versions of a program--to make sure it remains free
|
||||
software for all its users. We, the Free Software Foundation, use the
|
||||
GNU General Public License for most of our software; it applies also to
|
||||
any other work released this way by its authors. You can apply it to
|
||||
your programs, too.
|
||||
|
||||
When we speak of free software, we are referring to freedom, not
|
||||
price. Our General Public Licenses are designed to make sure that you
|
||||
have the freedom to distribute copies of free software (and charge for
|
||||
them if you wish), that you receive source code or can get it if you
|
||||
want it, that you can change the software or use pieces of it in new
|
||||
free programs, and that you know you can do these things.
|
||||
|
||||
To protect your rights, we need to prevent others from denying you
|
||||
these rights or asking you to surrender the rights. Therefore, you have
|
||||
certain responsibilities if you distribute copies of the software, or if
|
||||
you modify it: responsibilities to respect the freedom of others.
|
||||
|
||||
For example, if you distribute copies of such a program, whether
|
||||
gratis or for a fee, you must pass on to the recipients the same
|
||||
freedoms that you received. You must make sure that they, too, receive
|
||||
or can get the source code. And you must show them these terms so they
|
||||
know their rights.
|
||||
|
||||
Developers that use the GNU GPL protect your rights with two steps:
|
||||
(1) assert copyright on the software, and (2) offer you this License
|
||||
giving you legal permission to copy, distribute and/or modify it.
|
||||
|
||||
For the developers' and authors' protection, the GPL clearly explains
|
||||
that there is no warranty for this free software. For both users' and
|
||||
authors' sake, the GPL requires that modified versions be marked as
|
||||
changed, so that their problems will not be attributed erroneously to
|
||||
authors of previous versions.
|
||||
|
||||
Some devices are designed to deny users access to install or run
|
||||
modified versions of the software inside them, although the manufacturer
|
||||
can do so. This is fundamentally incompatible with the aim of
|
||||
protecting users' freedom to change the software. The systematic
|
||||
pattern of such abuse occurs in the area of products for individuals to
|
||||
use, which is precisely where it is most unacceptable. Therefore, we
|
||||
have designed this version of the GPL to prohibit the practice for those
|
||||
products. If such problems arise substantially in other domains, we
|
||||
stand ready to extend this provision to those domains in future versions
|
||||
of the GPL, as needed to protect the freedom of users.
|
||||
|
||||
Finally, every program is threatened constantly by software patents.
|
||||
States should not allow patents to restrict development and use of
|
||||
software on general-purpose computers, but in those that do, we wish to
|
||||
avoid the special danger that patents applied to a free program could
|
||||
make it effectively proprietary. To prevent this, the GPL assures that
|
||||
patents cannot be used to render the program non-free.
|
||||
|
||||
The precise terms and conditions for copying, distribution and
|
||||
modification follow.
|
||||
|
||||
TERMS AND CONDITIONS
|
||||
|
||||
0. Definitions.
|
||||
|
||||
"This License" refers to version 3 of the GNU General Public License.
|
||||
|
||||
"Copyright" also means copyright-like laws that apply to other kinds of
|
||||
works, such as semiconductor masks.
|
||||
|
||||
"The Program" refers to any copyrightable work licensed under this
|
||||
License. Each licensee is addressed as "you". "Licensees" and
|
||||
"recipients" may be individuals or organizations.
|
||||
|
||||
To "modify" a work means to copy from or adapt all or part of the work
|
||||
in a fashion requiring copyright permission, other than the making of an
|
||||
exact copy. The resulting work is called a "modified version" of the
|
||||
earlier work or a work "based on" the earlier work.
|
||||
|
||||
A "covered work" means either the unmodified Program or a work based
|
||||
on the Program.
|
||||
|
||||
To "propagate" a work means to do anything with it that, without
|
||||
permission, would make you directly or secondarily liable for
|
||||
infringement under applicable copyright law, except executing it on a
|
||||
computer or modifying a private copy. Propagation includes copying,
|
||||
distribution (with or without modification), making available to the
|
||||
public, and in some countries other activities as well.
|
||||
|
||||
To "convey" a work means any kind of propagation that enables other
|
||||
parties to make or receive copies. Mere interaction with a user through
|
||||
a computer network, with no transfer of a copy, is not conveying.
|
||||
|
||||
An interactive user interface displays "Appropriate Legal Notices"
|
||||
to the extent that it includes a convenient and prominently visible
|
||||
feature that (1) displays an appropriate copyright notice, and (2)
|
||||
tells the user that there is no warranty for the work (except to the
|
||||
extent that warranties are provided), that licensees may convey the
|
||||
work under this License, and how to view a copy of this License. If
|
||||
the interface presents a list of user commands or options, such as a
|
||||
menu, a prominent item in the list meets this criterion.
|
||||
|
||||
1. Source Code.
|
||||
|
||||
The "source code" for a work means the preferred form of the work
|
||||
for making modifications to it. "Object code" means any non-source
|
||||
form of a work.
|
||||
|
||||
A "Standard Interface" means an interface that either is an official
|
||||
standard defined by a recognized standards body, or, in the case of
|
||||
interfaces specified for a particular programming language, one that
|
||||
is widely used among developers working in that language.
|
||||
|
||||
The "System Libraries" of an executable work include anything, other
|
||||
than the work as a whole, that (a) is included in the normal form of
|
||||
packaging a Major Component, but which is not part of that Major
|
||||
Component, and (b) serves only to enable use of the work with that
|
||||
Major Component, or to implement a Standard Interface for which an
|
||||
implementation is available to the public in source code form. A
|
||||
"Major Component", in this context, means a major essential component
|
||||
(kernel, window system, and so on) of the specific operating system
|
||||
(if any) on which the executable work runs, or a compiler used to
|
||||
produce the work, or an object code interpreter used to run it.
|
||||
|
||||
The "Corresponding Source" for a work in object code form means all
|
||||
the source code needed to generate, install, and (for an executable
|
||||
work) run the object code and to modify the work, including scripts to
|
||||
control those activities. However, it does not include the work's
|
||||
System Libraries, or general-purpose tools or generally available free
|
||||
programs which are used unmodified in performing those activities but
|
||||
which are not part of the work. For example, Corresponding Source
|
||||
includes interface definition files associated with source files for
|
||||
the work, and the source code for shared libraries and dynamically
|
||||
linked subprograms that the work is specifically designed to require,
|
||||
such as by intimate data communication or control flow between those
|
||||
subprograms and other parts of the work.
|
||||
|
||||
The Corresponding Source need not include anything that users
|
||||
can regenerate automatically from other parts of the Corresponding
|
||||
Source.
|
||||
|
||||
The Corresponding Source for a work in source code form is that
|
||||
same work.
|
||||
|
||||
2. Basic Permissions.
|
||||
|
||||
All rights granted under this License are granted for the term of
|
||||
copyright on the Program, and are irrevocable provided the stated
|
||||
conditions are met. This License explicitly affirms your unlimited
|
||||
permission to run the unmodified Program. The output from running a
|
||||
covered work is covered by this License only if the output, given its
|
||||
content, constitutes a covered work. This License acknowledges your
|
||||
rights of fair use or other equivalent, as provided by copyright law.
|
||||
|
||||
You may make, run and propagate covered works that you do not
|
||||
convey, without conditions so long as your license otherwise remains
|
||||
in force. You may convey covered works to others for the sole purpose
|
||||
of having them make modifications exclusively for you, or provide you
|
||||
with facilities for running those works, provided that you comply with
|
||||
the terms of this License in conveying all material for which you do
|
||||
not control copyright. Those thus making or running the covered works
|
||||
for you must do so exclusively on your behalf, under your direction
|
||||
and control, on terms that prohibit them from making any copies of
|
||||
your copyrighted material outside their relationship with you.
|
||||
|
||||
Conveying under any other circumstances is permitted solely under
|
||||
the conditions stated below. Sublicensing is not allowed; section 10
|
||||
makes it unnecessary.
|
||||
|
||||
3. Protecting Users' Legal Rights From Anti-Circumvention Law.
|
||||
|
||||
No covered work shall be deemed part of an effective technological
|
||||
measure under any applicable law fulfilling obligations under article
|
||||
11 of the WIPO copyright treaty adopted on 20 December 1996, or
|
||||
similar laws prohibiting or restricting circumvention of such
|
||||
measures.
|
||||
|
||||
When you convey a covered work, you waive any legal power to forbid
|
||||
circumvention of technological measures to the extent such circumvention
|
||||
is effected by exercising rights under this License with respect to
|
||||
the covered work, and you disclaim any intention to limit operation or
|
||||
modification of the work as a means of enforcing, against the work's
|
||||
users, your or third parties' legal rights to forbid circumvention of
|
||||
technological measures.
|
||||
|
||||
4. Conveying Verbatim Copies.
|
||||
|
||||
You may convey verbatim copies of the Program's source code as you
|
||||
receive it, in any medium, provided that you conspicuously and
|
||||
appropriately publish on each copy an appropriate copyright notice;
|
||||
keep intact all notices stating that this License and any
|
||||
non-permissive terms added in accord with section 7 apply to the code;
|
||||
keep intact all notices of the absence of any warranty; and give all
|
||||
recipients a copy of this License along with the Program.
|
||||
|
||||
You may charge any price or no price for each copy that you convey,
|
||||
and you may offer support or warranty protection for a fee.
|
||||
|
||||
5. Conveying Modified Source Versions.
|
||||
|
||||
You may convey a work based on the Program, or the modifications to
|
||||
produce it from the Program, in the form of source code under the
|
||||
terms of section 4, provided that you also meet all of these conditions:
|
||||
|
||||
a) The work must carry prominent notices stating that you modified
|
||||
it, and giving a relevant date.
|
||||
|
||||
b) The work must carry prominent notices stating that it is
|
||||
released under this License and any conditions added under section
|
||||
7. This requirement modifies the requirement in section 4 to
|
||||
"keep intact all notices".
|
||||
|
||||
c) You must license the entire work, as a whole, under this
|
||||
License to anyone who comes into possession of a copy. This
|
||||
License will therefore apply, along with any applicable section 7
|
||||
additional terms, to the whole of the work, and all its parts,
|
||||
regardless of how they are packaged. This License gives no
|
||||
permission to license the work in any other way, but it does not
|
||||
invalidate such permission if you have separately received it.
|
||||
|
||||
d) If the work has interactive user interfaces, each must display
|
||||
Appropriate Legal Notices; however, if the Program has interactive
|
||||
interfaces that do not display Appropriate Legal Notices, your
|
||||
work need not make them do so.
|
||||
|
||||
A compilation of a covered work with other separate and independent
|
||||
works, which are not by their nature extensions of the covered work,
|
||||
and which are not combined with it such as to form a larger program,
|
||||
in or on a volume of a storage or distribution medium, is called an
|
||||
"aggregate" if the compilation and its resulting copyright are not
|
||||
used to limit the access or legal rights of the compilation's users
|
||||
beyond what the individual works permit. Inclusion of a covered work
|
||||
in an aggregate does not cause this License to apply to the other
|
||||
parts of the aggregate.
|
||||
|
||||
6. Conveying Non-Source Forms.
|
||||
|
||||
You may convey a covered work in object code form under the terms
|
||||
of sections 4 and 5, provided that you also convey the
|
||||
machine-readable Corresponding Source under the terms of this License,
|
||||
in one of these ways:
|
||||
|
||||
a) Convey the object code in, or embodied in, a physical product
|
||||
(including a physical distribution medium), accompanied by the
|
||||
Corresponding Source fixed on a durable physical medium
|
||||
customarily used for software interchange.
|
||||
|
||||
b) Convey the object code in, or embodied in, a physical product
|
||||
(including a physical distribution medium), accompanied by a
|
||||
written offer, valid for at least three years and valid for as
|
||||
long as you offer spare parts or customer support for that product
|
||||
model, to give anyone who possesses the object code either (1) a
|
||||
copy of the Corresponding Source for all the software in the
|
||||
product that is covered by this License, on a durable physical
|
||||
medium customarily used for software interchange, for a price no
|
||||
more than your reasonable cost of physically performing this
|
||||
conveying of source, or (2) access to copy the
|
||||
Corresponding Source from a network server at no charge.
|
||||
|
||||
c) Convey individual copies of the object code with a copy of the
|
||||
written offer to provide the Corresponding Source. This
|
||||
alternative is allowed only occasionally and noncommercially, and
|
||||
only if you received the object code with such an offer, in accord
|
||||
with subsection 6b.
|
||||
|
||||
d) Convey the object code by offering access from a designated
|
||||
place (gratis or for a charge), and offer equivalent access to the
|
||||
Corresponding Source in the same way through the same place at no
|
||||
further charge. You need not require recipients to copy the
|
||||
Corresponding Source along with the object code. If the place to
|
||||
copy the object code is a network server, the Corresponding Source
|
||||
may be on a different server (operated by you or a third party)
|
||||
that supports equivalent copying facilities, provided you maintain
|
||||
clear directions next to the object code saying where to find the
|
||||
Corresponding Source. Regardless of what server hosts the
|
||||
Corresponding Source, you remain obligated to ensure that it is
|
||||
available for as long as needed to satisfy these requirements.
|
||||
|
||||
e) Convey the object code using peer-to-peer transmission, provided
|
||||
you inform other peers where the object code and Corresponding
|
||||
Source of the work are being offered to the general public at no
|
||||
charge under subsection 6d.
|
||||
|
||||
A separable portion of the object code, whose source code is excluded
|
||||
from the Corresponding Source as a System Library, need not be
|
||||
included in conveying the object code work.
|
||||
|
||||
A "User Product" is either (1) a "consumer product", which means any
|
||||
tangible personal property which is normally used for personal, family,
|
||||
or household purposes, or (2) anything designed or sold for incorporation
|
||||
into a dwelling. In determining whether a product is a consumer product,
|
||||
doubtful cases shall be resolved in favor of coverage. For a particular
|
||||
product received by a particular user, "normally used" refers to a
|
||||
typical or common use of that class of product, regardless of the status
|
||||
of the particular user or of the way in which the particular user
|
||||
actually uses, or expects or is expected to use, the product. A product
|
||||
is a consumer product regardless of whether the product has substantial
|
||||
commercial, industrial or non-consumer uses, unless such uses represent
|
||||
the only significant mode of use of the product.
|
||||
|
||||
"Installation Information" for a User Product means any methods,
|
||||
procedures, authorization keys, or other information required to install
|
||||
and execute modified versions of a covered work in that User Product from
|
||||
a modified version of its Corresponding Source. The information must
|
||||
suffice to ensure that the continued functioning of the modified object
|
||||
code is in no case prevented or interfered with solely because
|
||||
modification has been made.
|
||||
|
||||
If you convey an object code work under this section in, or with, or
|
||||
specifically for use in, a User Product, and the conveying occurs as
|
||||
part of a transaction in which the right of possession and use of the
|
||||
User Product is transferred to the recipient in perpetuity or for a
|
||||
fixed term (regardless of how the transaction is characterized), the
|
||||
Corresponding Source conveyed under this section must be accompanied
|
||||
by the Installation Information. But this requirement does not apply
|
||||
if neither you nor any third party retains the ability to install
|
||||
modified object code on the User Product (for example, the work has
|
||||
been installed in ROM).
|
||||
|
||||
The requirement to provide Installation Information does not include a
|
||||
requirement to continue to provide support service, warranty, or updates
|
||||
for a work that has been modified or installed by the recipient, or for
|
||||
the User Product in which it has been modified or installed. Access to a
|
||||
network may be denied when the modification itself materially and
|
||||
adversely affects the operation of the network or violates the rules and
|
||||
protocols for communication across the network.
|
||||
|
||||
Corresponding Source conveyed, and Installation Information provided,
|
||||
in accord with this section must be in a format that is publicly
|
||||
documented (and with an implementation available to the public in
|
||||
source code form), and must require no special password or key for
|
||||
unpacking, reading or copying.
|
||||
|
||||
7. Additional Terms.
|
||||
|
||||
"Additional permissions" are terms that supplement the terms of this
|
||||
License by making exceptions from one or more of its conditions.
|
||||
Additional permissions that are applicable to the entire Program shall
|
||||
be treated as though they were included in this License, to the extent
|
||||
that they are valid under applicable law. If additional permissions
|
||||
apply only to part of the Program, that part may be used separately
|
||||
under those permissions, but the entire Program remains governed by
|
||||
this License without regard to the additional permissions.
|
||||
|
||||
When you convey a copy of a covered work, you may at your option
|
||||
remove any additional permissions from that copy, or from any part of
|
||||
it. (Additional permissions may be written to require their own
|
||||
removal in certain cases when you modify the work.) You may place
|
||||
additional permissions on material, added by you to a covered work,
|
||||
for which you have or can give appropriate copyright permission.
|
||||
|
||||
Notwithstanding any other provision of this License, for material you
|
||||
add to a covered work, you may (if authorized by the copyright holders of
|
||||
that material) supplement the terms of this License with terms:
|
||||
|
||||
a) Disclaiming warranty or limiting liability differently from the
|
||||
terms of sections 15 and 16 of this License; or
|
||||
|
||||
b) Requiring preservation of specified reasonable legal notices or
|
||||
author attributions in that material or in the Appropriate Legal
|
||||
Notices displayed by works containing it; or
|
||||
|
||||
c) Prohibiting misrepresentation of the origin of that material, or
|
||||
requiring that modified versions of such material be marked in
|
||||
reasonable ways as different from the original version; or
|
||||
|
||||
d) Limiting the use for publicity purposes of names of licensors or
|
||||
authors of the material; or
|
||||
|
||||
e) Declining to grant rights under trademark law for use of some
|
||||
trade names, trademarks, or service marks; or
|
||||
|
||||
f) Requiring indemnification of licensors and authors of that
|
||||
material by anyone who conveys the material (or modified versions of
|
||||
it) with contractual assumptions of liability to the recipient, for
|
||||
any liability that these contractual assumptions directly impose on
|
||||
those licensors and authors.
|
||||
|
||||
All other non-permissive additional terms are considered "further
|
||||
restrictions" within the meaning of section 10. If the Program as you
|
||||
received it, or any part of it, contains a notice stating that it is
|
||||
governed by this License along with a term that is a further
|
||||
restriction, you may remove that term. If a license document contains
|
||||
a further restriction but permits relicensing or conveying under this
|
||||
License, you may add to a covered work material governed by the terms
|
||||
of that license document, provided that the further restriction does
|
||||
not survive such relicensing or conveying.
|
||||
|
||||
If you add terms to a covered work in accord with this section, you
|
||||
must place, in the relevant source files, a statement of the
|
||||
additional terms that apply to those files, or a notice indicating
|
||||
where to find the applicable terms.
|
||||
|
||||
Additional terms, permissive or non-permissive, may be stated in the
|
||||
form of a separately written license, or stated as exceptions;
|
||||
the above requirements apply either way.
|
||||
|
||||
8. Termination.
|
||||
|
||||
You may not propagate or modify a covered work except as expressly
|
||||
provided under this License. Any attempt otherwise to propagate or
|
||||
modify it is void, and will automatically terminate your rights under
|
||||
this License (including any patent licenses granted under the third
|
||||
paragraph of section 11).
|
||||
|
||||
However, if you cease all violation of this License, then your
|
||||
license from a particular copyright holder is reinstated (a)
|
||||
provisionally, unless and until the copyright holder explicitly and
|
||||
finally terminates your license, and (b) permanently, if the copyright
|
||||
holder fails to notify you of the violation by some reasonable means
|
||||
prior to 60 days after the cessation.
|
||||
|
||||
Moreover, your license from a particular copyright holder is
|
||||
reinstated permanently if the copyright holder notifies you of the
|
||||
violation by some reasonable means, this is the first time you have
|
||||
received notice of violation of this License (for any work) from that
|
||||
copyright holder, and you cure the violation prior to 30 days after
|
||||
your receipt of the notice.
|
||||
|
||||
Termination of your rights under this section does not terminate the
|
||||
licenses of parties who have received copies or rights from you under
|
||||
this License. If your rights have been terminated and not permanently
|
||||
reinstated, you do not qualify to receive new licenses for the same
|
||||
material under section 10.
|
||||
|
||||
9. Acceptance Not Required for Having Copies.
|
||||
|
||||
You are not required to accept this License in order to receive or
|
||||
run a copy of the Program. Ancillary propagation of a covered work
|
||||
occurring solely as a consequence of using peer-to-peer transmission
|
||||
to receive a copy likewise does not require acceptance. However,
|
||||
nothing other than this License grants you permission to propagate or
|
||||
modify any covered work. These actions infringe copyright if you do
|
||||
not accept this License. Therefore, by modifying or propagating a
|
||||
covered work, you indicate your acceptance of this License to do so.
|
||||
|
||||
10. Automatic Licensing of Downstream Recipients.
|
||||
|
||||
Each time you convey a covered work, the recipient automatically
|
||||
receives a license from the original licensors, to run, modify and
|
||||
propagate that work, subject to this License. You are not responsible
|
||||
for enforcing compliance by third parties with this License.
|
||||
|
||||
An "entity transaction" is a transaction transferring control of an
|
||||
organization, or substantially all assets of one, or subdividing an
|
||||
organization, or merging organizations. If propagation of a covered
|
||||
work results from an entity transaction, each party to that
|
||||
transaction who receives a copy of the work also receives whatever
|
||||
licenses to the work the party's predecessor in interest had or could
|
||||
give under the previous paragraph, plus a right to possession of the
|
||||
Corresponding Source of the work from the predecessor in interest, if
|
||||
the predecessor has it or can get it with reasonable efforts.
|
||||
|
||||
You may not impose any further restrictions on the exercise of the
|
||||
rights granted or affirmed under this License. For example, you may
|
||||
not impose a license fee, royalty, or other charge for exercise of
|
||||
rights granted under this License, and you may not initiate litigation
|
||||
(including a cross-claim or counterclaim in a lawsuit) alleging that
|
||||
any patent claim is infringed by making, using, selling, offering for
|
||||
sale, or importing the Program or any portion of it.
|
||||
|
||||
11. Patents.
|
||||
|
||||
A "contributor" is a copyright holder who authorizes use under this
|
||||
License of the Program or a work on which the Program is based. The
|
||||
work thus licensed is called the contributor's "contributor version".
|
||||
|
||||
A contributor's "essential patent claims" are all patent claims
|
||||
owned or controlled by the contributor, whether already acquired or
|
||||
hereafter acquired, that would be infringed by some manner, permitted
|
||||
by this License, of making, using, or selling its contributor version,
|
||||
but do not include claims that would be infringed only as a
|
||||
consequence of further modification of the contributor version. For
|
||||
purposes of this definition, "control" includes the right to grant
|
||||
patent sublicenses in a manner consistent with the requirements of
|
||||
this License.
|
||||
|
||||
Each contributor grants you a non-exclusive, worldwide, royalty-free
|
||||
patent license under the contributor's essential patent claims, to
|
||||
make, use, sell, offer for sale, import and otherwise run, modify and
|
||||
propagate the contents of its contributor version.
|
||||
|
||||
In the following three paragraphs, a "patent license" is any express
|
||||
agreement or commitment, however denominated, not to enforce a patent
|
||||
(such as an express permission to practice a patent or covenant not to
|
||||
sue for patent infringement). To "grant" such a patent license to a
|
||||
party means to make such an agreement or commitment not to enforce a
|
||||
patent against the party.
|
||||
|
||||
If you convey a covered work, knowingly relying on a patent license,
|
||||
and the Corresponding Source of the work is not available for anyone
|
||||
to copy, free of charge and under the terms of this License, through a
|
||||
publicly available network server or other readily accessible means,
|
||||
then you must either (1) cause the Corresponding Source to be so
|
||||
available, or (2) arrange to deprive yourself of the benefit of the
|
||||
patent license for this particular work, or (3) arrange, in a manner
|
||||
consistent with the requirements of this License, to extend the patent
|
||||
license to downstream recipients. "Knowingly relying" means you have
|
||||
actual knowledge that, but for the patent license, your conveying the
|
||||
covered work in a country, or your recipient's use of the covered work
|
||||
in a country, would infringe one or more identifiable patents in that
|
||||
country that you have reason to believe are valid.
|
||||
|
||||
If, pursuant to or in connection with a single transaction or
|
||||
arrangement, you convey, or propagate by procuring conveyance of, a
|
||||
covered work, and grant a patent license to some of the parties
|
||||
receiving the covered work authorizing them to use, propagate, modify
|
||||
or convey a specific copy of the covered work, then the patent license
|
||||
you grant is automatically extended to all recipients of the covered
|
||||
work and works based on it.
|
||||
|
||||
A patent license is "discriminatory" if it does not include within
|
||||
the scope of its coverage, prohibits the exercise of, or is
|
||||
conditioned on the non-exercise of one or more of the rights that are
|
||||
specifically granted under this License. You may not convey a covered
|
||||
work if you are a party to an arrangement with a third party that is
|
||||
in the business of distributing software, under which you make payment
|
||||
to the third party based on the extent of your activity of conveying
|
||||
the work, and under which the third party grants, to any of the
|
||||
parties who would receive the covered work from you, a discriminatory
|
||||
patent license (a) in connection with copies of the covered work
|
||||
conveyed by you (or copies made from those copies), or (b) primarily
|
||||
for and in connection with specific products or compilations that
|
||||
contain the covered work, unless you entered into that arrangement,
|
||||
or that patent license was granted, prior to 28 March 2007.
|
||||
|
||||
Nothing in this License shall be construed as excluding or limiting
|
||||
any implied license or other defenses to infringement that may
|
||||
otherwise be available to you under applicable patent law.
|
||||
|
||||
12. No Surrender of Others' Freedom.
|
||||
|
||||
If conditions are imposed on you (whether by court order, agreement or
|
||||
otherwise) that contradict the conditions of this License, they do not
|
||||
excuse you from the conditions of this License. If you cannot convey a
|
||||
covered work so as to satisfy simultaneously your obligations under this
|
||||
License and any other pertinent obligations, then as a consequence you may
|
||||
not convey it at all. For example, if you agree to terms that obligate you
|
||||
to collect a royalty for further conveying from those to whom you convey
|
||||
the Program, the only way you could satisfy both those terms and this
|
||||
License would be to refrain entirely from conveying the Program.
|
||||
|
||||
13. Use with the GNU Affero General Public License.
|
||||
|
||||
Notwithstanding any other provision of this License, you have
|
||||
permission to link or combine any covered work with a work licensed
|
||||
under version 3 of the GNU Affero General Public License into a single
|
||||
combined work, and to convey the resulting work. The terms of this
|
||||
License will continue to apply to the part which is the covered work,
|
||||
but the special requirements of the GNU Affero General Public License,
|
||||
section 13, concerning interaction through a network will apply to the
|
||||
combination as such.
|
||||
|
||||
14. Revised Versions of this License.
|
||||
|
||||
The Free Software Foundation may publish revised and/or new versions of
|
||||
the GNU General Public License from time to time. Such new versions will
|
||||
be similar in spirit to the present version, but may differ in detail to
|
||||
address new problems or concerns.
|
||||
|
||||
Each version is given a distinguishing version number. If the
|
||||
Program specifies that a certain numbered version of the GNU General
|
||||
Public License "or any later version" applies to it, you have the
|
||||
option of following the terms and conditions either of that numbered
|
||||
version or of any later version published by the Free Software
|
||||
Foundation. If the Program does not specify a version number of the
|
||||
GNU General Public License, you may choose any version ever published
|
||||
by the Free Software Foundation.
|
||||
|
||||
If the Program specifies that a proxy can decide which future
|
||||
versions of the GNU General Public License can be used, that proxy's
|
||||
public statement of acceptance of a version permanently authorizes you
|
||||
to choose that version for the Program.
|
||||
|
||||
Later license versions may give you additional or different
|
||||
permissions. However, no additional obligations are imposed on any
|
||||
author or copyright holder as a result of your choosing to follow a
|
||||
later version.
|
||||
|
||||
15. Disclaimer of Warranty.
|
||||
|
||||
THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
|
||||
APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
|
||||
HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY
|
||||
OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO,
|
||||
THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
|
||||
PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM
|
||||
IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF
|
||||
ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
|
||||
|
||||
16. Limitation of Liability.
|
||||
|
||||
IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
|
||||
WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS
|
||||
THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY
|
||||
GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE
|
||||
USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF
|
||||
DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD
|
||||
PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS),
|
||||
EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF
|
||||
SUCH DAMAGES.
|
||||
|
||||
17. Interpretation of Sections 15 and 16.
|
||||
|
||||
If the disclaimer of warranty and limitation of liability provided
|
||||
above cannot be given local legal effect according to their terms,
|
||||
reviewing courts shall apply local law that most closely approximates
|
||||
an absolute waiver of all civil liability in connection with the
|
||||
Program, unless a warranty or assumption of liability accompanies a
|
||||
copy of the Program in return for a fee.
|
||||
|
||||
END OF TERMS AND CONDITIONS
|
||||
|
||||
How to Apply These Terms to Your New Programs
|
||||
|
||||
If you develop a new program, and you want it to be of the greatest
|
||||
possible use to the public, the best way to achieve this is to make it
|
||||
free software which everyone can redistribute and change under these terms.
|
||||
|
||||
To do so, attach the following notices to the program. It is safest
|
||||
to attach them to the start of each source file to most effectively
|
||||
state the exclusion of warranty; and each file should have at least
|
||||
the "copyright" line and a pointer to where the full notice is found.
|
||||
|
||||
<one line to give the program's name and a brief idea of what it does.>
|
||||
Copyright (C) <year> <name of author>
|
||||
|
||||
This program is free software: you can redistribute it and/or modify
|
||||
it under the terms of the GNU General Public License as published by
|
||||
the Free Software Foundation, either version 3 of the License, or
|
||||
(at your option) any later version.
|
||||
|
||||
This program is distributed in the hope that it will be useful,
|
||||
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
GNU General Public License for more details.
|
||||
|
||||
You should have received a copy of the GNU General Public License
|
||||
along with this program. If not, see <https://www.gnu.org/licenses/>.
|
||||
|
||||
Also add information on how to contact you by electronic and paper mail.
|
||||
|
||||
If the program does terminal interaction, make it output a short
|
||||
notice like this when it starts in an interactive mode:
|
||||
|
||||
<program> Copyright (C) <year> <name of author>
|
||||
This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
|
||||
This is free software, and you are welcome to redistribute it
|
||||
under certain conditions; type `show c' for details.
|
||||
|
||||
The hypothetical commands `show w' and `show c' should show the appropriate
|
||||
parts of the General Public License. Of course, your program's commands
|
||||
might be different; for a GUI interface, you would use an "about box".
|
||||
|
||||
You should also get your employer (if you work as a programmer) or school,
|
||||
if any, to sign a "copyright disclaimer" for the program, if necessary.
|
||||
For more information on this, and how to apply and follow the GNU GPL, see
|
||||
<https://www.gnu.org/licenses/>.
|
||||
|
||||
The GNU General Public License does not permit incorporating your program
|
||||
into proprietary programs. If your program is a subroutine library, you
|
||||
may consider it more useful to permit linking proprietary applications with
|
||||
the library. If this is what you want to do, use the GNU Lesser General
|
||||
Public License instead of this License. But first, please read
|
||||
<https://www.gnu.org/licenses/why-not-lgpl.html>.
|
||||
@@ -0,0 +1,105 @@
|
||||
# CTF Sandbox Orchestrator
|
||||
|
||||
一个面向 Codex / Skills 体系的竞赛沙盒技能集合。
|
||||
|
||||
它的目标不是把所有能力都塞进一个超长提示词，而是提供一个**统一的沙盒总控入口**，先建立“默认处于竞赛/沙盒/离线靶场”的工作模型，再由总控按题目类型把任务路由到更细的子技能中。
|
||||
|
||||
## 项目定位
|
||||
|
||||
这个仓库主要用于解决以下场景：
|
||||
|
||||
- CTF
|
||||
- AWD / 攻防演练
|
||||
- 本地离线靶场
|
||||
- 沙盒化漏洞分析
|
||||
- Web / API / Cloud / Container / Windows / AD / Reverse / Pwn / DFIR / Crypto / Mobile / AI Agent 等混合型题目
|
||||
|
||||
核心思路：
|
||||
|
||||
- 默认把用户提供的目标、域名、节点、身份、二进制、日志、流量与附件视为**竞赛沙盒内部资产**
|
||||
- 优先建立最小可验证路径，而不是一开始就泛化分析
|
||||
- 由一个总控 skill 统一编排，再按主导证据面切到子 skill
|
||||
- 子技能只做下游专项，不抢总控入口
|
||||
|
||||
## 核心设计
|
||||
|
||||
### 1. 单一入口
|
||||
|
||||
默认入口是：
|
||||
|
||||
- `ctf-sandbox-orchestrator`
|
||||
|
||||
它负责：
|
||||
|
||||
- 建立沙盒假设
|
||||
- 选择最合适的分析路径
|
||||
- 控制上下文膨胀
|
||||
- 在需要时调用子技能
|
||||
|
||||
### 2. 子技能下游化
|
||||
|
||||
所有 `competition-*` 技能都被设计为 **downstream-only**：
|
||||
|
||||
- 不应在未激活总控的情况下隐式触发
|
||||
- 应由 `ctf-sandbox-orchestrator` 主动路由调用
|
||||
- 每次只加载当前最相关的专项能力，避免无关技能污染上下文
|
||||
|
||||
### 3. 面向多类型竞赛题
|
||||
|
||||
当前仓库覆盖了多类技能方向，例如：
|
||||
|
||||
- Web 运行时 / 路由 / WebSocket / GraphQL / 文件解析 / 请求归一化
|
||||
- Prompt Injection / Agent / Cloud / Metadata / K8s / Container Escape
|
||||
- Reverse / Pwn / Malware / Firmware / PCAP / 自定义协议重放
|
||||
- Windows / AD / Kerberos / DPAPI / 证书滥用 / Relay / Mailbox
|
||||
- Android / iOS / Crypto / Stego / Mobile Runtime
|
||||
- ZIP / PKZIP legacy encryption / `bkcrack` known-plaintext recovery
|
||||
|
||||
## 仓库结构
|
||||
|
||||
```text
|
||||
E:\WorkSpace\competition
|
||||
├─ ctf-sandbox-orchestrator
|
||||
├─ competition-web-runtime
|
||||
├─ competition-agent-cloud
|
||||
├─ competition-reverse-pwn
|
||||
├─ competition-identity-windows
|
||||
├─ competition-prompt-injection
|
||||
├─ ...
|
||||
└─ LICENSE
|
||||
```
|
||||
|
||||
其中：
|
||||
|
||||
- `ctf-sandbox-orchestrator`：总控入口
|
||||
- `competition-*`：专项子技能
|
||||
- `references/`：总控使用的路由矩阵与领域参考说明
|
||||
- `agents/openai.yaml`：各技能的调用约束与入口控制
|
||||
|
||||
## 推荐使用方式
|
||||
|
||||
### 方式一：从总控进入
|
||||
|
||||
优先激活：
|
||||
|
||||
- `ctf-sandbox-orchestrator`
|
||||
|
||||
然后让总控根据题目自动决定下一步，例如：
|
||||
|
||||
- Web 题路由到 `competition-web-runtime`
|
||||
- 容器 / 云题路由到 `competition-agent-cloud` 或更细粒度子技能
|
||||
- Windows / AD 题路由到 `competition-identity-windows`
|
||||
- 二进制 / 崩溃 / 恶意样本题路由到 `competition-reverse-pwn`
|
||||
|
||||
### 方式二：保留总控，按需下钻
|
||||
|
||||
当已经确认主导证据面后，由总控继续下钻到具体子技能，而不是让用户手动切换整个工作模型。这样可以保持：
|
||||
|
||||
- 沙盒假设一致
|
||||
- 输出风格一致
|
||||
- 路由策略一致
|
||||
- 子技能职责清晰
|
||||
|
||||
## 致谢
|
||||
|
||||
本项目已在 [LINUX DO 社区](https://linux.do) 发布，感谢社区的支持与反馈。
|
||||
@@ -0,0 +1,50 @@
|
||||
---
|
||||
name: competition-ad-certificate-abuse
|
||||
description: Internal downstream skill for ctf-sandbox-orchestrator. CTF-sandbox workflow for AD CS, certificate templates, enrollment rights, EKUs, SAN controls, PKINIT, certificate mapping, and cert-based privilege paths. Use when the user asks about ESC-style abuse, certificate templates, enrollment agents, EKUs, SAN or subject controls, smartcard or PKINIT logon, CA policy, or how an issued cert turns into accepted privilege. Use only after `$ctf-sandbox-orchestrator` has already established sandbox assumptions and routed here.
|
||||
---
|
||||
|
||||
# Competition AD Certificate Abuse
|
||||
|
||||
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 identity edge is certificate-based and the hard part is proving how a template or CA policy turns into accepted privilege.
|
||||
|
||||
Reply in Simplified Chinese unless the user explicitly requests English.
|
||||
|
||||
## Quick Start
|
||||
|
||||
1. Identify the CA, template, enrolling principal, and accepting service before diving into every certificate detail.
|
||||
2. Separate template enrollability from cert-based authentication or privilege acceptance.
|
||||
3. Record EKUs, subject or SAN controls, issuance requirements, enrollment rights, and mapping behavior in compact blocks.
|
||||
4. Tie the issued cert to one accepted path: PKINIT, Schannel, LDAPS, WinRM, or another mapped service.
|
||||
5. Reproduce the smallest certificate issuance-to-acceptance chain that yields the decisive privilege.
|
||||
|
||||
## Workflow
|
||||
|
||||
### 1. Map CA And Template Trust
|
||||
|
||||
- Record CA configuration, template name, enrollment permissions, manager approval, authorized signatures, EKUs, subject requirements, and SAN behavior.
|
||||
- Note whether the path depends on alternate subject names, `UPN`, DNS names, enrollment agent behavior, or template supersedence.
|
||||
- Keep principal, template, and issuance policy tied together.
|
||||
|
||||
### 2. Prove Cert-To-Privilege Acceptance
|
||||
|
||||
- Show how the issued certificate is mapped or accepted: PKINIT, smartcard logon, Schannel auth, service mapping, or explicit certificate mapping.
|
||||
- Record serial, subject, SAN, EKU, validity, and the exact service or domain edge that accepts it.
|
||||
- Distinguish certificate issuance from the separate step where privilege is actually granted.
|
||||
|
||||
### 3. Reduce To The Decisive Abuse Chain
|
||||
|
||||
- Compress the path to the smallest sequence: enrollment right or misconfig -> issued cert -> accepted mapping -> resulting privilege.
|
||||
- State clearly whether the weakness lives in template config, CA policy, mapping logic, relay path, or enrollment rights.
|
||||
- If the task is really about delegation or ticket transformation after PKINIT, switch back to the tighter Kerberos skill.
|
||||
|
||||
## Read This Reference
|
||||
|
||||
- Load `references/ad-certificate-abuse.md` for the AD CS checklist, template checklist, and evidence packaging.
|
||||
|
||||
## What To Preserve
|
||||
|
||||
- CA names, template names, rights, EKUs, issuance flags, SAN controls, and mapping details
|
||||
- Issued certificate fields, serials, subjects, SANs, and the accepting service or logon path
|
||||
- The smallest reproducible enrollment-to-privilege chain
|
||||
@@ -0,0 +1,7 @@
|
||||
interface:
|
||||
display_name: "Competition Ad Certificate Abuse"
|
||||
short_description: "Trace templates, EKUs, enrollment paths, and cert privilege"
|
||||
default_prompt: "After $ctf-sandbox-orchestrator is active, use $competition-ad-certificate-abuse to trace certificate templates, enrollment rights, EKUs, and cert-based privilege in this AD challenge."
|
||||
|
||||
policy:
|
||||
allow_implicit_invocation: false
|
||||
+27
@@ -0,0 +1,27 @@
|
||||
# AD Certificate Abuse Checklist
|
||||
|
||||
## Core Surfaces
|
||||
|
||||
- Enterprise CA configuration, issuance policy, enrollment permissions, manager approval, authorized signatures
|
||||
- Template flags, EKUs, subject or SAN controls, enrollment agent settings, superseded templates
|
||||
- PKINIT, smartcard logon, Schannel, certificate mapping, relay paths, accepting services
|
||||
|
||||
## Abuse Chain To Reconstruct
|
||||
|
||||
1. Principal with enrollment or relay path identified
|
||||
2. Template or CA weakness established
|
||||
3. Certificate issued with exploitable identity material
|
||||
4. Service or logon path accepts the cert
|
||||
5. Resulting privilege or account effect confirmed
|
||||
|
||||
## Evidence To Keep Together
|
||||
|
||||
- Template side: name, rights, EKUs, flags, SAN controls, issuance requirements
|
||||
- Cert side: subject, SAN, serial, validity, issuer, thumbprint
|
||||
- Acceptance side: PKINIT or service mapping, target account, resulting privilege
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
- Stopping at template misconfiguration without proving cert issuance
|
||||
- Proving issuance without proving where the cert is actually accepted
|
||||
- Mixing certificate abuse with Kerberos delegation when the decisive edge is the template or mapping itself
|
||||
@@ -0,0 +1,53 @@
|
||||
---
|
||||
name: competition-agent-cloud
|
||||
description: 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.
|
||||
---
|
||||
|
||||
# Competition Agent Cloud
|
||||
|
||||
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 challenge path is driven by prompt-to-tool execution, retrieval and memory boundaries, deployment drift, or build and release provenance.
|
||||
|
||||
Reply in Simplified Chinese unless the user explicitly requests English.
|
||||
|
||||
## Quick Start
|
||||
|
||||
1. Decide whether the dominant path is agentic or infrastructure-driven.
|
||||
2. Map one minimal control chain: untrusted input -> visible context -> tool or deployment side effect.
|
||||
3. Distinguish checked-in intent from live runtime truth.
|
||||
4. Keep prompts, tool args, manifests, mounts, and provenance steps in compact evidence blocks.
|
||||
5. Reproduce the exploit or misconfiguration with minimal context and minimal instrumentation.
|
||||
|
||||
## Workflow
|
||||
|
||||
### 1. Agent And Prompt Injection
|
||||
|
||||
- Treat prompts, tool schemas, retrieved chunks, planner notes, memory files, and handoffs as challenge artifacts.
|
||||
- Prove one minimal chain from untrusted content to model-visible instruction to tool side effect.
|
||||
- Distinguish claimed capability from runtime-exposed capability.
|
||||
|
||||
### 2. Cloud, Containers, And CI/CD
|
||||
|
||||
- Split build-time, deploy-time, and runtime.
|
||||
- Reconcile compose or kube manifests with live mounts, env, logs, and traffic.
|
||||
- Trace provenance from source to dependency resolution to build to publish to runtime consumer.
|
||||
|
||||
## Read This Reference
|
||||
|
||||
- Load `references/agent-cloud.md` for the control-stack checklist, deployment-truth checklist, and evidence packaging.
|
||||
- If the task is specifically about prompt-boundary abuse or retrieved-content-to-tool drift, prefer `$competition-prompt-injection`.
|
||||
- If the task is specifically about CI, dependency provenance, registry drift, or shipped artifacts, prefer `$competition-supply-chain`.
|
||||
- If the task is specifically about queue payloads, async worker drift, retries, or worker-only runtime state, prefer `$competition-queue-worker-drift`.
|
||||
- If the task is specifically about SSRF to internal control surfaces, metadata endpoints, or metadata-derived token pivots, prefer `$competition-ssrf-metadata-pivot`.
|
||||
- If the task is specifically about proxy-upstream parse differentials, ambiguous headers, path normalization drift, or request smuggling behavior, prefer `$competition-request-normalization-smuggling`.
|
||||
- If the task is specifically about metadata-service access, instance or workload identity, link-local token paths, or metadata-derived privilege, prefer `$competition-cloud-metadata-path`.
|
||||
- If the task is specifically about kube API permissions, service-account trust, admission behavior, controller drift, or cluster secret exposure, prefer `$competition-k8s-control-plane`.
|
||||
- If the task is specifically about live mounts, sidecars, init containers, or runtime-only secret exposure, prefer `$competition-container-runtime`.
|
||||
- If the task is specifically about container-to-host boundary crossing, kernel-surface prerequisites, or escape primitive verification, prefer `$competition-kernel-container-escape`.
|
||||
|
||||
## What To Preserve
|
||||
|
||||
- Prompt snippets, retrieved chunks, planner transitions, and final tool args
|
||||
- Compose or Kubernetes fragments tied to live mounts or routes
|
||||
- Artifact hashes, dependency drift, CI steps, and the resulting runtime consumer
|
||||
@@ -0,0 +1,7 @@
|
||||
interface:
|
||||
display_name: "Competition Agent Cloud"
|
||||
short_description: "Trace prompt-to-tool flow, deployment drift, and provenance"
|
||||
default_prompt: "After $ctf-sandbox-orchestrator is active, use $competition-agent-cloud to trace prompt-to-tool flow, deployment drift, mounted secrets, or artifact provenance in this challenge."
|
||||
|
||||
policy:
|
||||
allow_implicit_invocation: false
|
||||
@@ -0,0 +1,24 @@
|
||||
# Agent, Toolchain, Cloud, And Supply-Chain Checklist
|
||||
|
||||
## Agentic Path
|
||||
|
||||
- Map instruction layers, retrieval layers, memory layers, tool gates, auth material, and side effects
|
||||
- Keep one compact evidence block for prompts, retrieved text, planner drift, tool arguments, and side effect
|
||||
- Prove one minimal exploit chain before exploring variants
|
||||
|
||||
## Cloud And Container Path
|
||||
|
||||
- Compare checked-in manifests to live mounts, env, sidecars, and logs
|
||||
- Treat metadata services, registries, message buses, object stores, and IAM-like identities as sandbox control surfaces when they appear in-path
|
||||
- Track build-time, deploy-time, and runtime separately
|
||||
|
||||
## Supply Chain
|
||||
|
||||
- Keep a compact provenance chain: source -> dependency resolution -> build -> package/sign -> publish -> runtime consumer
|
||||
- Focus on version drift, registry pulls, generated artifacts, and final runtime hook points
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
- Trusting a prompt string without runtime confirmation
|
||||
- Treating checked-in manifests as deployment truth
|
||||
- Missing the point where retrieved content becomes executable tool input
|
||||
@@ -0,0 +1,50 @@
|
||||
---
|
||||
name: competition-android-hooking
|
||||
description: Internal downstream skill for ctf-sandbox-orchestrator. CTF-sandbox workflow for Android APK hooking, Frida tracing, request-signing recovery, SSL pinning bypass, JNI boundary inspection, and app trust-boundary analysis. Use when the user asks to hook an APK, inspect signer logic, trace Java or native boundaries, bypass pinning or root checks, inspect shared prefs or app databases, or replay accepted mobile requests. Use only after `$ctf-sandbox-orchestrator` has already established sandbox assumptions and routed here.
|
||||
---
|
||||
|
||||
# Competition Android Hooking
|
||||
|
||||
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 path runs through an Android app's live trust boundary rather than static strings alone.
|
||||
|
||||
Reply in Simplified Chinese unless the user explicitly requests English.
|
||||
|
||||
## Quick Start
|
||||
|
||||
1. Preserve the original APK, extracted resources, and decompiled output before patching or resigning.
|
||||
2. Start with manifest, exported components, deeplinks, native libs, prefs, local DBs, and bundled configs.
|
||||
3. Decide the narrowest runtime boundary to hook: signer, crypto helper, JNI bridge, WebView bridge, or request builder.
|
||||
4. Correlate static evidence and dynamic traces before claiming a trust edge is understood.
|
||||
5. Reproduce the signed request, accepted token, or gated branch from the smallest hook set.
|
||||
|
||||
## Workflow
|
||||
|
||||
### 1. Static Triage Before Hooks
|
||||
|
||||
- Map package structure, exported activities, services, receivers, providers, and deeplink handlers.
|
||||
- Note SSL pinning logic, root checks, feature flags, token storage, shared prefs, SQLite tables, and protobuf or RPC boundaries.
|
||||
- Identify whether the sensitive logic sits in Java, Kotlin, JNI, or a bundled WebView.
|
||||
|
||||
### 2. Hook The Narrowest Boundary
|
||||
|
||||
- Prefer hooking request signers, crypto helpers, keystore access, protobuf encode or decode, or JNI marshaling instead of broad UI hooks.
|
||||
- Record plaintext inputs, signed strings, headers, nonces, and outputs at the boundary that actually changes trust.
|
||||
- If pinning or environment checks block progress, patch or hook only enough to expose the real request path.
|
||||
|
||||
### 3. Replay The Accepted Path
|
||||
|
||||
- Rebuild the smallest sequence that reaches the accepted server-side branch: local state, nonce, request body, signature, and headers.
|
||||
- Keep hook logs, captured request shapes, and local storage paths tied to the same account or session state.
|
||||
- If the challenge becomes more about transform recovery than Android runtime, switch back to the broader crypto or mobile skill.
|
||||
|
||||
## Read This Reference
|
||||
|
||||
- Load `references/android-hooking.md` for hook targets, storage checklist, and evidence packaging.
|
||||
|
||||
## What To Preserve
|
||||
|
||||
- Hook points, class names, JNI symbols, signer inputs and outputs, and header names
|
||||
- Shared prefs, local DB rows, deeplinks, exported components, and token storage paths
|
||||
- The smallest replayable request or branch that proves the trust boundary
|
||||
@@ -0,0 +1,7 @@
|
||||
interface:
|
||||
display_name: "Competition Android Hooking"
|
||||
short_description: "Hook APK signers, JNI bridges, pinning checks, and requests"
|
||||
default_prompt: "After $ctf-sandbox-orchestrator is active, use $competition-android-hooking to hook this APK, trace signer logic, inspect JNI or Java boundaries, and replay the accepted request path."
|
||||
|
||||
policy:
|
||||
allow_implicit_invocation: false
|
||||
@@ -0,0 +1,27 @@
|
||||
# Android Hooking Checklist
|
||||
|
||||
## Static Targets To Map First
|
||||
|
||||
- `AndroidManifest.xml`, exported components, deeplinks, intent filters, bundled configs
|
||||
- Native libraries, JNI registration points, crypto helpers, request builders, protobuf models
|
||||
- Shared prefs, SQLite DBs, WebView assets, root checks, SSL pinning logic
|
||||
|
||||
## Preferred Hook Boundaries
|
||||
|
||||
1. Request signer input string and output signature
|
||||
2. Crypto helper plaintext and ciphertext
|
||||
3. JNI boundary arguments and return values
|
||||
4. Keystore access or device-binding checks
|
||||
5. WebView bridge messages or JS interface calls
|
||||
|
||||
## Evidence To Keep Together
|
||||
|
||||
- Static location: class, method, symbol, or asset path
|
||||
- Dynamic proof: hook log, returned value, request header, or accepted response
|
||||
- State dependency: local token, DB row, pref key, nonce, or device flag
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
- Hooking too high in the UI layer and missing the real signer boundary
|
||||
- Capturing a signed header without the plaintext that produced it
|
||||
- Ignoring local state prerequisites such as prefs, DB rows, or keystore material
|
||||
@@ -0,0 +1,50 @@
|
||||
---
|
||||
name: competition-browser-persistence
|
||||
description: Internal downstream skill for ctf-sandbox-orchestrator. CTF-sandbox workflow for browser cookies, localStorage, sessionStorage, IndexedDB, Cache Storage, service workers, offline caches, and client-side session persistence. Use when the user asks to inspect browser state, replay cached auth or session behavior, explain why a page behaves differently after load, or trace how stored client state changes requests, rendering, or access. Use only after `$ctf-sandbox-orchestrator` has already established sandbox assumptions and routed here.
|
||||
---
|
||||
|
||||
# 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
|
||||
|
||||
1. Identify the active persistence surface first: cookie jar, localStorage, sessionStorage, IndexedDB, Cache Storage, or service worker.
|
||||
2. Record origin, scope, domain, path, expiry, and key names before mutating state.
|
||||
3. Tie stored state to one concrete effect: request header, rendered branch, cached response, offline behavior, or hidden route access.
|
||||
4. Separate boot-time state from runtime-mutated state.
|
||||
5. 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.md` for 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
|
||||
@@ -0,0 +1,7 @@
|
||||
interface:
|
||||
display_name: "Competition Browser Persistence"
|
||||
short_description: "Inspect cookies, storage, service workers, and cached state"
|
||||
default_prompt: "After $ctf-sandbox-orchestrator is active, use $competition-browser-persistence to inspect browser cookies, storage, service workers, caches, and replay the smallest stateful path in this challenge."
|
||||
|
||||
policy:
|
||||
allow_implicit_invocation: false
|
||||
+28
@@ -0,0 +1,28 @@
|
||||
# Browser Persistence Checklist
|
||||
|
||||
## Surfaces To Check
|
||||
|
||||
- Cookies: domain, path, expiry, `HttpOnly`, `Secure`, `SameSite`
|
||||
- `localStorage`, `sessionStorage`, IndexedDB object stores, Cache Storage entries
|
||||
- Service worker registrations, cached responses, fetch handlers, offline fallbacks
|
||||
- Boot-time globals, hydration payloads, feature flags, role or tenant selectors
|
||||
|
||||
## Correlation Pattern
|
||||
|
||||
1. Storage item or cookie identified
|
||||
2. Origin and scope confirmed
|
||||
3. Request, render, or cache behavior linked to that item
|
||||
4. Clean-state vs mutated-state run compared
|
||||
5. Decisive branch reproduced
|
||||
|
||||
## Evidence To Keep Together
|
||||
|
||||
- State identity: origin, key, value shape, scope, expiry, DB or cache name
|
||||
- Runtime effect: header, route, feature flag, cached response, or rendered branch
|
||||
- Replay prerequisites: initial route, prior request, login state, or service worker registration
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
- Listing storage contents without showing which item changes behavior
|
||||
- Mixing several origins or tenants in one storage explanation
|
||||
- Treating cached UI data as backend authorization without proving a server-side effect
|
||||
@@ -0,0 +1,50 @@
|
||||
---
|
||||
name: competition-bundle-sourcemap-recovery
|
||||
description: Internal downstream skill for ctf-sandbox-orchestrator. CTF-sandbox workflow for source maps, build manifests, chunk registries, emitted bundles, obfuscated loader flow, and frontend runtime recovery. Use when the user asks to reconstruct served JavaScript structure, inspect source maps or chunk maps, trace bundle loading, recover hidden routes or APIs from emitted assets, or explain runtime behavior from built frontend artifacts. Use only after `$ctf-sandbox-orchestrator` has already established sandbox assumptions and routed here.
|
||||
---
|
||||
|
||||
# Competition Bundle Sourcemap Recovery
|
||||
|
||||
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 runtime truth lives in built assets, source maps, chunk tables, or obfuscated loader flow rather than in checked-in source alone.
|
||||
|
||||
Reply in Simplified Chinese unless the user explicitly requests English.
|
||||
|
||||
## Quick Start
|
||||
|
||||
1. Start from the served artifact set: entry HTML, build manifest, bootstrap bundle, chunk map, and source maps.
|
||||
2. Record chunk ids, route chunks, loader functions, endpoint strings, and config keys before broad manual deobfuscation.
|
||||
3. Reconstruct the smallest runtime graph that explains which asset executes now.
|
||||
4. Keep served artifact truth separate from repository source unless parity is proven.
|
||||
5. Reproduce the smallest asset-to-runtime boundary that proves the decisive behavior.
|
||||
|
||||
## Workflow
|
||||
|
||||
### 1. Map The Served Artifact Set
|
||||
|
||||
- Record entry HTML, script tags, preload hints, manifest files, asset map, chunk registry, and source map URLs.
|
||||
- Note framework-specific artifacts such as route manifests, client reference manifests, or lazy-loader tables when present.
|
||||
- Keep emitted filenames, hash suffixes, and route ownership tied together.
|
||||
|
||||
### 2. Reconstruct Runtime Structure
|
||||
|
||||
- Follow bootstrap code, chunk loaders, module registry, string decoders, and lazy import boundaries.
|
||||
- Use source maps, manifest files, and stable symbol clusters to recover route names, API calls, feature flags, and hidden panels.
|
||||
- Distinguish build-time intent from the bundle that is actively served now.
|
||||
|
||||
### 3. Reduce To The Decisive Bundle Path
|
||||
|
||||
- Compress the result to the smallest sequence: served asset -> loader path -> module or symbol -> runtime effect.
|
||||
- State clearly whether the decisive weakness lives in manifest drift, chunk loading, hidden route code, string decoding, or stale source assumptions.
|
||||
- If the task shifts from built assets to SSR or template enforcement, hand back to the tighter template-render skill.
|
||||
|
||||
## Read This Reference
|
||||
|
||||
- Load `references/bundle-sourcemap-recovery.md` for the artifact checklist, deobfuscation checklist, and evidence packaging.
|
||||
|
||||
## What To Preserve
|
||||
|
||||
- Served filenames, chunk ids, manifest entries, source map paths, recovered symbols, and endpoint strings
|
||||
- The exact executing bundle or module that proves the runtime branch
|
||||
- One minimal asset-to-runtime sequence that reaches the decisive effect
|
||||
@@ -0,0 +1,7 @@
|
||||
interface:
|
||||
display_name: "Competition Bundle Sourcemap Recovery"
|
||||
short_description: "Recover source maps, chunk loaders, and hidden runtime structure"
|
||||
default_prompt: "After $ctf-sandbox-orchestrator is active, use $competition-bundle-sourcemap-recovery to reconstruct served bundles, source maps, chunk loading, and the hidden runtime structure behind this challenge."
|
||||
|
||||
policy:
|
||||
allow_implicit_invocation: false
|
||||
+27
@@ -0,0 +1,27 @@
|
||||
# Bundle And Sourcemap Recovery Checklist
|
||||
|
||||
## First Pass
|
||||
|
||||
- Entry HTML, script tags, preload links, manifests, chunk registries, source map URLs
|
||||
- Bootstrap bundle, lazy chunks, route chunks, loader helpers, string decoders
|
||||
- Framework clues: route manifest, client reference manifest, build id, asset map
|
||||
|
||||
## Chain To Reconstruct
|
||||
|
||||
1. Served asset selected
|
||||
2. Bootstrap or loader resolves chunk or module
|
||||
3. Module registry or source map reveals structure
|
||||
4. Hidden route, API call, or branch is recovered
|
||||
5. Runtime effect is reproduced from the emitted asset set
|
||||
|
||||
## Evidence To Keep Together
|
||||
|
||||
- Asset side: filenames, hashes, chunk ids, manifest entries, source map path
|
||||
- Recovery side: recovered symbol, route, endpoint, loader helper, or decoded string
|
||||
- Effect side: rendered panel, hidden route, accepted request, or client behavior
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
- Trusting repository source over the currently served artifact set
|
||||
- Opening huge minified bundles before checking manifests and source maps
|
||||
- Recovering names without proving which bundle path actually executes at runtime
|
||||
@@ -0,0 +1,51 @@
|
||||
---
|
||||
name: competition-cloud-metadata-path
|
||||
description: Internal downstream skill for ctf-sandbox-orchestrator. CTF-sandbox workflow for cloud metadata services, instance identity, workload identity, link-local credential paths, role assumption, and metadata-to-privilege trust edges. Use when the user asks to inspect metadata-service access, instance credentials, pod or workload identity, link-local token paths, SSRF-to-metadata escalation, or explain how metadata-derived credentials turn into accepted cloud or control-plane privilege. Use only after `$ctf-sandbox-orchestrator` has already established sandbox assumptions and routed here.
|
||||
---
|
||||
|
||||
# Competition Cloud Metadata Path
|
||||
|
||||
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 edge is not just reaching metadata, but proving how metadata-derived identity becomes accepted privilege.
|
||||
|
||||
Reply in Simplified Chinese unless the user explicitly requests English.
|
||||
|
||||
## Quick Start
|
||||
|
||||
1. Identify which metadata surface is active: instance metadata, workload identity, node identity, task role, or platform-specific token endpoint.
|
||||
2. Record the exact reachability path: local process, pod, container, proxy, SSRF surface, or host route.
|
||||
3. Separate metadata reachability from credential issuance and from downstream privilege acceptance.
|
||||
4. Keep token format, role identity, scope, and accepting API in compact evidence blocks.
|
||||
5. Reproduce the smallest metadata-to-accepted-privilege path that proves the challenge edge.
|
||||
|
||||
## Workflow
|
||||
|
||||
### 1. Map Metadata Reachability
|
||||
|
||||
- Record the metadata endpoint, required headers, hop limits, session tokens, workload selectors, or path prefixes.
|
||||
- Note whether access comes from direct local calls, pod networking, SSRF, sidecar, or host-level routing.
|
||||
- Keep the reaching surface and the metadata endpoint in one chain.
|
||||
|
||||
### 2. Prove Credential Or Identity Issuance
|
||||
|
||||
- Show how the metadata response becomes a token, temporary credential, signed identity doc, or platform-specific workload identity.
|
||||
- Record expiration, role name, subject, audience, issuer, or cloud account mapping that matters downstream.
|
||||
- Distinguish raw metadata from usable credential material.
|
||||
|
||||
### 3. Reduce To The Decisive Trust Path
|
||||
|
||||
- Compress the result to the smallest sequence: reaching surface -> metadata call -> credential issued -> accepted cloud or cluster action.
|
||||
- State clearly whether the weakness lives in reachability, metadata config, role trust, downstream policy, or workload binding.
|
||||
- If the challenge narrows to RBAC or cluster mutation after credential issuance, switch back to the tighter control-plane skill.
|
||||
|
||||
## Read This Reference
|
||||
|
||||
- Load `references/cloud-metadata-path.md` for the reachability checklist, token checklist, and evidence packaging.
|
||||
- If the hard part is first proving a server-side fetch primitive, SSRF reachability, or internal endpoint traversal before metadata itself, prefer `$competition-ssrf-metadata-pivot`.
|
||||
|
||||
## What To Preserve
|
||||
|
||||
- Metadata endpoints, required headers, reachability path, issued tokens or creds, and accepted APIs
|
||||
- Role names, audiences, issuers, account bindings, and privilege-bearing actions
|
||||
- The smallest replayable metadata-to-privilege chain
|
||||
@@ -0,0 +1,7 @@
|
||||
interface:
|
||||
display_name: "Competition Cloud Metadata Path"
|
||||
short_description: "Trace metadata services, instance creds, and trust edges"
|
||||
default_prompt: "After $ctf-sandbox-orchestrator is active, use $competition-cloud-metadata-path to trace metadata-service access, instance credentials, and the trust path they unlock in this challenge."
|
||||
|
||||
policy:
|
||||
allow_implicit_invocation: false
|
||||
+27
@@ -0,0 +1,27 @@
|
||||
# Cloud Metadata Path Checklist
|
||||
|
||||
## First Pass
|
||||
|
||||
- Metadata endpoint, hop limit, required headers, session token requirements, link-local route, workload identity binding
|
||||
- Reaching surface: local process, pod, container, proxy, SSRF, sidecar, or host namespace
|
||||
- Downstream trust: role assumption, cloud API, cluster API, secret access, or signed identity use
|
||||
|
||||
## Chain To Reconstruct
|
||||
|
||||
1. Reachable path to metadata established
|
||||
2. Metadata response or token obtained
|
||||
3. Usable identity or credential material extracted
|
||||
4. Downstream API or trust edge accepts it
|
||||
5. Resulting privilege or artifact confirmed
|
||||
|
||||
## Evidence To Keep Together
|
||||
|
||||
- Reachability side: route, headers, namespace, container, SSRF primitive, or proxy path
|
||||
- Identity side: role name, token claims, expiration, audience, issuer, account or project binding
|
||||
- Acceptance side: API action, resource access, secret read, or spawned workload effect
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
- Proving metadata access without proving a useful credential was actually issued
|
||||
- Proving token issuance without showing which downstream API accepts it
|
||||
- Mixing node identity and workload identity without showing which one actually drove the privilege edge
|
||||
@@ -0,0 +1,51 @@
|
||||
---
|
||||
name: competition-container-runtime
|
||||
description: Internal downstream skill for ctf-sandbox-orchestrator. CTF-sandbox workflow for live container runtime analysis, mounted secrets, sidecars, namespaces, init containers, entrypoint drift, and route-to-container resolution. Use when the user asks why a live container differs from manifests, where a mounted secret is consumed, how a sidecar or init container changes runtime state, or which route resolves to which live container. Use only after `$ctf-sandbox-orchestrator` has already established sandbox assumptions and routed here.
|
||||
---
|
||||
|
||||
# Competition Container Runtime
|
||||
|
||||
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 challenge is really about what the live container or pod is doing now, not what the checked-in manifest claims it should do.
|
||||
|
||||
Reply in Simplified Chinese unless the user explicitly requests English.
|
||||
|
||||
## Quick Start
|
||||
|
||||
1. Split intent from reality: manifest, image, startup, live mount, live route, live process.
|
||||
2. Map host -> proxy -> container or pod -> mounted volume -> consuming process.
|
||||
3. Keep secrets, rendered config, init output, and sidecar output separate from static manifests.
|
||||
4. Prove one minimal live path from mounted or injected state to reachable behavior.
|
||||
5. Reproduce the effect with the smallest runtime-specific chain.
|
||||
|
||||
## Workflow
|
||||
|
||||
### 1. Map The Live Runtime
|
||||
|
||||
- Compare compose or kube manifests against running containers, pods, mounted volumes, env, sidecars, init containers, and entrypoints.
|
||||
- Identify which process actually consumes the mounted secret, rendered config, or shared volume output.
|
||||
|
||||
### 2. Trace Route And Mount Boundaries
|
||||
|
||||
- Map virtual host, reverse proxy, service, container port, filesystem mount, and runtime-generated file paths together.
|
||||
- Record whether the decisive state is image-baked, env-injected, mounted later, or written by an init/sidecar process.
|
||||
|
||||
### 3. Report The Runtime Deviation
|
||||
|
||||
- State the earliest point where live runtime diverges from checked-in intent.
|
||||
- Keep one compact evidence chain from manifest or compose intent to live consumer behavior.
|
||||
|
||||
## Read This Reference
|
||||
|
||||
- Load `references/container-runtime.md` for the runtime checklist, mount-chain checklist, and common live-vs-static pitfalls.
|
||||
- If the hard part is kube API permissions, service-account trust, RBAC edges, admission mutations, or controller-created workload drift, prefer `$competition-k8s-control-plane`.
|
||||
- If the hard part is Host-header routing, path-prefix rewriting, or route-to-service mapping across nodes, prefer `$competition-runtime-routing`.
|
||||
- If the hard part is proving container-to-host crossover, kernel attack-surface preconditions, or stable escape primitives, prefer `$competition-kernel-container-escape`.
|
||||
- If the hard part is replaying Linux secrets, socket trust edges, or host-to-host pivots after container foothold, prefer `$competition-linux-credential-pivot`.
|
||||
|
||||
## What To Preserve
|
||||
|
||||
- Compose/Kubernetes fragments tied to live mounts or routes
|
||||
- Container IDs, pod names, mount paths, sidecar outputs, rendered config paths, and consuming processes
|
||||
- The exact route or file path that becomes reachable only at runtime
|
||||
@@ -0,0 +1,7 @@
|
||||
interface:
|
||||
display_name: "Competition Container Runtime"
|
||||
short_description: "Explain runtime-vs-manifest drift, mounts, sidecars, and routes"
|
||||
default_prompt: "After $ctf-sandbox-orchestrator is active, use $competition-container-runtime to explain why the live container differs from manifests and where mounts, sidecars, or namespaces change runtime state."
|
||||
|
||||
policy:
|
||||
allow_implicit_invocation: false
|
||||
+40
@@ -0,0 +1,40 @@
|
||||
# Container Runtime Checklist
|
||||
|
||||
## Compare Intent vs Reality
|
||||
|
||||
Inspect side by side:
|
||||
|
||||
- compose or kube manifests
|
||||
- image layers and entrypoints
|
||||
- init containers
|
||||
- sidecars
|
||||
- mounted volumes
|
||||
- runtime env
|
||||
- live processes and listeners
|
||||
|
||||
## Trace The Mount Chain
|
||||
|
||||
- who writes the file
|
||||
- where it is mounted
|
||||
- which process reads it
|
||||
- which route or behavior depends on it
|
||||
|
||||
## High-Value Runtime Deviations
|
||||
|
||||
- rendered secrets written to shared volumes
|
||||
- init output consumed by the main container
|
||||
- sidecar-generated config or credentials
|
||||
- runtime-only env values not visible in checked-in manifests
|
||||
- reverse-proxy routing that exposes an internal path only after startup
|
||||
|
||||
## Evidence To Keep
|
||||
|
||||
- one compact block for manifest intent
|
||||
- one compact block for live mounts, processes, or rendered files
|
||||
- one compact block for the route or behavior reached only because of runtime state
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
- treating checked-in manifests as deployment truth
|
||||
- stopping at “secret is mounted” without proving the consuming process
|
||||
- missing sidecar or init output because only the main service was inspected
|
||||
@@ -0,0 +1,50 @@
|
||||
---
|
||||
name: competition-crypto-mobile
|
||||
description: Internal downstream skill for ctf-sandbox-orchestrator. CTF-sandbox workflow for crypto, encoding, steganography, APK, IPA, and mobile trust-boundary challenges. Use when the user asks to decode a blob, recover a transform chain or key, inspect hidden media payloads, hook an APK or IPA signer, inspect app storage, or replay mobile request-signing logic. Use only after `$ctf-sandbox-orchestrator` has already established sandbox assumptions and routed here.
|
||||
---
|
||||
|
||||
# Competition Crypto Mobile
|
||||
|
||||
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 active challenge depends on recovering a transform chain, hidden media payload, mobile signing path, or local trust boundary.
|
||||
|
||||
Reply in Simplified Chinese unless the user explicitly requests English.
|
||||
|
||||
## Quick Start
|
||||
|
||||
1. Decide whether the dominant path is crypto, stego, or mobile.
|
||||
2. Recover transforms in order; do not jump straight to the fanciest algorithm.
|
||||
3. Record exact parameters and boundaries that affect the result.
|
||||
4. Hook the narrowest mobile boundary that proves the behavior.
|
||||
5. Reproduce the plaintext, payload, signed request, or accepted branch.
|
||||
|
||||
## Workflow
|
||||
|
||||
### 1. Crypto And Encoding
|
||||
|
||||
- Reconstruct the chain step by step: container, compression, encoding, xor or substitution, crypto, integrity, final parse.
|
||||
- Keep exact keys, IVs, nonces, salts, tags, offsets, and byte order.
|
||||
|
||||
### 2. Stego
|
||||
|
||||
- Inspect metadata, chunk layout, palettes, alpha planes, LSBs, thumbnails, trailers, and transcoding artifacts.
|
||||
- Rank decode attempts by evidence, not by brute-force curiosity.
|
||||
|
||||
### 3. Mobile
|
||||
|
||||
- Start with manifest or plist, exported components, deeplinks, native libs, shared prefs, local DBs, and configs.
|
||||
- Trace signer logic, token storage, SSL pinning, protobuf or RPC boundaries, and native bridge calls.
|
||||
|
||||
## Read This Reference
|
||||
|
||||
- Load `references/crypto-mobile.md` for the transform checklist, hook targets, and evidence packaging.
|
||||
- If the task is specifically about Android dynamic tracing, signer hooks, JNI boundaries, or pinning checks, prefer `$competition-android-hooking`.
|
||||
- If the task is specifically about iOS runtime tracing, Keychain access, Objective-C or Swift hooks, or pinning checks inside an IPA, prefer `$competition-ios-runtime`.
|
||||
- If the task is specifically about media carriers, hidden channels, thumbnails, or appended trailers, prefer `$competition-stego-media`.
|
||||
|
||||
## What To Preserve
|
||||
|
||||
- Decisive bytes proving each decode stage
|
||||
- Hook points, signed strings, headers, and local storage paths
|
||||
- Component names, protobuf fields, channel-specific outputs, or trailer offsets
|
||||
@@ -0,0 +1,7 @@
|
||||
interface:
|
||||
display_name: "Competition Crypto Mobile"
|
||||
short_description: "Decode blobs, inspect stego, and hook mobile signers"
|
||||
default_prompt: "After $ctf-sandbox-orchestrator is active, use $competition-crypto-mobile to decode this blob, recover the transform chain, inspect stego payloads, or hook the mobile signing path."
|
||||
|
||||
policy:
|
||||
allow_implicit_invocation: false
|
||||
@@ -0,0 +1,24 @@
|
||||
# Crypto, Stego, And Mobile Checklist
|
||||
|
||||
## Crypto
|
||||
|
||||
- Work in order: container -> compression -> encoding -> xor/substitution -> crypto -> integrity -> parse
|
||||
- Recognition is not recovery; reproduce the actual plaintext or downstream artifact
|
||||
- Keep exact parameters in one compact evidence block
|
||||
|
||||
## Stego
|
||||
|
||||
- Check metadata, chunk layout, palettes, alpha, LSBs, thumbnails, appended trailers
|
||||
- Prefer evidence-driven decode attempts over blind brute force
|
||||
|
||||
## Mobile
|
||||
|
||||
- Check manifest/plist, exported components, deeplinks, native libs, shared prefs, local DBs, configs
|
||||
- Hook the narrowest boundary: signer, crypto helper, protobuf edge, keystore access, WebView bridge
|
||||
- Correlate static evidence and dynamic evidence before concluding
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
- Reporting only algorithm names with no reproduced artifact
|
||||
- Scattering transform stages across many bullets
|
||||
- Hooking too late and missing the trust boundary that matters
|
||||
@@ -0,0 +1,50 @@
|
||||
---
|
||||
name: competition-custom-protocol-replay
|
||||
description: Internal downstream skill for ctf-sandbox-orchestrator. CTF-sandbox workflow for custom binary or text protocol recovery, handshake reconstruction, framing, sequence control, checksums, stateful replay, and accepted-session reproduction. Use when the user asks to decode an unknown protocol, recover custom framing, build a replay harness, satisfy sequence or checksum rules, replay a captured session, or prove the smallest message order that reaches an accepted branch. Use only after `$ctf-sandbox-orchestrator` has already established sandbox assumptions and routed here.
|
||||
---
|
||||
|
||||
# Competition Custom Protocol Replay
|
||||
|
||||
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 hard part is not merely naming the protocol, but reproducing the exact message order and state needed for acceptance.
|
||||
|
||||
Reply in Simplified Chinese unless the user explicitly requests English.
|
||||
|
||||
## Quick Start
|
||||
|
||||
1. Identify client and server roles, session boundaries, and reset conditions before decoding field semantics.
|
||||
2. Recover framing, lengths, delimiters, sequence numbers, checksums, nonces, and state transitions before broad replay attempts.
|
||||
3. Keep one canonical transcript of a successful exchange.
|
||||
4. Change one field or one message at a time while replaying.
|
||||
5. Reproduce the smallest accepted conversation that proves the decisive branch.
|
||||
|
||||
## Workflow
|
||||
|
||||
### 1. Map The Session State Machine
|
||||
|
||||
- Identify handshake, negotiation, authentication, keepalive, command, and teardown phases.
|
||||
- Record which fields are static, which are derived, and which depend on prior messages.
|
||||
- Keep message order, direction, and timing tied to the same session identity.
|
||||
|
||||
### 2. Recover Framing And Integrity
|
||||
|
||||
- Reconstruct lengths, delimiters, type bytes, checksums, MACs, counters, compression, or encryption boundaries.
|
||||
- Distinguish transport framing from application-level framing.
|
||||
- Note exactly where server acceptance changes when one field or step is mutated.
|
||||
|
||||
### 3. Build The Minimal Replay Harness
|
||||
|
||||
- Reduce the path to the smallest transcript that reaches the accepted state, parser branch, command effect, or artifact.
|
||||
- Preserve both the original captured sequence and the replayed minimal sequence.
|
||||
- If the problem is mainly generic PCAP or stream decoding with no stateful replay requirement, switch back to the broader PCAP skill.
|
||||
|
||||
## Read This Reference
|
||||
|
||||
- Load `references/custom-protocol-replay.md` for the state-machine checklist, transcript checklist, and evidence packaging.
|
||||
|
||||
## What To Preserve
|
||||
|
||||
- Canonical transcript, message types, field boundaries, checksums, counters, and session identifiers
|
||||
- Original capture slices and the replay harness inputs that produce acceptance
|
||||
- The exact mutation that flips the protocol from rejected to accepted, or vice versa
|
||||
@@ -0,0 +1,7 @@
|
||||
interface:
|
||||
display_name: "Competition Custom Protocol Replay"
|
||||
short_description: "Replay custom framing, message order, and accepted state"
|
||||
default_prompt: "After $ctf-sandbox-orchestrator is active, use $competition-custom-protocol-replay to recover this custom protocol framing, replay message order, and reproduce the accepted protocol state."
|
||||
|
||||
policy:
|
||||
allow_implicit_invocation: false
|
||||
+27
@@ -0,0 +1,27 @@
|
||||
# Custom Protocol Replay Checklist
|
||||
|
||||
## Transcript First
|
||||
|
||||
- Establish roles, stream IDs, ports, session resets, handshake boundaries, and successful transcript examples
|
||||
- Separate transport segmentation from application messages
|
||||
- Record retransmits or duplicate messages so they do not pollute the protocol model
|
||||
|
||||
## Recovery Order
|
||||
|
||||
1. Framing and message boundaries
|
||||
2. Direction and sequence state
|
||||
3. Integrity fields: checksum, MAC, counter, nonce, or signature
|
||||
4. Compression, encoding, or crypto boundary
|
||||
5. Accepted vs rejected transcript deltas
|
||||
|
||||
## Evidence To Keep Together
|
||||
|
||||
- Message identity: type, offset, length, direction, sequence, or delimiter
|
||||
- Acceptance state: prior message dependency, negotiated value, checksum, or nonce source
|
||||
- Replay proof: minimal transcript, harness input, and server response or side effect
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
- Trying broad replay before framing and state dependencies are understood
|
||||
- Mixing messages from separate sessions into one replay model
|
||||
- Claiming protocol recovery without producing an accepted replay or meaningful state transition
|
||||
@@ -0,0 +1,50 @@
|
||||
---
|
||||
name: competition-dpapi-credential-chain
|
||||
description: Internal downstream skill for ctf-sandbox-orchestrator. CTF-sandbox workflow for DPAPI masterkeys, vault blobs, browser credential stores, protected secrets, domain backup keys, and secret-to-acceptance replay chains. Use when the user asks to inspect DPAPI blobs or masterkeys, recover browser or vault credentials, trace DPAPI context or backup-key use, or explain how protected Windows secrets become accepted access or privilege. Use only after `$ctf-sandbox-orchestrator` has already established sandbox assumptions and routed here.
|
||||
---
|
||||
|
||||
# Competition Dpapi Credential Chain
|
||||
|
||||
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 Windows secret is DPAPI-protected and the hard part is proving which context unwraps it and where the plaintext is accepted.
|
||||
|
||||
Reply in Simplified Chinese unless the user explicitly requests English.
|
||||
|
||||
## Quick Start
|
||||
|
||||
1. Separate protected blob, masterkey, decrypting context, and final accepting service.
|
||||
2. Record SID, user or machine context, masterkey path, vault or browser store, and target replay point before broad conclusions.
|
||||
3. Keep DPAPI source artifact, unwrap step, plaintext secret, and acceptance edge in one chain.
|
||||
4. Distinguish local user DPAPI, machine DPAPI, domain backup key use, and application-specific wrapping.
|
||||
5. Reproduce the smallest DPAPI-to-accepted-access path that proves the decisive edge.
|
||||
|
||||
## Workflow
|
||||
|
||||
### 1. Map Protected Secret And DPAPI Context
|
||||
|
||||
- Record blob source, masterkey location, SID, protector scope, profile path, credential store, and any application wrapper such as browser encryption or vault metadata.
|
||||
- Note whether the decisive value lives in Credential Manager, Vault, browser cookies, browser passwords, Wi-Fi profiles, RDP files, or custom app storage.
|
||||
- Keep protected artifact, masterkey candidate, and account or machine context tied together.
|
||||
|
||||
### 2. Prove Unwrap And Acceptance
|
||||
|
||||
- Show how the secret is decrypted: user logon material, machine context, domain backup key, or another recovered protector.
|
||||
- Record plaintext type, target host or service, replay method, and resulting session, token, or data access.
|
||||
- Distinguish successful blob decryption from actual accepted access.
|
||||
|
||||
### 3. Reduce To The Decisive DPAPI Chain
|
||||
|
||||
- Compress the result to the smallest sequence: protected artifact -> masterkey or unwrap context -> plaintext secret -> accepted replay or access -> resulting capability.
|
||||
- State clearly whether the decisive edge lives in masterkey recovery, DPAPI scope confusion, application wrapper handling, or the service that accepts the recovered secret.
|
||||
- If the task broadens into generic LSASS ticket material or full Windows pivoting, hand back to the tighter host or pivot skill.
|
||||
|
||||
## Read This Reference
|
||||
|
||||
- Load `references/dpapi-credential-chain.md` for the blob checklist, masterkey checklist, and evidence packaging.
|
||||
|
||||
## What To Preserve
|
||||
|
||||
- Blob paths, masterkey paths, SIDs, protector scope, store names, and application wrapper details
|
||||
- The exact accepting service or dataset unlocked by the recovered plaintext
|
||||
- One minimal protected-artifact-to-accepted-access sequence that proves the edge
|
||||
@@ -0,0 +1,7 @@
|
||||
interface:
|
||||
display_name: "Competition Dpapi Credential Chain"
|
||||
short_description: "Trace DPAPI masterkeys, blobs, stores, and replayable secrets"
|
||||
default_prompt: "After $ctf-sandbox-orchestrator is active, use $competition-dpapi-credential-chain to trace DPAPI masterkeys, protected blobs, browser stores, and the replayable secret edge in this challenge."
|
||||
|
||||
policy:
|
||||
allow_implicit_invocation: false
|
||||
+27
@@ -0,0 +1,27 @@
|
||||
# DPAPI Credential Chain Checklist
|
||||
|
||||
## First Pass
|
||||
|
||||
- Blob source, masterkey path, SID, protector scope, profile path, store name, wrapper metadata
|
||||
- Secret locations: Credential Manager, Vault, browser Login Data, cookies, Wi-Fi profiles, app storage
|
||||
- Acceptance targets: browser session replay, SMB, RDP, WinRM, app login, data decryption
|
||||
|
||||
## Chain To Reconstruct
|
||||
|
||||
1. Protected artifact is identified
|
||||
2. Matching masterkey or unwrap context is found
|
||||
3. Plaintext secret is recovered
|
||||
4. Accepting service or dataset is confirmed
|
||||
5. Resulting capability or access is reproduced
|
||||
|
||||
## Evidence To Keep Together
|
||||
|
||||
- Source side: blob path, store, SID, profile, machine or user scope
|
||||
- Unwrap side: masterkey source, backup key use, wrapper details, plaintext type
|
||||
- Acceptance side: target service, target host, unlocked data, resulting session or privilege
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
- Treating DPAPI decryption as the end instead of proving an accepting service or dataset
|
||||
- Mixing user and machine scope without recording which protector actually matches
|
||||
- Ignoring application-specific wrapping around browser or vault secrets
|
||||
@@ -0,0 +1,50 @@
|
||||
---
|
||||
name: competition-file-parser-chain
|
||||
description: Internal downstream skill for ctf-sandbox-orchestrator. CTF-sandbox workflow for file uploads, imports, previews, archive extraction, format conversion, parser invocation, and deserialization chains. Use when the user asks to inspect an upload or import path, trace archive extraction, preview or converter behavior, explain how a file reaches a parser or deserializer, or connect one uploaded artifact to the decisive backend effect. Use only after `$ctf-sandbox-orchestrator` has already established sandbox assumptions and routed here.
|
||||
---
|
||||
|
||||
# Competition File Parser Chain
|
||||
|
||||
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 hard part is following a file from ingress through every parser, extractor, converter, or deserializer boundary that matters.
|
||||
|
||||
Reply in Simplified Chinese unless the user explicitly requests English.
|
||||
|
||||
## Quick Start
|
||||
|
||||
1. Preserve the original upload and every derived artifact separately.
|
||||
2. Map the chain in order: ingress, temp storage, archive extraction, format conversion, parser call, deserialization, and final consumer.
|
||||
3. Record filenames, MIME guesses, extensions, temp paths, and parser choices before mutating anything.
|
||||
4. Separate client-visible validation from backend parser behavior.
|
||||
5. Reproduce the smallest file-processing chain that yields the decisive branch or artifact.
|
||||
|
||||
## Workflow
|
||||
|
||||
### 1. Map File Ingress And Derivation
|
||||
|
||||
- Record request shape, multipart names, content type, filename, temp paths, upload staging, and storage keys.
|
||||
- Note every derived artifact: extracted archive member, converted preview, generated thumbnail, temp document, or deserialized object.
|
||||
- Keep original file and each derivative labeled separately.
|
||||
|
||||
### 2. Trace Parser And Conversion Boundaries
|
||||
|
||||
- Show which parser, converter, extractor, or deserializer runs at each step.
|
||||
- Record parser-specific decisions driven by extension, MIME, magic bytes, schema, archive member names, or embedded metadata.
|
||||
- Distinguish parsing success, preview success, conversion success, and business-logic acceptance.
|
||||
|
||||
### 3. Reduce To The Decisive File Chain
|
||||
|
||||
- Compress the result to the smallest sequence: upload -> derived artifact -> parser boundary -> resulting effect.
|
||||
- State clearly whether the decisive weakness lives in archive handling, MIME inference, file conversion, path resolution, or deserialization.
|
||||
- If the chain becomes mostly a generic async worker problem after enqueue, hand off to the tighter queue or worker skill.
|
||||
|
||||
## Read This Reference
|
||||
|
||||
- Load `references/file-parser-chain.md` for the ingress checklist, parser checklist, and evidence packaging.
|
||||
|
||||
## What To Preserve
|
||||
|
||||
- Original uploads, derived files, temp paths, storage keys, parser names, and conversion steps
|
||||
- The exact boundary where backend behavior diverges from user-visible validation
|
||||
- One minimal replayable file-processing sequence that reaches the decisive effect
|
||||
@@ -0,0 +1,7 @@
|
||||
interface:
|
||||
display_name: "Competition File Parser Chain"
|
||||
short_description: "Trace upload parsing, converters, archives, and deserialization"
|
||||
default_prompt: "After $ctf-sandbox-orchestrator is active, use $competition-file-parser-chain to trace this upload or import through parsing, extraction, conversion, deserialization, and the decisive backend effect."
|
||||
|
||||
policy:
|
||||
allow_implicit_invocation: false
|
||||
+27
@@ -0,0 +1,27 @@
|
||||
# File Parser Chain Checklist
|
||||
|
||||
## First Pass
|
||||
|
||||
- Upload request shape, field names, content type, filename, extension, magic bytes, temp storage
|
||||
- Archive members, conversion outputs, previews, thumbnails, extracted docs, serialized objects
|
||||
- Final consumers: parser, converter, renderer, importer, deserializer, worker
|
||||
|
||||
## Chain To Reconstruct
|
||||
|
||||
1. File ingress accepted
|
||||
2. Temp or staged artifact created
|
||||
3. Extraction or conversion performed
|
||||
4. Parser or deserializer invoked
|
||||
5. Business-logic effect or artifact produced
|
||||
|
||||
## Evidence To Keep Together
|
||||
|
||||
- Ingress side: request, filename, MIME, temp path, storage key
|
||||
- Parser side: tool or library invoked, branch condition, derived artifact, parser choice
|
||||
- Effect side: rendered output, parsed object, backend branch, worker task, or privilege-bearing result
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
- Looking only at the original upload and ignoring derived intermediates
|
||||
- Treating MIME or extension checks as proof of backend parser choice
|
||||
- Mixing archive, preview, and deserialization stages without preserving each boundary separately
|
||||
@@ -0,0 +1,50 @@
|
||||
---
|
||||
name: competition-firmware-layout
|
||||
description: Internal downstream skill for ctf-sandbox-orchestrator. CTF-sandbox workflow for firmware images, partition tables, boot chains, update packages, extracted filesystems, embedded configs, and device-facing trust boundaries. Use when the user asks to unpack firmware, map partition layout, inspect bootloader or init chains, recover update keys or credentials, trace config loading, or explain how a device surface reaches the decisive artifact. Use only after `$ctf-sandbox-orchestrator` has already established sandbox assumptions and routed here.
|
||||
---
|
||||
|
||||
# Competition Firmware Layout
|
||||
|
||||
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 hard part is understanding how a firmware image is structured, booted, updated, and turned into reachable device behavior.
|
||||
|
||||
Reply in Simplified Chinese unless the user explicitly requests English.
|
||||
|
||||
## Quick Start
|
||||
|
||||
1. Preserve the original image, extracted partitions, unpacked filesystems, and patched copies as separate artifacts.
|
||||
2. Map outer container, partition table, bootloader, kernel, rootfs, config, and update metadata before editing anything.
|
||||
3. Track the boot or update chain in order instead of jumping straight to the most interesting file.
|
||||
4. Record keys, signatures, offsets, partition boundaries, and init entrypoints in one compact evidence chain.
|
||||
5. Reproduce the decisive secret, branch, or reachable service from the smallest extracted path.
|
||||
|
||||
## Workflow
|
||||
|
||||
### 1. Establish Image Layout
|
||||
|
||||
- Identify container type, partition headers, compression, filesystem type, and any appended or nested images.
|
||||
- Record offsets, sizes, hashes, mount points, and partition names before extraction mutates anything.
|
||||
- Separate bootloader, kernel, initramfs, rootfs, config blobs, and update metadata as different layers.
|
||||
|
||||
### 2. Trace Boot Or Update Flow
|
||||
|
||||
- Map how control moves from bootloader to kernel to init to services, or from update package to verifier to installer.
|
||||
- Note which credentials, certificates, passwords, seeds, or config files are consumed at each stage.
|
||||
- Distinguish checked-in firmware intent from the live behavior the extracted files actually support.
|
||||
|
||||
### 3. Reduce To The Decisive Path
|
||||
|
||||
- Show the smallest chain from image boundary to service exposure, auth bypass, debug interface, credential recovery, or flag artifact.
|
||||
- Keep extracted filesystems, derived configs, and patch experiments separate from pristine inputs.
|
||||
- If the challenge becomes mostly about native crash behavior or exploit primitives after extraction, switch back to the broader reverse skill.
|
||||
|
||||
## Read This Reference
|
||||
|
||||
- Load `references/firmware-layout.md` for the layout checklist, boot-chain checklist, and evidence packaging.
|
||||
|
||||
## What To Preserve
|
||||
|
||||
- Partition offsets, hashes, filesystem types, mount paths, boot entrypoints, and update metadata
|
||||
- Extracted secrets, config paths, init scripts, service units, and credentials tied to the stage that consumes them
|
||||
- Original images, extracted layers, mounted views, and patched copies as separate artifacts
|
||||
@@ -0,0 +1,7 @@
|
||||
interface:
|
||||
display_name: "Competition Firmware Layout"
|
||||
short_description: "Map firmware partitions, boot chains, and extracted secrets"
|
||||
default_prompt: "After $ctf-sandbox-orchestrator is active, use $competition-firmware-layout to map this firmware image, extract partitions, trace the boot or update chain, and recover decisive secrets or branches."
|
||||
|
||||
policy:
|
||||
allow_implicit_invocation: false
|
||||
@@ -0,0 +1,27 @@
|
||||
# Firmware Layout Checklist
|
||||
|
||||
## First Pass
|
||||
|
||||
- Identify outer container, partition headers, compression, checksums, and appended images
|
||||
- Record partition names, offsets, sizes, filesystem types, mount points, and hashes
|
||||
- Separate bootloader, kernel, initramfs, rootfs, config, and update payloads
|
||||
|
||||
## Boot Or Update Chain
|
||||
|
||||
1. Boot ROM or vendor bootstrap
|
||||
2. Bootloader or secure boot stage
|
||||
3. Kernel and initramfs
|
||||
4. Root filesystem init path and services
|
||||
5. Update verifier, installer, and post-install hooks
|
||||
|
||||
## Evidence To Keep Together
|
||||
|
||||
- Boundary facts: offsets, sizes, signatures, hashes, partition names
|
||||
- Consumed state: keys, certs, passwords, default configs, scripts, or service files
|
||||
- Reachable effect: debug service, auth branch, update bypass, or recovered artifact
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
- Editing extracted files before recording pristine offsets and hashes
|
||||
- Mixing config recovered from one partition with behavior sourced from another without proving the link
|
||||
- Treating an extracted secret as decisive without showing where the boot or update flow actually consumes it
|
||||
@@ -0,0 +1,51 @@
|
||||
---
|
||||
name: competition-forensic-timeline
|
||||
description: 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.
|
||||
---
|
||||
|
||||
# Competition Forensic Timeline
|
||||
|
||||
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 hard part is not finding one artifact, but turning many artifacts into one replayable chronology.
|
||||
|
||||
Reply in Simplified Chinese unless the user explicitly requests English.
|
||||
|
||||
## Quick Start
|
||||
|
||||
1. Pick the smallest reliable anchor: first execution, first logon, first network session, first file write, or first mailbox action.
|
||||
2. Normalize timestamps, time zones, hostnames, users, process IDs, message IDs, and file paths before correlating.
|
||||
3. Build one minimal chain from foothold to persistence, execution, access, or exfiltration.
|
||||
4. Separate confirmed event order from inferred gaps.
|
||||
5. Reproduce the decisive timeline segment that yields the artifact or privilege conclusion.
|
||||
|
||||
## Workflow
|
||||
|
||||
### 1. Establish Timeline Anchors
|
||||
|
||||
- Collect only the active surfaces: EVTX, Sysmon, registry, Amcache, prefetch, browser artifacts, mail traces, PCAPs, memory, or filesystem metadata.
|
||||
- Record clock source, timezone, and any drift or truncation that could reorder events.
|
||||
- Link shared identifiers across sources: PID, logon ID, GUID, message ID, hostname, username, IP, or hash.
|
||||
|
||||
### 2. Correlate The Execution Graph
|
||||
|
||||
- Track process tree, service or task creation, network sessions, file writes, registry changes, mailbox rules, or token use as one path.
|
||||
- Distinguish causal edges from coincidence by matching identifiers and adjacency, not just nearby timestamps.
|
||||
- Keep raw artifact and parsed summary side by side so every step can be traced back.
|
||||
|
||||
### 3. Compress To The Decisive Story
|
||||
|
||||
- Reduce the timeline to the smallest sequence that proves initial access, persistence, lateral movement, collection, or artifact recovery.
|
||||
- Call out missing validation steps separately instead of mixing them into confirmed chronology.
|
||||
- If the task becomes mainly about malware config extraction or a Windows pivot edge, switch to the tighter specialized skill.
|
||||
|
||||
## Read This Reference
|
||||
|
||||
- Load `references/forensic-timeline.md` for anchor selection, cross-source correlation, and evidence packaging.
|
||||
- If the hard part is packet reassembly, protocol framing, or transferred-object extraction from a capture, prefer `$competition-pcap-protocol`.
|
||||
|
||||
## What To Preserve
|
||||
|
||||
- Source file paths, event IDs, logon IDs, message IDs, PIDs, hashes, and timestamps with timezone noted
|
||||
- One compact timeline table or ordered list for the decisive segment
|
||||
- Raw artifacts, parsed output, and inferred edges kept separate
|
||||
@@ -0,0 +1,7 @@
|
||||
interface:
|
||||
display_name: "Competition Forensic Timeline"
|
||||
short_description: "Correlate host, mail, memory, and network evidence over time"
|
||||
default_prompt: "After $ctf-sandbox-orchestrator is active, use $competition-forensic-timeline to reconstruct the attack timeline across logs, disk, memory, mail, and network artifacts in this challenge."
|
||||
|
||||
policy:
|
||||
allow_implicit_invocation: false
|
||||
+28
@@ -0,0 +1,28 @@
|
||||
# Forensic Timeline Checklist
|
||||
|
||||
## Anchor Selection
|
||||
|
||||
- Earliest trustworthy markers: process creation, service install, scheduled task, mailbox rule write, browser download, network connect, or credential replay
|
||||
- Note the time source for each artifact: event log local time, UTC network time, filesystem timestamp, mailbox server time, or packet capture timestamp
|
||||
- Record drift, missing zones, daylight-saving ambiguity, or truncation before merging sources
|
||||
|
||||
## Cross-Source Correlation
|
||||
|
||||
Match on shared identifiers whenever possible:
|
||||
|
||||
1. Process ID, parent process ID, or command line
|
||||
2. Logon ID, SID, ticket cache, mailbox item ID, or message trace ID
|
||||
3. Hostname, IP, MAC, session ID, GUID, or hash
|
||||
4. File path, registry path, service name, task name, or attachment name
|
||||
|
||||
## Timeline Compression
|
||||
|
||||
- Keep one long-form raw chronology for yourself and one short decisive chronology for the final answer
|
||||
- Separate observed events from inferred transitions
|
||||
- If an edge is inferred, state the missing validation step explicitly
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
- Sorting by timestamp alone when clock drift or delayed logging exists
|
||||
- Mixing mailbox, browser, host, and network artifacts without shared identifiers
|
||||
- Reporting a long event dump instead of the smallest sequence that proves the challenge path
|
||||
@@ -0,0 +1,50 @@
|
||||
---
|
||||
name: competition-graphql-rpc-drift
|
||||
description: Internal downstream skill for ctf-sandbox-orchestrator. CTF-sandbox workflow for GraphQL schemas, persisted queries, RPC manifests, generated clients, OpenAPI drift, hidden operations, and contract-to-handler mismatches. Use when the user asks to inspect GraphQL or RPC requests, compare client contracts to live handlers, recover hidden operations, trace generated clients, or explain how schema or contract drift produces the decisive behavior. Use only after `$ctf-sandbox-orchestrator` has already established sandbox assumptions and routed here.
|
||||
---
|
||||
|
||||
# Competition Graphql Rpc Drift
|
||||
|
||||
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 hard part is matching declared contracts with live handlers to find hidden, stale, or privileged operations.
|
||||
|
||||
Reply in Simplified Chinese unless the user explicitly requests English.
|
||||
|
||||
## Quick Start
|
||||
|
||||
1. Collect the declared contract surface first: schema, manifest, generated client, persisted query map, or OpenAPI spec.
|
||||
2. Record actual request shapes, operation names, variables, method, path, and auth context before mutating anything.
|
||||
3. Compare declared contract, generated client behavior, and live handler behavior side by side.
|
||||
4. Preserve one accepted operation and one drifted or hidden operation with the smallest delta.
|
||||
5. Reproduce the smallest contract-to-handler mismatch that proves the decisive branch.
|
||||
|
||||
## Workflow
|
||||
|
||||
### 1. Map The Declared Contract Surface
|
||||
|
||||
- Record GraphQL schema, introspection output, persisted query ids, RPC manifests, generated clients, or OpenAPI documents that define the intended surface.
|
||||
- Note versioned endpoints, client-only guards, hidden enums, optional fields, and operation naming conventions.
|
||||
- Keep document source and generation path tied to the observed requests.
|
||||
|
||||
### 2. Prove Live Handler Behavior
|
||||
|
||||
- Capture the real request and response pairs, including operation name, variables, headers, cookies, and status.
|
||||
- Compare client-side validation, schema expectations, and live handler normalization or fallback behavior.
|
||||
- Record hidden operations, stale fields, undocumented methods, or handler-only branches that still execute.
|
||||
|
||||
### 3. Reduce To The Decisive Drift Path
|
||||
|
||||
- Compress the result to the smallest sequence: declared contract -> actual request -> handler branch -> resulting capability.
|
||||
- State clearly whether the decisive drift lives in generated client assumptions, persisted query mapping, schema version skew, RPC manifest mismatch, or handler-side hidden logic.
|
||||
- If the task shifts into generic JWT, OAuth, or queue behavior after acceptance, hand off to the tighter specialized skill.
|
||||
|
||||
## Read This Reference
|
||||
|
||||
- Load `references/graphql-rpc-drift.md` for the contract checklist, live-handler checklist, and evidence packaging.
|
||||
|
||||
## What To Preserve
|
||||
|
||||
- Schemas, manifests, generated clients, persisted query ids, operation names, and version markers
|
||||
- One accepted and one drifted request pair that proves the mismatch
|
||||
- One minimal contract-to-handler sequence that reaches the decisive effect
|
||||
@@ -0,0 +1,7 @@
|
||||
interface:
|
||||
display_name: "Competition Graphql Rpc Drift"
|
||||
short_description: "Trace GraphQL or RPC contracts, drift, and hidden operations"
|
||||
default_prompt: "After $ctf-sandbox-orchestrator is active, use $competition-graphql-rpc-drift to compare client contracts, schemas, persisted queries, and live handlers to find the decisive drift."
|
||||
|
||||
policy:
|
||||
allow_implicit_invocation: false
|
||||
+27
@@ -0,0 +1,27 @@
|
||||
# Graphql And Rpc Drift Checklist
|
||||
|
||||
## First Pass
|
||||
|
||||
- GraphQL schema, introspection output, persisted query ids, RPC manifest, generated client, OpenAPI doc
|
||||
- Operation names, fields, variables, method, path, version headers, auth context
|
||||
- Live handlers, fallback routes, hidden operations, stale fields, client-only guards
|
||||
|
||||
## Chain To Reconstruct
|
||||
|
||||
1. Declared contract is identified
|
||||
2. Real request shape is captured
|
||||
3. Handler normalization or hidden branch is observed
|
||||
4. Contract drift or hidden operation is confirmed
|
||||
5. Resulting capability or artifact is reproduced
|
||||
|
||||
## Evidence To Keep Together
|
||||
|
||||
- Contract side: schema, manifest, generated client, version marker, persisted query id
|
||||
- Request side: operation name, variables, method, path, headers, cookies
|
||||
- Effect side: hidden data, accepted action, privilege, or backend state change
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
- Treating generated clients as proof of the only supported operations
|
||||
- Looking at GraphQL schema or OpenAPI docs without capturing real requests
|
||||
- Describing hidden operations without proving the exact handler branch they hit
|
||||
@@ -0,0 +1,54 @@
|
||||
---
|
||||
name: competition-identity-windows
|
||||
description: Internal downstream skill for ctf-sandbox-orchestrator. CTF-sandbox workflow for Active Directory, Kerberos, LDAP, OAuth, enterprise messaging, Windows host forensics, credential material, and lateral-movement challenges. Use when the user asks to trace tickets or tokens, inspect mailbox rules, analyze Windows host evidence, understand an AD trust path, or explain a lateral-movement chain across sandbox-linked nodes. Use only after `$ctf-sandbox-orchestrator` has already established sandbox assumptions and routed here.
|
||||
---
|
||||
|
||||
# Competition Identity Windows
|
||||
|
||||
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 challenge revolves around identity flow, replayable credentials, Windows host artifacts, enterprise mail, or lateral movement.
|
||||
|
||||
Reply in Simplified Chinese unless the user explicitly requests English.
|
||||
|
||||
## Quick Start
|
||||
|
||||
1. Map the identity or pivot chain before diving into every host artifact.
|
||||
2. Separate credential possession from accepted privilege.
|
||||
3. Correlate identity evidence, host evidence, and mail evidence on one timeline.
|
||||
4. Keep tickets, SIDs, event IDs, mailbox rules, and pivot hosts in compact evidence blocks.
|
||||
5. Reproduce the privilege edge or mail effect from the smallest viable chain.
|
||||
|
||||
## Workflow
|
||||
|
||||
### 1. Identity And AD
|
||||
|
||||
- Trace principal origin, sync path, token or ticket minting, claims transformation, group resolution, and accepting service.
|
||||
- When Kerberos matters, record ticket type, SPN, delegation mode, PAC or group data, encryption type, and cache location.
|
||||
|
||||
### 2. Windows Host And Pivoting
|
||||
|
||||
- Correlate SAM, SECURITY, SYSTEM, NTDS, DPAPI, LSA secrets, ETW, Sysmon, PowerShell, services, tasks, WMI, WinRM, SMB, and RDP as one pivot graph.
|
||||
- Express movement as a concrete chain: foothold -> recovered artifact -> replay path -> pivot host -> resulting capability.
|
||||
|
||||
### 3. Enterprise Messaging
|
||||
|
||||
- Keep phishing lures, consent logs, mailbox rules, and identity-provider events tied together so the mail path and privilege path stay connected.
|
||||
|
||||
## Read This Reference
|
||||
|
||||
- Load `references/identity-windows.md` for the ticket, host, and enterprise-messaging checklist.
|
||||
- If the task is primarily a host-to-host pivot, Kerberos replay, or Windows privilege chain, prefer `$competition-windows-pivot`.
|
||||
- If the task is specifically about constrained delegation, unconstrained delegation, RBCD, S4U, or ticket-acceptance proof, prefer `$competition-kerberos-delegation`.
|
||||
- If the task is specifically about AD CS, certificate templates, EKUs, enrollment rights, PKINIT, or cert-based privilege, prefer `$competition-ad-certificate-abuse`.
|
||||
- If the task is specifically about OAuth or OIDC claims, callback flow, scopes, consent, or accepted login identity, prefer `$competition-oauth-oidc-chain`.
|
||||
- If the task is specifically about DPAPI masterkeys, vault blobs, browser or vault secrets, backup-key use, or protected-secret-to-access chains, prefer `$competition-dpapi-credential-chain`.
|
||||
- If the task is specifically about LSASS memory, ticket caches, LUID-linked material, DPAPI context, or replayable host credential artifacts, prefer `$competition-lsass-ticket-material`.
|
||||
- If the task is specifically about mailbox rules, forwarding, OAuth consent, delegate access, or transport-level mail abuse, prefer `$competition-mailbox-abuse`.
|
||||
- If the task is specifically about forced authentication, relay targets, or proving which service accepts relayed auth, prefer `$competition-relay-coercion-chain`.
|
||||
|
||||
## What To Preserve
|
||||
|
||||
- SIDs, SPNs, ticket fields, event IDs, mailbox rules, and replay points
|
||||
- Exact host-to-host pivot order and the service that accepts the credential or ticket
|
||||
- Raw artifacts, parsed summaries, and derived timelines as separate outputs
|
||||
@@ -0,0 +1,7 @@
|
||||
interface:
|
||||
display_name: "Competition Identity Windows"
|
||||
short_description: "Trace tickets, tokens, mailbox rules, and Windows pivot paths"
|
||||
default_prompt: "After $ctf-sandbox-orchestrator is active, use $competition-identity-windows to trace tickets, tokens, Windows host evidence, mailbox rules, or lateral movement in this challenge."
|
||||
|
||||
policy:
|
||||
allow_implicit_invocation: false
|
||||
@@ -0,0 +1,27 @@
|
||||
# Identity, Windows, And Enterprise Messaging Checklist
|
||||
|
||||
## Identity
|
||||
|
||||
- Map principal origin, token or ticket minting, claims or group transformation, and final accepting service
|
||||
- Distinguish credential material from effective privilege
|
||||
- Inspect ACLs, GPO links, SIDHistory, delegation, certificate templates, service accounts, and replication rights when AD edges matter
|
||||
|
||||
## Windows Host
|
||||
|
||||
- Check SAM, SECURITY, SYSTEM, NTDS, DPAPI, LSA secrets, browser stores, PowerShell history, ETW, Sysmon, prefetch, jump lists, Amcache, SRUM, shimcache
|
||||
- Correlate services, tasks, WMI, WinRM, SMB, RDP, admin shares, and remote registry as one pivot graph
|
||||
|
||||
## Enterprise Messaging
|
||||
|
||||
- Correlate phishing lures, attachment chains, consent logs, login traces, message-trace logs, and mailbox-rule changes
|
||||
|
||||
## Evidence To Keep
|
||||
|
||||
- One compact block for SIDs, SPNs, ticket fields, event IDs, logon IDs, or mailbox rules
|
||||
- One compact block for host pivots, replayed artifacts, and resulting privilege changes
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
- Treating possession of a hash or ticket as proof of resulting privilege
|
||||
- Saying "domain compromise" without a reproducible edge-by-edge chain
|
||||
- Separating host evidence from identity evidence until the story stops making sense
|
||||
@@ -0,0 +1,50 @@
|
||||
---
|
||||
name: competition-ios-runtime
|
||||
description: Internal downstream skill for ctf-sandbox-orchestrator. CTF-sandbox workflow for IPA runtime analysis, Frida hooks, Objective-C or Swift method tracing, Keychain inspection, SSL pinning bypass, URL scheme handling, and iOS request-signing recovery. Use when the user asks to hook an IPA, trace Objective-C or Swift runtime behavior, inspect Keychain or plist state, bypass pinning, analyze deeplinks or universal links, or replay accepted iOS requests. Use only after `$ctf-sandbox-orchestrator` has already established sandbox assumptions and routed here.
|
||||
---
|
||||
|
||||
# Competition iOS Runtime
|
||||
|
||||
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 path runs through live iOS trust boundaries rather than static strings or plist values alone.
|
||||
|
||||
Reply in Simplified Chinese unless the user explicitly requests English.
|
||||
|
||||
## Quick Start
|
||||
|
||||
1. Preserve the original IPA, extracted bundle, and any decrypted or re-signed copy as separate artifacts.
|
||||
2. Start with `Info.plist`, entitlements, URL schemes, frameworks, Keychain usage, and local app storage before broad runtime hooks.
|
||||
3. Choose the narrowest runtime boundary that proves behavior: signer, trust evaluator, Keychain accessor, Objective-C or Swift method, or network request builder.
|
||||
4. Correlate static bundle evidence and live hook output before claiming the trust path is understood.
|
||||
5. Reproduce the accepted request, token, or gated branch from the smallest hook set.
|
||||
|
||||
## Workflow
|
||||
|
||||
### 1. Static iOS Triage
|
||||
|
||||
- Map bundle structure, `Info.plist`, entitlements, URL schemes, universal links, embedded frameworks, and app group paths.
|
||||
- Record likely trust boundaries: request signers, device binding, certificate checks, jailbreak checks, Keychain access, or local cache loading.
|
||||
- Note whether sensitive logic sits in Objective-C, Swift, embedded frameworks, or a bundled web surface.
|
||||
|
||||
### 2. Hook The Runtime Boundary
|
||||
|
||||
- Prefer hooking request builders, crypto helpers, trust evaluators, Keychain reads, or Objective-C selectors instead of broad UI handlers.
|
||||
- Record plaintext inputs, headers, nonces, signed strings, and outputs at the boundary that changes server acceptance.
|
||||
- Patch or bypass pinning or environment checks only enough to expose the real request path.
|
||||
|
||||
### 3. Replay The Accepted Path
|
||||
|
||||
- Rebuild the smallest stateful sequence: local token, device identifier, request body, signature, headers, and trust checks.
|
||||
- Keep hook logs, bundle paths, plist keys, and local storage artifacts tied to the same session or account state.
|
||||
- If the task becomes mostly about transform recovery instead of iOS runtime, switch back to the broader crypto or mobile skill.
|
||||
|
||||
## Read This Reference
|
||||
|
||||
- Load `references/ios-runtime.md` for hook targets, storage checklist, and evidence packaging.
|
||||
|
||||
## What To Preserve
|
||||
|
||||
- Bundle paths, entitlements, plist keys, selectors, class names, hook points, and header names
|
||||
- Keychain items, local DB or plist paths, URL schemes, and app-group storage locations
|
||||
- The smallest replayable request or branch that proves the iOS trust boundary
|
||||
@@ -0,0 +1,7 @@
|
||||
interface:
|
||||
display_name: "Competition Ios Runtime"
|
||||
short_description: "Hook IPA signers, keychain access, pinning checks, and requests"
|
||||
default_prompt: "After $ctf-sandbox-orchestrator is active, use $competition-ios-runtime to inspect this IPA, trace iOS signer or keychain logic, bypass trust checks, and replay the accepted request path."
|
||||
|
||||
policy:
|
||||
allow_implicit_invocation: false
|
||||
@@ -0,0 +1,27 @@
|
||||
# iOS Runtime Checklist
|
||||
|
||||
## Static Targets To Map First
|
||||
|
||||
- `Info.plist`, entitlements, URL schemes, universal links, embedded frameworks, provisioning clues
|
||||
- Keychain access groups, app groups, local plist files, SQLite DBs, cache directories
|
||||
- Certificate checks, jailbreak checks, request builders, crypto helpers, device-binding logic
|
||||
|
||||
## Preferred Hook Boundaries
|
||||
|
||||
1. Request builder input and final signed headers
|
||||
2. Crypto helper plaintext and ciphertext
|
||||
3. Trust evaluator or pinning decision point
|
||||
4. Keychain read or write boundary
|
||||
5. Objective-C selector or Swift method that gates the accepted branch
|
||||
|
||||
## Evidence To Keep Together
|
||||
|
||||
- Static location: class, selector, framework, plist key, entitlement, or bundle path
|
||||
- Dynamic proof: hook log, returned value, header, request body, or accepted response
|
||||
- State dependency: Keychain item, plist value, DB row, nonce, device flag, or local token
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
- Hooking only UI handlers and missing the real signer or trust evaluator
|
||||
- Capturing a signed request without the plaintext or local state that generated it
|
||||
- Mixing original IPA, decrypted bundle, and patched runtime output without labeling them separately
|
||||
@@ -0,0 +1,50 @@
|
||||
---
|
||||
name: competition-jwt-claim-confusion
|
||||
description: Internal downstream skill for ctf-sandbox-orchestrator. CTF-sandbox workflow for JWT, JWS, and JWE validation paths, header parsing, key selection, claim acceptance, audience and issuer checks, role derivation, and token-to-identity confusion bugs. Use when the user asks to inspect JWT headers or claims, key lookup, `kid` handling, `alg` confusion, audience or issuer validation, role claims, or explain how a token becomes accepted identity or privilege. Use only after `$ctf-sandbox-orchestrator` has already established sandbox assumptions and routed here.
|
||||
---
|
||||
|
||||
# Competition JWT Claim Confusion
|
||||
|
||||
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 bug is not just "there is a JWT," but how headers, claims, and key selection turn into accepted identity.
|
||||
|
||||
Reply in Simplified Chinese unless the user explicitly requests English.
|
||||
|
||||
## Quick Start
|
||||
|
||||
1. Split the token path into parse, key lookup, signature or decryption, claim validation, and final acceptance.
|
||||
2. Record header fields, claims, key source, issuer, audience, and role mapping before mutating anything.
|
||||
3. Separate possession of a token from the exact service that accepts it.
|
||||
4. Keep parser behavior, trust policy, and resulting app session or privilege in one chain.
|
||||
5. Reproduce the smallest token-to-acceptance flow that proves the decisive confusion.
|
||||
|
||||
## Workflow
|
||||
|
||||
### 1. Map Header And Key Selection
|
||||
|
||||
- Record header fields such as `alg`, `kid`, `typ`, `cty`, `jku`, or embedded key material when present.
|
||||
- Note where keys come from: static config, JWKS, local file, cache, or dynamic lookup.
|
||||
- Keep token parser, key selection path, and validation mode tied together.
|
||||
|
||||
### 2. Prove Claim-To-Privilege Acceptance
|
||||
|
||||
- Show how subject, audience, issuer, tenant, scope, role, or custom claims become app session, route access, or backend privilege.
|
||||
- Record expiration, not-before, clock skew, issuer matching, audience matching, and claim normalization behavior.
|
||||
- Distinguish token parse success from actual authorization success.
|
||||
|
||||
### 3. Reduce To The Decisive JWT Path
|
||||
|
||||
- Compress the result to the smallest sequence: token supplied -> parser or key path taken -> claim accepted -> resulting capability.
|
||||
- Keep one canonical accepted token path and one mutated token path if confusion or bypass depends on a delta.
|
||||
- If the task broadens into a larger OAuth redirect chain, hand back to the tighter OAuth skill.
|
||||
|
||||
## Read This Reference
|
||||
|
||||
- Load `references/jwt-claim-confusion.md` for the header checklist, claim checklist, and evidence packaging.
|
||||
|
||||
## What To Preserve
|
||||
|
||||
- Raw headers, claims, key source, JWKS or local key path, and the accepting service
|
||||
- The exact validation or normalization step that turns the token into accepted identity
|
||||
- One minimal replayable token-to-acceptance sequence
|
||||
@@ -0,0 +1,7 @@
|
||||
interface:
|
||||
display_name: "Competition Jwt Claim Confusion"
|
||||
short_description: "Trace JWT headers, claims, key selection, and acceptance logic"
|
||||
default_prompt: "After $ctf-sandbox-orchestrator is active, use $competition-jwt-claim-confusion to trace JWT headers, claims, key lookup, validation decisions, and the point where a token becomes accepted identity."
|
||||
|
||||
policy:
|
||||
allow_implicit_invocation: false
|
||||
+27
@@ -0,0 +1,27 @@
|
||||
# JWT Claim Confusion Checklist
|
||||
|
||||
## First Pass
|
||||
|
||||
- Token form: JWS, JWE, nested token, detached signature, or bearer wrapper
|
||||
- Header fields: `alg`, `kid`, `typ`, `cty`, `jku`, x5u-like references, embedded keys
|
||||
- Claim fields: `iss`, `aud`, `sub`, `exp`, `nbf`, `iat`, tenant, role, scope, custom privilege claims
|
||||
|
||||
## Validation Chain To Reconstruct
|
||||
|
||||
1. Token parser invoked
|
||||
2. Key source selected
|
||||
3. Signature or decryption step performed
|
||||
4. Claim validation and normalization applied
|
||||
5. App session or privilege accepted
|
||||
|
||||
## Evidence To Keep Together
|
||||
|
||||
- Header side: fields, key source, lookup behavior, cache or remote key material
|
||||
- Claim side: issuer, audience, subject, roles, scopes, time claims, normalization rules
|
||||
- Acceptance side: session cookie, route unlock, backend action, or privilege-bearing claim usage
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
- Stopping at successful decode without proving authorization acceptance
|
||||
- Focusing on one claim without showing the whole validation chain
|
||||
- Ignoring key lookup or normalization behavior that matters more than the raw claim value
|
||||
@@ -0,0 +1,51 @@
|
||||
---
|
||||
name: competition-k8s-control-plane
|
||||
description: Internal downstream skill for ctf-sandbox-orchestrator. CTF-sandbox workflow for Kubernetes API analysis, service-account trust, RBAC edges, admission and controller behavior, cluster secrets, workload mutation, and namespace-scoped drift. Use when the user asks to inspect kube API permissions, service-account tokens, RoleBinding or ClusterRoleBinding edges, admission webhooks, controller-created pods, secret exposure, or why live workloads differ from manifests. Use only after `$ctf-sandbox-orchestrator` has already established sandbox assumptions and routed here.
|
||||
---
|
||||
|
||||
# Competition K8s Control Plane
|
||||
|
||||
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 path runs through Kubernetes control-plane state, API permissions, or controller behavior rather than a single container's runtime alone.
|
||||
|
||||
Reply in Simplified Chinese unless the user explicitly requests English.
|
||||
|
||||
## Quick Start
|
||||
|
||||
1. Separate manifest intent from live cluster state: API objects, mutations, controllers, secrets, and resulting workloads.
|
||||
2. Identify the active principal first: service account, kubeconfig identity, node credential, webhook, or controller.
|
||||
3. Map the smallest control-plane edge to its workload effect.
|
||||
4. Keep RBAC, service accounts, owner references, namespace boundaries, and secret consumers in compact evidence blocks.
|
||||
5. Reproduce the smallest cluster action that yields the decisive workload or secret effect.
|
||||
|
||||
## Workflow
|
||||
|
||||
### 1. Map The API Trust Path
|
||||
|
||||
- Record namespaces, service accounts, Roles, ClusterRoles, bindings, admission hooks, controllers, and the resources they can mutate.
|
||||
- Distinguish read access, create access, patch access, exec access, and secret access.
|
||||
- Keep principal, verb, resource, namespace, and resulting object in one chain.
|
||||
|
||||
### 2. Trace Mutation To Workload State
|
||||
|
||||
- Show how an API action becomes a pod, volume mount, secret exposure, env injection, job run, or controller-created artifact.
|
||||
- Compare checked-in YAML against live objects after defaulting, admission mutation, or controller reconciliation.
|
||||
- Distinguish pod-runtime behavior from cluster-level mutation logic.
|
||||
|
||||
### 3. Reduce To The Decisive Cluster Path
|
||||
|
||||
- Compress the result to the smallest chain: principal -> API permission -> mutated object -> resulting workload, secret, or route effect.
|
||||
- Keep kube objects, live describes, and consumed secret or config paths tied to the same namespace and controller.
|
||||
- If the problem narrows down to one container's mount or runtime deviation, switch back to the tighter container-runtime skill.
|
||||
|
||||
## Read This Reference
|
||||
|
||||
- Load `references/k8s-control-plane.md` for the RBAC checklist, controller checklist, and evidence packaging.
|
||||
- If the hard part is metadata-service reachability, workload identity, instance credentials, or metadata-derived privilege, prefer `$competition-cloud-metadata-path`.
|
||||
|
||||
## What To Preserve
|
||||
|
||||
- Namespace, service account, verb, resource kind, RoleBinding or ClusterRoleBinding, and owner reference chains
|
||||
- Admission mutations, generated workloads, mounted secrets, and controller-produced drift
|
||||
- The exact API action or object diff that creates the decisive effect
|
||||
@@ -0,0 +1,7 @@
|
||||
interface:
|
||||
display_name: "Competition K8s Control Plane"
|
||||
short_description: "Trace kube API, service accounts, secrets, and workload drift"
|
||||
default_prompt: "After $ctf-sandbox-orchestrator is active, use $competition-k8s-control-plane to trace this Kubernetes control-plane path, service-account edge, secret exposure, or workload drift in the sandbox."
|
||||
|
||||
policy:
|
||||
allow_implicit_invocation: false
|
||||
+27
@@ -0,0 +1,27 @@
|
||||
# K8s Control Plane Checklist
|
||||
|
||||
## First Pass
|
||||
|
||||
- Namespaces, service accounts, kubeconfigs, tokens, Roles, ClusterRoles, bindings
|
||||
- Admission webhooks, mutating or validating policy, controllers, operators, CRDs
|
||||
- Secrets, ConfigMaps, projected volumes, generated Jobs, and owner references
|
||||
|
||||
## Trust Chain To Reconstruct
|
||||
|
||||
1. Principal or token identified
|
||||
2. RBAC or admission edge established
|
||||
3. Object create, patch, or read action performed
|
||||
4. Controller or scheduler turns object into workload state
|
||||
5. Secret, route, workload, or artifact effect observed
|
||||
|
||||
## Evidence To Keep Together
|
||||
|
||||
- Principal side: service account, token source, namespace, binding, verb, resource
|
||||
- Mutation side: object manifest, admission change, controller output, owner refs
|
||||
- Effect side: mounted secret, env var, spawned pod, reachable route, or recovered artifact
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
- Stopping at a RoleBinding without proving the resulting API action
|
||||
- Explaining pod behavior without showing which cluster object created it
|
||||
- Mixing static YAML and live cluster objects without accounting for admission or controller drift
|
||||
@@ -0,0 +1,47 @@
|
||||
---
|
||||
name: competition-kerberos-delegation
|
||||
description: Internal downstream skill for ctf-sandbox-orchestrator. CTF-sandbox workflow for Kerberos delegation, SPN trust edges, S4U abuse, RBCD, constrained or unconstrained delegation, and service-ticket acceptance. Use when the user asks about constrained delegation, unconstrained delegation, RBCD, S4U, SPNs, ticket acceptance, or how a Kerberos trust edge turns into effective privilege under sandbox assumptions. Use only after `$ctf-sandbox-orchestrator` has already established sandbox assumptions and routed here.
|
||||
---
|
||||
|
||||
# Competition Kerberos Delegation
|
||||
|
||||
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 hard part is not "is there Kerberos here," but which delegation edge exists, which ticket is being minted, and which service really accepts it.
|
||||
|
||||
Reply in Simplified Chinese unless the user explicitly requests English.
|
||||
|
||||
## Quick Start
|
||||
|
||||
1. Write the trust chain first: principal -> delegation edge -> ticket type -> target SPN -> accepting service -> resulting privilege.
|
||||
2. Separate ticket possession from accepted privilege.
|
||||
3. Keep SPNs, delegation mode, PAC/group data, encryption type, and service acceptance in one compact evidence block.
|
||||
4. Reproduce one minimal delegation chain before broadening into variants.
|
||||
5. Tie every privilege claim to a specific accepted ticket or service-side effect.
|
||||
|
||||
## Workflow
|
||||
|
||||
### 1. Identify The Delegation Edge
|
||||
|
||||
- Determine whether the path is constrained delegation, unconstrained delegation, resource-based constrained delegation, protocol transition, or another trust edge.
|
||||
- Inspect SPNs, ACLs, service accounts, SIDHistory, certificate templates, and replication rights only when they affect the active path.
|
||||
|
||||
### 2. Trace Ticket Minting And Acceptance
|
||||
|
||||
- Record TGT/TGS type, S4U steps when relevant, delegation flags, PAC or group data, encryption type, cache location, and target SPN.
|
||||
- Prove which service actually accepts the ticket and what capability appears after acceptance.
|
||||
|
||||
### 3. Report The Effective Edge
|
||||
|
||||
- Compress the chain into one replayable path, not a vague "domain compromise" statement.
|
||||
- Separate candidate edges from the edge that really lands privilege.
|
||||
|
||||
## Read This Reference
|
||||
|
||||
- Load `references/kerberos-delegation.md` for the delegation checklist, ticket fields to preserve, and common proof mistakes.
|
||||
|
||||
## What To Preserve
|
||||
|
||||
- SPN, ticket type, delegation mode, PAC/group data, encryption type, cache location, accepting service
|
||||
- Service-side logs, event IDs, logon session changes, or group changes proving effective privilege
|
||||
- The exact trust edge that makes the ticket replayable
|
||||
@@ -0,0 +1,7 @@
|
||||
interface:
|
||||
display_name: "Competition Kerberos Delegation"
|
||||
short_description: "Trace S4U, RBCD, delegation edges, and ticket acceptance"
|
||||
default_prompt: "After $ctf-sandbox-orchestrator is active, use $competition-kerberos-delegation to trace delegation edges, minted tickets, and the service that accepts them."
|
||||
|
||||
policy:
|
||||
allow_implicit_invocation: false
|
||||
+35
@@ -0,0 +1,35 @@
|
||||
# Kerberos Delegation Checklist
|
||||
|
||||
## Write The Chain Explicitly
|
||||
|
||||
- source principal
|
||||
- delegation edge
|
||||
- ticket minted or transformed
|
||||
- target SPN
|
||||
- accepting service
|
||||
- resulting privilege
|
||||
|
||||
## Ticket Fields To Preserve
|
||||
|
||||
- TGT or TGS type
|
||||
- SPN
|
||||
- delegation mode
|
||||
- S4U step if present
|
||||
- PAC or group data
|
||||
- encryption type
|
||||
- cache location
|
||||
- accepting service
|
||||
|
||||
## Trust Edges To Inspect
|
||||
|
||||
- constrained delegation
|
||||
- unconstrained delegation
|
||||
- resource-based constrained delegation
|
||||
- protocol transition
|
||||
- SIDHistory or ACL-based privilege edges when they affect ticket usability
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
- Treating a minted ticket as proof of accepted privilege
|
||||
- Reporting the delegation mode without naming the accepting service
|
||||
- Expanding into every AD edge before one replayable chain is proven
|
||||
@@ -0,0 +1,50 @@
|
||||
---
|
||||
name: competition-kernel-container-escape
|
||||
description: Internal downstream skill for ctf-sandbox-orchestrator. CTF-sandbox workflow for kernel attack surface, namespace and cgroup boundaries, container isolation assumptions, syscall paths, and escape primitive verification. Use when the user asks to analyze container-to-host escape paths, kernel exploit prerequisites, namespace crossover, capability misuse, or prove whether an exploit primitive crosses the sandbox boundary. Use only after `$ctf-sandbox-orchestrator` has already established sandbox assumptions and routed here.
|
||||
---
|
||||
|
||||
# Competition Kernel Container Escape
|
||||
|
||||
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 step is proving a boundary crossing between containerized context and host or higher-privilege kernel context.
|
||||
|
||||
Reply in Simplified Chinese unless the user explicitly requests English.
|
||||
|
||||
## Quick Start
|
||||
|
||||
1. Map runtime isolation first: namespaces, cgroups, seccomp, capabilities, LSM, and mount boundaries.
|
||||
2. Separate exploit prerequisite, primitive, and boundary-crossing proof.
|
||||
3. Record kernel version, config hints, runtime options, and reachable syscall surface.
|
||||
4. Keep instrumented observations separate from pristine challenge path.
|
||||
5. Reproduce one minimal primitive-to-boundary-crossing chain.
|
||||
|
||||
## Workflow
|
||||
|
||||
### 1. Map Isolation And Kernel Surface
|
||||
|
||||
- Record namespace map, cgroup mode, capabilities, seccomp profile, AppArmor or SELinux state, mounted filesystems, and runtime sockets.
|
||||
- Note kernel version, distro build hints, module exposure, and container runtime behavior.
|
||||
- Keep host and container observations linked to exact node and context.
|
||||
|
||||
### 2. Prove Exploit Primitive And Crossover
|
||||
|
||||
- Show controllable input, trigger condition, affected object, and observable kernel or runtime state change.
|
||||
- Capture before and after identity, namespace, mount, or process visibility to prove boundary crossing.
|
||||
- Distinguish crash-only behavior from stable capability gain.
|
||||
|
||||
### 3. Reduce To Decisive Escape Chain
|
||||
|
||||
- Compress to: prerequisite state -> primitive trigger -> boundary crossing evidence -> resulting host-level capability.
|
||||
- State whether root cause is kernel vulnerability, runtime misconfiguration, capability overgrant, or namespace leak.
|
||||
- If path relies mostly on credential replay after initial foothold, hand off to Linux credential pivot skill.
|
||||
|
||||
## Read This Reference
|
||||
|
||||
- Load `references/kernel-container-escape.md` for isolation checklist, primitive checklist, and parity guidance.
|
||||
|
||||
## What To Preserve
|
||||
|
||||
- Kernel and runtime context, capability set, seccomp or LSM state, and namespace map
|
||||
- Primitive trigger data, boundary crossing evidence, and resulting capability
|
||||
- One minimal reproducible chain from container context to host-relevant effect
|
||||
@@ -0,0 +1,7 @@
|
||||
interface:
|
||||
display_name: "Competition Kernel Container Escape"
|
||||
short_description: "Map kernel and container boundaries to prove escape primitives"
|
||||
default_prompt: "After $ctf-sandbox-orchestrator is active, use $competition-kernel-container-escape to map kernel and container boundaries and prove the decisive escape primitive."
|
||||
|
||||
policy:
|
||||
allow_implicit_invocation: false
|
||||
+27
@@ -0,0 +1,27 @@
|
||||
# Kernel Container Escape Checklist
|
||||
|
||||
## First Pass
|
||||
|
||||
- Kernel version, runtime type, namespace map, cgroup mode, capability set
|
||||
- Seccomp profile, AppArmor or SELinux mode, mounts, privileged sockets
|
||||
- Potential primitives: syscall path, fs boundary, runtime API, namespace leak
|
||||
|
||||
## Chain To Reconstruct
|
||||
|
||||
1. Isolation baseline recorded
|
||||
2. Exploit or misconfig primitive triggered
|
||||
3. Boundary crossover evidence captured
|
||||
4. Host-relevant capability appears
|
||||
5. Chain reproduces from reset baseline
|
||||
|
||||
## Evidence To Keep Together
|
||||
|
||||
- Context side: kernel and runtime config, namespace and capability state
|
||||
- Primitive side: controllable input, trigger, affected object, observables
|
||||
- Effect side: identity change, host visibility, privileged action, persistence edge
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
- Treating container root as host compromise without crossover proof
|
||||
- Mixing several primitives before proving one decisive chain
|
||||
- Claiming escape from crash artifacts without stable capability evidence
|
||||
@@ -0,0 +1,50 @@
|
||||
---
|
||||
name: competition-linux-credential-pivot
|
||||
description: Internal downstream skill for ctf-sandbox-orchestrator. CTF-sandbox workflow for Linux credential artifacts, service tokens, SSH material, cloud and container secrets, socket-level trust, and host-to-host pivot chains. Use when the user asks to trace Linux auth artifacts, accepted token or key replay, socket or service-account trust edges, sudo or capability abuse, or explain lateral movement across Linux challenge nodes. Use only after `$ctf-sandbox-orchestrator` has already established sandbox assumptions and routed here.
|
||||
---
|
||||
|
||||
# Competition Linux Credential Pivot
|
||||
|
||||
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 edge is Linux credential material and where that material is accepted.
|
||||
|
||||
Reply in Simplified Chinese unless the user explicitly requests English.
|
||||
|
||||
## Quick Start
|
||||
|
||||
1. Separate credential storage from accepted privilege.
|
||||
2. Record user, process, namespace, socket, key file, and service trust boundary before conclusions.
|
||||
3. Keep artifact recovery, replay path, and resulting capability in one chain.
|
||||
4. Distinguish local escalation from lateral host pivot.
|
||||
5. Reproduce one minimal artifact-to-accepted-access path.
|
||||
|
||||
## Workflow
|
||||
|
||||
### 1. Map Credential And Trust Artifacts
|
||||
|
||||
- Record SSH keys, agent sockets, kubeconfigs, cloud tokens, service-account secrets, env vars, config files, and process memory clues.
|
||||
- Note sudoers rules, capabilities, setuid binaries, systemd unit context, and namespace boundaries.
|
||||
- Keep each artifact tied to owner, scope, and expected accepting service.
|
||||
|
||||
### 2. Prove Replay And Pivot
|
||||
|
||||
- Show where key, token, socket, or secret is accepted: SSH, API, Unix socket, container runtime, or control-plane endpoint.
|
||||
- Record host target, protocol, principal, and resulting session or privilege.
|
||||
- Distinguish authentication success from useful capability gain.
|
||||
|
||||
### 3. Reduce To Decisive Linux Pivot Chain
|
||||
|
||||
- Compress to: recovered artifact -> accepted replay path -> pivot host or privilege transition -> resulting capability.
|
||||
- State whether root cause is weak key handling, token leakage, socket trust, sudo or capability abuse, or namespace crossover.
|
||||
- If the chain pivots into kernel exploit boundaries, hand off to kernel container escape skill.
|
||||
|
||||
## Read This Reference
|
||||
|
||||
- Load `references/linux-credential-pivot.md` for artifact checklists, replay matrix, and evidence packaging.
|
||||
|
||||
## What To Preserve
|
||||
|
||||
- Artifact path, owner, scope, accepting service, and resulting principal
|
||||
- Exact pivot order with protocol and target host or namespace
|
||||
- One minimal replayable chain proving capability gain
|
||||
@@ -0,0 +1,7 @@
|
||||
interface:
|
||||
display_name: "Competition Linux Credential Pivot"
|
||||
short_description: "Trace Linux creds, tokens, sockets, and host-to-host pivots"
|
||||
default_prompt: "After $ctf-sandbox-orchestrator is active, use $competition-linux-credential-pivot to trace Linux credential artifacts, accepted replay points, and pivot chains."
|
||||
|
||||
policy:
|
||||
allow_implicit_invocation: false
|
||||
+27
@@ -0,0 +1,27 @@
|
||||
# Linux Credential Pivot Checklist
|
||||
|
||||
## First Pass
|
||||
|
||||
- SSH keys, agent sockets, kubeconfigs, cloud tokens, service-account secrets
|
||||
- Env vars, config files, systemd units, sudoers, capabilities, setuid binaries
|
||||
- Namespace context, container runtime sockets, control-plane endpoints
|
||||
|
||||
## Chain To Reconstruct
|
||||
|
||||
1. Credential artifact recovered
|
||||
2. Accepting service identified
|
||||
3. Replay or auth path executed
|
||||
4. New session, token, or privilege gained
|
||||
5. Pivot or lateral effect reproduced
|
||||
|
||||
## Evidence To Keep Together
|
||||
|
||||
- Artifact side: file or socket path, owner, scope, lifetime
|
||||
- Replay side: target host, service, protocol, principal
|
||||
- Effect side: privilege change, new shell, control-plane action, lateral movement
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
- Listing secrets without proving acceptance on a target service
|
||||
- Mixing local privilege escalation and lateral movement in one vague chain
|
||||
- Ignoring namespace or socket ownership context
|
||||
@@ -0,0 +1,51 @@
|
||||
---
|
||||
name: competition-lsass-ticket-material
|
||||
description: 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.
|
||||
---
|
||||
|
||||
# Competition LSASS Ticket Material
|
||||
|
||||
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 host artifact lives in LSASS, ticket caches, or adjacent credential material and the hard part is proving what is replayable.
|
||||
|
||||
Reply in Simplified Chinese unless the user explicitly requests English.
|
||||
|
||||
## Quick Start
|
||||
|
||||
1. Separate raw credential material from actually usable replay edges.
|
||||
2. Record logon session, LUID, ticket cache, package, account, and target service before broad conclusions.
|
||||
3. Keep host artifact, extracted secret, replay attempt, and resulting acceptance in one chain.
|
||||
4. Distinguish password, hash, ticket, DPAPI secret, SSP residue, and token by where each can actually be used.
|
||||
5. Reproduce the smallest host-artifact-to-accepted-privilege path that proves the decisive edge.
|
||||
|
||||
## Workflow
|
||||
|
||||
### 1. Map LSASS And Adjacent Credential State
|
||||
|
||||
- Record logon sessions, LUIDs, ticket caches, package names, SSPs, DPAPI context, and any service-account material tied to the active path.
|
||||
- Note whether the decisive value is a TGT, service ticket, delegated ticket, DPAPI secret, plaintext, hash, or package-specific secret.
|
||||
- Keep host source, account context, and cache location tied together.
|
||||
|
||||
### 2. Prove Replay Or Acceptance
|
||||
|
||||
- Show where the extracted material is accepted: SMB, WinRM, service ticket use, DPAPI unwrap, Schannel, or another host or service edge.
|
||||
- Record SPN, target host, logon session, ticket flags, encryption type, and resulting privilege or token change.
|
||||
- Distinguish material that is present from material that is actually replayable in this path.
|
||||
|
||||
### 3. Reduce To The Decisive Credential Chain
|
||||
|
||||
- Compress the result to the smallest sequence: host artifact -> extracted material -> accepted replay or unwrap -> resulting capability.
|
||||
- State clearly whether the decisive edge lives in LSASS memory, ticket cache reuse, DPAPI context, or accepting service behavior.
|
||||
- If the task broadens into full host-to-host pivoting, hand back to the tighter Windows pivot skill.
|
||||
|
||||
## Read This Reference
|
||||
|
||||
- Load `references/lsass-ticket-material.md` for the session checklist, replay checklist, and evidence packaging.
|
||||
- If the task is specifically about DPAPI masterkeys, protected blobs, browser or vault stores, or proving which recovered DPAPI secret is accepted, prefer `$competition-dpapi-credential-chain`.
|
||||
|
||||
## What To Preserve
|
||||
|
||||
- LUIDs, session IDs, ticket types, SPNs, encryption types, package names, and cache or memory source
|
||||
- The exact accepting host or service and the resulting privilege or logon effect
|
||||
- One minimal host-artifact-to-replay sequence that proves the edge
|
||||
@@ -0,0 +1,7 @@
|
||||
interface:
|
||||
display_name: "Competition Lsass Ticket Material"
|
||||
short_description: "Trace LSASS secrets, tickets, caches, and replayable material"
|
||||
default_prompt: "After $ctf-sandbox-orchestrator is active, use $competition-lsass-ticket-material to trace LSASS-resident secrets, ticket material, cache artifacts, and the replayable credential edge in this challenge."
|
||||
|
||||
policy:
|
||||
allow_implicit_invocation: false
|
||||
+27
@@ -0,0 +1,27 @@
|
||||
# LSASS Ticket Material Checklist
|
||||
|
||||
## First Pass
|
||||
|
||||
- Logon sessions, LUIDs, package names, ticket caches, SSP artifacts, DPAPI context, account names
|
||||
- Material types: plaintext, NTLM hash, TGT, service ticket, delegated ticket, DPAPI secret, gMSA material
|
||||
- Acceptance candidates: SMB, WinRM, service ticket use, Schannel, DPAPI unwrap, service logon
|
||||
|
||||
## Chain To Reconstruct
|
||||
|
||||
1. Host or memory artifact located
|
||||
2. Credential or ticket material extracted
|
||||
3. Replay or unwrap path identified
|
||||
4. Service or host accepts it
|
||||
5. Resulting logon, token, or privilege confirmed
|
||||
|
||||
## Evidence To Keep Together
|
||||
|
||||
- Host side: process, dump or cache source, LUID, package, account
|
||||
- Material side: type, ticket flags, SPN, encryption, DPAPI context, cache location
|
||||
- Acceptance side: target service, target host, resulting session or privilege change
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
- Treating every extracted secret as replayable without proving an accepting service
|
||||
- Mixing several logon sessions and ticket caches into one vague story
|
||||
- Describing ticket presence without tying it to a concrete privilege or pivot edge
|
||||
@@ -0,0 +1,50 @@
|
||||
---
|
||||
name: competition-mailbox-abuse
|
||||
description: Internal downstream skill for ctf-sandbox-orchestrator. CTF-sandbox workflow for enterprise mail abuse, OAuth consent, inbox or forwarding rules, transport rules, shared mailbox access, phishing chains, and token-to-mailbox side effects. Use when the user asks to trace mailbox rules, OAuth consent grants, forwarding or delegate abuse, shared mailbox access, message-trace evidence, or explain how mail artifacts turn into persistence, exfiltration, or privilege. Use only after `$ctf-sandbox-orchestrator` has already established sandbox assumptions and routed here.
|
||||
---
|
||||
|
||||
# Competition Mailbox Abuse
|
||||
|
||||
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 path runs through mailbox behavior, consent flow, or message-routing effects rather than generic AD evidence alone.
|
||||
|
||||
Reply in Simplified Chinese unless the user explicitly requests English.
|
||||
|
||||
## Quick Start
|
||||
|
||||
1. Decide whether the active path is phishing-to-consent, token-to-mailbox, rule-based persistence, or transport-level mail rerouting.
|
||||
2. Keep mailbox evidence, identity evidence, and message-trace evidence tied to the same user, mailbox, token, or message ID.
|
||||
3. Separate possession of a token or delegate edge from the actual mailbox effect it enables.
|
||||
4. Record forwarding targets, rule predicates, consent scopes, shared mailbox edges, and resulting mail flow in compact blocks.
|
||||
5. Reproduce the smallest mail effect that proves persistence, exfiltration, or privilege.
|
||||
|
||||
## Workflow
|
||||
|
||||
### 1. Map The Mail Trust Path
|
||||
|
||||
- Identify the principal, mailbox, token or session, consent grant, delegate edge, shared mailbox relationship, or app registration involved.
|
||||
- Record consent scopes, mailbox permissions, rule ownership, transport actions, and message-trace identifiers.
|
||||
- Distinguish client-visible symptoms from server-side mailbox or transport state.
|
||||
|
||||
### 2. Prove The Mailbox Effect
|
||||
|
||||
- Correlate consent logs, sign-ins, message traces, inbox rules, transport rules, forwarding settings, and mailbox audit events.
|
||||
- Show which rule or token produces which concrete effect: silent forwarding, marking read, deletion, delegate access, or message rerouting.
|
||||
- Keep message IDs, sender or recipient pairs, and timestamps aligned across logs.
|
||||
|
||||
### 3. Reduce To The Decisive Abuse Chain
|
||||
|
||||
- Compress the path to the smallest sequence: lure or grant -> token or delegate edge -> mailbox or transport mutation -> resulting mail effect.
|
||||
- State clearly whether persistence lives in consent, mailbox rules, transport config, or shared mailbox permissions.
|
||||
- If the task broadens into host pivots or Kerberos acceptance, switch back to the broader identity skill.
|
||||
|
||||
## Read This Reference
|
||||
|
||||
- Load `references/mailbox-abuse.md` for the consent checklist, rule checklist, and evidence packaging.
|
||||
|
||||
## What To Preserve
|
||||
|
||||
- Consent scopes, token claims, mailbox permissions, rule definitions, forwarding targets, and message IDs
|
||||
- Message-trace lines, audit events, and mailbox effects tied to the same mail path
|
||||
- The smallest replayable sequence that proves persistence, exfiltration, or delegate access
|
||||
@@ -0,0 +1,7 @@
|
||||
interface:
|
||||
display_name: "Competition Mailbox Abuse"
|
||||
short_description: "Trace mailbox rules, OAuth consent, and mail-flow abuse"
|
||||
default_prompt: "After $ctf-sandbox-orchestrator is active, use $competition-mailbox-abuse to trace how mailbox rules, OAuth consent, forwarding, or transport actions create the decisive mail-flow effect."
|
||||
|
||||
policy:
|
||||
allow_implicit_invocation: false
|
||||
@@ -0,0 +1,26 @@
|
||||
# Mailbox Abuse Checklist
|
||||
|
||||
## Core Surfaces
|
||||
|
||||
- Consent grants, app registrations, delegated or application scopes, sign-in events
|
||||
- Inbox rules, forwarding settings, delegate access, shared mailbox permissions, transport rules
|
||||
- Message traces, mailbox audit events, sender or recipient pairs, message IDs, folder actions
|
||||
|
||||
## Abuse Chain To Reconstruct
|
||||
|
||||
1. Lure, consent, or credential acquisition
|
||||
2. Token or delegate edge obtained
|
||||
3. Mailbox or transport mutation applied
|
||||
4. Message flow altered, hidden, or exfiltrated
|
||||
|
||||
## Evidence To Keep Together
|
||||
|
||||
- Identity side: user, app, scope, token claim, delegate edge
|
||||
- Mail side: rule predicate, forward target, folder action, message ID, transport action
|
||||
- Result side: delivered, forwarded, deleted, rerouted, or silently hidden effect
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
- Reporting a token without showing the mailbox effect it actually enables
|
||||
- Mixing inbox rules and transport rules without proving which one caused the observed message flow
|
||||
- Ignoring shared mailbox or delegate permissions when the mailbox owner itself never logged in
|
||||
@@ -0,0 +1,49 @@
|
||||
---
|
||||
name: competition-malware-config
|
||||
description: Internal downstream skill for ctf-sandbox-orchestrator. CTF-sandbox workflow for malware configuration recovery, staged payload boundaries, beacon parameter extraction, and IOC decoding. Use when the user asks to recover a malware config, decode C2 or beacon fields, unpack staged payloads, extract bot or campaign IDs, or tie recovered config to observed protocol behavior under sandbox assumptions. Use only after `$ctf-sandbox-orchestrator` has already established sandbox assumptions and routed here.
|
||||
---
|
||||
|
||||
# Competition Malware Config
|
||||
|
||||
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 value is not just "what the sample does," but which config fields, stages, or network parameters the sample hides and when they become plaintext.
|
||||
|
||||
Reply in Simplified Chinese unless the user explicitly requests English.
|
||||
|
||||
## Quick Start
|
||||
|
||||
1. Preserve the original sample before unpacking or patching.
|
||||
2. Separate loader, payload, config blob, and post-decode behavior.
|
||||
3. Rank candidate config blobs by entropy, field shape, nearby strings, and decode helpers.
|
||||
4. Record the exact transform chain for each recovered field.
|
||||
5. Reproduce the decoded config or beacon parameters from the smallest possible path.
|
||||
|
||||
## Workflow
|
||||
|
||||
### 1. Find The Config Boundary
|
||||
|
||||
- Inspect sections, resources, embedded archives, strings, imports, and decode helpers.
|
||||
- Identify where config is stored: resource, overlay, encrypted blob, registry seed, network bootstrap, or stage2 memory.
|
||||
- Keep one note of when each value becomes plaintext.
|
||||
|
||||
### 2. Reconstruct The Decode Chain
|
||||
|
||||
- Recover the chain in order: container -> compression -> encoding -> xor/substitution -> crypto -> parse.
|
||||
- Group all config fields from the same chain together instead of treating them as unrelated clues.
|
||||
- Preserve hashes, offsets, keys, IVs, masks, and parsed fields in one compact evidence block.
|
||||
|
||||
### 3. Tie Config To Behavior
|
||||
|
||||
- Show which field affects which branch: beacon path, mutex, wallet, bot id, campaign, tasking route, persistence name, or process target.
|
||||
- Correlate decoded config with PCAPs, process trees, or stage2 strings when possible.
|
||||
|
||||
## Read This Reference
|
||||
|
||||
- Load `references/malware-config.md` for the config-hunting checklist, staged-sample checklist, and evidence packaging rules.
|
||||
|
||||
## What To Preserve
|
||||
|
||||
- Original artifact, unpacked layer, dumped stage, and parsed config as separate artifacts
|
||||
- Offsets, hashes, decode helpers, keys, masks, and field names
|
||||
- The branch or protocol step each recovered field actually influences
|
||||
@@ -0,0 +1,7 @@
|
||||
interface:
|
||||
display_name: "Competition Malware Config"
|
||||
short_description: "Recover staged configs, beacon fields, and plaintext boundaries"
|
||||
default_prompt: "After $ctf-sandbox-orchestrator is active, use $competition-malware-config to recover the hidden config, staging layers, bot IDs, or beacon parameters from this sample."
|
||||
|
||||
policy:
|
||||
allow_implicit_invocation: false
|
||||
@@ -0,0 +1,36 @@
|
||||
# Malware Config And Staging Checklist
|
||||
|
||||
## Hunt For The Config Boundary
|
||||
|
||||
- Resources, overlays, embedded archives, section anomalies, decode helpers, registry seeds, bootstrap responses, stage2 memory
|
||||
- Nearby markers: URLs, mutex seeds, wallet-like strings, campaign IDs, bot IDs, task routes, persistence names
|
||||
|
||||
## Reconstruct The Transform Chain
|
||||
|
||||
Track in order:
|
||||
|
||||
1. Container or embedded layer
|
||||
2. Compression or chunking
|
||||
3. Encoding or substitution
|
||||
4. XOR or custom masks
|
||||
5. Crypto
|
||||
6. Final parse into fields
|
||||
|
||||
## Tie Fields To Behavior
|
||||
|
||||
- Beacon path or host -> network flow
|
||||
- Mutex or install path -> persistence branch
|
||||
- Campaign or bot id -> server-side routing or tasking
|
||||
- Wallet or key material -> downstream protocol or decryption branch
|
||||
|
||||
## Evidence To Keep
|
||||
|
||||
- One compact block for offsets, hashes, decode helpers, keys, masks
|
||||
- One compact block for parsed fields and what branch each field affects
|
||||
- Original, unpacked, dumped, and parsed outputs kept as separate artifacts
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
- Treating one IOC-looking string as the config without proving the full chain
|
||||
- Mixing fields from separate decode paths as if they came from one blob
|
||||
- Forgetting to prove where config becomes plaintext
|
||||
@@ -0,0 +1,51 @@
|
||||
---
|
||||
name: competition-oauth-oidc-chain
|
||||
description: Internal downstream skill for ctf-sandbox-orchestrator. CTF-sandbox workflow for OAuth, OIDC, redirect flows, state or nonce handling, PKCE, token exchange, refresh logic, claim mapping, and accepted login paths. Use when the user asks to trace redirects, callback parameters, scopes, state, nonce, PKCE, refresh tokens, consent, or explain how an OAuth or OIDC chain turns into accepted identity or privilege. Use only after `$ctf-sandbox-orchestrator` has already established sandbox assumptions and routed here.
|
||||
---
|
||||
|
||||
# Competition OAuth OIDC Chain
|
||||
|
||||
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 hard part is proving how an OAuth or OIDC flow is shaped, exchanged, and ultimately accepted.
|
||||
|
||||
Reply in Simplified Chinese unless the user explicitly requests English.
|
||||
|
||||
## Quick Start
|
||||
|
||||
1. Map the auth chain in order: entry route, redirect, authorize request, callback, token exchange, refresh, and final accepting service.
|
||||
2. Record scopes, state, nonce, PKCE material, redirect URIs, and claim-bearing tokens before mutating anything.
|
||||
3. Separate token possession from actual identity acceptance.
|
||||
4. Keep browser-visible redirects and backend-visible token exchange in one compact chain.
|
||||
5. Reproduce the smallest redirect-to-acceptance flow that proves the decisive identity edge.
|
||||
|
||||
## Workflow
|
||||
|
||||
### 1. Map The Redirect And Token Path
|
||||
|
||||
- Record issuer, client ID, redirect URI, authorize parameters, callback parameters, token endpoint, and refresh path.
|
||||
- Note which values are user-controlled, derived, cached, or validated: `state`, `nonce`, PKCE verifier, audience, scope, or prompt.
|
||||
- Keep browser redirects, server-side exchanges, and resulting session state tied together.
|
||||
|
||||
### 2. Prove Token-To-Identity Acceptance
|
||||
|
||||
- Show how code, ID token, access token, or refresh token turns into app session, claims mapping, tenant selection, or accepted privilege.
|
||||
- Record token claims, expiration, audience, subject, scopes, and the exact accepting app or backend edge.
|
||||
- Distinguish UI login success from backend authorization success.
|
||||
|
||||
### 3. Reduce To The Decisive OAuth Chain
|
||||
|
||||
- Compress the result to the smallest sequence: entry request -> redirect -> callback -> token or claim acceptance -> resulting capability.
|
||||
- Keep one canonical good flow and one minimal mutated flow if a parameter change matters.
|
||||
- If the task broadens into generic web routing or storage behavior outside the auth chain, switch back to the broader web-runtime skill.
|
||||
|
||||
## Read This Reference
|
||||
|
||||
- Load `references/oauth-oidc-chain.md` for the redirect checklist, token checklist, and evidence packaging.
|
||||
- If the hard part is JWT header parsing, claim normalization, key lookup, or token validation confusion after issuance, prefer `$competition-jwt-claim-confusion`.
|
||||
|
||||
## What To Preserve
|
||||
|
||||
- Redirect URIs, parameters, codes, token claims, scopes, and the accepting service or callback
|
||||
- The exact point where claims or tokens become accepted app identity
|
||||
- One minimal replayable redirect-to-acceptance sequence
|
||||
@@ -0,0 +1,7 @@
|
||||
interface:
|
||||
display_name: "Competition Oauth Oidc Chain"
|
||||
short_description: "Trace OAuth redirects, tokens, scopes, and accepted login flow"
|
||||
default_prompt: "After $ctf-sandbox-orchestrator is active, use $competition-oauth-oidc-chain to trace redirects, scopes, tokens, claims, and the accepted OAuth or OIDC login path in this challenge."
|
||||
|
||||
policy:
|
||||
allow_implicit_invocation: false
|
||||
@@ -0,0 +1,27 @@
|
||||
# OAuth OIDC Chain Checklist
|
||||
|
||||
## First Pass
|
||||
|
||||
- Entry route, issuer, client ID, redirect URI, callback route, token endpoint, refresh path
|
||||
- Authorize parameters: `response_type`, `scope`, `state`, `nonce`, PKCE challenge, audience, prompt
|
||||
- Browser redirects, backend token exchanges, stored session state, final app acceptance
|
||||
|
||||
## Chain To Reconstruct
|
||||
|
||||
1. Entry request or login trigger
|
||||
2. Authorize redirect built
|
||||
3. Callback parameters received
|
||||
4. Code or token exchange performed
|
||||
5. Claims or token accepted by app or backend
|
||||
|
||||
## Evidence To Keep Together
|
||||
|
||||
- Redirect side: route, parameters, callback values, issuer
|
||||
- Token side: type, claims, scopes, audience, expiration, subject
|
||||
- Acceptance side: session created, claims mapped, tenant selected, route unlocked, or privilege granted
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
- Stopping at the callback without proving token exchange or claim acceptance
|
||||
- Treating possession of a token as authorization without showing where it is accepted
|
||||
- Mixing browser-only redirect evidence and backend-only auth evidence without linking them
|
||||
@@ -0,0 +1,52 @@
|
||||
---
|
||||
name: competition-pcap-protocol
|
||||
description: Internal downstream skill for ctf-sandbox-orchestrator. CTF-sandbox workflow for packet capture analysis, session reconstruction, application-protocol decoding, stream reassembly, beacon timing, and packet-to-process correlation. Use when the user asks to analyze a PCAP, rebuild TCP or UDP sessions, decode HTTP, WebSocket, DNS, custom C2, or binary protocols, extract transferred artifacts, or tie packet sequences to host or malware behavior. Use only after `$ctf-sandbox-orchestrator` has already established sandbox assumptions and routed here.
|
||||
---
|
||||
|
||||
# Competition PCAP Protocol
|
||||
|
||||
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 evidence sits inside packet order, protocol framing, or stream reconstruction rather than a single IOC or host log.
|
||||
|
||||
Reply in Simplified Chinese unless the user explicitly requests English.
|
||||
|
||||
## Quick Start
|
||||
|
||||
1. Establish the capture boundaries first: hosts, time span, interfaces, missing packets, retransmits, and stream count.
|
||||
2. Group traffic into sessions before decoding payload semantics.
|
||||
3. Record protocol framing, sequence, timing, and transferred artifacts together instead of as isolated packets.
|
||||
4. Correlate packet evidence with host, malware, or app behavior only after the session is reconstructed.
|
||||
5. Reproduce the smallest decoded stream or transferred artifact that proves the challenge path.
|
||||
|
||||
## Workflow
|
||||
|
||||
### 1. Build The Session Map
|
||||
|
||||
- Identify endpoints, protocols, ports, TLS handshakes, DNS lookups, websocket upgrades, and long-lived streams.
|
||||
- Note missing capture coverage, asymmetric routing, packet loss, or reassembly issues before drawing conclusions.
|
||||
- Separate control channels, bulk transfers, keepalives, and noise.
|
||||
|
||||
### 2. Decode The Protocol Boundary
|
||||
|
||||
- Reassemble TCP streams or UDP conversations before interpreting fields.
|
||||
- Recover framing, message order, custom headers, binary fields, compression, encryption boundaries, and object transfers.
|
||||
- Keep payload direction, timing, and session state aligned with each decoded message.
|
||||
|
||||
### 3. Tie Packets To Behavior
|
||||
|
||||
- Show which packet sequence maps to which host event, malware branch, login flow, upload, exfiltration step, or command channel.
|
||||
- Distinguish protocol recognition from artifact recovery: naming HTTP, DNS, or a custom C2 is not enough without decoded content or proven downstream effect.
|
||||
- If the task becomes mostly a host timeline problem after decode, switch to the tighter forensic timeline skill.
|
||||
|
||||
## Read This Reference
|
||||
|
||||
- Load `references/pcap-protocol.md` for the session checklist, decode checklist, and evidence packaging.
|
||||
- If the hard part is a WebSocket or SSE handshake, subscription flow, realtime frames, or frame-driven state, prefer `$competition-websocket-runtime`.
|
||||
- If the hard part is a custom handshake, framing, checksum, sequence dependency, or deterministic replay harness, prefer `$competition-custom-protocol-replay`.
|
||||
|
||||
## What To Preserve
|
||||
|
||||
- Stream IDs, endpoint pairs, packet ranges, timestamps, protocol framing, and object boundaries
|
||||
- Decoded requests, responses, commands, transferred files, and the session that carried them
|
||||
- The exact packet sequence or reconstructed stream that proves the challenge behavior
|
||||
@@ -0,0 +1,7 @@
|
||||
interface:
|
||||
display_name: "Competition Pcap Protocol"
|
||||
short_description: "Rebuild sessions, decode protocols, and tie packets to behavior"
|
||||
default_prompt: "After $ctf-sandbox-orchestrator is active, use $competition-pcap-protocol to reconstruct sessions from this PCAP, decode the application protocol, and tie packet evidence to the challenge behavior."
|
||||
|
||||
policy:
|
||||
allow_implicit_invocation: false
|
||||
@@ -0,0 +1,27 @@
|
||||
# PCAP Protocol Checklist
|
||||
|
||||
## First Pass
|
||||
|
||||
- Capture time span, interfaces, endpoint pairs, port distribution, TLS use, DNS lookups, websocket upgrades
|
||||
- Missing data, retransmits, out-of-order packets, NAT ambiguity, asymmetric routing
|
||||
- Candidate high-value streams: auth, upload, download, command, beacon, exfiltration
|
||||
|
||||
## Decode Order
|
||||
|
||||
1. Reassemble stream or conversation
|
||||
2. Recover framing and direction
|
||||
3. Identify compression, encoding, crypto, or transfer boundaries
|
||||
4. Extract decoded messages or transferred objects
|
||||
5. Tie the decoded stream to host or sample behavior
|
||||
|
||||
## Evidence To Keep Together
|
||||
|
||||
- Session identity: endpoints, ports, protocol, stream ID, timestamps
|
||||
- Decode facts: framing markers, lengths, message order, headers, keys, or object names
|
||||
- Behavioral link: command executed, file transferred, beacon path, auth effect, or parser branch
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
- Reasoning from single packets when stream reassembly is required
|
||||
- Naming a protocol without decoding the content that matters to the challenge
|
||||
- Mixing unrelated streams because they share a host or port but not the same session state
|
||||
@@ -0,0 +1,49 @@
|
||||
---
|
||||
name: competition-prompt-injection
|
||||
description: 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.
|
||||
---
|
||||
|
||||
# Competition Prompt Injection
|
||||
|
||||
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 challenge is primarily about trust boundaries inside an agentic system.
|
||||
|
||||
Reply in Simplified Chinese unless the user explicitly requests English.
|
||||
|
||||
## Quick Start
|
||||
|
||||
1. Identify the first untrusted content that becomes model-visible.
|
||||
2. Map the chain from retrieval, memory, or transcript into planner or executor behavior.
|
||||
3. Record the exact point where text becomes a tool argument, file path, network target, or secret request.
|
||||
4. Prove one minimal exploit chain before exploring variants.
|
||||
5. Keep prompt snippets and tool transitions in compact evidence blocks.
|
||||
|
||||
## Workflow
|
||||
|
||||
### 1. Map The Control Stack
|
||||
|
||||
- Track system, developer, user, retrieved, memory, planner, and tool-response layers separately.
|
||||
- Distinguish claimed capability from runtime-exposed capability.
|
||||
- Note what the model can actually call, read, or mutate.
|
||||
|
||||
### 2. Prove The Boundary Crossing
|
||||
|
||||
- Reproduce one chain from untrusted text to changed planner behavior, changed tool args, or secret exposure.
|
||||
- Keep the decisive transcript compact: source chunk, rewritten planner state, final tool invocation.
|
||||
- Prefer the smallest transcript that still demonstrates the bug.
|
||||
|
||||
### 3. Report By Boundary
|
||||
|
||||
- State which layer failed: retrieval, summarizer, planner, executor, tool normalization, or output post-processing.
|
||||
- Separate instruction drift from actual side effect.
|
||||
|
||||
## Read This Reference
|
||||
|
||||
- Load `references/prompt-injection.md` for the checklist, evidence layout, and common prompt-boundary pitfalls.
|
||||
|
||||
## What To Preserve
|
||||
|
||||
- Original malicious chunk or prompt
|
||||
- Intermediate summary or planner drift if it matters
|
||||
- Final tool args, file paths, or exposed secret surface
|
||||
@@ -0,0 +1,7 @@
|
||||
interface:
|
||||
display_name: "Competition Prompt Injection"
|
||||
short_description: "Analyze retrieval poisoning, planner drift, and tool abuse"
|
||||
default_prompt: "After $ctf-sandbox-orchestrator is active, use $competition-prompt-injection to trace how untrusted content poisons prompts, memory, planning, or tool arguments."
|
||||
|
||||
policy:
|
||||
allow_implicit_invocation: false
|
||||
@@ -0,0 +1,33 @@
|
||||
# Prompt Injection And Tool Boundary Checklist
|
||||
|
||||
## Map These Layers Explicitly
|
||||
|
||||
- System and developer instructions
|
||||
- User request
|
||||
- Retrieved chunks or documents
|
||||
- Memory or summaries
|
||||
- Planner draft or chain-of-thought proxy artifacts
|
||||
- Executor or tool adapter
|
||||
- Final tool invocation and side effect
|
||||
|
||||
## Minimal Proof Chain
|
||||
|
||||
Use the smallest chain that proves the bug:
|
||||
|
||||
1. Untrusted content enters context
|
||||
2. Model-visible instruction boundary changes
|
||||
3. Planner or executor behavior drifts
|
||||
4. Tool call or secret access changes
|
||||
5. Side effect becomes observable
|
||||
|
||||
## Evidence To Keep
|
||||
|
||||
- One compact block for the malicious chunk or prompt
|
||||
- One compact block for planner drift or intermediate rewrite
|
||||
- One compact block for final tool args and side effect
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
- Treating a malicious string as proof without a side effect
|
||||
- Mixing several injection variants before one minimal chain is proven
|
||||
- Forgetting to separate retrieval contamination from executor normalization bugs
|
||||
@@ -0,0 +1,50 @@
|
||||
---
|
||||
name: competition-queue-worker-drift
|
||||
description: Internal downstream skill for ctf-sandbox-orchestrator. CTF-sandbox workflow for queues, async workers, cron jobs, delayed tasks, retry behavior, worker-only config drift, and payload-to-side-effect chains. Use when the user asks to trace a queue payload, inspect async job execution, explain worker-only behavior, follow retries or dead-letter handling, or connect an enqueued item to a later file, cache, email, or privilege-bearing side effect. Use only after `$ctf-sandbox-orchestrator` has already established sandbox assumptions and routed here.
|
||||
---
|
||||
|
||||
# Competition Queue Worker Drift
|
||||
|
||||
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 effect happens after enqueue, inside a worker, or only under async runtime state that differs from the request path.
|
||||
|
||||
Reply in Simplified Chinese unless the user explicitly requests English.
|
||||
|
||||
## Quick Start
|
||||
|
||||
1. Map the async chain first: enqueue point, queue payload, worker consumer, retries, and final side effect.
|
||||
2. Keep request-time state separate from worker-time state.
|
||||
3. Record queue name, message shape, worker config, retry policy, and downstream store in one chain.
|
||||
4. Compare synchronous path and async path when behavior diverges.
|
||||
5. Reproduce the smallest enqueue-to-side-effect flow that proves the decisive async drift.
|
||||
|
||||
## Workflow
|
||||
|
||||
### 1. Map Enqueue And Worker Identity
|
||||
|
||||
- Record queue names, topics, cron schedules, delayed jobs, dead-letter queues, worker processes, and consumer groups.
|
||||
- Note which config, env vars, feature flags, or credentials exist only in the worker environment.
|
||||
- Keep enqueue request, stored payload, and worker identity tied together.
|
||||
|
||||
### 2. Trace Worker-Only State And Retries
|
||||
|
||||
- Show how worker runtime differs from the request path: different env, files, mounts, caches, permissions, or clocks.
|
||||
- Record retry count, backoff, dedupe keys, failure handling, dead-letter flow, and idempotency behavior.
|
||||
- Distinguish immediate request success from eventual worker success or failure.
|
||||
|
||||
### 3. Reduce To The Decisive Async Chain
|
||||
|
||||
- Compress the result to the smallest sequence: enqueue -> worker runtime -> retry or branch -> resulting effect.
|
||||
- State clearly whether the decisive difference lives in payload shape, worker config, retry path, or downstream consumer.
|
||||
- If the issue is really about the file parser invoked by the worker, switch back to the tighter file-parser skill.
|
||||
|
||||
## Read This Reference
|
||||
|
||||
- Load `references/queue-worker-drift.md` for the queue checklist, retry checklist, and evidence packaging.
|
||||
|
||||
## What To Preserve
|
||||
|
||||
- Queue names, payloads, worker identities, retry metadata, dead-letter edges, and downstream effects
|
||||
- The exact worker-only config or state that changes behavior
|
||||
- One minimal enqueue-to-side-effect reproduction chain
|
||||
@@ -0,0 +1,7 @@
|
||||
interface:
|
||||
display_name: "Competition Queue Worker Drift"
|
||||
short_description: "Trace queue payloads, worker state, retries, and async drift"
|
||||
default_prompt: "After $ctf-sandbox-orchestrator is active, use $competition-queue-worker-drift to trace queued payloads, worker execution, retries, and the async state drift that creates the decisive behavior."
|
||||
|
||||
policy:
|
||||
allow_implicit_invocation: false
|
||||
+27
@@ -0,0 +1,27 @@
|
||||
# Queue Worker Drift Checklist
|
||||
|
||||
## First Pass
|
||||
|
||||
- Enqueue endpoint, queue or topic name, payload schema, worker process, schedule or delay, downstream store
|
||||
- Worker env, mounts, credentials, feature flags, config files, retry policy, dedupe behavior
|
||||
- Final effects: file write, cache mutation, email, report, artifact generation, privilege-bearing action
|
||||
|
||||
## Async Chain To Reconstruct
|
||||
|
||||
1. Request or cron enqueue occurs
|
||||
2. Payload stored or scheduled
|
||||
3. Worker picks it up under its own runtime state
|
||||
4. Retry, backoff, or failure path taken if relevant
|
||||
5. Side effect lands in file, DB, cache, email, or service
|
||||
|
||||
## Evidence To Keep Together
|
||||
|
||||
- Enqueue side: route, payload, queue name, task ID
|
||||
- Worker side: process, env, config, retry metadata, dedupe or lease state
|
||||
- Effect side: resulting artifact, downstream mutation, timestamps, and replay prerequisites
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
- Explaining only the request path and never proving the worker branch
|
||||
- Ignoring worker-only env or mount differences
|
||||
- Treating eventual side effects as synchronous behavior without isolating the async boundary
|
||||
@@ -0,0 +1,50 @@
|
||||
---
|
||||
name: competition-race-condition-state-drift
|
||||
description: Internal downstream skill for ctf-sandbox-orchestrator. CTF-sandbox workflow for race windows, ordering bugs, idempotency failures, lock gaps, concurrent worker drift, and state inconsistencies that produce decisive effects. Use when the user asks to reproduce timing-sensitive bugs, concurrent state corruption, duplicate actions, stale reads, or privilege or balance drift caused by request ordering. Use only after `$ctf-sandbox-orchestrator` has already established sandbox assumptions and routed here.
|
||||
---
|
||||
|
||||
# Competition Race Condition State Drift
|
||||
|
||||
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 behavior depends on request timing, async ordering, lock gaps, or stale state.
|
||||
|
||||
Reply in Simplified Chinese unless the user explicitly requests English.
|
||||
|
||||
## Quick Start
|
||||
|
||||
1. Identify mutable state first: rows, cache keys, queue payloads, session fields, counters, or files.
|
||||
2. Reproduce with smallest concurrent sequence and fixed timing assumptions.
|
||||
3. Capture one baseline run and one racing run with only one variable changed.
|
||||
4. Track read, check, write, enqueue, and commit boundaries separately.
|
||||
5. Prove final state drift from a clean reset.
|
||||
|
||||
## Workflow
|
||||
|
||||
### 1. Map Mutable Boundaries
|
||||
|
||||
- Record transaction scope, lock behavior, retry logic, idempotency keys, cache invalidation, and queue handoff.
|
||||
- Note where read-check-write is split across requests, workers, or services.
|
||||
- Keep each boundary tied to exact timestamps or sequence numbers.
|
||||
|
||||
### 2. Reproduce Timing Window
|
||||
|
||||
- Build deterministic concurrent inputs with controlled delay, duplicate requests, or reordered worker execution.
|
||||
- Compare accepted and rejected paths under identical payloads.
|
||||
- Record which condition flips when ordering changes.
|
||||
|
||||
### 3. Reduce To Decisive Race Chain
|
||||
|
||||
- Compress to: request A and B ordering -> stale check or lock gap -> conflicting writes -> resulting capability or artifact.
|
||||
- State whether root cause is missing lock, weak idempotency, stale cache read, delayed async commit, or retry side effect.
|
||||
- If the path becomes queue-dominant, hand off to queue worker drift skill.
|
||||
|
||||
## Read This Reference
|
||||
|
||||
- Load `references/race-condition-state-drift.md` for race harness ideas, evidence blocks, and parity checks.
|
||||
|
||||
## What To Preserve
|
||||
|
||||
- Mutable keys, transaction boundaries, lock behavior, and idempotency markers
|
||||
- Timestamped or sequenced traces for baseline and race runs
|
||||
- One minimal replayable concurrent sequence proving drift
|
||||
@@ -0,0 +1,7 @@
|
||||
interface:
|
||||
display_name: "Competition Race Condition State Drift"
|
||||
short_description: "Reproduce races, ordering bugs, and state drift under contention"
|
||||
default_prompt: "After $ctf-sandbox-orchestrator is active, use $competition-race-condition-state-drift to reproduce race windows, ordering bugs, and decisive state drift."
|
||||
|
||||
policy:
|
||||
allow_implicit_invocation: false
|
||||
+27
@@ -0,0 +1,27 @@
|
||||
# Race Condition State Drift Checklist
|
||||
|
||||
## First Pass
|
||||
|
||||
- Mutable rows, cache keys, counters, files, queue payloads
|
||||
- Read-check-write boundaries, lock scope, retry behavior, idempotency handling
|
||||
- Worker delays, commit timing, stale reads, invalidation timing
|
||||
|
||||
## Chain To Reconstruct
|
||||
|
||||
1. Baseline ordering established
|
||||
2. Concurrent or reordered flow injected
|
||||
3. Check or lock boundary is bypassed
|
||||
4. Conflicting state mutation lands
|
||||
5. Decisive drift is reproduced
|
||||
|
||||
## Evidence To Keep Together
|
||||
|
||||
- State side: key or row, initial value, final value, commit boundaries
|
||||
- Timing side: request order, delays, retries, queue timing
|
||||
- Effect side: duplicated action, privilege drift, balance drift, stale authorization
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
- Running noisy stress tests without a minimal deterministic sequence
|
||||
- Mixing several mutable keys without proving which key drives the effect
|
||||
- Reporting timing sensitivity without final-state parity proof
|
||||
@@ -0,0 +1,50 @@
|
||||
---
|
||||
name: competition-relay-coercion-chain
|
||||
description: Internal downstream skill for ctf-sandbox-orchestrator. CTF-sandbox workflow for forced-auth coercion, relay chains, target selection, NTLM or related acceptance paths, and coercion-to-privilege transitions. Use when the user asks to trace a coercion primitive, follow a relay path, analyze forced authentication, determine which service accepts relayed auth, or connect a coercion step to resulting privilege, enrollment, or code execution. Use only after `$ctf-sandbox-orchestrator` has already established sandbox assumptions and routed here.
|
||||
---
|
||||
|
||||
# Competition Relay Coercion Chain
|
||||
|
||||
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 hard part is proving the full chain from forced authentication to a service that actually accepts the relayed identity.
|
||||
|
||||
Reply in Simplified Chinese unless the user explicitly requests English.
|
||||
|
||||
## Quick Start
|
||||
|
||||
1. Split the chain into coercion source, captured auth, relay target, acceptance point, and resulting effect.
|
||||
2. Record transport, protocol, and service identity at each hop.
|
||||
3. Separate forced-auth generation from relay success and from downstream privilege.
|
||||
4. Keep coercion trigger, relay transcript, and accepting service in one evidence chain.
|
||||
5. Reproduce the smallest coercion-to-acceptance path that proves the decisive edge.
|
||||
|
||||
## Workflow
|
||||
|
||||
### 1. Map The Coercion Source
|
||||
|
||||
- Identify the service, RPC, file path, printer path, WebDAV edge, or protocol trigger that forces authentication.
|
||||
- Record source host, coerced principal, transport, and any environmental preconditions.
|
||||
- Keep one compact note of exactly what causes the auth to leave the source.
|
||||
|
||||
### 2. Trace The Relay Target
|
||||
|
||||
- Record where the authentication lands, how it is forwarded, and which protocol or service consumes it.
|
||||
- Distinguish capture-only, replay-only, and actual relay acceptance.
|
||||
- Keep service name, target host, protocol, relay transcript, and acceptance response tied together.
|
||||
|
||||
### 3. Reduce To The Decisive Relay Chain
|
||||
|
||||
- Compress the result to the smallest sequence: coercion trigger -> relayed auth -> accepted service -> resulting privilege or artifact.
|
||||
- State clearly whether the decisive weakness lives in the coercion source, the relay target, signing settings, or the accepted downstream service.
|
||||
- If the path ultimately becomes a certificate-enrollment issue or a pure Kerberos delegation edge, hand off to the tighter specialized skill.
|
||||
|
||||
## Read This Reference
|
||||
|
||||
- Load `references/relay-coercion-chain.md` for the coercion checklist, relay checklist, and evidence packaging.
|
||||
|
||||
## What To Preserve
|
||||
|
||||
- Coercion trigger details, source host, coerced identity, target host, accepting service, and resulting effect
|
||||
- Relay transcripts, error or acceptance responses, and the exact protocol used at each hop
|
||||
- The smallest replayable coercion-to-acceptance sequence
|
||||
@@ -0,0 +1,7 @@
|
||||
interface:
|
||||
display_name: "Competition Relay Coercion Chain"
|
||||
short_description: "Trace coercion, relay targets, and accepted auth edges"
|
||||
default_prompt: "After $ctf-sandbox-orchestrator is active, use $competition-relay-coercion-chain to trace the coercion step, relay target, and accepted authentication edge in this challenge."
|
||||
|
||||
policy:
|
||||
allow_implicit_invocation: false
|
||||
+28
@@ -0,0 +1,28 @@
|
||||
# Relay Coercion Checklist
|
||||
|
||||
## Chain Segments
|
||||
|
||||
- Coercion source and trigger
|
||||
- Captured or forwarded authentication
|
||||
- Relay target and protocol
|
||||
- Acceptance point and resulting effect
|
||||
|
||||
## Reconstruction Order
|
||||
|
||||
1. What triggers the source to authenticate
|
||||
2. Which identity leaves the source
|
||||
3. Where that authentication is relayed
|
||||
4. Which service actually accepts it
|
||||
5. What privilege, enrollment, or artifact results
|
||||
|
||||
## Evidence To Keep Together
|
||||
|
||||
- Source side: host, service, trigger, protocol, coerced principal
|
||||
- Relay side: listener, transcript, target host, protocol, response
|
||||
- Effect side: accepted service, resulting account effect, privilege, or issued artifact
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
- Stopping at “forced auth happened” without proving relay acceptance
|
||||
- Proving relay acceptance without showing what capability it produced
|
||||
- Mixing several candidate relay targets without isolating the one that actually accepted the relayed auth
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user