The challenge
"Crystal compiles to native code with a distinctive shine. Fingerprint the runtime, then follow the DNS labels — this one has somewhere it wants to resolve."
130 questions in the Single Solve: 10 per day for Days 1 to 13. Earlier days' questions are the same as Day 12's. The 10 new d13_* fields have the same shapes as Day 12's:
answer_id |
Asks for | Format |
|---|---|---|
d13_ |
SHA-256 of the Day 13 file | exact text |
d13_ |
processor architecture from the header | pattern (name, tool label, or machine code) |
d13_ |
container format | exact text |
d13_ |
the header's machine field | pattern (label or decimal/hex code) |
d13_ |
config campaign |
exact text |
d13_ |
config domain |
exact text |
d13_ |
config mutex |
exact text |
d13_ |
config url |
exact text |
d13_ |
the config record's CRC-32 | 0x + lowercase hex |
d13_ |
where the HCFG record starts | base-10 integer |
Answer kinds across all 130: 66 exact text, 46 pattern, 9 integer, 5 JSON, 4 enum.
Reading the prompt: what it said we'd need
| Clue | What it pointed to | What I did about it |
|---|---|---|
| "Crystal compiles to native code" | a binary from the Crystal language (compiled through LLVM to a native executable) | Nothing new. Our Binary solver reads the ELF header and the embedded config, not the source language |
| "Fingerprint the runtime" | Crystal links its own runtime and standard library into the program | No question asked about it. The format, architecture, and machine fields came from the ELF header as usual |
| "follow the DNS labels", "somewhere it wants to resolve" | a hostname in the config | The config's domain and url keys, read by the solver's HCFG reader |
Safety
Static only. The evidence zips (≈32 MB each) were read in memory on our Kali VM. No binary was executed. This write-up was built from the solver's records, the saved Game Master replies, our record of ranked times, and the request log only. The zips weren't reopened for it.
What was in the files
One evidence.zip (32.2 MB) with one program per day. The solver's record shows these answers for the Day 13 file in the Single Solve set:
- format
elf, architecturex86-64, machine62: a 64-bit x86-64 ELF; - config campaign
BR13-000, domainnode-000.day13.example.invalid, mutexGlobal\HuntressBR13_000, urlhttps://node-000.day13.example.invalid/api/BR13-000, CRC-320xa69b7e61; - HCFG record at file offset 560,188 (Day 12's Pascal build had it at 82,928); SHA-256
6d141b21…e0df.
Unconfirmed: the Crystal runtime details the prompt hints at (symbols, sections, file size). No question asked about them, and the file wasn't reopened for this write-up.
The timed variants used the same template with different values. The Time Trial's Day 13 file was variant 007 (Global\HuntressBR13_007, 0x6c8999d9), still at offset 560,188, and so was the Mastery's set 3.
Single Solve (the solver, 3 batches)
The core already covered all 10 new fields. No new add-on was written. The morning solver picked up the new challenge by itself with the core Binary solver, sent the core's answers first, then the two add-ons'. Every batch was accepted:
| Batch | Sent | Result | Open after |
|---|---|---|---|
| core | 115 | accepted | 15 |
| d01 ELF add-on (Day 1 ELF basics) | 9 | accepted | 6 |
| d02 config add-on (Day 2 HCFG fields + XOR key) | 6 | CORRECT |
The d01 ELF batch included ELF64, once rejected on a different question; it was accepted again. Nothing was rejected. CORRECT at 13:00:47.698 UTC, flag 0f28af3e…00b0.
Time Trial
The start reply said unique_attempts_remaining: 0 and unranked. The clock was 80 s (Day 12's Binary routes had 30 s).
started_at 2026-10-13T13:00:54.283Z deadline 13:02:14.283Z (80 s)
artifact evidence.zip, 32.2 MB, Day 13 = variant 007
answers 130, one submit
d13_analysis_config_mutex: Global\HuntressBR13_007
d13_analysis_config_url: https://node-007.day13.example.invalid/api/BR13-007
d13_analysis_config_crc32_hex: 0x6c8999d9
d13_analysis_hcfg_offset: 560188
laps start 463, artifact 833, solve 599, ready 0, submit 840, TOTAL 2735 ms
vs started_at (client clock): start +115, artifact +949, solve +1547, ready +1548, submit +2387 ms
result CORRECT 13:00:56.091Z flag 78198067…483d
Mastery
started_at 2026-10-13T13:01:03.071Z deadline 13:04:23.071Z (200 s)
artifacts 3 streamed downloads: 01/02/03-evidence.zip, 32.2 / 32.3 / 32.2 MB
answers 390 (130 per set), one submit; e.g. set3.d13_analysis_hcfg_offset: 560188
laps start 894, dl3 801, dl2 692, dl1 393, artifact 1, solve 538, ready 1, submit 1329, TOTAL 4648 ms
vs started_at (client clock): start +235, dl3 +1036, dl2 +1728, dl1 +2121, artifact +2122, solve +2660,
ready +2661, submit +3989 ms
result CORRECT 13:01:06.370Z flag cc96598c…c14b
The three downloads ran at the same time and finished out of order (3, 2, then 1). About half the clock went to downloads (2.1 s of 4.0 s).
Later: ranked retries
On 2026-10-15 Days 13–14 began to accept ranked-clock requests with fresh pools. The Mastery now came as five zips (650 answers, 320 s clock). On a retry, the submit reply's solved_by.at still shows the first CORRECT, so these are our own client-side laps.
| When (ET) | Route | Submit after started_at |
Note |
|---|---|---|---|
| 10-15 13:09 | Time Trial / Mastery | +3.91 / +14.00 s | Slow server: the Mastery's five downloads took until +9.7 s |
| 10-15 22:37 | Time Trial / Mastery | +3.32 / +5.42 s | Healthier server |
| 10-15 23:44 | Time Trial / Mastery | +6.30 / +5.00 s (ready 2.59 / 3.73 s) |
The CTF-only fast path: answers from a memo of our own solver's earlier answers, keyed by each zip member's name, CRC-32, and size (it works only because the generator reuses a fixed pool of variant files); solve ~5 ms. The Time Trial's download was slow, so the earlier time stood |
Boards after all of 2026-10-15's passes: Time Trial 4th of 15 (2.646 s), Mastery 2nd of 11 (4.302 s). The top times (0.155 s and 0.224 s) are too fast to include a full download of a multi-MB zip; we haven't worked out how.
Time to solve
The morning solver started the Single Solve at 13:00:42 UTC and had it CORRECT 5.3 s later; the Time Trial (1.8 s) and Mastery (3.3 s) each went CORRECT on the first submit, unranked, for 23.9 s from the first start to the last CORRECT. Ranked retries on 2026-10-15 ET (three passes, all CORRECT) set the board times above.
Takeaways
- The prompt's language doesn't decide the questions. "Fingerprint the runtime" was never asked; the questions were the usual field set, and the parser that read Day 12's Pascal build read Day 13's Crystal build unchanged.
- The same record, a bigger program. The HCFG record moved from offset 82,928 to 560,188; a search by structure and CRC doesn't care where it sits.
- Mastery is download-bound. Solve was ~0.5 s; downloads were half the day's run and most of the slow ranked one.