Vertrauen ist gut, Verschlüsselung ist besser
Bei dem zweiten Ansatz – der Verschlüsselung des auszuführenden Codes – werden bereits während des Software-Build-Prozesses Teile der Applikation verschlüsselt und entsprechender Entschlüsselungscode in die Applikation eingebaut. Auch hier sind zwei Ansätze zu unterscheiden: Die Applikation liegt entweder verschlüsselt auf dem Speichermedium und wird zum Ladezeitpunkt entschlüsselt – liegt also im Speicher entschlüsselt vor. Oder in der Applikation sind ausgewählte Bereiche verschlüsselt und die Entschlüsselung erfolgt erst beim Aufruf der entsprechenden Funktion.
Der erste Ansatz vermeidet eine Beeinflussung des Laufzeitverhaltens, allerdings liegt bei der Ausführung die Applikation unverschlüsselt im Speicher vor und somit liefert ein Speicherabbild die entschlüsselten Informationen.
Ansatz Nummer zwei erfordert eine feine Kontrolle, welche Methoden verschlüsselt werden sollen. Der Entwickler muss gezielt die zu schützenden beziehungsweise nicht zu schützenden Codezeilen auswählen können. Nur so lässt sich ein negativer Einfluss auf zeitkritische Methoden sicher vermeiden. Es gibt eine Reihe von Vorteilen, die für diese Variante sprechen. Die Ladezeit wird nicht negativ beeinflusst und das Speicherabbild liefert keine unverschlüsselte Applikation. Außerdem lassen sich durch die gezielte Wahl der Methoden auch Lizensierungsmaßnahmen auf dieser Ebene automatisch einbauen. Der Entwickler kann auf diese Weise also nicht nur festlegen, welche Methode verschlüsselt werden soll, sondern auch ob sie nur bei Vorliegen einer bestimmter Lizenz ausgeführt werden darf. Im Idealfall schlägt das Entwicklerteam damit zwei Fliegen mit einer Klappe – die Applikation ist vor Reverse Engineering geschützt und gleichzeitig sorgt ein durchdachtes Software-Lizenzmanagement für mehr Flexibilität.
[subscribe2]
