Architectural Diversity (German)

Universität MannheimLehrstuhl Praktische Informatik 1Software Reverse Engineering

Kapitel 8: Architektur und

Vielfalt


2

Übersicht

8.1 •Zielsetzung

8.2 •Motivation

8.3 •Architekturen

8.4 •REIL

8.5 •Zusammenfassung


Architektur und Vielfalt

8.1 Zielsetzung


4

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.



8.2 Motivation


6

8.2 Motivation

• Verschiedene Anwendungsgebiete

• Unterschiedlichste Architekturen

• Mehrere mögliche Compiler

Unterschiedlichste

Systeme

• Eingebettete Systeme, Server, PCs,..

• Consumer Elektronik, Spiele Konsolen, Mobiltelefone, ..

Anwendungsgebiete

• Bisherige Methoden sind unzureichend

• Der Zeit und Kosten Faktor unberechenbar

Herausforderung



8.3 Architekturen


8

Name: ARMVerwendung: Low Power Devices (Mobiltelefone, ..)Architekturtyp: RISC 32BitAnzahl 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-Shifterverwenden um Ihre Argumente zu „shiften“.• Bei manchen ARM Cores ist das Ausführen von Java Code direkt auf der CPU möglich.

8.3 Architekturen [I]


9

Name: x86-32/64Verwendung: PCs und ServerArchitekturtyp: CISC 32/64 BitAnzahl 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.

8.3 Architekturen [II]


10

Name: MIPSVerwendung: Router, Server, Low Power DevicesArchitekturtyp: RISC 32/64 BitAnzahl 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“

8.3 Architekturen [III]


11

Name: SPARC / UltraSPARC / NiagaraVerwendung: High Performance ServerArchitekturtyp: RISC 32/64 BitAnzahl 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“.

8.3 Architekturen [IV]


12

Name: PowerPCVerwendung: Server, PC‘s, Gaming ConsolesArchitekturtyp: RISC 32/64 BitAnzahl 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.

8.3 Architekturen [V]


13

Name: AVRVerwendung: Eingebettete Systeme, Automobilsektor, Architekturtyp: RISC 8 BitAnzahl 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.

8.3 Architekturen [IV]


14

8.3 Zusammenfassung

• Mehr als eine Architektur ist Interessant1

• Jede Architektur hat Ihre Besonderheiten2

• Für die Analyse sind die Besonderheiten enorm wichtig3

• Gibt es trotz dieser Vielfältigkeit eine Architektur unabhängige Möglichkeit der Analyse ? 4



8.4 REIL


16

Übersicht

8.4.1 •Zielsetzung

8.4.2 •Motivation

8.4.3 •Sprachdefinition

8.4.4 •Anwendungen

8.4.5 •Zusammenfassung


17

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.


18

8.4.2 Motivation I

• Architekturelle Besonderheiten

• Mehr als ein Compiler

Verschiedene Architekturen

• Schwerer zu Analysieren

• Steigende Kosten

Steigende Komplexität

• Architektur und Compiler unabhängig

• Einfach zu definierende Algorithmen

Anforderungen


19

8.4.2 Motivation II

• Fehler finden wird schwieriger

• Die Defensive hat den Quellcode

• Die Defensive investiert in die Analyse von Quellcode

Offensive vs. Defensive

• Tiefe geht vor Breite

• Ohne automatisierte Werkzeuge wird das Spiel verloren

Offensive Statische Analyse


20

8.4.3 Sprachdefinition

Reverse Engineering Intermediate Language


21

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


22

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


23

8.4.3 Sprachdefinition [Instruktionen]

• Einzigartige Adresse [0xAABBCCDD.XX]

• Simples Format [Adresse [Mnemonik (OP1, OP2, OP3), {Meta}]]

Format

• Mnemonik beschreibt Programmstatuseffekt exakt

Effekt

• Arithmetik

• Bitweise

• Logische

• Datentransfer

• Weitere

Instruktionskategorien


24

ADDSUBMULDIVMODBSH


MNEMONIC OPERAND 1 OPERAND 2 OPERAND 3 META INFO

LDMSTMSTR

ANDORXOR

BISZJCC

NOPUNKNUNDEF

Ari

thm

etik

Bo

ole

sch

e

Logi

sch

e

Dat

en T

ran

sfer

An

der

e

Instruktionen nutzen 0 bis 3 der möglichen Operanden

Metainformationen enkodieren zusätzliche Informationen

ADDR


25


add t0, t1, t2

and t0, t1, t2

bsh t0, t1, t2

div t0, t1, t2

mod t0, t1, t2

mul t0, t1, t2

or t0, t1, t2

sub t0, t1, t2

xor t0, t1, t2

bisz t0, , t2

jcc t0, , t2

ldm t0, , t2

nop , ,

stm t0, , t2

str t0, , t2

undef , , t2

unkn , ,

Alle Instruktionen sind gleich

Aber manche Instruktionen sind gleicher


26

8.4.3 Sprachdefinition [Operanden]

• Register

• Literal

• Unter-Adresse

Operanden sind typisiert

• 1byte, 2bytes, 4bytes, …

Operanden haben eine Größe


27

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


28

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.


29

8.4.3 Sprachdefinition [Übersetzung]03F535B4 MOV R2, R1

3F535B400: str R1, , R2

03F535C4 STR LR, [SP,0x4]

3F535C400: add SP, 4, t13F535C401: and t1, 4294967295, t03F535C402: stm LR, , t0

3F7C39400: bisz Z, , t33F7C39401: jcc t3, , 66569108.53F7C39402: add R2, 6, t53F7C39402: ldm t5, , R33F7C39403: and t5, 0xFFFFFFFF, t43F7C39405: nop , ,

03F7C394 LDREQH R3, word [R2,0x6]


30

8.4.3 Sprachdefinition [Limitierung]

• Nicht alle Instruktionen können übersetzt werden

• Floating Point Instruktionen

• MMX, SSE, Altivec

• Hardwarenahe Instruktionen SETEND, BKPT

• System Aufrufe

• Interrupts

Übersetzung

• Keine Unterstützung von Ausnahmen (Exceptions)

System Charakteristiken

• Eine Instruktion hat sich als nicht ausgereift erwiesen

Fehler im Initialen Design


31

8.4.4 Anwendungen

1

• MonoREIL (Abstrakte Interpretation)

• Register Tracking

2

• Deobfuscator

• Typereconstruction

3• Plattform unabhängiges „return-oriented

programming“


32

8.4.4 MonoREIL

• 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

Abstrakte Interpretation

• Aussage über den Zustand eines Programms machen

Ziel

• Viele der gestellten Fragen sind unlösbar („Halte-Problem“)

Problem


33

8.4.4 MonoREIL

• Wir betrachten eine Menge, über die wir Schlussfolgerungen ziehen können (Bereich vs. Satz von Werten)

• Deswegen „abstrakt“

Wie umgeht man dieses Problem


34

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


35

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.


36

8.4.4 MonoREIL [Register tracking]

• Gegeben ein Register in einer Instruktion: Welchen Effekt hat der Wert dieses Register auf den Programstatus und den Kontrollfluss

Ziel

• MonoREIL wird auf ein konkretes Problem angewendet

Herangehensweise


37


1• Instruktionsgraph wird durch MonoREIL erstellt

2• Der Graph wird nach unten durchlaufen

3• Einfacher Registersatz ist ein Programmstatus

4• Für die 17 Instruktionen Transformationen definieren

5• Bei Programmflusszusammenführung Registersätze zusammenführen

6

• Startvektoren: Elternknoten mit zu verfolgenden Register initialisieren, Kind Knoten mit leerem Registersatz.


38


DEMO


39

8.4.5 Zusammenfassung

• Viele Architekturen erfordern neue Wege1

• Die Besonderheiten spielen die entscheidende Rolle2

• Kosten sind der entscheidende Faktor3

• REIL ist eine mögliche Antwort4


40

Referenzen

• http://www.zynamics.com/downloads/csw09.pdf

• http://de.wikipedia.org/wiki/Abstrakte_Interpretation

• 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

http://www.zynamics.com/downloads/csw09.pdf

http://de.wikipedia.org/wiki/Abstrakte_Interpretation

http://de.wikipedia.org/wiki/Abstrakte_Interpretation

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

http://www.phrack.org/issues.html?issue=64&id=8

Architectural Diversity (German)

Documents

Transcript of Architectural Diversity (German)