What is the best way to write a C# application "kill switch"?

Question

I need to write a "kill switch" into my C# application for licensing/billing purposes. What is the best way to do that?

The requirements are as follows (its actually 2 kill switches):

1 - "passive kill switch" - If a particular user does not log into the application in X days then the application stops working.

2 - "active kill switch" - A user can log in and set a date in the future when the application will stop working.

I can think of various ways to do this with a database but users might be able to bypass that. Is there a way I can use an encrypted database or something of the sort? Or maybe a secured file that can contain this data?

Answer 1

No matter what you come up with, there will be a way to crack it. How much time and effort are you going to spend fighting your users instead of writing features that they would want? Just storing the time in plain text in the registry will be enough to prevent most ordinary users from messing with it. If advanced users want to pirate your program they will no matter what you do. I'd say don't waste your time trying to prevent this and give them something that would make them want to pay for your product instead.

Answer 2

It will always be possible for a sufficiently talented user to defeat your "kill switch" functionality.

The best you can hope for is to generate a public/private key pair, and embed the public key in your application. Then make it periodically "phone home" to a server that has the private key, which will respond with an authenticated message as to whether the application needs to shut down or not.

However, a malicious user can still modify your executable directly to disable the "phone home" routine (always making it return true, for example). As long as the end user has an executable on his/her own computer, there is no way to prevent this.

Answer 3

If humans made it, humans can break it, that's the inevitable truth. But if you want to put something that will slow down the average user, here is what I would do.

Create a script with basic windows authentication, and then a second set of authentication that is programmatic. The basic windows auth never changes, but the authentication on the page does. (Create an account for each person). Make that page return some XML with a random string in it.

On your desktop application, during startup send a request with:

the windows auth info 
the random string

And, if the user is current, they will authenticate, get the random string from the server, match it with the randomized string from the app (use an algorithm to generate it) and if they match, let the app work. If they don't match, post some sort of notification.

This way, when you need to kill switch an application, you simply delete or disable their account. Then they can't log in, or match the string.

Of course this could be defeated too by a hex editor or clever internal webserver, but if they're that smart, and that determined they will get the application no matter what.

Hope this helps.

Answer 4

1 - "passive kill switch" - If a particular user does not log into the application in X days then the application stops working.

2 - "active kill switch" - A user can log in and set a date in the future when the application will stop working.

To implement either of these, you will need to reliably store state information for your application. Your options for where it's possible to store state are straightforward: in the filesystem, in a database (SQL Server, Access, Active Directory, etc), in the registry, or in some remote store.

For the filesystem option, you can store it directly as a file, or as an NTFS stream attached to a file. Streams are nice because they don't appear in a simple DIR list, and because they will follow the associated file if it's copied somewhere. For example, you might put the data in "file.exe:key".

The most secure approach is probably to use multiple locations, and to check for discrepancies as part of your validation process. You can use encryption to prevent one user being able to copy the validation data from one machine to another -- perhaps by creating a key that includes the local machine's MAC address.

You might also consider using the DPAPI to store any encryption keys you use; that keeps them more secure than just using a file in the filesystem.

Answer 5

You could always try DotFuscator that ships with Visual Studio, personally I've never got round to trying it myself but in terms of security it might work.

Hope I'm on the same lines as you anyway.

http://www.preemptive.com/products/dotfuscator/overview