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.
In GDB, call the overwritten function:
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); Bad Memories -v0.9- -recreation-
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:
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: gdb -c core
Using gdb with the core file:
chmod +x bad_memories_v0.9 ./bad_memories_v0.9 It prints: We can manually trigger the print: Category: Reverse
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.
[0x00401234]> afl | grep secret 0x00401456 sym.secret_function Disassemble secret_function :