Step 279. ★ CTF Competition #1: Full Weekend Participation — The Goal of Your First Competition Is Finishing, Not Ranking

Level 3 — Real-World CTF & Advanced Offensive Skills | Difficulty ★★★☆☆ | Estimated time: 1 weekend (24–48-hour competition + half a day of prep and retrospective)

Prerequisites: Step 190’s CTFtime schedule with your first competition confirmed, the main-track course of Steps 191–250, Step 278’s real-world check complete.

What you need: one weekend competition confirmed on CTFtime, Kali Linux (or your attack environment), the penetration playbook (Step 272), a timer, and the competition log script you’ll build today.
⚠️ All exercises in this chapter are for your own lab and legal platforms only. Applying them to unauthorized systems is a crime. CTF competitions registered on CTFtime are legal platforms opened by their organizers for participation — attack nothing except the challenge servers the competition provides.
Caution: the competition platform’s scoreboard and challenge-list scenes are all screen examples. Every competition has a different platform (CTFd, etc.) and different rules, so you must check the actual screens yourself. The only thing actually executed and verified in this chapter is the local log script, and its output is marked as measured.

The competition is finally here. Starting from Step 176’s taste of CTF, you’ve crossed the five field tracks and the live-machine section to arrive here. Let’s fix the goal of the first competition clearly before we start — finishing and data collection. Recording which fields produce points, where time leaks away, and when your mental game shakes. Those records are the raw material for Step 280’s debrief and Step 283’s goal setting.

1. Learning Objectives

By the end of this chapter, you will be able to:

Run a checklist that inspects environment, tools, and playbook before the first competition
Execute the "full sweep" of the first 30 minutes and the easy-problems-first strategy
Operate a competition log that records start/solve/stuck/drop per problem, with timestamps
Cut losses on stuck problems with the "2-hour rule" and reallocate time
Write a retrospective memo right after the competition ends, securing material for the next step’s debrief

2. Background Knowledge — Today’s Tools and Concepts

Today’s Tools at a Glance

Category	Details
Language/environment	Competition platform (CTFd, etc., screen examples), Kali Linux, Python (log script)
Today’s screens/tools	CTFtime competition page, the competition challenge board, `ctf_log.py` (start/solve/stuck/drop records)
Concepts needed	The finishing goal, the 30-minute full sweep, the 2-hour rule, dynamic scoring, the retrospective golden time
Today’s deliverable	Competition log CSV + one retrospective memo written right after the end

2-1. The First Competition’s Goal Is Finishing — Scores Start from the Second One

The most common failure in a beginner’s first competition is not "0 points" but dropping out midway. In the frustration of unsolved problems, concluding "I’m not ready yet" and closing the window. So contract the success condition in advance: leaving a log to the very end.

There’s one more reason ranking isn’t the goal — a first competition’s score is not a measurement of skill but noise. Difficulty varies widely between competitions, and lucky problem types inflate you while unlucky ones deflate you. Instead, the real data to collect at this competition is three things.

Which fields produce points — field verification of your main track
Where the time went — the time distribution from start to drop
When your mental game shook — the log’s stuck memos show it directly

2-2. A Competition’s Time Structure — 48 Hours Is "A Day and a Half"

The weekend competition standard is 48 hours: Friday night (Korea time) start, Sunday night end. But the time you can actually use, minus sleep and meals, is barely half. Fix your immersion blocks before the competition.

[48-hour competition time design example] — a planning template, not a screen example
Fri 21:00  Competition starts → 30-minute full sweep → easy-problem warmup
Fri 24:00  Sleep (no all-nighter on night one — an investment that keeps Saturday afternoon's focus alive)
Sat 09:00  Main assault block 1 (main track)
Sat 14:00  Block 2 (harvesting easy problems outside the main track)
Sat 19:00  Block 3 → sleep before midnight
Sun 09:00  Block 4 — concentrate firepower on "the closest problem"
Sun 21:00  End → 30-minute retrospective memo immediately

The point is no all-nighter on night one. Experienced players repeatedly report a pattern — the participant who stays up Friday night watches their judgment collapse Saturday afternoon, and that’s exactly the stretch where scores diverge. In a 48-hour competition, sleep is not desertion; it’s strategy.

2-3. Problem Selection — What the Scoreboard Tells You

A competition challenge board looks roughly like this (screen example):

┌──────────┬──────────┬──────────┬──────────┬──────────┐
│   Web    │   Pwn    │   Rev    │  Crypto  │Forensics │
├──────────┼──────────┼──────────┼──────────┼──────────┤
│ 50  ★12  │ 100 ★3   │ 100 ★5   │ 100 ★8   │ 100 ★9   │
│ 150 ★4   │ 200 ★1   │ 200 ★2   │ 150 ★6   │          │
│ 300 ★0   │          │          │          │          │
└──────────┴──────────┴──────────┴──────────┴──────────┘
(★number = solve count)

The solve count is the de facto difficulty. Recent competition platforms often use dynamic scoring (points drop as more teams solve), so "how many have solved it" is a more honest signal than the displayed point value. The job of the 30-minute full sweep right after the start is reading every problem’s description and noting ① is it my field? ② is the solve count climbing?

The strategy for the first problem is settled: start with the most-solved problem. The reason is not points but flow — an early first flag creates the feeling of "today is a working day," and that feeling becomes the stamina that holds on to the hard problems.

2-4. Why a Log — Memory Gets Deleted When the Competition Ends

Mid-competition, you remember less than you think. After the thrill of a captured shell, "what command did I type then?" is gone; after the frustration of a stuck problem, "how far did I get?" is gone. The quality of the debrief (Step 280) is decided by the quality of in-competition records.

Four kinds of events are enough to record.

Event	Meaning	What to leave in the memo
start	Began a problem	Field, problem name, points
solve	Flag submitted successfully	(solve time recorded automatically)
stuck	Progress halted	The concrete cause of where it stopped
drop	Cut losses	The drop reason (2-hour rule, etc.)

The stuck memo is the core. "Didn’t work" is not debrief material, but "halted at the anti-debugging section" is a debrief starting point. Think of it as a letter to future you and leave one line.

2-5. The 2-Hour Rule — Cutting Losses Is Also a Skill

When 2 hours pass on one problem with no progress, that problem is very likely one today’s you cannot solve. Stepping back then is the 2-hour rule. What matters is that it’s not "giving up" but "holding" — drop it together with a stuck memo, and the problem becomes material for debrief block A after the competition ends.

2 hours is not an absolute value but a baseline. If your total available time in a 48-hour weekend competition is 20 hours, the moment you spend 3 hours on one problem, the opportunity of three or four other problems disappears. In your first competition, better to keep the rule rigid. Exceptions can wait until your third competition, when data has accumulated.

3. Follow Along

3-1. Confirming the Competition and Checking Registration (Screen Example)

Reconfirm the competition you fixed in Step 190. Four things to check.

[Final competition-page check] — screen example
□ Converted the start/end times to my local time and put them on the calendar
□ Created an account on the competition platform (separate site) and confirmed login
□ If team registration is required, completed the team code/invite
□ Read the rules page's prohibitions (automated-scan limits, sharing bans, etc.)

The last item is the legal and rules-based safety device. Every competition has rules like "no DoS-style scanning of challenge servers" and "no publishing write-ups during the competition," and breaking them gets you disqualified. Five minutes of rules reading is the cheapest insurance for your first competition.

3-2. Environment Check — The Day-Before 30 Minutes

If a tool won’t run mid-competition, that time simply evaporates. Run this list the day before.

[Environment check checklist]
- [ ] Kali boots and update state confirmed (no updating on competition day)
- [ ] VPN/network — if any setup is needed for competition infrastructure, test it in advance
- [ ] Core tools per field launch: Burp Suite, gdb/pwntools, Ghidra, CyberChef, Wireshark
- [ ] Penetration playbook (Step 272) current — are the new techniques from recent live machines reflected?
- [ ] Screenshot tool and memo app positioned to stay open at all times
- [ ] ctf_log.py placed in the home directory and run once as a test

3-3. Building the Competition Log Script (Measured)

In-competition recording must be light — it has to end with one line in the shell so the competition flow doesn’t break. Save the following script as ctf_log.py. It’s a tool that stacks events into a CSV and shows a summary with report.

# ctf_log.py — record per-problem start/solve/stuck/drop events to a CSV during a competition
import csv, sys, os
from datetime import datetime

LOG = "ctf_log.csv"
FIELDS = ["time", "event", "field", "problem", "points", "memo"]

def now():
    return datetime.now().strftime("%m-%d %H:%M")

def load():
    if not os.path.exists(LOG):
        return []
    with open(LOG, newline="", encoding="utf-8") as f:
        return list(csv.DictReader(f))

def save(rows):
    with open(LOG, "w", newline="", encoding="utf-8") as f:
        w = csv.DictWriter(f, fieldnames=FIELDS)
        w.writeheader()
        w.writerows(rows)

def add(event, problem_arg, points, memo, at):
    rows = load()
    if " - " in problem_arg:
        field, problem = problem_arg.split(" - ", 1)
    else:
        field, problem = "", problem_arg
    if event != "start":   # events after start inherit field/points from the start record
        for r in rows:
            if r["event"] == "start" and r["problem"] == problem:
                field = field or r["field"]
                points = points or r["points"]
    rows.append({"time": at or now(), "event": event, "field": field,
                 "problem": problem, "points": points or "", "memo": memo or ""})
    save(rows)
    print(f"logged: [{at or now()}] {event} {field + ' - ' if field else ''}{problem}")

There are four commands (report comes in 3-4 below).

python ctf_log.py start "Web - warmup-cookie" 50     # start (points optional)
python ctf_log.py solve "warmup-cookie"              # solve
python ctf_log.py stuck "license-check" "stalled at the anti-debugging section"   # stuck
python ctf_log.py drop "license-check" "2-hour rule triggered"                    # drop

Omit the time and the current time goes in; when tidying up after the competition, you can pass a time like "04-11 21:12" yourself as the fourth argument.

3-4. Operating the Competition — Log Records (Measured)

To see how a first competition’s two days land in the log, we actually recorded an example competition (a fictional "Weekend CTF 1") with the script. Below is the measured output in Git Bash (the times are example data entered in post-entry mode).

$ python ctf_log.py start "Web - warmup-cookie" 50 "04-11 21:12"
logged: [04-11 21:12] start Web - warmup-cookie
$ python ctf_log.py solve "warmup-cookie" "04-11 21:34"
logged: [04-11 21:34] solve Web - warmup-cookie
$ python ctf_log.py start "Crypto - caesar-training" 100 "04-11 21:40"
logged: [04-11 21:40] start Crypto - caesar-training
$ python ctf_log.py solve "caesar-training" "04-11 22:05"
logged: [04-11 22:05] solve Crypto - caesar-training
$ python ctf_log.py start "Rev - license-check" 200 "04-11 22:20"
logged: [04-11 22:20] start Rev - license-check
$ python ctf_log.py stuck "license-check" "stalled at the anti-debugging section" "04-11 23:30"
logged: [04-11 23:30] stuck Rev - license-check
$ python ctf_log.py drop "license-check" "2-hour rule triggered, folding for today" "04-11 23:40"
logged: [04-11 23:40] drop Rev - license-check
$ python ctf_log.py start "Forensics - packet-present" 100 "04-12 09:10"
logged: [04-12 09:10] start Forensics - packet-present
$ python ctf_log.py solve "packet-present" "04-12 09:48"
logged: [04-12 09:48] solve Forensics - packet-present
$ python ctf_log.py start "Web - admin-panel" 300 "04-12 10:20"
logged: [04-12 10:20] start Web - admin-panel
$ python ctf_log.py stuck "admin-panel" "all SQLi payloads blocked" "04-12 12:10"
logged: [04-12 12:10] stuck Web - admin-panel
$ python ctf_log.py start "Crypto - xor-note" 150 "04-12 12:30"
logged: [04-12 12:30] start Crypto - xor-note
$ python ctf_log.py stuck "xor-note" "stuck estimating the key length" "04-12 14:00"
logged: [04-12 14:00] stuck Crypto - xor-note

Read this log and the competition’s story is visible: Friday night, two warmup problems taken fast (22 and 25 minutes each), then the first wall at the 200-point Rev, folded by the 2-hour rule. Saturday morning the flow came back with Forensics, and in the afternoon the 300-point Web and a Crypto blocked in turn. 3 solved, 3 stuck — a perfectly normal first competition, and one with high debrief value.

3-5. Right After the End — The Summary via report (Measured)

When the competition ends (or at a midway check), one report line shows the competition in numbers. Measured output.

$ python ctf_log.py report
=== Competition Log Summary (ctf_log.csv) ===
13 events / 6 problems started / 3 solved

[Solved problems]
  Web        warmup-cookie        50pts  took 22min
  Crypto     caesar-training     100pts  took 25min
  Forensics  packet-present      100pts  took 38min

[Unsolved problems — debrief candidates]
  Rev        license-check      stuck memo: stalled at the anti-debugging section
  Rev        license-check      drop  memo: 2-hour rule triggered, folding for today
  Web        admin-panel        stuck memo: all SQLi payloads blocked
  Crypto     xor-note           stuck memo: stuck estimating the key length

How to read it: ① the solved problems’ times (22–38 min) are your "easy-problem processing speed" — they become the basis for the next competition’s warmup plan. ② the "unsolved problems" list is the target pool for Step 280’s debrief block A. Thanks to concrete stuck memos, even a week after the competition, where you stopped restores immediately.

3-6. The Retrospective Memo — The 30-Minute Golden Time

The retrospective written within 30 minutes of the end is the most accurate. Fill just three paragraphs in this frame.

[Competition retrospective — Weekend CTF 1]
1. Numbers: 3 problems solved (250 pts), rank ○○/○○○, 3 of 6 starts solved
2. What went well: took both warmup problems within 30 minutes and caught the flow
3. What fell short: 2 hours on admin-panel and still stuck — WAF-bypass study lacking
4. Closest unsolved: xor-note (reached as far as the key length)
5. To do before the next competition: debrief block A, 3 problems (license-check, admin-panel, xor-note)

The last item is the link connecting to 3-5’s "debrief candidates." This retrospective memo and ctf_log.csv are all of this chapter’s deliverables — small-looking, but Step 280 and Step 283 run on top of these two files.

4. Missions & Exercises

Mission — Finish Your First Competition

Register for the confirmed weekend competition, and complete 3-2’s environment check the day before.
In the 30 minutes right after the start, sweep all problems and start with the easiest by solve count.
Record every start/solve/stuck/drop in ctf_log.py for the entire competition.
Write the 3-6 retrospective memo within 30 minutes of the end.
Keep the report output and the retrospective memo — they’re used as-is in Step 280.

Exercises

Exercise 1. Give two reasons for setting the first competition’s goal as "finishing and data collection" rather than "ranking."

Exercise 2. Explain why, right after the start, you’re advised to grab the most-solved problem before high-point problems.

Exercise 3. In the 3-4 log, why was dropping license-check the right answer? Explain from the 2-hour rule’s standpoint.

Exercise 4. Connect to the debrief procedure and explain why a stuck memo must be concrete — "stalled at the anti-debugging section" rather than "didn’t work."

5. Model Answers & Completion Criteria

Mission Model Answer

How to verify: ① open ctf_log.csv — do events span from competition start to end? If only day one is filled and day two is empty, that’s a mid-dropout signal. ② are stuck/drop memos descriptions of where it stopped, not "didn’t work"? ③ does the retrospective memo contain numbers (problems solved, points) and the "closest unsolved"? ④ are 3+ unsolved problems left in the log, fixing the next debrief targets? Even if you solved zero problems, if ①–④ are filled, this mission is a success — a 0-point log is also complete data.

Exercise Answers

Answer 1. ① A first competition’s score is swayed by per-competition difficulty variance and problem-type luck, so it can’t serve as a skill measurement. ② The log left by finishing — which fields produced points, where the time went — becomes the raw material for the next competition’s strategy and for the debrief. Ranking starts meaning something from the second competition.

Answer 2. Solve count is the de facto difficulty indicator, and solving an easy problem early creates an "it’s working today" flow up front. That flow (morale) becomes the source of the focus that holds the late hard problems. With dynamic scoring, solving early also keeps the point value high — a side benefit.

Answer 3. From the 22:20 start to the 23:30 stuck there was no progress for 70 minutes, and the memo says "anti-debugging section" — a type a beginner can’t break mid-competition without study. Spending the rest of night one on this problem costs even Saturday morning’s condition. Holding it with a drop lets you learn it from write-ups after the competition, protecting both that day’s time and the problem’s learning value.

Answer 4. Debrief block A’s first question is "how far did I get?" With a concrete memo, you can compare the correct write-up against your frontier and find "the next one step" immediately, but "didn’t work" has no comparison baseline, so the debrief itself is impossible. Record concreteness is the debrief’s starting-point coordinates.

Completion Criteria Checklist

[ ] I can explain why the first competition’s goal is "finishing and data collection"
[ ] I completed the day-before environment check (tools, accounts, playbook)
[ ] I executed the 30-minute full sweep and the "most-solved first" strategy
[ ] I left start/solve/stuck/drop records with times
[ ] I consciously applied the 2-hour rule at least once
[ ] I wrote the retrospective memo within 30 minutes of the end
[ ] I confirmed the debrief candidate list in the report output

6. Common Pitfalls & Fixes

Wall 1. I misread the start time and lost day one

Symptom: you connect Friday evening and the competition hasn’t opened — or it’s already running.

Cause: CTFtime displays UTC. Korea is UTC+9, so a Friday 12:00 UTC start is Friday 9 PM Korea time.

Fix: when putting competition times into your calendar app, convert to local time from the start. Set two alarms: one hour before, and at the start.

Wall 2. My flag is right but submission fails

Symptom: this message appears on submission (screen example — varies by platform).

Incorrect flag. You have 4 attempts remaining before a 60 second lockout.

Likely cause #1: whitespace or a newline got copied along with the flag. #2: flag formats differ per competition (flag{...}, CTF{...}, a competition-name prefix).

Fix: trim leading/trailing whitespace before submitting, and check the flag format written in the problem description. Repeated failures lock you out and the submission attempts themselves become time loss — the habit of reading the format notes in problem descriptions at the start is the answer.

Wall 3. I clung to one problem and the competition ended

Symptom: "just a little more and I’ve got it" ate four hours, and the log has one event.

Cause: time sense turns off mid-immersion. The 2-hour rule is kept by devices, not willpower.

Fix: start a 2-hour timer the moment you start a problem. When the timer rings, ask "when did I last learn a new fact?" — if the answer is an hour ago, drop is the right answer.

Wall 4. The log script throws an error

Symptom (measured):

$ python ctf_log.py stuck onlyname
Traceback (most recent call last):
  File ".../ctf_log.py", line 81, in <module>
    add("stuck", sys.argv[2], "", sys.argv[3], ...)
IndexError: list index out of range

Cause: stuck and drop require the memo argument, and it was omitted.

Fix: always attach the memo, like python ctf_log.py stuck "problem-name" "where it stopped". A memo-less stuck has no debrief value anyway — the script is right here.

Wall 5. The competition ended without a single solve

Cause: the first competition pick was too heavy, or the problem types simply didn’t fit. Neither is evidence of lacking skill.

Fix: write "which field came closest?" in the retrospective — that’s the next goal. If stuck memos remain, this competition is not 0 points but a competition that secured 3 debrief materials. Adjust difficulty by picking a "Beginner/Junior"-labeled competition next, and fill the stuck types with Step 280’s debrief.

7. Summary

Today’s Concepts

Concept	One-line explanation
The finishing goal	The first competition’s success condition is the log left to the end, not points
30-minute full sweep	The time right after the start to read every problem description and note field/solve count
Solve count	The de facto difficulty indicator — a more honest signal than points
Dynamic scoring	Points drop as more solve — earlier is better
The 2-hour rule	No progress for 2 hours → drop (hold) — cutting losses is also a skill
Competition log	Timestamped records of the four events start/solve/stuck/drop — debrief raw material
Retrospective golden time	The 30 minutes right after the end — retrospectives written while memory lives are most accurate

Today’s Commands

Command	What it does
`python ctf_log.py start "field - problem" points`	Record starting a problem
`python ctf_log.py solve "problem"`	Record a flag solve
`python ctf_log.py stuck "problem" "where it stopped"`	Record a stall — memo required
`python ctf_log.py drop "problem" "reason"`	Record a loss-cut (hold)
`python ctf_log.py report`	Solved/unsolved summary — the debrief candidate list

The Core Instinct

A competition is not an exam — it’s a measuring device. What you bring home from the first competition is not points but "the coordinates of my skill" — which fields work, which types stop you, where time leaks. Only with coordinates can a map be drawn, and that map’s first stretch is the next chapter’s debrief.

And one more — browse the competition chat. People who came alone, people stuck on the same problems — they’re all there. Today’s finish becomes the bridge to Step 281’s team competition.

Once every box is checked, Step 279 is complete. Click the checkbox in the sidebar to save your progress.