$ cat writeup.md…
$ cat writeup.md…
broncoctf2026
Task: remote x86-64 shellcode runner installs a strict seccomp allowlist (only open/read/write) then jumps to user bytes; execve is blocked. Solution: classic ORW shellcode — build 'flag.txt' on the stack, open(2)->read(0)->write(1) — bypassing the allowlist without execve. Gotcha: the flag is at the RELATIVE path flag.txt, not any absolute path.
$ cat /etc/rate-limit
Rate limit reached (20 reads/hour per IP). Showing preview only — full content returns at the next hour roll-over.
Mr. Krabs has heard about these so-called "shellcode hackers" trying to break into his secret vault. So he hired the barnacles. They said no execve. Something about a "Strict Sea Policy." You'll need to get creative if you want that flag.
Remote target: nc 0.cloud.chals.io 34381 (alias broncoctf-crab-trap.chals.io).
English summary: A remote x86-64 Linux shellcode runner prints an ASCII banner and a > prompt, reads one raw shellcode blob (max 512 bytes), reports the swallowed byte count ("Nom nom... swallowed N bytes. Deploying the Barnacle Barrier..."), installs a strict seccomp allowlist, then jumps directly to the supplied bytes. The goal is to read the flag despite execve being blocked.
Semantic clues in the prompt map directly to the mechanism:
push "/bin/sh"; execve shellcode is dead.Behavior of the service under the filter:
open (2), read (0), write (1). execve and friends are blocked.open, read, and write are all allowed, plain ORW (open -> read -> write) shellcode works out of the box. No openat2 trick, no pre-opened-fd assumption, no exit syscall needed after writing./etc/passwd via open -> read -> write, confirming syscalls 2/0/1 fire under the filter and return data.The main gotcha was the flag path. Absolute paths (/flag, /flag.txt, /app/flag.txt, /home/ctf/flag) do not exist. The flag is at the relative path flag.txt (the service's CWD), so open("flag.txt", O_RDONLY) is what succeeds.
Send a short ORW shellcode after the > prompt. The shellcode:
...
$ grep --similar