Bad Memories -v0.9- -recreation- Access

(gdb) set void *(char *)0x6020a0 = 0x401456 (gdb) call (*(void(*)(char*))0x6020a0)(0x6020a0+8) Output:

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:

[0x00401234]> afl | grep secret 0x00401456 sym.secret_function Disassemble secret_function :

Loading memory... [1] Allocate [2] Write [3] Read [4] Free [5] Exit A heap note manager – likely vulnerable to UAF (use-after-free) or double-free. Bad Memories -v0.9- -recreation-

(gdb) x/10gx 0x6020a0 Shows 0x401456 in the vtable slot – that’s the secret function address!

gdb -c core.dump Inside GDB:

gdb -c core.dump (gdb) dump memory recovered.bin 0x400000 0x401000 # typical .text section But better: use volatility (if full memory dump) or memdump from /proc/pid/maps style. (gdb) set void *(char *)0x6020a0 = 0x401456 (gdb)

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:

Flag: CTFBad_Memories_Unleash_Secret_Recreation Alternatively, the flag might already be in memory. Dump all strings from core:

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). [1] Allocate [2] Write [3] Read [4] Free

CTFBad_Memories_Unleash_Secret_Recreation To recreate the vulnerability locally:

Check with radare2 :

(gdb) info files Shows the executable was bad_memories_v0.9 . We can try to recover the binary from memory:

(gdb) call ((void(*)(char*))0x401456)(0x6020a0+8) Or simply: