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

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.

Die ausführbare Datei wird durch AxProtector analysiert und komplett verschlüsselt. AxEngine – 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 passende Lizenz vorhanden, belegt AxEngine diese Lizenz und verwendet den in der Lizenz enthaltenen 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 Protection Suite ist dies natürlich schon immer möglich gewesen.

Ohne passende Lizenz, d.h. ohne passenden 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-Entscheidung hängt.

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 AxEngine Anti-Debug- und Anti-Dumping-Mechanismen als zweite Schutzschicht integriert.

Einer dieser Mechanismen ist die Verschlüsselung von Ressourcen. Die Ressource-Sektion Ihrer Anwendung wird dabei verschlüsselt in der ausführbaren Datei abgelegt. Diese Ressource-Sektion wird beim Laden in den Speicher nicht entschlüsselt, 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 Anwendung komplett transparent im Hintergrund funktioniert. Im Memory-Dump sind die Ressourcen aber weiterhin verschlüsselt und können ohne den Schlüssel in der passenden Lizenz nicht entschlüsselt und verwendet werden.

Ein zweiter Mechanismus ist das Erkennen von laufenden Hacker-Tools wie Dumpern und Debuggern. Falls diese Tools laufen, bricht AxEngine das Laden der Anwendung schon vor der Entschlüsselung ab. Ein Memory-Dump ist unmö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ängten 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 statischen (durch AxProtector beim Verschlüsseln) und dynamischen (durch AxEngine beim Laden) Modifikationen Ihrer ausführbaren Dateien. Dabei werden bekannte Muster wie Aufrufe von Windows-API-Funktionen erkannt und verändert. Diese Veränderung wird so durchgeführt, dass sie von automatischen Dumping- und Rekonstruktions-Tools nur extrem aufwändig rückgängig gemacht werden kann.

Die meisten dieser Methoden sind für Windows implementiert, was der Tatsache Rechnung trägt, dass die meisten Hacker-Tools ebenfalls auf Windows-Plattformen verfügbar sind.

IxProtector für dynamische Entschlüsselung zur Laufzeit

IxProtector ist die dritte Schutzschicht zum Schutz Ihrer Anwendung gegen Memory-Dumps. Sie definieren einzelne Funktionen, die ganz analog zu den Ressourcen verschlüsselt im Speicher liegen bleiben. Über die Funktionen WupiDecryptCode und WupiEncryptCode können Sie selber implementieren, wann die einzelnen Funktionen entschlüsselt und wieder verschlüsselt werden.

Die einzelnen Funktionen liegen in einem Memory-Dump dann in der Regel auch weiterhin verschlüsselt vor. Um einen vollständig lauffähigen Hack zu erzeugen, müssten hier vom Hacker viele Puzzleteile manuell zusammengesetzt werden. Durch eine Erhöhung der Anzahl der verschlüsselten Funktionen und eine dynamische Entschlüsselung zur Laufzeit können Sie den Schutzlevel selbstständig steigern.

IxProtector ist für Windows, Linux x86/x64/ARM und macOS verfügbar.

Fallen zur Verhinderung von statischer Analyse

Ein Angreifer könnte vor dem Dumping oder auch im erzeugten Dump auf die Idee kommen, alle verschlüsselten Funktionen manuell zu entschlüsseln.

Zum einen benötigt er dazu die passenden Lizenzen dieser Funktionen. Unterschiedliche Lizenzen besitzen im CodeMeter-Universum auch unterschiedliche Schlüssel – ein weiteres Alleinstellungsmerkmal von CodeMeter. Wenn einzelne Funktionen verschiedenen Lizenzen zugeordnet sind, können diese auch mit unterschiedlichen Schlüsseln verschlüsselt werden. Ein Hacker müsste alle Schlüssel besitzen.

Zum anderen: Auch wenn ein Hacker alle Schlüssel besitzt, bietet IxProtector mit Fallen als vierter Schutzschicht eine perfekte Lösung, um ein systematisches Entschlüsseln aller Funktionen zu verhindern. Sie fügen in Ihre Anwendung Funktionen ein, die nie aufgerufen werden. Der Anfang der Funktion wird durch einen Sperrcode ersetzt. Entschlüsselt ein Hacker solch eine Funktion (weil er alle Funktionen entschlüsseln will), sperrt sich seine Lizenz und eine Entschlüsselung weiterer Funktionen ist erst nach Freischaltung durch Sie als Hersteller wieder möglich – ein effektiver Mechanismus, vor allem für CmDongles.

Translocated Execution als ultimativer Schutz

Translocated Execution ist die fünfte und ultimative Schutzschicht zum Schutz gegen Memory-Dumps. Neben dem höheren Schutz bietet Translocated Execution einen Automatismus, der die Integration von IxProtector deutlich vereinfacht.

Translocated Execution ist eine Erweiterung von IxProtector. Im Gegensatz zum Standard-IxProtector werden die Funktionen aber nicht am originalen Platz entschlüsselt und ausgeführt, sondern an einer anderen Stelle im Speicher. Die gleiche Stelle wird für mehrere verschiedene Funktionen verwendet, die nacheinander benötigt werden. Das Puzzlespiel für den Hacker wird damit deutlich komplexer, da eine Zuordnung, an welche Stelle welche Teile passen, umso schwieriger wird – ein Puzzle mit Teilen, die sich in der Form ändern. Außerdem wird die Stelle, an der sich der entschlüsselte Code befindet, von den meisten Dumping-Tools ignoriert.

Für die Entschlüsselung stehen Ihnen zwei Modi zur Verfügung:

Bei der automatischen Entschlüsselung müssen Sie sich nicht um die Entschlüsselung kümmern. AxProtector fügt den Entschlüsselungs-Code automatisch an die Stelle ein, an der sich die originale Funktion befunden hat. Ein Modus mit Cache bietet die Option, die Funktion für eine kurze Zeit in einem Cache zu halten, bevor sie automatisch verworfen wird. Ohne Cache wird die Funktion sofort nach der Benutzung aus dem Speicher entfernt bzw. mit anderen Daten überschrieben.

Für mehr Kontrolle und für den Fall, dass die originale Funktion zu klein ist, können Sie die Funktionen wie beim Standard-IxProtector mit WupiDecryptCode und WupiEncryptCode selber entschlüsseln bzw. aus dem Cache entfernen. Die Auswahl des Modus kann individuell für jede Funktion getroffen werden.

Translocated Execution ist für Windows, Linux x86/x64 und macOS verfügbar.

High-Level-Programmiersprachen

Für High-Level-Programmiersprachen wie .NET und Java stehen mit AxProtector .NET und AxProtector Java zwei speziell für diese Anwendungsfälle zugeschnittene Werkzeuge zur Verfügung. In diesem Fall ist die Trennung zwischen AxProtector und den Methoden von IxProtector fließend. Methoden, Funktionen und Klassen werden dynamisch zur Laufzeit entschlüsselt. Fallen stehen ebenso zur Verfügung. Bei .NET erfolgt die Entschlüsselung automatisch an einer anderen Stelle im Speicher.

Zusammenfassung

Die Verwendung von CodeMeter Protection Suite schützt Ihre Software effektiv gegen Memory-Dumping. Mit IxProtector und Translo-
cated Execution stehen Ihnen zwei Methoden zur Verfügung, die einfach zu integrieren sind und zusätzliche Schutzschichten bereitstellen, um Ihre Anwendung schützen.