part 3: cleaning and optimising shellcode

In Part 2: Building the shellcode, we created a bind shell on port 4444 which accepts connections from any host and then interacts with “/bin/sh” to facilitate remote code execution. Our shellcode however was littered with null bytes and would probably not be very useful if embedding in any exploit code.

In this final part, we will clean our code and remove any null bytes from our shellcode. We will also look at removing unnecessary instruction to make our shellcode smaller if possible. Lets get started.

Step one, lets take a look at our shellcode using objdump:

part 2: building the shellcode

In Part 1: Disassembling and Understanding Shellcode we disassembled some shellcode and found out the steps required to create a bind shell. In Part 2, we will take each of these 6 steps, understand them and write assembly instructions to call them.

The steps we need to follow to create our bind shell are:
1. Socket
2. Bind
3. Listen
4. Accept
5. Dup2
6. Execve

We are going to spend a lot of time working with NASM (The Netwide Assembler). To install NASM, run the following command:

part 1: disassembling and understanding shellcode

About a month ago I signed up for the Securitytube Linux Assembly Expert certification to get a deeper understanding of assembly and GDB. Doing so has helped me understand what is actually going on in the registers and not just relying on “hail-mary” advice like “use pop, pop, ret when dealing with SEH.” If you’re interested in Assembly or writing shellcode, I’d highly recommend you take the certification.

My first SLAE assignment was to write my own bind shell. I don’t know C well enough to code straight from memory, and even though I understand how individual assembly instructions affect data in the registers and the stack, I didn’t know how to string these together to create working shellcode. I couldn’t find many tutorials devoted to the subject so I decided to just dive in and build it from scratch.

decrypting base64 encrypted binary hashes

I came across a database while testing the other day which happily contained a table called users with the good old id, username and password fields. What made this a somewhat interesting find was the fact that the passwords appeared to be encrypted as base64.

After I stopped giggling I dumped the database and grabbed the first few hashes in an attempt to quickly script the decryption. The script ran fine although I ended up with a lot of garbled text and no plain text passwords. I decided to try decrypt these passwords using several online websites when I discovered that they were actually binary files that had be encoded with base64. I began to doubt my sanity and asked myself why anyone would have passwords stored as binary files. I mean, the log in page didn’t have a field for username and an upload box for password so what was going on?