How to protect application against duplication of a virtual machine

Question

We are using standard items such as Hard Disk and CPU ID to lock our software licenses to physical hardware. How can we reduce the risk of customers installing onto a virtual machine and then cloning the virtual machine, bypassing our licensing?

Ours

As mentionned here under, locking based on hardware makes it a pain in the ass even for paying users. I would rather check somehow that another computer is using the same licence somewhere else on the network (licence indicating also how many users are allowed to use it) and fail quite silentely if licence is overruled : just make your program crash with a not so explicit error message for example. Paying customers will contact you if it ever happens, pirats will just move onto another software... – Tomchay

Answer 1

One approach is to have a licensing server. When you enter a license code into the client (on a VM), it contacts the server and sends it its license code and other information. It contacts it repeatedly (you define the interval -- maybe once every few hours) asking 'Am I still valid"? Along with this request, it sends a unique ID. The server replies 'Yes, you are valid', and sends a new unique ID back to the client. The client sends this unique ID back with its next request to the server. The server verifies this is the same ID it sent to the client for that license, the previous request.

If the VM is duplicated, the next time it asks the server 'Am I valid?', the unique ID will be incorrect either for it, or for the other VM. Both will not continue to work.

You will need to determine what to do if the server goes down, or the network goes down, such that the client cannot communicate with the server. Do you immediately disable your software? Bad idea! Don't make your customers angry. You'll want to give them a grace period. How long should this be? A few days? Weeks?

Let's say you give them a 1-month grace period. In theory, they could clone the parent VM just after entering the license key, then restore the other VMs to this clone just before their grace period runs out, disabling network access to them. This would be a hassle for your customers though, just to have pirated additional copies of your software. You have to determine what kind of grace period won't hassle your legitimate customers, while hopefully giving you the protection you seek.

Additional protection could be achieved by verifying that the VM's clock is set correctly. This would prevent the above approach to pirating.

Another consideration is that a savvy user could write their own licensing server to communicate with the VM instances, and tell them all 'you're good' -- so encrypting the communication could help deter this. How far you want to go here really depends on how much you think pirating really might be an issue with your customers. In the end you won't be able to stop true pirates who have time on their hands, but you can keep honest users honest.

Polled

How to handle a rollback to a snapshot, restoring a backup or a reboot of a docker image? In all this cases the old unique ID should be invalid. – Segarra

Yes, you have to build in administration functions where a user can 'reset' their machine. Resetting it gives both server and client a brand new unique ID and begins the syncing process again. – Polled

May I know where that unique ID will be kept in client. If that unique ID is kept in a file or in memory, that will again be copied to new cloned virtual machine right? – Nodose

@KalyanKumar It doesn't matter if it's copied to a new VM. Whichever client communicates next with the server, that client will become the 'authorized' client, and when the next client tries to communicate, the unique ID will be different, and it will become de-authorized. – Polled

Answer 2

License. Tell your users, they may not run unlicensed copies.

We are actually failing to buy a license for a software at the moment, because the vendor is scared of virtual machines: The infrastructure for our department is being moved to a centralized virtualized sollution and we have to fight the vendor to be allowed to buy a license for his software!

Don't be afraid of paying users.

People too cheep to buy licenses are going to look for another sollution and will be too much hassle anyway.

(good luck telling your boss that, though...)

Fibroblast

I agree, pirates will be pirates - draconian licensing arrangements only hurt real end users. – Taft

Not quite -- good licensing schemes help keeping honest customer honest, as it helps management assess usage and thus pay you appropriately. – Flick

@jake: ditto, license servers allow things like having more work stations that licenses. – Tally

Answer 3

There is no good reason to lock to a physical machine. Last I checked computers can break down, and then the user is probably going to be inconvenienced not only by a dead computer, but by having to call you to get the software locked to a new machine. If you must do draconian license management use a (local) management server and have running copies verify that they have a license every few minutes. Just realize that whatever you do if someone really wants to use your software without paying you they will find a way.

Uball

Answer 4

You need something outside the computer "hardware" to authenticate against. Most companies choose hardware keys (dongles) in for software with a high cost where users will put up with it.

Other companies use online methods - if more than one user with CPUID and other hardware is concurrently using a given license, then disallow another instantiation, or close the existing instantiation.

You have to choose protection according to your needs and the consumer's willingness to jump through your anti-piracy hoops.

-Adam

Horsetail

Presumably if a dongle will work on one virtual machine it will work on multiple. Therefore, unless you intend to ban virtualization (which is a sales-limiting move these days), I don't think dongles will work. – Jada

@david - Dongle devices, especially USB, can't be shared simultaneously by cloned virtual machines, which is what the OP is referring to. – Horsetail

If you can detect duplicate CPUIDs, then there's no reason to prevent two instances with the same CPUID anyway: just count that as two instances and be done with it! – Perdita

Answer 5

There's not a lot you can do AFAIK, except require periodic online activation.

We have problems with people Norton-ghosting physical machines. Apparently HDD serial numbers are ghosted too.

Mamie

Answer 6

If your software runs under a VM, then it will run under any number of cloned VMs. Therefore, the only option seems to prevent it running under a VM at all. Here's an article about virtual machine detection: Detect if your program is running inside a Virtual Machine and one about thwarting it.

By the way, cloning a VM is usually enough of a hassle to deter casual users from bypassing your licensing and those hell bent on cracking will probably find a way to bypass it anyway.

Hobard

Answer 7

"Don't bother" is the short version. It's non trivial enough for your clients to do it that if they are doing that, then either they won't pay for what they use no matter what (they will not use it unless they can get it for free) or you are just flat charging to much (as in you are gouging.)

The "real" customer will generally pay for the stuff. From what I've seen, places like businesses will generally consider it not worth the effort.

Tally

Not true. There are three different kinds of users: a) Those who would never pirate software, either due to ethical considerations, or because it's not worth the bother. b) Those who would pirate if it's easy to do so (i.e. merely clone a snapshotted VM where your software is already licensed). c) Those who have the skills to hack whatever anti-piracy mechanism you want to put into place. It makes sense to put basic protections in place for users in the 'B' category. Don't worry too much about C -- they will always find a way. – Polled

I'm asserting that cloning a VM doesn't constituent "easy to do" regardless of your skill set as running the app then ends up being a pain. Others thresholds for "easy" may differ but I don't think (without evidence) enough will to matter. – Tally

Answer 8

I know some virtual machine software (at least VMware) have features that allow software to detect virtualization. But there is no foolproof way, it's possible to patch such features away anyway. Mysteriously changing performance (due to CPU spikes in the host) could also be used, reliability is questionable. There is a plethora of "signs of being virtualized", but they tend to be not 100% reliable.

Mame

Answer 9

It is a problem, and any savvy user will be able to defeat pretty much anything you do about it. Unsavvy users might get caught by behaviors like VmWare's player that changes MAC and other IDs of the virtual machine when you move it, presumably in a nod to this kind of issue.

The best solution is likely to use a license server instead, since that server will count the number of active licenses. Node locking is easier to defeat, and using a server tends also to push responsibility onto an IT department that is more sensitive to not breaking license agreements compared to individual users who just want to get their job done as quickly as possible.

But in the end, I agree that it all falls back to proper license language and having customers you trust somewhat. If you think that people are making a fool of you in this way, you should not be selling your software to them in the first place...

Flick

I would assume that the MAC changing was for a more practical reason, actually: what do you suppose would happen if two VMs with the same MAC address were connected to the same (virtual) ethernet? – Perdita

Answer 10

If your software was required to under on a VM what about this concept:

• on the host machine you create a compiled program that run eg. every half hour, which reads the Hard Disk and CPU ID, and then stores that together with the current timestamp in a file together with a salted hash of all that information.
• you then require that the folder with the file is shared with the VM.
• in your compiled software within the VM you can then read this file and check that the timestamp is recent and the hash is valid.

Or better yet, have the host program somehow communicate with the software in the VM directly.

Couldn't this be an okay solution? Not as secure as using a hardware key (like Yubikey) but you would have to be quite tech savvy to break it...?

Silverweed