Selective Memory

The challenge

Objective-C never forgets: every class, every selector, every string is registered and waiting. Read the persistence descriptor and learn what this binary remembers.

140 questions in the Single Solve: 10 per day for Days 1 to 14. Earlier days' questions are the same as yesterday's. The 10 new d14_* fields:

Answer kinds across all 140: 72 exact text, 49 pattern, 9 integer, 5 JSON, 5 enum.

Reading the prompt: what it said we'd need

Safety

Static only. The evidence zips (≈32 MB each, AES-encrypted with the usual lab password) were read in memory on our Kali VM with python3 -I. No binary was executed. For this write-up I re-read the saved zips the same way (section table, symbol names, .rodata strings, the HCFG record) and made no Game Master calls.

What was in the files

One evidence.zip with 15 members, one program per day (d03 also has its runtimeconfig.json). The Day 1 to 13 files were byte-identical to Day 13's: all 130 earlier answers today equal yesterday's.

The new file, d14--variant-000.elf (17,304 bytes):

• 64-bit x86-64 ELF, linked with gold 1.16. It needs libobjc.so.4.6 and libgnustep-base.so.1.27: a GNUstep Objective-C build.
• Sections include .hcfg and the GNUstep v2 runtime sections __objc_selectors, __objc_classes, __objc_class_refs, __objc_constant_string, and others.
• One class, TriggerDescriptor (subclass of NSObject), with an ivar _triggerName, a read-only triggerName property, and the methods initWithTrigger: and eventCountForModel:. One constant string: UserLogin.
• A .rodata trace template that describes itself as harmless. Defanged excerpt: "family":"non_mutating_trigger_plan","effects":"synthetic_trigger_plan_only",...,"network":"none".
• The HCFG record: raw (not Base64) at file offset 4000, which is the start of .hcfg. Version 1, XOR key 0xa1, 367 bytes, CRC-32 0x79f491da. Keys: campaign BR14-000, domain, ipv4 (a documentation-range address), url, mutex, windows_path, linux_path, service, host_model. All hosts are under .invalid.

The timed variants used the same template with different values. Every Day 14 file in every zip is 17,304 bytes with the record at offset 4000; only the variant number (and so the config values and CRC) changes:

Single Solve (solver, 3 batches)

The solver's core already covered all 10 new fields. No new plug-in was written. The solver picked up the new challenge by itself and used its core; it had last been changed on 2026-10-11.

How the core answered each new field:

• SHA-256: hash of the member's bytes.
• format / architecture / machine: the ELF magic gives elf; e_machine 62 gives x86-64 and 62.
• config fields and CRC-32: the HCFG reader finds the one CRC-checked HCFG record and reads its keys.
• has_hcfg_section: the Day 10 (Zig Zag) rule: is any ELF or PE section named .hcfg? Here, true.

The solver sent the core's answers first, then the two plug-ins'. Every batch was accepted:

The Day 1 ELF batch carried a warning from the solver's answer history: ELF64 had once been rejected on a different question. It is still the right form for d01_analysis_elf_class and was accepted again.

Question families in the 140 (all accepted on the first send):

CORRECT at 13:00:47 UTC, flag 9da1df0f…af4a. The solver records no lap timings for the untimed Single Solve.

Time Trial

started_at   2026-10-14T13:00:54.036Z   deadline 13:01:24.036Z (30 s)
artifact     evidence.zip, 32.2 MB, Day 14 = d14--variant-002.elf
answers      140, one submit
             d14_analysis_config_mutex: Global\HuntressBR14_002
             d14_analysis_config_url: https://node-002.day14.example.invalid/api/BR14-002
             d14_analysis_config_crc32_hex: 0x9fab14e7
             d14_analysis_has_hcfg_section: true
laps         start 548, artifact 776, solve 598, ready 0, submit 957, TOTAL 2881 ms
vs started_at: start +121, artifact +897, solve +1496, ready +1496, submit +2454 ms
result       CORRECT 13:00:55.915Z   flag e6688b5a…f372

Mastery

started_at   2026-10-14T13:01:03.235Z   deadline 13:01:33.235Z (30 s)
artifacts    3 streamed downloads: 01/02/03-evidence.zip, 32.2 / 32.4 / 32.2 MB
             set 2 is the PE/ELF mix (d02, d04, d10 as PE .exe); Day 14 is ELF in all three sets
answers      420 (140 per set), one submit
             e.g. set2.d02_analysis_format: pe, set2.d10_analysis_machine: 34404 (PE x86-64),
                  set1/set3 d10 machine: 62 (ELF), set1-3 d14_analysis_has_hcfg_section: true
laps         start 1185, dl2 1010, dl3 506, dl1 46, artifact 0, solve 672, ready 1, submit 1257, TOTAL 4678 ms
vs started_at: start +232, dl2 +1242, dl3 +1749, dl1 +1795, artifact +1795, solve +2467,
             ready +2468, submit +3725 ms
result       CORRECT 13:01:06.236Z   flag e1c0ac30…7f85

The three downloads ran at the same time and finished out of order (2, 3, then 1). The solve lap ended 672 ms after the last one landed.

Both timed start replies said hall_of_fame_eligible: false and unique_attempts_remaining: 0, as on earlier Binary days. These times aren't ranked and no retry is possible.

Time to solve

All three modes were solved by 09:01:06 ET, 24.1 s from the first start to the last CORRECT; the Single Solve's three batches were all accepted, and the Time Trial and Mastery each went through on the first submit. Both timed runs were unranked.

Takeaways

• The prompt's language doesn't decide the questions. It talked about classes, selectors, and strings, but the questions were the same field set as every day. The Objective-C metadata was never asked about.
• Structure-based parsers carried one more language. ELF header, section table, and the CRC-checked HCFG search covered GNUstep Objective-C with no change. That's the payoff of answering by structure and not by language.
• Old rules pay off later. has_hcfg_section was added on Day 10 for Zig; today's build also kept the record in its own section, and the rule answered it unchanged.
• Downloads are still most of the Mastery clock: about 1.6 s of 3.7 s went to three 32 MB zips.