Licensing for LLBLGen
Seth wrote:
This question is for the development team. I am a paying customer so I don't want you to think I am trying to rip you off with this question. I was looking at the licensing file and was wondering how you did the licensing for the software. I want to do a similar thing with software I built using LLBLGen (meaning have a license file for each program I sell). Can you give any pointers as to how you did it? or any API's?? Thanks!
I wrote my own, but that was because at that time (2003) the commercial licensing packages like XHEO licensing were pretty easy to break and also because I found it quite fun to write a licensing scheme which was hard to break.
The first thing you have to learn and live with is that: there will be a day when someone will either break your protection method or will find a way around it. If the protection is tough, they will likely use a stolen credit card. Pirated software is a large industry with a lot of money involved and you can't win from these, no matter how hard to try.
That's not to say you shouldn't make it easy on them of course 
. Though there's one other thing you should know upfront: the protection should never annoy paying customers and should never be a thing you should choose above a feature which could benefit your paying customers. Please read this insightful article:
http://www.ericsink.com/bos/Transparency.html (paragraph 4)
There are 2 types of protection: trial ware protection and purchased licenses protection (terms I cooked up but you get the point ). Trial ware protection deals with different things than the purchased license protection: you have to prevent the user from working around the time trial/# of times the software is started.
I spend most of my time on the time trial part of the protection for the demo. One thing you have to find a solution for is : how do I detect how long the trial is running? So you have to store somewhere a marker when it started. Storing that marker is the weak spot: most crackers simply run a registry/file monitor when they install / first run a trial/demo application. These two applications reveal every regkey created and every file created. You should check if a commercial offering works around this.
The main part of the license we use is a signed XML file. This is a common technique, which is also used by commercial libraries. You create a strong key, with a public and a private key part. You sign the license with the private key part and store the signed xml in a file. You can then check if it's still in tact with simple code for loading signed XML which uses the public key part to check if the license data is indeed not tampered with. You can find examples of working with signed xml files on the net very easily.
There's a weak spot with every protection technique and that's this:
if(CallSuperDuperProtectionMechanism(key))
{
// genuine version, proceed
}
else
{
// invalid license, take action
}
You see the weak spot? I mean, I can go into the IL, and alter the code above in:
if(true)
{
// genuine version, proceed
}
etc.
So you have to protect the IL from tampering with. One easy way to do that in a way is strongly sign the assemblies with your own strong key. A developer then can't tamper with the IL anymore unless he strips off the signature from ALL assemblies in the application, otherwise the assembly can't be loaded again. (stripping off a signature is done quite easily: ildasm to file -> edit IL -> ilasm to dll)
One way to add a layer of protection is obfuscate the application's assemblies. This will make it harder to look for the code to tamper with to hack out the protection, but it's still doable, it just takes a lot of effort and if the effort is too big to go on, people will leave it alone. Obfuscation works best if you make all your .exe classes internal and all public methods of your .exe also internal or private (use a tool like ndepend to check which classes/methods can be internal / private). This doesn't stop stripping out the strong name from the assemblies though, so you have to add checks for that inside your code.
So, you see it will be some work to get it all done correctly and you will in the beginning run into the mistakes I also made perhaps. A commercial license for a licensing library these days isn't that much money and you earn it back quickly as it will take a lot of time to get this right (I spend at least 3 weeks on this, but as said, I found it a fun excersize to do, to come up with the protection, brainstorming about how the cracker should work. ) the commercial libraries have come a long way and are pretty solid these days.
One thing I would do is pack information about the purchaser in the license file. This solves another weak spot: spread of license info. If the purchaser has his/her own name in the license, s/he won't easily spread the license file on the internet as that will reveal immediately who did it. Because the file is signed, you can't tamper with it either
