Friday, 28 November 2008

HackThisSite Application 7 Solution Using In Memory Fuzzing

Hello All,

This post is meant to describe a 'different' approach to solving the Application 7 challenge of It does so by using a technique called 'In Memory Fuzzing'. To avoid any flames as to whether that is fuzzing or bruteforcing you can call it whatever you want - I call it recursive fuzzing as per owasp.

Tools that will be utilised are:

  • Immunity Debugger v1.4
  • Python 2.5.1
  • pydbg (edited pydasm.dll to support python25.dll)

Providing a detailed analysis of the binary is not part of this post. Other's have done it - a lot better than I could have done it. So here goes...

Rough binary(app7win.exe) breakdown

The following is a rough decomposition of the app7win.exe binary in logical blocks:

We can see that the only purpose the password that is inputted by the user serves is to add all the characters in one key and use it to decrypt the file and produce the final password. This Key (K) is stored in [EBP-1C]. That is what we will fuzz - "bruteforce".

In-Memory Fuzzing in a Nutshell
So now that we have broken down our interesting function it is time to start preparing for our fuzzing. In Memory fuzzing works by

  1. Taking a process snapshot at an ideal – for your type of tests – point. This will be used a the initial state of your tests and is the state that the process will be restored to after each test run.
  2. Setting several break points:
    1. The breakpoint(s) at which you need to perform you actions (such as altering memory contents)
    2. he restore breakpoint (s) that designate the end of your test and at which you will need to restore the initial process snapshot
  3. Setting callbacks. Those are action you need to take at each breakpoint hit. It may be different actions per breakpoint

For a more thorough explanation of Memory Fuzzing have a look at the book ‘Fuzzing: Brute Force Vulnerability Discovery’ by Amini, Sutton, Greene.

Let's start fuzzing

As a rule of thumb – which is sometimes bent

a bit due to special circumstances – we will try to alter the execution of the original binary as little as possible.

Thus far we have identified that the contents of [EBP-1C] are used as the sole basis to perform several mathematical operations on the encrypted.enc contents and subsequently - based on the outcome of these operations ( 0040118C |CMP DWORD PTR SS:[EBP-18],0DCA ) - provide the password.

Another parameter we must work out is the range of the fuzzing parameter (bruteforcing). This was calculated as the result of hex(7D) (max ascii printable character code) * 20 (possible password length) = hex(9C4). It was decided to round that up to hex(1000).

Try 1: After Initial Calculation

For our first run we used

  • 0x00401064 (immediately after the password has been inputted) as our process snapshot point
  • 0x004010E0 (just before reading the key for the first time) as our rewrite memory breakpoint
  • 0x004011AD (at the ‘Display Invalid Password' code segment) as our rewind breakpoint.

This never worked past the first iteration. It kept breaking with a

ACCESS VIOLATION ERRORS. If anyone can point as to why I would be grateful.

Try 2: Entry Point

For our second run we used

  • 0x004014C0 (process entry point) as our process snapshot point
  • 0x004010E0 (just before reading the key for the first time) as our rewrite memory breakpoint
  • 0x004011AD (at the ‘Display Invalid Password' code segment) as our rewind breakpoint.

Executing the fuzzer at this point worked OK with a small glitch, it was asking for the password every time. It was time to bend our previous rule of thumb. The only use password entry was ser
ving was to calculate the initial key, that is the value being stored in [EBP-1C] which we were resetting after all. So the password entry point was NOPed as is shown in the following screenshots.

At this point the fuzzer worked as expected. The fuzzer source code is provided in the file accompanying this post.

Although it is mentioned explicitly in the fuzzer source code I must stress that a large part of my fuzzer source code is ripped from the In Memory Fuzzer found in So kudos to those guys.

Fuzzer Source Code

Saturday, 8 November 2008

Sulley on Python 2.5.

Sulley is a multipurpose fuzzer created by the guys at TippingPoint (3Com) in Python. More on sulley can be found at the BlackHat USA 2007 talk titled "Fuzzing Sucks! Introducing Sulley Fuzzing Framework" (pdf) (mp4).

The installer comes with local copies of the Python 2.4.3 programming language, the pcapy python library, the ctypes python library and WinPcap 4.0.3. All of these are installed along with the sulley fuzzing framework.

Although not exactly rocket science I did not find anywhere a guide on installing sulley in a Python 2.5 environment. So I decided to give it a go and create one myself.

  • Install Python 2.5
  • The ctypes python library is, as of Python 2.5, included in the Python core so nothing needs to be done as far is this is concerned.
  • The pcapy python library on the other hand is not, so it needs to be downloaded from The file that worked for me is pcapy-0.10.5.win32-py2.5.exe. (sha1sum = 04e2e969e343e01adaec44680376714a6b10c97b)
  • Install Winpcap (Optional)
  • Install Sulley Fuzzing Framework cancelling out on all additional packages it prompts you to install with the exception of WinPcap (based on whether you chose to pre-install it or not - See previous step).
  • Finally, sulley comes with a Python 2.4 based version of pydasm.pyd. My preferred way is Hexedit the pydasm.pyd and change the python24.dll with python 25.dll.

Et voila!!!! A working sulley installation.

Hello World!

So I started blogging... Big deal...

Anyway, this blog is going to be largely related to information security in random topics I am interested in (the rand part of it) and at various other aspects of our life (the rant part of it).

A few words about myself...
  1. check the box on the upper right corner of the page you are in.
  2. I work in the field of information security. My current interests are:
    • Reverse Engineering
    • Malware
    • Penetration Testing
    • .Net Programming (C# mainly)
    • Fuzzing
I hope to see you again...