[0x00401234]> afl | grep secret 0x00401456 sym.secret_function Disassemble secret_function :
Check with radare2 :
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.
chmod +x bad_memories_v0.9 ./bad_memories_v0.9 It prints: Bad Memories -v0.9- -recreation-
Flag: CTFBad_Memories_Unleash_Secret_Recreation Alternatively, the flag might already be in memory. Dump all strings from core:
But it’s never called normally. The challenge name "Bad Memories" + -recreation- hints we need to force a UAF to redirect execution to this function. Examine heap chunks in the core dump.
core.dump: ELF 64-bit LSB core file, x86-64, version 1 (SYSV) Check what program generated it: [0x00401234]> afl | grep secret 0x00401456 sym
Check if that note was freed:
strings core.dump | head -20 Noticed a binary name: ./bad_memories_v0.9 and a suspicious string: [!] You found a secret? Try -recreation- .
void secret_function() char flag[64]; FILE *f = fopen("flag.txt", "r"); fread(flag, 1, 64, f); flag[strcspn(flag, "\n")] = 0; printf("Flag: %s\n", flag); Dump all strings from core: But it’s never
(gdb) call ((void(*)(char*))0x401456)(0x6020a0+8) Or simply:
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:
gdb -c core.dump Inside GDB: