Encrypt file on client side

Question

I am going to create an application which will run in the client's computer. The program will allow the client to use the software N times, and then for the client to be able to use the software again he/she will need to buy an X amount of times to use the software. It would be like buying a license or token (i don't know if they're the same or not, since my english isn't that good).

I was thinking about creating a .lic or .txt or anything else, which would be encrypted, and when updated with the new .lic or .txt, etc, it would change the number fo times the client would be able to use the software.

The thing is that I don't think that method is very reliable, since, even if encrypted, the client somehow could be able to crack and understand this file.

Could anybody help me in figurnig out a solution for this?

PS: The software can't be validated via internet, the client must be able to use the software offline, if it wasn't I'd validate the software's usage via internet and wouldn't be having this problem.

Answer 1

First I must agree with the commentary that simply says, this will not be secure. Even though they are correct, it will be easy for a developer to work around, there still may be a valid need/desire to prevent the other 99% of the population. This is the same battle that DRM faces, there are always those 1%'ers that are willing to put in the time to decipher what you're doing and work around it. But let's move on to how you would achieve this...

Step 1 - You need a 'counter' to know how many times your application has been run. This, unfortunately, will only be obfuscated from the user since your application must be able to read this value. Often this obfuscation is achieved by hiding values in several places both in the registry and file system. Occasionally you will find this information is 'encrypted' (actually it's obfuscated by an encryption algorithm) using information available on host, the bios, cpu type, hdd id, etc.

Ultimately this storage and obfuscation of the execution counter is your 'secret sauce', and the only thing that makes it difficult to reverse is by keeping what you are doing a closely guarded secret (as most forms of obfuscation rely on secrecy). Due to this there is not really a value I could provide in offering you a solution, once posted here it's no longer a secret :)

Step 2 - Once you've got this counter working you will need to provide a 'license' to the user. This is actually the easy part and where PKI cryptography can serve you well. What you want is a private key only you control, while your client software has the public key hard-coded somewhere. Then you use you're private key to 'digitally sign' a license file for a client. When your client loads the license file it verifies the signature to ensure that this license file was signed by the related private key, which in theory since only you have access to this key, means that you authorized this license.

Step 3 - Now you need to provide a way to verify that this counter has not exceeded the licensed number of uses. This should be straight forward.

Problems and Solutions

1. The most obvious attack on such a solution will be reverse engineering the code. You will need to address this with a .NET obfuscation library or by writing unmanaged code.

2. The next most likely attack is using a debugger to skip past this verification. There are lots of anti-debugging articles out there. The most complete I've found is titled "An Anti-Reverse Engineering Guide".

3. Another attack that should be considered is modification of you're executable. Sign you're executable and verify it's signature just as you will for the license to prevent the code from being directly edited.

4. Your storage of the execution counter will be an obvious target, make sure you store it in multiple places and if any of them have been tampered with you can take an appropriate action.

Lastly, All of this will be insufficient to prevent a determined individual from successfully defeating you're licensing strategy. Accept that now and implement only as much as you feel is required based on both the level of computer competency of your average user and the amount of lost revenue versus the cost of implementation. In other words say you implement something really silly and basic and expect that 20% of your users could figure it out. Based on your clients you believe that of that 20% of your users less than a quarter of those would actually circumvent you're DRM rather than paying for the license. So you expect to loose out on 5% of your possible revenue, say you make 1 million a year, that mean you loose 50k in revenue. Now ask yourself if I spend X dollars of my time making this harder for someone to circumvent, at what point does it become a negative return? Certainly at an expected loss of 50k you wouldn't want to spend a year working on DRM.

Honestly speaking I think most applications that employ a DRM could do with a great deal less effort. If you're application is priced right people will pay for it. For the people that will circumvent your DRM, they probably wouldn't buy your application anyway so you haven't really lost anything. If I where you I'd set aside a fixed amount of time to spend on this problem, (a week?) and do only what you can within that time limit.