strings core.dump | head -20 Noticed a binary name: ./bad_memories_v0.9 and a suspicious string: [!] You found a secret? Try -recreation- .
Also found references to malloc , free , heap , and flag.txt . Since only the core dump was given (no original binary), we need to recreate the binary or at least its memory layout.
file core.dump Output:
Using gdb with the core file:
eu-unstrip -n --core=core.dump This reveals the missing binary path and build ID. We can fetch or reconstruct. After recovering the binary (named bad_memories_v0.9 ), analyze it:
strings core.dump | grep -i ctf Returns:
(gdb) set void *(char *)0x6020a0 = 0x401456 (gdb) call (*(void(*)(char*))0x6020a0)(0x6020a0+8) Output: Bad Memories -v0.9- -recreation-
(gdb) x/10gx 0x6020a0 Shows 0x401456 in the vtable slot – that’s the secret function address!
However, this core dump is process-only. Use elfutils :
[0x00401234]> afl | grep secret 0x00401456 sym.secret_function Disassemble secret_function : strings core
gdb -c core.dump Inside GDB:
So a note was freed, then its print_func pointer was overwritten via another allocation (use-after-free write), pointing to the secret function. The core dump captured the program after the exploit but before the flag was printed. We can manually trigger the print:
In GDB, call the overwritten function:
struct note void (*print_func)(char *); char data[56]; ; Found a pointer at 0x602010 pointing to a function 0x400c80 (normal print) and another at 0x6020a0 pointing to 0x401456 (secret function).
gdb -c core.dump ./bad_memories_v0.9 (gdb) info registers (gdb) x/20gx $rsp Look for a struct: