Fog Creek Software
Discussion Board

Key Generators - How do they work?

I was searching on a software package on Google and came across a number of links. One of the sites offered a key generator to the software pacvkage.

i.e. I assume that the generator will give me a serial number to use the software.

How do the key generators work? There must be numerous permutations for creating serial numbers for software.

How are these cracked?

BTW - my questions are from an academic perspective. I am not about to embark on a career of cracking. My job depends on people paying for software.

Ram Dass
Wednesday, November 12, 2003

<g> Im assuming you re not an (experienced) programmer though or you would be able to think that one through yourself..

Wednesday, November 12, 2003

They just generate numbers that satisfy the check in the software.  For example, a random bit string followed by the right kind of checksum.  Best way to learn how is usually via program disassembly.

H. Lally Singh
Wednesday, November 12, 2003

I believe crackers usually decompile the source to assembly language and locate the validation functions, and then pretty much run them in reverse.

Eric DeBois
Wednesday, November 12, 2003

Tracking down the section of code that validates the key and then inverting it to create a generator is pretty straightforward.  Usually there's some message box that pops up saying something like "Invalid key".  The section of code referencing that string can be easily found and is typically preceded by the validation algorithm. 

Usually, the algorithms aren't at all complex.  At one point, all that Microsoft's validation code did was something like add up the numbers in the key and check if the result is divisible by 7.  The point is to "keep the honest people honest" as the saying goes.

Wednesday, November 12, 2003

Strange how all the posts are on how to crack key generators and now how to write one.

I think Credit Cards also work on a simlar scheme, ever mis-type your credit card and immediately after you hit submit, before even the page does anything, it tells you you must enter a valid number? You might want to start looking at how that happens, how to create a sequence that satisfies a certain criteria, how to figure out what that critera should be in the first place, etc.

I thought for sure this thread would be about encryption and public/private keys and how a few wiggles of the mouse generates a key. Oh well.
Wednesday, November 12, 2003

Chi Lambda
Wednesday, November 12, 2003

Credit card numbers are very easy to validate.  It's a matter of verifying that the sum of the digits (with some quirks thrown in like doubling every other digit) plus a check digit (tacked on the end) is divisible by 10.  I believe it exists mainly for detecting simple typos.

Thursday, November 13, 2003

Credit cards are a great example,  the algorithm is basically used to catch transpositions and typos.  It's not terribly secure,  but it's the same idea. 

Check out:


Michael Koziarski
Thursday, November 13, 2003

Just a thought on the decompilation process.

Any ideas how effective the approah of implementing a simple lisp machine to carry out the checksum, so that it isn't implemented in the actual code itself.

The lisp machine could take abstract tokens, rather than text, making the lisp code extremely difficult to understand.

It seems a pretty obvious approach to me, so I'm sure its been done before.  Any obvious pitfalls?

Ged Byrne
Thursday, November 13, 2003

No one will be looking at, or trying to look at the Lisp code, it will always be assembly or even hex dumps.

Unless by Lisp machine you mean a separate piece of hardware, in which case, the cracker just has to look at the comms/network/remote port at a low level instead of the local code.

Dominic Fitzpatrick
Thursday, November 13, 2003

No, By Lisp Machine I just meant a software interpreter that is built into the code.  This means that the algorythm for the Key cannot be found in the assembler.

A Lisp interpreter is very easy to implement, and only requiring just 7 primitive operators [1].  The only thing the hacker could find in the assembly is the parser and these simple primitives.

Everything else would be implemented using the Lisp.  The tokens could be encrypted to add further obsfucation.  The key to decode the tokens could be part of the key provided by the user, so that it isn't left lying around in the binary for the hacker to find.

It seems very obvious, so must be in use already.  Is it obvious enough to patent?


Ged Byrne
Thursday, November 13, 2003

Well, you would also need the lisp code that would do the verification and that would be findable, and as it is interpreted (and the interpreter is actually there), could be executed.

However it is done it is all only security through obscurity, never a good idea and like the MS example above, only stops people who don't want to do it anyway (through honesty or because they dont care enough about what is protected).

Dominic Fitzpatrick
Thursday, November 13, 2003

Decoding the algorithm is a waste of time and probably not used very often for cracks. An easier way is to run a debugger and enter an invalid code to the application, and catch the place where there is either an error message thrown to the user or the application is terminated. Then all that needs to be done is find the jump to that command and change that jump to something harmless, like a comment.

Now regardless of the code, be it invalid or not, the exiting / error message is never reached. Sure, it may need to be tracked a bit further down the execution path to where there is an if... type segment that leads to the terminating path, and invalidate that (because the code entered is either valid or not, so one road leads to not valid and the other leads to yes valid -> find out which one is not valid and change it to be the same as the yes valid one).

This would probably defeat the Lisp approach as well, because there would need to be a similar way to either accept or deny the code. Find that command, change it, and hey presto - program cracked.

Note: I've never done this myself, nor would I know how to technically, but I think this is the road I would go if I ever wanted to become a cracker. The obvious way to fight back at this is to make the application check itself (the executable), and not run if it is modified. No, wait, that can be circumvented using the same method...

Maybe accept both, the wrong and the right code / password, and then check it much much later in the application. Or better yet, in multiple places or at random time intervals. At least it would be damn difficult to find the right place to crack by reverse-engineering the executable.

Antti Kurenniemi
Thursday, November 13, 2003

The Lisp code would be findable, but it would be very difficult to read because

(1) it would consist of abstract tokens, so that the code would be a list of numbers.

(2) It would be encrypted, with the key being necessary to decrypt.

Note that it is not just the code for the key algorythm that is encoded, but the whole library of commands built upon Lisp's 7 primitives.  Without the key to decode the library, the interpreter would be of no use, being just something that can be found in textbooks.

Now for the problem of just patching out of the checking code.

What if the Lips interpreter was used not only for the key validation, but was also used for some critical but non performance dependant functions within the applicaiton. 

The application could not function without the lisp interpreter, and the lisp interpreter would only be available with a valid key.

Ged Byrne
Thursday, November 13, 2003

1. The code doesn't need to be understood, just executed, even assuming it is easier to do this than bypass it totally.

2. Encryption of the library/key/whatever is irrelevant, it is decrypted at some point by your application, which the cracker has full control over.

The only way to maintain proper security is to have some portion of the application that you retain control over, on a server the user/potential cracker does not have access to. Note this cannot just be the security/verification part of your app as this can then still be bypassed.

Dominic Fitzpatrick
Thursday, November 13, 2003


I like your idea of using Lisp for anti-piracy protection. But I think that  the Brainfuck programming language is more suited for this task than Lisp (-8.

Karel Thönissen
Thursday, November 13, 2003

Please enter your activation key: )()((()))()))))()()()()()((())()()()))((()()()()()
Thursday, November 13, 2003


Of course total security is impossible.  However, it is possible to work up your pyramid.

Bottom level is no copy protection.  100% of users can copy your application without bother.

At the top is a well secured server based application with a thin client.  0% of users can copy your applicaiton.

I don't know how to do the exact metrics, but to crack the protection the hacker will need to understand assembly and lisp at the very least.  That must put us into one of the top percentiles.

Ged Byrne
Thursday, November 13, 2003


The more obscure the language used the better.

Perhaps a BF interpreter could be written in Lisp?

Ged Byrne
Thursday, November 13, 2003

Crackers don't always try to decode algorithms, they just figure out where your IsCodeValid() function is and modify it to always return true (e.g.). Then they have tools that do a diff on the unmodified and modified exe and automatically create a small patch.exe to make the change (and that's what people download, not the free reg code).

Thursday, November 13, 2003

The kind of people who try to break programs security have exactly the kinds of skills needed to do so and it is those people who you have to figure you are going up against. So, your application WILL be cracked. People have tried CD based tricks, hardware devices and they all fall due to the cracker having control.

I would dispute that under a lisp based scheme it would be necessary to know lisp. It is just a level of indirection, the cracker has access to the interpreter and the code being interpreted and can watch it being interpreted in memory. They only have to patch the interpreter to always return "correct code" when it is checking the code.

Dominic Fitzpatrick
Thursday, November 13, 2003

There are products which wrap your software in a protective security envelope.

This is not very interesting, as they are easy to crack by experienced crackers.

BUT - these products can also encrypt parts of the code with an encrption key - and the serial you give your users contains that key.



Thursday, November 13, 2003

Brainfuck is simple. Did you know WhiteSpace ?

Thursday, November 13, 2003

*  Recent Topics

*  Fog Creek Home