ctf-solve-and-sync

name	ctf-solve-and-sync
description	End-to-end CTF workflow for solving a challenge, checking the user's Notion CTF Cheat Sheet for related exploit notes, and then recording the final exploit path back into Notion. Use when a user wants one flow that handles triage, exploit development, solver validation, and structured Notion note capture after the challenge is solved.

CTF Solve And Sync

Use this skill when the job is not only to solve a CTF challenge, but also to store the final result in Notion.

Mission

Act like a self-sufficient CTF teammate:

• solve the challenge with a reproducible path
• keep notes and artifacts organized during the solve
• sync only the final, technically defensible result into Notion

The solve is the priority. The Notion note is the handoff artifact.

Research Boundaries

• Do not search GitHub or other public repositories for ready-made challenge solvers or third-party writeups as part of the default solve flow.
• Prefer the challenge files, local experimentation, official challenge material, and the user's existing Notion notes.
• If stuck, it is allowed to research the underlying technique online:
  • look up generic exploit methods, mitigation bypasses, kernel/browser/runtime internals, academic references, official docs, CVEs, and high-signal background material
  • prefer technique-level research over challenge-name research
  • use external material to inform hypotheses and debugging, not to substitute for validation
• Only look for public external solves if the user explicitly asks for that research.

Solve First

1. Capture challenge context:
   • name, category, prompt, files, endpoint, flag format, and rules
   • required deliverable: steps, solver, writeup, or all three
2. Check the user's Notion for related exploit notes before going deep:
   • search the CTF Cheat Sheet for the likely exploit family, primitive, mitigation bypass, product, or bug class
   • reuse existing notes for tactics, payload patterns, offsets, caveats, and debugging ideas
   • treat Notion as prior art and a hint source, not proof that the current challenge is solved
3. Triage quickly:
   • enumerate inputs, trust boundaries, protections, and likely bug classes
   • define one primary path and one fallback
   • timebox low-signal branches and pivot fast
4. Build the exploit:
   • prefer deterministic scripts over manual browser clicks
   • keep helper logic separate from the main exploit flow
   • use stable CLI args and actionable failures
   • store intermediate state when brute force or oracle recovery is involved
5. Validate the solve:
   • rerun from a clean start when possible
   • record exact commands, payloads, and checkpoints
   • note unstable assumptions, races, environmental dependencies, and timing

Do not sync half-proven guesses into Notion. Sync only after the path is solved or the technique is worth preserving as a vetted note.

Solve Loop

Use a tight repeated loop:

1. observe
2. hypothesize
3. test
4. log
5. keep or discard the branch

Do not let dead-end experimentation flood the final note. Preserve only the pivots that explain why the winning path worked.

Category Triage

Always adapt the initial checklist to the category.

Web

Check:

• sources, sinks, trust boundaries, origin transitions, CSP, sandboxing, cookies, SSRF, deserialization, template rendering, browser flags, bot behavior
• client-side code, extension code, service worker behavior, and admin-bot automation when present
• whether a local harness or replayable browser script can replace manual clicking

Pwn

Check:

• architecture, mitigations, libc/loader, I/O model, primitives, memory disclosure, code execution path, and remote/local drift
• whether exploit stages should be separated into leak, compute, and control phases

Crypto

Check:

• exact scheme, threat model, oracle surface, algebraic structure, randomness assumptions, encoding, and implementation bugs
• whether the solve needs symbolic math, lattice work, brute force, or a protocol transcript parser

Reversing

Check:

• packers, obfuscation, anti-debugging, important code paths, file formats, and the minimum artifact needed to recover secrets
• whether scripting the recovery is faster than stepping manually

Forensics / Misc / OSINT

Check:

• timeline, archive layers, metadata, protocol traces, file carving, search space pruning, and what should be automated versus inspected once

Category Output Conventions

Match the final artifacts to the category.

Web

Prefer:

• solver.py, exploit.js, or a minimal browser harness
• exact payloads, request sequences, CSP or browser conditions, and bot behavior notes
• a reduced exploit excerpt if the full helper server is mostly boilerplate

Pwn

Prefer:

• exploit.py with clear phases for leak, resolve, and control
• explicit remote/local target settings, libc/loader handling, and retry logic
• notes with offsets, gadgets, memory layout assumptions, and mitigation bypass reasoning

Crypto

Prefer:

• a single solver script or notebook-backed script distilled into a plain script when possible
• explicit equations, parameters, oracle behavior, and recovered values
• notes that separate theorem/observation from implementation detail

Reversing

Prefer:

• a recovery script, patch script, or minimal emulator harness if useful
• notes with function names, offsets, constants, and exact decode logic
• extracted pseudocode only for the decisive routine, not entire binaries

Forensics / Misc / OSINT

Prefer:

• extraction or parsing scripts, carving helpers, or exact shell pipelines
• notes with file names, hashes if relevant, timestamps, and the final evidence chain
• the shortest reproducible workflow from artifact to flag

Artifact Discipline

During the solve, keep artifacts ready for reuse and handoff.

Preferred local outputs:

• solver.py or category-equivalent main exploit
• notes.md or similar scratchpad for verified observations
• state or checkpoint files for long oracle/bruteforce runs
• auxiliary probe scripts only when they support the final exploit path

Rules:

• name things predictably
• keep the final solver separate from one-off probes when possible
• prefer resumable state for expensive scans or incremental recovery
• make failures loud and actionable
• preserve exact versions, endpoints, and runtime assumptions when they matter

Long Solves

If the challenge is taking a long time, switch from a short exploit workflow to a checkpointed campaign.

Required behaviors:

1. Keep a current status summary:
   • what is proven
   • what is still hypothesis
   • what branch is primary
   • what branch is fallback
2. Checkpoint expensive work:
   • brute force progress
   • oracle results
   • recovered bytes/words/keys
   • offsets, leaks, intermediate secrets
3. Make long-running stages resumable:
   • save state to disk
   • avoid recomputing finished phases
   • separate discovery from exploitation where possible
4. Timebox branches explicitly:
   • abandon low-signal paths faster
   • keep only decisive dead ends in the final note
5. Treat partial progress carefully:
   • do not sync noisy scratch notes into the cheat sheet
   • if the solve is not complete but the technique is worth keeping, label it as a vetted partial note
6. Record operational caveats:
   • runtime cost
   • race sensitivity
   • remote instability
   • dependency on versions, timing, or external services

Solve Quality Gate

Before syncing, verify all of these:

1. The exploit path is actually solved, or the preserved technique is explicitly marked as a vetted partial note.
2. The final solver or command sequence is rerunnable.
3. The winning payloads and exact conditions are captured.
4. Any race, timeout, browser version, libc version, or environment dependency is recorded.
5. The final path is distinguished from dead ends and false leads.
6. For long solves, checkpoint files and resume behavior are documented if they matter.

Sync After Solve

Use notion-mcp after the solve is stable.

Target database:

• CTF Cheat Sheet
• data source collection://19448583-e65d-8053-b09d-000bd5fdd100
• title property Doc name

Workflow:

1. Search the CTF Cheat Sheet for related exploit notes before writing anything new.
2. Reuse any existing note that already covers the decisive primitive, mitigation bypass, or tooling pattern for the challenge.
3. Search for the right topic page.
4. Reuse an existing bucket if the solve belongs there.
5. Create a new bucket only if no page matches the technique or tooling family.
6. Fetch the target page before editing so the existing style is preserved.
7. By default, append the writeup to the bottom of the chosen bucket page itself.
8. Do not put the main writeup inside a child page unless the user explicitly asks for a separate child page.
9. Upload final solver and supporting artifacts with Notion's native attachment tool when supported; follow Attachment Upload below.
10. Append a new entry instead of rewriting unrelated older notes.
11. After updating, fetch the page again and verify the final rendered content, attachment blocks, filenames, and hashes.

Attachment Upload

Prefer a real Notion attachment over a manual-upload placeholder.

1. Select only final, useful artifacts such as the solver, exploit source, checkpoint/state file, packet capture, archive, or reduced evidence file. Do not upload noisy probes or secrets.
2. Compute and record the artifact's SHA-256 before upload.
3. Call Notion create_attachment with exactly one source:
   • For a supported UTF-8 text artifact no larger than 200 KiB, pass its exact content. Supported inline formats include plain text, Markdown, HTML, CSV, JSON, XML, CSS, YAML, TSV, calendar, GPX, and SVG.
   • For a binary artifact, use a direct publicly reachable HTTPS source_url when available. It must not require cookies, headers, redirects, or private-network access, and must satisfy the connector's current size and timeout limits.
4. If a source-code extension is rejected but its bytes are valid UTF-8, upload the exact contents with a lossless .txt filename such as solver.py → solver.txt. In Attachments, state the original filename, the rename needed after download, and the SHA-256. Never silently change the contents.
5. Immediately place the returned markdown_source or suggested_markdown in the page's Attachments block. Temporary file-upload:// references expire if they are not attached within one hour. Use the connector-provided block instead of inventing attachment syntax.
6. If native upload is unavailable or cannot accept the artifact because it is a local binary, too large, or otherwise unsupported, add Manual upload: ORIGINAL_FILENAME instead. Do not fabricate a file block or expose temporary/signed URLs in References.
7. Fetch the page after updating and verify that the rendered entry contains the permanent file block, expected filename, recorded SHA-256, and any rename instruction. Treat successful upload without successful page attachment as incomplete.

Topic Selection

Prefer one short page title per technique or tooling bucket:

• exploit families: XSS, XSLeak, SQL, PHP, Browser, Crypto, Pwn, Reversing
• tooling buckets: Codex, Automation, Puppeteer / Playwright

If a challenge spans multiple families, choose the page that best matches the decisive primitive in the final exploit chain.

Bucket Selection Map

Use this map before creating or updating a note:

• Browser
  • browser internals, extension behavior, bot-browser quirks, CSP/sandbox/origin tricks, devtools/remote-debugging, webdriver behavior, file-origin quirks, popup routing, permission-policy, display-capture, browser CVEs
• XSLeak
  • side channels, scroll/focus/history/frame-count oracles, cache/timing leaks, text-fragment oracles, connection-or-no-connection leaks, cross-origin state disclosure where the decisive primitive is the leak itself
• XSS
  • direct script execution, HTML injection that directly becomes JS execution, sanitization bypasses, template injection leading to browser-side code execution
• PHP
  • PHP-specific web bugs, stream wrappers, unserialize, type juggling, loose comparisons, LFI/RFI in PHP apps
• SQL
  • SQL injection and query-logic abuse as the decisive primitive
• Crypto
  • scheme breaks, oracle attacks, algebraic recovery, nonce/key misuse, lattice or math-heavy exploitation
• Pwn
  • native memory corruption, shellcoding, ROP, heap/stack bugs, pwning bots through binary exploitation
• Reversing
  • static/dynamic analysis of binaries, VM/obfuscation reversal, key checks, unpacking, patching
• Automation
  • notes where the main value is tooling, orchestration, brute-force frameworks, reusable bot harnesses, or exploit infrastructure rather than a single bug class
• Codex
  • agent workflows, MCP/Notion usage, exploit-development process notes, solver automation patterns that are more about workflow than the challenge primitive
• Puppeteer / Playwright
  • browser automation techniques, admin-bot harnesses, DOM-driving and screenshot/testing flows where the automation technique itself is the note

Tie-break rules:

1. Choose the decisive primitive over supporting bugs.
2. If the final step is a browser or extension behavior quirk, prefer Browser unless the decisive primitive is clearly an XSLeak.
3. If the final step is a side channel or oracle, prefer XSLeak even if earlier setup used XSS or HTML injection.
4. If the main reusable value is the harness or orchestrator rather than the exploit class, prefer Automation.
5. Reuse the existing page if a similar note is already there; consistency beats perfect taxonomy.

Entry Shape

Read references/notion-template.md before writing.

The default destination is the bucket page selected above. The template is for an appended entry on that page, not for a separate child page, unless the user explicitly requests a child page.

Each synced entry should contain:

1. # short technique headline
2. metadata table with:
   • Event Name
   • Source URL
   • Challenge Name
3. <details> blocks for Attachments and References
4. ---
5. terse notes with:
   • root cause
   • exploit chain
   • exact payloads or solver fragments
   • useful references
   • environment or timing caveats when relevant
6. when the challenge has meaningful source or exploit code, include these sections:
   • why it is vulnerable
   • exploit payload
   • solver
7. for long solves, add a brief note for:
   • resume/checkpoint behavior
   • what was brute-forced, leaked incrementally, or recovered in stages

Content Rules

• Keep the note terse and technical.
• Preserve exact payloads, commands, and snippets.
• Record the final working path, not every abandoned path.
• Include one or two dead-end notes only if they explain an important pivot.
• Prefer append-only updates to preserve the cheat sheet history.
• If a source link is included, prefer the official challenge page, official release repository, or official source drop. Do not use third-party solver repositories as the default source link.
• Do not leave placeholder pseudo-code in a solver section. If there is a solver section, put the real solver or a directly executable reduced version of it.
• If the user asks for the full solver, put the full exact solver in the solver section, not a shortened excerpt.
• If the note has a why it is vulnerable section, use commented code snippets, not raw code with no explanation.
• References must contain only actual links. Never add local file paths or bare filenames there.
• Use Notion's native attachment upload for supported artifacts. If an extension is rejected but the file is UTF-8 text, preserve its exact contents under a .txt filename, record the original filename and SHA-256, and explain the rename. Use a manual-upload line only when native upload is unavailable or unsupported.
• Prefer the smallest complete code block that still shows the real exploit path. Avoid giant boilerplate when a reduced exact excerpt is enough.
• The note should be understandable standalone: a reader should see the vulnerable code, the exploit, and the solver without needing local repo paths.
• If a statement is an inference rather than directly verified, label it as such.
• Match the level of detail to the category: equations for crypto, offsets for pwn, routines for reversing, artifacts/timestamps for forensics, and browser/runtime conditions for web.

Note Quality Gate

Before finishing the sync, verify all of these:

1. References contains only valid links or is empty.
2. Attachments contains either a verified real Notion attachment or, only when native upload is unavailable or unsupported, a manual-upload placeholder.
3. Every uploaded artifact has its expected rendered filename and SHA-256; any lossless extension substitution includes a rename instruction.
4. why it is vulnerable explains the bug with inline comments if code is shown.
5. exploit payload shows the working payload, not a sketch.
6. solver is real code or exact executable commands, not semantics notes.
7. The final note reflects the decisive exploit path, not intermediate dead ends.
8. The entry matches the style of the target bucket page.
9. The note can stand alone without repo-local context.
10. Long-solve notes mention checkpoints or staged recovery if that mattered to the result.

Deliverables

• local solver or reproducible commands
• concise explanation of why the exploit works
• Notion entry in the correct topic page
• final page URL after sync