Back in 2007, I wrote an article showing one way of protecting an application with a licensing system. Still today, this article generates traffic and questions.

I made an error when I wrote that article. I have built both the protected client application and the key generation application into the same UI. It was really hard to figure out how to implement in your own solutions.

This time, I will really split the 2 applications in 2 distinct applications (each reusing a set of classes in a class library project).

Demo code

This month downloadable demo code is provided in both VB and C#. The solution was built using Visual Studio 2015 but you can reuse the code in older versions as nothing fancy is used here.

Because there is a bit too much code, no code is shown in this paper. Download the solution and test it following the steps explained here.

The structure of the solution

When you will open the solution, you will find 6 projects. 3 are in VB, 3 are in C#.

The project named DemoLicensingXX is a class library containing classes shared by both the test client project (DemoWPFLicensingXX) and the key generation project (DemoWPFLicensingXX-KeyGenerator).

Figure 1: the solution

How it works

Let’s starts by explaining the regular flow.

You will have your application deployed to your users (DemoWPFLicensingXX). The first time they will launch the application, it will detect that nothing is in the registry (which store encrypted values to determine if the application is licensed or not).

Figure 2: launching the test application for the first time

You can simulate what will happen by changing the date from the date picker control.

Figure 3: advancing the trial period

Figure 4: changing the date to simulate an expired trial.

So that means that you can use that state to enabled and disabled various controls in your application.

Now if your user wants to continue using your application, he will need to contact you to get a key.

This is where you will use the second application (DemoWPFLicensingXX-KeyGenerator).

Figure 5: Generating a key for your user

Using the 16 first characters of the client name you provide this application and a pass phrase (which is a constant used for encryption that you need to replace with yours), a key will be generated. You need to provide this key to your user.

Now that your user received his key, he needs to go back to your application in which you need to provide a way of entering this key.

The user needs to provide exactly the same client name (but not case sensitive) as the one you used to generate the key. If you enter the incorrect information, the application is not licensed.

Figure 6: Entering incorrect registration information

But when the user enters valid information, the application is marked as valid.

Figure 7: entering valid information

Now if the application is closed and re-opened, you will find that the application detects that it is fully licensed.

Figure 8: A fully licensed application

Where is the key stored?

You might wander where this information is stored? I decided to save it in the registry. All the values are encrypted so the user cannot really see and alter the values. It is encrypted using the famous pass phrase constant (limited to 16 characters) defined in the class library. Both the key generator and the client application needs the same key.

As you can see in figure 8, the values are stored in HKCU\Software. The keys YourCompany\YourApplication are just another constant declared in the class library that you need to adjust to your own values.

Figure 9: Values are stored in the registry

I hear you screaming that anybody finding this key will be able to copy it to another computer and be able to reuse the very same key on any computer. This is not true. In my demo, I am storing the Win32_BaseBoard (the mother board ID) into the CompID key in the registry. When validating if the license is valid, this value is compared to the current one and returns a message saying that the key is not valid on this computer.

Deleting the key

In the current state of the code, if you delete this key from the registry, will restart the trial period. That might be an interesting feature in your application to reset the trial period.

If you absolutely do not want this behavior, you will need to find another mechanism (like storing a hidden file in an obscure folder where the user can write) to store another value but even that is breakable. The harder your mechanism is, the more support you will need to provide.

Conclusion

So I hope that this newer version will help you over the black magic of the first version.

This code is really yours to fit to your needs. I think it is a good basis to protect your application.