Decompiler - Der Stand der Technik im Jahr 2008

Inhaltsverzeichnis

Abbildungsverzeichnis

Kurzfassung

Begriffsdefinitionen

1 Einleitung

2 Allgem eines
2.1 Begriffsdefinition Decompiler
2.2 Abgrenzung zu Reverse Engineering / Disassembling:
2.3 Gründe für die Verwendung von Decompiling
2.4 Rechtliche Aspekte (Legalität)

3 Der Decompiling Prozess
3.1 Module
3.2Phasen

4 Probleme beim automatischen Decompiling
4.1 Halteproblem
4.2Idiom e

5 Überblick über ausgewählte Decompiler
5.1 Maschinensprache
5.2Assem blerCode
5.3Java Bytecode
5.4 .NET assembly, CIL Code
5.5 Skriptsprachen Perl und PHP
5.6 ParallelenundFolgerungen

6 Obfuscation: Schutz vor Decompiling

7 Zusammenfassung

Literaturverzeichnis

Abbildungsverzeichnis

Abbildung 1: Forward/Reverse Engineering

Abbildung 2: Beispiel für Syntaxbaum

Abbildung 3: Zwischencode-Erzeugung

Abbildung 4: Datenfluss-Analyse

Abbildung 5: Kontrollfluss-Analyse

Abbildung 6: exe-Datei

Abbildung 7: Vergleich Source Code vs. Dekompilat

Abbildung 8: Eclipse Plugin JAD Decompiler

Abbildung 9: Vergleich .NET-Decompiling

Kurzfassung

Die nachfolgende Arbeit soll ein en Überblick über den aktuellen Stand der Technik zum Them a Decom piling geben. Dazu wird zunächst de r Begrif f Decom piling gegenüber ähnlichen Begriffen abgegrenzt.

Nach einem Überblick über die Gründe für Decom piling und rechtlich en Aspekten wird der Decompiling-Prozess näher dargestellt und in einzelne Phasen unterteilt. E s wird erklärt welche Vorteile diese Einteilung in einzelne Phasen mit sich bringt.

Zur praktischen Veranschau lichung werden gängige D ecompiler-Tools für aktuell relevante Sprachen wie z.B. Java oder .NET vorgestellt. Die Ergebnisse dieser Tools werden mit dem originalen Source Code verglichen um ein Indiz für die Qualität der Tools zu liefern.

Weiters werden vorhandene theoretische Probleme aufgezeigt, die beim Decompiling auftreten können. Ein Überblick über Techniken zum Schutz vor Decompiling rundet diese Arbeit ab.

Begriffsdefinitionen

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1: Begriffsdefinitionen

1 Einleitung

In der folgenden Arbeit wird versucht ein Überblick über den aktuellen Stand der Technik zum Thema Decompiling zu geben.

Anfangs beschäftigt sich die Arbeit m it der Begriffsabgrenzung gegenüber Reverse Engineering undDisas sembling.Weiters werdendieG ründefürDecom piling behandelt und auf rechtliche Aspek te eingegangen, die beim Decom piling beachtet werden müssen.

Im weiteren Verlauf der Arbeit wird der Decompiling-Prozess in m ehrere Phasen eingeteilt. Die Aufgaben dieser Phas en werden näher erläutert. Darüber hinaus wird festgelegt welche Vorraussetzungen diese Phasen haben bzw. welche Ergebnisse diese liefern m üssen. W eiters wird begründet, warum es sinnvoll ist den Decompiling-Prozess derar t zu gliede rn.I m Anschluss werden verschied ene theoretische Problem e behandelt, die si ch beim Decompiling Prozess ergeben können.

Im nächste n Abschnitt dieser A rbeit wird näher untersucht, wie sehr sic h verschiedene Codearten dazu eign en D ecompiling zu unterstützen. Darüber hinaus werden verschiedene Möglichkeiten und T ools vorgestellt, m it denen sich diese Codearten dekompilieren lassen. Ein Vergleich des dekompilierten Source Codes mit dem originalen Source Code gibt Aufschluss über die Qualität dieser Tools.

Zum Abschluss werden Fakt oren für erfolgreiches Decom piling besprochen und die Möglichkeiten zum Schutz vor Decompiling beleuchtet.

2 Allgemeines

Der nachfolgende Abschnitt dient der ausreichenden Definition des Begriffs Decompiler und der Abgrenzun gegenüber Reverse Engineering und Disassembling. Weiters werden die Gründe für die Verwendung von Decompiling und rechtlich e Aspekte erläutert.

2.1 Begriffsdefinition Decompiler

Ein Decompiler ist ein Programm, das ein in Binärcode vorliegendes Programm liest und es in ein äquivalentes, in einer Hi gh-Level-Sprache gesc hriebenes Programm übersetzt. Es wird also versucht, den Prozess eines Compilers umzudrehen.^[1]

2.2 Abgrenzung zu Reverse Engineering / Disassembling:

Der BegriffReverse Engineering stamm t ursprünglich aus dem Maschinenbau und wurde in die Terminologie des Software Engineerings übernommen. Nach [Elliot et al. 1990 S. 13] ist Reverse Engineering ei n Prozess, der das betrachtete System analysiert, um seine Komponenten und ih re Beziehungen zu identifizieren. Zweck dieses Prozesses ist es, für das analysiert e System neue Abbildungen des System s zu schaffen, meist in and erer Form und auf höherer Abstrak tionsebene. Decom piling stellt also eine von vielen Ausprägungen des Oberbegriffs Reverse Engineering dar.

Bei Disassem bling handelt sich ebenfalls um eine Anwendung von Reverse Engineering. Auch hier dien t ein in Binärcode vorliegendes Programm al s "Ausgangspunkt". Ein Decom piler erze ugt daraus High-Level-Code, beim Disassembling hingegen wird der Code in eine für Menschen 1 esbarere Assembl er- sprache umgewandelt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Forward/Reverse Engineering2

Wie in der vorangegangenen Abbildung gut ersichtlich ist, endet das Decompiling im Rahmen des Reverse E ngineerings dort, wo die Abstraktion der Architektur hoch wird.

2.3 Gründe für die Verwendung von Decompiling

Es gibt eine Vielzahl an Problem eni m So ftware-Bereich, wo es wichtig ist, den Source Code aus einem Kompilát wiederherzustellen. Beispiele dafür sind^{[2] [3]}:

- Wiederherstellen verlorenen Source Codes
- Bugfixing eines kompilierten Frameworks bzw. einer Applikation
- Migration einer Anwendung auf eine neue Hardware-Plattform
- Verbesserung der Dokumentation einer Anwendung
- Analyse von fremden Code (auch Viren und Schadprogramme)
- Testen von Compilern, besseres Verständnis für die Compiler-Vorgänge^[4]

2.4 Rechtliche Aspekte (Legalität)

Die Legalität von Decompiling und von Reverse Engineering im Allgemeinen ist ein in den letzten Jahren rechtlich heftig diskutiertes Thema.

Viele Untemehm en untersagen explizit in den Lizenzbedingungen kommerzielle Software zu dekompilieren, sei es auch nur zu Studienzwecken oder um die Software für den Eigengebrauch zu verändern. Solche Lizenzklauseln sind jedoch in vielen Ländern generell ungültig, da den Nutzem ei ner Sache gesetzlich das Recht zusteht, zur Überprüfung der Anwendungssicherheit oder zur Fehlerbehebung Reverse Engineering an einer erworbenen Software durchzuführen.

So ist esz. B. in Deuts chland erlaubt, ein Programm zu dekom pilieren, soweit d ies notwendig ist, um die „Interoperabilität“ mit einem unabhängig vom ursprünglichen Programm geschaffenen Computerprogramm zu erhalten. Lizenzvereinbarungen, die dem widersprechen, sind laut dem "Ges etz über Urheberrecht und verwandte Schutzrechte" nichtig. Oftmals dienen so lche Lizenzklaus ein eher dem Zweck der Abschreckung und sind somit als einseitige W illensäußerung bzw. je nach Form als prophylaktische, einseitig vorgetragene Rechtsauffassung zu verstehen, die bei unabhängiger rechtlicher Pr üfung möglichem eise kein e Bestätigung und som it keinen weiteren Bestand haben wird.

Benutzt man das Ergebnis eines Reverse Engineering-Vorgangsjedoch zum gewerb­lichen Nachbau, so wird m an sich m it der großen Menge der gewerblichen Schutz­rechte (z. B. Plagiat) in ähnlicher Weise konfrontiert sehen. Häufig dient das Reverse Engineering der Produktpirate rie, wobei hier natürlic h nicht nur die Software­Branche betroffen ist.

Reverse Engineering von freien oder gar selb st verfassten P rogrammen ist natürlich injeder Hinsicht gesetzeskonform.

3 Der Decompiling Prozess

Ein Decompiler charakterisiert sich, ähnlich einem Compiler, durch mehrere Phasen. Diese werden schrittw eise durchlauf en und erzeugen, ausgehend von eine m Maschinencodejeweils ein um gewandeltes Äquivalent des ursprünglichen Codes. Das Ziel-Produkt ist letztendlich ist ein Programm in High-Level-Sprache, welches in seiner Funktion dem Quell-Programm entspricht.

3.1 Module

Die einzelnen Phasen eines Decompilers können in drei Module gruppiert werden:^[5]

Frontend

Das Frontend beginnt den Dekom pilierungsvorgang, in dem es den Maschinencode einliest. Es beinhaltet die syntaktische und semantische Analyse, die Z wischencode- Erzeugung sowie die E rstellung eines Contro 1 Flow Graph. All diese Phasen sind abhängig vonjener Maschine, auf der der ursprüngliche Maschinencode ausgeführt wurde. Am Ende dieses Moduls liegt eine Repräsentation des ursprünglichen Programms in einer Low-Level-Zwischensprache sowie ein Control Flow Graph vor.

Universal Decompiling Machine (UDM)

Dieses Modul ist sowohl von der ursprüngl ichen Maschine als auch von der zukünf­tigen High-Level-Sprache vollkom men unabhängig. Die D atenfluss- und Kontroll- fluss-Analyse bilden das Herzstück de s Dekompilierungsvorganges. Aus dem vom Frontend gelieferten Low-Level-Zwischencode sowie dem Control Flow Graph wi rd ein High-Level-Zwischencode erzeugt.

Backend

Das Backend erzeugt schließ lieh aus dem High-Level-Zwischencode einen Source Code in derjeweiligen Zielsprache. Es ist also sprachenabhängig.

Theoretisch bietet dieser Aufbau desD ecompiling-Prozesses die Möglichkeit, durch neue Frontends und Backends Decom piler für viele Maschinen und viele ver­schiedene High-Level-Zielsprachen zu erze ugen. In der Praxis sind diese Möglich- keitenjedochje nach Wahl der Zwischensprache verschieden stark limitiert.

[...]

^[1] vgl. [Cifuentes 1994]

^[2] Quelle: [VanEmmerik 2003]

^[3] vgl. [Van Emmerik 2003]

^[4] vgl. [Van Emmerik 2003]

^[5] vgl. [Cifuentes 1994 S. 12f]