Have anyone tried this approach? Is it even possible?

Imagine a target with complex algorithm for serial key protection.
The only thing that you can currently see is the fixed key length and allowed key characters, everything beyond that is hard to follow during the debugging because too much functions, too much math operations ...
You have found an function in target that does the calculation, checking, etc ...
Also, you have found where the application jumps if the wrong serial key is entered (app shows MsgBox with wrong key).

What if we can save ourself from all the tracing, taking notes and calculating the operations on paper ... all the manual cracking? What if we can code a small program that will attach to our target, set the key, modify the EIP in target and let it loop thru the all possible key variations. Since we know where the application jumps if wrong key is entered, we could set a check there, so if EIP points to there, we can switch to next key, insert it into target again and modify the target's EIP.

It would loop thru the code till we find correct serial key. When the key is found, our program tells us.

Basicly, using the target itself to get the correct serial key.

I tried looking for some documents and this is the closest thing I could find:
(Cracking with Loaders: Theory, General Approach and a Framework
Shub Nigurrath)
http://www.codebreakers-journal.com//viewarticle.php?id=65

Thank you,

please do not flame!

Hi

I believe you're talking about a self-keygen or black box analysis concept. If say you choose the start of the analysis function as your loop 'start' and the error MessageBox EIP as the loop 'end', then just start inputting values, you've got a bruteforcer without the usual ripping of code. This is a good idea but it's still a bruteforcer which may take days to complete.

You may be able to refine the idea a bit. Depending on the algorithm function you may be able to identify certain jumps or calls which lead to the desired execution path. Inputs which don't lead to that path can be eliminated at an earlier stage than waiting for the MessageBox.

Rather than using a strictly bruteforcer (sequential) approach to generating input values, you can theoretically use a Genetic Algorithm (GA) method to 'evolve' a population of values which lead further and further down the desired execution path.

You might want to look at the following paper which discusses using Genetic Algorithms in a black box fuzzing approach.

Sidewinder: An Evolutionary Guidance System For Malicious Input Crafting
http://www.blackhat.com/presentations/bh-usa-06/BH-US-06-Embleton.pdf

There may be further papers around or others with ideas which give a more practical approach to designing such a black box analysis.

Cheers,
Kayaker

Obviously this is an admirable undertaking, that a lot of people would love to see done successfully, I assume you've done the math and realize the gawd-awfull amount of combinations that even a 12 character serial can represent, but to play devil's advocate for a moment, just based on my observations, a heck of a lot of app's are switching to server verification - thus requiring patching up front, you've mentioned identifying the good boy jump, it seems to me once you find that, you can trace back the code that generates a valid condition, this code if traced back far enough is usually the same routine that verifies the serial on start-up also, so patching is far more attractive than tying up a machine for many hours or days or weeks. I've also run into several apps that intentionally run a loop that makes the checking routine last several seconds further complicating the time allowed.

Don't get me wrong, this tool if you were successfull, would be great, I'd love to see one that specifically could find a valid serial for hardware fingerprint protected Arma.

Just a few thoughts -

SiGiNT

Howdy,

No flammage intended.

There is absolutely no bad reasons why this idea would not work.
You would need to make it target/protection specific.
In other words, to save a huge amount of time, you could code a target specific algo into it so you are not wasting time searching for a 16 character key when the target requires 12 or 24 characters.

I also would be more concerned with server based verification.
That will be the future. I think 50% if not more now use that method.

Woodmann

This approach - especially the evolutionary one, which btw is an interesting field of its own - might actually work for a lot of the more homespun serial algorithms out there (i.e. simple checksums, substitutions and the like), but one should be aware of the fact that it'll almost certainly fail if your target uses any half-decently implemented crypto (e.g. Armas hardware locking algorithm).
Therefore the targets such a tool might succeed on are usually easily reversed in the first place (the exception proves the rule).



regards,
Pyrae


P.S. Don't get me wrong, I don't wanna keep anyone from implementing such a tool, but one should consider its very, very limited use in real world scenarios.

"Speed up"? More like "slow down", except with trivial cases such as maybe 6-8-digit serials.

Computers are certainly much better than humans at rapid operations, but still don't have the intelligence of a skilled reverser. "To be successful, one has to know when to invoke the calculating power of the Machine, and when to use one's own mind in Analysis."

If you're not talking about keygenning, finding the critical jump and forcing it is probably going to take far less time than attempting to bruteforce the serial key, and is mandatory for remote server-based schemes.

Writing a program to run an algorithm in reverse, however, is a much better strategy for "automated cracking".