Häufig gestellte Fragen
Teilen:
.NET
- Seit AxProtector Version 10.70 gibt es für .NET eine neue Laufzeitbibliothek cprsrt.dll, die zur Laufzeit verfügbar sein muss.
Diese Bibliothek wird mit Zertifikaten abgesichert, um eine verschlüsselte Kommunikation und einen Integritätscheck zu ermöglichen.
Dafür muss AxProtector bei der Verschlüsselung das "WPK Zertifikat" einer FSB (Firm Security Box) verwenden.
Hierfür wird normalerweise immer das Zertifikat für den Firm Code des Lizenzeintrags, für den die Anwendung verschlüsselt ist, verwendet.
Da bei Verwendung von IP Protection allerdings kein Lizenzeintrag verwendet wird, müssen Sie hier explizit einen Firm Code eintragen, für den Sie bei der Verschlüsselung einen gültigen FSB-Eintrag haben, z.B.: -lfc6000010. - Im AxProtector .NET v10.70 ist die neue Laufzeitbibliothek "CodeMeter Protection Suite Runtime Bibliothek (CPSRT)" hinzugekommen.
Diese wird bei der Ausführung des geschützten Assemblies mit dem .NET Framework benötigt und daher beim Verschlüsseln in den Ausgabeordner kopiert.
Mit Hilfe dieser CPSRT-Bibliothek wird die Unterstützung von 'AppDomain' umgesetzt. Die bisher für diese Anwendungsfälle notwendige Option '-appdomain' entfällt damit.
Zur Verwendung der CPSRT-Dlls ist ein Firm Code-spezifisches Zertifikat in Ihrer FSB notwendig. Dieses scheint bei Ihnen zu fehlen.
Daher erscheint bei der Verschlüsselung folgende Meldung:
=========================================
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".
=========================================
Das fehlende Zertifikat kann kostenlos bei Wibu-Systems angefordert werden. Bitte gehen Sie dazu wie in der Fehlermeldung beschrieben vor und schicken Sie eine Kontext-Datei vom Firm Code 99 Ihrer FSB per Mail mit dem Betreff "Certificate License Update" an license@wibu.com. - AxProtector .NET stellt über die WupiEngineNet.dll mehrere Attribute zur Verfügung, die verwendet werden können, um gezielt den Schutz von spezifischen Namespaces, Klassen und Methoden zu beeinflussen.
Die Attribute heißen Protection und Licensing und sind über den WupiEngine Namespace verfügbar.
Folgend ein kleines Beispiel das die Verwendung demonstriert:
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
}
}
}
Folgende Kombination ist auch möglich:
[Licensing(Encryption=True, LicenseList=1)] - Bei der Verwendung von AxProtector .NET können Elemente gezielt aus der Obfuskierung ausgeschlossen werden, indem Attribute verwendet werden.
Dazu kann das Obfuscation Attribute aus dem System.Reflection Namespace verwendet werden. Dazu wird der Parameter Exclude=true benötigt.
Anbei ein Code-Beispiel, wie dies aussehen könnte:
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 ist ein optionales Sicherheitsfeature in Windows das die Verwendung einiger .NET Framework-Klassen einschränkt. Dabei geht es darum, dass nur speziell ausgewählt krypthografische Implementationen verwendet werden sollen.
Mehr Informationen dazu finden Sie unter: https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/system-cryptography-use-fips-compliant-algorithms-for-encryption-hashing-and-signing
CodeMeter verwendete in der Vergangenheit Klassen, z.B. SHA256ManagedHash, die nicht kompatibel mit diesem Standard sind. Beginnend mit CodeMeter 6.60a ist CodeMeter nun FIPS kompatibel.
Desweiteren gibt es zwei Behelfslösungen, mit denen der Fehler umgangen werden kann:
1. Deaktivieren des FIPS Modus auf dem System.
2. Die spezifische Anwendung als Ausnahme für FIPS definieren.
Hierzu muss eine "MyApp.exe.config" (Name muss angepasst werden) neben die Anwendung gelegt werden, mit folgendem Inhalt:
<configuration>
<runtime>
<enforceFIPSPolicy enabled="false"/>
</runtime>
</configuration> - Für AxProtector .NET wurde ab Version 10.30 angefangen, den Ansatz zum Schutz eines Assembly grundsätzlich umzustellen.
Dabei kam es zu Inkompatibilitäten zwischen Assemblies, die mit verschiedenen AxProtector-Versionen geschützt wurden.
Grundliegend gibt es zwei Technologien, die nacheinander implementiert wurden:
• High Speed Cache (HSC)
• Copy Protection System Runtime (cpsrt)
Technisch sind diese zueinander inkompatibel und können nicht im gleichen Prozess verwendet werden.
Folgende Technologie verwenden Sie je nach AxProtector-Version und Konfiguration:
High Speed Cache (HSC)
• AxProtector Version 10.30, wenn die Option -hsc gesetzt wurde
• AxProtector Version >= 10.31 und < 10.60
• AxProtector Version 10.60, wenn die Option -appdomain nicht gesetzt wurde
Copy Protection System Runtime (cpsrt)
•AxProtector Version 10.60, wenn die Option -appdomain gesetzt wurde
•AxProtector Version >= 10.70
Mit älteren AxProtector-Versionen (<10.30 oder 10.30 ohne -hsc) geschützte Assemblies sind mit beidem kompatibel und können problemlos weiterverwendet werden. - Dass durch die Verschlüsselung Performance Probleme auftreten können, ist uns bekannt. Die Ursache dafür ist, dass die Verschlüsselung den Original-Code an eine andere Stelle verschiebt und an der Original-Adresse AxProtector-Code eingefügt wird.
Wenn Sie nun die Assembly ausführen und eine verschlüsselte Methode aufgerufen wird, dann wird der AxProtector-Code vorgefunden, der an die entsprechende Stelle verweist, an die Ihr verschlüsselter Original-Code verschoben wurde. Anschließend wird der Code entschlüsselt, eine dynamische Methode erstellt und ausgeführt.
Dieser sicherheitstechnische "Umweg" lässt den ersten Aufruf einer verschlüsselten Methode ca. 1,2 - 1,5 ms (bei generischen Methoden auch bis zu 1,5 -2 ms) länger dauern. Dies hängt natürlich auch von der Hardware-Ausstattung des Systems ab, auf dem die Assembly ausgeführt wird.
Wenn die Methode nun ein zweites Mal aufgerufen wird, dauert dieser Aufruf ca. 8- 10 µs (bei generischen Methoden ca. 30 - 60 µs) länger. Dies liegt daran, dass erneut der AxProtector-Code angesprungen wird und dieser prüft, ob die Methode bereits entschlüsselt wurde. Wenn ja, wird direkt an die Stelle im Speicher verwiesen, an der der unverschlüsselte Code bereits liegt. Aber selbst diese kurze Umleitung bewirkt einen minimalen, weiteren Performanceverlust.
Der Performance-Verlust kann aber auch maßgeblich über die Anzahl, d.h. wie häufig die einzelnen Methoden aufgerufen werden, beeinflusst werden.Einzelne Methoden können teilweise bis zu 5.000.000 mal aufgerufen werden. Wenn Sie beispielsweise 5.000.000 mal 8 µs rechnen, ergeben sich daraus bereits 40 Sekunden. Und dies nur für eine einzelne Methode.
Häufig enthalten aber die Methoden, die so häufig aufgerufen werden, keinen elementaren Code.Daher kann man an Performance zurückgewinnen, wenn man diese Methoden von der Verschlüsselung ausschließt.
Wir schließen z.B. bereits standardmäßig automatisch alle Methoden von der Verschlüsselung aus, die kleiner als 10 Bytes sind, da wir davon ausgehen, dass eine Methode dieser Größe keinen elementaren Code beinhaltet. Sie können die Größe aber auch selbst festlegen. Die Option dafür ist "-CMLn": es werden dann nur Methoden verschlüsselt, die kleiner n Bytes sind.
Um herauszufinden, welche Methoden bei Ihrer Assembly außergewöhnlich oft aufgerufen werden, empfehlen wir den Einsatz eines .NET Profiling Tools. Diese Profiling Tools zeigen genau an, welche Methoden, wie häufig aufgerufen wurden und wieviel Zeit dafür benötigt wird. Auf Basis dieser Daten kann dann entschieden werden, welche Methoden verschlüsselt werden sollen und welche nicht. - Da WPF/Xaml/Prism-Anwendungen viel mit Reflection arbeiten, kann nicht ohne Weiteres garantiert werden, dass die obfuskierten Namen von Methoden, Feldern usw. überall anstelle der ursprünglichen Namen eingetragen werden.
Wenn die Obfuskierung aktiviert ist und WPF-Anwendungen erkannt werden, wird die Verschlüsselung mit einer Fehlermeldung abgebrochen. Fehler: XPM6402
Wenn Sie sicher sind, dass Sie trotzdem obfuskieren woll, können Sie mit -force:XPM6402 den Fehler deaktivieren.
Anschließend ist es aber wichtig, dass Sie testen, dass nach der Verschlüsselung noch alles korrekt funktioniert. - Wenn Sie ein Assembly signieren wollen, müssen Sie dies nach der Verschlüsselung tun.
AxProtector .Net bietet dabei Möglichkeiten, die Schlüssel für die Signierung als Parameter mit anzugeben und damit das bei der Verschlüsselung erzeugte Assembly zu signieren.
Für die Signierung besitzen Sie mehrere Optionen:
Strong Name aus einer Datei
Sie können mit Sn.exe -k WibuKeyFile.snk ein Schlüsselpaar direkt in eine snk-Datei schreiben.
Über die AxProtector .NET-Einstellungen 'Strong Name aus Datei' (Option –snkf) können Sie nun die Datei 'WibuKeyFile.snk' für die Signierung angeben.
Bitte beachten Sie, dass die Verwendung einer Passwort-geschützten Datei (*.pfx) hier nicht unterstützt wird. Sie können diese aber wie nachfolgend beschrieben verwenden.
Verzögertes Signieren:
Wenn Sie verzögert signieren, benötigen Sie zunächst eine snk-Datei, die den PublicKey enthält und dann später eine snk-Datei mit Ihrem Schlüsselpaar.
Dann gehen Sie folgt vor:
1. Assembly vom Compiler erzeugen lassen und dabei zusammen mit der Option "Nur Signieren verzögern" die snk-Datei mit dem Public Key angeben.
2. Erzeugtes Assembly von AxProtector .NET verschlüsseln lassen, dabei keine snk-Datei angeben!
3. Verschlüsseltes Assembly signieren bzw. signieren lassen.
Strong Name aus einem Container
Eine mit sn.exe -k WibuKeyFile.snk erzeugte Datei oder auch *.pfx-Datei , können Sie dann auch in einen Container installieren:
sn.exe -i WibuKeyFile[.snk|pfx] WibuContainer
Über die AxProtector .NET-Einstellungen 'Strong Name aus Container“ (Option –snkn) können Sie nun 'WibuContainer' für die Signierung angeben.