Shellcodes

The 0xCC at the end is INT3 or a which should result in Trace/breakpoint trap

If you change 0xCC to 0xC3, it will return without faulting.

One possible mitigation would be if your compiler is putting constant strings into .rdata instead of .text .

Instead of:

You have a typo in your push immediate instructions, and the command you are actually trying to execute is //in//sh. As no such file exists, the execve system call fails, which means that it returns. So your program continues executing past the last int 0x80, after which there is only garbage that crashes your program when executed as instructions.

Can't answer your comment, you can't just change int 0x80 to syscall to make it work, system call numbers differ, i.e sys_write you have here, have id 4 for int 0x80, and id 1 with syscall

Here you can see numbers for syscall

And here for int 80

When the shellcode execve(/bin/sh) executes, it has no connected standard input (because of GETS) and will terminate.

The solution is to close stdin descriptor, reopen /dev/tty before executing /bin/sh.

int (*func)(); is a pointer to a function (taking no parameters in C++) that returns an int.

(*func)(); or just func(); calls the function pointed to.

(int (*)()) code; is a nasty type cast telling the compiler that code is pointing to such a function. If it is not, but you still try to call the function, the program is invalid and anything can happen.

"Anything" includes actually executing the shell code, or crashing, or something else. The language standard doesn't say.

This is the result of the von Neumann architecture. Code and data are just numbers in the memory of the Computer. Therefore the disassembler can't know (without any apriori information about the byte sequence) what is code and what is data. Means, you have to do it by manual.

Fortunately it is easy to do. Just replace the string data with nop's (\x90) and dissassemble it again. Then you can put the string data back into the source code by replacing the nop areas.

Also make sure you are using the correct target CPU for disassembling. I think it is not likely that this shellcode is intended to work on a 16 Bit 8086 CPU.

The reason itself is easy enough to explain, just the push instructions in the shellcode erased the ending bytes of shellcode (noticed the eip is on stack and very near esp, right?) prefix the shellcode with "add esp, 0x70" is enough in most times.

However, I think you need to learn how to debug the program before asking questions. Use gdb, learn some assembly, and learn how shellcode works, so that you can know how it does not work.

For example in shellcode1 it ends with \xcd\x80 which is int 0x80. But when you debug, the final int 0x80 disappears before the final execve call completed. That is strange, therefore one need to consider what had modified the shellcode.

Those are numbers, just like you're familiar with: 1, 2, 3, and so on.

But they are written in hexadecimal instead of decimal. In decimal, we have 10 digits: 0, 1, 2, 3, 4, 5, 6, 7, 8, and 9. In hexadecimal, we have 16. The first 10 are the same as listed before. The six new ones are A, B, C, D, E, and F.

What this means is that in decimal, we count ...8, 9, 10, 11..., but in hexadecimal, we count ...8, 9, A, B.... And in hexadecimal we count ...E, F, 10, 11, when in decimal we could be counting ...14, 15, 16, 17....

The reason hexadecimal is used is because 16, unlike 10, is a power of 2, and computers love powers of two.

Think of it like this. Computers work in binary, and if you have four bits (BInary DIgits) you'll write something like 1001. Simple enough. But with one single hexadecimal digit, you can compactly write 4 bits all at once.

The reason is that there are 16 possible combinations of four bits, from 0000 to 1111. All we have done is mapped those sixteen combinations onto the sixteen digits of the hexadecimal system. So, 0 in hex = 0 in binary, while A in hex = 1010 in binary (= 10 in decimal).

This compactness is the reason why hexadecimal is used so often. One byte (eight bits) can be represented with two hexadecimal digits. Since computer memory is always addressed by bytes or multiples of bytes, memory addresses are easily expressed using hexadecimal. Likewise, many quantities related to computing, such as quantities of data, are usually multiples of bytes as well.

0x is a prefix used to specify that the number coming after it is in hexadecimal. This is needed because some hexadecimal numbers look just like decimal numbers, e.g. 32.

Another you might see is the octal system. All the same concept above apply, except that the prefix is just a single 0. And which octal, you can write 3 bits compactly instead of 4.

Hope this helps!