Frequently Asked Questions
Share:
.NET
- Since AxProtector version 10.70, there is a new runtime library cprsrt.dll for .NET, which must be available at runtime.
This library is secured with certificates to enable encrypted communication and an integrity check.
For this AxProtector must use the "WPK certificate" of a FSB (Firm Security Box) for encryption.
For this, usually the certificate for the Firm Code of the license entry is used, for which the application is encrypted.
However, since no license entry is used when using IP Protection, you must explicitly enter a Firm Code here for which you have a valid FSB entry when encrypting, e.g.: -lfc6000010. - In AxProtector .NET v10.70, the new runtime library "CodeMeter Protection Suite Runtime Library (CPSRT)" has been added. This is required when executing the protected assembly with .NET Framework and is therefore copied to the output folder during encryption.
With the help of this CPSRT library, the support of 'AppDomain' is implemented. The '-appdomain' option previously required for these applications is no longer required.
A Firm Code specific certificate is required in your FSB to use the CPSRT-Dlls. This seems to be missing in your case. Therefore, the following message appears during encryption:
==========================================
Error: No WPK certificate found in FSB. For protection, a certificate matching the Firm Code is required. This certificate is available free of charge from Wibu-Systems. Please send a context file for Firm Code 99 of your CodeMeter-FSB by e-mail to license@wibu.com with the subject "Certificate License Update".
==========================================
The missing certificate can be requested from Wibu-Systems free of charge. To do this, please proceed as described in the error message and send a context file from the Firm Code 99 of your FSB by email with the subject "Certificate License Update" to license@wibu.com. - AxProtector .NET provides several attributes via WupiEngineNet.dll that can be used to target the protection of specific namespaces, classes and methods.
The attributes are called Protection and Licensing and are available through the WupiEngine namespace.
Below is a small example that demonstrates the usage:
using WupiEngine;
[Licensing(Encryption=true)]
namespace TestAssembly
{
public class showWindow : Form
{
[Licensing(Encryption=false)]
public showWindow()
{
// stays unencrypted
InitializeComponent();
}
[Protection(TrapLevel.All)]
private void ShowModuleAdvanced()
{
// trap that will lock the license when called
}
[Licensing(LicenseList=1)]
private void ShowModule()
{
// encrypted using License List 1 as defined in the AxProtectorNet settings
}
}
}
The following combination is also possible:
[Licensing(Encryption=True, LicenseList=1)] - When using AxProtector .NET elements can be specifically excluded from obfuscation by using attributes.
For this purpose, the obfuscation attribute from the System.Reflection namespace can be used. This requires the parameter Exclude=true.
Below is a code example of how this might look
using System.Reflection;
namespace WUPIBlackistingAttributesDemoCS {
[Obfuscation(Exclude=true)]
public partial class Form1 : Form {
public Form1() {
InitializeComponent();
}
[Obfuscation(Exclude=true)]
private void button1_Click(object sender, EventArgs e) {
MessageBox.Show("Hello World!");
}
}
} - FIPS is an optional security feature in Windows that restricts the use of some .NET Framework classes. The idea is that only specially selected crypthographic implementations should be used.
More information about this can be found at: https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/system-cryptography-use-fips-compliant-algorithms-for-encryption-hashing-and-signing
In the past, CodeMeter used classes, e.g. SHA256ManagedHash, which are not compatible with this standard. Starting with Version 6.60a CodeMeter is now FIPS compatible.
Furthermore, there are two workarounds that can be used to avoid the bug:
1. Disable FIPS mode on the system.
2. Define the specific application as an exception for FIPS.
To do this, a "MyApp.exe.config" (name must be customized) must be placed next to the application, with the following content:
<configuration>
<runtime>
<enforceFIPSPolicy enabled="false"/>
</runtime>
</configuration> - For AxProtector .NET, the approach to protecting an assembly was fundamentally changed from version 10.30 and higher.
This resulted in incompatibilities between assemblies that were protected with different AxProtector versions.
Basically, there are two technologies that were implemented after each other:
• High Speed Cache (HSC)
• Copy Protection System Runtime (cpsrt)
Technically, these are incompatible with each other and cannot be used in the same process.
Use the following technology depending on the AxProtector version and configuration:
High Speed Cache (HSC)
• AxProtector Version 10.30, if the -hsc option has been set
• AxProtector Version >= 10.31 and < 10.60
• AxProtector Version 10.60, if the -appdomain option has not been set
Copy Protection System Runtime (cpsrt)
•AxProtector Version 10.60, if the -appdomain option has been set
•AxProtector Version >= 10.70
Assemblies protected with older AxProtector versions (<10.30 or 10.30 without -hsc) are compatible with both and can continue to be used without any problems. - Since WPF/Xaml/Prism applications work a lot with reflection, it cannot be easily guaranteed that the obfuscated names of methods, fields, etc. will be entered everywhere instead of the original names.
If obfuscation is enabled and WPF applications are detected, encryption is aborted with an error message. Error: XPM6402
If you are sure that you still want to obfuscate, you can disable the error using -force:XPM6402.
Afterwards it is important that you test that everything still works correctly after the encryption. - This performance loss is a known issue. It occurs because your original code is "moved" to a secure place, and AxProtector code is placed at the original address when encrypting your assembly with AxProtector .NET.
If you now run your encrypted assembly and the method, which you encrypted, is called, only this AxProtector code is found. This AxProtector code redirects to the place at which the encrypted original code is stored. This code is then decrypted, and a dynamic method is created and executed.
As a result, the first calling-up of your encrypted method takes about 1.2 - 1.5 ms longer. This behavior also depends on the hardware setup of the PC on which the assembly is executed.
If your method is called a second time, this takes approx. 8 - 10 µs longer (generic methods take 30-60 µs longer), because the AxProtector code is executed again. However, AxProtector now checks, whether the method has been decrypted before. If this is the case, it redirects to the already encrypted code.
However, the performance loss is also largely determined by how often individual methods are called. For example calling a method 5,000,000 times adds up to 40 seconds, given 8 µs for each call.
Methods called this often typically hold no elementary code. You can regain performance, if you exclude such method from encryption. By default, we automatically exclude all methods smaller than 10 bytes. You can also customize the size of the excluded methods. This is done via the AxProtector option "-CMLn", which defines that only methods smaller than n bytes are encrypted.
In order to find out which methods are called frequently by an assembly, we recommend using a .NET profiling tool. These tools give detailed information on the methods called and the time required. Based on this data, you can decide which methods should be encrypted. - If you want to sign your assembly, you must do so after the encryption.
AxProtector .Net offers the possibility to specify the keys for the signing as parameters and to sign the assembly created during the encryption.
You have several options for signing:
Strong Name from a file
You can use Sn.exe -k WibuKeyFile.snk to write a key pair directly to a snk file.
Via the AxProtector .NET settings 'Strong Name from file' (option -snkf) you can now specify the file 'WibuKeyFile.snk' for signing.
Please note that the use of a password protected file (*.pfx) is not supported here. However, you can use it as described below.
Delayed signing:
When you perform a delayed signing, you first need a snk file that contains the PublicKey and then later a snk file with your key pair.
Then please proceed as follows:
1. Have assembly generated by compiler, specifying a snk file with public key along with the "delay signing only" option.
2. Let AxProtector .NET encrypt generated assembly, do not specify a snk-file!
3. Sign the encrypted assembly or have it signed.
Strong Name from a container
A file created with sn.exe -k WibuKeyFile.snk or *.pfx file can be installed into a container:
sn.exe -i WibuKeyFile[.snk|pfx] WibuContainer
Via the AxProtector .NET settings 'Strong Name from Container' (option -snkn) you can now specify 'WibuContainer' for the signing.