KEYnote 34 Deutsch - Ausgabe Herbst 2017 - Page 4

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)