Writeup on FortID CTF 2026: Pwn / Fortune Teller

Three files, one of them the C source - so no reversing is needed to find the bug.

2. Docker/nc - what we get

A per-team instance, reachable over TLS - plain nc will not do, the client has to wrap the connection:

Option 2 is the win condition and it reports the current value of the counter, which is a convenient oracle for checking whether a write landed. The menu loops, so the format string bug can be used as often as needed - leak first, write second.

3. Analysis steps

3.1 Read the source, confirm the protections (success)

The handout ships chall.c, so the first look goes there rather than into a disassembler.

printf(question) with user-controlled question is a textbook format string vulnerability. The protections confirm what it has to be used for:

Conclusion: no shellcode (NX), no GOT overwrite (Full RELRO), no return address games worth the trouble (canary plus Shadow Stack and Indirect Branch Tracking). But none of that is needed: blessing is an ordinary writable global, and receive_blessing() calls win() for us. Two things are required - the runtime address of blessing (PIE), and a write primitive.

3.2 Leak the base with %p (success)

%p prints whatever happens to sit in printf's argument slots. Walking the slots until something looks like a code pointer gives the PIE base.

Repeat it to see that the value moves with Address Space Layout Randomization (ASLR) and keeps its shape:

Conclusion: with the %33$p leak, proc_base = leak - 0x2d68 and blessing = proc_base + 0x304c. Note that proc_base here is the text page, not the ELF base - the two differ by 0x1000, which matters later in 3.7.

3.3 Find the slot that the write has to point at (success)

%n writes the number of characters emitted so far to the address in its argument slot. Nobody passes such an argument here, so printf reads it off the stack - and the stack is where our own buffer lives. The question is which slot number corresponds to the buffer.

question sits at rbp-0x110, and because the frame is set up with a single sub $0x110, %rsp and nothing is pushed afterwards, rsp at the printf call is the same address. On the System V AMD64 ABI the first five variadic arguments come from registers and the sixth is the first stack slot - which is therefore question[0]:

That is everything needed to build the payload. 0x1337 is 4919 decimal, so %4919c drives the character counter to exactly the wanted value (a width in %c counts the printed character itself), and %8$hn stores it as two bytes. blessing is a 4-byte unsigned int in .bss and starts out zero, so writing only the low half is enough:

Two details are load-bearing. The format string is 11 bytes, which would put the address at a non-aligned position, hence the padding to 16 - slot boundaries are 8 bytes apart, and 16 lands on slot 8. And the address has to come after the conversions: it contains null bytes, at which printf stops reading. The null bytes do reach the buffer, because read_line() only stops at a newline.

Conclusion: one menu iteration to leak, a second one to write. Works locally.

3.4 Remote: the connection just hangs (failed)

The local exploit was correct, so switching process() for remote(..., ssl=True) should have been the whole porting effort.

Probing the host by hand shows why. The name carries both an A and an AAAA record, and only one of them works - the IPv6 address accepts the TCP connection and then never completes the TLS handshake:

Worth noting while poking at the name: an invented hostname in the same domain resolves to the very same pair of addresses, i.e. there is a wildcard record. A name that resolves proves nothing about the instance being alive.

Conclusion: pwntools defaults to fam='any' and picks the AAAA record on a dual-stacked machine, so it hangs where ncat happened to pick IPv4 and worked. Forcing the family fixes it: remote(host, port, ssl=True, fam='ipv4').

3.5 Remote: the leak is unstable (failed)

%33$p had been rock solid across ten local runs, so it was taken as a reliable offset.

It is not. Slot 33 is 27 quadwords past the start of the buffer, i.e. 216 bytes inside question[256] itself. read_line() writes only what was typed plus a terminator, so everything behind that is stale stack data left over from earlier calls. It reproduces perfectly as long as the program takes the exact same path every time, and stops reproducing the moment anything before it differs.

Conclusion: use slot 41 instead. From the slot table in 3.3 that is ask_oracle's saved return address, a real pointer rather than garbage, and it always points just past the call site in main at 0x1664.

3.6 The leak offset and the base arithmetic belong together (failed)

Leak	base	target
`%33$p`	`leak - 0x2d68` (text page)	`+ 0x304c`
`%41$p`	`leak - 0x1664` (ELF base)	`+ 0x404c`

Both pairs are individually correct and arrive at the same address - the old proc_base is just the text page, one page above the ELF base, which is why 0x304c and 0x404c differ by 0x1000. Mixing them put the write 0x2704 bytes off target, into a read-only page, and the segmentation fault surfaced as the EOFError. The debug trace shows it precisely: 4864 of the 4919 spaces had already arrived, so the counter ran fine and the process died on the store itself.

Conclusion: elf_base must end in 000. The printed 0x55f375c938fc was visibly wrong before anything was even sent - a free sanity check worth building in.

3.7 All three fixes together (success)

Conclusion: fam='ipv4', %41$p, and -0x1664/+0x404c. Flag on the first try.

4. Solution

5. Run it

6. Summary of how the exploit works

#	Stage	Mechanism
1	Leak the ELF base	`%41$p` prints `ask_oracle`'s saved return address, which is always `elf_base + 0x1664`. Slot 41 is `rbp+0x08`, past the buffer, the canary and the saved `rbp`.
2	Locate the target	`blessing` is at `elf_base + 0x404c` per `nm` - a writable `unsigned int` in .bss, so Full RELRO, NX and the canary are all irrelevant.
3	Put the target address into an argument slot	`question[256]` sits at `rbp-0x110`, which equals `rsp` at the `printf` call, so the buffer is printf's first stack argument (slot 6). Padding the format string to 16 bytes places `p64(blessing)` in slot 8. It has to go last, because the address contains null bytes.
4	Drive the character counter to 0x1337	`%4919c` emits 4919 characters, and 4919 == 0x1337. The field width counts the printed character itself.
5	Write	`%8$hn` takes slot 8 as a pointer and stores the counter there as two bytes. The upper half of the `unsigned int` is still zero from .bss, so `blessing == 0x1337` exactly.
6	Collect	Menu option 2 passes the comparison in `receive_blessing()`, which calls `win()` - and that simply prints `flag.txt`.

Writeup on FortID CTF 2026:
Pwn / Fortune Teller

Contents

0. Challenge description

1. Download

2. Docker/nc - what we get

3. Analysis steps

3.1 Read the source, confirm the protections (success)

3.2 Leak the base with `%p` (success)

3.3 Find the slot that the write has to point at (success)

3.4 Remote: the connection just hangs (failed)

3.5 Remote: the leak is unstable (failed)

3.6 The leak offset and the base arithmetic belong together (failed)

3.7 All three fixes together (success)

4. Solution

5. Run it

6. Summary of how the exploit works

7. Visual Summary

Writeup on FortID CTF 2026: Pwn / Fortune Teller

Contents

0. Challenge description

1. Download

2. Docker/nc - what we get

3. Analysis steps

3.1 Read the source, confirm the protections (success)

3.2 Leak the base with %p (success)

3.3 Find the slot that the write has to point at (success)

3.4 Remote: the connection just hangs (failed)

3.5 Remote: the leak is unstable (failed)

3.6 The leak offset and the base arithmetic belong together (failed)

3.7 All three fixes together (success)

4. Solution

5. Run it

6. Summary of how the exploit works

7. Visual Summary

Writeup on FortID CTF 2026:
Pwn / Fortune Teller

3.2 Leak the base with `%p` (success)