ELF Aware

The challenge

Before you can reverse anything, you have to learn to read. These plain C binaries are your primer: headers, section tables, symbol tables. Start with readelf -h -S and work your way down.

Nine questions per binary. Every text answer is checked exactly (case and spelling matter).

For exact text, the format adds: "use the literal none only when the requested field is absent." That sentence turned out to be the key to Mastery.

Reading the prompt: what it said we'd need

Safety

Static analysis only. No binary was ever executed. Each ELF was extracted with its execute permission removed, then read with readelf and objdump. Constants were read from the disassembly, not by running the code.

What was in the files

Every binary was the same small C program: main, _start, the standard C runtime helpers, one custom function at 0x401120, and a custom .huntress section. The variants changed only the custom function's name, its constant, the marker, and whether the symbols were stripped.

The Single Solve's symbol-orientation.elf (15,560 B), from readelf -h:

  Class:                             ELF64
  Data:                              2's complement, little endian
  Type:                              EXEC (Executable file)
  Machine:                           Advanced Micro Devices X86-64
  Entry point address:               0x401030

• 27 sections, including [14] .huntress (24 bytes at 0x402010) and [24] .symtab.
• .huntress: BR01-SYMBOL-ORIENTATION, followed by a NUL byte.
• Symbols: besides the standard ones, one GLOBAL FUNC recover_code at 0x401120 (6 bytes), and one LOCAL OBJECT huntress_marker (the .huntress string).
• recover_code's whole body:

text 401120: mov $0x539,%eax 401125: ret

It returns 0x539 = 1337. The compiler also inlined the same constant into main (movl $0x539,…).

The four variants seen across the timed modes:

Everything else was identical in every file: ELF64 / little endian / x86-64 / EXEC, and entry 0x401030.

How the stripped file's function was found without a name: two independent clues. 1. The same place: at 0x401120, exactly where recover_code sits in the other variants, is the same two-instruction stub. 2. main uses the same constant. _start hands 0x401020 to __libc_start_main, which makes 0x401020 main, and main starts by loading the same constant.

Single Solve: CORRECT

The certain answers went in together first (a partial submit), and came back accepted, remaining 5: - marker = BR01-SYMBOL-ORIENTATION - has_symtab = true - recover_code = 1337 - entry_point = 0x401030

exported_symbol = recover_code, tested alone → accepted. It's the only non-standard GLOBAL function. huntress_marker was the other candidate, but it's a LOCAL object.

Then the four header fields, one request each:

The checker's vocabulary is a mix of styles, so each field has to be worked out on its own. 11 requests in total. CORRECT, flag 4f330c02…4526.

Time Trial: CORRECT in 2.48 s (on the 4th attempt)

The timed runs were driven by the Homebase agent, using scripts it wrote on the Homebase. Claude analysed each failed delivery offline (downloads still work after expiry) and refined the rules between attempts.

Flag 32991031…c627.

Mastery: CORRECT in 3.42 s (on the 6th attempt)

Two sets, each its own evidence.zip with several slot files. The answer format for recover_code is fixed per set before any files exist: exact text in set 1, an integer in set 2.

Every uncertain field went in alone, so a wrong theory never cost the confirmed answers:

Flag a7984627…8033. Between attempts 5 and 6, both Claude and the Homebase agent re-examined the integer set's files independently. Neither found any other number in them. A friend's confirmation that Mastery was solvable is what prompted testing the rule (none) instead of another value.

The confirmed rules

Time to solve

All three modes were solved on 2026-10-02 by 22:43:48 UTC, 1 h 16 min after the Single Solve started. The Single Solve took about 5 minutes; the Time Trial went through on its 4th attempt (2.48 s) and the Mastery on its 6th (3.42 s), with each failed attempt studied offline before the next.

Takeaways

• Read the question literally. "The constant returned by recover_code" meant that name. When it's absent, the answer is none, not the constant of whatever replaced it.
• A format label can be a template, not a fact. The "integer" label was set per set before the files existed. When a label conflicts with a confirmed rule, test the rule once.
• Get the certain answers accepted first, then test each uncertain one on its own. Partial progress survives an incorrect, so a wrong theory costs nothing else.
• A checker's vocabulary can mix styles (ELF64, little, x86-64, ET_EXEC). Confirm each field separately.
• Expired attempts are still useful. Downloads keep working, so every failed delivery could be studied offline.
• Stop safely, then widen the rule. Each of the agent's stops (renamed, slots, stripped) showed a variant the rules didn't cover yet.
• When the evidence runs out, check which constraint you're treating as fixed before calling it unsolvable.

Appendix: the Homebase agent's run log and approach

From the Homebase agent's own records. It recorded only total times, not per-phase timings.**

How its scripts work, in summary: an analyser reads each ELF statically: header, sections, symbol tables, the .huntress marker, and the custom function's return constant. It stops on anything ambiguous. A runner drives the Game Master: it takes the answer IDs and formats from the start reply, verifies each delivery's hash, maps each set's slots to its own files, and submits the confirmed answers in one batch and every uncertain one alone.

Its key lesson: "The answer IDs determine the file-to-slot mapping; the questions array can be a reusable template."