PROTECTION
Höchste Sicherheit mit Translocated Execution
„Einen Wrapper, der eine Software verschlüsselt, kann man mit einem Memory-Dump recht einfach aushebeln. Man wartet, bis alle
Teile der Anwendung entschlüsselt sind und führt dann den Dump durch.“ Diese oder ähnliche Aussagen gelten für viele einfache
Produkte, aber nicht für CodeMeter Protection Suite. In diesem Artikel zeigen wir im Detail, warum dies bei Wibu-Systems besser ist.
AxProtector als erste
Schutzschicht Protection Suite ist dies natürlich schon immer
möglich gewesen.
AxProtector legt sich als Schutzschicht um jedes
einzelne Executable und jede Laufzeitbibliothek
Ihrer Anwendung. Dabei legen Sie selber fest,
ob Sie alle Module verschlüsseln wollen oder
nur einzelne ausführbare Dateien. AxProtector
ist als Kommandozeilenwerkzeug verfügbar
und kann somit im automatischen Buildsystem
im Rahmen von Continuous Integration einfach
aufgerufen werden. Ohne passende Lizenz, d.h. ohne passen-
den Schlüssel, ist eine Entschlüsselung nicht
möglich. Hier unterscheidet sich AxProtector
stark von einfachen Schutztools, die mit einem
festen Schlüssel arbeiten und bei denen die
Frage des Schutzes nur an einer Ja/ Nein-Ent-
scheidung hängt.
Die ausführbare Datei wird durch AxProtector
analysiert und komplett verschlüsselt. AxEn-
gine – eine Laufzeitkomponente, die für die
Entschlüsselung beim Starten der Anwendung
verantwortlich ist – wird zur ausführbaren Datei
hinzugefügt. Der Original Entry Point (OEP)
wird dabei so geändert, dass AxEngine beim
Laden zuerst aufgerufen wird. Ist eine passen-
de Lizenz vorhanden, belegt AxEngine diese
Lizenz und verwendet den in der Lizenz enthal-
tenen Schlüssel, um den ausführbaren Code im
Speicher zu entschlüsseln. Ein oft verbreiteter
Irrglaube ist übrigens, dass dies nicht erlaubt
sei. Dieser Irrglaube ist darin begründet, dass
fehlerhafte Implementierungen existierten, bei
denen diese Aktion fehlschlug. Mit CodeMeter
4
Automatische Anti-Dump-
Methoden
Eine einfache Entschlüsselung, wie im vorherigen
Kapitel beschrieben, ist natürlich viel zu wenig,
um einen Memory-Dump effektiv zu verhindern.
Daher sind in AxProtector und vor allem in AxEn-
gine Anti-Debug- und Anti-Dumping-Mechanis-
men als zweite Schutzschicht integriert.
Einer dieser Mechanismen ist die Verschlüsselung
von Ressourcen. Die Ressource-Sektion Ihrer An-
wendung wird dabei verschlüsselt in der ausführ-
baren Datei abgelegt. Diese Ressource-Sektion
wird beim Laden in den Speicher nicht entschlüs-
selt, sondern bleibt verschlüsselt im Speicher
liegen. AxProtector findet bei der Analyse Ihrer
Anwendung alle Stellen, an denen Sie auf Ihre
eigenen Ressourcen zugreifen und lenkt diese
Zugriffe auf AxEngine um. Dies führt dazu, dass
der Zugriff auf Ihre Ressourcen für Ihre Anwen-
dung komplett transparent im Hintergrund funk-
tioniert. Im Memory-Dump sind die Ressourcen
aber weiterhin verschlüsselt und können ohne
den Schlüssel in der passenden Lizenz nicht ent-
schlüsselt und verwendet werden.
Ein zweiter Mechanismus ist das Erkennen von
laufenden Hacker-Tools wie Dumpern und De-
buggern. Falls diese Tools laufen, bricht AxEn-
gine das Laden der Anwendung schon vor der
Entschlüsselung ab. Ein Memory-Dump ist un-
möglich. Eine sehr generische Art ist dabei die
„generische Debuggererkennung“. AxEngine
enthält in diesem Fall einen eigenen Debugger,
der an Ihre Anwendung angehängt (attached)
wird. Da eine Anwendung nur einen angehäng-
ten Debugger gleichzeitig haben kann, ist dies
eine sehr effektive Methode, um Debugging zu
verhindern. Diese Methode geht natürlich nur
einmal pro Prozessraum und sollte daher nur
für das Executable aktiviert sein und nicht für
die Laufzeitbibliotheken.
Einen dritten Mechanismus bilden die stati-
schen (durch AxProtector beim Verschlüsseln)