 An at C3 lingo, C3 lingo oder unter dem Hashtag C3T. Willkommen Marius, der hier diesen Talk halten wird. Applaus aus dem Saal. Okay, danke für die Einführung. Ich bin Marius und ich werde heute über Avatar 2 sprechen. Ich habe das als Teil von meinem PhD entwickelt. Und wenn ich Avatar sage, dann meine ich nicht den Film oder den Anime. Schauen wir mal, wie ich euch das erzählen will. Zuerst möchte ich euch etwas über firmware Analyse ganz grundsätzlich erzählen und dann die Tooling-Landenschaft anschauen, was andere machen, was sie gemacht haben. Dann will ich die High-Level-Konzepte von meinem Framework vorstellen. Und am Ende werde ich ein paar Beispiele zeigen, welche darlegen, wie das Framework benutzt werden kann und benutzt wird. Also, firmware Analyse, warum sind wir überhaupt daran interessiert? Die Firmware von Embedded Devices zu analysieren. Es hat immer wie mehr, jeden Tag wegen dem Internet of Things und überhaupt. Am Ende sind das einfach miteinander verbundene Geräte. Und Fehlkonfigurationen und Box und Vulnerabilität sind sehr, sehr verbreitet. Und die meisten davon sind eben solche Fehlkonfigurationen und sogenannte Low-Hanging-Fruits. Ein Fehler auf dem Web-Server oder halt einfache Box in den Web-Servern, die dort verwendet werden. Aber wir hoffen, dass wir in der Zukunft, dass sich das ändert in der Zukunft und dass die Verkäufer dieser Devices das besser machen und dass wir dann anfangen müssen, halt kompliziertere Box finden, welche da vorhanden sein werden. Aber wenn wir solche komplexen Fehler Box finden wollen, dann brauchen wir auch bessere Tools. Natürlich, wir können uns hinsetzen und da den langen Weg machen und das ganze Bit-for-Bit-Reverse-Engineering, aber es geht besser mit Tools. Aber speziell im Vergleich zu Desktop-Systemen gibt es hier einige zusätzliche Herausforderungen. Und zwar gibt es einen sehr großen Spektrum an verschiedenen Plattformen, welche ihre eigenen Speicher-Layouts und Zusatzgeräte haben. Und das kann von weiteren Geräten abhängen. Es gibt keine Obstraktionen auf dem Level des Betriebssystems. Viele davon verwenden eine Version von Linux oder haben ihre eigene Firmware, die direkt nur für diese Systeme gebaut wurde. In vielen Fällen werden die Interaktionen mit der Hardware direkt in der Firmware eingebettet und sind nicht Teil der Hardware. Und das schafft zusätzliche Probleme. Wenn die Firmware mit der Hardware interagiert, dann kann das über Memory-Mapped-Io-geschehen oder über Interrupts. Und wir müssen all diese verschiedenen Varianten analysieren in unserem Tooling. Und zudem zu den ganzen gibt es noch einen Riesenhaufen unterschiedlicher Architekturen. Nicht nur verschiedene Verkäufer und Plattformen, sondern Architekturen. ARM, MIPS, PowerPC, Spark, alles Mögliche. Und jetzt einfach ein Beispiel, das müsst ihr nicht lesen können. Das sind nur die Mikroarchitekturen, welche von ARM definiert wurden. Und das ist nur ARM selber. Keine Drittpartei-Verkäufer, welche für ARM, Systeme und Chips designen. Das sind 30 verschiedene Mikroarchitekturen, alle mit wirklich kleinen Unterschieden in ihrer Mikroarchitekte. Was relativ schwierig ist in einem allgemeinen Tool für alle zusammen. Es gibt auch noch ein paar mehr Probleme, die wir mit denen wir uns beschäftigen müssen. Auf Desktop-Systemen ist es häufig mit Instrumentation gelöst. Man schaut sich an, was passiert während der Laufzeit, z.B. mit Hooks in Funktionen usw. Bei Mikrocontroller ist es ein bisschen schwieriger, weil es fehlen Abstraktionen durch das Betriebssystem kommen. Die Abstraktionen durch das Betriebssystem fehlt. Außerdem können wir nicht direkt auf der Embedded Device immer rum die Bergen kommen. Außerdem kann es sein, dass die Firmware durch den Hersteller verschüsselt ist oder signiert, so dass man sie nicht ändern kann. Außerdem kann die Immolation der Instruktion auch sehr schwierig sein. Auf dem Desktop ist das alles durch das Betriebssystem geregelt, mit der Hardware-Interaktion usw. Bei Embedded Devices, bei Mikrocontrollern ist das nicht so, weil es viele verschiedene Geräte gibt, die man nicht allgemein immolieren könnte. Oder es jedenfalls viel Implementation aufwand wäre. Außerdem ist es auch schwer herauszufinden, wenn es ein Memory Fault gibt, also wenn es in valide Adressen gelesen werden oder so. Zum Beispiel kriegen wir auf dem Desktop so etwas wie Heap Corruption, Warnung, wenn wir mit der G-Lib C arbeiten und die G-Lib C merkt, dass wir den Heap Corrupted haben. Und das ist auf Embedded Devices nicht so, weil auf den Embedded Devices gibt es meistens gar keine G-Lib C. Die G-Lib C sind da einfach viel kleiner, viele dieser Geräte haben vielleicht noch nicht mal eine Memory Management Unit, was überhaupt erst das Konzept von falschen Speicherzugriffen geben kann. Das heißt, vielleicht wird die Firma einfach weiter ausführen, obwohl wir das Programm grumpiert haben. Viele der Firmen laufen einfach kontinuierlich immer weiter und updateen es in State. Und werden diesen Main Loop bestimmen, diese Hauptscheife kontrollieren. Wenn wir statische Analyse durchführen wollen, dann müssen wir rausfinden, wo diese Interrupts gehandelt werden. Und es gibt viele Architekturen und die haben eine Haufen kleine Unterschiede, welche nur auf dieser genauen Architektur so sind und dann kann es sogar passieren, dass von Kern zu Kern bei RM die Instruktionen leicht unterschiedlich sind. Und das zeigt die Herausforderungen, welche es hier gibt. Und dann schauen wir jetzt mal hin, was es bereits gibt an Tools. Und aufgrund dieser Herausforderungen ist die Landschaft an Tools deutlich deutlich kleiner, gerade im Vergleich zu Desktop-Applikationen. Und während es für Desktop viele gibt, dann kann man sie nicht zwingend auf die Embedded-Devices anwenden, weil sie machen Annahmen über die Umgebungen, in denen sie laufen, welche nicht zwingend wahrbleiben. Und es ist halt schwierig, vorher zu sagen, wie sich die Angehängtengeräte und die Interrupts verhalten werden. Und darum möchte ich eine Liste zeigen, was es gibt. Das ist keine vollständige Liste, aber es gibt mal einen Einblick. PHY ist für die MSP430 firmware und das ist basiert auf KLE. Und das funktioniert über die Zwischenrepräsentation, welche von LLVM generiert wird. Und das macht eine explizite Analyse, es analysiert das Memory und die Interruptspezifikation. Und diese Memory-Spezifikation gibt vor auch, wie sich das Memory verhalten soll, wenn davon gelesen oder darauf geschrieben wird. Und das abstractiert und emuliert so eine Memory-Controller. Die Interrupt-Spezifikation, nun ja, das gibt halt an, wann es Interrupts geben könnte und welcher Interrupt-Handler ausgeführt werden sollte. Und während das tolle Arbeit ist und keine physische Device vorgeben würde, muss man dazu den Source Code der firmware haben, weil das ist so, wie halt KLE funktioniert. Leider ist der Source Code meistens nicht verfügbar, wenn wir Firmware analysieren wollen. Also schauen wir uns doch mal, wie man Binära-Analysen machen kann. Da gibt es zuerst mal Firmware ein. Das ist ein Binary-Analyser, der auf QM basiert. Das ist ein voller System-Analys-Emulator. Damit kann man, das wird in diesem Kontext als voller System-Analyser verwendet. Der kann einen Haufen Systeme emulieren und damit auch einen Haufen Hardware-Boards emulieren. Spezifisch zielt Firmware ein auf ARM und MIPS Firmware und benutzt einen modifizierten Linux Kernel. Es nimmt also eine Linux Firmware, führt die in QMU aus und erlaubt damit automatisierte Analysen von Webseiten und SNMP-Emplementationen und man kann damit auch mit bekannten Exploits automatische Tests durchführen. Daher ist auch ganz interessant, dass ein Haufen Exploits, die auf einer Devise existieren können, verbreitet werden und wiederverwendet werden in anderen Devices und es gibt entsprechend, und das bedeutet, dass es eine große geteilte Code-Basis gibt zwischen den Linux Firmwares. Das funktioniert aber leider nur mit Linux basierter Firmware, wenn die keine zu spezifischen Kernel-Module verwenden, weil wenn sie zwingend spezifische Kernel-Module für Hardware in der Interaktion braucht und spezifische Peripherals hat, dann kann man die nicht emulieren und dann funktioniert Firmware ein nicht. Ein weiteres spannendes Projekt, das dieses Jahr rauskam, ist Lua QMU, das ist, wie der Name schon sagt, auf QMU basiert, ist noch ein Work-and-Progress und das Beispiel, das mit dem Tool veröffentlicht wurde, zielt auf BZM 4358 Firmware und das ist ein Chip, der in einem Haufen von Smartphones verwendet wird und mit diesem Tool kann man Boards mit Lua prototypisch bauen und man hat damit auch Kapazitäten, um zu instrumentieren und automatisieren. Leider emuliert, dass die Firmware nur und da viel Hardware-Interaktion passiert, vor allem in der Initialisierung. Deswegen führt das dazu, dass es viel Versuch und Fehler geben muss, damit man das überhaupt hinbekommt. Das letzte Werkzeug, was ich euch vorstellen möchte, ist Avatar. Wie ihr vielleicht schon gedacht habt, wenn ich über Avatar 2 rede, gab es vielleicht schon ein erstes Avatar. Dieses Werkzeug war auf S2E basiert, was eine Mischung aus QEMU und Klever, was selber dann es benutzt OpenCD und GDB und funktioniert auf ARM Hardware. Das heißt, dass die Firmware selber auf der echten Hardware laufen und ein bisschen davon auch im Emulator. Bestimmte Hardware-Anfragen werden auf das echte physische Gerät umgeleitet. Außerdem erlaubt es Avatar, dass man anfangen kann, auf dem echten Gerät zu laufen und dann den Status auf den Emulator zu übertragen, um die Ausführungsprogramms auf dem Emulator weiterzuführen. Das heißt, man kann alle Initialisierungsfunktionen übersprungen, indem er sich auf dem Board ausführt und dann den Hauptteil nur anders sehen. Außerdem können wir mit Kle auch symbolisch ausführen, was hilfreich ist. Leider war Avatar 1 sehr an die S2E-Infrastruktur angebunden und dass die partielle Emulation das echte Geräte benötigt hat. Was können wir jetzt hier sehen? All diese Tools fokussieren hauptsächlich auf die ARM-Architektur. Außerdem benutzen die meisten dieser Tools die QEMO-Emulations-Framework. Das heißt, dass Leider diese Frameworks sehr stark an die QEMO gebunden sind. Das heißt, es ist ein bisschen schwierig, den Status des Emulators in ein anderes Tool reinzubekommen. Und dieses Problem, diesen Status zwischen den Analysierungen hin und her zu kriegen, ist die Motivation für die Avatar 2 Framework. Avatar 2 will damit Framework Analyse auf Multitarket-Automatisierung machen. Es ist Python basiert, wir haben das Juni dieses Jahres veröffentlicht. Es ist ziemlich neu, es ist ein Forschungsprojekt. Wir versuchen, eine saubere und benutzbare Codebossis zu haben, aber stellenweise kann das heute etwas fragil sein. Im Vergleich mit Avatar 1 haben wir es komplett neu designed und neu implementiert für bessere Benutzbarkeit und bessere Abstraktionen der Ziele. Es wird spezifisch von der Software & Systems Security Group bei Eurecom entwickelt und zwar von Marius Mönch, Dario, Nisi und hier war ich nicht schnell genug. Die Hauptziele, als wir angefangen haben Avatar 2 zu schreiben, war, dass wir die Ziele automatisieren können, dass wir Ausführungen und Speicher separieren können und dass wir Status transferieren und synchronisieren können. Und diese Ziele können alles sein, Debuggers, Emulatoren, Geräte und wir wollen einfach fakes sein, neue Ziele hinzuzufügen. Wir wollen eine klare Trennung zwischen Ausführungen und Speicher, weil das ist die Hauptanforderung, die wir haben, damit wir Input Output Forwarding und Remote Memory haben kann, damit wir die Analyse auf einem Gerät und den Speicher auf einem anderen Gerät haben können. Und dann ist es noch wichtig, dass wir den Zustand transferieren können, weil auch wenn wir die Analyse auf einem bestimmten Ziel starten, wollen wir diese nicht zwingend lokal behalten können. Eventuell wollen wir ja von einem Embedded Device zu einem Emulator wechseln und dazu brauchen wir einfache Wege, um den State zu transferieren. Und am Schluss kommen wir bei einem Framework, an das aus vier Komponenten besteht. Dem Avatar 2 Core, das ist ein Python Library und das ist das Hauptinterface zwischen dem analysierten und dem zu analysierenden Gerät. Dann haben wir die Ziele und dann haben wir noch die Endpoints. Endpoints sind da alles, Emulatoren, Debuggers, Frameworks, aber die Ziele und die Endpoints sprechen nicht direkt miteinander. Die werden verbunden über ein Layer aus sogenannten Protokollen. Das können wir hier sehen. Wir haben den Avatar 2 Core oben auf dem Bild und dann haben wir die Torquets und die sprechen wir Ausführungsprotokollen, Speicherprotokoll, Registerprotokoll mit dem eigentlichen Endpoint. Die Idee, warum wir das machen, ist ziemlich einfach. Viele Tools kommunizieren auf ähnliche Art. Sowohl QUMU und noch eines bieten einen GDB-Interface an, um die Software, die zu analysieren ist, mit dir zu interagieren und indem wir die Protokolle aufteilen in diese Bereiche, wie Ausführung und Speicher, erlauben wir da eine saubere Trennung zwischen den verschiedenen Konzepten in der Ausführung. Sprechen wir jetzt mal von den umgesetzten Zielen. Das könnte auch ein kurzes Canada Open Source Logos sein. Hier ist das Logo von GDB. Das ist der Archivist, der schießt mit Wasser, dass er spuckt, einzelne Box ab und damit er sie essen kann. Unten links haben wir QUMU, das ist der Full System Emulator, von dem wir schon gesprochen haben. Oben rechts ist Panda, das ist ein Reverse Engineering Framework basierend auf QUMU, welches wiederholbares Reverse Engineering ermöglichten will. Es tut das, indem es den ganzen, nicht der terministischen IO aufzeichnet und diesen dann wieder abspielen kann zu einem späteren Zeitpunkt aus aufbauend auf dem selben Initialisierungszustand. Der Vorteil, das so zu tun, ist, dass der resultierende Speicherfußabdruck eines solchen Recordings sehr klein ist gegenüber den olden Trices. Panda hat zudem ein Plug-in System, welches ermöglicht, zusätzliche Funktionen zu QUMU hinzuzufügen. Das letzte Tool auf das Leid ist das Anger Framework, was im Moment noch entwickelt wird, veröffentlicht wird bzw. in den öffentlichen Branchen gemerged soon, also bald, das ist ein symbolisches Ausführungsframework, welches sehr mächtige Fähigkeiten zur symbolischen Ausführung ermöglicht. Etwas habe ich noch vergessen, wir unterstützen noch ein fünftes Ziel, das noch nicht repräsentiert ist und das ist Open OCD, ein Tool, mit dem man mit JTAG Interfaces sprechen kann, um darüber mit Embedded Devices sprechen. JTAG ist der Debugging-Port, der auf vielen Embedded Devices vorhanden ist, den wir dann verwenden können, um dynamisch die Firmware auf diesem Target zu analysieren. Wie wir es auch schon davor gesehen haben, viele dieser Tools sind auf QEMU basiert, das heißt, wenn wir mit denen einfach integrieren wollen, um sie in das Avatar-System einzubinden, ist das wir, sollten wir QEMU an uns anpassen, das haben wir getan. Diese Änderungen sind in einem einfachen Unterverzeichnis unseres Clubs, das heißt, es sollte relativ einfach sein, einen neuen QEMU basierten Ziel von Avatar zu machen. Was haben wir noch hinzugefügt? Wir haben eine konfigurable Maschine hinzugefügt, damit können wir mit Lua eine Maschine beschreiben. Die Konfiguration der Hardware ist in einer JSON-Datei geschrieben, die von Avatar ausgespuckt worden ist, was der Entwickler dann in Palten geschrieben hatte. Aus dem gibt es ein zusätzliches Gerät in QEMU, nämlich Avatar Peripheral. Es ist quasi einfach ein Protokoll, mit dem man neue Geräte hinzufügen kann. Damit kann man dann die Speicherzugriffe weiter leiten kann. Mit diesen weitergeleitenen Zugriffen muss man dann, kann man zum Beispiel an die echte Hardware weiter leiten. Was wir auch noch für Avatar 2 gemacht haben, ist, wir haben das Architektur unabhängig geschrieben, d.h. wir haben ein Unterverzeichnis, das sich mit Plattformabstraktionen beschäftigt. D.h. wir haben zurzeit für ARM, für X86 und X86 64 Abstraktionen. Wir entwickeln auch gerade einen MIPS, etwas für die MIPS Architektur. Wir haben auch eine besondere Speicherlayout, um Dinge herumzuschieben. Man kann Peripherals auch direkt in Python definieren und diese so modellieren. Wählen man einen Peripheral, weil das immer die gleichen Werte zurückgebt, kann man das auch machen. Man kann es auch dynamisch haben. Zudem wollen wir den Avatar 2 Kern so klein wie möglich halten. Gleichzeitig muss man bei einer Analyse viele verschiedene Tasks machen. Um das einfacher zu machen und zu ermöglichen, bauen wir ein flexibles Plugin-System. Da hat es schon ein paar Beispielplugins. Es gibt ein Orchestration Plugin, welches automatisch die Ausführung von Zielen ausführt. Wenn man ein Avatar-Script schreibt, dann wird man explizit, wenn was passiert, im Orchestration Setting definiert man nur Übergänge und das Avatar-System das Plugin kann den Zustand gemäß diesen Übergängen anpassen. Wir haben auch ein Instruction Forwarder, der kann mit nicht emulierten Anweisungen umgehen. Und wenn Avatar so eine Instruction findet, dann wird es sie nicht im Emulator ausführen, sondern auf der Device, damit der Zustand mindestens dort entsprechend angepasst wird. Nach diesem ganzen High-Level darüber reden, gehen wir mal zu den Beispielen. Ich werde euch zwei Anwendungsfälle zeigen, bei denen Avatar als dynamisches Analyse und Orchestrierungsframework verwendet wurde. Wenn ihr ein Avatar-Script schreiben wollt, dann müsst ihr 3 oder 4 Sachen machen, normalerweise. Ihr müsst das Haupt-Avatar-Objekt erstellen. Ihr müsst ein Set von Zielen, mit denen ihr euch in der Analyse befassen wollt, definieren. Optional müsst ihr, wenn ihr mehrere Targets oder ein QEMU-basiertes Target habt, müsst ihr das Memory-Layout definieren und dann müsst ihr einen Ausführungsplan spezifizieren. So, Demo. Beginnen wir mit etwas einfachern und zwar die Hello World Demonstration. Wir haben hier ein Ausführbares Datei, die heißt Aided Out. Das ist ein Python-Script. Und wir haben ein Python-Script, HelloWorld.py, das sieht man ja hier. Wenn wir Aided Out ausführen, dann exit es einfach mit dem Fehler-Code 42 und nichts passiert. Und im Python-Script sehen wir die ganze Orchestrierung und Analyse. Wir definieren ein Avatar-Objekt mit der Architektur. Wir kreieren das entsprechende Target, das ist in dem Fall GDB. Wir fügen das Target nicht nur hinzu, sondern wir öffnen gerade den GDB-Server. Dieser GDB-Server wird einfach das Aided-Out ausführen. Wir initialisieren das Ziel, das verbindet uns direkt mit dem Endpoint und führt die ganze Initialisierung aus. Und dann haben wir hier den Shell-Code, den wir einfügen wollen. Dieser Shell-Code macht nichts anderes als ein simples Hello World auszuführen auf Standard Out. Hier ist das Interessante, wir instrumentieren GDB von außen. Wir instruieren es, dass es Speicher an den Instruction-Pointe schreiben soll. Das hatte die Länge vom Shell-Code, ist der Shell-Code und ist Raw Memory. Anschließend wollen wir unsere Ausführung weiterführen. Wir führen das aus, wir haben Hello World als Ausput. Das ist eine simple Demo, die die Instrumentierungskapazitäten von Avatar 2 demonstriert. Und insbesondere, was ich da toll finde, ist die Möglichkeit, GDB von außen zu skripten, ohne dass man ein Python-Script innerhalb von GDB ausführen müsste. Auf der rechten Seite kommen direkt die volle Analyse zentralisiert an einem Ort sehen. Fahren wir weiter mit der Binärinstrumentation auf einem echten Target weiter. Als unser echtes Ziel wählen wir hardware aus. Das ist ein PLC-Rootkit, das letztes Jahr an der NDSS präsentiert wurde. Und das basiert auf Code-Injection via JTAG. Das PLC hat selber mehrere Boards. Schauen wir mal, ob das funktioniert. Hier sind wir. Das ist der PLC, was wir relativ schnell an- und ausschalten können. War das der Richtige? Okay, tut mir leid. Ich habe vergessen, das vorherzutun. Diese Demonstration ist ziemlich, geht ziemlich schnell kaputt. Wir sehen hier mehrere Boards. Hier auf der Seite sehen wir ein menschliches Interface. Zum Beispiel für SD-Karten, USB-Karten usw. Hier oben sehen wir IOs für diesen programmable Low-Jet Controller. Hier oben haben wir Input-Output-Dinge, die man verbinden kann. Hier sieht man, dass es keine IOs erkannt hat. Deswegen sind all die LEDs aus. Das Spezielle an diesem Board ist, dass man der Cortex-M3-Prozessor, der hauptsächlich mit Aktualisierung, mit Updates von der äußeren Welt beschäftigt. Dieser M3-Prozessor hat freundlicherweise auch einen aktivierten JTAG-Port. Das heißt, wir können hier einfach etwas ranlöten und haben uns mit diesem Chip verbunden. Das führt uns zu dieser Demo. Dieses Gerät ist besonders interessant, weil einige Teile der Firmware innerhalb von SRAM drin sind. Und die Firmware in den SRAM geladen ist. Das heißt, dass wir diese Teile der Firmware instrumentieren können. Was wir auch getan haben, indem wir den Proof-of-Concept von Harvey neu implementiert haben. Hier machen wir einfach wieder das Gleiche. Wir kreieren das Avatar-Objekt, laden das Assembler-Plug in, setzt das OCD-Target, setzt ein Breakpoint an der Hauptschleife. Wir holen wieder die Initialisierungsfunktion überspringen wollen. Wir führen die Ausführung fort, bis wir zum Breakpoint kommen. Das wird vom Waite gemacht. Und dann fügen wir unseren eigenen Assembly-Code ein. Das ist bloß eine Proof-of-Concept Implementation. Keine volle Implementierung, aber es wird schon zeigen, dass wir die Ausführung woanders hinbringen können, sodass das menschliche Interface denkt, dass andere Inputs kommen. Wir machen das, indem wir in ein Interrupt-Handler reinhucken, welcher häufig aufgerufen wird und daraus den Zustand verändern. Lass uns schauen, ob das funktioniert. Wir versuchen sowohl Python 2 und Python 3 kompatibel in Kurz haben. Also lass uns mal hier Python 3 verwenden. Also hier, hier schaut mal. Die Kamera ist jetzt aus, also kann ich es euch nicht zeigen. Aber hier hat es angefangen zu blinken. Das heißt, das Input da ist, aber hier sieht man deutlich, dass Input keinen da ist. Ich habe hier noch ein Bild hinzugefügt, nur falls die Demo nicht funktioniert. Lass uns jetzt zum nächsten Beispiel fortschreiben. Hier geht es um Fault Detection. Dieses Beispiel ist part von, what you corrupt is not what you crash. Also was man korrompiert, ist nicht das, was man crashed. In diesem Vortrag schauen wir uns das Ganze in mehr Detail an. Da könnt ihr euch das nachschauen. Hier schauen wir, wie wir diese Devices ein bisschen fassen können. Aber ein weiteres Problem von Fast-Testing hier ist die Skalierbarkeit, weil man viele Prozesse gleichzeitig ausführen muss, aber schwierig ist in der Embedded Device. Dafür brauchte man nämlich einen Riesenhaufen für verschiedene Geräte. In unserem Paper evaluieren wir verschiedene Strategien, um das Fast-Testing zu unterstützen. Zum Beispiel sind Binarys umzuschreiben. Am Ende wollen wir etwas die Richtung vorgeben, indem wir Avatar 2 verwenden, um das Fault Detection zu ermöglichen. Für das Paper hatten wir einen Setup mit zwei Zielen. Einerseits ein STM3252RI Devboard, das habe ich hier, und das ist ein ziemlich gutes Board mit netten Features, das direkt einen J-Tag-Interface Embedded hat und ein USB-Zugang bietet. Anderer Target, das wir verwenden, ist Panda, das Reverse-Engineering-Framework. Als Zielsoftware für unseren Test haben wir X-PAD, eine instrumentierte Version von X-PAD, mit künstlich eingefügten Vulnerabilities verwendet. Die Initialisation der Geräte lief auf dem Physical Board und die Emulation des Main-Loops geschah innerhalb von Panda. Wir haben fünf Panda-Plugins verwendet zur Analyse, welche verschiedene bestehende Techniken nachgemacht haben. Wir haben etwas gehabt, das war ähnlich wie eine Shadow Stack Implementation. Wir hatten etwas, was die Heap-Konsistenz überprüfen will, in dem es Mallocked, Freed- und Freialocked-Objekte trakt. Der große Vorteil von diesem Vorgang ist, dass man die Formule nicht modifizieren muss. Wir haben 100 Fussing-Sessions je eine Stunde gemacht mit ganz unterschiedlichen Setups. Wir haben als Baseline das Board selber genutzt. Wir haben Partielle Emulationen mit IO4-Wording gemacht, Partielle Emulationen mit Avatar 2 Peripherals und volle Emulationen. Wir konnten damit zuvor unentdeckte Fehler finden und die volle Emulation hat bessere Performance gebracht als das native Fussing, weil beim Emulieren können wir den Clockspeed des Devices höher setzen als auf dem tatsächlichen Gerät. Die nächste Demo ist ein Teil dieser Arbeit und eines der Features, das man hat, wenn man Panda verwendet. Das ist speziell cool, weil wenn man ein Beta-Device analysiert, muss man das Device physisch dabei haben. Aber wenn wir Panda nutzen, können wir eine Ausführung davon aufnehmen und später wieder ausführen im Emulator, ohne dass man das Gerät präsent hat. Also, schauen wir die Demo an. Damit ihr mir das glaubt, die Demo, die Software hier, ist tatsächlich der XML-Parser, wie gesagt. Wir schauen uns hier den Seriellen-Output an und schreiben da XML. Und da haben wir die XML-File da wieder rausgegeben und dann den Document-Tree dafür gekriegt. Das funktioniert also. Also schauen wir uns das Avatar-2-Script an für das. Das ist etwas komplexer. Die zuvor gesehenen, wir definieren zwei Ziele, Target und Open-OCD. Wir bereiten hier mehrere Memory-Ranges für Read-Only, für RAM und mehrere für Memory-Mapped-IO. Und damit wollen wir das Serial-Interface mit einem Avatar-Peripheral emulieren. Und hier als Beispiel für die Orchestration-Plugins. Wir starten es, wir führen einen Übergang aus und dann starten wir die Orchestration. Und hier, sobald diese Adresse beim Ausführen erreicht wird, wird diese Zustandsveränderung durchgeführt und wir gehen vom Nuclear zum eigentlichen Board. Und hier wechseln wir zu einer I-Python Shell bei der Ausführung und dann wird dann in diese I-Python Shell weiter ausgeführt. Die Demo macht hier gerade nicht mit. Das GDB-Protokoll kann nicht verbinden. Da habe ich jetzt keine Zeit dafür, das zu debuggen. Ich glaube mir, das funktioniert. Gelächter und Applaus. Und ich habe schon ein paar Aufzeichnungen vorbereitet, welche beeindruckend unspektakulär sind. Diese hier führt Panther aus mit einer konfigurierten Maschine mit den ausgelesenen generierten Konfigurationen. Mal schauen, ob zumindest der Replay funktioniert von einer zuvor ausgeführten. Der Replay wurde korrekt ausgeführt. Wir sehen hier einige Debug-Messages, die hier rauskommen. Das letzte Beispiel, was wir euch zeigen, ist immer noch Work in Progress, wo wir die symbolische Ausführungen nutzen wollen, um komplexe Software mit Avatar zu analysieren. Wir sind hier noch nicht fertig. Wir haben einen Bug in Firefox eingeführt und eingefügt und das Komplett-Inhalt von GDB ausgeführt, bis wir die betroffenen Funktionen gefunden haben und Angel selber könnte so komplexe Software nicht ausführen. Wir analysieren einen einzelnen Thread und sobald wir die interessante Funktionen treffen, extrahieren wir das Memory-Layout aus GDB und kopieren nur dieses Layout in Anger-Ryne während die eigentlichen Speicher-Inhalte Copy-on-Read send. Also wenn Anger die Lesen will, dann wird es rauskopiert vom Firefox. Und wir machen das so, weil wenn wir die ganze Memory dumpen würden, dann würde es dann RAM sprengen. Und wir verwandeln die Funktionsargumente in Symbole und führen dann aus. Wir hatten hier circa 10 Minuten Ausführungszeit, 36 Blöcke ausgeführt, 21 Speicherseiten gelesen und wir haben den Bug gefunden. Wir hatten jetzt fünf Beispiele gesehen, einmal Dynamische Instrumentierung mit GDB, einmal mit PLC, Volt-Erkennung mit einem Entwicklungsbord und Panda aufzeichnen und wieder abspielen auf einem Entwicklungsbord, was wir nicht gesehen haben, nur wieder abspielen und symbolische Ausführungen mit Firefox und GDB. Die meisten dieser Dinge werden spätestens nächsten Monaten verfügbar sein, um zusammenzufassen. Dynamische Firmware-Analyse ist immer noch ein sehr schwieriges Problem. Ich werde nicht behaupten, dass wir es komplett gelöst haben, aber Avatar 2 versucht einige dieser Herausforderungen anzugehen und den Stand der Technik zu verbessern. Dass man viele Frameworks und Emulatoren zusammenarbeiten lässt, ist ein Konzept, was nicht nur für Firmen zutrifft, sondern auch für Desktop-Analyserwäre das ganz gut. Da es tatsächlich das Ende des Jahres ist, machen wir ein paar Pläne für das nächste Jahr. Wir wollen unser Entwicklung zu auf GitHub bewegen. Das ist ein bisschen doof zur Zeit, weil wir unser privates Repository dafür haben und das ein bisschen schwer zu synchronisieren. Außerdem wollen wir mehr und mehr Targets hinzufügen. Falls ihr uns helfen wollt oder falls ihr eine Frage habt, kontaktiert uns auf IRC, via E-Mail oder einfach direkt mit mir zu reden. Aushemmen suchen wir vielleicht nach Leuten, die unser Team joinen können. Insofern möchte ich noch diesen Leuten danken und wir können zu Fragen und Antworten weitergehen. Okay, die erste Frage hier drin. Also, funktioniert die Software auch für komplexe x86 Software wie die Intel Management Engine? Also das Framework selber führt keine Software selber aus. Es verwendet darunter liegende Tools, bzw. andere Tools und Targets, um die Software auszuführen. Wenn ihr spästisch GDP auf eurer Maschine verwendet, dann habt ihr ein passendes Tool. Was ihr wahrscheinlich machen müsst, ist die Registerdefinitionen etwas anpassen innerhalb der Architektur Definitionen, innerhalb der Architektur Abstraktionen, aber es sollte gehen. Nächste Frage, Mikrofon 4. Ich habe noch nicht von Panda gehört, aber man kann Ausführungen aufzeichnen und wieder abspielen. Das inkludiert auch Parzella-Ausführungen. Können wir da auch auf echten Devices hin und zurückspringen? Ja, das kann man auch für es Debugging verwenden. Ursprünglich ging es damit nur darum, Software zu reverse-engineern, direkt auf dem Emulator ausgeführt wurde. Ich weiß nicht, wie weit die Entwicklung da ist, aber sie arbeiten daran, dass man das auch zum Debugging verwenden kann. Im Generellen, während man das wiedergibt, kann man sich immer mit GDP oder einem anderen Tool da reinhängen und das für seine eigenen Zwecke analysieren. Danke. Hat das Internet noch weitere Fragen? Dann noch mal Mikrofon 4. Als Allererstes. Ich habe zwei Fragen. Ist Panda jetzt veröffentlicht worden? Sie sind noch dabei, das Papier darüber zu veröffentlichen? Nein, Panda ist draußen. Ist offen Open Source und wir haben eine modifizierte, instrumentierte Version in Avatar 2, aber das kann man auf GitHub kriegen. Und zweitens, ich erinnere mich daran, dass es ein Problem mit Avatar 1 gab. Es war langsam. Und ich würde gerne wissen, was sind die Verbesserungen in Avatar 2 diesbezüglich? Das ist eine wunderbare Frage. Wir haben da ... Wir haben die Geschwindigkeit deutlich verbessert. Man hat es hier nicht gesehen in der Demo, der Aufzeichnung der Ausführung hier. Aber sagen wir in Avatar 1 war der Hauptfaschenhaus die Speicherinteraktion mit physischer Hardware. Wir hatten einige Benchmarks. Das Transferieren von 40.000 Pages hätte in Avatar 2 bis 5 Minuten gedauert und hier hat es ein paar Sekunden gedauert. Es ist eine wahnsinnige Verbesserung, aber immer noch nicht gut genug für Echtzeit-Anwendungen. Okay, next question goes to microphone 2. Nächste Frage bei microphone 2. Embedded systems rather often have real-time components. Embedded systems haben häufig Echtzeit-Komponenten. Könnte man da z.B. in Thread to just analyze Thread reinhucken, um die nicht zeitgerichtlichen Teile reinzucken? Ja, sollte möglich sein. Ich meine, generell müssen wir die Echtzeit-abhängigen Embedded systems noch genauer anschauen. Wir haben das bisher außerhalb unseres Rahmens gehalten, aber wir wollen das in der Zukunft noch generell anschauen. Real-time-critical parts may be just working. Ich denke, die nicht zeitkritischen Teile könnten einfach schon funktionieren. Danke schön. Okay, Internet. Ich würde gerne wissen, ob Internet mit den MIPS zu Avatar 2 wie lange es mit den MIPS-Support braucht. Gibt keine Roadmap im Moment. Wir haben damit begonnen, das zu implementieren. Wir arbeiten auf der Seite etwas daran, aber wenn jemand sich meldet und damit helfen will, dann sind wir noch so froh. Wir können euch sagen, was gemacht werden muss um MIPSupport zu ermöglichen. Generell werden wir arbeiten dran. Sorry, ich kann dir da jetzt keine genaue Zeit sagen. Okay, weitere Fragen? Nein? Vielen Dank euch allen. Dann danken auch wir euch, dass ihr uns zugehört habt hier in der deutschen Übersetzung dieses Talks zu...