As a part of working in a Licensing component codebase, I’m checking commercial components to see how they implement licensing and the result, as you guess, is that mostly in-house (read dumb) lousy solutions are used for licensing and trial versioning. So if you see the key-gen for your application spread on the internet a couple of days after releasing a new version, maybe this post is meant for you.

If you’ve been a .NET developer for long enough, you probably know that your high level .NET Language (C# / VB.NET, etc.) is converted to Common Intermediate Language (CIL). That is true for all languages converting to Intermediate Language so the discussion here is not limited to .NET, nor it is a weakness of .NET languages per se.

So what’s the big deal? The problem is that your assembly, can be converted BACK to IL, modified and saved, so malicious crackers can remove your copy protection pretty easily, so you need to take extra precautions to make it harder for cracker to do that.

You may think changing the IL code needs extensive amount of IL knowledge, but that is not true. To have better idea what to do, you need to put yourself in the cracker’s shoe. Let’s see a real world component and see how it can easily be cracked (I’ve removed/changed the names/namespaces to protect the innocent).

Disclaimer: This is to show software vendors and providers how to protected (or not protect) their intellectual property. Author is not responsible or liable for any misuse of the information provided here.

Chances are, when a cracker wants to remove the copy protection, he opens your assembly in Reflector to find out how the internals are working.

Namespaces

As you can see, this is the worst case scenario because the cracker can isolate the protection mechanism instantly just by looking at namespaces! It helps to put that code somewhere that is not so obvious, or even better, spread the protection code to a couple of places! Upon further investivation, he will find out that a simple Date object is used to track compilation date of the assembly and make it stop working after a predefined days are passed:

1
2
3
4
5
6
7
internal static class TrialSystem
{
public static DateTime CompilationDate
{
get { return new DateTime(2011, 1, 1); }
}
}

The easiest crack would be to change the CompilationDate to return DateTime.Now every time accessed, so the application would never expire! But how would you do that? Supposing the cracker has limited knowledge of IL, he fires up the VisualStudio, writes the replacing code in C# / VB.NET and opens the output assembly in Reflector in IL language!

IL

All needed is to replace this code with the one inside the assembly. Believe it or not, the tools needed are accompanied in .NET SDK! Open the VisualStudio 2010 Command Prompt and type the following on the same folder the assembly resides in:

1
ILDASM /OUT=SourceCode.il TheAssemblyName.dll

This dumps the IL code into SourceCode.il file and places the rest of the resources at the same folder so later all these files can be stitched back together. Cracker can now open the IL file in any text editor, replace old IL code with the one shown above and save the IL code back to disk. Now time to convert the IL back to regular assembly. The following command creates a .NET Assembly from the IL code:

1
ILASM /DLL SourceCode.il /OUT=NewAssembly.dll

Now he can use the new assembly without any limitation. If you think signing the assembly will prevent crackers, you’re completely wrong. It may make it a little bit more laborious but the assembly is still vulnerable.

In next post, I’ll show you some techniques to make this process a little harder for crackers, but remember, as a general rule of thumb if your application is worth more than couple of hundred dollars or has more than hundred users, chances are it WILL get cracked at some point.