A good example of a Virtual Machine (VM) guest environment is where the Windows operating system is running in an isolated environment in OS X (using software like VMWare Fusion or Parallels). Although copy protection is designed to prevent copying a license from one machine to another, its effectiveness is often limited when the license machine happens to be a virtual machine. This is due to the fact that the virtual hardware (and the device drivers for that hardware) does not change after copying the virtual machine from one host computer to another.
The way your application should react to a virtual machine guest environment will largely depend on the nature of your application and the systems on which it is run. For example, if your application is a typical desktop GUI application that should be activated once on each licensed computer, then you might opt to prevent your application from running in this type of environment. However, if your application needs to run in large office environments where employees use virtualized desktop environments, or if your application provides some kind of service (especially one which requires high-availability, such as a web application or web service), you may need to allow the application to run in these types of environments. If your application falls into the latter category, then you should take further consideration into the types of system identifiers used by your application.
PLUSNative makes it very easy to detect virtual machine guest environments via the SK_SystemVirtualMachineDetect function. The code below provides an example of how this can be used in your protected application(s).
Note that the example above assumes the API context has already been declared and initialized.
As mentioned in the introduction of this topic, copy protection is limited in how well it can prevent a protected application from running in a copied virtual machine guest environment. If you need license virtual machine guest environments regardless of the limitations, there are some reasonable measures you can take to help prevent this sort of thing from happening, which is what is explained here.
PLUSNative includes a number of system identifier algorithms that can help you better identify both physical machines and virtual machine guests. This section will explain what algorithms are most effective for virtual machine guest environments, and the behavior you can expect from each of the algorithms.
The identifiers generated with SK_SystemIdentifierAlgorithm.SK_SYSTEM_IDENTIFIER_ALGORITHM_HARD_DISK_VOLUME_SERIAL use data that is generated when a partition is formatted. Since this is usually done when installing the operating system, this value is usually different between different virtual machine guests. However, as with physical machines, use of system imaging software (such as Backup Exec System Recovery) can duplicate an operating system installation, including the volume's serial number. With this limitation in mind, this algorithm is best used when accompanied by another algorithm.
The MAC (or physical) address of Network Interface Cards (NICs), which may be identified with SK_SystemIdentifierAlgorithm.SK_SYSTEM_IDENTIFIER_ALGORITHM_NIC, is also useful for identifying both physical machines and virtual machine guests. This is because two machines cannot have connectivity on the same network when they share the same MAC address. While this may be useful, it should be noted that most hypervisors allow you to configure the virtual machine guests to use Network Address Translation (NAT), which essentially hides the virtual machine guest behind a separate network. In other words, two virtual machines sharing the same MAC address with bridged connections will not work on the same network, but they may work on separate hosts when using NAT.