Chapter 8 - Reverse Engineering

Reverse engineering is taking apart an object to see how it works in order to duplicate or enhance the object. The practice, taken from older industries, is now frequently used on computer hardware and software. Software reverse engineering involves reversing a program's machine code back into the source code that it was written in, using program language statements.

— Anonymous

The below will pertain to Buffer Overflow steps.

Fuzzing

STEP 1 - script

The point of this is to crash the application and to find approximately how many bytes were needed to crash the application.

#!/usr/bin/python

import socket

buffer=["A"]
counter=100 #start at 100 As

while len(buffer) <=1000:
    buffer.append("A"*counter)
    counter=counter+1 #increment by 1 untill 1000

try:
    for string in buffer:
        print "Fuzzing App with %s bytes" % len(string)
        s=socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        connect=s.connect(("127.0.0.1", 9999))
        s.recv(1024)
        s.send(string + '\r\n')
        s.close()

except:
    print "Could not connect to app..."

STEP 2 - pattern_create

With the number of bytes we found from the previous step, we will use MSF's pattern create tool to create a unique buffer which we will send to the application again.

The output will be plugged into the buffer variable in a simpler fuzzer script, shown below.

STEP 3 - pattern_offset

Now we will run the new script with the pattern_create buffer. The application should once again crash. Check the EIP and take that value and plug it into pattern_offset.

The output of the above command will output an exact offset of bytes in the application. This offset is then used to determine the where the overflow lies from the applications EBP (524), and into EIP (525).

STEP 4 - Shellcode size

Because we now know where the cutoff point is in the appplications stack, we can now start looking at how big our allotment for shellcode is. Let's look at the below code.

'A' is used for filling up the applications's buffer. We know we only need 524 because of STEP 3. 'B' is used for filling in the EIP register. 'C' is used to show us how much space we are given to add our own (shell)code into it.

This is an important step because the we will try to add a number of 'C' and that will show us if we are limited in size of our shellcode/malicious payload.

The more 'C's you see, the more space you have to inject larger sized shellcode.

STEP 5 - bad characters check

Now it's time to test bad characters. These are characters that will cause our shellcode to be interupted if not checked before execution.

possible bad chars

note: \x00 may stop/crash your program due to it being a NULL char. Please remove it before continuing if you deem appropriate.

We are going to add the above into our script like below and run.

We should expect to see everything in the badchars variable within the ESP of the application using ollydbg. We should see the following in the hex dump of the ESP in the dump...

Should there be a bad character, we should not see the preceding characters after. For example, if we added \0x00, then we shouldn't see any more of the following characters from the badchars variable in the script.

STEP 6 - Find the JMP

Find the JMP ESP. ESP is the location where our shellcode will theoretically begin. We need to find the address of the function that will jump us to the ESP register.

In ollydbg, we can restart the application and right click, search for, all commands will allow us to search for jmp esp. We then will copy the address of this function.

With the address of the JMP ESP, we will now add it to the script replacing the 'B's. So when the buffer overflow runs, it will add the JMP ESP address into the EIP and have it jump to where our shellcode starts, ESP. Ollydbg helps visualize where everything in the application lives.

note: It's placed in little endian format

STEP 7 - Shellcode creation

Time to create our malicious shellcode.

Add the output to the script and call the buf variable in the buffer variable.

note: Adding a NOP sled prior the buf.

STEP 8 - Exploit

After your python script is ready, set up a listener according to the shellcode created and run!

Reverse Engineering Resources

Reverse Engineering is hard and I'm bad at it, looking for contributions to this section. Please DM me on Twitter

Reverse Engineering - WikiPedia

Intro to Reverse Engineering - YouTube

Intro to Reverse Engineering - Course Files

Intro to x86 Assembly - YouTube

Intro to x86 Assembly - Course Files

Awesome Reversing

Reverse Engineering 101 - Malware Unicorn

What Can Reverse Engineering Do For You? - Malware Unicorn

Lenas Reversing for Newbies

PoC||GTFO 0x16

PreviousChapter 7 - CrackingNextChapter 9 - Miscellaneous

Last updated

Was this helpful?