Challenge: Stack It
Category: Reverse Engineering
Author: @sudo_Rem

---

Challenge Overview

In the Stack It challenge, I was provided with a binary file (stack_it.bin) and a hint about flossing twice a day from a dentist. The task was to analyze the binary, retrieve hidden data, and extract the flag. Given that the challenge falls under reverse engineering, I suspected that the solution would involve debugging and inspecting memory contents.

---

Step 1: Initial Analysis with GDB

To start, I opened the file in GDB (GNU Debugger) to explore the binary’s behavior and inspect its memory. This tool is highly effective for analyzing binaries, allowing us to set breakpoints, step through execution, and view memory content.

gdb stack_it.bin

Upon loading the binary, I found that it didn’t contain debugging symbols, which is common in CTF challenges to increase difficulty. This meant I’d need to directly interact with memory addresses and set breakpoints.

Step 2: Setting a Breakpoint

Without symbols, I needed to choose a memory location to set a breakpoint, and 0x08049048 seemed like a logical choice based on the structure of the binary. Here’s how I arrived at this address:

• Hex Dump Analysis: By inspecting the binary with xxd, I observed that addresses around 0x0804 contained structured data and readable strings. This was a good indication that this address range might hold constants or data relevant to the flag.
• Common Data Sections: In many x86 binaries, addresses in the 0x0804 range correspond to sections like .data or .bss, where strings and constants are often stored. This made 0x08049048 a strong candidate for inspection.

Using this approach, I set the breakpoint:

(gdb) break *0x08049048

I then ran the program:

(gdb) run

The binary hit the breakpoint, allowing me to examine memory in its current state.

Step 3: Examining Memory

Using GDB’s memory inspection command, I checked the contents at memory location 0x804a050. I used a command to display 32 bytes in hexadecimal and ASCII representation, which helped uncover potential strings or clues.

(gdb) x/32xb 0x804a050

The output revealed a sequence of bytes that seemed to resemble the start of a flag, beginning with flag{...}. This was a promising lead! Here’s what I saw:

0x804a050: 0x66 0x6c 0x61 0x67 0x7b 0x62 0x34 0x32
								0x804a058: 0x33 0x34 0x66 0x34 0x62 0x62 0x61 0x34
								...
									

Step 4: Dumping the Flag Data to a File

To retrieve the full flag, I dumped the memory range from 0x804a050 to 0x804a0C0 into a file (extended_dump.bin). This allowed me to analyze the contents outside of GDB.

(gdb) dump memory extended_dump.bin 0x804a050 0x804a0C0

After quitting GDB, I examined the dumped file using xxd, a hex-dump tool:

xxd extended_dump.bin

The output revealed the full flag:

00000000: 666c 6167 7b62 3432 3334 6634 6262 6134  flag{b4234f4bba4
								00000010: 3638 3564 6338 3464 3665 6539 6134 3865  685dc84d6ee9a48e
								00000020: 3963 3130 367d 0000 0000 0000 0000 0000  9c106}..........
									

Step 5: Interpreting the Flag

From the hex dump, the plaintext flag was visible within the flag{} format:

flag{b4234f4bba4685dc84d6ee9a48e9c106}

This was the final answer required to solve the challenge.

---

Conclusion

The Stack It challenge was a fantastic exercise in reverse engineering, requiring memory inspection and knowledge of GDB commands. By setting breakpoints, inspecting memory addresses, and dumping data, I successfully retrieved the flag. This challenge underscored the importance of using debugging tools like GDB for binary analysis and memory forensics in CTFs.