Partial Key Verification

Question

This question goes out to those of you who have experience with the partial key verification technique for software protection. I'm trying to understand how PKV is better than other keygen schemes, and after reading the much-referenced

http://47hats.com/2007/07/26/implementing-a-partial-serial-number-verification-system/

I have a couple of questions.

Basically, if I understand correctly, the idea behind PKV is that not the entire key is checked on the client side so that if someone (i.e. a hacker) comes up with a keygen, you only have to recompile the software with different checks to the key, and voila, the fake keygen will no longer work.

But what I don't understand is that if there was a keygen at some point, it was obviously able to unlock at lease one of the versions of the software, which can still be found online. So basically, you haven't avoided false keys at all, you just have a version of your software which works with the fake keygen and another which doesn't.

So how exactly is this superior to other keygen protection techniques?

Monocarpic

This question appears to be off-topic because it is about security.stackexchange.com – Sedan

Answer 1

The idea here is this - if we imagine first that your application includes code to validate the whole license key, and someone creates a key-gen, your only real option to re-secure your licencing process for the next version is to change your key generation algorithm entirely so that the key-gen can no longer generate valid keys.

This has one significant disadvantage - legitimate users will need to be issued new licence keys created with the new key algorithm in order to use the updated version. This is likely to be a support nightmare for you and an annoyance for your customers, possibly to the point that they will switch to a competitor's product.

By only validating part of the key in any one version of your product, it should be nearly impossible for an attacker to determine how the entire key is generated by disassembling the binary. As a result, to lock out illegitimately generated keys in the next version, you simply have to start checking different parts of the key that were not checked in the previous version. Since the key generation mechanism hasn't changed, legitimate users' keys still work fine but illegitimate keys (and the key-gens that created them) cease to be effective. Of course, an old key-gen will still work for the old version, but there's not a lot you can do about that.

Of course since your keys are a finite length, there's only so many times you can repeat this process before you're checking the whole key or there's sufficient information from the checks in all the prior versions to reconstruct the entire key generation process, but perhaps it will last long enough for you to be able to reasonably expect users to buy a new license for the next major version of your product where you can change the generation mechanism entirely and start all over again.

Lecialecithin

'' legitimate users will need to be issued new licence keys created with the new key algorithm '' -> that's the part I missed. Thanks a lot dude! – Monocarpic

Great explanation. For @Pickle : unfortunately once the hacker has figured out how to re-create a part of the key, further tests (of the updated version) are much easier for him so while such scheme can make your life to some extent easier, it's really not much easier. New key protection scheme will need to be introduced within months, if not weeks. And remember that once you fight hackers, you will start dealing with carders (those who purchase legitimate licenses with stolen credit cards). – Lousewort