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

http://blog.zynamics.com	773
url_unknown	4
http://www.slideshare.net	1
http://static.slideshare.net	1
http://127.0.0.1:8795	1

Architectural Diversity (German)

by zynamics GmbH on May 21, 2010

Accessibility

Upload Details

Usage Rights

5 Embeds 780

Statistics

Architectural Diversity (German) — Presentation Transcript