Obfuscator-Techniken, oder wie kann in .NET Programmcode

Obfuscator-Techniken, oder wie kann in .NET Programmcode

Obfuscator-Techniken, oder wie kann in
.NET Programmcode geschützt werden?
Johannes Lipsky, Katja Weidner, Marc Schanne (lipsky|weidner|schanne@fzi.de)
1 Motivation
reichen vom Brechen von Kopierschutzmechanismen
über das gezielte Aufspüren von Sicherheitslücken bis
hin zum Diebstahl geistigen Eigentums. Als Schutzmechanismus vor unerwünschter Spionage kommt zwar auf
den ersten Blick auch das Verschlüsseln des Codes in
Frage. Jedoch erweist sich diese Möglichkeit als wenig
geeignet, da man der CLR zum Ausführen sowohl die
Entschlüsselungsmethode als auch den Schlüssel bereitstellen müsste und diese Informationen stehen damit
automatisch auch dem Angreifer zur Verfügung.
Eine der wichtigsten Entwurfsentscheidungen des
Microsoft .NET Frameworks ist die Sprachunabhängigkeit. Quellcode, der in einer .NET Sprache geschrieben
wurde, wird vom Compiler in CIL (Common Intermediate Language) Anweisungen übersetzt und in
Assemblys zusammengefasst. Eine Assembly stellt die
Verpackungseinheit eines .NET Programms dar, sie erscheint nach außen als gewöhnliche Datei (.exe oder
.dll), ist jedoch intern völlig anders strukturiert und enthält unter anderem Metadaten, die Typen, Mitglieder
und Code-Referenzen zu anderen Assemblys beschreiben. CIL-Anweisungen werden von einer Stack-basierten, virtuellen Maschine, der CLR (Common Language
Runtime), des ausführenden Systems zur Laufzeit interpretiert und dabei in maschinenabhängigen Code übersetzt. Eine .NET Assembly enthält also Code, der sich
auf einem höheren Abstraktionsniveau befindet, als ein
Programm in Maschinencode, das zum Beispiel in C++
geschrieben wurde. Neben den Vorteilen der Sprachunabhängigkeit und der Interoperabilität der .NET Hochsprachen bringen diese Eigenschaften jedoch einen nicht
zu unterschätzenden Nachteil mit sich. Die in einer Assembly enthaltenen Daten stellen genug Informationen
bereit, um den Quellcode der .NET Sprache fast originalgetreu wieder herzustellen (siehe Abb. 1). Der Schutz
geistigen Eigentums, wie etwa Algorithmen, Programmlogik oder Datenstrukturen, ist praktisch nicht vorhanden.
Ein Obfuscator überführt eine Assembly in eine Form,
die Daten und Programmabläufe verschleiert und das
Verständnis des rückübersetzten Codes damit möglichst
schwierig macht. Gleichzeitig verändert der Obfuscator
jedoch nicht die Funktionalität des Programms. Der
Trick eines Obfuscators besteht also darin den Angreifer
zu verwirren und gleichzeitig der CLR die selbe Logik
zu liefern. Abbildung 2 zeigt den Einsatz eines Obfuscators. Einen hundertprozentigen Schutz gewährt zwar
auch ein Obfuscator nicht, macht aber Reverse Engineering zeitaufwendig und damit letztlich unrentabel.
In diesem Papier stellen wir zunächst die Möglichkeiten
der Deassemblierung und Dekompilierung von .NET Assemblys kurz vor. Danach wird ein detaillierter Einblick
in die unterschiedlichen Formen von Obfuscatingtransformationen und deren Arbeitsweise geliefert. Daraus
folgern wir einige Bewertungskriterien, die den Leser bei
der Wahl eines für seine Zwecke geeigneten Obfuscators
unterstützen sollen. Abschließend geben wir eine Übersicht der momentan verfügbaren Obfuscatoren.
Ist der Quellcode der Hochsprache erst wieder hergestellt, sind die Möglichkeiten des Angriffs vielfältig und
Dekompiler
Source Code
Compiler
Source Code
Angriff
Assembly
CLR
P rogrammausführung
Abbildung 1: Vorgehen ohne Obfuscator
Dekompiler
Assembly
verschleierter
Source Code
Angriff
geschützte
Assembly
Obfuscator
CLR
P rogrammausführung
gleiche Funktionalität
Abbildung 2: Vorgehen mit Obfuscator
1/15
Abbildung 3: "Hallo Welt" in ILDASM geöffnet
Abbildung 4: Die Main-Methode von "Hallo Welt" in ILDASM
2 Deassemblierung von .NET Assemblys
Metadaten sowie den CIL Code an. In Verbindung mit
dem ebenfalls enthaltenen Programm ILASM.exe ist es
sogar möglich, Veränderungen am CIL Code vorzunehmen und die so entstandenen neuen Dateien wieder in
eine funktionsfähige Binärdatei zu übersetzen. Dieser
Vorgang wird als round tripping bezeichnet.
Dieser Abschnitt beschreibt die Möglichkeiten der Deassemblierung von .NET Assemblys exemplarisch anhand
der beiden Programme ILDASM und Reflector [11].
Dies soll zeigen, wie wichtig der Schutz eines .NET Programmes ist da sich selbst mit frei verfügbarer Software
beachtliche Ergebnisse erzielen lassen. Beide Programme nutzen den Mechanismus der Reflektion, um den Inhalt einer Assembly zu erfassen. Wir demonstrieren ihre
Arbeitsweise jeweils mit einem einfachen "Hallo
Welt"-Programm und einer komplexeren Funktion aus
mscorelib.dll. Als Beispiel dient das Programm "Hallo
Welt", das in Beispiel 1 als C# Programmtext dargestellt
ist.
Das Öffnen des kompilierten "Hallo Welt"-Programms
führt zu der in Abbildung 3 gezeigten Ausgabe. In der
obersten Ebene der Baumstruktur befindet sich das Manifest der Assembly und der Namensraum "Hallo". Darauf folgt in der nächsten Ebene die einzige Klasse des
Namensraums, "HalloWelt". Das erste Element der
Klasse enthält Metadaten und zeigt an, dass die Klasse
keinen Klassenkonstruktor benötigt. Darauf folgen der
Instanzkonstruktor der Klasse und die statische Methode
Main.
using System;
namespace Hallo
{
public class HalloWelt
{
static void Main(string[] args)
{
Console.WriteLine("Hallo Welt!");
}
}
}
Beispiel 1: Das Program "Hallo Welt!"
Ein Doppelklick auf ein beliebiges Element der Baumstruktur öffnet ein neues Fenster und zeigt die Implementierung des Elements in IL Code. Die Main-Methode
des Beispiels sehen Sie in Abbildung 4. Der Befehl
ldstr legt den String "Hallo Welt!" auf dem Stack ab.
Anschließend wird die Methode System.Console.WriteLine aufgerufen, die den String auf dem
Stack als Parameter nutzt.
In Abbildung 5 sehen Sie die in ILDASM geöffnete
Klasse System.Collections.ArrayList aus
mscorelib.dll. Die Datei befindet sich im Installationsverzeichnis des .NET Framework.
2.1 ILDASM
Das Programm ILDASM.exe (Intermediate Language
Disassembler) ist bereits in der Installation des .NET
Framework SDK enthalten. Es öffnet bereits kompilierte
Module oder Assemblys und zeigt die darin enthaltenen
Öffnet man zum Beispiel die Methode InsertRange
2/15
Abbildung 5: Die Klasse System.Collection.ArrayList in ILDASM
Abbildung 6: Ausschnitt der InsertRange Methode der Klasse System.Collection.ArrayList
der Klasse ArrayList sieht man deutlich komplexeren
Code. Abbildung 6 zeigt einen Ausschnitt der Methode.
Die Funktionalität des Codes nachzuvollziehen, ist nicht
mehr so leicht wie im ersten Beispiel, aber mit Hilfe der
bereitgestellten Metadaten und einer CIL Befehlsreferenz keinesfalls unmöglich.
tor ist der des IL Disassemblers sehr ähnlich, jedoch gehen die Fähigkeiten des Programms weit darüber hinaus.
In einer Dropdownliste in der Menüleiste von Reflector
kann die gewünschte Sprache einstellt werden, in die Reflector den Code der Assembly rückübersetzt. Die
Auswahl einer Methode zeigt deren Signatur im unteren
Abschnitt von Reflector an und ein Doppelklick führt zur
Darstellung des Codes in der oben ausgewählten Sprache. Abbildung 7 zeigt dies am Beispiel von "Hallo
Welt". Die in Abbildung 8 gezeigte InsertRange Methode der ArrayList-Klasse demonstriert noch einmal deutlicher wie mächtig dieses Werkzeug ist. Der
2.2 Reflector
Reflector wurde von Lutz Roeder [11], einem Entwickler
bei Microsoft, geschrieben und kann von dessen Website
kostenlos bezogen werden. Die Arbeitsweise von Reflec-
3/15
Abbildung 7: "Hallo Welt" in Reflector geöffnet
Abbildung 8: Anzeige der InsertRange Methode in Reflector
3 Obfuscatingtransformationen
hier gezeigte Code könnte praktisch per Copy&Paste
übernommen werden.
Um die Funktionsweise eines Programms vor Angreifern
zu verbergen, muss ein Obfuscator den Code des Programms verändern. Erreicht wird dieses Ziel durch die
Anwendung verschiedener Transformationen, die auch
als Obfuscatingtransformationen bezeichnet werden.
Dieses Kapitel beschäftigt sich mit unterschiedlichen
Formen von Obfuscatingtransformationen und ihrer
Funktionsweise.
2.3 Fazit
Selbst mit einfachen, frei erhältlichen Programmen lassen sich beachtliche Ergebnisse bei der Deassemblierung
bzw. Dekompilierung von .NET Assemblys erzielen.
Dies gilt selbst dann, wenn man sich zuvor nicht oder
nur sehr wenig mit den Methoden des Reverse Engineering beschäftigt hat, wie die obigen Beispiele verdeutlichen. Maßnahmen zum Schutz der eigenen Programme
vor Spionage zu ergreifen, ist also keineswegs übertriebener Aufwand.
Eine Transformation ist nur zulässig, wenn das Programm nach der Veränderung das selbe, beobachtbare
Verhalten zeigt, wie zuvor. „Beobachtbares Verhalten“
bedeutet in diesem Zusammenhang „aus der Sicht des
Benutzers äquivalent“. Das Programm darf also nach der
4/15
a = b.a(true);
a.a();
a(a);
Anwendung von Transformationen durchaus neue Seiteneffekte, wie zum Beispiel, das Erstellen von Dateien
enthalten, die ursprünglich nicht vorhanden waren. Dies
gilt allerdings nur unter der Bedingung, dass diese Effekte vor dem Benutzer verborgen werden. Weiterhin wird
nicht verlangt, dass das Programm nach seiner Veränderung mit der gleichen Effizienz, wie zuvor, arbeitet. Tatsächlich wird es in vielen Fällen langsamer arbeiten oder
mehr Speicher benötigen, da mit den meisten der nachfolgenden Transformationen eine Erhöhung der Rechenlast oder des Speicherbedarfs einhergeht. Man bezeichnet dies auch als die „Kosten“ einer Obfuscatingtransformation.
}
}
Beispiel 3: Deassemblierter Code mit Obfuscation [3]
3.2 Kontrolltransformationen
Unter die Kategorie der Kontrolltransformationen fallen
Transformationen, die den Kontrollfluss eines Programms verschleiern. Man kann Kontrolltransformationen in drei Kategorien unterteilen:
●
Aggregationstransformationen trennen Berechnungen, die logisch zusammen gehören, oder
fügen Berechnungen zusammen, die keinen
Bezug zueinander haben.
●
Ordnungstransformationen ändern die Reihenfolge, in der Anweisungen ausgeführt werden
und fügen, falls möglich, ein Element des Zufalls hinzu.
●
Berechnungstransformationen fügen redundanten oder toten Code ein oder nehmen Änderungen an Algorithmen vor.
Im Wesentlichen können die Transformationen in vier
Hauptkategorien eingeteilt werden:
●
Layouttransformationen
●
Kontrolltransformationen
●
Datentransformationen
●
präventive Maßnahmen
Eine weitere Unterteilung nach der Art der Obfuscation,
die die jeweilige Transformation auf dem Zielprogramm
ausführt, ist möglich.
Bei allen Transformationen, die den Kontrollfluss verändern, muss mit einer Erhöhung der Laufzeit oder des
Speicherbedarfs des Programms gerechnet werden. Oft
ist es nötig, einen Kompromiss zwischen dem Grad der
Effizienz eines Programms und dem Grad der Verschleierung des Codes einzugehen.
3.1 Layouttransformationen
Als triviale Layouttransformation bezeichnet man das
Entfernen von Formatierungen und Kommentaren aus
dem Code. Diese Transformationen sind nicht sehr wirksam, verursachen allerdings auch keine Erhöhung der
Laufzeit oder des Speicherbedarfs. Für .NET Sprachen
sind triviale Transformationen unbedeutend, da der CILCode weder Formatierungen noch Kommentare enthält.
Die Funktion vieler Transformationen beruht auf der
Existenz opaker Variablen und Prädikate (boolesche
Ausdrücke). Ein opakes Konstrukt zeichnet sich dadurch
aus, dass es eine bestimmte Eigenschaft oder einen bestimmten Wert hat, der zum Zeitpunkt der Transformation feststeht, aber für einen Angreifer nicht leicht zu ermitteln ist. Ein einfaches Beispiel für ein solches Konstrukt ist 7y² - 1 == x². Dieser boolesche Ausdruck wird, unter der Bedingung, dass x und y Elemente
der ganzen Zahlen sind, immer zu false evaluieren.
Dies ist jedoch nicht ohne weiteres ersichtlich.
Das Umbenennen von Bezeichnern ist eine weitere Layouttransformation. Im Gegensatz zu den trivialen Transformationen ist diese jedoch wesentlich effektiver. Die
meisten Programmierer geben ihren Methoden aussagekräftige Namen, welche die von der Methode verrichtete
Arbeit beschreiben. Diese Information hilft einem Angreifer enorm, da sie ihm einen Einblick in die Arbeitsweise des Programms verschafft. Viele Obfuscatoren
versuchen zum Beispiel möglichst vielen Methoden den
Namen „a“ zu geben. Dies verschlechtert die Lesbarkeit
des Codes und provoziert zudem Missverständnisse und
falsche Zuordnungen. Die Beispiele 2 und 3 zeigen die
selbe Methode im ursprünglichen Quellcode bzw. mit
umbenannten Bezeichnern.
Natürlich kann die Eigenschaft dieses Beispiels durch
eine statische Analyse relativ leicht ermittelt werden. Es
existieren jedoch auch Wege, opake Konstrukte zu erzeugen, die um ein Vielfaches komplexer sind. Eine
Möglichkeit besteht darin, eine komplexe Datenstruktur
(einen Baum oder Graph) zu erzeugen und eine Reihe
von Zeigern, die auf Elemente dieser Struktur verweisen,
zu verwalten. Während des Programmablaufs werden,
sowohl die Datenstruktur (hinzufügen neuer Elemente,
aufspalten in Teilbäume,...), als auch die Zeiger möglichst willkürlich geändert. Die Änderungen müssen jedoch einigen wenigen Bedingungen genügen, wie etwa
"Zeiger p und q dürfen nie auf das gleiche Element zeigen". Diese Bedingungen sind einfach zu programmieren, aber für den Angreifer schwer nachzuvollziehen.
Mit Hilfe der Elemente der Datenstruktur und der Kenntnis der Bedingungen können, dann im Programm opake
Konstrukte erstellt werden. Für dieses Verfahren bietet
sich auch die Verwendung mehrerer Threads an, die die
Datenstruktur gleichzeitig modifizieren und das System
private void CalcPayroll(SpecialList
employeeGroup)
{
while (employeeGroup.HasMore())
{
employee = employeeGroup.GetNext(true);
employee.updateSalary();
DitributeCheck(employee);
}
}
Beispiel 2: Deassemblierter Code ohne Obfuscation [3]
private void a(a b)
{
while (b.a())
{
5/15
public static int ggt(int a, int b)
{
int c = 0;
while (b != 0)
{
c = a % b;
a = b;
b = c;
}
return a;
}
Beispiel 5: Methode größter gemeinsamer Teiler
dadurch noch undurchsichtiger machen.
3.2.1 Aggregationstransformationen
Ein gängiges Mittel um der Komplexität eines Programmierproblems Herr zu werden, ist das Einführen von Abstraktionen. Methoden stellen eine sehr wichtige Form
der Abstraktion dar, sie bündeln zusammengehörigen
Code und grenzen ihn gegen andere Programmteile ab.
Aus diesem Grund ist es wichtig, Methodenaufrufe so
weit wie möglich zu verschleiern. Die grundlegende Idee
ist also Code, den der Programmierer in einer Methode
zusammengefasst hat, aufzubrechen und über das gesamte Programm zu verteilen und gleichzeitig Codeteile, die
keinen logischen Zusammenhang haben, in Methoden
zusammenzufassen. Im Folgenden stellen wir einige
Möglichkeiten vor, um Methoden und deren Aufrufe zu
verschleiern.
public static int calc(bool s, int a, int b)
{
int c = 0;
int d = 0;
if (s)
{
while (b != 0)
{
c = a % b;
a = b;
b = c;
}
return a;
}
else
{
c = calc(true, a, b);
d = a * b / c;
Methodentransformationen
Inlining und Outlining sind Techniken, die eigentlich
von Compilern zur Optimierung eingesetzt werden.
Beim Inlining wird der Aufruf einer Methode einfach
durch deren Rumpf ersetzt. Dies ist auch für den Zweck
der Verschleierung äußerst hilfreich, da gleichzeitig die
mit der Methode verbundene Abstraktion aus dem Code
entfernt wird. Outlining bezeichnet das Umwandeln einer Folge von Anweisungen in eine Subroutine. Mit Hilfe von Outlinig ist es möglich gefälschte Abstraktionen
zu erzeugen.
return d;
}
}
Beispiel 6: Verschatelte Methoden
Durch das Erstellen mehrerer unterschiedlicher
Versionen ein und der selben Methode können die
Aufrufpunkte und die Signatur einer Methode
verschleiert werden. Bei dieser als klonen bezeichneten
Technik
werden auf die Originalmethode unterschiedliche Sets von Obfuscatingtransformationen angewendet, um so verschiedene Klone zu erzeugen. Es wird
der Anschein erweckt, dass unterschiedliche Methoden
aufgerufen werden, obwohl dies tatsächlich nicht der
Fall ist.
Diese beiden Techniken lassen sich sehr gut in Kombination einsetzen. Dazu wird zuerst eine Folge von Methodenaufrufen mittels Inlining in eine Sequenz von Anweisungen verwandelt. Danach werden mittels Outlining
aus zufällig gewählten Anweisungssequenzen neue Methoden erzeugt.
Methoden, die in derselben Klasse deklariert sind, lassen
sich mit relativ wenig Aufwand verschachteln. Dies geschieht, indem man die Rümpfe und Parameterlisten der
Methoden zusammenführt und dann durch einen zusätzlichen Parameter oder eine globale Variable unterscheidet. Ideale Ergebnisse erzielt man mit diesem Verfahren,
wenn die Methoden sich sehr ähnlich sind und z.B. dieselben Parameter nutzen. Das Entdecken von verschachteltem Code wird dann für einen Angreifer äußerst
schwierig.
Schleifentransformation
Die meisten Schleifentransformationen wurden mit dem
Ziel entworfen, die Performance eines Programms, vor
allem bei numerischen Berechnungen, zu verbessern. Da
einige dieser Transformationen jedoch auch die Komplexität des Codes erhöhen, lassen sie sich auch zum Zweck
der Verschleierung einsetzen. Zur Demonstration verwenden wir die einfache Schleife in Beispiel 7, welche
die Fibonacci Folge bis zum n-ten Element und den Wert
von x² berechnet.
Die Beispiele 4 und 5 zeigen die Methoden zur Berechnung des größten gemeinsamen Teilers und des kleinsten
gemeinsamen Vielfachen. Beispiel 6 zeigt die verschachtelten Methoden. Die boolesche Variable s dient zur
Unterscheidung des Methodenaufrufs.
[0] = 0; a[1] = 1; b[0] = 0; b[1] = 1;
public static int kgv(int a, int b)
{
int c = ggt(a, b);
int d = a * b / c;
public static void original(long[] a, long[] b,
int n)
{
for (int i = 2; i < n; i++)
{
a[i] = a[i - 2] + a[i - 1];
b[i] = i * i;
}
}
Beispiel 7: Ausgangsmethode zur Schleifentransformation
return d;
}
Beispiel 4: Methode kleinstes gemeinsames Vielfaches
6/15
Loop blocking (Beispiel 8) wird benutzt, um den Iterationsraum einer Schleife so aufzuteilen, dass die Daten,
die in der Schleife benutzt werden, solange im Cache
bleiben, wie sie von der Schleife benötigt werden.
tionen jedoch in Kombination eingesetzt, erhöht sich die
von ihnen erzeugte Verwirrung drastisch. Die Anwendung aller drei Transformationen auf die Beispielmethode in Kombination zeigt Beispiel 11.
public static void blocking(long[] a, long[] b,
int n)
{
for (int I = 2; I < n; I += 10)
for (int i = I; i < Math.Min(I + 10, n);
i++)
{
a[i] = a[i - 2] + a[i - 1];
b[i] = i * i;
}
}
Beispiel 8: Loop blocking
public static void kombiniert(long[] a, long[]
b, int n)
{
for (int I = 2; I < n; I += 10)
{
for (int i = I; i < Math.Min(I + 9, n - 1);
i += 2)
{
a[i] = a[i - 2] + a[i - 1];
a[i + 1] = a[i - 1] + a[i];
}
for (int i = I; i < Math.Min(I + 9, n - 1);
i += 2)
{
b[i] = i * i;
b[i + 1] = (i + 1) * (i + 1);
}
}
if (n % 2 != 0)
{
a[n - 1] = a[n - 2] + a[n - 3];
b[n - 1] = (n - 1) * (n - 1);
}
}
Beispiel 11: Kombinierte Transformationen
Loop unrolling (Beispiel 9) erhöht die Cache Hit Rate
und verringert die Anzahl von Sprüngen, indem der
Schleifenkörper mehrfach dupliziert wird. Die Schleifenbedingung muss somit weniger oft ausgewertet werden.
Das komplette Entrollen einer Schleife ist möglich, wenn
zum Zeitpunkt des Kompilierens die Grenzen der
Schleife feststehen.
public static void unrolling(long[] a, long[]
b, int n)
{
for (int i = 2; i < (n - 1); i += 2)
{
a[i] = a[i - 2] + a[i - 1];
b[i] = i * i;
a[i+1] = a[i - 1] + a[i];
b[i+1] = (i+1) * (i+1);
}
if (n % 2 != 0)
{
a[n - 1] = a[n - 2] + a[n - 3];
b[n - 1] = (n - 1) * (n - 1);
}
}
Beispiel 9: Loop unrolling
3.2.2 Ordnungstransformationen
Programmierer organisieren Quellcode im Allgemeinen
so, dass die Lokalität möglichst maximal ist. Das bedeutet, dass Codeteile, die einen starken logischen Bezug
zueinander haben, sich auch im Code möglichst nahe
beieinander befinden. Lokalität existiert auf jeder Ebene
des Quellcodes, also zum Beispiel zwischen Anweisungen in Basisblöcken, Basisblöcken in Methoden, Methoden in Klassen, usw. Alle diese Arten der Lokalität
geben einem Angreifer nützliche Hinweise. Deshalb
sollte die Platzierung aller Elemente in der jeweiligen
Ebene möglichst zufällig erfolgen. Für manche Arten ist
dies relativ einfach, wie z.B. Methoden innerhalb von
Klassen. In anderen Fällen, wie etwa Anweisungen innerhalb von Basisblöcken, ist dies keineswegs trivial und
ohne vorherige Abhängigkeitsanalyse nicht möglich.
Loop fission (Beispiel 10). Ziel dieser Transformation ist
es eine Schleife in mehrere neue Schleifen aufzuteilen,
die jeweils über die gleiche Indexlänge laufen, jedoch
nur einen Arbeitsschritt der ursprünglichen Schleife
übernehmen. Dadurch wird eine Erhöhung der Datenlokalität erreicht.
Diese Arten der Transformation machen den Code an
sich zwar für Menschen nicht wesentlich schwerer zu
verstehen, erhöhen jedoch die Widerstandsfähigkeit gegen automatische Angriffe beträchtlich. In vielen Fällen
sind diese Transformationen nicht umkehrbar. Ist die
Ordnung erst einmal zerstört, kann sie nicht wieder hergestellt werden.
public static void fission(long[] a, long[] b,
int n)
{
for (int i = 2; i < n; i++)
{
a[i] = a[i - 2] + a[i - 1];
}
for (int i = 2; i < n; i++)
{
b[i] = i * i;
}
}
Beispiel 10: Loop fission
3.2.3 Berechnungstransformationen
Dieses Papier beschreibt drei unterschiedliche Formen
von Berechnungstransformationen.
Alle drei Transformationen erhöhen die Anzahl der Codezeilen und die Anzahl der auszuwertenden Bedingungen eines Programms und damit auch dessen Komplexität. Alleine eingesetzt, bietet jede dieser Transformationen nur einen geringen Schutz. Es ist z.B. nicht weiter
schwierig, eine entrollte Schleife zu erkennen und die
Umwandlung um zukehren. Werden die Transforma-
7/15
●
Transformationen, die den tatsächlichen Kontrollfluss hinter irrelevanten, nicht zu den aktuellen Berechnungen beitragenden, Anweisungen verstecken.
●
Transformationen, die Kontrollflussabstraktionen entfernen und gefälschte Abstraktionen einfügen und
●
Entfernen von Bibliotheksaufrufen
Transformationen, die Codesequenzen im Objektlevel-Code einfügen, für die keine entsprechenden Konstrukte in der Hochsprache existieren.
Die meisten Programme enthalten viele Aufrufe von Methoden aus Standardbibliotheken. Die Semantik dieser
Methoden ist bekannt und die Methodennamen können
nicht verschleiert werden, da sie für den Aufruf der Methode benötigt werden. Daher bietet sich die Analyse der
verwendeten Standardfunktionen als Einstiegspunkt für
einen Angriff an.
Die letzte Form ist nur in Sprachen anwendbar, bei denen der Objektcode mächtiger ist, als die Hochsprache.
Dies ist in Java der Fall, nicht jedoch im .NET Framework. Diese Art der Transformation ist hier nur der Vollständigkeit halber erwähnt.
Durch das Bereitstellen eigener Versionen der Standardbibliotheken ist der Obfuscator in der Lage, sowohl die
aussagekräftigen Namen, als auch den Code der Standardfunktionen zu verschleiern. Diese Transformation
erhöht vor allem den Speicherbedarf einer Applikation,
da die neu erzeugten Bibliotheken zusammen mit dem
Programm bereitgestellt werden müssen. Die Laufzeit
wird dagegen kaum erhöht.
Man kann sich leicht unterschiedliche Einsatzbereiche
für jede Form der Berechnungstransformation vorstellen.
Im Folgenden werden dazu mehrere Umsetzungen präsentiert.
Verwendung opaker Konstrukte
Die Komplexität eines Programmteils steigt mit der Anzahl der in ihm enthaltenen Verzweigungen und Bedingungen. Mit Hilfe opaker Konstrukte ist es relativ einfach Transformationen zu entwerfen, die diese Eigenschaft ausnutzen.
Tabelleninterpretation
Hierbei handelt es sich um eine der effektivsten und
gleichzeitig auch am schwierigsten umzusetzenden
Transformationen. Bei der Tabelleninterpretation werden
Teile des Codes in Code einer anderen virtuellen Maschine übersetzt. Der Applikation muss dann ein Interpreter hinzugefügt werden, der die Ausführung des Codes zur Laufzeit übernimmt. Eine Applikation kann auch
mehrere unterschiedliche Interpreter enthalten, die jeweils für einen Teil des Codes verantwortlich sind. Diese
Transformation sollte nur für kleine Codeabschnitte verwendet werden, die ein hohes Maß an Schutz benötigen.
Es ist mit einer signifikanten Erhöhung der Laufzeit und
des Speicherbedarfs eines Programms zu rechnen.
So kann man zum Beispiel innerhalb eines Basisblocks
ein opakes Prädikat einfügen, welches den Block teilt
und immer zu true evaluiert. Der restliche Code des
ursprünglichen Blocks befindet sich danach auf dem
true-Pfad. Das Prädikat wird als irrelevanter Code bezeichnet, da es den Ablauf des Programms nie ändert.
Der im false-Pfad enthaltene Code wird nur mit der
Absicht erzeugt, den Angreifer in die Irre zu führen. Es
kann sich dabei durchaus um Code handeln, der bei einem Test Fehler verursacht, da er ja im Anwendungsfall
nie zur Ausführung kommt. Man bezeichnet dies auch
als toten Code.
Um die Abbruchbedingung einer Schleife zu verschleiern, wird die Schleifenbedingung mit einem Prädikat so
ergänzt, dass sich die Anzahl der Schleifendurchläufe
nicht ändert. Das Beispiel 12 zeigt eine while Schleife,
deren Abbruchbedingung um den booleschen Ausdruck
(x³-x) % 3 == 0 erweitert wurde. Da dieses Prädikat immer zu true evaluiert, ändert sich der Ablauf der
Schleife nicht.
Code parallelisieren
int x = 0, counter = 0;
Zur Verschleierung des Kontrollflusses existieren zwei
Varianten. Die erste Möglichkeit besteht darin einen
oder mehrere Attrappen-Threads zu erzeugen, die Code
enthalten, der allein zur Täuschung dient. Bei der zweiten Variante wird ein ursprünglich sequentieller Bereich
des Programms in mehrere Abschnitte aufgeteilt, die parallel jeweils in einem eigenen Thread ausgeführt werden.
Ein Bereich ohne Datenabhängigkeiten ist sehr leicht zu
parallelisieren, sind jedoch Abhängigkeiten vorhanden,
muss beim Aufspalten des Bereichs auf die Synchronisation der Threads geachtet werden. Der Code wird dann
auch nach der Transformation sequentiell ausgeführt,
aber der Kontrollfluss wechselt von einem Thread zum
nächsten.
Parallelisieren von Code eignet sich hervorragend zum
Verschleiern von Programmabläufen. Die Transformation bietet einen guten Schutz vor statischen Analysen,
denn die Anzahl der möglichen Ausführungspfade steigt
exponentiell mit der Anzahl der auszuführenden Prozesse. Zudem ist das Verstehen von parallelem Code wesentlich schwieriger als das von sequentiellem Code.
while (x < 50 && (x * x * x - x) % 3 == 0)
{
counter += x;
x++;
}
Beispiel 12: Erweiterte Schleifenbedingung
Arithmetische Ausdrücke lassen sich durch Hinzufügen
überflüssiger Operanden verschleiern. Am Besten funktioniert dieser Vorgang mit Integer-Berechnungen, da
hier nicht auf numerische Genauigkeit geachtet werden
muss. Ziel dieser Transformation ist es, konstante Werte
durch Berechnungen darzustellen oder zusätzliche Berechnungsschritte in arithmetische Ausdrücke einzufügen, die das Ergebnis nicht verändern.
8/15
3.3 Datentransformationen
Statische in prozedurale Daten konvertieren
In diesem Abschnitt beschreiben wir Transformationen,
die entworfen wurden, um im Quellprogramm enthaltene
Datenstrukturen zu verschleiern. Unterschieden wird hier
zwischen Transformationen, welche die Speicherung,
Codierung, Aggregation oder Ordnung der Daten beeinflussen.
Statische Daten, wie zum Beispiel Strings, liefern dem
Angreifer nützliche Hinweise über die Funktion einer
Methode. Eine einfache Möglichkeit, um einen String zu
verbergen, besteht darin, eine Methode zu erstellen, die
den String produziert. Damit steht der Inhalt des Strings
erst zur Laufzeit zur Verfügung und ist nicht direkt im
Code einzusehen. Es ist allerdings nicht sinnvoll, die Erzeugung des Strings in einer Methode zu kapseln. Stattdessen kann der Code aber in kleine Komponenten aufgeteilt und dann im Kontrollfluss des Programms verteilt
werden. Damit wird er wesentlich schwieriger zu durchschauen.
3.3.1 Speicherungs- und Codierungstransformationen
Für die meisten Daten existieren bereits (Grund-) Typen,
um die entsprechenden Werte aufzunehmen. Beispielsweise werden die meisten Programmierer für die Zählvariable einer Schleife einen Integertyp verwenden. Zwar
können auch andere Typen verwendet werden, aber diese
Möglichkeit wird kaum genutzt, da ein Integertyp für
diese Aufgabe die logische Wahl ist. Ebenso ist mit einem Variablentyp auch immer eine bestimmte Interpretation des Bitmusters verbunden. Ein 8 Bit Integer mit
dem Bitmuster 00001001 wird für gewöhnlich die Zahl 9
darstellen.
Stringverschlüsselung ist eine weitere Variante, um den
Inhalt von Zeichenketten zu verbergen. Grundsätzlich
bietet das Verschlüsseln von Strings jedoch weniger
Schutz, als die oben vorgestellte Konvertierung, denn
um die Strings zur Laufzeit zu entschlüsseln, muss eine
entsprechende Methode im Code vorhanden sein, die immer dann verwendet wird, wenn ein String benötigt wird.
Die Entschlüsselungmethode ist dadurch für einen Angreifer sehr leicht zu identifizieren und kann sofort benutzt werden, um die im Code enthaltenen Strings zu enschlüsseln.
Um Daten zu verschleiern, wählen Speicherungstransformationen unübliche Typen, um dynamische oder statische Daten aufzunehmen und Codierungstransformationen wählen unübliche Codierungen für bestehende Datentypen.
3.3.2 Aggregationstransformationen
In objektorientierten Programmen werden Kontrollfunktionen um Datenstrukturen organisiert. Eine wichtige
Aufgabe des Reverse Engineering besteht daher darin,
die ursprüngliche Datenstruktur eines Programms zu
rekonstruieren. Es ist also notwendig, auch
Datenstrukturen zu verschleiern.
Codierung ändern
Die Codierung einer Variable kann durch einen arithmetischen Ausdruck transformiert werden. Eine Variable a
wird beispielsweise unter Verwendung der Gleichung a'
= a * b + c in ihre neue Form a' transformiert, wobei b
und c konstant sind. Bei dieser Art der Transformation
ist eine vorherige Analyse notwendig, um Überläufe
oder Rundungsfehler auszuschließen. Die Erhöhung der
Laufzeit und Sicherheit gehen bei dieser Transformation
Hand in Hand. Die oben genannte Beispieltransformation wird die Laufzeit nur unwesentlich beeinflussen, die
Codierung der Variable jedoch auch nicht sehr stark verschleiern.
Skalare Variablen verschmelzen
Zwei oder mehr skalare Variablen können in einer Variable mit größerer Reichweite gespeichert werden. Zum
Beispiel können zwei 32 Bit Integer Werte in einer 64
Bit Integer Variablen gespeichert werden. Eine Variante
dieser Transformation besteht darin, mehrere skalare Variablen in einem Array zu speichern und so den Eindruck
einer Datenstruktur zu erwecken, die eigentlich nicht
vorhanden ist.
Variablen spalten
Durch Aufspalten kann man eine Variable durch eine
Kombination von zwei oder mehr Variablen darstellen.
Um eine Variable V in k Variablen p1,...,pk aufzuspalten, werden drei Informationen benötigt. Eine Funktion
f(p1,..,pk), welche die Werte der k Variablen auf den
entsprechenden Wert von V abbildet, eine Funktion
g(V), welche den Wert von V auf die Variablen p1,..,pk
abbildet und neue Operationen auf p1,..,pk, welche den
auf V möglichen Operationen entsprechen. Je größer die
Anzahl der Variablen ist, auf die V abgebildet wird, um
so effektiver verschleiert diese Transformation die ursprüngliche Variable. Gleichzeitig steigen mit der Erhöhung der Anzahl, jedoch auch die von dieser Transformation verursachten Kosten bezüglich Laufzeit und
Speicherbedarf.
Arrays neu strukturieren
Arrays werden häufig eingesetzt um Daten zu aggregieren. Es gibt einige sehr einfache Transformationen, um
ihre Struktur zu verändern. Arrays können aufgespalten,
zusammengefügt, gefaltet (Erhöhung der Dimension)
oder abgeflacht (Verringerung der Dimension) werden.
Beispielsweise kann ein Array A in zwei Arrays A1 und
A2 aufgespalten werden, wobei A1 alle Elemente von A
mit geradem Index enthält und A2 alle Elemente von A
mit ungeradem Index. Auf den ersten Blick scheinen diese Transformationen wenig effektiv zu sein, weil die
Elemente nur umsortiert werden. Der eigentliche Nutzen
dieser Transformationen liegt jedoch im Verbergen der
Struktur und nicht ihrer Elemente.
9/15
Um beispielsweise eine Matrix zu speichern, ist ein
zweidimensionales Array die logische Wahl. Wird dieses
Array nun abgeflacht und damit in ein eindimensionales
Array verwandelt, ist es bereits wesentlich schwieriger,
die Matrix auch als solche zu erkennen. Die Anwendung
weiterer Arraytransformationen kann diesen Effekt noch
verstärken. Ebenso ist es natürlich möglich, durch Umstrukturieren eines Arrays den Eindruck einer Struktur
zu erwecken, die nie im ursprünglichen Code vorhanden
war. Beide Methoden eignen sich hervorragend, um Datenstrukturen zu verbergen.
Das in Beispiel 13 gezeigte zweidimensionale Array
wird in Beispiel 14 abgeflacht, indem alle Elemente
spaltenweise in das neue eindimensionale Array eingetragen werden. Unter den Abbildungen finden Sie jeweils den Code für eine einfache Matrix-Vektor Multiplikation. Die Vektoren b und c sind jeweils eindimensionale Arrays und werden nicht transformiert:
a1,0 a1,1 a1,2
a2,0 a2,1 a2,2
for (int i = 0; i < 3; i++)
for (int j = 0; j < 3; j++)
{
c[i] += a[i, j] * b[j];
}
Beispiel 13: ursprüngliches Array
a0,0 a1,0 a2,0 a0,1 a1,1 a2,1 a0,2 a1,2 a2,2
1
2
3
4
5
6
7
Wie bereits früher erwähnt, ist es sinnvoll, die Berechnungsreihenfolge so weit wie möglich zufällig anzuordnen. Dies gilt auch für die Anordnung von Methoden
und Instanzvariablen in Klassen, sowie von Parametern
in Methoden. In vielen Fällen ist es auch möglich, die
Elemente innerhalb eines Arrays neu zu ordnen.
3.4 Präventive Maßnahmen
Im Gegensatz zu Kontroll- und Datentransformationen
liegt die Hauptaufgabe von präventiven Maßnahmen
nicht darin, das Programm in eine für Menschen möglichst schwer verständliche Form zu überführen. Vielmehr liegt ihr Zweck darin, bereits bekannte automatische Deobfuscatortechniken zu erschweren oder Fehler
in bekannten Deobfuscatoren oder Decompilern auszunutzen.
Inhärente präventive Maßnahmen werden vor allem eingesetzt, um die Widerstandsfähigkeit bereits angewendeter Transformationen gegen automatische Angriffe zu erhöhen. Nehmen wir beispielsweise an, eine Schleife
wurde nach vorheriger Datenanalyse so umgeordnet,
dass sie nun rückwärts läuft. Ein automatischer Deobfuscator kann nun ebenfalls eine Datenanalyse ausführen,
feststellen, dass keine Datenabhängigkeiten vorhanden
sind und die Transformation rückgängig machen. Um
das zu verhindern, werden nach der Schleifentransformation gefälschte Datenabhängigkeiten in die Schleife eingebettet. Der Deobfuscator ist nun nicht mehr ohne weiteres in der Lage, die Transformation zu erkennen und
umzukehren. Der Schutz, den inhärente präventive Maßnahmen bereitstellen, addiert sich also immer zu einer
bereits bestehenden Transformation.
a0,0 a0,1 a0,2
Neuer Index: 0
3.3.3 Ordungstransformationen
8
for (int i = 0; i < 9; i++)
{
c[i%3] += a[i] * b[i/3];
}
Beispiel 14: Arraytransformation
Vererbungsbeziehungen modifizieren
Das Klassenkonzept in objektorientierten Programmiersprachen ist das wichtigste Mittel zur Modularisierung
und Abstraktion. Zwei Klassen A und B können auf zwei
unterschiedliche Arten miteinander in Verbindung stehen. Entweder A aggregiert B, enthält also eine Instanzvariable vom Typ B, oder A erbt von B, A erweitert also
die Funktionalität von B. Die Komplexität einer Klasse
wächst mit ihrer Tiefe, der Entfernung zur Wurzel der
Vererbungshierarchie, und der Anzahl ihrer direkten
Nachkommen. Es gibt im Wesentlichen zwei Wege um
die Komplexität einer Klasse zu erhöhen, das Aufspalten
von Klassen und das Einfügen von neuen gefälschten
Klassen. Im Normalfall werden diese beiden Techniken
kombiniert eingesetzt, denn es ist zum Beispiel nicht
schwierig, aufgespaltene Klassen wieder zusammenzufügen.
Gerichtete präventive Maßnahmen zielen darauf ab,
Schwächen in bekannten Dekompilern und Deobfuscatoren auszunutzen und so das Ausspionieren von Assemblies zu verhindern. Ein Beispiel dafür ist das Einfügen
einer Methode mit einem etwa 75 Kilobyte großen Bezeichner, die bei ILDASM zu einem Absturz führt [12].
Methodennamen dieser Länge sind im Quellcode nicht
erlaubt, weshalb die Methode erst nach dem Kompilieren
in die Assembly eingefügt werden kann. Die Methode
hat keine Funktion und kann im normalen Programmablauf auch nicht aufgerufen werden. Wird die Assembly
jedoch mittels Reflection von ILDASM untersucht, verursacht der Name der Methode einen Pufferüberlauf und
dies führt zum Abbruch des Deassemblierers.
4 Bewertung
In diesem Abschnitt stellen wir zunächst einige formale
Kriterien vor, die von Collberg, Thomborson und Low in
[2] entworfen wurden und anhand derer die in Abschnitt
3 erläuterten Transformationen bewertet werden können.
Tabelle 1 bietet eine Übersicht der einzelnen Transformationen und ihrer Bewertungen nach den einzelnen
Kriterien. Abschließend möchten wir noch auf einige allgemeine Punkte hinweisen, die Sie bei der Anschaffung
eines Obfuscators in Betracht ziehen sollten.
10/15
4.1 Kriterien zur Bewertung von Transformationen
Die Gesamtqualität einer Transformation ergibt sich
dann aus der Kombination dieser Werte.
Das Prädikat "einweg" nimmt eine gesonderte Stellung
ein. Transformationen, die als "einweg" gekennzeichnet
sind, können nicht rückgängig gemacht werden. Der
Grund hierfür liegt im Allgemeinen in dem Entfernen
von Informationen aus dem Programm, die zum Zeitpunkt der Erstellung des Programms sehr hilfreich
waren, aber für die korrekte Ausführung nicht benötigt
werden. Die in der Tabelle aufgeführten Transformationen besitzen schwache (+) oder starke (+ + ) Widerstandsfähigkeit oder sie sind als einweg (+ + +) klassifiziert. Transformationen mit trivialer oder vollständiger
Widerstandsfähigkeit sind in diesem Papier nicht
enthalten.
Wirkung
Kosten
Die Wirkung einer Transformation ist ein Maß dafür,
wie schwer es für einen menschlichen Angreifer ist den
Code zu verstehen. Dieses Kriterium lässt sich natürlich
nicht mathematisch präzise definieren, da die Wirkung
auch immer von den Fähigkeiten der Person abhängt, die
den Angriff ausführt. Allerdings hat die Komplexität von
Code einen großen Einfluss darauf, wie leicht ein Programm verstanden werden kann.
Die Kosten einer Transformation setzen sich aus dem erhöhten Speicherbedarf und der Erhöhung der Laufzeit
zusammen, welche die jeweilige Transformation durch
ihre Anwendung verursacht. Einige triviale Transformationen sind kostenfrei, die meisten Transformationen
sind jedoch mit einer variablen Menge an Kosten
verbunden. Zu beachten ist auch, dass Kosten
kontextsensitiv sind. Eine Transformation, die auf Code
innerhalb einer Schleife angewendet wird, hat natürlich
höhere Kosten als dieselbe Transformation, angewendet
auf Code, der nur einmal ausgeführt wird.
Verschleiernde Transformationen können nach vier Kriterien bewertet werden:
●
Wirkung
●
Widerstandsfähigkeit
●
Kosten
●
Heimlichkeit
Um die Wirkung zu messen, können Metriken aus der
Softwaretechnik hinzugezogen werden, die entwickelt
wurden um die Komplexität von Code zu bestimmen.
Diese Metriken basieren auf statischen Analysen von
Quellcode und benennen Eigenschaften des Codes, die
einen Einfluss auf dessen Komplexität haben (Anzahl
der Anweisungen und Prädikate, Verschachtelungstiefe
von if-Anweisungen, Tiefe und Breite des Vererbungsbaums, ...).
Die Wirkung einer Transformation ergibt sich aus der
Erhöhung einer oder mehrerer dieser Eigenschaften. In
der Tabelle unterscheiden wir nach niedriger (+), mittlerer (+ +) und hoher (+ + +) Wirkung einer Transformation.
Widerstandsfähigkeit
Auf den ersten Blick scheint es relativ einfach zu sein,
die Wirkung einer Transformation zu erhöhen. Beispielsweise könnten immer zusätzliche if-Anweisungen mit
konstanten Bedingungen eingefügt werden. Eine solche
Maßnahme ist allerdings von einem automatischen
Deobfuscator leicht rückgängig zu machen. Die Widerstandsfähigkeit setzt sich aus Programmieraufwand und
Deobfuscatoraufwand zusammen und misst, wie viel
Widerstand eine Transformation einem automatischen
Deobfuscator liefern kann.
Der Programmieraufwand bezeichnet dabei den Aufwand, der benötigt wird, um einen automatischen Deobfuscator zu konstruieren, der in der Lage ist, die Wirkung einer Transformation zu verringern. Der Deobfuscatoraufwand bezeichnet die Zeit, die von diesem automatischen Deobfuscator aufgewendet werden muss, um
die Wirkung einer Transformation zu verringern.
Die Einteilung der Kosten erfolgt nach vier Stufen. Der
Aufwand bezeichnet hier jeweils den Mehraufwand an
Ressourcen (Rechenzeit, Speicherbedarf), der durch die
Anwendung der Transformation an der entsprechenden
Stelle im Programm entsteht. Kostenfreie Transformationen verursachen keinen oder nur konstanten O(1)
Aufwand, günstige Transformationen verursachen eine
lineare O(n) Erhöhung des Aufwands und teure Transformationen führen zu einer polynomiellen Erhöhung
des Aufwands. Aufwendige Transformationen erzeugen
eine exponentielle Erhöhung des Aufwands.
Für die Darstellung der Bewertung wird in der Tabelle
ein Minuszeichen verwendet, da Kosten ein Negativkriterium darstellen. Für die vorgestellten Transformationen
reichen die Kosten von frei (-) über günstig (- -) bis teuer
( - - -).
Heimlichkeit
Transformationen, die eine hohe Widerstandsfähigkeit
besitzen, werden zwar von automatischen Deobfuscatoren nicht leicht erkannt, dies muss jedoch nicht für einen
menschlichen Angreifer gelten. Wenn eine Transformation Code einführt, der sich sehr von dem umgebenden
Code unterscheidet, so ist dies für einen Reverse Engineer leicht zu erkennen. Heimlichkeit ist ein Maß dafür,
wie gut sich der verschleierte Code mit dem ursprünglichen Code mischt bzw. ihn ersetzt. Natürlich ist dieses
Kriterium hochgradig kontextsensitiv. Es lässt sich demzufolge nur im tatsächlichen Anwendungsfall einer
Transformation feststellen, ob der erzeugte Code heimlich ist oder nicht.
Die Bewertung der Widerstandsfähigkeit erfolgt in den
Stufen trivial, schwach, stark, vollständig und einweg.
11/15
Obfuscation
Ziel
Kriterien
Transformation
Wirkung
Widerstand
sfähigkeit
Kosten
++
+++
-
Layout
Bezeichner umbenennen
Kontrollfluss
Inlining
1
++
+++
-
Outlining
1
++
++
-
Methoden verschachteln
1
Methoden klonen
1
Schleifentransformationen
1
+
+
-/--
Ordnungstransformationen
2
+
+++
---
Einfügen von totem oder
irrelevantem Code
3
Erweitern von
Schleifenbedingungen
3
Überflüssige Operanden
3
Tabelleninterpretation
3
+++
++
---
Entfernen von
Bibliotheksaufrufen
3
++
++
variabel
Code parallelisieren
3
+++
++
---
Codierung ändern
4
Hängt von der Komplexität der
Codierungsfunktion ab.
Variablen spalten
4
Hängt von der Anzahl der Variablen ab, in
welche die ursprüngliche Variable
aufgespalten wird
statische in prozedurale
Daten Konvertieren
4
Hängt von der Komplexität der
generierten Funktion ab.
skalare Variablen
verschmelzen
1
+
+
-
Arrays neu strukturieren
1
variabel
+
-/--
Vererbungsbeziehungen
modifizieren
1
++
+
-
Ordnungstransformationen
2
+
+/+++
-
Daten
Hängt von der Qualität der verwendeten
opaken Konstrukte ab
Hängt von der Qualität der verwendeten
opaken Konstrukte ab und von der
Schachtelungstiefe, in der die
Transformation eingefügt wurde.
Tabelle 1:Obfusatingtransformationen und Bewertungen
12/15
In Tabelle 1 sind alle in diesem Papier präsentierten
Transformationen zusammen mit ihrer jeweiligen Bewertung nach den Kriterien Wirkung, Widerstandsfähigkeit und Kosten aufgeführt. Die Transformationen sind
nach ihren Zielbereichen Layout, Kontrollfluss und Daten gruppiert. Die Zahl hinter der jeweiligen Transformation gibt an, welcher Unterkategorie sie angehört. Aggregationstransformationen sind mit einer 1 gekennzeichnet,
Ordnungstransformationen mit einer 2, Berechnungstransformationen mit einer 3 und Speicherungs- und
Codierungstransformationen mit einer 4.
4.2 Allgemeine Kriterien
Nachfolgend finden Sie einige allgemeine Kriterien, die
beim Kauf eines Obfuscators in Betracht gezogen werden können. Auch wenn diese Punkte prinzipiell auf jede
Art von Software zutreffen, heißt dies keineswegs, dass
sie bei der Anschaffung eines Obfuscators vernachlässigbar sind.
Die beste Möglichkeit, um herauszufinden, ob ein Produkt für die eigenen Zwecke geeignet ist, besteht darin
es selbst zu testen. Gerade bei Obfuscatoren ist dies besonders wichtig, denn kein Hersteller wird detailliert erklären, welche Transformationen in seinem Produkt nach
welchen Regeln angewendet werden (dies wäre in Hinblick auf die Aufgabe des Obfuscators auch nicht sehr
sinnvoll). Sie sollten darauf achten, ob für ein gegebenes
Programm Testversionen zur Verfügung stehen und welchen Einschränkungen diese Software unterliegt. Wie
lange kann getestet werden? Welche Funktionen sind in
der Testversion enthalten und welche nicht? Ist mit den
gegebenen Einschränkungen überhaupt ein aussagekräftiger Test möglich?
Eine gute Dokumentation ist nicht immer selbstverständlich oder überhaupt verfügbar. Sie sollten sich
informieren, ob und in welcher Form (Handbuch, pdf,
Visual Studio Hilfe) das Produkt dokumentiert ist. Im
optimalen Fall können Sie die Dokumentation zumindest
teilweise schon vor dem Kauf des Produktes einsehen.
Auch die Verfügbarkeit von Supportleistungen ist ein
nicht zu unterschätzendes Kriterium. Üblicherweise wird
Support in Form von E-Mail, per Telefon, oder über ein
Online Forum angeboten. Wichtig ist hier auch, ob der
Support bereits für Testversionen zur Verfügung steht
und ob oder in welcher Form Support in einer Lizenz
enthalten ist. Sind Supportleistungen mit zusätzlichen
Kosten verbunden oder zeitlich nur begrenzt nutzbar?
Existieren unterschiedliche Abstufungen, je nach erworbener Lizenz?
Ist der Obfuscator aus einem Freeware- oder Open Source Projekt hervorgegangen, lohnt sich die Frage, ob das
Projekt noch aktiv weiterentwickelt wird. Sind Dokumentation und Support überhaupt verfügbar? Ist es eventuell lohnenswert den Obfuscator selbst zu erweitern (sofern erlaubt)?
Bei kommerzieller Software besteht die Möglichkeit,
sich genauer über den Hersteller zu informieren. Hat sich
die Firma auf den Bereich Softwaresicherheit spezialisiert und wie lange ist sie schon in diesem Bereich tätig?
Sind Lizenzen für Ihren Bedarf verfügbar? Gibt es ande-
re Produkte des Herstellers, die für Sie von Interesse sein
könnten, oder ist für den Betrieb des Obfuscators ein anderes Produkt des Herstellers nötig?
5 Marktübersicht
Im folgenden Abschnitt finden Sie eine Zusammenstellung momentan erhältlicher Obfuscatoren. Dies stellt jedoch keine komplette Auflistung aller verfügbaren Programme dar. Die Programme wurden im Rahmen dieses
Papiers nicht getestet und die Beschreibungen sind auch
in keiner Weise wertend. Wenn Sie sich näher für eines
der genannten Produkte interessieren, sollten Sie daher
keinesfalls auf eigene Tests verzichten.
Aspose.Obfuscator [13]
Version: 1.6
Lizenz: Freeware
Aspose.Obfuscator unterstützt die Sprachen C#, Visual
Basic.NET und JScript.NET. Das Programm benennt
private und internal deklarierte Mitglieder mittels eines
alphanumerischen Schemas um. Falls möglich werden
Methoden überladen. Das Umbenennen von als public
gekennzeichneten Mitgliedern ist nicht möglich, jedoch
können Mitglieder auf Wunsch von der Umbenennung
ausgeschlossen werden. Der Obfuscator ist Freeware und
wird von Aspose nicht mehr weiterentwickelt. Support
und Dokumentation sind über das Forum von Aspose
verfügbar.
Demeanor for .NET [14]
Version: 4.0
Lizenz: pro CPU; Enterprise Edition, $799
Demeanor operiert direkt auf .NET Assemblys ohne
Umwege über Round Tripping Verfahren zu verwenden.
Zu den Features zählen das Verschleiern von Namen,
Verschlüsseln von Strings und Umordnen von Assemblies. Auch das Verschleiern von verwendeten Ressourcen (sofern sie managed Code verwenden) und generische Methoden und Typen werden unterstützt. Demeanor kann über die Kommandozeile, per Visual Studio
Add-in oder über die standalone GUI gesteuert werden.
Über Eigenschaften lässt sich das Verhalten des Obfuscators für jede Assembly separat einstellen. So können
beispielsweise automatisch auch als public gekennzeichnete Mitglieder umbenannt werden, wenn es sich bei der
zu erstellenden Assembly um eine .exe Datei handelt.
Die an Assemblys vorgenommen Änderungen können in
einer XML-Datei protokolliert werden, dies ermöglicht
das inkrementelle Verscheiern von Assemblys. Für
Testzwecke kann eine auf zwei Wochen beschränkte
Testversion des Obfuscators bezogen werden. Support
wird per E-Mail und Telefon angeboten.
13/15
Dotfuscator [15]
Version: 3.0
Lizenz: Community Edition, - ; Professional Edition,
$1890 (1 Benutzer); Network Edition, $4950 (1 - 5 Benutzer)
Die Community Edition des Dotfuscators ist bereits in
Visual Studio enthalten, bietet jedoch im Vergleich zur
Professional Edition nur einen sehr begrenzten Funktionsumfang. Eine detaillierte Übersicht über die Unterschiede zwischen den einzelnen Editionen ist auf der Homepage von preemtive verfügbar. Zu den Features zählen das Umbenennen von Mitgliedern, Kontrollflussverschleierung, Stringverschlüsselung und das Überladen
von Methoden. Zusätzlich können Applikationen, die aus
mehreren Assemblys bestehen, zu einer einzigen Assembly verbunden werden. Die Auswahl der Mitglieder,
die verschleiert werden sollen, erfolgt über Regeln und
Attribute, das .NET Framework 2.0 wird vollständig unterstützt. Für inkrementelle Verschleierungen und verbesserte Fehleranalyse werden XML-Dateien generiert.
Dotfuscator ist über eine standalone GUI, Visual Studio,
die Kommandozeile oder einen MS Build Task ausführbar. Registrierte Benutzer erhalten für ein Jahr Zugang
zu gesonderten Supportseiten. Erweiterte Supportverträge werden zum Verkauf angeboten.
Salamander .NET Obfuscator [16]
die Konsole. Die Integration in Visual Studio ist mittels
einer optionalen Erweiterung möglich. Der Obfuscator
benennt Mitglieder wahlweise nach einem eigenen Algorithmus um oder nach einer durch den Benutzer bereitgestellten Tabelle. Die Umbenennungen können auch über
das User Interface oder Attribute im Code kontrolliert
werden.
IL-Obfuscator 2.0 [18]
Version: 2.0 Beta 7
Lizenz: $79, DotNet-Lab
Der IL-Obfuscator ist Bestandteil des Lesser-Software
DotNet-Lab, das unter anderem auch einen ReflectionBrowser und Decompiler für C# und VB.NET enthält.
Der Obfuscator arbeitet direkt auf Assemblys und unterstützt das Umbenennen von Mitgliedern, Kontrollflussverschleierung und Stringverschlüsselung. Bei Programmen, die aus mehreren Assemblys bestehen, wird auch
das Umbenennen von internal Mitgliedern unterstützt.
Auch ein Schutz gegen das Decompilieren mit ILDASM
ist enthalten. Die Auswahl der zu verschleiernden Mitglieder erfolgt über die GUI. DotNet-Lab wird zum
Download auf der Lesser-Software Homepage angeboten und ist ohne Registrierung nur mit eingeschränkter
Funktionalität nutzbar.
6 Fazit
Version: 2.0
Lizenz: $799 (1-5 Benutzer), $1399 (6-10 Benutzer)
Der Obfuscator wird entweder über eine standalone GUI
oder die Kommandozeile bedient. Im GUI Modus ist zusätzlich ein Explorer für .NET Applikationen enthalten,
der zusätzlich auch als Decompiler verwendet werden
kann. Das Programm arbeitet direkt auf bereits kompilierten Assemblys und kann auch Applikationen verschleiern, die für das Compact Framework erstellt wurden. Die Einstellungen für die jeweilige Applikation
werden in XML Dateien gespeichert, die Konfiguration
durch Attribute ist jedoch ebenfalls möglich. Satellitenund Ressourcenassemblys werden automatisch verschleiert. Das Handbuch behandelt auch Fälle, bei denen
Probleme auftreten können, wie beispielsweise Reflection oder Serialisation und zeigt anhand von Beispielen,
wie Probleme in diesen Bereichen umgangen werden
können. Eine Testversion mit vollem Funktionsumfang
ist verfügbar. Eine Lizenz enthält ein Jahr kostenlosen
Online Support und Upgrades.
Spices.Obfuscator [17]
Version: 5.1.04
Lizenz: $692.95 (1 Benutzer); Team Pack $2192.95 (4 5 Computer)
Auch der Spices Obfuscator arbeitet direkt mit Assemblys und unterstützt die Frameworks 1.0 – 2.0, das Compact Framework und managed C++ Code. Gesteuert wird
der Obfuscator entweder über eine graphische Shell oder
In diesem Übersichtspapier wird gezeigt, dass Programme in .NET sehr leicht mit Methoden des Reverse Engineering angegriffen werden können und Schutzmaßnahmen nötig sind. Dieser Schutz kann durch Obfuscatoren
und die von ihnen verwendeten Transformationen bereit
gestellt werden. Es werden die unterschiedlichen Kategorien von Obfuscatingtransformationen erläutert und es
stellt mehrere Transformationen aus den jeweiligen
Kategorien vor. Mit den Kriterien wird ein Bewertungssystem eingeführt, das es ermöglicht, die Transformationen hinsichtlich ihrer Effektivität und Kosten zu
bemessen, und es wird deutlich gemacht, dass der Schutz
eines Programms mittels Obfuscation immer einen Kompromiss zwischen dem Grad des erreichten Schutzes und
dem Mehraufwand für die Programmausführung bedeutet. Abschließend bleibt zu erwähnen, dass Obfuscation,
ebenso wie Verschlüsselung, nur Schutz mit einer begrenzten Dauer bieten kann. Denn mit steigender Rechenleistung und Fortschritten im Bereich der automatischen Deobfuscation, wird ein einmal verschleiertes Programm leichter angreifbar.
Das Potential der Obfuscation ist zum momentanen Zeitpunkt jedoch keineswegs ausgeschöpft. Die Entwicklung
völlig neuer Transformationsarten und die Variantenbildung bereits bekannter Techniken stellen nur eine Möglichkeit dar, die Fähigkeiten von Obfuscatoren zu erweitern. Auch ein besseres Verständnis der Zusammenhänge
zwischen Kosten und Wirkung/Widerstandsfähigkeit einer Transformation, oder die Optimierung der Kombination einzelner Transformationen bieten viel Raum für
Verbesserungen.
14/15
Interessant ist auch, dass sich mit dem Einsatz von Obfuscatoren auch andere Schutzfunktionen, wie beispielsweise, Wasserzeichen implementieren lassen. Es ist
möglich, etwa über das Einfügen von totem Code, Wasserzeichen in einem Programm zu verstecken. Diese
Wasserzeichen können dann benutzt werden, um den
Diebstahl eines Algorithmus zweifelsfrei nachzuweisen
oder die Herkunft von Raubkopien zu bestimmen.
[4] Gabriel Torok, Bill Leach: "Obfuscate It: Thwart
Reverse Engineering of Your Visual Basic .NET or
C# Code", MSDN® Magazine,
http://msdn.microsoft.com/msdnmag/issues/03/11/
NETCodeObfuscation, Zugriff am 26.09.06
[5] Brian Long: "Reverse Engineering To Learn .NET
Better",
http://www.blong.com/Conferences/DCon2003/
ReverseEngineering/ReverseEngineering.htm,
Zugriff am 26.09.06
Glossar
[6] "Code protection - Obfuscation", madgeek
SharpToolbox, http://sharptoolbox.com/categories/
code-protectors-obfuscators, Zugriff am 05.10.06
Basisblock:
Eine Folge von Anweisungen, die in ihrer Mitte keine
Sprünge oder Sprungziele enthält. Als Sprungziel ist nur
der Anfang eines Basisblocks erlaubt und ein Sprung aus
dem Basisblock darf nur an dessen Ende stehen.
[7] Sonali Gupta: "Code Obfuscation", Palisade,
http://palisade.plynt.com/issues/2005Aug/codeobfuscation/, Zugriff am 10.10.06
Reflection:
[8] Sonali Gupta: "Code Obfuscation - Part 2:
Obfuscating Data Structures", Palisade,
http://palisade.plynt.com/issues/2005Sep/codeobfuscation-continued/, Zugriff am 10.10.06
Ein Prozess, der es unter anderem ermöglicht die Metadaten einer Anwendung abzufragen. Mit Hilfe von Reflection können Anwendungen zur Laufzeit auch Erkenntnisse über ihre eigene Struktur gewinnen.
[9] Sonali Gupta: "Code Obfuscation Part 3 - Hiding
Control Flows", Palisade,
http://palisade.plynt.com/issues/2005Oct/hidingcontrol-flows/, Zugriff am 10.10.06
Reverse Engineering:
Bezeichnet in der Softwaretechnik die Rückgewinnung
des Quellcodes von einem ausführbaren Programm oder
einer Programmbibliothek. Die üblichen Werkzeuge sind
Dekompiler und Disassembler.
Round Tripping:
Ein Verfahren, um bereits kompilierte Assemblys zu verändern. Zuerst wird die Assembly mittels eines Disassemblers in IL Quellcodes umgewandelt. Der so entstandene Quellcode kann editiert und danach wieder in ein
ausführbares Programm zurückübersetzt werden.
Satellitenassembly:
Satellitenassemblys enthalten Informationen, die zur Lokalisierung eines Programms in eine andere Sprache benötigt werden. Sie enthalten keinen ausführbaren Code
und sind immer der Assembly zugeordnet, die die Informationen benötigt.
Literaturverzeichnis
[1] Christian Collberg, Clark Thomborson, Douglas
Low: "Manufactoring Cheap, Resilient, and
Stealthy Opaque Construkts", Department of
Computer Sience, The University of Auckland,
Januar 1998
[2] Christian Collberg, Clark Thomborson, Douglas
Low: "A Taxonomy of Obfuscating
Transformations", Technical Report #148,
Department of Computer Sience, The University of
Auckland, Juli 1997
[3] Andrew Binstock: "Obfuscation: Cloaking your
Code from Prying Eyes", Destination.NET,
http://www.devx.com/microsoftISV/Article/11351,
Zugriff am 26.09.06
[10] Mike Gunderloy: "How-To-Select an
Obfuscation Tool for .NET™", How-ToSelect™-Guides,
http://www.howtoselectguides.com/dotnet/
obfuscators/#sc_obfuscators, Zugriff am 09.11.06
[11] Lutz Roeder: Lutz Roeder's Programming.NET,
http://www.aisto.com/roeder/dotnet/, Zugriff am
02.10.06
[12] OWASP: http://www.owasp.org/index.php/
Buffer_OverFlow_in_ILASM_and_ILDASM
Zugriff am 27.10.06
[13] Aspose: Aspose.Obfuscator,
http://www.aspose.com/Products/
Aspose.Obfuscator/, Zugriff am 09.11.06
[14] Wiseowl: Demeanor for .NET:
http://www.wiseowl.com/products/products.aspx,
Zugriff am 09.11.06
[15] Preemtive: Dotfuscator,
http://www.preemptive.com/products/dotfuscator/
index.html, Zugriff am 09.11.06
[16] Remotesoft: Salamander.NET Obfuscator,
http://www.remotesoft.com/salamander/
obfuscator.html, Zugriff am 09.11.06
[17] 9rays.net: Spices.Obfuscator,
http://www.9rays.net/products/Spices.Obfuscator/,
Zugriff am 09.11.06
[18] Lesser Software: IL-Obfuscator 2.0,
http://www.lesser-software.com/, Zugriff am
09.11.06
15/15