Funkynator — Hack The Box

Description

No original organizer description was preserved in the task files.

The binary lets us create, save, revisit, and edit heap-backed messages. Despite strong mitigations and a modern provided glibc 2.41, one unchecked byte-write primitive is enough to build a full heap-to-stack exploitation chain.

Analysis

Binary summary

• Binary: challenge/funkynator
• Provided libc: challenge/glibc/libc.so.6
• Protections: Full RELRO, NX, Canary, PIE

Core bug

The vulnerability is in process_message().

puts("please give the offset of the byte:");
size_t offset;
scanf("%lu", &offset);
...
message[offset] = (char)value;

offset is read as an unsigned long and never validated, so the menu option overwrite byte becomes an arbitrary relative one-byte write from the current heap chunk. That lets us:

• corrupt the current chunk header,
• extend printing into adjacent chunks,
• overwrite freed-chunk metadata such as tcache fd pointers.

Important reversing notes

funkify() only changes alphabetic characters to alternating case. Non-alphabetic bytes are left untouched, so heap metadata, pointer bytes, and ROP payload bytes survive as long as we avoid alphabetic characters where needed.

Why the first FSOP idea failed

The initial plan was a House of Apple 2 / _IO_list_all attack. That line of attack was abandoned for a good reason:

1. Reaching _IO_list_all did not trigger code execution.
2. Even replacing _IO_list_all with a sentinel like 0xdeadbeef still produced a normal exit.
3. That strongly suggested the expected flush path was not reached in a useful way for this binary/libc combination.

Instead of forcing FSOP further, the successful exploit pivoted completely to a more direct path: libc leak -> safe-linking key leak -> tcache poison -> environ leak -> stack ROP.

Solution

Step 1: Leak libc from unsorted-bin metadata

...