One of the most widely use of assembly language is in writing shellcode. If you new to this subject, try playing with assembly a bit.
Prerequisites: x86 Assembly language(Strictly Recommended).
2. C programming language.
Caution:The shellcodes can be used in most exploits without a problem.However, these codes may cause serious damage to your computer and should therefor only be used against TEST systems that have NO network connectivity! Imagine what happens if you run the backdoor on you system and forget about it ?
What is shellcode?
The shellcode is literally a "code" that returns a remote (or local) shell when executed. Shellcode can be seen as a list of instructions that has been developed in a manner that allows it to be injected in an application during runtime.The term “shellcode” (or “shell code”) derives from the fact that in many cases, malicious users utilize code that provides them with either shell access to a remote computer on which they do not possess an account or, alternatively, access to a shell with higher privileges on a computer on which they do have an account. In the optimal case, such a shell might provide root- or administrator-level access to a vulnerable system.
Understanding shellcode and eventually writing your own is, for many reasons, an essential skill. First and foremost, in order to determine that a vulnerability is indeed exploitable, you must first exploit it. Second, software vendors will often release a notice of a vulnerability but not provide an exploit. In these cases you may have to write your own shellcode if you want to create an exploit in order to test the bug on your own systems. Unfortunately, for many hackers the shellcode story stops at copying and pasting bytes. These hackers are just scratching the surface of what’s possible.Custom shellcode gives you absolute control over the exploited program. Perhaps you want your shellcode to add an admin account to /etc/passwd or to automatically remove lines from log files. Once you know how to write your own shellcode, your exploits are limited only by your imagination. In addition, writing shellcode develops assembly language skills and employs a number of hacking techniques worth knowing.
Understanding System Calls: As we have already discussed,System calls are APIs for the interface between user space and kernel space.We write shellcode because we want the target program to function in a manner other than what was intended by the designer. One way to manipulate the program is to force it to make a system call or syscall. Syscalls are an extremely powerful set of functions that will allow you to access operating system– specific functions such as getting input, producing output, exiting a process, and executing a binary file. Syscalls allow you to directly access the kernel, which gives you access to lower-level functions like reading and writing files.
More in detail : The concept of Assembly- System calls :http://programmingethicalhackerway.blogspot.in/2015/07/the-concept-of-assembly-system-calls.html
Writing Shellcode for the exit() Syscall: There are basically three ways to write shellcode:
1.writing manually in hex opcode.
2. writing the C code, compile it, and then disassebling it to obtain the assembly instructions and hex opcodes.
3. writing the assembly code and , assemble the program, and then extract the hex opcodes from the binary.
There are various types of shellcode like:
1. Basic Shellcode:It would be nice if we did not have to write our own version of a shell just to upload it to a target computer that probably already has a shell installed. With that in mind, the technique that has become more or less standard typically involves writing assembly code that launches a new shell process on
the target computer and causes that process to take input from and send output to the attacker. The easiest piece of this puzzle to understand turns out to be launching a new shell process, which can be accomplished through use of the execve system call on Unix-like systems and via the CreateProcess function call on Microsoft Windows systems.The more complex aspect is understanding where the new shell process receives its input and where it sends its output.
2. Port Binding Shellcode: When attacking a vulnerable networked application, it will not always be the case that simply execing a shell will yield the results we are looking for. If the remote application closes our network connection before our shell has been spawned, we will lose our means to transfer data to and from the shell.One solution to this problem is to use port binding shellcode, often referred to as a “bind shell.”
3. Reverse Shellcode: If a firewall can block our attempts to connect to the listening socket that results from successful use of port binding shellcode.In many cases, firewalls are less restrictive regarding outgoing traffic. Reverse shellcode exploits this fact by reversing the direction in which the second connection is made.Instead of binding to a specific port on the target computer, reverse shellcode initiates a new connection to a specified port on an attacker-controlled computer. Following a successful connection, it duplicates the newly connected socket to stdin, stdout, and stderr before spawning a new command shell process on the target machine.
Kernel Space Shellcode: User space programs are not the only type of code that contains vulnerabilities. Vulnerabilities are also present in operating system kernels and their components, such as device drivers.
Before we start writing exit shellcode, let's understand a C program which is most widely used to test a shellcode.This is an example C code used to test out our codes, there several ways to write this but they works out all the same:
char code[] = "bytecode(like \x31\xdb\xb0\x01x\cd\x80 ) will go here!";
int main(int argc, char **argv)
{
int (*func)(); //func is a function pointer
func = (int (*)()) code; //func points to our code(shellcode)
(int)(*func)(); //execute as function code[]
}
In the main function, the code:
int (*func)();
is a declaration of a function pointer. Actually func is pointer to function returning int.A function pointer is essentially a variable that holds the address of a function. In this case, the type of function that func points to is a one that takes no arguments and returns an int.
The next line:
func = (int (*)()) code;
assigns a function pointer an address to the code[] (which is assembler bytecode, the instructions your CPU executes). Here (int (*)()) is a cast to a function pointer that takes no arguments and returns an int. This is so the compiler won't complain about assigning what is essentially a char* to the function pointer func.
The last line:
(int)(*func)();
calls the function by its address (assembler instructions) with no arguments passed,because () is specified.
Here the result is cast to an int and this cast is not necessary.So the last line
(int)(*func)();
could be replaced with
(*func)();
Note:
1. Address Space Layout Randomization is a defense feature to make buffer overflows more difficult, and Kali Linux uses it by default. Fortunately, it's easy to temporarily disable ASLR in Kali Linux.
In a Terminal, execute these commands: :
root@kali:~/Desktop/Assembly# echo 0 | tee /proc/sys/kernel/randomize_va_space
0
root@kali:~/Desktop/Assembly# cat /proc/sys/kernel/randomize_va_space
0
2.To compile the code without modern protections against stack overflows :
root@kali:~/Desktop/Assembly# gcc test.c -o test -ggdb -fno-stack-protector -z execstack
Essentially, you now have all the pieces you need to make exit() shellcode.Our first step will be to use the assembly code from previous tutorial "exit.asm" code example to write a shellcode.The assembly code is :
global _start
section .text
_start:
mov ebx,0
mov eax, 1
int 0x80
If this code is not clear , check here:http://programmingethicalhackerway.blogspot.in/2015/07/a-simple-exit-assembly-program.html
Now To get the opcodes, we will first assemble the code with nasm andthen use the GNU linker to link object files;then disassemble the freshly built binary with objdump:
root@kali:~/Desktop/Assembly# nasm -f elf32 exit.asm -o exit.o
root@kali:~/Desktop/Assembly# ld exit.o -o exit
root@kali:~/Desktop/Assembly# ./exit
root@kali:~/Desktop/Assembly# objdump -d exit
exit: file format elf32-i386
Disassembly of section .text:
08048060 <_start>:
8048060: bb 00 00 00 00 mov $0x0,%ebx
8048065: b8 01 00 00 00 mov $0x1,%eax
804806a: cd 80 int $0x80
root@kali:~/Desktop/Assembly#
You can see the assembly instructions on the far right. To the left is our opcode.The second column contains the opcodes we need. All you need to do is place the opcode into a character array and whip up a little C to execute the string.Therefore, we can write our first shellcode and test it with a very simple C program(Discussed above):
char shellcode[] = "\xbb\x00\x00\x00\x00"
"\xb8\x01\x00\x00\x00"
"\xcd\x80";
int main(int argc, char **argv)
{
int (*func)();
func = (int (*)()) code;
(int)(*func)();
}
Now, compile the program and test the shellcode:
root@kali:~/Desktop/Assembly# gcc test.c -o test -ggdb -fno-stack-protector -z execstack
root@kali:~/Desktop/Assembly# ./test
root@kali:~/Desktop/Assembly#
It looks like the program exited normally. Unfortunately, looking at the shellcode, we can notice a little problem: it contains a lot of null bytes and, since the shellcode is often written into a string buffer, those bytes will be treated as string terminators by the application and the attack will fail.
There are two ways to get around this problem:
1.writing instructions that don't contain null bytes (not always possible),
2. writing a self-modifying shellcode (without null bytes) which will write the necessary null bytes (e.g. string terminators) at run-time.
Here we will apply the first method.First, the first instruction:
mov $0x0,%ebx
can be replaced by the more common :
xor ebx, ebx
Instead of using the mov instruction to set the value of EBX to 0,use the Exclusive OR (xor) instruction.If you remember assembly, the Exclusive OR (xor) instruction will return zero if both operands are equal. This means that if we use the Exclusive OR instruction on two operands that we know are equal, we can get the value of 0 without having to use a value of 0 in an instruction.
The second instruction:
mov $0x1,%eax
instead, contained all those zeroes because we were using a 32 bit register (EAX), thus making 0x01 become 0x01000000 (bytes are in reverse order because Intel processors are little endian).We can get around this problem if we remember that each 32-bit register is broken up into two 16-bit “areas”; the first-16 bit area can be accessed with the AX register. Additionally, the 16-bit AX register can be broken down further into the AL and AH registers. If you want only the first 8 bits, you can use the AL register.
Our binary value of 1 will take up only 8 bits, so we can fit our value into this register and avoid EAX
getting filled up with nulls. Therefore, we can solve this problem simply using an 8 bit register (AL) instead of a 32 bit register:
mov al,1
Now we should have taken care of all the nulls. Let’s verify that we have by writing our new assembly instructions and seeing if we have any null opcodes.Now our assembly code looks like:
global _start
section .text
_start:
xor ebx,ebx ;zero out ebx
mov al, 1 ;exit is syscall 1
int 0x80
Take the following steps to compile and extract the byte code.
root@kali:~/Desktop/Assembly# nasm -f elf32 exit.asm -o exit.o
root@kali:~/Desktop/Assembly# ld exit.o -o exit
root@kali:~/Desktop/Assembly# ./exit
root@kali:~/Desktop/Assembly# objdump -d exit
exit: file format elf32-i386
Disassembly of section .text:
08048060 <_start>:
8048060: 31 db xor %ebx,%ebx
8048062: b0 01 mov $0x1,%al
8048064: cd 80 int $0x80
The bytes we need are 31 db b0 01 cd 80.As you can see, doesn't contain any null bytes!All our null opcodes have been removed, and we have significantly reduced the size of our shellcode. Now you have fully working, and more importantly, injectable shellcode.
Now test the new shellcode:
char shellcode[] = "\x31\xdb\xb0\x01"
"\xcd\x80";
int main(int argc, char **argv)
{
int (*func)();
func = (int (*)()) code;
(int)(*func)();
}
Once again, to make the shellcode work in real-world applications, we will need to remove all those null bytes!
Ideas for writing small shellcode : Here i will share some useful ideas for constructing shellcode that is as small as possible.
1. Use small instructions.
2. Use instructions with multiple effects.
3. Bend Windows API rules.
4. Don’t think like a programmer.
5. Consider using encoding or compression.
Prerequisites: x86 Assembly language(Strictly Recommended).
2. C programming language.
Caution:The shellcodes can be used in most exploits without a problem.However, these codes may cause serious damage to your computer and should therefor only be used against TEST systems that have NO network connectivity! Imagine what happens if you run the backdoor on you system and forget about it ?
What is shellcode?
The shellcode is literally a "code" that returns a remote (or local) shell when executed. Shellcode can be seen as a list of instructions that has been developed in a manner that allows it to be injected in an application during runtime.The term “shellcode” (or “shell code”) derives from the fact that in many cases, malicious users utilize code that provides them with either shell access to a remote computer on which they do not possess an account or, alternatively, access to a shell with higher privileges on a computer on which they do have an account. In the optimal case, such a shell might provide root- or administrator-level access to a vulnerable system.
Understanding shellcode and eventually writing your own is, for many reasons, an essential skill. First and foremost, in order to determine that a vulnerability is indeed exploitable, you must first exploit it. Second, software vendors will often release a notice of a vulnerability but not provide an exploit. In these cases you may have to write your own shellcode if you want to create an exploit in order to test the bug on your own systems. Unfortunately, for many hackers the shellcode story stops at copying and pasting bytes. These hackers are just scratching the surface of what’s possible.Custom shellcode gives you absolute control over the exploited program. Perhaps you want your shellcode to add an admin account to /etc/passwd or to automatically remove lines from log files. Once you know how to write your own shellcode, your exploits are limited only by your imagination. In addition, writing shellcode develops assembly language skills and employs a number of hacking techniques worth knowing.
Understanding System Calls: As we have already discussed,System calls are APIs for the interface between user space and kernel space.We write shellcode because we want the target program to function in a manner other than what was intended by the designer. One way to manipulate the program is to force it to make a system call or syscall. Syscalls are an extremely powerful set of functions that will allow you to access operating system– specific functions such as getting input, producing output, exiting a process, and executing a binary file. Syscalls allow you to directly access the kernel, which gives you access to lower-level functions like reading and writing files.
More in detail : The concept of Assembly- System calls :http://programmingethicalhackerway.blogspot.in/2015/07/the-concept-of-assembly-system-calls.html
Writing Shellcode for the exit() Syscall: There are basically three ways to write shellcode:
1.writing manually in hex opcode.
2. writing the C code, compile it, and then disassebling it to obtain the assembly instructions and hex opcodes.
3. writing the assembly code and , assemble the program, and then extract the hex opcodes from the binary.
There are various types of shellcode like:
1. Basic Shellcode:It would be nice if we did not have to write our own version of a shell just to upload it to a target computer that probably already has a shell installed. With that in mind, the technique that has become more or less standard typically involves writing assembly code that launches a new shell process on
the target computer and causes that process to take input from and send output to the attacker. The easiest piece of this puzzle to understand turns out to be launching a new shell process, which can be accomplished through use of the execve system call on Unix-like systems and via the CreateProcess function call on Microsoft Windows systems.The more complex aspect is understanding where the new shell process receives its input and where it sends its output.
2. Port Binding Shellcode: When attacking a vulnerable networked application, it will not always be the case that simply execing a shell will yield the results we are looking for. If the remote application closes our network connection before our shell has been spawned, we will lose our means to transfer data to and from the shell.One solution to this problem is to use port binding shellcode, often referred to as a “bind shell.”
3. Reverse Shellcode: If a firewall can block our attempts to connect to the listening socket that results from successful use of port binding shellcode.In many cases, firewalls are less restrictive regarding outgoing traffic. Reverse shellcode exploits this fact by reversing the direction in which the second connection is made.Instead of binding to a specific port on the target computer, reverse shellcode initiates a new connection to a specified port on an attacker-controlled computer. Following a successful connection, it duplicates the newly connected socket to stdin, stdout, and stderr before spawning a new command shell process on the target machine.
Kernel Space Shellcode: User space programs are not the only type of code that contains vulnerabilities. Vulnerabilities are also present in operating system kernels and their components, such as device drivers.
Before we start writing exit shellcode, let's understand a C program which is most widely used to test a shellcode.This is an example C code used to test out our codes, there several ways to write this but they works out all the same:
char code[] = "bytecode(like \x31\xdb\xb0\x01x\cd\x80 ) will go here!";
int main(int argc, char **argv)
{
int (*func)(); //func is a function pointer
func = (int (*)()) code; //func points to our code(shellcode)
(int)(*func)(); //execute as function code[]
}
In the main function, the code:
int (*func)();
is a declaration of a function pointer. Actually func is pointer to function returning int.A function pointer is essentially a variable that holds the address of a function. In this case, the type of function that func points to is a one that takes no arguments and returns an int.
The next line:
func = (int (*)()) code;
assigns a function pointer an address to the code[] (which is assembler bytecode, the instructions your CPU executes). Here (int (*)()) is a cast to a function pointer that takes no arguments and returns an int. This is so the compiler won't complain about assigning what is essentially a char* to the function pointer func.
The last line:
(int)(*func)();
calls the function by its address (assembler instructions) with no arguments passed,because () is specified.
Here the result is cast to an int and this cast is not necessary.So the last line
(int)(*func)();
could be replaced with
(*func)();
Note:
1. Address Space Layout Randomization is a defense feature to make buffer overflows more difficult, and Kali Linux uses it by default. Fortunately, it's easy to temporarily disable ASLR in Kali Linux.
In a Terminal, execute these commands: :
root@kali:~/Desktop/Assembly# echo 0 | tee /proc/sys/kernel/randomize_va_space
0
root@kali:~/Desktop/Assembly# cat /proc/sys/kernel/randomize_va_space
0
2.To compile the code without modern protections against stack overflows :
root@kali:~/Desktop/Assembly# gcc test.c -o test -ggdb -fno-stack-protector -z execstack
Essentially, you now have all the pieces you need to make exit() shellcode.Our first step will be to use the assembly code from previous tutorial "exit.asm" code example to write a shellcode.The assembly code is :
global _start
section .text
_start:
mov ebx,0
mov eax, 1
int 0x80
If this code is not clear , check here:http://programmingethicalhackerway.blogspot.in/2015/07/a-simple-exit-assembly-program.html
Now To get the opcodes, we will first assemble the code with nasm andthen use the GNU linker to link object files;then disassemble the freshly built binary with objdump:
root@kali:~/Desktop/Assembly# nasm -f elf32 exit.asm -o exit.o
root@kali:~/Desktop/Assembly# ld exit.o -o exit
root@kali:~/Desktop/Assembly# ./exit
root@kali:~/Desktop/Assembly# objdump -d exit
exit: file format elf32-i386
Disassembly of section .text:
08048060 <_start>:
8048060: bb 00 00 00 00 mov $0x0,%ebx
8048065: b8 01 00 00 00 mov $0x1,%eax
804806a: cd 80 int $0x80
root@kali:~/Desktop/Assembly#
You can see the assembly instructions on the far right. To the left is our opcode.The second column contains the opcodes we need. All you need to do is place the opcode into a character array and whip up a little C to execute the string.Therefore, we can write our first shellcode and test it with a very simple C program(Discussed above):
char shellcode[] = "\xbb\x00\x00\x00\x00"
"\xb8\x01\x00\x00\x00"
"\xcd\x80";
int main(int argc, char **argv)
{
int (*func)();
func = (int (*)()) code;
(int)(*func)();
}
Now, compile the program and test the shellcode:
root@kali:~/Desktop/Assembly# gcc test.c -o test -ggdb -fno-stack-protector -z execstack
root@kali:~/Desktop/Assembly# ./test
root@kali:~/Desktop/Assembly#
It looks like the program exited normally. Unfortunately, looking at the shellcode, we can notice a little problem: it contains a lot of null bytes and, since the shellcode is often written into a string buffer, those bytes will be treated as string terminators by the application and the attack will fail.
There are two ways to get around this problem:
1.writing instructions that don't contain null bytes (not always possible),
2. writing a self-modifying shellcode (without null bytes) which will write the necessary null bytes (e.g. string terminators) at run-time.
Here we will apply the first method.First, the first instruction:
mov $0x0,%ebx
can be replaced by the more common :
xor ebx, ebx
Instead of using the mov instruction to set the value of EBX to 0,use the Exclusive OR (xor) instruction.If you remember assembly, the Exclusive OR (xor) instruction will return zero if both operands are equal. This means that if we use the Exclusive OR instruction on two operands that we know are equal, we can get the value of 0 without having to use a value of 0 in an instruction.
The second instruction:
mov $0x1,%eax
instead, contained all those zeroes because we were using a 32 bit register (EAX), thus making 0x01 become 0x01000000 (bytes are in reverse order because Intel processors are little endian).We can get around this problem if we remember that each 32-bit register is broken up into two 16-bit “areas”; the first-16 bit area can be accessed with the AX register. Additionally, the 16-bit AX register can be broken down further into the AL and AH registers. If you want only the first 8 bits, you can use the AL register.
Our binary value of 1 will take up only 8 bits, so we can fit our value into this register and avoid EAX
getting filled up with nulls. Therefore, we can solve this problem simply using an 8 bit register (AL) instead of a 32 bit register:
mov al,1
Now we should have taken care of all the nulls. Let’s verify that we have by writing our new assembly instructions and seeing if we have any null opcodes.Now our assembly code looks like:
global _start
section .text
_start:
xor ebx,ebx ;zero out ebx
mov al, 1 ;exit is syscall 1
int 0x80
Take the following steps to compile and extract the byte code.
root@kali:~/Desktop/Assembly# nasm -f elf32 exit.asm -o exit.o
root@kali:~/Desktop/Assembly# ld exit.o -o exit
root@kali:~/Desktop/Assembly# ./exit
root@kali:~/Desktop/Assembly# objdump -d exit
exit: file format elf32-i386
Disassembly of section .text:
08048060 <_start>:
8048060: 31 db xor %ebx,%ebx
8048062: b0 01 mov $0x1,%al
8048064: cd 80 int $0x80
The bytes we need are 31 db b0 01 cd 80.As you can see, doesn't contain any null bytes!All our null opcodes have been removed, and we have significantly reduced the size of our shellcode. Now you have fully working, and more importantly, injectable shellcode.
Now test the new shellcode:
char shellcode[] = "\x31\xdb\xb0\x01"
"\xcd\x80";
int main(int argc, char **argv)
{
int (*func)();
func = (int (*)()) code;
(int)(*func)();
}
Once again, to make the shellcode work in real-world applications, we will need to remove all those null bytes!
Ideas for writing small shellcode : Here i will share some useful ideas for constructing shellcode that is as small as possible.
1. Use small instructions.
2. Use instructions with multiple effects.
3. Bend Windows API rules.
4. Don’t think like a programmer.
5. Consider using encoding or compression.
If you like this post or have any question, please feel free to comment!
