Find the code on my GitHub: A-D-Agent

1. Why I Built A-D-AGENT

In Attack & Defense (A&D) CTFs I kept juggling a chaotic pile of ad‑hoc Python scripts, tmux panes, half‑broken cron loops, and manual flag submission one‑liners; context switching robbed time from actually sharpening exploits, so I set out to consolidate editing, execution, flag extraction, and submission into a single, browser‑based, continuously running system—thus A-D-AGENT was born.

2. Core Goals From Day 0

My design targets were: (1) Zero database / minimal infra so I can spin it up mid‑round; (2) Single authoritative config file to retarget an entire competition quickly; (3) Tight feedback loop—edit → run → see output → harvest flags automatically; (4) Deterministic flag pipeline with de‑duplication + resilient submission; (5) Portable container that works over VPNs with host networking; (6) Extensibility (AI rewrite, custom submission scripts) without bloating the core. These emerged directly from friction I experienced in prior A&D events (inference based on listed features & architecture).

3. High‑Level Feature Set

The platform ships with a VS Code‑like web IDE (Monaco editor), exploit templating, real‑time manual test runs, automated periodic execution across multiple services/IPs, regex‑based flag detection, deduplication, batch or individual submission (HTTP / netcat / dual), retry logic, statistics dashboard, event timeline, and Dockerized one‑command deployment.

4. Architecture Snapshot

I intentionally chose a full‑stack containerized approach: Frontend (React + Vite + Monaco) served from the same process; Backend in Go (Gin) compiled to a static binary; Runtime layer includes Python 3.11 plus common libraries; configuration lives in config.go; Docker multi‑stage build outputs a slim runtime image. This separation keeps exploit execution fast and concurrent while the frontend stays responsive.

5. The “Single Config File” Philosophy

All operational parameters—services, IP generation helpers, flag regex, submission modes (HTTP / netcat / both), batching size, retry semantics, AI key, timing intervals, exclusion list for my own team—reside solely in config.go. Editing one file mid‑round is far safer than hunting environment variables everywhere; a quick rebuild (./start.sh) propagates changes.

6. Service & Target Modeling

Services are typed (Service struct) with Name + slice of IPs; helper range generation (e.g. helper.GenerateIPRange(“10.10.%d.10”, 1, 5)) accelerates onboarding for 50‑team networks; I can append bespoke IPs when anomalies exist. Grouping exploits by service name (filename prefix) lets the runner map each exploit to the correct IP set automatically.

7. Timing & Concurrency Strategy

A tunable TickerInterval (default 10s) balances race conditions against scoreboard rotation windows; each cycle concurrently invokes all Python exploits across all targets with a strict 5‑second timeout per execution, capturing stdout/stderr for later regex scanning (inference anchored to documented periodic execution + timeout).

8. Exploit Authoring UX

New exploit creation through the UI auto‑injects a Python template scaffolding parameters (host = sys.argv[1]), reducing boilerplate; the run button passes a chosen IP for ad‑hoc testing before the automation loop picks up the file. This immediate feedback loop was prioritized over fancy persistence—localStorage suffices for state continuity.

9. Automatic Flag Harvesting Pipeline

Pipeline phases: (1) discover .py exploits under tmp/; (2) parallel execution; (3) apply configurable regex (FLAG_REGEX) over captured outputs; (4) deduplicate and log to flags.txt; (5) submit via selected method(s) with batching + retry triggers; each stage is time‑staggered (flag detection at T+20s) to avoid blocking the hot execution loop (inference referencing timing & stage descriptions).

10. Regex Flexibility & Multi‑Format Support

The config explicitly documents patterns for standard {} styles, hashes, alternations, and case‑insensitive variants, enabling quick adaptation when organizers get creative (e.g., MD5‑like, multi‑format alternation). This pre‑baked guidance reduces guesswork mid‑round.

11. Submission Modalities (HTTP / Netcat / Both)

A-D-AGENT abstracts three strategies: pure HTTP with configurable headers + JSON key (FLAG_KEY), raw TCP via netcat with multiple line/command/json output formats, or dual submission for redundancy. Batch sizing (NUMBER_OF_FLAGS_TO_SEND_AT_ONCE) optimizes scoreboard throughput while respecting rate limits; netcat remains single‑flag by design.

12. Resilient Retry Semantics

ERROR_MESSAGES acts as a semantic filter—only transient responses keep a flag in the queue (e.g., rate limit, temporary errors), avoiding infinite spins on truly invalid flags. Centralizing this list in the config makes tuning immediate when a checker reveals its distinct wording.

13. AI‑Assisted Refactoring

An optional OpenAI API key unlocks “AI Rewrite” to clean, optimize, and comment exploit code while preserving behavior—useful when rapidly cloning and modifying scripts under time pressure. The feature is deliberately opt‑in due to outbound code transmission and potential sensitive logic (inference referencing optional flag & rewrite feature).

14. Custom Submission Extension Points

If neither HTTP nor netcat matches exotic infrastructures (OAuth, proprietary APIs, Telnet/SSH, multi‑step workflows) I provide a reference Python tail‑reader that streams new lines from flags.txt and posts them—standing in as a blueprint for crafting protocol‑specific sidecars or integration with Slack/Discord bots.

15. Containerization Rationale

The multi‑stage Dockerfile builds the frontend then a static Go binary before assembling a Python runtime image with network tooling (netcat, curl, iputils, bind-tools) ready for exploit scripts; this drastically trims production size and cold‑start latency compared to shipping build chains inside the final image.

16. Deployment Modes & Host Networking

docker-compose.yml defaults to network_mode: “host” to seamlessly traverse VPN tunnels common in A&D events (where bridging complicates routing), with explicit alternative commented configuration for bridge scenarios; volume mounts persist flags.txt and the tmp exploit directory across restarts.

17. Startup / Operational Ergonomics

start.sh performs defensive cleanup: stops old containers, purges images to force rebuild, backs up previous flags.txt, clears stale exploits, then builds & launches—providing a deterministic baseline each contest morning; docker-entrypoint.sh self‑checks artifacts (frontend bundle count, backend binary presence) and restarts the Go server if it crashes, giving autonomous resilience.

18. Health & Observability

A healthcheck curls /api/services ensuring the container orchestrator can mark readiness; runtime debug prints (file counts, DNS servers, container IP, default route) assist when VPN constraints sabotage connectivity—a pragmatic, low‑overhead approach instead of integrating a full metrics stack (inference building on healthcheck & diagnostic scripting).

19. Minimal State Persistence Philosophy

I intentionally eschewed databases: the only durable artifacts are flags and exploit scripts, mapped into volumes. This decreases complexity and reduces the blast radius of accidental data corruption while enabling quick manual inspection (inference anchored to volume mounts & lack of DB references).

20. Example Competition Flow

1. Adjust Service definitions & regex in config.go.

2. ./start.sh (or Windows batch) builds & launches.

3. Open http://localhost:1337, create new exploits per service template.

4. Test single IP manually; iterate until a flag prints.

5. Allow automation to cycle; harvested flags appear in flags.txt and submit via configured method(s).

6. Monitor dashboard (flag counts, last capture, event timeline) to gauge exploit stability; tune TickerInterval or error retry list when scoreboard behavior changes.

21. Performance Trade‑Offs

I considered aggressively lowering intervals below 5s, but config comments highlight risk of overwhelming services / triggering rate limits; conversely >60s risks missing fast‑rotating flags—so 10s offers a balanced, adaptable default. Batching HTTP submissions reduces overhead yet remains bounded to defend against scoreboard throttle (inference anchored to timing guidance & batching semantics).

22. Safety & Ethical Guardrails

The exclusion list (MYSERVICES_IPS) prevents self‑attacks; explicit comments around API keys and external AI usage remind me to strip or neutralize sensitive data before enabling AI rewriting; config centralization mitigates accidental credential sprawl (inference referencing exclusion + API key notes).

23. Rapid Iteration & Rebuild Cycle

Because Go compiles fast and the Docker multi‑stage caches dependencies, iterative changes to backend/main.go or config.go are quick—start.sh enforces a clean build, ensuring stale artifacts never linger (inference referencing build script + multi‑stage design).

24. Extensibility Vectors

Future features can slot in via: (a) augmenting the web UI (React) without touching runtime; (b) adding new submission modules in config (pattern already set); (c) sidecar containers reading flags.txt; (d) additional analysis on exploit outputs before regex scanning. The architecture’s separation encourages targeted evolution.

25. Lessons Learned

Centralizing documentation inside config.go (heavy inline commentary) drastically lowers onboarding friction for teammates mid‑round; explicit examples for multiple flag formats and submission styles preempt panic when organizers deviate from assumptions; investing in restart resilience (entrypoint watchdog + healthcheck) yields disproportionate stability under contest pressure.

26. Roadmap Ideas

Planned improvements:

• Structured JSON event stream for external dashboards.

• Pluggable scoring heuristics to prioritize exploit triage.

• Sandboxed execution (Firecracker / nsjail) for untrusted exploit code.

• Automatic diff‑based AI suggestions on failing exploits (enhancing existing rewrite). These evolve naturally from current modular design (inference referencing existing modular architecture & AI integration).

27. Closing Thoughts

A-D-AGENT distills repetitive, error‑prone contest logistics into an integrated, observable loop so I can redirect cognitive bandwidth toward finding & weaponizing vulnerabilities—not wrestling scripts, terminals, and submission quirks. Ship once, iterate fast, harvest flags reliably.