I have always been curious about copy protection and how CD Keys work. Specifically how keys are generated, verified and broken. After thinking for a few moments I had an idea of how things may work: Lets say we have a series of polynomial functions f_0(x) = y_0, f_1(x) = y_1 ... f_n(x) = y_n etc. The idea is that we choose a system of equations with infinite solutions. This means we can use the solutions to the system as keys that when subbed back in to the equations produce the vector on the right side of our equation Ax=b. Is there anything wrong with this system? How could it be broken. More importantly, do you guys have any knowledge of how things are really done?

Well I'm not sure I understand your method, but I think if you've seen two keys, and you know how the figures are broken up... any key "between" the two keys will also be a key for the system. If you have several keys, you can figure out the valid range for each element of the key. I think the weakness in such a system is that the equations aren't coupled so one can make new keys from existing keys in the way I described. You need a system that is coupled in a non linear way... this means that having two keys does not allow you to calculate any more. I guess what you really want is something more along the lines of a cryptographic system. A scheme whereby you have a private key that is the programs key... and a set of public keys. The private key can be transformed into any number of public keys (which are valid keys for the system)... but the public keys cannot be transformed into one another... one requires the private key to create new public keys. I'm not sure if this is write or not as cryptography is not really my thing. As to your method... if I've misunderstood it and am wrong about it... please post some slightly more detailed info (maybe with code/pseudo code? or more maths) about it.
Thanks,

Dan

I'm no expert, but how about some hashing maybe?

Quote:Is there anything wrong with this system? How could it be broken.

CD-keys are broken without touching the keys.

The code will always boil down to something like this:


So the hack boils down to removing the call to isValid.

The other solution is to interleave your keys into application itself. For example, a function f( key ), which equals 1 for valid key, and non-1 for invalid keys. Then, you add this code to all array accesses a[ index * f(key) ]. If user enters invalid key, the application crashes.

This is very bad, since crashing applications, legal or pirated, are bad.

So the real problem doesn't come down to keys, but finding a way to insert reliable transparent tests through as much of your code as possible, without destroying performance, sacrificing reliability, or increasing development time.


CD-keys, by themself, tend to be trivial. They are just encoded meta information (region, version, product code), with several checksums performed and appended on the data, then encoded with alphanumeric alphabet.

They aren't designed to be unbreakable (not for software, pre-paid cards are different topic).

When breaking applications that use keys to authenticate you simply run a debugger until you find the code that validates the checksum. When you do, you either reverse engineer it, or simply copy the assembly, and presto - a key generator.

Most of the keys (for the above stated reasons) aren't cryptographically strong, they are just a slightly transformed number.

As with many problems - solve the simplest problem. In this case - not breaking the key is simpler than doing so.