Protecting a high value C# application with only one user

Question

I have a single application -- written in C# -- which is used by only one user. I provide this software for a very high monthly fee (> $10,000). I'd like to protect this application against use by any other user and I'd like to be able to stop the one user from using the application if they stop paying the license fee.

I know that there is no perfect protection scheme, and I've reviewed the many similar questions on SO, but my question is a little different because I have only one client, I have full access to their hardware, and I don't mind taking even a few hours per installation for a substantial increase in security.

Answer 1

Security is a process.

I question the reason why someone would pay 10k per month for an application. Duplication of the functionality of this application would probably not be at that great of cost. So if the entity using it describes it to another programmer could they duplicate it? Probably.

At any rate, if you have access to their hardware and you control their OS user name / password, simply make the password expire every month.

Answer 2

You can bind your app to the box. You can also limit the use to the user by providing him with a login. I do not see though what you can do about your user sharing his credentials and the box with somebody else.

If binding to a box is enough there are techniques to do that - i.e. you can bind it to NIC hardware id.

Answer 3

For 10K/month you could afford to run it on your hardware, which you administer, instead of on their hardware. You could put your hardware in a datacentre, to which they don't have physical access.

---

The hardware must be run on hardware at the customer's site.

So, I guess they're sensitive about where their data is located.

There are many 3rd-party licensing solutions (for example, Infralution, .Net Reactor, Oreans WinLicense, Armadillo, XHEO DeployLX, and presumably many more). If you're interested in Microsoft's own solution, see InishTech here and here.

Answer 4

The only way to truly protect your code and ensure that you can charge for it, is to make a subscription-based web application. Barring that, there's several options that might work:

1. running the app on a server that you control, updating the app so it only runs on that system, and granting them remote desktop access
2. making the program contact a remote subscription and authorization system that you control (although this could be circumvented by reverse engineering the code)

Side note: dang, I need to find a client that'll pay me $10K a month for a software package! LOL.

Answer 5

I am going to assume a Windows platform (i.e. not Mono).

You might want to look at generating and installing a certificate on the machine your software is installed on. This means your software can check that the machine is authorised to run your software, and you can also use the certificate to encrypt and decrypt stuff. IOW you could look to encrypt your assemblies, and then decrypt them before dynamically loading them, or you could use encryption/decryption on any data you provide.

This link may be a good start for you to check this out.

Answer 6

The best solution is probably a combination of popular tactics in use today:

Lock the application down

…to the MAC address, hard drive serial number, and windows product key of the host operating system (if available). You could hard-code this into the application after gathering it at the site. If the wrong hardware is detected then shut it down. Also, look for items in the registry that suggest the presence of VMware or Virtual PC integration features and refuse to run when found.

Obfuscate

…so it will be more difficult to reverse-engineer as well as remove your licensing. CIL is extremely easy to reverse-engineer so this should be a focus with your application (as described) no matter what else you do. This may take a lot of time to get right, especially if you rely on serialization. If possible, wrap all of your assemblies into one EXE file which is encrypted and has an unmanaged bootstrapper.

Send out a heartbeat

…to an offsite server, with hardware or site specific data. If the software is copied and started on another computer you may get a tip. This also has the potential to alert you if the application goes offline. Additionally, you could configure the application to require a basic encrypted response from your server or shut down.

One final note: don’t go overboard. Presumably, you are being paid $10,000 because of the experience of your application over possible alternatives (whatever those are). As you add in protective measures you increase the number of possible (very annoying) bugs, add maintenance cost, and headaches for your customer. A heavily disruptive licensing scheme could make your client think otherwise.

Answer 7

This sounds like a situation where a hardware dongle might be appropriate. Pay somebody to create a hardware dongle (it sounds like you can afford it!) and send one to the customer. Construct your software such that the user has to enter a password to unlock something encrypted on the dongle that your software needs to run.

Authentication is generally based on at least two aspects of the user's situation:

1. Something you are (biometrics)
2. Something you have (dongle)
3. Something you know (password)

If you want to go for all three, combine your hardware dongle with a fingerprint reader.

Answer 8

I have, in the past, used a 'phone home' authentication on application start up, that assures it can only run if your servers give it authentication.

This requires, of course, that you can provide very high availability on your authentication servers, and have a well obfuscated code base, but it works very well.

Answer 9

Take a look at the article Developing for Software Protection and Licensing; it explains how to choose a solution, why you should obfuscate your application and gives a number of tips for structuring your code to be harder to crack.

The gist of the article is that you should be thinking of these things right from the start of development, but it's never to late to address them.

The thing to remember is that once your application is running on another machine, there is no 100% guaranteed way to prevent execution. What you can do, if you're careful, is raise the bar sufficiently high that it's easier to purchase your software than to crack it.

Obligatory disclaimer & plug: the company I co-founded produces the OffByZero Cobalt software licensing solution for .NET.