How to defeat challenge site crackits - “”Internal Brute forcer”"

The Idea

Many crackits aren’t that difficult, and have fairly simple algorithms. Which could be easily brute forced. There are several ways that you could do this:

• Recode the algorithm used in another programming environment and add a brute forcer loop.
• Use an external program, that tries to validate every password. The external program would interact with the target using the win32 API
• Use the crackit itself as a brute forcer.

However, copying the algorithm to another envirement is very error prone. For example there could be values that are initialised in an obscure way. Or altered by a debugger check somewhere. Other than that this requires quite a lot of knowledge and effort.

Using an external program is much slower, and only works in limited cases. For example if the crackit closes itself after every try, this method would be ridiculously slow.

The solution to all these problems is the Internal brute forcer. In essence a brute forcer is a simple idea. It basically consists of these 4 steps:
1: input the first password
2: Run the algorithm
3: check if the algorithm returned the correct result
4: if not try the next Password

The good news is that the crackit already does steps 1 through 3. Hence all we need to do is step 4 (Jeej). Wait, there’s more good news, step 4 is often brainless and can be reused from previously solved crackits.

The Example

Since seeing is believing, I took the liberty to prepare an example. As always I’m not an artist so we’ll have to make do with this layout ;-).

You can download the source code and executable here. This time it was written in Masm, heavily using the Macro’s so it should be easily understandable to everybody. I used the RadASM IDE with the ‘programming pack’. If you are not familiar with these great tools and the power they posses, you really should check them out.

If you want, you can take a quick look at the source code. It might help you grasp the assembler listing below a bit faster. As you probably noticed the program is really tiny. We don’t need to brute force this. But we are pretending that we don’t know and, more importantly, don’t care how the function “Checkpassword” works.

Believe it or not this is all the code that makes this 3072 bytes example .exe do what it does. You can click the “M” on top of the OllyDbg toolbar, and check out what the other sections contain, studying this could really give you an insight into how windows(tm) operate. I’ll give you a short explanation of the assembly listing. First there are some initialisations. Next (at 0×00401022), the program asks Windows(tm): “O lord windows(tm), could you please draw this dialog box as described in the data section, and then don’t bother me again until something happens to that dialog window? Windows kindly does this. From now on it will only transfer control to the program(at 0×0040202E) when an event occurs “window redraw”, “mouse click”, “key down”, … and plenty more. When this happens, my program will check which event occurs. The only one of interesting to us is the “hey this command button got clicked”. The program realises this when it reaches 0×0040204D. It will now get the user input, run the checkPassword(at 0×004010C2) routine, and then display either the good or the badboy message. These are steps 1,2 & 3 which I mentioned in the introduction.

The only bit of code that I didn’t explain yet are the jumps at the bottom, this is called a trampoline, and enables my program to call windows correctly. How this works exactly is outside the scope of this tutorial, intresting none the less. Researching IAT will get you in the right direction.

So now that I made absolutely sure everybody can understand what’s going on. We’ll advance to the next section.

Adding the brute force loop

In the introduction I promised this method also bypasses debugger checks. Well it does. Everything except integrity checks. (file checksums, file size, …) Because we can add the code, save it to the .exe and run it as a normal program. Without OllyDbg. This usually beats the crackit authors most devious anti debugger tricks(due to the absence of a debugger ;)). However if we know debugger checks are not important we could use features of ollydbg to simplify some steps. Since they both have their advantages, I need to make a choice. I will explain this example using the last method facilitating ollydbg, and point out the differences with the other as we go along. These explanations will be indented and can be skipped if desired.

Where

It’s clear by now we are going to add code to the existing program. Our first concern is where. We don’t need much space say around 50 bytes is usually enough. We are looking for something that is often called a “cave”. It’s a bit of unused space somewhere in the executable. Because of alignment issues there’s usually plenty of space we can use. Most often it’s enough to scroll through the code section in search of a bunch of zero bytes. When using the Ollydbg method, we don’t have to bother about this at all, if there really really isn’t any place you can use, you could just trace past the initialisation code, break, and overwrite the initialisation code. Of course we can’t do this when we want to save the brute force loop to file.

We need to ensure that the PE headers of the .exe list the correct sizes. Or it might not be loaded correctly. Since the alignment in an .exe(often 0×100 bytes) are usually different from the alignment in memory (basically always 4kb), not all the bytes you see in ollydbg, will be mapped into the .exe. You can edit PE headers with various tools, among the more popular ones is LordPe. This is a piece of the PE header that illustrates this issue. It was taken from ollydbg, click the “M” on the toolbar double click the “SimpleKey PE header” line, a window pops up:

Here we are looking at the code section header and the rdata section header respectively. The virtual size of the code section is 0×10E bytes long(meaning there are 0×10E bytes used), but because of the file alignment(every section must have a size which is a multiple of 0×100) the actual size (size of raw data) is 0×200. So we want to set the Virtual datasize to 0×200 as well. This way we can use the remaining 0×92 bytes. Now If you look at Ollydbg the code section, goes from (Relative virtual) memory locations 0×00401000 to 0×00402000 meaning it’s 4kb in size. Plenty of zero’s :). This is due to the memory alignment. However keep in mind that any alterations to a memory location above 0X004011FF will not be saved to the executable and is useless to us, when we want to be able to run the brute forcer outside ollydbg. It should also be noted that this is dependant on the windows(tm) loader, the part of the operating system that ‘loads programs’(copies the data from the .exe to memory, fixes import addresses and such, jumps to the first instruction), If this bit of software is set to ignore the virtual size field, and just copy SizeOfRawData bytes, this doesn’t matter. As far as I know different versions of the Windows(tm) loader will do this differently.

If there isn’t enough space, you could look if there is anything you could overwrite, like for example an about dialog, or why not, the code that makes the program exit cleanly. Basicly anything that isn’t needed to get the crackit to validate a password. Or since overwriting is dangerous you could use LordPE again and make the any other section Executable. And if that doesn’t help you can always add a section to the executable using for example zeroadd

In both cases we would choose the locations 0×004010E and following. This brings us to our second concern.

What

Now for the juicy bit, the brute force loop. First we concentrate on the part that will generate the next password to try. I’ll present you with two versions. A fast one, which often works, and does for this example. A slower one, which is usually less of a hassle to get right.

The Fast one:
60 BE 74 30 40 00 8A 06 FE C0 3C 7B 75 07 B0 61 88 06 46 EB F1 88 06 61

You can just copy the bytes above the image over to ollydbg. Just select the line above the image, copy it to the clipboard. Go over to ollydbg, select the bytes you want to paste over (say 40110E through to 401130) and use the context menu to go to “binary”->”binary paste”.
This code brute forces from a through z. If that’s not the desired range change the constants 61 and 7b appropriately. furthermore the address 0×00403074 is hardcoded for the address where the encryption algorithm will look. This is the bit that might cause hassles. If this causes problems you should use the next version.

The slightly slower one:
If we don’t want to poke directly in the string that the algorithm uses. We can keep track of our own string. And use the windows API SetDlgItemTextA to feed the password to the crackit. Just as windows(tm) would do it, when you typed it into the textbox. We are calling windows(tm) code, and this snippet is larger, so it will eat up more clock cycles. Usually we don’t care about that too much, but ye be warned. We will store the string in the data section, because the code section is not writeable (even though ollydbg won’t complain when saving to file …). Since it will only be accessed at runtime we can use the entire 4kb of the memory page that the data section is loaded in. Hence we can use all of the 0×403000 through to 0×00403FFF memory locations. The PE headers of the executable file states that it only uses 0×204 hence we can probably safely use anything past 0×403305. Lets take 0×00403333.

You need to adjust the address for the SetDlgItemTextA api, and the push right in front of it, to use the right window handle. You can easily retrieve this handle, if you first run the crackit, and then press the “W” in the ollydbg toolbar.

REMARK:This one might not work when you save it to file, and if it does the .exe will crash on other computers. Because the API function is not imported by the .exe. So basically Ollydbg knows where the setDlgItemText API is located in memory and patched in the memory address for me. However this address changes from OS version to OS version. There is a way to locate the correct address at runtime though, Even without the GetModuleHandle and GetProcAddress API. However this too is outside the scope of this text. Also in this snippet I hardcoded the window handle argument for the SetDlgItemTextA api call, this won’t fly if you write it to a .exe-file. you will need to pass the hwnd as an argument, or get it some other way.

How

Ok we almost have everything. All we need to do now is tie in the brute force next-password-generator with the rest of the code. Basically somewhere in the code we need to add a JMP [first instruction of our incrementer]. And to finalize our creation we need to ADD a jump towards a point somewhere before the checking algorithm. These “somewhere”s are tricky. We will be interrupting the normal program flow, to some stuff, then jump back to program code. What makes it even worst is that we will be doing this millions of times. Hence we need to be extremely careful that we don’t “break” anything. For example if we add one dword on the stack every iteration a crash is inevitable. We also don’t want to disturb the algorithm, and thus make sure that all the initialised values are valid. Often this isn’t much of an issue, but if it goes wrong, this is probably what caused it.
Ok, that said, first we concentrate on the jump towards the incrementer. What would be a great place to add it without breaking anything? Right the “bad boy” messagebox. After the check there is optional MessageBox that displays if it was correct or not. Now if there’s one thing we don’t need it’s a messagebox telling us that we got the wrong answer so just patch the instructions at 0×00401087 with “JMP 40110E”. You do this by selecting the line in question and pressing the spacebar, and you will be prompted for the new commands. After the incrementer code, you would, in a similar manner add a “JMP 401066″ this is right at the call to checkPassword.

Voila you have a working brute forcer. Ok Ok we forgot to mention one final thing. After the brute forcer finds the password, we must know what it is. You could simply break on the goodboy messagebox and check the memory at 00403074.

If you want to write everything to an .exe. You will need to do some aditional work. Basically you need to patch the goodboy messagebox to also output the password.

That’s all folks

This really is all there is to it. Our computers have gained in strength substantionally since most of the crackits that are around today were written. Therefore many crackits are easily brute forceable. My example crackit returned a result within minutes for the 7 character password. In my experience the fiddling that is required to get this technique to work, is far less of a hassle than trying to reverse the algorithm. I hope you enjoyed the text keep the comments coming. I invented the code snippets on the fly, I’m sure there not optimal but they get the job done.

dis z d another i go throw …

Free Tools

• Youtube Downloader

• Find Domain age,Pagerank,Valid Pagerank, Directory Listing,Indexed Pages in Search Engines,Web Archive, Alexa Traffic and Graph

• Free RapidShare and MegaUpload Search Engine

• Watch Live Tv

You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.