 Jetzt ist es meine große Freude Dominik und Kate vorzustellen. Die sprechen über das öffnen geschlossene System mit Glitchkits. Sie haben etwas Interessant aussehen der Elektronik mit sich gebracht. Wir sind gespannt zu hören, wie sie uns dabei helfen werden, unsere Geräte zu befreien. Also ein warmer Applaus für Dominik und Kate. Ich bin Dominik, das ist Kate. Das sind unsere Gesichter, mein Groß. Und unsere Twitterhandels, falls ihr live tweeten möchtet, wie schrecklich dieser Vortrag ist. Ich arbeite für offensichtlich im Software & Firmware, für embedded Systems wie Hacker of Great Fat. Was so erzählen wir, du bist? Ich hoffe, mein Mikrofon funktioniert perfekt. Ich bin nicht wirklich in der Infosecurity-Szene. Ich bin ein Reverse-Engineer. Ich mache Projekte, mit denen man Informationen über Projekte kriegt und in die reinschauen kann. Und ich helfe Leuten, über verschiedene Systeme zu lernen und einen Fuß halt, die für zu kriegen. Und das hilft. Und wir haben unser gemeinsames Projekt. Das ist der Great Fat, den maintainen wir gemeinsam. Wir kommen also zu diesem Vortrag von Leuten ausgehend, die im Gegensatz zu uns tatsächlich Infosec-Menschen sind. Ich bin Ingenieurin und habe ein bisschen mit der Hacking-Kultur zu tun. Und worüber wir heute hier sprechen wollen, ist ein Tool, mit dem wir Leuten helfen wollen, ihre Systeme besser kennenzulernen. Und wir wollen damit helfen, dass Leute Sachen aufmachen können. Und wir freuen uns darauf, wenn Leute diese Tools dann auch benutzen, um damit ihre Geräte zu öffnen. Und deswegen machen wir diese Werkzeuge eben auch open source und verfügbar für Leute. Und wir wurden unterstützt von Micah Elizabeth Scott. Die wunderbare Sache macht. Und es sind auch ein paar Sachen in dieser Präsentation, die ihre Arbeit sind. Colin Nufflin ist sehr erfahren mit Glitching. Und wir sollten uns auch bedanken bei Great Scott Gadgets, die uns ermöglichen, zu Veranstaltungen videoser zu kommen und hier Zeit zu verbringen und unsere Arbeit vorzustellen. Wir sind jetzt nicht absolut an der Schwerspilze der Technologie, sondern wir sind Werkzeugmacher. Und diese Leute sind diejenigen, die die Wege überhaupt erst freigeräumt haben, auf denen wir dann schreiten konnten. Ich habe einfach hier Colin's World aufgenommen, dass das fantastisch was er gemacht hat. Die Software ist großartig und die Tools, die Werkzeuge. Und ich habe keine Ahnung überall, das ist Glitching. Und wir haben es rüber unterhalten, das ist wirklich cool. Es wäre großartig, wenn irgendjemand sich daran auskennt, zum Beispiel ich, das aufnehmen könnte und dann eben ein System zum Glitching bekommen, sie kann. Und viele Sachen kamen aus den Urteilungen mit diesen beiden Leuten. Das ist wirklich großartig. Und hier ein bisschen Hintergrund, warum wir das machen? Das ist jetzt das Board für ein HDMI-Switch, außer dass es vor ein paar Monaten benutzt hat. Das ist ein sehr groß, nervigen Fehler, ein Videospiel spielt, dann würde es halt flickern. Und was man dann machen würde, was das jeder tun würde, der sich daran auskennt, der hat es auseinander gebaut und versucht rauszufinden, wo man das Problem legt. Und dann gibt es die ganzen Hot-Plug-Signale, die eben sagen, ob ein Kabel drinsteckt oder nicht. Diese Signale, die diese Signale übermitteln, hatten immer ein bisschen Störungen drin. Und immer mal wieder gab es halt Fehler, obwohl kein Kabel Fehler drin war, dass ein Kabel drin war. Und dann hat das halt so ein Switchen, obwohl auch geführt. Das ist ein Intel 8051 Microcontroller. Und wenn ich die Firma für diesen Microcontroller gehabt hätte, dann wäre das wahrscheinlich 10 Minuten Arbeit gewesen. Also ein bisschen debonzen, ein bisschen Neues filtern. Und dann hätten wir das einfach sehr schnell gefixt. Aber ohne die Firma, mussten wir halt die Firma von Null aufbauten oder halt andere Hecks benutzen, um dieses Gerät zum Arbeiten bekommen. Manchmal ist die Lösung einfach 50 Euro auszugeben oder eben ein Clitching-From-Mark zu bauen. Das ist ein anderes Gerät, mit dem ich gespielt habe. Das ist das innere für eine Thermal-Kamera. Das ist eine relativ günstige, 200-300-Dollar-Kamera. Und es wird ziemlich cool. Es hat eine SD-Karte, wo die Bilder drauf gespeichert werden, ein USB-Port. Der Dünne-Lubin ist so benutzt, um die Bilder auf einem Computer hochzuladen. Und hat einen ziemlich starken großen Microcontroller drauf. Und das wäre großartig, so ein Board zu benutzen für Exponente zu benutzen, wo man Thermaldaten rein nimmt und ein PC weiter leitet. Aber die Designer haben da nicht so drüber nachgedacht über diesen Use Case. Und das heißt, obwohl man so einen großen Microcontroller drauf hat, mit 512 Kilobytes Fleisch, der nur ganz wenig benutzt wird, kann man so viel nicht machen mit der Firma, die da drauf ist. Deswegen haben wir Glück, dass die Firmware in einer zugreifbaren Form ist. Man kann die per USB auslesen oder ändern. Und wenn man sich dieser Teil anschaut, dann sieht man hier am Anfang eine ARM Cortex-Vector-Tabelle am Anfang. Am Anfang davor allerdings noch sind Metadaten. Und da kann man dir jetzt natürlich raten, was bedeuten wohl diese Metadaten, was könnte das sein? Ist das vielleicht eine Länge? Also wie viele Daten jetzt folgen? Das sind so die Sachen, ohne wenn man die nicht weiß, kann man ja noch nicht mal die Firmware zum Bootloader hochladen. Und der Bootloader, der ist natürlich auch bei diesem Firmware-Updates dabei. Der weiß, wie diese Uploads funktionieren. Also wenn man den Bootloader hat, wenn man da irgendwie rankommt, dann kann man da reingehen und den Code reverseingenieren und herausfinden, welche Struktur diese Metadaten haben. Und durch das Gletschen konnten wir eben eine Verletzlichkeit herausfinden. Und das hat uns dazu ermöglicht, dieses Gerät zu hacken. Aber das wäre natürlich viel einfacher gewesen, hätten wir die Möglichkeit gehabt, den Bootloader einfach direkt rauszufinden. So, ich glippe dir den Klicker. Viele Sicherheitsprobleme, die wir haben, kommen daher, dass wir von irgendwelchen Voraussetzungen ausgehen, die dann nicht stimmen. Zum Beispiel, ja, der Code, den kenn ich, der funktioniert, aber funktioniert er gar nicht. Zum Beispiel das Stringcopy. Das ist eine schlechte Idee, dem übergibt man eine Länge. Und dafür muss man natürlich wissen, wie lang ist die Eingabe und entsprechend wird dann Platz auf dem Stack reserviert. Und ich habe schon von vielen Hackern gehört, dass das keine gute Idee ist. Und hier ist noch ein Paper. Da geht es um... Dieser Paper geht so um Pasa und stellt sich raus, dass Leute sind ziemlich schlecht mit verschiedenen Dateiformaten herauszukommen. Also man muss eine Annahme machen, dass wenn in einem Datenblatt, man sagt, versorgt diesen Chip mit einer Spannung von hier bis hier, dann muss man die Annahme treffen, dass die Stromversorgung konstant und gut ist. Das ist sehr begildet für eine Clock. Also man nimmt die Annahme, solange die Clockgeschwindigkeit in diesem Bereich ist, sollte alles gut funktionieren. Man muss diese Annahme treffen, dass die Clock, also die Clock, also die Uhr, die Zeitgebung eben sich nicht dramatisch verändert. Und das ist wo jetzt eben das Clitching ins Spiel kommt, was wir machen ist. Wir machen diese Annahmen kaputt und benutzen das, um eben das Verhalten eines Teils zu ändern. Und das macht man einfacher, indem man diese Annahmen anschaut und eben sich darauf verschränkt. Das würde man einfach davon nicht mehr ausgehen, dass man einen Strang bekommt, der schön mit null Termination eine bestimmte Länge hat. Oder eben auch davon, dass diese elektrischen Spezifikationen einfach nicht eingehalten werden, wenn da steht, wie die Clock aussehen soll. Wenn man diese Unterstellung dann einfach mal hinterfragt, wenn man was ganz anderes macht, dann landet man bei den exploitativem Verhalten. Und das Hauptding ist, es gibt natürlich Methoden, um so ein Angriff zu vermeiden, aber die sind eben teuer, die sind komplex. Und die meisten Geräte versuchen eben so günstig wie möglich zu sein, mit Mikro-Kontrollern, die dann eben in einer Kameranlage landen, damit die möglichst günstig ist. Und wenn man diese ganzen Angriffe vermeiden wollen würde, würden die Preise sehr stark steigen. Also die meisten Teile, die meisten Bauteinsteine, die wir da draußen sehen, haben überhaupt gar keinen Schutz vor irgendwelchen solchen Angriffen. Und wie funktioniert es dieses Glitchen? Wer von euch hat denn schon mal was geglitched? Das sieht so aus, als wäre das ein großer Teil der Zuhörerschaft. Und ich habe jetzt auch vorne, weil da was gemacht, ich möchte euch mal ganz kurz erklären, wie das funktioniert hat. Prinzipiell reden wir über zwei Hauptteile, zwei Hauptangriffe, über die wir reden. Das eine ist die Clock-Glitching. Und das andere ist Strom-Glitching. Und hier beispielsweise haben wir ein Clock-Signal. Da sieht man diese netten Clock-Pulse. Wie manche sich das vorstellen, was zum Beispiel in einem Prozessor passiert, immer wenn ein Clock-Pulse kommt, passiert alles auf einmal. Was aber in Wirklichkeit passiert ist, dass die Sachen natürlich hintereinander passieren. Also zuerst wird der Programmcounter erhöht und dann wird die Instruktion gelesen. Und dann wird das interpretiert, ist das eine Addition beispielsweise. Und all diese Sachen passieren eben nacheinander. Und wenn wir mal einen Blick in die Schaltung selber werfen, wie alles hintereinander passiert, sehen wir eben, das dauert eine Zeit und das ist quasi fertig direkt bevor der nächste Clock-Impulse kommen würde. Aber was passiert, wenn wir diesen Clock-Pulse beschleunigen? Also wenn wir einfach den Clock-Pulse schon wieder runterziehen, bevor der Clock-Pulse überhaupt vorbei ist, bevor diese ganzen Instruktionen vorbei sind. Und dadurch können wir erreichen, dass der Instruktion-Pointer erhöht wird und das Ergebnis dieser Berechnung mit dem Passiert einfach nichts. Dann geht es weiter, aber die letzte Instruktion ist einfach nicht passiert. Und damit können wir sozusagen einzelne Teile des Codes überspringen. Okay, Spannungs-Cleaching. Also in Chips sind ganz viele Transistoren. Was ist das? War das ein Einsatz? Nein. Ich weiß noch ein bisschen mehr, ja. Ich mache nicht so viele Halbwehre. Aber diese Transistoren, wenn die stabil, also wenn sie nicht gerade schalten, dann ziehen sie sehr wenig Leistung. Okay, ich muss nochmal nachfragen. Aber wenn sie switchen, dann ziehen sie viel mehr Strom. Also wenn man das machen kann, dass wenn sie switchen, dass man dann sehr schnell die Spannungen ändert, die man mit der Medi-Mens-Chip versorgt, dann hat man viel größere Chance, denn es ist beeinflussen, anders als das eben gedacht ist. Also wenn man ganz plötzlich die Strom runterdreht, zum Beispiel gerade, wenn ein Check-Summel berechnet wird, dann ist es sehr viel wahrscheinlicher, dass die Werte eben falsch rauskommen. Was man daraus mitnehmen kann ist, dass wenn man ein Teil des Chips hat, der eben irgendwas berechnet, oder eine Status-Zustandsänderung macht, dann kann man da diese Geräte viel einfacher kaputt machen durch das Heruntersetzen der Spannung. Und wenn der Chip gar nichts macht, dann hat das nicht so viel Auswirkungen. Es sind nur die Sachen, die sich in dem Moment ändern. Zum Beispiel, dass Registern im Grade geschrieben wird oder was er gerade berechnet, dass sich das ändert. Damit sind wir damit durch. Fühlt sich irgendjemand jetzt informierter als noch vor zwei Folien? Wow. Das wäre natürlich viel besser, wenn das nicht gerade mein Arbeitgeber wäre. Hier haben wir mal was, ein Stück Hut. Wir haben da einen Puffer und wir wollen diesen Puffer irgendwo hinschicken. Wir haben da eine Funktion, Sandbyter ist die. Das ist hier links aufgeschrieben und rechts sieht man, wie das aussieht, wenn es kompalt wurde. Und jetzt stellen wir uns auf, wir wollen diesen Puffer verschicken. Aber wir wollen das System eben auch so beeinflussen, dass auch alles, was danach kommt, nach dem Puffer verschickt wird. Und da gibt es ein paar Stellen in dem Programm, die da interessant sein könnten. Das sollte man vielleicht auch wissen. Das ist Sandby, den ich geschrieben habe. Es ist so eine Mischung aus Risken und 8051 Assembler. Das ist möglichst alle Leute, die sich mit Assembler auskennen, verstehen können. Was wir als erstes machen, ist, wir multiplizieren. Das funktioniert besser auf dem schwarzen Hintergrund. Wir machen diese Multiplikation, um festzustellen, die Länge. Wenn wir hier angreifen, können wir eine Länge bekommen, die natürlich viel größer ist als dieses Ergebnis. Und wenn wir dann die Funktion aufrufen, bekommen wir eben viel mehr Daten. Und hier ziehen wir jedes Mal die Länge ab. Wenn wir diese Subtraktion so umbauen können, dass sie auf eine seltsame Art und Weise funktioniert, dann könnte es sein, dass wir eine viel größere Nummer in das Längenfeld laden und dann auch wieder viel mehr Daten bekommen. Wenn wir ein bisschen kriegen, dass dieser Jump übersprungen wird, dann wird beim nächsten Mal die Zahl negativ. Und dann ist es sozusagen nicht mehr 0. Und dadurch läuft das dann beliebig lange weiter. Und da haben wir eben die entsprechenden Stellen, wo wir eingreifen müssen, diese Instruktion so zu verändern, dass wir beliebig viele Daten übertragen können. Und danach kommt vielleicht ein anderer Speucherbereich. Da liegen dann vielleicht die Firmenwerte drin. Also vielleicht Daten, die der Gerätehersteller gar nicht unbedingt irgendwie in der Öffentlichkeit haben will. Und mit anderen Techniken könnte es euch dann auch hinkriegen, wenn ihr es findet, die direkt danach kommen. Sondern auch andere. Aber da ist natürlich bei allem das Timing absolut kritisch. Wir müssen genau wissen, an welchen Stellen das Gerät verwundbar ist. Und wir müssen genau an den Stellen was machen, damit wir den Effekt bekommen, den wir gerne hätten. Aber wir wissen natürlich vorher auch eben nicht, welche Glitche effektiv sind auf einem System. Das heißt, wir müssen viel experimentieren. Das heißt, wir brauchen eine sehr präzise Art und Weise, um die Zeit zu messen, relativ zu der Ablaufzeit des Programms. Und dieses Diagramm zeigt einfach auf diesem Zeitstrahl die ganzen roten Striche, zeigen die Möglichkeiten, wo wir den Programmablauf beeinflussen können. Und das eine ist die Multiplikation. Und da sind überall die Decrement-Operationen. Und ganz am Schluss haben wir diesen Jump, diesen Sprung, wenn wir mit dem Loop fertig sind. Und da haben wir nur eine einzige Chance, an der Stelle ihn sozusagen zu überspringen. Danach haben wir 0 getroffen, und dann ist es vorbei. Das sieht jetzt vielleicht ein bisschen synthetisch aus. Solche Schleifen sieht man hoffentlich nicht in allzu vielen Programmen. Aber das ist genau das wie Hardware. Beispielsweise, wie ein DMA-Kontroller funktioniert. Da zählt jemand einfach die Länge immer runter und die Adresse hoch. Also selbst, wenn das jetzt hier gerade synthetisch aussagt, passiert das absolut auch in echter Hardware. Und wenn man ein DMA-Kontroller hat auf einem Micro-Kontroller, was macht er wohl, wenn er ein Fehler trifft? Der kann ja dann nicht irgendwie eine Dialogbox aufmachen. Es ist ein Fehler aufgetreten, sondern er macht einfach genau das, was ihm gesagt worden ist. Das ist ein kleines Python-Script, das Kate hier zusammen gehackt hat, das mit dem DMA-Kontroller spricht. Und das macht nur und programmiert es an den DMA-Kontroller. Das sieht man nicht in jedem Micro-Kontroller, aber diese Fehlerprüfung ist eine ... Also die CPU operiert auf dem Bass und wird benachrichtigt, wenn ein Speicher abgefragt, dass es gar nicht gibt, aber ab und zu ein DMA-Kontroller hat gar keine Fehlerprüfung, weil es keine Möglichkeit gibt, diese Fehler abzufangen, wenn es auf Hardware ausgeführt wird. Er macht also auch völlig problemlos einfach genau das, beliebig viele Nullen zu lesen. Und hier haben wir jetzt 128 bytes ausgelesen. Aber wenn ich jetzt das gleiche nochmal mache, von einer anderen Speicherstelle, mach mal 0, 0, 0, 0, 0, 0, 0. Da gibt es einfach Speicherbereiche, also zum Beispiel Reserviertebereiche, die es gar nicht gibt, dann gibt es kein Fehler. Er gibt einfach genau das aus, was wonach wir ihn fragen und wenn da einfach nichts ist, dann kommen einfach uns in die Gewerte. Dann kommen halt einfach nur Nullen. Wenn wir jetzt aber den DMA-Kontroller überzeugen können, dass er ein Teil des Speichers lesen soll und er mit einfach weitermachen, selbst wenn er an eine Stelle kommt, an der er eigentlich nicht lesen dürfte, dann können wir einfach weiterlesen und das DMA-Kontroller macht das, was wir wollen und wir lesen diese Daten aus. Wir können also zum Beispiel eine Adresse ausgeben, die ganz am Ende des Speicherbereiches ist. Damit lesen wir, sozusagen, das absolut letzte byte aus und die 127 bytes, die danach kommen. Also immer, sozusagen, eine Ziffer höher und dann fällt er natürlich zurück auf Null und fängt er an ganz am Anfang des Adressbereichs zu lesen. Und wenn wir jetzt hier Werte übergeben können, die eben sehr, sehr lang sind, dann können wir den Speicher komplett auslesen und am Ende rollt er über und fängt vorne wieder an. Also mit 32 bits zahlen. Da muss man nur an der Stelle, wo er auf Null überprüft, einmal springen und dann ist es eben minus 1 und er liest dann weiter und weiter und weiter und wir kommen einmal komplett rum. Einer der grundlegenden Technologie-Teile, die wir benutzen sind, oder unsere Arbeit aufbaut, ist dieser Chip Whisperer. Das ist the light version, das ist die billigere Version davon. Das ist ein Werkzeugkit, mit dem man Stromside-Channel-Analysis machen kann. Es gibt Module für Clock-Clitching und Strom-Clitching. Es gibt eben Software, die hilft dir, diese Glitches genau in richtigen Zeitpunkten zu machen. Dieser Synchronisierungspunkt muss eben spezifiziert werden. Also der Chip Whisperer Light kann das eben nur zwei Racing-Edge-Signale zu triggern. Es geht also nicht damit, dass man beispielsweise sagen kann, ich möchte das basierend auf einer USB-Kommunikation machen, sondern man kann nur sagen, dass an einer bestimmten Stelle, wo ein bestimmter Pegel ansteigt oder abfällt, also müsste man dann eine eigene Hardware machen, die an einer Stelle, die man braucht, eben ein entsprechendes Signal reagiert. Man bräuchte dann beispielsweise Hardware am DMR-Controller, die zu einem bestimmten Zeitpunkt ein Signal rauskippt und dann weiß der Chip Whisperer, okay, jetzt lege ich los. Wenn ihr hier mal das Datenblatt eines typischen Mikro-Kontrollers anschaut, diese ganzen kleinen Boxen am Rand, das sind die Peripheririräte, das sind die U-Arts oder die analog-digital Wandler, die digital-analog Wandler, und wenn wir jetzt ein Gerät haben, wo es möglichst viele von diesen Peripheriräten belegt sind, da ist dann eine SD-Karte angeschlossen, wenn ich da rein will, dann brauche ich eben spezielle Hardware, die entsprechend feststellen kann, wann werden diese Geräte genutzt, und dann brauche ich eben spezielle Hardware, die man da ranhängen kann, und da weiß ich dummerweise auch nicht, ob das überhaupt funktioniert, und deswegen hätten wir natürlich gerne auch ein Werkzeugkasten, die man einfach an USB-Port hängen kann. Lass uns heute mal USB ausprobieren, und damit kann ich dann nach kurzer Zeit wissen, dass mich mit USB-Zugriffen entsprechend mein Timing machen kann, sodass ich interessante Effekte bekomme. Also, dass da auch noch einmal gearbeitet in den letzten Monaten, das vereint jetzt sehr viele diese Feature, die wir benutzen wollen, und ich denke zum Beispiel verschiedene Synchronisierungsfeatures. Das ist einfach noch ein Diagramm von Glitch Game, aber wir gehen in eine Sekunde ins Detail. Das ist unser Open Software Framework, das funktioniert mit anderen Open Source Hardware, und hilft dir von einem System zu so schnell wie möglich anzugreifen. Damit können wir beliebige Transistoren auch simulieren, anstatt dass wir selber Hardware erstellen müssen, die man dann an bestimmte Busse anschließen kann, sodass man dann eben auch diese ganzen Modifikationen, wenn sie funktionieren, an all diesen Bussen anwenden kann, und damit dann eben auch schnell ändern, welche der Busse man entsprechend angreifen will. Wir möchten gerne die Anzahl der Hardware, die man braucht, um Hardware-Hacking zu machen, auf Null runterbringen. Das funktioniert natürlich nicht, aber wir haben es so klein wie möglich gemacht, und eben hier ein Prototypen gemacht, festgestellt, das funktioniert, dann haben wir wieder ein paar Teile Kupplungskondensatoren, und haben gesehen, okay, es geht auch, und was wir jetzt am Ende haben wollen, ist eben ein Gerät, was viele von diesen Pirefiri-Geräten simulieren kann, und das wird das sozusagen von den entsprechenden Datasheets aus nachbauen können in Software, und das ist dieses Gerät, das ist der GreatFat, und der ist ein Mikro-Controller-Board, das den haben wir nicht verstanden, Design-Tat. Im Endeffekt ist das ein Breakout-Board mit all diesen Anschlüssen wie zum Beispiel dem USB-Kampf, über den wir vorhin gesprochen haben. Die Designs gibt es momentan auf GitHub, auf dem Hardware, und wie es dazu kam, dass es eben dieses Board gibt, war bei der Entwicklung vom HackRF, da haben wir eben diesen einen Controller entdeckt, und festgestellt, oh, da kann ja tolle Sachen, den würden wir gerne auch noch mal in einem anderen Zusammenhang benutzen, dann könnte man ja zum Beispiel einfach in den USB-Port stecken, und dann könnte man bestimmte Protokolle, SPI, einfach direkt sprechen, und diese große, artige Plattform, da kann man dann eben diese ganzen Features draufbauen, mit Ad-On Boards, mit sogenannten Shields. Es war jetzt ein kleiner Wortwitz, den man nicht übersetzen kann. Eine Sache noch, als wir über Greatfab gesprochen haben, über dieses Board, wenn ihr ein Radio-Batch habt, also wenn ihr auf dem TTC-Camp wart, dann habt ihr dieses Teil im Endeffekt, dann habt ihr dieses Teil im Endeffekt, weil die Software, die wir geschrieben haben, die funktioniert auf diesem Batch, allerdings ist das nicht die empfohlene Art und Weise, weil eben viele von den Ports leichter sozusagen auf dem neuen Board verfügbar sind. Also, lasst uns mal kurz durchgehen. Es gibt drei Hauptteile davon. Als erstes haben wir den Event-Router, und diese lässt uns verschiedene Sachen nehmen, die in der Ziel-Hardware passieren, und sie in interessanten Weise zu kombinieren. Also, wir haben... Vielleicht möchten wir einfach nur das machen, wenn das alles passiert, oder wir möchten mit der Clock was machen, wenn diese, wie gesagt, GPO angeht, oder wir möchten diese Events eben zusammensteckeln und irgendwas Komplizierteres zu machen. Zum Beispiel von dem Hardware-Zustand. Also, eine allgemeine Aufgabe ist, wenn man diese Geräte benutzt, dass man Sachen synchronisiert über verschiedene Aufgaben. Zum Beispiel, man möchte zum Beispiel ein USB-Gerät angreifen, man macht einen Strom an, und man wartet dann für das System zu booten. Man wartet, dass es der Microcontroller gestattet ist, und an diesem Punkt kann man dann eine Stimuli anmachen und einen Angriff durchführen. Man hat ein Gerät, das man anmachen muss, und man hat eine Clock, die das Gerät reibt, aber man möchte diese Clock eben erst an einem gewissen Zeitpunkt anmachen. Dieses Event-Routing-System ist das Herz von Glitchkit, und es hilft dir, all diese verschiedenen Informationen, Stimuli zu nehmen und eben andere Sachen zu treiben. Wenn das jetzt angeht, dann möchte ich auch eine Clock starten. Ich möchte jetzt warten, bis das System geboten ist, und darauf warte ich darauf, dass ein GPU angeht. Wenn das dann passiert, dann möchte ich noch ein Stimuli draufwerfen. Und ganz am Schluss, wenn das passiert ist, dann möchte ich eben ein Glitch auslösen. Das, was alle all diese verschiedenen Teile miteinander verbindet. Es gibt auch eine Clock-Management-Section, ein Teil, das macht so Sachen wie sicherzustellen, dass all die verschiedenen Teile ihrer einzelnen Systeme eine gleiche Clock haben. Also alles auf der selben Zeitbasis funktioniert, passiert. Und... dass alles auf der selben Clock passiert, wie das Zielgerät oder eben der Chip ist, weil... Also, dass einfach alles, was passiert, ist, sozusagen, entsprechend aufeinander aufgebaut. Und das ist besser, das natürlich direkt zu haben, als wenn man auf externe Clocks angewiesen ist. Wir wollen ja eben die Clock genau haben, um das entsprechend Clock Glitchen zu können. Müssen wir das natürlich auch verändern. Entsprechend funktioniert dann die externe Clock eben auch nicht. Die ist dann eben nicht mehr stabil deswegen. Wenn man jetzt zum Beispiel irgendwas hat, was ganz, ganz genaues Timing braucht, dann ist es natürlich sinnvoll, eine gemeinsame Clock zu haben, sodass sie alle wirklich genau gleichzeitig miteinander funktionieren. Weil, wenn wir da ein Offset haben, eine Verzögerung zwischen dem Start und einem bestimmten Punkt, das es dann wirklich konsistent ist, was dann kommt, wenn wir beispielsweise ein Bootloader glitchen wollen, dann müssen wir vielleicht auch direkt den Chip anschalten und dann eigentlich direkt sofort irgendwas machen. Aber manchmal wollen wir eben... Die hat wir auch proben. Also, wir wollen sie erstmal ganz normal starten und erst wenn bestimmte Geräte hochkommen, sozusagen irgendwas machen. Also beispielsweise können wir hier ein USB Host emulieren und da zum Beispiel ein Flaschgerät dranhängen. Und dann warte ich vielleicht einfach darauf, bis eine Anforderung kommt von dem Gerät und das kann eben lange dauern, dann muss das Gerät das innommogiert werden und da hängen vielleicht fünf oder sechs USB-Geräte dran und dann ist es völlig unklar, wie lange es braucht, bis, sozusagen, wir an der entsprechenden Stelle sind. Wir warten also, sozusagen, bis alles fertig ist, bis wir ein bestimmtes Kommande bekommen und dann schicken wir an das GlitchKit die Information jetzt fängt der Timer an zu laufen. Also diese ganzen Hardware-Funktionen, die kann man eben davon abhängig machen, dass man einen bestimmten Befehl bekommt. Ich werde das erst machen, wenn ich mein Deskriptor bekommen habe zum Beispiel, sodass ich dann eben weiß, an welcher Stelle davon abhängig eben der Zeitpunkt kommt, wenn das Gerät angreifbar ist. Und manchmal ist genau dieser Stimulus, auf dem man erwarten muss, dass man eben gerade genau eine Response, eine Antwort auf ein bestimmtes Kommando erwarten möchte. So können wir das dann eben auch mit dem Routing-System verknüpfen. Also man kann zum Beispiel das USB-System anmachen und dann schickt man ein bestimmtes Kommando raus und daraus kann man dann wiederum neue Ereignisse generieren, also zum Beispiel eine Glocke anschalten. Dadurch, das ist uns ermöglicht, mit dem Gerät für längere Zeit zu interagieren und dadurch haben wir ein deutlich größerer Angriffsoberfläche, weil wir an jeder Stelle des Coats, der in den Geräten läuft, beliebige USB-Funktionalitäten abwarten, weil wir natürlich nicht wissen, welcher der verschiedenen Teile in dieser Kommunikation am angreifbarsten ist. Das ist eben vielleicht auch gar nicht unbedingt so klar, alles definiert. Manchmal werden diese Sachen ja eben auch ganz schnell zusammengeschmissen am Tag, bevor sie dann eben auch in die Produktion gehen müssen. Da heißt es dann okay, was solls, ziehen wir einfach eins von einem Integer ab. Und dann hat man dann eben ein Fehler, wo man eigentlich auch erstmal hinkommen muss, an dem man erstmal finden muss. Es kann ja auch einfach sein, dass in dem Gerät erstmal der Speicherbus an einer bestimmten Stelle runtergehen muss. Das heißt, dadurch, dass wir das Projekt über die lange Zeit beobachten können, erhöhen wir deutlich die Angriffsoberfläche. Okay, und jetzt kommen die eigentlichen Trigger. Das ist das, wofür wir das Gerät eigentlich haben. Das sind diese teilweise wirklich sehr komplizierten Verfahren. Also zum Beispiel haben wir den einfachen Ereignis Trigger. Da machen wir dann sowas wie einfach diese Linie, diese Signal geht hoch oder runter oder fünfmal hoch. Dann können wir an dieser Stelle einfach etwas auslösen. Wir können sozusagen auch sagen, wir machen irgendwas direkt nach dem. Einen Signal zum fünften Mal hoch geht oder direkt, wenn es zum vierten Mal erscheint. Diese einfachen Ereignis Trigger haben eine ganz einfache bulge Kondition. Die kann man auch beliebig miteinander verschalten. Das komplizierteste, von dem ich vorhin gesprochen habe, ich habe einen Mikrocontroller, der liest Informationen von einem externen Flash und an einer Stelle in diesem Lesevorgang. Möchte ich was machen? Da könnte ich natürlich einen SPI Flash nachbauen, der so tut, als wäre ein SPI Flash. Und dann kann ich aber stattdessen auch einfach sagen, okay, das verhält sich jedes Mal gleich. Beim vierten Lesezugang oder beim 24. Lesezugang, wenn die Clock zum 24. Mal hochgeht, dann ist genau der Moment, auf dem ich sozusagen diesen Trigger ansetzen möchte und der ermöglicht dann an der Stelle beispielsweise die Clock zu starten oder ein anderes System mit einer Clock zu versorgen, die ganzen zeitbasierten Sachen einfach auch einen bestimmten Stimmelust zu erzeugen, USB-Pakete zu verschicken und man will ja, dass man sozusagen an irgendeiner Stelle das Gerät einschalten kann und dann eben warten, bis irgendwas passiert, also bis zum Beispiel die USB-Kommunikation beginnt oder man hat auch eine LED, wo man dann sagen kann, okay, sobald diese LED angeht, passiert irgendwas. Das funktioniert leider gerade nicht. Aber da sind wir natürlich dran. Als nächstes haben wir die seriolische Stelle als Trigger. Also da haben wir dann eben die ganzen Geräte, wie beispielsweise einen Router, den ihr von eurem Internetanbieter bekommt. Die haben eine seriolische Schnittstelle und da kann man dann eben diese seriolische Schnittstelle an den Schiffwesferer anschließen und dann kann man eben auch die Zeit davon abhängig machen, wann eine bestimmte Meldung kommt. Oder man nimmt den Trigger-Input um eben dein Logic-Analysis benutzen, also die D-Bug-Information eben außerhalb des Glitchens zu kommen. So, eine der Sachen, der Arbeit, die wir gemacht haben, vor ein paar Jahren, bevor jetzt, war das die Inspiration, die wir darauf gezogen haben von einer Freundin, Micah. Sie hatten USB-Tablet, das sie hatte, und wir wollten das benutzen als generelle Code-Ausführungs-Engine, um die Idee aus umzusetzen. Sie wollte eben diesen RFID-Reader mit der eigenen Firma zu betreiben und eben RFID-Token zu lesen, dass ganz nahe an dieses Tablet gehalten wird. Das macht man nochmal, also dieses Ding benutzen wir normalerweise mit einem normalen Zeichenstift, und wenn man den Stift nah ranhält, dann erkennt das der Chip eben. Und dadurch kann man eben Informationen kommunizieren. Ja, also ich bin ein Stift, ich habe jetzt so stark getroffen und diese Art Funktion, es sieht so aus wie ein RFID-Chip, der auch so eine gewisse Modulation macht. Also der Pen empfängt ein bisschen Strom, Energie und kommuniziert dann, wo es gerade ist und auch wie stark es eben gedrückt wurde. Und RFID empfängt Energie und sendet dann die Informationen zurück. Und es ist ja die Idee, dass diese zwei Sachen eben genau ähnliche Sachen an der Hardware sind. Und sie wollte das eben eben, sie wollte eben Firma-Execution auf diesem Gerät kriegen und es hat sich den angeschaut und hat gesehen, dass es eine spezielle Microcontroller drauf ist, eine komplette eigene Architektur. Und es hat ein Debug-Interface an der Schnittstelle und das war zwar ander, aber es war nicht dokumentiert. Also es war dokumentiert und da konnte sie eben an die Firma kommen. Was sie gemacht haben, sie liebt es einfach total, irgendwie in diese Geräte reinzugehen und sozusagen, das als sich zu nutzen zu machen, wie die USB-Pakete gesendet werden und wie man das dann eben auch für Angriffe nutzen kann. Also man sieht hier jetzt, wie USB funktioniert, es wird einen Kontrollbefehl geschickt. Man schickt erst den Kommando. Das passiert in einem Zustand der Z-Up-Zustand heißt. Und der sorgt eben dafür, dass USB kompliente Geräte mit irgendeiner Art von Beschreibung antworten, die sagt, was sie so sind. Also zum Beispiel sagen sie mehr oder weniger, hallo, ich bin ein Vakuum-Tablet und dadurch weiß das Betriebssystem dann eben durch diesen Device-Deskriptor, was es für ein Gerät ist. Und kann eben auch anzeigen, ja, da wurde jetzt ein Vakuum-Tablet angeschlossen. Und um eben ein komplientes Gerät zu sein, muss jedes Gerät so eine Beschreibung senden. Und dafür nimmt man ein kleines Stück, ein kleines Stück, der erst im Speicher liegt, was wird dann einfach per DMR rausgeschrieben wird. Also hier gibt es dann so ein kleines Paket, das wird dann als Antwort einfach rausgeschrieben. Und dann gibt es die Bestätigung, dass dieses Paket empfangen wurde. Da sehen wir also sozusagen der Set-Up, dann der Deskriptor und dann die Antwort, der Deskriptor ist angekommen. Und in diesem einen Paket in der Mitte da hat sich das Gerät in E-Machine ein sehr, sehr langes Paket zu verschicken. Das könnten an der Stelle also auch mehrere Pakete sein, die dann zusammen eine Meldung ergeben. Also wenn man 512 Bytes beispielsweise hat, dann könnte man die auch in mehrere kleinere Pakete hintereinander zerlegen. Und wenn wir uns anschauen, wie eine USB-Gerät funktioniert, meistens so ähnlich wie der Host-Controller. Es gibt eine Link-Liste, da stehen immer drin, wie viele Bytes übertragen werden müssen und eben in welchen Speicherbereichen die Daten stehen, die man übertragen will. Also immer die Länge und die Adresse. Und wenn ich hier anschau, wie der Deskriptor-Request sozusagen angelegt wird, dann sieht man, wie der Gerät mit tatsächlich einem kleinen DMA anfängt. Erst mal 256 Bytes von dieser Adresse rauszuschieben. Das ist das meiste, was auf diesen Bus passt. Das liegt eben daran, wie dieser Bus funktioniert. Dann wird die Länge jedes Mal verkleinert und die Adresse hochgezählt. Und das macht dann eben so lange, bis die Slang-File sozusagen bei 0 ist. Und bei USB gibt es eben keine Terminierung im Protokoll, sondern man schickt einfach ein Paket raus, was kleiner ist, als die Mindestlänge. Das schickt dann also hier sozusagen einfach noch ein 0-Bite Paket raus, um zu sagen, okay, hier sind wir fertig. Wenn man jetzt eigentlich hier anfängt mit Spannungsklitsches oder mit Zeitglitsches, mit Clockglitsches, dann sieht man, dass dann einfach man ein Paket verschicken kann, was größer ist als 0-Bite. Und dadurch wird dann einfach weiter übertragen und weiter übertragen immer in diesem Paketen. Und wenn wir eben ein Gerät haben mit so einem DMA-Kontroller, der funktioniert, wie die meisten DMA-Kontroller funktionieren, dann wird ja nicht bei einem bestimmten Segment dieses Speichers aufhören, sondern der läuft dann einfach weiter und überträgt den Gesamten Speicher. Um also an dieser Stelle das auszulösen, brauchen wir eben eine Möglichkeit, mit diesem Gerät zu interagieren. Und dafür habe ich dieses Gerät gebaut, den Face Whisperer. Das ist sozusagen die kleine Vorgänger-Variante. Und da ist einfach ein USB-Hoschip drauf. Und was der macht, ist mit sehr genauem Timing sich selber reinzusynchronisieren in die Ausführung dieses Tablets. Und an der Stelle dann eben USB-Pakete zu schicken und den Chip Whisperer zu starten, dass er eben kleine Pakete abschickt. Und damit konnte sie dann eben den Mikrokontroller glitchen und damit konnte sie eben dann auch Angriffe ausloten, die ihr dann am Ende ermöglicht haben, diese Firmware auszulesen. Und dadurch hatte sie dann eine neue Art gefunden, eben diesen Bootloader auszulesen, aus dem Gerät. Das hat sie natürlich gemacht, weil sie einen Hyperfokus hat und gesagt, okay, ich will diese Firmware sehen, ich bau da jetzt extra ein Gerät, nur um diese Fehler zu finden, um dann die Firmware auszulesen. Ja, an der nächsten Seite haben wir versucht, diese Idee zu nehmen und das so einfach zu machen. Zielschritt gab es damals noch nicht, als sie das gemacht hat. Also Design und Boah, diese ganzen Schritte, die sie durchgehen musste. Wir können das einfach nur mit diesem Python Code machen. Beide von uns lieben es, Technologie für Leute zur Verfügung zu stellen. Und einer dieser Ziele von diesem ist, was habe ich auch Michael versprochen, ist, dass wir nehmen diese ganze Technik, wo man so eine spezielle entwickelte Hardware braucht und verschiedene Ebenen des Verstehens von den Geräten und man kann das dann relativ einfach machen. Und das ist jetzt der Backend Code für das Gleiche mit GlitchKit. Das wurde in Python geschrieben, aber wir wollten eigentlich durchgehen, aber wir sind ein bisschen knapp mit der Zeit. Wir würden uns freuen, das mal zu erklären, aber wahrscheinlich nicht jetzt, aber das Wichtige ist, dass man das nicht immer schreiben muss. GlitchKit hat auch eine Oberfläche, wo man das sich einfach zusammenklicken kann und kann das also direkt in der Oberfläche konfigurieren. Okay, wir werden jetzt eine kleine Demo zeigen und dann werden wir noch ein bisschen über unsere Arbeit zeigen. Das ist jetzt die Oberfläche. Wir haben hier diese verschiedenen GlitchKit-Methoden, die eben in diesem GreatFat reden. Das gibt es sehr viele Kabel, die wir uns hier wahrscheinlich sehen können, auf unserem Tisch hier. Wir haben hier ein GreatFat und ein ChipWizPro, die mit unserer Target-Hardware verknüpft sind. Also, man wählt jetzt hier direkt aus, was man mit wem reden möchte. Also, der GreatFat, der USB-Stack liegt, das heißt, ich wähle das aus und kann dann gleich auswählen. Ich möchte jetzt den Device-Descript auslesen. Jetzt möchte ich ihn genau dann auslesen, wenn irgendein Pin hochgeht und so weiter. Es ist ein bisschen schwierig zu sehen hier, aber wenn man mir hierher schaut, hier sind die ganzen Konfigurations-Settings. Es sind irgendwelche Vor-Konditionen, wenn irgendwas generiert wird. Man kann jetzt in dieses Interface gehen. Also, wenn das Satz passiert, und das im vierten Mal passiert, also die ganzen komplexen Koalitionen, die wir hier schon geredet haben, und dann wird das Software eben genau das auslösen. Also, diesen ChipWizPro, dann sagen wir, es soll jetzt das und das tun. Natürlich würden wir jetzt hier nicht die Arbeit von anderen Leuten einfach so übernehmen. Wir mussten an einer Stelle uns gegen unsere eigene Schöpfung wenden. Hier haben wir ein Great-Fat, der wurde stark bearbeitet. Da wurden eben die ganzen Koppelkondensatoren ausgelötet. Und das soll es eben ermöglichen, genauer die entsprechenden Spannungsversorgung runterzureißen. Und damit kann man dann eben an einer bestimmten Stelle genau eine bestimmte Spannung einstellen oder eben auch die Spannung auf Null runterzureißen. Hier habe ich hier ein Entkopplungsnetzwerk, das die ganzen Koppelkondensatoren auf der Platine ersetzt. Und das wird dann eben über eine Impandanz angeschlossen, sodass man das entladen und wiederladen kann. Also es tut mir leid, Michael Ostmann, dass wir das Gerät, was du erstellt hast, sozusagen komplett zerstört haben. Aber vielleicht müsste man eher sagen, es tut uns allen gegenüber leid, weil schaut euch das doch einfach mal an. Wir haben das eben ganz oft retweetet bekommen und es wurde uns ständig gesagt, mach doch mal eure Platine sauber bitte. Wobei man auch eher sagen muss, dass diese Modifizierung eben gemacht wurde nach ein paar Getränken an Weihnachten. Was wir aber eben machen wollten, war dieses Board zu glitchen, um die Firmware darunter zu bekommen. Andererseits ist es natürlich open source. Insofern haben wir die Firmware schon. Also er schreibt hier Briefe, dass man das nicht machen soll, obwohl es open source ist. Wir haben natürlich sehr viel Angst davor, dass wir dafür nicht verklagt werden. Das heißt, wir werden jetzt einfach den Bootloader angreifen. Und der im Read-Only, der im Bootloader angreift, der im Bootloader angreift, der im Read-Only-Memory steht, die LPC 43, die Serie hat ein USB-DFU-Bootloader und auch so gewisse USB-Funktionalitäten. Und es gibt hier noch einen Rommabschnitt. Kann ich jetzt nicht hier zeigen, aber... Dieses Gerät hat ein USB-Bootloader, das all das tut, was das Tabler tut, weil es eben mit dem USB-Standard kompatibel ist. Deswegen haben wir jetzt hier einfach die gleichen Glitching-Attacken angewendet auf dieses Romm. Da ist natürlich die Frage, warum ist das interessant, dieses Romm anzugreifen? Weil es so eben möglich ist, ein Teil des Speichers auszulesen, das alles ganz tiefes Ramm, alles andere, was wir kennen, kommt danach. Aber wenn man sich eben auch anschaut, der sichere Modus, also was sie da machen, in diesem Bootloader, ist es ein verschlüsseltes Image zu lesen von einem Flash-Chip, ist zu entschlüsseln und in einem S-Ramm zu speichern und von da aus aus dem Shadow-Bereich das zu starten und wenn wir den Shadow-Bereich angreifen können, dann haben wir die Möglichkeit, von da aus weiter zu lesen und eben auch die entschlüsselten Images auszulesen. Nur ist jetzt der schwierige Teil. Schau, schau, das passiert, dass du auf meiner Maschine versuchst, was zu machen. Jetzt musst du dich eben erst verbinden und anfangen zu blinken. So. Löschen wir die Tabelle von den Vorhergenden abläufen. Und jetzt checkt es hier eben ein USB, die befehlt an das Gerät und liest die Antwort aus und wir sehen eben das Anzeig mit Farben. Was ist ein guter Antwort, was ist eine schlechte Antwort und man sieht eben alle Antworten, die hier zurechtkommen sind. Zurückkommen sind schlechte Antworten und da kann man eben auch anschauen, was ist da jeweils passiert. Man sollte vielleicht auch erwähnen, dass hier ein Symbol Lackrom ist, der Maschine, wie es normalerweise laufen würde, also durch ganz viele, viele, viele Intervalle laufen um eben dann die zu finden, wo man angreifen kann. Aber wir haben ja hier nicht so viel Zeit, statt einfach alles durchlaufen zu lassen, springt an verschiedene Stellen in diesem Ablauf und wir bekommen deswegen eben ganz viele Antworten, die wir da auch erwartet haben. Also beispielsweise hier steht hier 18 Bytes und dann kommen auch 18 Bytes, aber hier sehen wir ja, das ist deutlich mehr, deutlich mehr Daten und wir simulieren das eben, weil das nicht ganz so schnell geht, wir müssen normalerweise laufen lässt und in einem vorhergehenden Ablauf haben wir das hier gedammt in diese Datei, in diese Hex-Datei. Also ich mach mal die Schrift größer, was wir also sehen, ist, was wir hier auslesen konnten aus dieser Datei. Was wir in diese Datei reinspeichern konnten, war eben alles, was wir ab dem USB-Diskripte ausgehend lesen konnten. Was wir hier gefunden haben, hier zum Beispiel steht USB-C und hier steht USB-S und das sind sehr, sehr aussagekräftige Strings, denn das sind USB-Kommandos, die geschickt werden, die nur bei USB-Bulk-Speichern verwendet werden und das ist eh hier eben eine Antwort mit einem Status. Das zeigt also, dass dieser Bootloader auch die Möglichkeit hat, einen USB-Hose zu sein, USB-Massenspeicher zu sein und dann gibt es eben hier auch einige Codes für Romfunktionen, von denen wir gar nicht wussten, dass sie überhaupt in diesem Chip sind. Wir konnten also aus dem Code für dieses NXP-Gerät sozusagen auslesen, was sozusagen alles an undokumentierten Funktionen da noch drinsteckt. Wir haben das jetzt nicht so angelaufen lassen, wir haben jetzt nicht so viel Daten bekommen, aber die Theorie ist, dass man, nachdem man das einmal laufen lassen kann, dann hat man eine komplette entschlüsselte Firmware, von der man dann sozusagen auch herausfinden kann, wie man sozusagen aus der verschlüsselten Firmware die Entschlüsselte ermitteln kann. Wir haben jetzt hier keine Zeit mehr für Fragen, aber wir sind ja gleich da draußen, da könnt ihr mit uns sprechen oder ihr schaut in den IRC-Kanal, den habe ich jetzt leider nicht verstanden. Da könnt ihr vorbeikommen, vielen Dank.