protecting trial releases in .NET

Question

I want to provide a trial version of my software. This version should only be evaluated within a specific period of time. Let's say only during January 2011.

As this software massively uses the system clock in processing, it would be quite annoying to set the clock to an earlier time to be able to use it over and over. So because of this, I wound't think of a more complicated protection mechanism.

So I have thought about exiting after a test like:

if (DateTime.Now.Year != 2011 && DateTime.Now.Month != 1)
{
    MessageBox.Show("expired!");
    Application.Exit();
}

How easy will this be cracked :-) ?

Is there a "safe" way to do this ?

Answer 1

Basicly you can say it is impossible to secure trial software against cracking. Everything you do in Software can be bypassed (Yes! Even Ring-0 Drivers).

Even if you have an external dongle from which you recieve the authentication to start can be spoofed through software. Although it isn't easy :-)

You can only make it hard not impossible :-)

Answer 2

It's not exactly related to cracking it, but it's worth noting that if this is an app that can be used internationally, it'll show as being 'expired' for many users before they've even had a chance to try it at all. The values returned by DateTime reflect the local users culture, so DateTime.Now.Year returns 1431 for Arabic cultures and 2553 for the Thai culture for instance. Months can similarly differ, so you shouldn't hardcode values for them without checking the culture first.

You can get round this by using the InvariantCulture each time ,e.g. DateTime.Now.Year.ToString(System.Globalization.CultureInfo.InvariantCulture);

Answer 3

This method could be cracked if the user set his computer Date to 2009: your software will be used for other two years.

If you want to use this method I think the best way is to check the actual date on the internet. However some users couldn't have a connection; in that case you can use something like a countdown that makes the software executable for n-days.

• You ship your software with an encrypted file that contains the date of installation;
• The next time you will check for that file:
  • If exists and the day is different increment a counter;
  • If exists but is corrupted or if it doesn't exists update the counter to "max-day";
  • If exists but the counter is equal to "max-day" exit the application;
• Update the old file with the new values;

Obviously the counter will be another encrypted file and, as for the other file, you have to check his state (corruption or deletion).

Answer 4

Here's my opinion. The weak point of any time-limit or dongle-protection is that in the end everything must be checked with an 'if' statement. In the old 'x86 days there is JNE, JE, JNZ family of instructions. Such 'if' statement must exist in hundreds if not thousands or more in the application. So any cracker must find out where to start looking, for instance, dongle checkers almost always use DeviceIoControl API, which could be pinpointed quickly. After the calls to DeviceIoControl API found, the cracker just reverse engineered the routine around the API call, and try change JNE instructions around that to JE or the other way around. In your case, the usage of DateTime is the tell-tale (but of course, there is a lot of place where DateTime being used for other things, that makes it harder for the cracker). To make things difficult for the cracker, copy the current date to some object's values, and try to make, like, 20 places or something that stores the DateTime. Or even better, retrieve current date from the net and also from the current computer. Don't check the DateTime directly, but use the value that you store in some objects before, to make it harder for the cracker. Use consistency check mechanism to ensure the dates are within tolerance, and kill the app if you find out that 2 of the datetime is different to the other stored datetime (give 2 days tolerance or so). Also check whether the clock is not turned back by the user, if you found out that CurrentDateTime < StoredDateTimeInRegistry then you should store a kill flag somewhere in the registry. Or you might also want to use a file in addition to the registry. For every kind checks you do, try to do it in many places and in different ways. At the end, I must say that what Bigbohne said is true (nothing is impossible to crack) - it is just that, by making it difficult for the cracker, we changed his/her effort-to-result ratio, and hopefully discouraging him from continuing the cracking process.

Answer 5

Checking trial period expiration in C# code is easy to crack, even if you will obfuscate code due to it is compiled into CLR. It is better carry out this check into code that is compiled to byte code. Also you can read topic Protect .NET code from reverse engineering? about protecting .NET code from reverse engineering

Answer 6

Software licensing is a complete subject on its own, and it looks like that you are looking for a simplest solution to be implemented for your trial software.

What simply you can do, on startup of your application log the current date/time in registry and use it is as a reference point for validation. So even if the system time would be changed it wouldn't effect your application validation logic.

If possible, write the registry access library in C++, which wouldn't be possible to crack. Good luck.