If I had more than 16-bytes to write too, I could write to the return address and inject shellcode that pops a shell.
Since I can only write 16-bytes, I thought that maybe libc has an
execve("/bin/sh", ...)
in it.
It does! In fact, 3 of them. I was able to get the offsets using a tool that I wrote. So, (libc base addr)+(libc offset), I can write to those 16-bytes.
The problem is that when I run the binary (without environment variables), the return address is stored 8-bytes after the buffer on the stack.
I don’t understand, I’m really no expert in this type of stuff but how would you exploit anything here ? The scanf function is protected againt BOF thanks to the %16s, and this is the only data you have under your control. Is this really all ? Because if yes I’d be curious to know how you solve that challenge !
I’m curios too. Learning too (just successfully exploited my first modern buffer overflow on a HTB machine) Maybe it was compiled with some weird buggy compiler that has a faulty implementation of scanf or format strings.
actually looking at the source… the buffer’s name is buffer but scanf uses an undefined variable named input - that is just a mistake/typo from transcribing the decompilation, right?
Is this all the code there is?
You could look at the actual disassembled code to find something that might be hidden in the decompiled source.