Protection Options

Set options for the shell protection. You can enable features including code protection, Terminal Services restriction, Remote Key Update Broadcast, Network Key, and UpdateShield.

Main

Protection Method

Select the method you want to protect your program.

 

The following protection methods are provided for Win16, Win32, Win64, and .NET applications:

 

·         Injection-1. The Injection-1 method encrypts the code section of the executable. It then injects the shell protection code into the header and stub of the executable, which functions to detect the Key and decrypt the code section at run time.

This method has an advantage that the protected program remains as a single executable. However, it may not be compatible with some types of the executable due to limitations preventing modification to the header and stub of the executable.  

·         Injection-2. The Injection-2 method uses the same approach as Injection-1. It encrypts the code section of the executable, but uses different techniques to inject the shell protection code into the header and stub of the executable. If it appears that the Injection-1 method does not work with your program, it is recommended to try to use the Injection-2 method.

·         EXE Scramble. The EXE Scramble method scrambles and encrypts the executable. It then creates a separate loader that functions to detect the Key and decrypt the executable at run time. When using this method, ElecKey Integrator will create the protected program that consists of two executables: the loader (e.g. Program.exe) and the encrypted executable (e.g. Program_PKS.exe). Both files must be included together when deploying the protected program.

Since the EXE Scramble method does not modify the header and stub of the executable, it is compatible with more types of the executable. For this same reason, this method is also less likely to get a false positive detection by some anti-virus software. If it appears that the Injection methods do not work with your program, it is recommended to use the EXE Scramble method.

note NOTE: The shell protection supports a wide range of the most common executable file types for 32/64-bit Windows applications. However, due to limitations of the executable, the shell protection might not support your application. For a guideline to adjust the protection settings and determine if the shell protection can support your application, see Appendix: Shell Protection Limitation.

 

·         .NET Encryption. The .NET Encryption method encrypts the whole managed assembly. It then creates a native executable that is composed of the encrypted assembly and the loader, which functions to detect the Key and decrypt the assembly at run time. When using this method, ElecKey Integrator will create the protected program that consists of the following executables.

·         Program.exe is a 32-bit executable that serves as the main program for Program32.exe and Program64.exe. When started, it determines whether its process is running on 32-bit Windows or WOW64 (Windows-on-Windows 64-bit) emulator, and then executes the corresponding version of the encrypted assembly.

·         Program32.exe is a 32-bit executable that is composed of the Win32 loader and the encrypted assembly.

·         Program64.exe is a 64-bit executable that is composed of the Win64 loader and the encrypted assembly.

It is recommended that you include the above three files together when deploying the protected program. So, when starting Program.exe, the program can run on both 32-bit and 64-bit platforms. However, it is also possible if you want to deploy Program32.exe or Program64.exe individually.

note NOTE: The .NET Encryption method has a limitation that may cause a conflict with some .NET class/object and give run time exception. For more details and resolution, see Appendix: .NET Encryption Limitation.

 

The following protection methods are provided for DOS applications:

 

·         DOS-COM. The DOS-COM method encrypts the code section of the executable. It then injects the shell protection code into the header and stub of the executable, which functions to detect the Key and decrypt the code section at run time. This method is designed for the DOS COM executable, which the size does not exceed the limit of 640 Kbytes.

·         DOS-EXE. The DOS-EXE method uses the same technique as DOS-COM, but designed for the DOS EXE and overlaid DOS EXE executable.   

Code Protection

The following code protection options are enabled by default to protect your program against tampering and reverse engineering. However, due to limitations of the executable, in some cases, you may need to disable some of the options so that the shell protection can wrap over your program.

 

Below are the code protection options for Win32/64 applications:

 

·         Enable Shell Protection Optimization. The shell protection uses the technique to wrap the executable that is more friendly to anti-virus software. This helps to avoid the issue that the protected executable may get a false positive detection by some anti-virus software. However, some executable cannot be optimized. Disabling this option will allow you to protect more types of the executable. 

·         Enable Code Section Encryption to Protect Against Decompilation. The shell protection encrypts the code section of the executable to safeguard against decompilation. To thwart access to the code, the shell protection only decrypts the needed code just before the run time in memory. After execution, the code is immediately returned to its encrypted state.

·         Enable Self Checksum to Protect Against Code Modification. The shell protection always performs integrity check of the executable, including the ElecKey system files, to protect against tampering, modification, and virus infection. If a checksum is found invalid, the shell protection immediately terminates the executable. However, if you plan to code sign your program, you will need to disable this option to avoid conflict. 

·         Enable Code Section Encryption on Loader. The shell protection uses the injection technique to encrypt the code section of the loader when using the EXE Scramble and .NET Encryption methods. This can help to enhance the security. However, it is possible that some anti-virus software might detect the code injection as a false positive. To avoid the issue, you can disable this option, which will make the protected application more friendly to anti-virus software.

 

Below is the code protection option for DOS applications:

 

·         Enable Overlay Encryption to Protect Against Decompilation. The shell protection encrypts the code section of the executable to safeguard against decompilation. To thwart access to the code, the shell protection only decrypts the needed code just before the run time in memory. After execution, the code is immediately returned to its encrypted state.

Stand-Alone/Local

Key Location

Select the location to which the protected program detects the Key.

Terminal Server Restriction

Set restriction for the protected program running in a Windows Terminal Server environment (for Win32/Win64/.NET applications).

 

·         Restrict Session. The protected program allows only one Terminal Server session.

·         Block Session. The protected program does not allow any Terminal Server session.

Detect Key in Background Process

Enable the protected program to detect the Key in background process (for Win32/Win64/.NET applications).

 

·         Interval. Specify the time interval (in seconds) to which the protected program detects the Key. The time interval ranges from 20 to 4,294,967 seconds.

Enable RKUB (Remote Key Update Broadcast)

Enable the RKUB or Remote Key Update Broadcast operation.

 

·         RKU File. Specify the file name to which the protected program accesses for updating the Key.

Network

Protected Program Site

·         Configuration File. Specify the network configuration file to which the protected program uses to connect to NetKey License Server.

NetKey License Server Site

·         Location. Select the location to which the server detects the Key.

·         Interval. Specify the time interval (in seconds) to which the protected program sends commands to the server to detect the Network Key. The server always detects the Network Key in background process. The time interval ranges from 20 to 4,294,967 seconds.

Enable RKUB (Remote Key Update Broadcast)

Enable the RKUB or Remote Key Update Broadcast operation.

 

·         RKU File. Specify the file name to which the server accesses for updating the Key.

Terminal Server Restriction

Set restriction for the protected program running in a Windows Terminal Server environment (for Win32/Win64/.NET applications).

 

·         Restrict Number of Sessions. The protected program connects to the NetKey License Server before creating a Terminal Server session. The Key on NetKey License Server determines the number of the sessions allowed.

·         Block Session. The protected program does not allow any Terminal Server session.

UpdateShield

Enable Automatic Software Update

Enable the protected program to interface with its Updater that automatically checks for updates on the server.

Auto-Update Conditions

Specify the condition to perform automatic update.

 

·         Always perform auto-update. The protected application always performs automatic update regardless of its license status.

·         Perform auto-update if the application is registered. The protected application performs automatic update only if it is registered or licensed.

·         Perform auto-update if the subscription is valid. Before performing automatic update, the protected application connects to the Activation Server to check its subscription status. It performs automatic update if the subscription is valid.

Options

·         Terminate the application before executing the downloaded update. The Updater terminates the protected application before executing the downloaded update.

Enable Automatic License Update/Validation

Enable the protected application to automatically update and validate the license via the Activation Server. Within one second after the application is started, it attempts to connect to the Activation Server in background process. When connected, it performs the following operations. 

 

·         License Update. A license update is performed when a product upgrade is applied to the user account on the Activation Server. Specifically, you can log on to Activation Manager, under the Control page, choose an upgrade from the drop-down list and click the Upgrade Product button. The server will return a new License Key to update the license. For more details, see the topic Activation Server: Activation Manager/Accounts page.

·         License Validation. The validation checks against the user account on the Activation Server. If a user account becomes invalid (e.g. fraudulent), you can log on to Activation Manager, under the Accounts page, enable the Destroyed checkbox on the user account. As a result, the server will return a command to destroy the license. For more details, see the topic Activation Server: Activation Manager/Accounts page.

·         Genuine Validation. The genuine validation provides extra security to protect the application against piracy. It determines and ensures that the license must be activated properly via the Activation Server only. If the application is activated offline by a key generator (e.g. cracker or even LicenseKey Manager), the license will not pass the genuine validation. You can set an action to respond.

note NOTE: Genuine license validation is the feature implemented on the Activation Server. If the license is activated using License Key via the LicenseKey Manager tool or the LicenseGen SDK, the application will not pass the genuine validation.
Web Service URL

Specify the Web Service URL of the Activation Server.

 

note NOTE: If you customize the Activation Server and change the Web Service Namespace, you can add the ns=<WebServiceNamespace> parameter with your Namespace to the Web Service URL, e.g.

http://myserver.web/service.asmx?ns=http://myserver.web/

 

Server connection is required at least once every xxx day(s)

Enable and specify the time interval that the protected application must connect to the Activation Server to update and validate the license.

Genuine License Validation

Select an action if the application does not pass genuine validation.

 

·         No Action. The protected program performs no action.

·         Set non-genuine flag for KeyCheck API. The non-genuine flag (bit-30 of the Options property) is set to the Key. You can use the KeyCheck API to get this flag value and perform the action as you want, for example, disabling some features in your application. This flag is cleared when the license is activated properly by the Activation Server.

·         Invalidate license. The protected program invalidates the Key after which it can no longer to be licensed again.

note NOTE: An attempt to run the protected program with the invalidated license will give the error message “Invalid Key (Program ID)!”. To allow the user to activate the license again, you can provide the user the Remake utility with the automatic activation option. In this case, the valid Activation Key is required for authentication with the Activation Server first before the remake can be made. For more details, see the topic: End-User Utilities: Machine License Utilities/Remake Utility.

Extended

Block Multiple Processes for Win32/64/.NET Applications

Enable the protected program to operate as one process (or one task) only. The protected program blocks all additional processes that might be executed.

 

·         Module Name. Assign a unique name for the protected program. This module name is used by the shell protection in the process of blocking multiple processes. A unique name is automatically assigned when the Auto detect is checked.  

Errors Caused by Protected Program in Background Process

This option allows you to specify how the protected Win32/Win64/.NET program running in background process handles errors.

 

·         Terminate the protected program without confirmation prompt. The protected program running as a background process is sometimes not connected to a console. For instance, an ActiveX/COM DLL runs on an IIS platform server as a web-based application. The error messages may not be accessed by the end-user. When an error occurs, this option enables the protected program to terminate itself without displaying a confirmation prompt. This option should be enabled when characteristic of the protected program is set to Service or ActiveX/COM DLL. 

Application Startup Optimization

When starting the protected application, the ElecKey agent is automatically loaded in the background. This may cause a slight delay in the startup of the application. You can speed up the startup by specifying how the agent is loaded.

 

·         [Normal] Run the agent until the application is closed. By default, the agent is loaded when the application is started, and is terminated when the application is closed. An advantage is that the agent only runs in the background when the application is in use. However, the agent needs to be loaded every time when the application is started.

·         [Faster] Run the agent without termination. The agent is loaded when the application is started, but it is not terminated when the application is closed. This can help to speed up the startup the next times the application is started because the agent remains running in the background.

·         [Maximum] Run and install the agent to the Windows startup. The first time the agent is loaded, it will be installed to the Windows startup registry. Thereafter, the agent is automatically loaded when Windows starts. This ensures that the agent is always running in the background whenever the application is started.