Protecting and Licensing a Windows Service or Server Application

During our regular CodeMeter customer support meetings, I find that we frequently discuss customer questions regarding protection and licensing for a Windows Service or Server application. In most cases, the issue at hand boils down to two major requirements when protecting a Windows service or a server application that differ greatly from the protection of most desktop applications:

1. The service or server application is generally not able to show graphical error messages (to display licensing and protection errors).
2. In most use cases, the service or application should keep running, even if the license is not available.

While these requirements may seem challenging, they don’t have to be, especially with CodeMeter Protection Suite, which offers easy-to-implement and strong protection mechanisms against reverse engineering. CodeMeter offers three approaches to address these requirements.

1.1 Use of the CodeMeter Protection Suite IP Protection with UserMessage Interface

AxProtector is the ideal solution to save time and effort when it comes to integrating protection into your Windows Service or Server software. With AxProtector, you can protect your software against piracy and reverse engineering in a fully automated fashion.

In case of a licensing error, i.e. “license has expired”, the protected application shows an error message. Usually this error message is a Messagebox. With the UserMessage Interface, the error handling can be implemented in a separate library (.dll, .so or jar). Instead of showing the error message, this library is called. The library handles the error notification and delivers a return code back to the protected application. The possible return codes depend on the specific error type. This method allows you to decide whether an unlicensed application can “try again” or whether to “terminate application” without having a visible alert to prevent execution of the protected Service or Server Application.

With this option, the ISVs can implement their own error notification system, depending on their requirements. They can write a library that writes error messages to the Windows system log and terminates the service if the license is not available. To implement this, see the UserMessage documentation. UserMessage is available for AxProtector, AxProtector .NET, and AxProtector Java.

This approach handles requirement (1), but not requirement (2).

1.2 Use of CodeMeter Core API

The ISV implements licensing with the use of CodeMeter Core API. In this case the ISVs can catch the error message themselves, when an error occurs. In this case, the ISV decides how the service continues. The functionality can be reduced or the service can be terminated.

CodeMeter Core API offers licensing, but only limited protection. That’s why it can be combined with CodeMeter Protection Suite IP Protection. The entire application is encrypted with AxProtector, AxProtector .NET or AxProtector Java. But the decryption at the start of the application doesn’t need a license. The application starts anyway, even if no license is available. An error occurs only if the application is being debugged.

This approach handles both requirements. Due to the separation of licensing and protection, the protection is weaker in this approach.

1.3 Use of IxProtector

IxProtector, which is integrated into AxProtector, is also an option. It’s available for AxProtector, AxProtector .NET, and AxProtector Java. It allows the selective encryption of functions within an executable or library. The ISV defines which functions/methods should be available with and without a license. The application runs as a basic framework, even if no license is available. If a protected function should be executed, the ISV checks the availability of the license with the WUPI-API, before calling the decryption of the function. If the license is not available, the ISV decides how the application should handle this error.

This approach handles both requirements. It meets the definition of encrypted and unencrypted functions and the implementation of the WUPI-API. While this approach offers the highest level of protection, it is more time consuming to implement.

1.4 Additional options

There are two additional options available.

1. Case (1.3) can be combined with Case (1.2). The basic framework functions are encrypted without a license and can be executed without a valid license. The important functions/methods are encrypted using IxProtector.
2. It is possible to split the application into an executable and separate libraries. The executable includes the framework functionality and is either not protected at all or uses CodeMeter Core API (1.2). The libraries are protected with AxProtector or AxProtector .NET. In this case, the library needs to be loaded dynamically. The library needs to use the UserMessage Interface (1.1) and the executable needs to handle the error if a library cannot be loaded.

Hopefully, these simple instructions to alternative approaches to protecting and licensing Windows Service or Server applications can help diffuse any issues. And, as always, our professional services team is at the ready to answer any additional questions.