Flag Pipeline
Real CookieFarm flag pipeline from exploit capture to checker submission and dashboard state.
Flag Pipeline
This page describes the real flag path implemented in CookieFarm code.
Flag production (Python runtime)
Python exploits print JSON to stdout. A valid capture event uses status: "success" and includes at least:
flag_codeteam_idport_servicename_service
Output format is defined in exploiter/python/cookiefarm/logger.py.
Client parsing (ckc)
ckc reads stdout/stderr, parses JSON, and maps successful events into database.Flag.
Main rules:
success-> queued to submit channelfailed,error,fatal,info,debug-> logged, not submittedstats-> logged as round summary
Files: cookiefarm/client/internal/exploit/parse.go, run.go.
Server ingestion
Two modes:
- CKP TCP (default):
ckc exploit run - Direct HTTP:
ckc exploit run -S
CKP sends compact binary flag frames to TCP port 7777.
Server files: server/internal/ckp/handler.go, server/internal/ckp/ckp.go, server/api/handler_api.go.
Buffering and persistence
Server uses FlagCollector:
- flush on size threshold (
maxBufferSize=100) - periodic flush (
flushInterval=10s) - writes to SQLite
flagstable (INSERT OR IGNORE)
This prevents duplicate inserts for the same flag (flag_code is PK).
Submission to flag checker
Periodic server loop (StartFlagProcessingLoop):
- fetches
unsubmittedflags - submits batch using configured protocol (
pkg/protocols) - updates DB status (
accepted/denied/error)
Relevant config:
server.submit_flag_checker_timeserver.max_flag_batch_sizeserver.protocol
Dashboard rendering
Dashboard reads from DB:
- paginated flag table
- mapped state (
UNSUBMITTED/ACCEPTED/DENIED/ERROR) - timing fields (
submit_time,response_time, duration)
State meanings for A/D
UNSUBMITTED(0): queued, not processed by checker yetACCEPTED(1): valid flagDENIED(2): rejected flagERROR(3): submit/check error
Practical Failure Modes
Exploit outputs non-JSON lines
Symptom: no flags get queued.
Action:
- always use helper
log_statusin Python runtime - verify shared
regex_flagconfig
Unstable CKP link
Symptom: send retries, reconnects, or throughput drop.
Action:
- verify TCP reachability to port
7777 - verify server CKP listener is running
- use temporary
-Sfallback during incident response
Checker slow or unavailable
Symptom: large UNSUBMITTED backlog, response_time remains zero.
Action:
- reduce exploit threads
- lower batch size
- verify checker endpoint and protocol
How is this guide?