clutter-overflow

Description

Solution

1. Step 1Find the buffer size and variable offset
   The program calls gets() into a 256-byte buffer on the stack. The code variable sits 264 bytes from the start of the buffer. Use pwntools cyclic to confirm the exact offset.
   python3 -c "from pwn import *; print(cyclic(300))" | ./clutter-overflowCopied!

   python3 -c "from pwn import *; print(cyclic_find(0x61616174))"Copied!
   Learn more

   gets() is one of the most notoriously dangerous functions in the C standard library. It reads characters from stdin into a buffer until it encounters a newline or EOF, with no length limit whatsoever. There is no way to use gets() safely -- it was deprecated in C99 and removed from the C11 standard entirely. Any program that calls it is unconditionally vulnerable to a stack buffer overflow.

   The stack frame for a function contains: the saved frame pointer (rbp), the saved return address (rip), and local variables. Variables declared as local arrays (like char buf[256]) are allocated on the stack in a contiguous block. A variable declared immediately after the buffer (at a higher address on x86 stack, which grows downward) is overwritten when the buffer is overflowed. Ghidra's decompiler shows the stack layout with variable offsets relative to rbp, making the distance calculation straightforward.

   The cyclic_find() function works by looking up the 4-byte value in the de Bruijn sequence generated by cyclic(). When the program crashes with code = 0x61616174 (from reading the overwritten memory), passing that value to cyclic_find() returns the byte offset in the cyclic pattern where that 4-byte sequence appears -- which equals the number of padding bytes needed.

2. Step 2Build the overflow payload
   Send 264 bytes of padding followed by 0xdeadbeef in little-endian 64-bit format. The gets() call has no length limit, so it writes all bytes including the overwrite of code.
   python3 -c " from pwn import * payload = b'A' * 264 + p64(0xdeadbeef) print(payload) "Copied!
   Learn more

   Little-endian byte order is the storage format used by x86 and x86-64 processors. In little-endian, multi-byte integers are stored with the least significant byte at the lowest memory address. So the 64-bit value 0x00000000deadbeef is stored in memory as the bytes \xef\xbe\xad\xde\x00\x00\x00\x00. pwntools' p64() packs an integer into this 8-byte little-endian format automatically.

   0xdeadbeef is a classic magic number in programming -- historically used as a placeholder or sentinel value in C programs, debugger outputs, and memory initialization. In CTF binary exploitation, challenges frequently use it as the "magic value" that must be written to trigger a win condition, making it immediately recognizable as the target.

   The payload structure is deliberate: b'A' * 264 fills the gap between the start of the buffer and the start of the code variable with the byte 0x41 (ASCII 'A'). The next 8 bytes overwrite code with the target value. Any bytes after that would continue overwriting the stack -- the saved rbp, then the return address -- but for this challenge, only the variable overwrite is needed.

3. Step 3Exploit remotely and read the flag
   Send the payload to the remote server. When code equals 0xdeadbeef, the binary prints the flag.
   python3 -c " from pwn import * conn = remote('mars.picoctf.net', <PORT>) payload = b'A' * 264 + p64(0xdeadbeef) conn.sendline(payload) conn.interactive() "Copied!
   Learn more

   pwntools remote() opens a TCP connection to the specified host and port, returning a tube object that supports sending and receiving data. sendline(payload) sends the payload bytes followed by a newline (which gets() uses as the terminator, stopping reading). The newline is appended automatically by sendline() -- using send() instead would skip it.

   This exploit works identically on the remote server as it does locally because the challenge binary is the same and stack layout is deterministic (no ASLR, no stack canary based on the challenge description). In more hardened binaries, ASLR would randomize the stack base address, requiring an information leak to defeat. Stack canaries would require either leaking the canary value or using a different exploitation primitive entirely.

   The broader lesson of this challenge: gets() makes buffer overflow trivial. Its replacement, fgets(buf, sizeof(buf), stdin), takes an explicit length limit and prevents the overflow. Other safe alternatives include scanf("%255s", buf) with an explicit width specifier. Modern compilers emit warnings when gets() is used -- always treat these as errors.

Flag

picoCTF{...}

gets() has no length limit -- it reads until newline regardless of buffer size, making any program that calls it unconditionally vulnerable to stack overflows.