Friday, November 28, 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


  1. Hi,

    I wanted to give a try at your solution but whenever I try to run it, the following error windows raises :, line167 in dbg.load('app7win_NOPed.exe'), line 2431, in load raise pdw("CreatedProcess()", True)
    pydbg.pdx.pdx: [2] CreatedProcess(): the specified file was not found

    Any hint about how to bypass it?

  2. Hello utwor,

    The fuzzer expects a app7win.exe having NOPed the password entry point. Check the last two screen shots in order to see how I have done. Rename the resulting executable to app7win_NOPed.exe, put it in the same directory as the fuzzer and give it a try.


  3. dude can u explain wat to do after the last screenshot..??

  4. @narad nothing, just run the fuzzer and it will take care of the rest.