One very common tool among penetration testers is Metasploit, which includes a lot of nice exploits and payloads. The 5th assignment of the SecurityTube Linux Assembly Expert certification is about Metasploit shellcode analyses for Linux/x86 target systems. The task is to take 3 shellcode payloads generated by msfpayload (which has been replaced by msfvenom in the meanwhile) and dissect their functionalities using different analysis tools like GDB, Ndisasm or Libemu.

Since there are numerous interesting payloads for Linux/x86 in Metasploit:


But I have already covered bind and reverse tcp shellcodes in previous articles, I’m going to analyse some local payloads in this article.

I try to stick to only one specific tool for each payload, but in some cases I will also use GDB, which helps explaining things a little bit better. But anyways…the first goes with GDB, the second with Libemu and the third with Ndisasm.

  • linux/x86/chmod => GDB
  • linux/x86/exec => Libemu
  • linux/x86/read_file => Ndisasm

Have fun reading!


The first payload I’m going to dissect is linux/x86/chmod. The payload changes the file permissions of the supplied FILE argument to 666. The following msfvenom command piped through hexdump:

msfvenom -p linux/x86/chmod FILE=/tmp/rcesecurity R | hexdump -v -e '"\\x" 1/1 "%02x"'

outputs a ready to use shellcode for a C code snippet:

 #include <stdio.h>

unsigned char shellcode[] = \

        //printf("Shellcode Length:  %d\n", sizeof(shellcode) - 1);
        int (*ret)() = (int(*)())shellcode;

Compiling and executing results in a change of the permissions of the file /tmp/rcesecurity. It had permissions of 600 before the payload execution, and 666 after payload execution:


Let’s attach GDB to the executable and disassemble the payload. The initial part up to the first call at 0x804a045 looks quite normal. The first cdq (convert double to quad) is simply used to clear out the EDX register. After that 0xf is pushed onto the stack and POPed to EAX again, followed by the EDX 0x0, which is PUSHed onto the stack.


After the first call instruction at 0x804a045, it looks like there is a lot of gibberish, but it isn’t really. Interesting to see is that the CALL instruction is referencing some instructions in the middle of the gibberish. If you have a look at the string-representation of the gibberish using GDB, it reveals that you’re dealing with the supplied FILE argument used during the payload creation. Due to the fact that the FILE string is 16 bytes in length, the call starts at the 17th byte after 0x0804a04a <+10>, which would be 0x804a05b and right inside the gibberish.


Since a CALL instruction puts a pointer to the next instruction onto the stack, you’ve got a valid pointer to the FILE argument now. After stepping over the CALL instruction, the finalizing instructions are understandable again and include two new instructions (pop ebx and push 0x1b6), which were not visible before.  So the recently added pointer to the filename is POPed to EBX and the value 0x1b6 is PUSHed to the stack and afterwards POPed to ECX:


Finally the syscall 0xf (sys_chmod) is executed, which changes the persmissions of the FILE. It’s C-style representation and the associated register layout is as follows:

int chmod(const char *pathname, mode_t mode);

The register layout at this point:

EAX => 0xf => sys_chmod syscall
EBX => *pathname => /tmp/rcesecurity
ECX => 0x1b6 => octal representation of 666

In the end another sequence to gracefully exit the payload is executed – although the EBX is not filled with a 0x0 here, which would be a really graceful exit 😉 – by PUSHing 0x1 (sys_exit syscall) to the stack, POPing it to EAX and executing the syscall…and this results in a chmod’ded file. Done 🙂 !


The next payload is called linux/x86/exec, which simply executes a binars on the target system. Let’s first create a simple binary snippet using msfvenom and the CMD argument “hostname” and piping it through hexdump:

msfvenom -p linux/x86/exec CMD=hostname R | hexdump -v -e '"\\x" 1/1 "%02x"'

This creates the following shellcode output, which can be put into a C source code snippet:

 #include <stdio.h>

unsigned char shellcode[] = \

	int (*ret)() = (int(*)())shellcode;

Compiling and executing results in:


Seems to work smoothly too. Now pipe that string to the libemu tool sctest:

echo -en "\x6a\x0b\x58\x99\x52\x66\x68\x2d\x63\x89\xe7\x68\x2f\x73\x68\x00\x68\x2f\x62\x69\x6e\x89\xe3\x52\xe8\x09\x00\x00\x00\x68\x6f\x73\x74\x6e\x61\x6d\x65\x00\x57\x53\x89\xe1\xcd\x80" | sctest -S -s 10000 -vv -G

This results in the following output:

graph file
verbose = 2
[emu 0x0x89cd0a0 debug ] cpu state    eip=0x00417000
[emu 0x0x89cd0a0 debug ] eax=0x00000000  ecx=0x00000000  edx=0x00000000  ebx=0x00000000
[emu 0x0x89cd0a0 debug ] esp=0x00416fce  ebp=0x00000000  esi=0x00000000  edi=0x00000000
[emu 0x0x89cd0a0 debug ] Flags: 
[emu 0x0x89cd0a0 debug ] 6A0B                            push byte 0xb
[emu 0x0x89cd0a0 debug ] 58                              pop eax
[emu 0x0x89cd0a0 debug ] 99                              cwd 
[emu 0x0x89cd0a0 debug ] 52                              push edx
[emu 0x0x89cd0a0 debug ] 66682D63                        push word 0x632d
[emu 0x0x89cd0a0 debug ] 89E7                            mov edi,esp
[emu 0x0x89cd0a0 debug ] 682F736800                      push dword 0x68732f
[emu 0x0x89cd0a0 debug ] 682F62696E                      push dword 0x6e69622f
[emu 0x0x89cd0a0 debug ] 89E3                            mov ebx,esp
[emu 0x0x89cd0a0 debug ] 52                              push edx
[emu 0x0x89cd0a0 debug ] E809000000                      call 0xe
[emu 0x0x89cd0a0 debug ] 57                              push edi
[emu 0x0x89cd0a0 debug ] 53                              push ebx
[emu 0x0x89cd0a0 debug ] 89E1                            mov ecx,esp
[emu 0x0x89cd0a0 debug ] CD80                            int 0x80
int execve (const char *dateiname=00416fc0={/bin/sh}, const char * argv[], const char *envp[]);
[emu 0x0x89cd0a0 debug ] 0000                            add [eax],al
cpu error error accessing 0x00000004 not mapped

stepcount 15
copying vertexes
optimizing graph
vertex 0x8a233b0
going forwards from 0x8a233b0
 -> vertex 0x8a25550
 -> vertex 0x8a256c0
 -> vertex 0x8a25808
 -> vertex 0x8a25908
 -> vertex 0x8a25b10
 -> vertex 0x8a25bf8
 -> vertex 0x8a25d00
 -> vertex 0x8a25e98
 -> vertex 0x8a26058
 -> vertex 0x8a26188
 -> vertex 0x8a262b8
 -> vertex 0x8a263e8
 -> vertex 0x8a26518
copying edges for 0x8a26518
 -> 0x8a29b18
vertex 0x8a26648
going forwards from 0x8a26648
copying edges for 0x8a26648
vertex 0x8a26bf8
going forwards from 0x8a26bf8
copying edges for 0x8a26bf8
[emu 0x0x89cd0a0 debug ] cpu state    eip=0x0041702e
[emu 0x0x89cd0a0 debug ] eax=0x0000000b  ecx=0x00416fb0  edx=0x00000000  ebx=0x00416fc0
[emu 0x0x89cd0a0 debug ] esp=0x00416fb0  ebp=0x00000000  esi=0x00000000  edi=0x00416fc8
[emu 0x0x89cd0a0 debug ] Flags: 
int execve (
     const char * dateiname = 0x00416fc0 => 
           = "/bin/sh";
     const char * argv[] = [
           = 0x00416fb0 => 
               = 0x00416fc0 => 
                   = "/bin/sh";
           = 0x00416fb4 => 
               = 0x00416fc8 => 
                   = "-c";
           = 0x00416fb8 => 
               = 0x0041701d => 
                   = "hostname";
           = 0x00000000 => 
     const char * envp[] = 0x00000000 => 
) =  0;

This does not only create a very nice source code snippet, but also creates a .dot file visually describing the shellcode. The .dot file can be easily converted to another format using the dot command:

dot -T png -o msfvenom-linux-x86-exec.png

Et voila:


Looks nice and simple. Let’s dissect it.

First the value 0xb is pushed onto the stack and afterwards POPed to EAX. The next instruction “Convert Word to Doubleword” (cwd) is a simple trick to clear out the EDX register. By using this function the sign bit of the AX register is copied into DX. Since the sign bit is 0 here, DX is zeroed out:

push byte 0xb
pop eax

Afterwards the zeroed EDX is pushed onto the stack, followed by the word 0x632d, which is a representation of “-c”. The pointer to the actual ESP address of the string is then saved to EDI:

push   edx
push  word 0x632d
mov edi,esp

Finally another important part is pushed onto the stack: “/bin/sh” via two push dword instructions, and the ESP pointer is also saved to EBX:

push   dword 0x68732f
push   dword 0x6e69622f
mov    ebx,esp

In the next step first EDX is pushed onto the stack. The following CALL is used to get the pointer to the customized command (in this case hostname, which is at 0x0041701d) onto the stack:

push edx
call 0xe

Another side-effect is that the call moves the EIP 0xe bytes to the next instruction set, which pushes the different arguments into the stack and finally leads to the execution of execve():

push edi
push ebx
mov ecx, esp
int 0x80

So what’s happening here? Maybe you already know the execve() call structure:

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

The register layout at this point:

EAX => 0xb => sys_execve syscall
EBX => *filename => pointer to “/bin/sh”
ECX => argv[] => ESP (same like EBX)
EDX => envp[] => 0x0

And all arguments “/bin/sh” + “-c” + “hostname” + terminating 0x0 are placed onto the stack.


Looks like a smooth execve code execution! Done 🙂


The last payload to dissect is linux/x86/read_file. First let’s create msfvenom payload, which reads the file specified using the PATH argument (/etc/hostname):

msfvenom -p linux/x86/read_file PATH=/etc/hostname R | hexdump -v -e '"\\x" 1/1 "%02x"'

Adding the output to the C snippet file:

 #include <stdio.h>

unsigned char shellcode[] = \

	int (*ret)() = (int(*)())shellcode;

Compiling and executing it results in:


It works. So let’s create a binary file to use with ndisasm:

msfvenom -p linux/x86/read_file PATH=/etc/hostname R > msfvenom-linux-x86-read-file.bin

Some ndisasm magic later:

ndisasm -i -u msfvenom-linux-x86-read-file.bin

You’ve got the plain assembly of the shellcode:


This is a perfect example of a jmp-call-pop technique. The first instruction jumps 38 bytes to the call function at 0x00000038. Maybe you have already recognized the bytes right after the call instruction:

jmp short 0x38
call dword 0x2


This is the byte representative of the file to read by the payload: /etc/hostname. By using the call instruction the pointer to the address of the next instruction is saved onto the stack, which means you have a reference to the payload. Afterwards the call is heading back to address 0x2, which is a combination of MOVing 0x5 (this is the sys_open syscall) to EAX, POP the recently saved pointer to EBX, clear out the ECX register and finally issue the syscall:

mov    eax,0x5
pop    ebx
xor    ecx,ecx
int    0x80

When you take a look at the used syscall arguments, you meay already recognize what is happening here:

int open(const char *pathname, int flags);

The register layout at this point:

EAX => 0x5 => sys_open syscall
EBX => *pathname => points to /etc/hostname
ECX => flags => 0x0

The syscall opens the file /etc/hostname and returns a file descriptor into EAX. This descriptor is then saved to ebx and syscall 0x3 (sys_read) is MOVed into EAX.

mov    ebx,eax
mov    eax,0x3

The definition of sys_read refers to 3 arguments:

ssize_t read(int fd, void *buf, size_t count);

Beside having EBX to reference the file descriptor, you still need a buffer and a size count. First the address of the ESP is MOVed int ECXto have a valid buffer for the return value on the stack, after this the value 0x1000 is MOVed into EDX representing the size_t count followed by the execution of the syscall:

mov    edi,esp
mov    ecx,edi
mov    edx,0x1000
int    0x80

The register layout at this point:

EAX => 0x3 (sys_read)
EBX => fd => points to the file descriptor received by previous syscall
ECX => *buf => some pointer to a valid stack address
EDX => size_t count => 0x1000 bytes

Up next a sequence to setup syscall 0x4 (sys_write) to output the read contents:

ssize_t write(int fd, const void *buf, size_t count);

Since the previous syscall returned the number of bytes read to EAX, this value just needs to be put into EDX to represent the size_t count. EAX is filled by the syscall as mentioned above, and EBX is filled by 0x1 serving as a file descriptor. Luckily ECX already points to the contents read from the file during the last syscall, so no need to change anything here before executing the syscall:

mov    edx,eax
mov    eax,0x4
mov    ebx,0x1
int    0x80

The register layout at this point:

EAX => 0x4 => sys_write
EBX => fd => 0x1
ECX => *buf
EDX => size_t count

One part, which is not shown by the sctest graph, is about exiting the sequence gracefully by using the syscall 0x1 (sys_exit) and by filling EBX with 0x0:

void _exit(int status);

Therefore the syscall exits with a status of 0 (successful).


Contents of the file were successfully read! You can find all the used C source code snippets in my Git too.

This completes another SLAE mission! Damn – I really love this low-level stuff 🙂

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

Student ID: SLAE- 497