Serial number (registration key) algorithm in .NET

问题:

There have been a few timely posts about IP security and the like, but none that I can find that specifically address an algorithm. In one of my current projects, we've decided to go the route of an offline registration key system.

I imagine most of our eventual user base will be honest, so I don't think we have too much to worry about. On the other hand, I'd rather not have the casual cracker gain access without a good deal of sweat and tears.

So, what are some options for how to generate (and verify) the key? Hardware keying is most likely out because the install model is to run from a samba share on an intranet server. Also, how long should the key be?

Secondly, how big is the danger of the verification algorithm simply being Reflected out, even if it is obfuscated? Would it be better to write the algorithm in unmanaged code instead?

回答1:

In my opinion, the key problem you'll face is not with your registration algorithm and level (or lack) of obfuscation.

Rather, it's this: At some point in your code it comes down to simple binary decision - to run, or to exit. Hacking your system only requires finding and tweaking this decision point.

Everything else - obfuscation, strong signing, tamper detection - is oriented to make this more difficult, but it can't make it that much harder.

回答2:

Typically what you want to do is pick some data that you want to include in the key like who owns it and when it expires, possibly even some small pieces of code your application needs to work properly (thus making it hard to make it work without the key). Then use a digital signature scheme like RSA to digitally sign the key with your company's private key. Distribute the public key with the application executable. Then when you load the key, just verify the signature is valid and then use the data contained in the key. A 1024 or 2048 bit key should be plenty for this.

Of course no matter how sophisticated your code is someone will always be able to break it or get around it. So the question you have to ask yourself is how difficult do you want to make it (keeping in mind more difficult schemes are harder to code and maintain for you)? There is a point of diminishing returns, usually that is pretty low. As long as the program won't work without a key, and the key is complicated enough that you can't fake one (or change the expiration date etc) with a hex editor then you are probably fine.

回答3:

As far as refactoring the key out, writting it in unmanaged might not help if they kill the call site from managed to unmanaged. One option you have with obfuscation if your using Dotfuscator professional is to enable their "Tamper Detection" essentially they tag your assembly and if someone modifies you can have your code do various things. Of course the hacker can remove this but its a lot more sweat and tears.

回答4:

I've only found one way to lock down code very well. Almost every form of serial validation can be cracked easily by your average second-year programmer.

The way I've done it is to use a License object in .NET. Within my home-grown license object, it reads a "license" file to find out where "home" is. That license is an encrypted string. The private key to the string is in the License object.

The License object then calls home with a secret password, also encrypted. The server decrypts the password and validates it... also logging the IP and user name in case of fraud investigation. If the server can validate the password, it responds with a secret response, encrypted again so that it cannot be spoofed. If it cannot be validated, the connection is dropped. No response is sent, thus the License object at the other end fails.

When the integrated License object fails, it will automatically throw an exception, forcing the application to fail and exit at the point that the license is called.

It took me about two work-days to write the server and the License object, so it's a bit of a workout, but not rocket science.

If you want some sample source, or more info, let me know. I'll be glad to get you what I can.

回答5:

You might want to take a look at the answers to this question