Runic is a heap exploitation challenge implementing a "rune" (string) management system with alloc, free, edit/rename, and show operations. The vulnerability is a heap overflow triggered by a null-byte name collision in the edit function: a name like "A\x001" matches "A" during lookup (C string comparison stops at the null byte) but stores the full 2 bytes, allowing one rune's edit to overflow into adjacent chunks. The exploit chains this overflow into three successive tcache poisoning attacks -- for libc leak, stack leak, and ROP -- demonstrating the standard modern heap exploitation methodology with safe-linking bypass.

The binary stores named "runes" with associated content buffers. The edit function takes a name to look up the rune and a new name to rename it to. The critical flaw:

edit(current_name="B", new_name="A\x001", data=<overflow payload>)

When looking up the rune to edit, the binary uses strcmp() or equivalent, which compares C strings. "A\x001" is compared as "A" because strcmp stops at the first null byte. But the new name is stored in full, including the null byte and subsequent bytes.

This creates a collision: the rune originally named "A" can now be found by either "A" or the truncated form of "A\x001". More importantly, the edit operation writes data to the content buffer of the rune found by the lookup -- but the name change may have altered which rune is targeted, allowing the write to go to a different (smaller or freed) buffer than intended, causing a heap overflow.

When rune "B" is renamed to "A\x001", the edit writes data to rune "B"'s content buffer. But if rune "B"'s content buffer is adjacent to rune "C"'s metadata (which it is in a controlled heap layout), the data overflows into C's chunk header:

Before edit: