This post is meant to describe a 'different' approach to solving the Application 7 challenge of www.hackthissite.org. 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...
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
- 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.
- Setting several break points:
- The breakpoint(s) at which you need to perform you actions (such as altering memory contents)
- he restore breakpoint (s) that designate the end of your test and at which you will need to restore the initial process snapshot
- 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 serving 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 http://www.fuzzing.org. So kudos to those guys.
Fuzzer Source Code
