Kapitel 8:
Architektur und
Vielfalt
Universität Mannheim
Software Reverse Engineering Lehrstuhl Praktische Informatik 1

Übersicht
8.1 •Zielsetzung
8.2 •Motivation
8.3 •Architekturen
8.4 •REIL
8.5 •Zusammenfassung
Universität Mannheim
2
Software Reverse Engineering Lehrstuhl Praktische Informatik 1

Architektur und
Vielfalt
8.1 Zielsetzung
Universität Mannheim
Software Reverse Engineering Lehrstuhl Praktische Informatik 1

8.1 Zielsetzung
Wir wollen uns ein Bild von
verschiedenen Architekturen und
deren Einsatzgebieten machen.
Wir wollen verstehen warum diese
Architektur-Vielfalt neue Ansätze und
Herangehensweisen für einen Reverse
Engineer erfordern.
Wir wollen einen möglichen Ansatz
näher Betrachten und die möglichen
Probleme dieses Ansatzes diskutieren.
Universität Mannheim
4
Software Reverse Engineering Lehrstuhl Praktische Informatik 1

Architektur und
Vielfalt
8.2 Motivation
Universität Mannheim
Software Reverse Engineering Lehrstuhl Praktische Informatik 1

8.2 Motivation
• Verschiedene Anwendungsgebiete
Unterschiedlichste • Unterschiedlichste Architekturen
Systeme • Mehrere mögliche Compiler
• Eingebettete Systeme, Server, PCs,..
• Consumer Elektronik, Spiele Konsolen,
Anwendungsgebiete Mobiltelefone, ..
• Bisherige Methoden sind
unzureichend
Herausforderung • Der Zeit und Kosten Faktor
unberechenbar
Universität Mannheim
6
Software Reverse Engineering Lehrstuhl Praktische Informatik 1

Architektur und
Vielfalt
8.3 Architekturen
Universität Mannheim
Software Reverse Engineering Lehrstuhl Praktische Informatik 1

8.3 Architekturen [I]
Name: ARM
Verwendung: Low Power Devices (Mobiltelefone, ..)
Architekturtyp: RISC 32Bit
Anzahl Register: 16 x 32Bit
Besonderheiten:
• Mehrere Instruktionssets (32Bit ARM, 16Bit THUMB, [32/16]Bit THUMB-2).
• Fast alle Instruktionen sind konditionell ausführbar.
• Unterschiedliche Stack Adressierungsverfahren (FA, FD, EA, ED).
• Arithmetische Instruktionen können ohne Laufzeitverlust den Barrel-Shifter
verwenden um Ihre Argumente zu „shiften“.
• Bei manchen ARM Cores ist das Ausführen von Java Code direkt auf der CPU
möglich.
Universität Mannheim
8
Software Reverse Engineering Lehrstuhl Praktische Informatik 1

8.3 Architekturen [II]
Name: x86-32/64
Verwendung: PCs und Server
Architekturtyp: CISC 32/64 Bit
Anzahl Register: 8 bei 32 Bit 16 bei 64 Bit;
Besonderheiten:
• Variable Length Instruction Set.
• Verschiedene Multimedia Extensions (MMX, SSEx, …).
• Virtualisierung in Hardware.
• Heute gebräuchliche CPUs diesen Typs Übersetzen das CISC Instruktionsset in
einen leichter parallelisierbaren Microcode.
Universität Mannheim
9
Software Reverse Engineering Lehrstuhl Praktische Informatik 1

8.3 Architekturen [III]
Name: MIPS
Verwendung: Router, Server, Low Power Devices
Architekturtyp: RISC 32/64 Bit
Anzahl Register: 32 x (32/64) Bit
Besonderheiten:
• Wird heute meist in eingebetteter Form für viele Cisco Router genutzt.
• Modelliert Flags als Exceptions.
• Besitzt einen „Branch Delay Slot“ welcher nach einer Return Anweisung
ausgeführt wird.
• Eine der im universitären Umfeld meist genutzte Architektur für Kompiler-Bau
Vorlesungen durch die „beste ausgestorbene Programmiersprache“
Universität Mannheim
10
Software Reverse Engineering Lehrstuhl Praktische Informatik 1

8.3 Architekturen [IV]
Name: SPARC / UltraSPARC / Niagara
Verwendung: High Performance Server
Architekturtyp: RISC 32/64 Bit
Anzahl Register: 32 (64Bit) visible / 128 Total
Besonderheiten:
• Nutzt einen Registershift Mechanismus um die Parameter Übergabe zwischen
Funktionen ohne Nutzung des Stacks zu realisieren.
• Hat wie die MIPS Architektur einen „branch delay Slot“.
Universität Mannheim
11
Software Reverse Engineering Lehrstuhl Praktische Informatik 1

8.3 Architekturen [V]
Name: PowerPC
Verwendung: Server, PC‘s, Gaming Consoles
Architekturtyp: RISC 32/64 Bit
Anzahl Register: 32
Besonderheiten:
• Zur Zeit die in den meisten Spiele-Konsolen verwendete Architektur (PS3,
XBOX, Wii) in Form von verschiedenen Implementierungen der Kernarchitektur.
• Unterstützt konditionelle Instruktionen für Moves.
• Unterstützt mehrere Endianess Modes für Instruktionen und Daten.
• Basiert auf der IBM POWER Architektur.
Universität Mannheim
12
Software Reverse Engineering Lehrstuhl Praktische Informatik 1

8.3 Architekturen [IV]
Name: AVR
Verwendung: Eingebettete Systeme,
Automobilsektor,
Architekturtyp: RISC 8 Bit
Anzahl Register: 32 8Bit Register
Besonderheiten:
• Die AT(xmega/mega/tiny/) Architektur wird meistens als eingebettetes System
eingesetzt.
• EEProm / SRAM / FlashSpeicher auf dem Chip.
• A/D Wandler und Timer, die direkt in C oder Assembler angesprochen werden
können.
• Direkte Unterstützung von verschiedenen Bussystemen wie z.B. CAN.
Universität Mannheim
13
Software Reverse Engineering Lehrstuhl Praktische Informatik 1

8.3 Zusammenfassung
1 • Mehr als eine Architektur ist Interessant
2 • Jede Architektur hat Ihre Besonderheiten
3 • Für die Analyse sind die Besonderheiten
enorm wichtig
• Gibt es trotz dieser Vielfältigkeit eine
4 Architektur unabhängige Möglichkeit der
Analyse ?
Universität Mannheim
14
Software Reverse Engineering Lehrstuhl Praktische Informatik 1

Architektur und
Vielfalt
8.4 REIL
Universität Mannheim
Software Reverse Engineering Lehrstuhl Praktische Informatik 1

Übersicht
8.4.1 •Zielsetzung
8.4.2 •Motivation
8.4.3 •Sprachdefinition
8.4.4 •Anwendungen
8.4.5 •Zusammenfassung
Universität Mannheim
16
Software Reverse Engineering Lehrstuhl Praktische Informatik 1

8.4.1 Zielsetzung
Wir wollen eine Methode kennenlernen,
welche uns viele von den gezeigten
Unterschieden abstrahiert.
Als Abstraktionsmethode werden wir eine
Metasprache einführen, die mit einem sehr
einfachen RISC Instruktionsset arbeitet.
Wir werden die Sprache und Instruktionen
beispielhaft anwenden.
Wir werden die Einschränkungen der
Sprache betrachten und mögliche
Erweiterungen diskutieren.
Universität Mannheim
17
Software Reverse Engineering Lehrstuhl Praktische Informatik 1

8.4.2 Motivation I
Verschiedene Architekturen
• Architekturelle Besonderheiten
• Mehr als ein Compiler
Steigende Komplexität
• Schwerer zu Analysieren
• Steigende Kosten
Anforderungen
• Architektur und Compiler unabhängig
• Einfach zu definierende Algorithmen
Universität Mannheim
18
Software Reverse Engineering Lehrstuhl Praktische Informatik 1

8.4.2 Motivation II
Offensive vs. Defensive
• Fehler finden wird schwieriger
• Die Defensive hat den Quellcode
• Die Defensive investiert in die Analyse von
Quellcode
Offensive Statische Analyse
• Tiefe geht vor Breite
• Ohne automatisierte Werkzeuge wird das Spiel
verloren
Universität Mannheim
19
Software Reverse Engineering Lehrstuhl Praktische Informatik 1

8.4.3 Sprachdefinition
Reverse Engineering Intermediate Language
Universität Mannheim
20
Software Reverse Engineering Lehrstuhl Praktische Informatik 1

8.4.3 Sprachdefinition [Übersicht]
Reverse Engineering Intermediate Language
Plattformunabhängige Metaassembler Sprache
Speziell für die statische Analyse von Binärcode entworfen
Kann aus nativem Assemblercode erzeugt werden
Bisher sind x86, PowerPC, ARM, MIPS unterstützt
REIL Algorithmen sind simpler als Native Algorithmen
Universität Mannheim
21
Software Reverse Engineering Lehrstuhl Praktische Informatik 1

8.4.3 Sprachdefinition [Übersicht]
So einfach wie Möglich (Syntaktisch / Semantisch)
Instruktionen teilen sich das gleiche Instruktionsformat
Sehr kleines Instruktionsset (17 Instruktionen)
Instruktionsset ist Seiteneffektfrei
Explizite Modellierung aller States des Prozessors (Flags)
1-zu-1 Abbildung zwischen nativem Code und REIL
Universität Mannheim
22
Software Reverse Engineering Lehrstuhl Praktische Informatik 1

8.4.3 Sprachdefinition [Instruktionen]
Format
• Einzigartige Adresse [0xAABBCCDD.XX]
• Simples Format [Adresse [Mnemonik (OP1, OP2, OP3), {Meta}]]
Effekt
• Mnemonik beschreibt Programmstatuseffekt exakt
Instruktionskategorien
• Arithmetik
• Bitweise
• Logische
• Datentransfer
• Weitere
Universität Mannheim
23
Software Reverse Engineering Lehrstuhl Praktische Informatik 1

8.4.3 Sprachdefinition [Instruktionen]
ADDR MNEMONIC OPERAND 1 OPERAND 2 OPERAND 3 META INFO
Instruktionen nutzen 0 bis 3 der möglichen Operanden
Metainformationen enkodieren zusätzliche Informationen
ADD
Daten Transfer
SUB
Arithmetik
AND LDM NOP
Boolesche
MUL BISZ
Logische
OR STM UNKN
Andere
DIV JCC
XOR STR UNDEF
MOD
BSH
Universität Mannheim
24
Software Reverse Engineering Lehrstuhl Praktische Informatik 1

8.4.3 Sprachdefinition [Instruktionen]
Alle Instruktionen sind gleich
add t0, t1, t2
Aber manche Instruktionen sind gleicher
and t0, t1, t2
bsh t0, t1, t2 bisz t0, , t2
div t0, t1, t2 jcc t0, , t2
mod t0, t1, t2 ldm t0, , t2
mul t0, t1, t2 nop , ,
or t0, t1, t2 stm t0, , t2
sub t0, t1, t2 str t0, , t2
xor t0, t1, t2 undef , , t2
unkn , ,
Universität Mannheim
25
Software Reverse Engineering Lehrstuhl Praktische Informatik 1

8.4.3 Sprachdefinition [Operanden]
Operanden sind typisiert
• Register
• Literal
• Unter-Adresse
Operanden haben eine Größe
• 1byte, 2bytes, 4bytes, …
Universität Mannheim
26
Software Reverse Engineering Lehrstuhl Praktische Informatik 1

8.4.3 Sprachdefinition [REIL VM]
Die REIL VM
• Beschreibt die Interaktion mit Registern und
Speicher
• ist eine Register Maschine ohne expliziten Stack
REIL Register
• sind unbegrenzt verfügbar (t0, t1, …, tn).
• sind instruktionslokal.
• sind beliebig groß.
Universität Mannheim
27
Software Reverse Engineering Lehrstuhl Praktische Informatik 1

8.4.3 Sprachdefinition [REIL VM]
REIL Speicher
• hat ein flaches Speicherlayout.
• ist theoretisch „unendlich“ groß.
• hat keine Alignement Anforderungen.
• hat die Endianess der analysierten Plattform.
Universität Mannheim
28
Software Reverse Engineering Lehrstuhl Praktische Informatik 1

8.4.3 Sprachdefinition [Übersetzung]
03F535B4 MOV R2, R1 03F535C4 STR LR, [SP,0x4]
3F535B400: str R1, , R2 3F535C400: add SP, 4, t1
3F535C401: and t1, 4294967295, t0
3F535C402: stm LR, , t0
03F7C394 LDREQH R3, word [R2,0x6]
3F7C39400: bisz Z, , t3
3F7C39401: jcc t3, , 66569108.5
3F7C39402: add R2, 6, t5
3F7C39402: ldm t5, , R3
3F7C39403: and t5, 0xFFFFFFFF, t4
3F7C39405: nop , ,
Universität Mannheim
29
Software Reverse Engineering Lehrstuhl Praktische Informatik 1

8.4.3 Sprachdefinition [Limitierung]
Übersetzung
• Nicht alle Instruktionen können übersetzt werden
• Floating Point Instruktionen
• MMX, SSE, Altivec
• Hardwarenahe Instruktionen SETEND, BKPT
• System Aufrufe
• Interrupts
System Charakteristiken
• Keine Unterstützung von Ausnahmen (Exceptions)
Fehler im Initialen Design
• Eine Instruktion hat sich als nicht ausgereift erwiesen
Universität Mannheim
30
Software Reverse Engineering Lehrstuhl Praktische Informatik 1

8.4.4 Anwendungen
• MonoREIL (Abstrakte Interpretation)
1 • Register Tracking
• Deobfuscator
2 • Typereconstruction
• Plattform unabhängiges „return-oriented
3 programming“
Universität Mannheim
31
Software Reverse Engineering Lehrstuhl Praktische Informatik 1

8.4.4 MonoREIL
Abstrakte Interpretation
• Theoretische Grundlage der meisten Code Analyse Methoden
• Entwickelt von Patrick und Rhadia Cousot 1975-1977
• Formalisiert „statische abstrakte Schlussfolgerung aus dynamischen
Eigenschaften“
• Genauere Betrachtung wird hier nicht vorgenommen
Ziel
• Aussage über den Zustand eines Programms machen
Problem
• Viele der gestellten Fragen sind unlösbar („Halte-Problem“)
Universität Mannheim
32
Software Reverse Engineering Lehrstuhl Praktische Informatik 1

8.4.4 MonoREIL
Wie umgeht man dieses Problem
• Wir betrachten eine Menge, über die wir
Schlussfolgerungen ziehen können
(Bereich vs. Satz von Werten)
• Deswegen „abstrakt“
Universität Mannheim
33
Software Reverse Engineering Lehrstuhl Praktische Informatik 1

8.4.4 MonoREIL
1
• Instruktionsgraphen erstellen
2
• Einen Graph-Ablaufalgorithmus bestimmen
3
• Programmstatus-Definitionen bestimmen
4
• Programmtransformationen definieren
5
• Programmflusszusammenführung definieren
6
• Startvektor definieren
Universität Mannheim
34
Software Reverse Engineering Lehrstuhl Praktische Informatik 1

8.4.4 MonoREIL
Starten mit dem Startvektor und Graph; mit
vorgegebenem Algorithmus durchlaufen.
Zusätzliche Informationen über den
Programablauf durch die Transformatoren und
Zustandszusammenführung sammeln.
Das Sammeln von Informationen wird beendet,
wenn keine weiteren Informationen mehr
hinzugefügt werden können.
Das Ergebnis wird in einem finalen
Ergebnisvektor abgelegt und dann mit den
originalen nativen Instruktionen verbunden.
Universität Mannheim
35
Software Reverse Engineering Lehrstuhl Praktische Informatik 1

8.4.4 MonoREIL [Register tracking]
Ziel
• Gegeben ein Register in einer Instruktion:
Welchen Effekt hat der Wert dieses Register
auf den Programstatus und den Kontrollfluss
Herangehensweise
• MonoREIL wird auf ein konkretes Problem
angewendet
Universität Mannheim
36
Software Reverse Engineering Lehrstuhl Praktische Informatik 1

8.4.4 MonoREIL [Register tracking]
• Instruktionsgraph wird durch MonoREIL erstellt
1
• Der Graph wird nach unten durchlaufen
2
• Einfacher Registersatz ist ein Programmstatus
3
• Für die 17 Instruktionen Transformationen definieren
4
• Bei Programmflusszusammenführung Registersätze zusammenführen
5
• Startvektoren: Elternknoten mit zu verfolgenden Register initialisieren, Kind
6 Knoten mit leerem Registersatz.
Universität Mannheim
37
Software Reverse Engineering Lehrstuhl Praktische Informatik 1

8.4.4 MonoREIL [Register tracking]
DEMO
Universität Mannheim
38
Software Reverse Engineering Lehrstuhl Praktische Informatik 1

8.4.5 Zusammenfassung
1 • Viele Architekturen erfordern
neue Wege
2 • Die Besonderheiten spielen die
entscheidende Rolle
3 • Kosten sind der entscheidende
Faktor
4 • REIL ist eine mögliche Antwort
Universität Mannheim
39
Software Reverse Engineering Lehrstuhl Praktische Informatik 1

Referenzen
• http://www.zynamics.com/downloads/csw09.pdf
• http://de.wikipedia.org/wiki/Abstrakte_Interpretatio
n
• http://www.di.ens.fr/~cousot/Equipeabsint-eg.shtml
• http://bitblaze.cs.berkeley.edu/
• http://www.eresi-project.org/
• http://www.phrack.org/issues.html?issue=64&id=8#
article
Universität Mannheim
40
Software Reverse Engineering Lehrstuhl Praktische Informatik 1