my problem is when I try to run the code it appears as if the c program is actually executing the shellcode as it fills the buffer.

when I run the python program I get the message:

sh: 1: shCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCEFGHDDDDDDDDD: not found

when I look at the python program through GDB with set follow-fork-mode child, I see that a /bin/sh shell is spawned, generates the error above, and closes.

Is there any reason why the shellcode would be executed before I have the eip jump onto the nop slide? I am generating the payload with metasploit. I am trying to get a local root shell on the box so I am using the linux/x86/exec payload with the CMD = /bin/sh. I have tried several different encoders, all of which result in errors unless I use the cmd/generic_sh. The machine is a Debian 6 box and a ubuntu 12 box.

poor encoding mostly. I was also lazy and had my shell generated for me rather than writing my own by using msfpayload linux/x86/exec CMD=/bin/sh. I realize there are much smaller shells I could have used.

I discovered that the box has non executable stack enabled which was killing my program as soon as the shell started. I tried making a ROP of the same program but just can't seem to get it to work correctly.

with the first 4 byte address being the start of the program. the 4 A's are overwriting the EIP and then the /bin/sh is the last 4 bytes. I found the /bin/sh address in gdb using find system, +999999999, "/bin/sh", though when I run x/s 0xb7fbb0df in gdb and I don't see /bin/sh as the output. I could also put the exit of the program into the ROP where EIP is overwritten but the address is 0xb7ec5300 and the nul byte gets removed from the perl string and core dumps the program.

3. Do lots of testing in GDB. Run the program with 50 (less or more, adjusted for the length of the buffer) A's, and 4 B's. If the EIP contains BBBB (in hex) at the end of it, then you're right on the money.

4. Before taking it out to the real world, run it all in GDB first. Being able to set breakpoints and view the stack frames is AMAZINGLY helpful when messing with shell-code. Once you get a shell spawned in GDB, you should be able to get a shell spawned in the real world fairly easily.

5. Remember that the addresses shown to you in GDB and in a real world test differ slightly. You may have to adjust the length of your NOP sled and mess with it a bit before it works.

6. Try, try, try again!

7. If you need any help, you can find me here or in #coffeesh0p in IRC.

Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. -Rick Cook

Thanks for the suggestions. The issue I was having was the non executable stack. Sadly, I am trying to get back into the swing of things for my job.

Also great suggestion for Hacking The Art of Exploitation. I thankfully have the second edition and quickly reacquainted myself with his work on bypassing the non executable stack. I was able to exploit the program in no time after that. Thank you both for the suggestions.