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.
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);
Category: Reverse Engineering / Forensics (Memory Analysis) Difficulty: Medium Author: CTF Player Tooling: strings , gdb / radare2 , Volatility 3 (or 2 ), hexdump , python 1. Challenge Description "We recovered a core dump from a suspicious process. The developer said it's 'just a game', but we saw unusual memory access patterns. Find the flag hidden in the bad memories." Provided file: core.dump (or bad_memories.v0.9.core ) 2. Initial Analysis First, identify the file type: Bad Memories -v0.9- -recreation-
(gdb) call ((void(*)(char*))0x401456)(0x6020a0+8) Or simply:
However, this core dump is process-only. Use elfutils : But it’s never called normally
[0x00401234]> afl | grep secret 0x00401456 sym.secret_function Disassemble secret_function :
Using gdb with the core file:
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: