 So, I want to answer three questions about spy-spy, which is... Okay, ja, drei Fragen beantwortet über spy-spy, oder spy-spy, meine Open-Source-Sbi-Emulation. Also, was ist spy-Flash? Warum wollen wir es emulieren und wie werden wir es tun? Ihr rechts ist das Einfache des spy-Flash. Wir haben kleine, nicht flüchtige Speicher-Ship auf Servern und Laptops und anderen Computern. Die sind typischerweise ein 8-Pin-SY-Package. Man kann sich das Datenblatt unterladen und man kann sehen, dass SPI ist die Abkürzung für Serial Peripherial Interface, also Seriales Schildstellen oder Peripherial Interface, das relativ einfach ist. Die sind typisch relativ klein, also etwa 16 Megabyte. Typischerweise werden sie Boot-ROMs genannt, aber es ist ein bisschen fehlender Nennung, weil eigentlich es ist Flash-Memory. Dieses ersetzt die 64 Kilowatt-ROMs in alten Maschinen. Das erlaubt uns. Er hat sehr viel mehr Komplexität in die Firmware von unseren Maschinen gegeben. Er kennt vielleicht die UAV-Firmware, die modernen Rechner sind, die geben einem Grafik und Netzwerken und allen Massen-Speicher, bevor das Betriebssystem gespeichert ist. Und es gibt auch Dinge wie Linux-Boot oder Core-Boot, die es dem Leuten erlauben, die Firmware in ihren SPI-Flashes zu ersetzen und durch freie Software zu ersetzen. Warum wollen wir so SPI-Flashes ersetzen? Nun, wenn ihr über Core-Boot oder Linux-Boot arbeitet oder wenn ihr Sicherheitsforschung über UAV macht, dann müsst ihr sehr häufig diese Chips neu flaschen. Und ihr macht das wirklich, wirklich häufig. In meiner Zeit, wo ich Firmware, Research gemacht habe, Firmware-Forschung gemacht, das habe ich sehr, sehr viel Zeit, damit verbracht, SPI-Flashes an die Bagger zu anzuschließen und neu zu schreiben. Wie gesagt, okay, es sind nur 16 Megabyte. Wie lange kann es dauern, das zu machen? Nun, das Problem ist, dass diese Chips so geschrieben sind, dass man sie 4 Kilobytes auf einmal schreiben muss. Und man muss vorher die 4 Kilobytes löschen, bevor man sie schreiben kann. Und im schlimmsten Fall dauert es 120 Millisekunden jeden Sektor zu lösen, also 120 Millisekunden und 15 Megabyte. Durch 4 Kilobytes Schreibvorgang bleiben 8 Minuten im schlimmsten Fall für einen Schreibvorgang. Das ist eine wirklich, wirklich schlimme Zykluszeit. So, hier ein Beispiel, wie ich das hatte, aus der Zeit vor Spy-Spy, man schaltet den Strom ab, weil der SPI-Bus nicht erlaubt, dass man die Spannung versorgt. Da muss man den Flaschprogrammiergerät anschließen, weil man kann es nicht angeschlossen lassen wegen Stromlast und Kapazitäten. Und dann fängt man an zu flaschen. Die erste Sektion geht wirklich schnell. Jetzt hat man die Managementregion nicht gemacht. Und dann startet es in dem Bereich, wo es löschen und überschreiben muss. Und dann, ja, die Minuten vergehen. Es ist immer noch 20 Kilobyte pro Sekunde löscht. Ja, 5 Minuten-Syndrom. Und du hast wirklich Lust, einfach wegzugehen und was anderes zu machen. Nach 5,5 Minuten, 49 Kilobyte pro Sekunde durchschnittsgeschwindig, dann bist du noch nicht mal fertig. Jetzt musst du erstmal den Flaschprogrammier-Ship abmachen, das System neu einmachen. Und dann muss man alles nochmal machen, weil du feststellst, dass du irgendwo einen kleinen dummen Fehler irgendwo in deinem Image gemacht hast. Und das ist wirklich, wirklich schmerzhaft. Da muss es einen besseren Weg geben. Und da kommt das Spy-Spy-Gerät hinzu. Man schließt es einmal an, wenn man mit der Firmaentwicklung beginnt, und lässt es einfach dran. Und man hat ein neues Coreboot-Bild, installiert, macht man das in Echtzeit. Es kann den neuen Coreboot in das Deram auf dem Spy-Spy kopieren und es im Wesentlichen über durch die Geschwindigkeit von dem USB beschränkt. Also 12 Sekunden statt 5,5 Minuten. Das ist nicht zu schlecht. Wir können sogar noch ein bisschen besser Dingen, weil es am Ende von durch die USB-Serielle-Abstraktion beschränkt sind. Für das Modul, das ACM-Modul, aber das ist auch so schon eine unglaubliche Verbesserung. Der andere Vorteil ist, wir können jetzt einen weichen Reboot in die neue Firmware machen. Wir müssen nicht ausschalten. Wir müssen nicht... Es ist eine sehr, sehr große Verbesserung. Die andere Sache, die Spy-Spy bei uns gibt, ist einzig darin, was passiert, wenn der Computer bootet. Wenn du gerade von den 1960'n kommst, dann würdest denken, dass die... wird auch so bootet wie in den ACM. Aber das ist überhaupt nicht das, was in modernen CPUs passiert. Spy-Spy guckt auf den Bus, gibt es uns ein... wie ein TCB-Dump, eine Liste von allem, was aus dem Flash-Speicher gelesen wird. Und wir können sehen, dass der Platform-Controller Hub erst aus dem Intel Flash-Diskriptor von Offset 10 lest, dann die Intel Management Engine, die ihre Firmware liest und validiert. Dann können wir das etwas, was dem X86, irgendwie ein Bootcode oder Bebootraum, oder aus dem Microcode, die Fit-Tabelle, die Firmware-Interface-Tabelle, die enthält Zeiger auf Microcode-Updates, die der X86 dann laden. Und dann schließlich ist es immer noch nicht Zeit für den Reset-Vektor, es springt in den Boot-Guard oder eine sichere Boot-Methode und validiert die Signatur. Und erst dann wird der Reset-Vektor aufgerufen und dann springt da in den BIOS, oder woch immerhin. Das ist eine sehr nützliche Einsicht. Und wir können diese Daten auch plotten. Also wenn wir einen Plot machen, welche Adressen über die Zeit, welche Reihenfolge sie geladen werden und schreiben sie blau für das erste Mal, dass eine Adresse gelesen wird. Das ist typisch, wenn Boot-Guard oder eine die Management-Engine eine Signaturprüfung machen. Das nennen wir Time-of-Check. Und dann gibt es Adressen, die nochmal gelesen werden aus dem Flash. Und wir können sehen, dass da ganzen Haufen andere Time-of-Use-Reads sind. Dieses Tock-Tow, also Time-of-Check, Zeit der Überprüfung und Zeit der Benutzung ist etwas, wo wir Tock-Tow-Angaben Artacken gegen Boot-Guard machen können. Wo wir an Intel's Boot-Guard vorbeigehen können, indem wir ähnliche Technologien wie Spiceball benutzen. So, das ist das was und das warum. Jetzt kommt das why, das warum. Also, wie funktioniert das? Ich sage immer, dass das mein Projekt ist, aber es basiert auf sehr vielen anderen wundervollen Open-Source-Projekten. Wie z.B. Josis, das Projekt Trellis und Next-PNR, wo wir in meinem vorigen Vortrag geredet haben. Diese Gruppe hat eine Open-Source-Toolchain für FPGAs entwickelt. Sie hat ein ganzes Ecosystem von programmierbarem Hardware. Sie hat ein paar Kollaboratoren von Resprace, die mit mir zusammen auf der initialen FPGA-Implimentation gearbeitet haben. Das haben wir für die Hack-in-the-Box-Demo benutzt. Wir benutzen wesentlich schmal kleineren FPGA, den ISE 40 OP5-Kerl. Das ist auch etwas, was wir haben, für einen Megabit Block-Ram. Das ist nicht genug, um ein ganzes Flash-Image zu speichern, aber es ist genug für die Time-of-Check-Time-Views-Verwundbarkeit. Wir brauchen viel mehr Speicher. Es gibt zum Glück ein sehr nettes Open-Source-Hardware-Projekt. Das Radiano aus dem Radiano-Hackerspace aus Kroatien. Sie haben das auf dem Lattice APC-5 gebaut. Das ist ein 32-Megabyte SD-Ram, auf dem ihr Releasen schreiben könnt, mit 250 Megabyte per Sekunde. Das heißt, wir können davon profitieren, dass es da die Schemaß gibt. Wir können die Open-Toolchains benutzen und das als Block für unser System benutzen. Das Problem ist aber, das SD-Ram ist ziemlich komplexes. Es gibt sehr viel schwarze Magie in den Zustandsübergängen, die wir benutzen müssen. Ich weiß nicht, wie es euch geht, aber ich möchte in diesem Level SD-Ram nicht verstehen müssen. Aber das müssen wir zum Glück nicht. Stefan Kristiansund hat unter einer sehr freizügigen Lizenz ein SD-Ram-Controller veröffentlicht, den wir gut anpassen konnten. Wir haben es dann mit der Open-Source-FPGA-Toolchain gebaut. Das hat uns sehr schnell weitergebracht. Das andere Problem ist, es sind die meisten Open-Source-Projekten, basieren auf Sachen, die andere Leute veröffentlicht haben. Es ist generell ein Problem. Das ist ein Problem, das andere Leute veröffentlicht haben. ScanLime hat etwas Ähnliches gemacht, um Nintendo DS Speichestelle zu emulieren. Das war sehr hilfreich, zu lernen, wie der SPI-Bus funktioniert und wie man damit kommuniziert. Jetzt gehen wir mal kurz ins Detail, wie ein SPI-Bus funktioniert. Es gibt diese 8-Pins System-on-Chip. Es gibt immer den Pin-Out und das Timing-Diagramm. Der Rote Punkt zeigt an, wo der erste Pin ist. Dann können wir die Stromversorgung und die Erde finden. Das möchten wir ganz sicher nicht vertauschen. Die Chip-Select-Leitung ist auch sehr wichtig. Das kommt nämlich von einem Plattformen. Das wird benutzt, um dem Chip zu sagen, dass wir jetzt mit dem Chip reden möchten. Das ist ein Problem, dass wir jetzt mit dem Chip reden möchten. Das geht auf niedrig, während der Übertragung. Das heißt Active Low. Das ist normalerweise mit einem Ausruferzeichen oder mit einer Rote im Namen. Die Clock ist auch dabei. In fallenden Kanten ändern sich immer die Werte und auf den steigenden Flanken sind die Werte stabil. Das nennt wir ein Rising-Edge-Clock-Signal. Der Serial-In-Pin kommt in den Chip hinein und enthält die Befehlbytes, die von einem Chip verarbeitet werden. Am Schluss wird der Flash dann seinen Ausgang an den Serial-Out-Pin. Das ist ein Problem. Wir müssen uns anschauen, wie die Befehlbytes aussehen. Im Datenblatt stehen sehr viele Befehle. Was uns am meisten interessiert, ist das ganz normale Lesen. Es gibt drei Adressbytes, die nach dem Kommando-Byte kommen. Wir müssen uns anschauen, wie die Befehlbytes aussehen. Da sind die Befehlbytes angekommen. Dann sind die Befehlbytes auf den Wenn wir also etwas aus dem Blog-Degrahmen lesen, dann schicken wir das wieder zurück, das hat da funktioniert, weil Blog-Ram eben in einem einzelnen Zyklus funktioniert, aber das ist aber mit dem D-Ram funktionieren, probieren, dann funktioniert das nicht. Dann der echte Ram, der echte SPI-Flasche ist in blau, man sieht, dass das erste Bit ungefähr 50 Nanosekunden verzögert ist, bevor sie den richtigen Wert einnimmt. Und der Grund dafür ist, weil es D-Ram ist nicht einfach ein Gatte, aus dem man lesen kann, man muss eben eine Zeile aktivieren und mal so ein paar Clockzyklen warten und dann die Spalte auswählen und dann auch wieder warten. Diese gesamte Latents kann 5 bis 7 Clockzyklen dauern, das ist dann ungefähr 50 Nanosekunden, also 50 bis 80 Nanosekunden. Das ist das Problem, wir brauchen das SPI-Clockzyklen, das ist das Problem, dass die Latents so schnell und schnell gehen würden, dann ändert sich diese zufällige Lesezeit nicht, weil die Latents eben hoch geht, das heißt mit einem 2400, das ist selbst mit 2,4 Gigahertz RAM, es sind immer noch 50 Nanosekunden. Das Problem ist, wir brauchen das Ergebnis aber ein halben Clockzyklus später und das sind gerade ungefähr 25 Nanosekunden, bis wir unser Ergebnis anlegen müssen. Was der Vorteil an FPGA aus ist, dass wir keine Beschränkungen haben, wie wir mit traditionellen Programmiersprachen haben, das heißt wir können die Zeilen auswählen schon anfangen, nachdem wir die Adresse, die ersten 14 Bits der Adresse haben und die Spaltenaktivierung können wir nach den weiteren 9 Bits starten. Das heißt wir haben 16 Bits vom RAM und das können wir alles übereinanderlegen mit der SPI-Übertragung, das heißt wir können das letzte Bit benutzen, um das höhere oder das untere Bit eben auszuwählen und das funktioniert. Wir haben es geschafft das erste Bit nur ungefähr nach 10 Nanosekunden, also langsam mehr als das Originalflash zu bekommen und wir haben dann geschafft den Platform Controller Hub zu überzeugen, dass der Flasch gut ist. Und das sieht man in der 5a5 Daten, Zehner Offsite in unserem Flasch. Zehner und John Butterworth haben in ihrem Training erzählt, dass es die Signatur ist, für die ihr PCH sucht, um den Flasch zu identifizieren. Wenn es das nicht findet, dann startet das System überhaupt gar nicht. Es gibt also kein Lebenssein von der Maschine. Also wir können den PCH überzeugen zu starten, aber manchmal schlagen der Linux Kernel viel mit einem Read Page. Der Grund dafür ist auch wieder eine neue Komplexität im DRAM. DRAM besteht aus sehr vielen Kondensatoren und die entladen sich sehr langsam. Es ist notwendig für den SD-RAM-Controller, um diese Spalten periodisch zu aktualisieren. Das dauert ungefähr 8 Mikrosekunden. Das passiert alle 8 Mikrosekunden und dann kann man für 60 Nanosekunden nicht mehr lesen. Und das bringt uns komplett durcheinander im Timing. Zum Glück ist unser SD-RAM-Controller Open Source. Das heißt, wir haben ein Signal eingebaut, dass das aktualisieren, dass das Spalten zu unterbinden. Das hat funktioniert. Wir haben es geschafft, komplett in Linux zu booten. Ihr habt ein Haufen Bilder gesehen, wo wir diese lötfreien Chip-Clips von Pomona benutzt haben. Und ihr könnt euch fragen, wie verhindern wir, dass der wirkliche Flash-Chip auf diese Request Anfragen antwortet. Nun, es stellt sich heraus, in meisten Mainwords, nicht allen, aber guckt vorher, bevor ihr es macht, ist dieser Notseer, dieser Chip-Select Int, wird geht durch einen kleinen Serien-Widerstand, so dass er von dem PC-Hast CS Output ein bisschen gebuffert ist. Diese Widerstand bedeutet, dass wir im Wesentlichen ein Oder-Gitter-Batter bauen können, wo wir entscheiden können, ob der CS hoch ist oder nicht. Wir sehen, wenn die SPI-Transaktion startet, dann zieht der PC-H CS No, also noch niedrig, was den Flash-Baustein aufwegt, und es fängt an, Daten auf Serial Out zurückzuschicken. Wenn der FPGA diese Transaktion übernehmen will, kann das die Leitung hochziehen, und was den SPI Flash abschaltet, also der SPI Flash wird seinen Output Driver abschalten, und der FPGA kann die Serial Output-Leitung einfach für seine eigene Zwecke verwenden und an den PC-H PC-H antworten. Problem jetzt, wir wissen nicht, wann die Transaktion vorbei ist, deshalb müssen wir einen anderen Hack machen. Das heißt, der FPGA guckt auch auf die Clocked Line, und wenn er feststellt, es gibt seit langem keine Takt-Signale auf dieser Clocked-Sein, dann schaltet es seinen CS Output in den Tri-State-Zustand, also Hochohmig, und das System geht mit dem hohe Zustand zurück. Also, ein großer Haufen Hacks, aber es funktioniert alles. Wir können einen ganzen Haufen Laptops puten, wir haben es auf eindlichen Serf angetan, und auf jedem System, auf dem wir es getan haben, haben wir interessante Tock-Toe Verwundbarkeiten gefunden, wir haben ein Firmware angeguckt, und konnten sehen, was diese Maschinen machen. Ein Bereich, in dem wir wirklich viel Forschung machen wollen, sind andere Architekturen. Auf den meisten Servern ist ein anderes Spy Flash neben dem X86. Flash, das die Firmware für den Board Management Controller, den BMC, speichert. Wer darüber interessiert, dann könnt ihr meinen Talk vom letzten Kongress angucken über Supermicro BMC Hacks. Unglücklicherweise benutzt der ARM in dem BMC einige Read-Kommandos, die wir im Moment nicht unterstützen. Also, wenn ihr an dem Projekt mitarbeiten sollt, wir brauchen Hilfe, die uns diese verschiedenen Lesel-Kommandos, die der ARM schickt, implementieren. Wir können auch jedenfalls das UI verbessern, das ist sehr programmierbar zentlich. Wir würden auch gerne zu entweder USB-Massen-Speicher wechseln oder zu USB-Ethernet. Und es gibt auch einen ganzen Haufen anderer Busse in dem System, über das wir diese Ideen anwenden können. Das LPC oder der ESBI, der von Apple T2 Code Prozessor benannt, oder der EMMC-Bus, über den auf eingebetteten Devices für Uploads gemacht werden. Also, hoffentlich hat das eure Fragen über das, was, wie, warum und wieso, wie das SpySpy beantwortet. Wie ihr interessiert, könnt ihr euch die Source von unserem GitHub-Tree angucken. Wir haben ein Slack-Kanal für SpySpy und ihr könnt mich auch auf Mastodon oder Twitter finden. Und wer ist bereit, irgendwelche, alle eure Fragen entgegenzunehmen, die ihr über das Projekt haben könntet? Es gibt also noch 15 Minuten für Fragen und Antworten. Also, scheut euch nicht. Geht das auch mit der RAM-Chips? Die meisten SRAM-Chips sind sehr schmal und sind heutzutage ziemlich teuer, um 32 megabyte SRAM-Chips zu machen für das... Hi, thanks for the talk, very interesting. Normalerweise gibt es einen Befehl, um den ganzen Flash zu löschen, was normalerweise viel schneller als Sector-Errace ist. Ist das eine Option oder ist es immer noch zu langsam? Das ist immer noch sehr langsam aus verschiedenen Gründen. So, der Chip Erraced-Kommando für den ganzen Chip ist 80 Sekunden. Typischerweise ist das aber keine Optimierung, weil ein Großteil des Chips sich nicht geändert hat. Das würde zum Beispiel auch die Management Engine löschen. Wenn man nicht gerade ein Management Engine Ersatz arbeitet, dann würde das ganze Chip löschen erfordern, dass man auch die ganze Management Engine neu programmieren muss. Und die Programmierzeit für eine Programmesite ist so lang, dass es immer noch ein Verlust ist. Eine zweite Frage ist, Nannflasche, ist das ein Ding in diesen Controller? Typisch nicht, und ich bin mir nicht sicher, warum. Es gibt einen ganzen Haufen Innovationen, das bei einanderen Chips oder anderen Systemen passiert. Zum Beispiel Apple benutzt eSpy, um ihre Systeme zu booten. Und Sie haben einen Sicherheits-Core-Prozessor, der ungefähr so wie der Spy-Spy arbeitet, als ein Zwischenteil zwischen dem Speicher und der CPU, und das all diese Sicherheitsprüfung machen kann, bevor die CPU aus dem Reset entlässt, dass er die Daten alle lesen kann. Hi, Sie hatten ein iS40-Design, bevor du auf ein anderes Design gegangen bist. Was sind da die Unterschiede? Warum habt ihr den Übergang gemacht? Der iS40 ist mit dem 20-Mb-Spy-Bus wunderbar klargekommen. Es sieht so aus, als wenn die neue Hardware deutlich einfacher fällt, die Timing-Requirements zu erfüllen. Wir brauchen wenigstens sechsmal die Spy-Taktgeschwindigkeit, um mit dem SDRAM zu kommunizieren, um einfach dieses Überlappen zwischen der SDRAM-Aktivierung und der Adressauswahl und so was machen können. Und für den iS40 mit 40 MHz sind wir nie so weit gekommen. Das war gerade genug, um mit dem 20-Mb-Bus klarzukommen, also vorhanden wegen diesem Zwei-Takt-Cast-Delay bei dem SDRAM. Das Zugrussmuster ist das vorhersegbar, kann man da vielleicht cashen? Wir haben uns das angeguckt, versucht das zu tun. Das ist vorhersegbar im Fall einer bekannten Server, bekannten Firmware, aber nicht, wenn man Firmware-Development macht und das häufig verändert. Das andere, worauf wir geguckt haben auf dem iS40 5K mit einem Mbit von BlockRAM, konnten wir jedes erste Bit für ein 8-Mb-Speicher cashen, also von einem 8-Mb-ROM, aber leider ist das gerade eben nicht groß genug für ein 16-Mb-ROM. Und viele Systeme, die wir uns heute angucken, haben 32-Mb-SBI-Flash. Und wir wollten nicht in Richtung dieser proprietären FPGAs gehen. Also wir sind sehr dankbar für die Arbeit, die JOSES-Projekt gemacht hat. Es hat wirklich Arbeit mit FPGAs so viel angenehmer gemacht. Das hast du vielleicht auch darüber gesprochen, aber die Existenz von Graphing-Bugs, habt ihr da irgendwie die Firmware in der Toolchain ausgetauscht? Ja, wir waren in der Lage Intel Boot Guard zu überlisten. Peter Boschern hat einen Tag bei Hack in the Box gegeben mit ganzen Details. Die spezielle Verwundbarkeit hatte damit zu tun, dass es einen kleinen Fenster gibt, wo die Kurze die Caches abschalten müssen während des Bootprogramms. Das heißt, die nächste Instruktion wird aus dem Flash gelesen, und danach wird der Cache wieder angeschaltet. Und wir hatten da dieses ein Instruktionsfenster, wo wir den Code überschreiben konnten. Es unterstützt das Projekt auch andere Instruktionssets, als das SPI Flash, was sie jetzt demonstriert haben. Und zu anderen Herstellern. Es unterstützt den kleinsten gemeinsam Vielfachen von den verschiedenen SPI Flash-Protokollen, den serial Flash-Descriptor und die moderne Intel Chips erfordern, um damit man davon boten kommen. Es hat ersten Unterstützung zum Schreibelsupport, aber das ist momentan etwas wackelig. Das haben Sie beschrieben mit diesem Widerstand, um dann Chips direkt zu über was passiert, wenn das Mainboard das nicht hat. Wenn das Mainboard keinen hat, dann müssen wir halt den Pin 1 von dem Flash auf den Board entlöten und aus dem Weg biegen und einen Jumper darunter passen, damit man die Verbindung zwischen dem Flash-Chip und dem Mainboard unterbrechen kann. Keine weiteren Fragen. Und damit verabschieden sich Flo und Peter aus der Besetzungskabine.