Enhancing Protection With "AppOnChip"
Sentinel LDK Envelope incorporates AppOnChip protection to significantly increase the security of an application that is protected with a Sentinel HL (Driverless configuration) key.
NOTE This section is relevant for native Windows applications. For information on protecting .NET assemblies with AppOnChip, see Sentinel LDK Envelope for Windows.
Currently, the following limitations apply for the application to be protected using AppOnChip:
>You cannot use AppOnChip to protect the Licensing API DLL.
>AppOnChip protection cannot be applied to applications and DLLs that have already been protected with tools from other vendors or sources.
NOTE An application that is protected using AppOnChip is not compatible with Sentinel SL keys or with any HL keys other than Sentinel HL (Driverless configuration) keys. If no Sentinel HL (Driverless configuration) key is present at execution time, an application that is protected using AppOnChip will stop and display a message that asks the user to attach an appropriate HL key.
If the protected application will be licensed using a Sentinel HL Basic key or Sentinel HL Pro key, you must connect a Developer key that contains the AppOnChip module at the time that you protect the application. For more information, see AppOnChip Module.
Once enabled, AppOnChip uses a code transformation engine to analyze the application code. AppOnChip searches the application code for code fragments that can be offloaded to the Sentinel HL key. Functions containing eligible code fragments are listed in a table on the AppOnChip tabbed page in the Sentinel LDK Envelope interface.
AppOnChip identifies eligible code fragments in a two-step process:
1.AppOnChip identifies the application's functions using a map file. If a map file is not available, AppOnChip uses only the functions exported by the exe/dll (exports) for its subsequent analysis. Currently, only map files generated by a Microsoft Visual Studio compiler or a Delphi compiler are supported.
2.AppOnChip analyzes the machine code of the functions identified in the first step and searches for code fragments that are suitable to be extracted and executed by the Sentinel HL key. Functions that contain suitable code fragments are added to AppOnChip's list of functions.
You can examine AppOnChip's list of functions and modify the selections to include only those functions that you want AppOnChip to protect.
AppOnChip also provides a Performance Profiling facility. This facility equips the eligible code fragments so that the application collects runtime statistics for these code fragments when they are executed. Minimal runtime overhead is added by this process. These statistics are then used by AppOnChip to help you balance application security and performance.
When Envelope generates the protected application, AppOnChip automatically removes the eligible code fragments from the selected functions and replaces them with a transition code. The extracted code fragments are encrypted and signed with a vendor-specific key, and saved as part of the protected application.
Note that with the supported compilers (described above), the protection process is fully automatic. It is not necessary for you to make any changes to your application code to accommodate this process.
At run-time, when the application calls one of the protected functions, the encrypted code fragment is uploaded to the Sentinel HL key. Within the key, the code is decrypted and loaded into a virtual machine. Once loaded, the code is executed by the virtual machine. The output of the code is passed back to the protected function so that the application can continue to execute.
As a result of this process, protected code fragments are never exposed in any manner that would enable a cracker to analyze or disassemble the code.
Best Practices for Selecting Functions for Protection
AppOnChip provides significant protection when you implement it correctly to create a strong binding between the application logic and the HL key. To achieve optimum security, be sure to implement the following recommendations:
>Apply AppOnChip to a large number of functions. This increases an attacker's effort and also increases the odds of covering the recommendations that follow.
>Use AppOnChip to protect functions that are really necessary for the application's core purpose. There is little benefit in protecting secondary functions (for example: licensing, phone home). Your main objective is to force an attacker to really attack AppOnChip instead of just disabling the calls to the AppOnChip-protected functions.
>Use AppOnChip to protect functions that process user data and not just constant data. Functions that process unchanging data can be defeated using a replay attack.
>Use AppOnChip to protect functions that have not been released with a previous version of your application. Otherwise, an attacker could reconstruct AppOnChip snippets by taking the code from a previous release.
To achieve an optimum balance between performance and security for the protected application, consider the following factors:
>Estimated upload time.
>Size of the function code. (It is more difficult for a cracker to guess the logic of larger blocks of code.)
>Frequency with which the function is called.
>Importance of the intellectual property in the function.
When you choose which functions should be protected, consider the frequency with which each function will be swapped and the time required to upload the function. Pay attention to recursive functions and to functions that are called within loops. This becomes especially important when you enable concurrency, and the protected application is licensed using a Sentinel HL network key. Multiple instances of the protected application will be calling different functions at the same time.
For information about the following, see Sentinel LDK Envelope for Windows:
>The functions available for protection with AppOnChip.
>Using Performance Profiling mode to evaluate the performance impact on your selected functions.
