Architectural Diversity (German)

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
2

Architektur und
Vielfalt

8.1 Zielsetzung

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.

4

Architektur und
Vielfalt

8.2 Motivation

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

6

Architektur und
Vielfalt

8.3 Architekturen

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.

8

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.

9

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“

10

8.3 Architekturen [IV]
Name: SPARC / UltraSPARC / Niagara
Verwendung: High Performance Server
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“.

11

8.3 Architekturen [V]
Name: PowerPC
Verwendung: Server, PC‘s, Gaming Consoles
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.

12

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.

13

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 ?
14

Architektur und
Vielfalt

8.4 REIL

Übersicht
8.4.1 •Zielsetzung

8.4.2 •Motivation

8.4.3 •Sprachdefinition

8.4.4 •Anwendungen

8.4.5 •Zusammenfassung
16

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.

17

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
18

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
19

8.4.3 Sprachdefinition

Reverse Engineering Intermediate Language

20

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

21

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

22

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
23


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
24

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 , ,

25

8.4.3 Sprachdefinition [Operanden]
Operanden sind typisiert

• Register
• Literal
• Unter-Adresse

Operanden haben eine Größe

• 1byte, 2bytes, 4bytes, …

26

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ß.
27

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.

28

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 , ,
29

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
30

8.4.4 Anwendungen
• MonoREIL (Abstrakte Interpretation)
1 • Register Tracking

• Deobfuscator
2 • Typereconstruction

• Plattform unabhängiges „return-oriented
3 programming“

31

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“)

32

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“

33

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

34

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.

35

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

36

• 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.

37


DEMO

38

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

39

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

40

Architectural Diversity (German)

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (20)

Similar to Architectural Diversity (German)

Similar to Architectural Diversity (German) (20)

More from zynamics GmbH

More from zynamics GmbH (9)

Recently uploaded

Recently uploaded (7)

Architectural Diversity (German)