View Full Version : Newbie trying to learn. Think my project maybe a little to advanced.

September 13th, 2007, 20:43

Firstly, I would like to say I have been reading up on this for a bit now. I am understand how most serial numbers work, and how to crack them. I am using OllyDbg, and am finding it nice to work with.

I am trying to crack an application which requires a keyfile. There is a file already on my system called KeyInstaller.exe which was installed with the application I'm trying to crack.

The KeyInstaller.exe file has these text strings:

Keyfile Installer
Keyfile has been installed!
Keyfile Instaler
Keyfile Installer
Invalid argument given

As far as I can tell, the Application loads, checks to see if KeyInstaller is there, if it is, then it loads into Demo mode. If its not, It installs it.

So I have been trying to understand how the KeyInstaller works.

I know when you buy the software, you are sent a small file, which is placed in the same folder as the main application, which then gives you an option to type in the following:

User Email

It then gives you a serial, to email to the developers, who send you a code to unlock the application.

I cant find any infomation within the application about the Keyfiles name, extension or size.

Im not here asking for someone to do this for me, as Im doing it to learn. Can anyone point me in the right direction.



September 13th, 2007, 23:18
You can buy it and find out how it works or try to look for encryption constants inside the keyfile application (PEiD & IDA have plugins for this). Anyway this is too much of ping pong situation between a customer and a company, i wonder if they have any customers...

September 14th, 2007, 06:44
Thankyou Blurcode for replying, but I feel your suggestions are sumwhat unhelpful.

As I explained earlier, I do not have the keyfile. Its sent when you buy the application. So looking at its contents is impossible. Buying the software is an option, and I didnt plan on doing so. But I am currently trying to learn something new, and do this myself.

I feel just buying the software would defeat object here.

The company in question have plently of customers, because if you buy the software, its not to much hassel really.

If anyone else has any suggestions, I would really appriate it.

Also, I have tried getting it to always jump to the code which says "Registration Keyfile '{0]' Found" but even this doesnt work. I have no idea what '{0}' is, but I have seen it a few times. for example still within the application:

MOV DWORD PTR SS:[ESP+48],0A4CDB0 | Unicode "{0}\{1}"

Within the KeyInstaller.exe

PUSH 40B274 | Unicode "{0}\{1}"

My plan is to get it to think there is a valid keyfile there. Not by actually making one, but to have it see there isnt one, but still execute the code which would run one. The only problem is, I cant find the code for not finding it.

Also, does anyone have any idea what a Displacement Key is?



September 14th, 2007, 07:59
Have you thinked that the code that missing is this small file they send you the first time?

September 14th, 2007, 08:10
Yep, I do indeed think that is the case.

But the main application must be looking for this small file, because it has unicode saying:

"Registration key file '{0}' found"

This makes me think that there is away to get it always recieve a possitive on that check.

But I cant find the negative, to edit it.



September 14th, 2007, 08:32
[Originally Posted by Michael_J;68487]
I am trying to crack an application which requires a keyfile. There is a file already on my system called KeyInstaller.exe which was installed with the application I'm trying to crack.

As far as I can tell, the Application loads, checks to see if KeyInstaller is there, if it is, then it loads into Demo mode. If its not, It installs it.

I would guess that by the time keyfile installer is found or created, the application already has NOT found the keyfile. Think of it: Why do you need a key installer when you already have the key?

Here is the plan: Find FileMon (A free util by Russinovich, widely available on the web) and see which files your app is trying to find, before it searches for KeyInstaller. Let's assume it searched for "MyFile.key". (FileMon will give you a list of a lot of files your app attempted to open but were not found).

Then you can make your own bogus MyFile.key and place inside of it your favorite text: So you can find it in memory later on i.e. your favorite song?

Then by placing break points on CreateFileA for instance, catch your app opening MyFile.key loading it to memory. Then figure out what code validates the contents of MyFile.key.

So I have been trying to understand how the KeyInstaller works.

I doubt this will take you very far, Michael

In Blue

September 14th, 2007, 08:59
Cheers, I have now found out what the keyfile is called and created an empty version of it. You have really helped me along. Thankyou Naides.

September 14th, 2007, 11:17
The moral of this story (at least this little chapter in Michel's story) is that, no matter how secretive an application is regarding its protection, sooner or latter it has to interact with the operating system: call APIs, read files, set Internet sockets. It is then that we can peek at the protection hidden cards. . .

September 14th, 2007, 11:48
Well, Im not there just yet. Still working on it, but I have now read the softwares log file which reads:

i 2007-09-14 17:03:37] Cap::Licensing::LoadKeyFiles : Registration key file '.c2k' found
[E 2007-09-14 17:03:37] SysLib::File::Read : File ('D:\Program Files\*********\\.c2k') size differs from size indicated in file

So, its not cracked yet.


September 14th, 2007, 14:42
Look for a value , probably in EAX that is compared to a vlaue on the stack or to a value in memory - that's probably the expected value, you have several choices here you can do a mov eax,eax or make your file the size it wants - or simply xor eax,eax then make the appropriate jump - then you'll end up with an "invalid key" message, unlerss you can step thru and fish out the proper key, you have more work ahead of you - you're very lucky that your target is so verbose, many nowadays are not - intentionally to limit the amount of clues.


September 14th, 2007, 15:48
Im currently looking at how to just skip any kind of keyfile. It knows it there, which is great. Now im trying to just tell its there, when its not. Im not sure lucky is the right word here.

Its a good challange though. Been editing the code on this now for 2 days, each day brings me a tiny little bit closer, but the software really does some wierd things.

For example, I can change the Demo account to a Extended version by editing some of the code.

Demo Code:


Extended Edition Code:


Now, looking at the code there are only a few differences.

One being:

Demo = PUSH 0A4CF2C
Exteneded Edition = PUSH 0A4CF54


Demo = CMP AX,1
Extended Edition = CMP AX,3

Also, Demo has this line, which Extended, Basic and Partner edition do not:

MOVZX EAX,WORD PTR DS:[EAX+14]. (I have little to know Idea what this does)

when I edit Demo to follow the code of Extended, I load the application and it shows the applications name and then Extended Edition in the tool bar, but the save function and time limit is still running.

So dispite changing the application to run in Extended mode, the software is only telling me its running in the mode, when its still actually has all the limitations of Demo.

Slightly confusing, but that If i focus on telling the application that there is always a keyfile, which is exactly what it wants to see on the system. Then I may be in luck.

Although, It did occur to me, that maybe the keyfile modifies some code within the application itself, which could leave me a little stuck.



September 14th, 2007, 17:28
Just a guess but find out where MOVZX EAX,WORD PTR DS:[EAX+14] is in memory - look in the bottom of the disassembly window - write it down, reload and if you can and it's not in lower all purpose memory, set a memory breakpoint on write - when the prog breaks change the value loaded from 1 to 3 - and my guess is you will have a full enabled extended vers. tip: if when you reload the memory location is not available run the prog to that line then set a hardware BP on write at the memory location - restart when the prog breaks the code loading the value will be above the line it breaks on. - set a break on that line and remove the HW BP and restart.


Afterthought - a subroutine almost never starts with a cmp xxx,xx so there must be a jump to it above the code you show - looking at what precedes that jump will tell you more.

September 14th, 2007, 18:34
Here is the code for Demo user:

JNZ SHORT 00405013

Correct me if Im wrong, but i see that the first line, is saying something like If not equal to something go to MOV EAX,EBX

I have tried changing the code to say

If equal to something go to mov eax,ebx but it doesnt work. (I used JE SHORT 00405013)

Not knowing what SHORT means, Im a little bit in the dark to whats actually happening though.


I have just finished searching the internet for pictures of the activation process and found one for the version before. It shows a few things:

Before you can start using Application registraion keyfile you must unlock it for us on this computer. To accomplish this, - email your serial code and the unlock request code below to unlock MyApplication@ThisISAFakeEmail.com

Serial Code:
Unlock request code:

a button saying "Run in demo mode" in the meanwhile, the time limitation will be disabled"

and finally

"When you recieve your unlock code, enter it in the field below and press the Unlock button.

This is for version 3 of the software, and were now on version 4. Im trying to crack version 4.

Looking threw the Unicode, I can find referances to unlock, but I also find this:


Now they may have changed the product activation a little, to include these, but I have a feeling that these are decoys. Version 3.7 has a patch on the internet, which they stopped working on the next release, 3.8. Maybe they have got wise to hackers and are trying to trick us.

Maybe Im wrong and its just there to add more data to create the serial.

Anyway, back to trying to work out how this beast is actually working.



September 15th, 2007, 23:08
Oh hi, I seem to have found your problem.
[Originally Posted by Michael_J;68524]Not knowing what SHORT means, Im a little bit in the dark to whats actually happening though.
From that line and an assessment of * your Posts, it seems you know nearly NOTHING AT ALL about Asm! Randomly changing around bits of code may eventually lead you to "breaking" the protection, but what's the point? A million monkeys modifying the code would've probably done that better than you.

Download the 4-part IA-32/IA-64 Intel® Architecture Software Developer’s Manuals (PDFs, available at the Intel site), set aside several hours of uninterrupted time, and start reading them.

After you have read and understood everything you can from the Manuals, start reading and understanding the code, the keyword being understanding -- figure out what the code is doing, the entire process of activation et al. Only then should you come up with a few hypotheses on points to change, and proceed to test them.

September 16th, 2007, 08:11

Im definently not just just randomly changing around bits of code. Im looking at how its all connected and trying to work out what it does.

Im sorry Im not an Asm expert like youself, but we have to start somewhere. I have bought a book on Asm and im slowly reading threw it. I am very much interested how this works.

And with regards to understanding whats happening with the code. I have a rough idea of what is happening, and this software is NOT an easy piece to crack.



September 16th, 2007, 09:21
Michael, if you are new to this, maybe you should start with a simpler software then, as you have mentioned that "this software is NOT an easy piece to crack."

Have Phun

September 16th, 2007, 11:52
Hello Michael_J:

sigint33 gave you some excellent advise on how to possibly break this protection scheme you are working on. Try to find out where in code the address [EAX+14] gets set to a 1. If you find that, try to determine why it gets set to a 1 and not a 3.

Keep trying. Ask more questions.

If you want, you may private message me a download link to your target. No guarantees that I will even look at it, but, I may be able to help.


September 16th, 2007, 17:51
This is a difficult target, not only is that value being set, there are multiple values along with it that control menu items, save options, etc.. probably on the order of 5-10 of them, that mem BP does get you to a "sweet spot" but it is executed before the license is checked so even though you enable a bunch of stuff the proggie crashes when you attempt to use an unlicensed option, it looks as though fooling the target into thinking it has a valid keyfile is going to be necessary - or actually trying to fish out the needed info - more info - this target is a mixture of "C" and Python - looks like we need to try the Immunity Debugger - however I think the Python stuff is only for the graphics.


September 17th, 2007, 02:10
[Originally Posted by Michael_J;68564]I have bought a book on Asm and im slowly reading threw it.
Who buys books these days

Especially when there's "milliards of pages on the Web, a vast resource of knowledge of everything" (Fravia, searchlores.org)

Also, I believe you can order printed copies of the Intel manuals at no cost.

@sigint33: Python decompilers are awesome. Team 509 (Chinese group) have a version that works with the latest compiler.

September 17th, 2007, 11:11
Cheers SiGiNT for letting people know its not easy.

I have followed tutorials and been reading up on it online. I buy have bought books because I like to read before bed.

I maybe a newbie to all of this, but I am trying to learn and wheres the point in repeating simple tasks which I have already learnt? I choose this application because im trying to learn some more advanced software protection systems work.

After this application I will probably move onto to trying to crack some applications which require dongles.

Cheers for all your help though, Its really appreciated.

Michael J

September 17th, 2007, 14:28
Giant steps are not good steps - you lose a lot of the fundamentals in the process, for instance you could choose to try and reverse a HASP HL protected target in the future assuming that it can be done - maybe it can, but, no one has done it yet without the benefit of having a dongle to work with - the problem I'm going to have with your target is trying to teach you exactly how and why I did what I did, with well protected targets sometimes the only approach is to patch it willy nilly until it runs - then go back and undo what you did one at a time to find the unnecessary patches - this particular protection has in the past been called "magic bullets" and in it's more common use a Dword is assigned in memory for product activation status which is indicated by which bytes are 0 or contain data - this particular target has the "bullets" located in different areas of memory the best way to reverse this one is to generate a valid license - and that's not going to be easy, especially for a hack like me, but, we'll see I'm determined to teach you something in the process - please feel free to share the target with others, I could stand to learn a lot myself


Just a note - to reinforce what I said above - this app. comes complete with a command line keygen, but nothing to tell you what the command line syntax is - someone who had a really good understanding of assembler and a lot of time could probably figure it out - that would be a great learning experience for a noob!

September 18th, 2007, 09:40
I just had a short period of time to work on this last night, but here is a tidbit, in the lic. routine @4E790E the lic file size is checked, there are 2 ways to approach this, the line is CMP ESI,DWORD PTR SS:[ESP+20] - you can fool it by changing it to MOV DWORD PTR SS:[ESP+20], ESI or you can insert as the first Dword in your lic file, in little endian, the value compared, for instance if the value @ the memory location is 0000010A change with a hex editor the first 8 bytes in your lic file to 0A010000, this will allow you to proceed with the rest of the routine.


September 19th, 2007, 00:59

Has anybody else perchance perused this target????? - I noticed this last night and really didn't think anythimg abput it - BUT - without a license you can enable the save functions easily by changing 4F52FC SETE to SETNE - but when you try to save one of the demo files it gives the message "the file contains extended features that may not be saved" - if you break on this nag and look in the stack, on my machine it breaks after executing atioglxx.dll - a video driver file - if you bring up this file in the cpu window and do a text search you get a listing of pretty much every serial and license used on your machine - this is really unsettling and bizarre behavior - anyone have any comments? Or can verify this on a different machine?


That combined with the name of the target tweeks ny paranoia bone

September 19th, 2007, 01:53
[Originally Posted by sigint33;68647]but when you try to save one of the demo files it gives the message "the file contains extended features that may not be saved" - if you break on this nag and look in the stack, on my machine it breaks after executing atioglxx.dll - a video driver file
Not surprising, if the program outputs through the driver that's where I'd expect to end up after any output occurred.

September 19th, 2007, 09:21

That's not my concern, it certainly is a graphic intensive app, but why would a video driver be logging what amounts to the contents of my registry and environment, almost exclusively licenses?? - I do assume its a third party driver due to the "gl" contained in it's name, as a good portion of the code this app uses is open source, if I make a leap of faith I can almost believe it's for error reporting as this does seem to be a legit app. but it's behavior is odd at best.


September 20th, 2007, 00:53
It is not unusual for 'tricky' developers to attempt to hide their main protection code and library by using ambiguous or deliberately misleading filenames and export names.

Its quite possible that the file is just an extension of the product that was installed somewhere in the Windows path in an attempt to hide it somewhat. Naming it something like atiblah.dll also would make most people skip over its reference as unimportant.

If the dll file has a blacklisting of serials and such its quite probable that the author knows people are cracking his software and is trying to put as many obstacles in front of the attacks as he can...

A classic case of security through obscurity

September 20th, 2007, 01:36

I've seen that many times, actually used it to my advantage by learning a valid but blacklisted number - then patching around the obligatory "violators will be prosecuted ... blah blah" to reg the app, but this list also contains FlexLM references and all kinds of interesting stuff - it's late but may be I'll disassemble it just to see what the hell it is.


September 25th, 2007, 13:13
Sorry for not being so active lately. Just moved house and havnt had the internet.

I have been carry on with trying to crack it. Still not closer. Will carry on tonight, with the new info and let you know how I did.

Has anyone had any luck so far?

September 25th, 2007, 13:39

I've put this one on hold for the moment - things have gotten busy at work and around my house - read up a ways and you'll see some of my discoveries - I'm pretty much convinced, (everytime I say that I prove myself wrong), that generating a valid license is the way to go - I'm not good at that - I'm pretty much a hack but I can use the education - so when I have time I'll see what hapenns - I really want to look into that video driver crap - the file is newer than the last time I updated my driver so I need to find a clean comparison.


September 27th, 2007, 12:13
I have just been playing around and have enabled the save function like you described. It however crashes everytime I try to save. So we now have the menu working, but the app doesn't actually want to save.

I found the area of code which relates to the 1 hour 30 minute limit on the app and have changed it. Fingures crossed that will stop the "you are using a demo version of APPLICATION which is limited to 1 hour 30"

I was looking on my machine for this file you mention :atioglxx.dll

Im sure im being dumb, but I cant find it anywhere on my machine, or anything like it.



September 27th, 2007, 12:42
You wouldn't have it unless you are using an ATI graphics card - interesting note, I was working on another app last night and had it running fine 1 time - on the next run it crashed while accessing the same file - this was an app that I'm sure was not using open GL stuff so it's really starting to bug me - eventually I got the app. up and running with no problem.


September 28th, 2007, 13:02

I have now got the application running for as long as I want it to. So that demo restriction is no longer working. This is great. One more step and then I have actually got the application running as well as purchased copy.

The save feature is the second bit of the app Im going to try and get sorted. It just crashes on my PC. Im going to try and clean install of XP and the application on a different PC to see if that has any effects on it.

From what I can tell, it looks like it checks whether the file is there or not when trying to save, sees that its not. Tries to write the file and then an access error occurs and it closes the whole app. Kind of odd, but I shall work on it.

Im going to buy the software in november so, if worst comes to worst, I shall view the legit copy and then work out how the app works.



September 28th, 2007, 16:10
Don't bother on the install of XP - it crashes my machine also - my SWAG is that it checks for a valid lic. before saving - setting the byte that makes it say it's a good version is not enough - there are at least 5 memory locations that need to be set and maybe more - maybe you can successfully trace into the save function, if I break the app. at the save screen and start a trace it crashes immediately, I didn't have time but try walking the stack back to the cause of the exception, after it crashes hit the"K" button set a breakpoint by double clicking on the lower line in the stack window then set a break on that line in the cpu window - do this again when it breaks on that line - repeat until you are back in a program module - then trace back to the branch to the exception.


October 4th, 2007, 10:56
I have been playing around with the application a little more. It now believes its in extended mode. But the save feature is still not working. I have used file monitor to watch what is happening, and it would appear to be a buffer overflow. Im going to carry on tonight trying to solve the issue.

Its now getting close to cracking the app, as the time limit is no working active, it shows its in extended mode and the save feature half works.

Who knows, maybe soon we will have this bad boy cracked.



October 5th, 2007, 01:14
Good to see someone developing progress on their own.

Perseverance is a virtue.

December 26th, 2007, 16:27
I kind of hit a brick wall, and the more I thought about it, the more it made me think that the Keyfile added code to the software.

The only way I was going to crack this software and work out how it works was to get a keyfile. So I opened up my wallet and did what I always planned.

I spent $1,617 on the software so I could work out how it worked.

I have the keyfile now sat on my desktop.

It installs itself and when you load the software, it loads a new window asking for a serial number.

When I dont enter a serial, it comes up with:

"The unlock code entered is invalid. Please verify that you have entered the correct code! If the problem persists, contact us by email to *****@*****.com"

I formatted my PC only a few days ago, and havnt installed Olly yet, but will do on a Virtual PC, and give this another go.

Of course, Its now almost pointless as I have the software legitamitly, but I only ever did this for learning.

Cheers for all your help, and fingures crossed I will be able to have a working crack soon.



January 10th, 2008, 06:53
Noted one of your firsts posts:

"Registration key file '{0}' found"

Usually {0} is used to pass arguments when printing or building strings in C#, have you checked to see if this is a C# or VB.NET related program? If so, you may make it easier by trying to look at specific tutorials and resources for disassembling the application.

February 5th, 2009, 11:14
Interestingly I've been having a go at the same application being discussed above (as my first attempt at reverse engineering).

I was feeling really chuffed with myself for having worked past all the keyfile checking routines and being able to reliably select which version of the program I wanted to run (Demo, Extended etc...), when I hit the same problem as Michael - when you click 'Save As...' it crashed.

Upon further inspection several of the pointers to functions used in the save routine are stored in a table and encrypted. The encryption seems to be a simple XOR key, and knowing that pointers to code almost always begin with 00 and often end in 0, I've been able to work out the repeating key length - 36 bytes in this case, and some of the XOR keys.

However I'm really stuck now, as digging through the code it appears that the encryption key is supplied in the keyfile they deliver (this part of the key will obviously be the same for all users).

I've had a look to see if I can take educated guesses at these function pointers, for instance I could XOR pointers encrypted with the same key together to find out the difference between the original pointers, however that didn't really narrow down the search enough.

What I'm quite surprised about is the fact that they bothered encrypting the pointers - why not just supply the exe with 00's in the table and supply the actual function pointers in the key file? The way they've done it I at least have some clues about the data.

Has anyone come across a similar situation before and if so, how did you solve it? Failing that if someone fances halting a working version of the app and sending me the 36 bytes of data starting at 0x009581B0 that would also be good

February 5th, 2009, 13:31
I've just had a brainwave!

If I can get hold of slightly earlier/later versions of the same program then the chances are the functions used will have moved slightly.... If they haven't changed their encryption key between versions then by XORing the two encrypted tables together I will cancel out the key and be left with the differences between the original location and the new function location.

I can then do a binary comparison of the two executables and see which functions have moved by the offset given.... this should at the very least narrow down the search.

(the version I've been working on is 1.13.4)

This hasn't actually helped because I haven't been able to find any other versions, but I like the principle...

Any other ideas? This is almost a straight cryptography attack problem rather than a code hacking one.

February 5th, 2009, 16:32
Problem with that, it's a huge pain in the ass, long calls may have changed, a bunch of stuff just adjusted slightly will throw you of big time, they also usually change the base address and multi purpose registers may have changed, disassemble both, split screen try to line them up and go from there.

Good Luck


February 5th, 2009, 19:30
That's what BinDiff and friends are for SiGiNT...


February 5th, 2009, 20:01
I have to plea idiocy on this one, I've never bothered trying bindiff, but, usually look for a common landmark in both disassembled files then try to line them up that way - frequently I find that jumps with in a routine and addresses called from another routine have been added or subtracted, so using gray matter, (I aint got much left), is usually what I rely on, if you really want to have fun, try comparing your unpacked file to someone else's unpacked file, here I'll usually scroll down in the Winhex window until they match and then trim off the top and run compare, going with the parts that make sense.


February 6th, 2009, 06:23
Okay - maybe that idea is a non-starter (it certainly is until I find any other versions).

I'm basically after clues to help me construct the key - here's what I know:

* The key is 36 bytes long and is simply XOR'd with the pointers
* The same key is used to encrypt 3 different pointers (i.e. roughly 27 pointers are encrypted in total).
* 18 bytes of the 36 byte key are fairly easy to guess, because most function pointers begin with 0x00 (the 0x1f ones should be fairly easy to spot)
* Statistically I can get 3 or 4 bytes more, on the basis that a lot of function pointers end in 0, however with only 3 pointers encoded with the same key this sin't really working for me.
* I do know that the pointers will point to the start of functions - can I use this knowledge in any way?

I did wonder if I could write a program to brute force the remaining bytes by testing each possibility (as there are only 6 bytes left per pointer to guess this is only 16 million possibilities) - in order to test each possibility I would check if all 3 pointers encoded with the guessed key line up to function entry points as decided by IDA Pro. However I'm not sure this will work - IDA pro has misidentified a couple of function entry/exit points on functions which had blatent pointers to them. As the functions I'm interested in are probably not called from anywhere except these encrypted pointers who is to say that IDA has identified them at all? I may also get several thousand 'hits' if luck isn't on my side of which I'd have to trawl through manually.

If we think along the brute force lines - are there any other ways I could test for valid pointers? I do know the number of parameters being pushed onto the stack before the calls, however how could I check how many the functions were using in a simple script?

February 6th, 2009, 15:57
Pythag, here's a quick thought. In your brute forcing function, you could look for the typical "function setup bytes" each time. The normal "mov bp, sp", and the like. If you dig around, you should get an idea of what the compiler produces for a function, and in theory, be able to look for those bytes at the locations produced after each iteration through your function.

Does this make sense?

February 8th, 2009, 15:43
I had a quick look and unfortunately there isn't any consistent easy-to-spot pattern. Most functions start off by pushing a few bits and bobs onto the stack, but what they push varies considerably (some don't push anything).

Around 50% of the functions seem to begin with 'push 0FFFFFFFFh' - why would a compiler do this? Maybe it's the default return value of -1 that people often use?

As the program doing the brute-forcing can do a bit of statistical analysis I can probably say "if it starts with 'push 0FFFFFFFFh' then I've almost certainly found a function entry point" and "If it starts with a push of some kind then I might have" and use that.

My gut feeling is that I probably have enough information here to rebuild this table, but it's going to take a bit of work.