Learning Assembly Through Writing Shellcode

Months ago, I wrote hello world in X86 Assembly, and later that same day I wrote hello world in Python. Python is fast, elegant, and powerful. But unfortunately, it doesn’t really give you an understanding of what’s going on inside your computer. And any good little hacker should know precisely what’s going on inside their computer.

Every time I start teaching myself some complicated thing, I try to make the learning process enjoyable because I know that I’ll retain more information if I can apply it to something fun or useful. Being a terribly precocious kid, I taught myself quantum mechanics when I was fourteen. It was really difficult, and I probably wouldn’t have been able to pull it off if I hadn’t made it fun. And, oh, did I make it fun: FOIA’ed thermonuclear weapons manuals, ten years expired, from some obscure and slightly sketchy web page. I didn’t mean any harm, and I neither was nor am a proponent of nuclear weapons production, maintenance, or warfare. I wasn’t planning on starting up an Uranium-238 enrichment program, or searching the black markets for hollow plutonium cores. I wanted to learn physics, and what’s more fun than learning how to destroy things?

Assembly languages are cumbersome and arcane. The learning curve is steep, and progress is always slow compared to higher level programming languages. Fortunately, however, Assembly can be used to destroy things! Enter shellcode.

The best introduction I found to writing shellcode was in Gray Hat hacking, so I’m going to quote the first few pages of the Linux shellcoding chapter, and then leave you to somehow obtain your own copy.

Basic Linux Shellcode

The term “shellcode” refers to self-contained binary code that completes a task. The task may range from issuing a system command to providing a shell back to the attacker, as was the original purpose of shellcode.

There are basically three ways to write shellcode:

Directly write the hex opcodes.

Write a program in a high level language like C, compile it, and then disassemble it to obtain the assembly imstructions and hex opcodes.

Write as assembly program, assemble the program, and then extract the hex opcodes from the binary.

Writing the hex opcodes directly is a little extreme. We will start with learning the C approach, but quickly move to writing assembly, then to extraction of the opcodes. In any event, you will need to understand low level (kernel) functions such as read, write, and execute. Since these system functions are performed at the kernel level, we will need to learn a little about how user processes communicate with the kernel.

System Calls

The purpose of the operating system is to serve as a bridge between the user (process) and the hardware. There are basically three ways to communicate with the operating system kernel:

Hardware interrupts  For example, an asynchronous signal from the keyboard

Hardware traps  For example, the result of an illegal “divide by zero” error

Software traps   For example, the request for a process to be scheduled for execution

Software traps are the most useful to […] hackers because they provide a method for the user process to communicate to the kernel. The kernel abstracts some basic system level functions from the user and provides an interface through a system call.

Definitions for system calls can be found on a Linux system in the following file:

$ cat /usr/include/asm/unistd.h

#ifndef _ASM_I386_UNISTD_H_

#define _ASM_I386_UNISTD_H_

#define __NR_exit 1

…snip…

#define __NR_execve 11

…snip…

#define __NR_setreuid 70

…snip…

#define __NR_dup2 99

…snip…

#define __NR_socketcall 102

…snip…

#define __NR_exit_group 252

…snip…

In the next section, we will begin the process, starting with C.

System Calls by C

At a C level, the programmer simply uses the system call interface by referring to the function signature and supplying the proper number of parameters. The simplest way to find out the function signature is to look up the function’s man page.

For example, to learn more about the execve system call, you would type

$ man 2 execve

This would display the following man page:

[]

As the next section shows, the previous system call can be implemented directly with assembly.

System Calls by Assembly

At an assembly level, the following registries are loaded to make a system call:

eax   Used to load the hex value of the system call (see unistd.h earlier)

ebx  Used for first parameter—ecxis used for second parameter, edx for third, esi for fourth, and edifor fifth

If more than five parameters are required, an array of the parameters must be stored in memory and the address of that array stored in ebx.

Once the registers are loaded, an int 0x80 assembly instruction is called to issue a software interrupt, forcing the kernel to stop what it is doing and handle the interrupt. The kernel first checks the parameters for correctness, then copies the register values to kernel memory space and handles the interrupt by referring to the Interrupt Descriptor Table (IDT).

The easiest way to understand this is to see an example, as in the next section.

Exit System Call

The first system call we will focus on executes exit(0). The signature of the exit system call is as follows:

eax   0x01 (from the unistd.h file earlier)

ebx   User-provided parameter (in this case 0)

Since this is our first attempt at writing system calls, we will start with C.

Starting with C

The following code will execute the function exit(0):

$ cat exit.c

#include

main(){

exit(0);

}

Go ahead and compile the program. Use the -static flag to compile in the library call to exit as well.

$ gcc -static -0 exit exit.c

Now launch gdb in quiet mode (skip banner) with the -q flag. Start by setting a breakpoint at the main function; then run the program with r.Finally, disassemble the _exit function call with dissass _exit.

[]

[NOTE FROM isis agora lovecruft: My computer is doing weird things here, because I use a modern Linux kernel which supports stack randomization, like a good modern OS should. While there are ways to turn stack randomization off for practice purposes, I feel like it’s better to just get used to stack randomization because you’re going to have to deal with that randomization breaking your shellcode when you execute it on a system other than the one on which it was written. I’m going to explain what happened here, and leave out the silly, non-stack-randomized explanation in the book.]

You can see that the function starts by loading the last user input (%edi) into the 64-bit registry space %rdx at line \<+0>. For a good paper on assembly for 64-bit processors, see the attached documents at the end of this post. Also, to understand the hex in the above dump, see the attached chart at the end of this post titled “Machine Hex Opcodes to Assembly”. For now, you’re just going to have to take my word for it that this information is what I’m telling you it is. So, next, the program stores a bunch of index registers (0xffffffffffffff…) and a subtraction from those registers (…b0) into the delay slot %r9. Then, it moves an accumulator (0xe7) to the delay slot %r8d, moves a return from interrupt (0x3c) to %esi, and then jumps to line \<_exit+48>. Then it moves the last user input (0), which was temporarily stored in %rdx to %rdi. Then, everything that was accumulated into the delay slot %r8d gets moved into the %eax registry.

At this point, we’re exactly where we would be if stack randomization were turned off. Except that if it were turned off, all of this would have only taken two lines of assembly code without any jumps. Stack randomization: Is. Fucking. Hell. And it also is supposed to keep your computer safe from hackers, but as I said, there’s ways around it. But, as you can see, it does make things complicated.

So, next, that program makes the syscall at \<+54>. Finally. Then it jumps around and copies a bunch more things into other literally random places, and I’m not going to go through with explaining the rest of it, because it’s complicated and I’m tired of typing percent signs all over the place.

Move to Assembly

Now for rewriting the exit() syscall in assembly:

[]

Alright, so this is the code the book gives. This code will not produce working shellcode for a system with stack randomization. As you can see, the assembly that my machine dumped was extremely complicated. We would need to rewrite that dump in assembly language to get working shellcode for my system, but another trouble/benefit with stack randomization is that, next time I call that program, it’s going to operate at some other place in memory. Also, if I reboot my computer, all the system calls are going to be at different locations in memory as well. But, let’s just pretend that this would work for now, so that I can show you without typing too much and confusing you. Back to the book.

Assemble, Link, and Test

Once we have the assembly file, we can assemble it with nasm, link it withld, then execute the file as shown:

$ nasm -f elf64 exit.asm

\$ ld exit.o -o exit

\$ ./exit

Not much happened, because we simply called exit(0), which exited the process politely. Luckily for us, there is another way to verify.

Verify with strace

As in our previous example, you may need to verify the execution of a binary to ensure the proper system calls were executed:

$ strace ./exit

0

_exit(0) = ?

As we can see, the _exit(0) syscall was executed!

I’m not going to go through the rest of the book. Obviously, the exit syscall is the first and most basic one. Any syscalls could be used, such as setreuid (which would grant user permissions), execve (to execute code), or bind and listen (to bind ports).

The last step to producing shellcode is to turn the assembly program into a single hex string, because often only one string can be injected into a vulnerable program. To obtain the hex opcodes, we simply use the objdump tool with the -d flag for disassembly:

[]

The most important thing about this printout is to verify that no NULL characters (\x00) are present in the hex opcodes. If there are any NULL characters, the shellcode will fail when we place it into a string for injection during an exploit.

So the shellcode for the exit(0) program would be “\x31\xc0\x31\xdb\xb0\x01\xcd\x80“.

Voila, shellcode. Assembly is still cool.

Basic Linux Shellcode

System Calls

System Calls by C

System Calls by Assembly

Exit System Call

Starting with C

Move to Assembly

Assemble, Link, and Test

Verify with strace

blogroll

social