 Ich habe mich heute mal auf media.cc.de angeschaut, wie viele Talks zum Konsolenhacking wir bereits haben. Und es ist eine ziemlich lange Liste. Wir hatten die Xbox, wir hatten die PSP, wir hatten noch einige mehr. Es ist eine ziemlich lange Liste, wirklich. Und ich bin froh, hier Yvonne Lou und Davy hier zu haben, welche uns etwas über den Hack der PlayStation wieder erzählen können. Schauen wir mal, wie sie das gemacht haben. Eine warme Runde Applaus für Yvonne und Davy. Vielen Dank, dass ihr hier seid. Also, wie viele von euch haben eine wieder besessen? Sind schon einige im Saal mich irgendwie angeschlossen? Wie viele haben einen 3DS? Das sind einige mehr. Ich hoffe, dass ich euch am Ende dieses Talks davon überzeugen kann, zu besseren Konsolen zu kommen. Wer sind wir? Wir sind Team Molecule, das ist unser Maskottchen. Und Davy, ich, Yvonne, für die Rechtsanwälte bin ich XYZ und dann gibt es noch Proxima, die nicht hier ist heute. Wir haben, seit von Anfang an waren wir daran, die Vita zu hacken und haben auch einiges anderes noch gemacht. So, also das Übersicht, das ist ein Grundlagentalk. Wir wollen mehr über die Techniken sprechen, die wir angewendet haben und mehr als nur die Resultate. Das ist vielleicht nicht ganz so spannend für alle hier, aber wir hoffen, dass ihr da bleibt und trotzdem was davon lernen könnt. Davy wird die Software Seite präsentieren und ich werde nachher dann wieder zurückkommen und über die Hardware sprechen. Gut, damit hier ist Davy. Hallo. Also ich werde jetzt über die Software Seite des Hackens der PlayStation Vita sprechen und spezifisch werde ich über den Sicherheits-Core Prozessor sprechen. Also zuerst muss ich mal über die Sicherheitsarchitektur der PlayStation Vita sprechen. Sieht etwas so aus. Das sind die grundlegenden Privilegienstufen und wir haben schon seit einer langen Weile an der Vita gearbeitet und wir haben es bereits ins Trust Zone Level geschafft. Und was da schon daran spannend ist, ist, dass der Sony dem eigentlich schon gar nicht vertraut. Also das wird geproxied von dem Core Prozessor und wir können das Ganze so simplifizieren. Und was ich heute darüber sprechen werde, ist, wie ich in den Food-Cornel und Food-Loader Levels einbrechen werde. Und was ist das eigentlich? Das ist der Sicherheits-Core Prozessor. Das ist ein spezieller Prozessor, der ein proprietäres Instruktions-Set ausführt. Und jetzt sprechen wir noch kurz über die zwei Privilegien Levels, die er hat. Food-Cornel, das ist das DRM des Systems und der stellt sicher, dass alles auf die richtige Art authentisiert ist. Und der Food-Loader, das ist mehr wie ein Boot-Loader und Start-up und der stellt sicher, dass die Schlüssel geschützt sind. Und wenn wir das hacken wollen, dann müssen wir uns überlegen, wie wir das machen wollen. Mit seinen proprietären Prozessor müssen wir zuerst mal mehr Informationen sammeln. Als erstes die Hardware-Architektur, die dahinter steckt. Anschließend müssen wir die Software anschauen, die auf dem Prozessor läuft und damit können wir dann ein Plan beginnen zu formulieren. Das erste, worüber ich reden werde, wird die Hardware-Architektur sein. Das ist das Blockdiagramm für die Vita. Das ist Kermit, tatsächlich nach dem Frosch benannt. Sie nennen ihre Systeme auch häufig nach Sesamstrasse. Es gibt kein Bert, es gibt aber Ernie. Auf der PSP gab es zum Beispiel Kirk und Spock und Paul. Nur die beiden hier. Wir interessieren uns eigentlich nicht so über den Rest, sondern hauptsächlich nur um Foot. Und wir sehen da drin, dass es den Map-C5-Prozessor gibt. Map ist ein Risk von Toshiba. Der Name Foot kommt von Elf-Headern von Executables da drin. Damit haben wir einfach gearbeitet. Seitdem ist das Geschichte. Der Map-Prozessor wird normalerweise benutzt in Park-Lösungen oder Sicherheitslösungen. Diesmal haben wir es wohl für den sicheren Co-Prozessor benutzt. Hier haben wir noch eine Crypto-Engine und Key Slots. Das ist wichtig für diesen Talk. Es hat auch einen eigenen Speichhaber. Hier ist ein Secure SRAM, 128 Kilobytes. Das kann nur von dem hier zugriffen werden. Kein anderes Armsystem kann darauf zugriffen. Das ist ein eigener Risk. Wie kriegen wir darüber was raus? Na, das ist eigentlich so wie immer. Wir googeln es. Da kriegen wir ein paar Datenblätter. Die meisten in Englisch, die meisten in Japanisch. Da ist Google Translate, euer beste Freund. Nach ein paar Google-Suchen haben wir das Datenblatt. Dann kriegen wir das Instruction-Set dadurch und ein paar komische Dinge darüber. Glücklicherweise haben wir GCC und so weiter sehr gut. Aber wir wollen gerne mehr darüber wissen. Wir probieren es einfach mal. Wir haben mit jeder Plug-in geschrieben, ein Emulator geschrieben. Das hat uns wieder ein paar komischen Dinge gelehrt. Wir haben sogar ein Decompiler geschrieben. Was haben wir dadurch gelernt? Es ist hauptsächlich inspiriert durch MIPS. Es hat keinen komischen Instruction-Set. Das Instruction-Set ist aber ungefähr das gleiche. Es gibt keinen virtuellen Speicher, keinen Memory-Schutz. Es ist einfach bloß physischer Spiel. Es ist kein Sicherheitsreinforster-Prozessor. Es gibt keinen ASLR und so weiter. Wir dachten, das ist nicht besonders sicher für einen Coop-Prozessor. Naja, egal. Eine nächste, worüber wir reden wollen, ist die Software, die draufläuft. Während der Laufzeit gibt es dort einen sicheren Kernel, der während der ganzen Zeit läuft. Und der hat so Applets, die so ein bisschen Funktionalität verpacken. Zum Beispiel DRM, oder irgendwelche anderen Features, die authentifiziert werden müssen. Man lädt es, dann gibt es ein RPC, ein Remote Procedure Call Interface, um Berechnungen, Entschlüsselung oder was auch immer zu machen. Danach entleht man es wieder, weil man lädt es, man tut was, man entleht es wieder, weil bloß ein einziges Applet auf einmal geladen werden kann. Natürlich, unglücklicherweise für uns gibt es, sind die Applets signiert und verschlüsselt. Dann schauen wir uns mal den Lebenszyklus genauer an, insbesondere den Applet laden. Man sieht hier drei Regionen, Arm, Trustzone und Food. Trustzone ist hauptsächlich nutzlos, eigentlich nur in Proxy. Wir können es eigentlich als so ansehen, simplifizierter. Wir können uns eigentlich anschauen, wie es zwischen Arm und Food passiert. Arm lädt das Applet ins Weiche, das wird rübergeschickt nach Food, überprüft die Signatur und dann entschlüsselt, und dann gibt es ein Ergebnis zurück, ob es erfolgreich oder nicht war. Für das RPC ist hauptsächlich das Gleiche, man formatiert eine Anfrage, dann schickt man es rüber, der sichere Kernel wird es zum Applet weitergegeben, das Applet wird den Request ausführen und dann wird es wieder zurückgesetzt. Entladen funktioniert genauso, man fragt einen Anload an, dann wird das Input gemacht und dann gibt es das Resultat zurück. Wenn wir das jetzt wissen, wie können wir das angreifen? Okay, schauen wir uns an, was wir wissen. Wir können alles, was man in Food reingibt, bestimmen. Wir können wie viel auch immer Daten reingeben, wie wir wollen. Wir können das Memory Layout, Applets haben aber auch ein Elf-Header, Sie haben ein Segment-Header und wir sehen, an welchen Adressen es geladen wird und dadurch kriegen wir ein ganz gutes Modell, wie der Sprache aussehen wird. Der Co-Processor hat keine Sicherheitsfeatures, ziemlich praktisch. Wir verstehen den Applet-Lebenszyklus. Wir sehen die RPC-Calls. Wir können also RPC-Calls anschauen. Wir schauen uns die Executables an. Sie sind leider signiert und sind auch verschlüsselt. Wir können diese nicht lesen, weil sie auch verschlüsselt sind. Also können wir sie nicht vorher analysieren und das macht das ganze System effektiv zu einer Blackbox. Was wir also am liebsten hätten, wenn wir hier weitermachen sollen, wäre eine Möglichkeit, den privaten Speicher von Food anzuschauen, um hier einen genaueren Angriff, einen besseren Angriff zu machen. Also gehe ich mal zurück zum Applet-Loading und will das hier genauer anschauen. Um genau zu sein, wissen wir, dass das Applet in Speicher geladen und dann an Food geschickt, wo ein Signatures-Check durchgeführt wird und dann entschlüsselt wird. Was genau passiert hier allerdings? Es hat zwei Probleme hier. Arm arbeitet mit virtuellem Speicher und Food nicht. Das ist ein Problem, weil virtueller Speicher ist nicht zwingend durch zusammenhängenden physischen Speicher umgesetzt. Das heißt, entweder müssen wir alles ins physische Memory rüber speichern, da was teuer wäre. Also, oder wir verwenden gar nicht virtuellen Speicher, es muss also einen besseren Weg geben. Hier sehen wir virtuelles und physisches Memory und wir sehen, dass in der physischen Seite das Ganze nicht zusammenhängt ist und wir müssen hier irgendwas besser machen, sonst kriegen wir ein Durcheinander. Was Sonniger macht, ist, sie kreiert eine Liste von physischen Adressen und übergibt diese Liste statt den Daten. In dieser Liste, das erste Element ist die Adresse und das zweite Element in der Liste ist die Größe. Wenn Food also ein Executable lesen will, dann geht das durch die Liste und baut sich so die Datei auf. Und so kopiert man den virtuellen Speicher in einen zusammenhängenden physischen Block. Also, das Food-Modul hier ist ein Applet und die ersten drei Bytes sind repräsentiert vom ersten Eintrag in der physical address Liste und so weiter und so fort. Und damit wird das Kopieren gefixt und wir wissen, wie die Daten Food übergeben werden. Das hat ein Problem allerdings. Wenn wir zu diesem Modell zurückgehen und wir sehen, dass die ganzen Daten im DRAM sind, was passiert, wenn wir einen diesen Listen-Einträgen verändern? Zeigen Sie ins Food-Private-Memory. Das stellt sich raus. Der Food-Colonel blacklisted seinen eigenen Speicher nicht. Das macht keine Daten öffentlich. Food kopiert da nichts raus. Also, sehen wir da nicht mehr? Die Daten werden immer noch nach einer Signatur überprüft. Also, ist das nutzlos? Wenn wir da unbekannte Daten reinladen, dann wird das einfach falsch lagen? Oder nicht? Was ist, wenn die Daten im privaten Speicher dem Original passen? Dann würden wir erwarten, dass der Signatur-Check funktioniert und dass die Daten weiter machen. Und wenn das funktioniert, dann wissen wir, was in dem Teil des Speichers ist. Wenn wir den Listen-Eintrag also auf ein Byte reduzieren und dann die Liste vereinfachen, sodass sie aussieht wie hier. So, der erste Eintrag ist der erste Teil der Teil. Der zweite ist ein einzelnes Byte. Ein Zero-Byte, das wir erwarten. Dann können wir alle Zero-Bytes im privaten Speicher von Food finden. Was wir erwarten also ist, wenn wir hier immer ein Zero-Zero sehen, dann sollte der Signatur-Check funktionieren. Also, können wir hier durchgehen? Wir zeigen also auf das erste Element. Dann können wir das Food übergeben. Funktioniert nicht. Also, wissen wir, da dieses Byte im Speicher ist nicht 00, können das nächste und so weiter und so fort. Ist wir irgendwann ein Erfolg haben? Damit wissen wir, dieses Byte ist 00. Das passt zu dem im Applet. Also ist das 00. Das können wir mit dem ganzen Speicher machen. Voilà, wir haben jetzt mal ein Modell, wo alle Nullen sind. Das ist noch nicht super nützlich. Und jetzt suchen wir mal noch 01. Und jetzt können wir das gleiche machen und einfach wieder durchgehen und alle 01-Einträge suchen. Oh, voilà, da ist eines. Wir machen weiter, wir machen weiter. Die Nullen können wir schon skippen. Die kennen wir ja schon. Und, ah, noch eines. Und so weiter. Das können wir mit dem ganzen Memory machen. Dann haben wir alle 1. Dann machen wir es mit den 2, den 3, den 4 bis zu FF. Und wenn wir das gemacht haben, dann haben wir ein komplettes Modell vom Food SRAM. Und wir haben den Plaintext des Kernels. Das nennen wir den Octopus exploit. Nicht nachfragen, warum. Jetzt haben wir den Food Colonel. Wir haben Lesezugriff. Damit können wir weitere Analysen machen. Wir können weitere Schwachstellen finden. Damit hätten wir nicht drauf eingehen. Aber da haben wir den Zugriff jetzt. Also als Next is, der Foodloader. Das ist der nächste Schritt. Und weil das die Bootstufe ist, geht es sehr schnell vorbei und es persistiert nicht während der Laufzeit. Das macht die Angriffsfähche sehr, sehr klein. Um damit umzugehen, müssen wir die Hardware auch schon und das übergebe ich wieder an Yiffan. Vielen Dank. Ich habe euch gesagt, ich bin wieder da. Wir sind in einer Situation, wo die Software-Leute von den Hardware-Leuten gerettet werden müssen. Worüber ich heute reden möchte, ist Glitching. Das ziemliches Buzzword. Ich bin mir sicher, ihr habt ganz viele Leute darüber reden. Aber ich möchte eigentlich genauer sagen, was ist Glitching denn überhaupt? Wie funktioniert es und warum funktioniert es? Kurz gesagt, es ist ein Hardware-Glitch. Erlaubt uns, einen Software-Verwundbarkeit zu erzeugen, wo keine es gibt. Es gibt viele Möglichkeiten, das zu tun. Eines davon ist die Spannung zu Glitchen. Die anderen sind viel komplizierter oder teurer zu tun. Zum Beispiel, um ein Beispiel zu zeigen, hier habe ich ein bisschen C-Code. Das ist ein Größencheck. Und es ist farbische Daten, wenn der Check funktioniert. Wenn ich das nach mit kompiliert, so sieht es aus. Ich füße einfach mal aus als der Computer. Hier laden wir die Größenwert. SLTU3 ist quasi ein kleiner Gleich anzahnt. Und dann kriegen wir das Resultat davon, dass es auf Null gesetzt war, es nicht kleiner Gleich gewesen ist. Dann sind wir in der Fehlerbranche. Es gibt keine Möglichkeit, das zu hecken. Aber wenn wir ein Spannungslitch einfügen, dann kriegen wir an der Stelle ein Fehler in der Berechnung. Hier sollte er auf Null sein. Aber wegen des Spannungslitches ist es 1. Und dann kriegen wir die Branche. Dann sind wir woanders. Warum funktioniert es? Das ist sehr dicht an meinem Herz dran. Ich möchte wirklich die tiefen Details wissen. Dafür müssen wir leider nach auf Transistor anschauen und Logikgatter. Falls ihr euch daran nicht mehr erinnert, dann ist es okay. Das ist ein NAND. Oder nicht. Und hier ist ein Wahrheitswertetabelle. Das implementieren wir mal in moderner Transistortechnologie, CMOS. Da gibt es zwei verschiedene Transistoren. Die eine Sorte ist auf der Toppart. Ich zeige euch den Diagramm später, dann macht das mehr Sinn. Der Transistor feuert, wenn beim Gate Strom reinkommt. Dann kann es zwischen Source und Drain Strom fließen. Hier sieht man, wie ein Nicht-und-Gate ausschaut. Die oberen Gates sind an, weil 0 und 0 gibt ein 1. Hier sieht man, wie ein Nicht-und-Gate ausschaut. Die oberen Gates sind an, weil 0 und 0 gibt ein 1. Und 1, 1, NAND, 0 ist immer noch 1. Und jetzt sieht man, 1 von den oberen ist an. Und das gibt immer noch 1, 1 von den unteren ist an. Das kommt aber nicht bis ganz unten an. 1, NAND, 1 gibt immer noch 0. Und jetzt sind die oberen beide 0, weil sie notet wurden. Warum sind die beiden unteren an? Das ist damit, weil quasi hier noch etwas Strom durchtröpfelt und der irgendwo weg muss. So, und jetzt hier haben wir ein Glitch. Wenn wir ein Glitch einführen wollen, dann meinen wir damit, dass wir die Spannungsquelle mit Ground, mit 0 Volt verbinden. Wir stellen damit also die Stromquelle ab. Im Moment macht das zunächst mal nichts. Es hat noch ein bisschen übrig gebliebenen Strom, der zum Output fließt. Und das ist, weil man stellt ab, aber es ist noch nicht ganz weg, es tropft noch ein bisschen weiter. Aber ein kleines bisschen später geht der Output gegen 0 und das ist incorrect. Weil 1, 9, 0, das sollte 1 geben. Aber das Wichtige ist, man muss es nachher wieder einstellen und das Ganze korrigieren. Weil wenn man das nicht macht, dann stellen sich alle Transistorien ab und das ganze System gestaltet sich einfach ab und das bringt dann nichts. Also was wir machen ist, wir können ein Nandgate auf incorrecten Output setzen, aber nur für eine kurze Zeit. Wenn wir das zu lange kurz schließen, dann stellt sich das ganze System ab. Aber wir haben noch nicht alle Hoffnung verloren, weil diesen Fehler mit dieser ganz, ganz kurzen Zeit durchpropagieren, wenn wir das an der richtigen Stelle machen. Hier sehen wir eine Baumstruktur aus verschiedenen Nandgates. Und sagen wir, hier können wir einen Voltage, einen Spannungsglitch machen. Aber das ist ein Input für diese 2 und für diese 2 und dann für dieses. Da haben wir jetzt Fehler in etwa der Hälfte der Gates gemacht. Das ist natürlich ein Idealfall. In echt ist das nicht so klar, es ist nicht so einfach rauszufinden, wo überall Fehler passieren. Es gibt natürlich nur einen Fall, wo wir eine 1 kriegen und 3 Fälle, wo wir eine 0 kriegen. Andersrum natürlich. Aber was ich damit sagen will, es ist nicht eine 50-50-Chance um hier den falschen Output zu kriegen. Aber damit können wir falsche Outputs für eine kurze Zeit generieren. Das kann sich durchpropagieren und hat ein Haufen Möglichkeiten, dass es sich wieder korreieren kann, weil die Gates nicht symmetrisch sind. Und das ist so beabsichtigt, darum ist euer Computer so robust, weil er kann Fehler wie das korrigieren. Wir kreieren das manuell. Aber Glitches in der digitalen Logik sind eine Konstante. Das kennt man, das passiert auch ohne äußere Einflüsse. Und Computers sind so designed, dass das damit umgehen kann. Also müssen wir ein spezifisches Ziel finden, damit wir wirklich etwas damit auslösen können. Und der Idealfall ist natürlich, dass wir einen Fehler vorsachen können, der einen Haufen Änderungen kreiert. Beispielsweise bei Arithmet, bei mathematischen Operationen oder bei Verschlüsselungshart. Dort, wo eine kleine Änderung am Input eine große Wirkung haben wird. So, das ist mal die Theorie. Jetzt könnt ihr wieder aufwachen. So, jetzt kommen wir zum praktischen Teil. Da müssen wir rausfinden, wo angreifen, was angreifen und das Ganze automatisieren. Das wird mehr Sinn machen, wenn wir so weit sind. Wo angreifen, heißt, hier sieht man ein Bild des Chips. Also ein bisschen das Boards, wo der Chip draufkommt. Alles, was so kompliziert ist wie dieses System, hat einen Haufen Spannungsquellen, welche verschiedene Sachen mit Stromversorgung, DRAM, Input-Output. Das Einzige, was uns interessiert, ist das, was direkt zu den Transistoren des Prozesses geht. Und da müssen wir rausfinden, welcher Pin das ist. Jede Stromquelle ist mit Dutzenden von Pins verbunden. Das heißt, es ist nicht nur eins, und es hat 724 Pins auf dem Chip. Aber ich kann euch einen Weg zeigen, wie wir das von Hand durchgehen können. Es ist nicht super einfach, aber es ist machbar. Und man kann es in einem Wochenende oder zwei machen. Das ist ein Prozess, wo man die Pins halt kartografiert. Und wir haben jetzt leider natürlich kein Datenblatt, und das ist viel einfacher, wenn man einen kommerziellen Chip hat, wo man das Datenblatt anschauen kann. Dann geht das viel einfacher, aber hier hat man das halt nicht, und dann kann man das so machen. Was man wissen muss, ist, dass man, wie man so ein PCB entschichten kann, und da gab es Talks darüber. Und das Wichtige davon ist, es ist relativ günstig, jeder kann es zu Hause machen, mit den richtigen Werkzeugen. Leider hat jemand namens Byteful hier Scans von diesem PCB hochgeladen. Und das ist gut für mich, dass man die ganzen Nebenprodukte hier nicht einatmen. Mit einer Lötmaske sieht man hier das Layout. Und was ich hier zeigen will, ist, dass einige der Pins sehen aus wie Pins und andere sehen so aus, als ob sie Teil einer Wurst sind oder wie auch immer ihr das hier nennt. Die in der Mitte sind wahrscheinlich stromrelevant. Wenn man einen Chip-Design dann will man den Strom möglichst in der Mitte haben, damit die Wärme und die Energie gleichmäßig verteilt und die Distanz zu jeder Komponente möglichst gleich ist. Also nehmen wir einen zufälligen Pin in der Mitte und schauen mal, wo der verbunden ist, mit welcher Stromquelle und welcher anderen Pins damit in Verbindung stehen. Also haben wir den markiert. Ich markiere eine Schicht in Rot und dann gehe ich eine Schicht runter und werde da in Orange eine neue Markierung auf dieser Schicht machen. Hier sind ja ein paar dieser kleinen dunklen Löcher, die sind dazu da, um mehrere Schichten aus Metall zu verbinden. Wenn ihr da was seht, dann hat es eine elektrische Verbindung zwischen diesen zwei Schichten. Wenn wir noch tiefer gehen, dann sehen wir die Kabel, die größer sind als auf der letzten Ebene. Wenn wir immer, immer weiter gehen, dann kommen wir irgendwann eine Kupferebene, dass unsere Dings verbunden ist. Ich habe es mal hier markiert. Hier kommt der Powerpin hin. Ich zeige jetzt mal nicht, was es tatsächlich mit Stromversorgung ist. Aber hier sehen wir ganz viele andere Kabel auf dieser Ebene, die ich mit Rot markiert habe. Alle sind hier mit verbunden. Dann können wir zurückgehen und das Gleiche tun. Und dann sehen wir wohin es verbunden ist. Und dann sind wir oben. Und dann sehen wir, dass all diese langen Striche verbunden sind. Das heißt hier, dass hier sind alles 35 verschiedene Kabel. Und dann sehen wir, dass alle diese langen Striche verbunden sind. Das heißt hier, dass hier sind alles 35 verschiedene Powerpins. Das heißt, wir brauchen nur noch 680. 245 sind einfach nicht verbunden. Man sieht nicht zwischen Ebene 1 und 2. 175 sind Ground, also Spannung 0, weil die mit einem großen Kupferdingen verbunden sind, wo alle Leute mit verbunden sind. Es sind nur noch 269 Pins übrig. Es ist nicht das Beste, was man am Freitag nach Mittwoch tun kann. Aber ihr wisst, wenn ich, wenn man ich bin, was soll man sonst tun? So sieht der Chip aus, wenn man ihn vollständig analysiert hat. Die roten sind verschiedene Spannungsquellen. Die anderen Farben sind Datenübertragungspins. Das habe ich einfach nur so gemacht, um was cooles zu machen. Wir haben 9 verschiedene Spannungsquellen gefunden. Woher wollen wir wissen, welches der richtige ist? Dafür probieren wir einfach mal alle. Neun Dinge zu Bruteforsten ist relativ einfach. Wir schauen uns einfach mal ein Zähler an, der immer weiter inkommentiert wird. Und dann schließen wir es an dem Computer an. Und dann schauen wir uns an, was passiert, wenn wir die Voltage zu glitchen. Warum funktioniert das? Wenn wir einen Spannungsglitch erzeugen, dann erzeugen wir irgendwo ein Fehler in der Berechnung. Und weil die Arbeit, die der Prozessor macht, hauptsächlich das inkrementieren ist, dann wird, wenn der Glitch passiert, wahrscheinlich ein dieser Additions-Operationen, treffen. Und dann kommt so ein Fehler wie hier. So, jetzt haben wir dieses Tool. Wir haben die richtigen Pinnen gefunden. Wir haben richtige Spannungsquellen gefunden. Wir können irgendwo Fehler erzeugen. Aber was können wir damit tun? Von vorherigen Quellen kennt ihr, dass man den Signaturcheck umgehen möchte. Aber es ist ein bisschen schwer. Wir wissen nicht so richtig, wie die Signatur gepasst wird. Wir wissen nicht, wo die Signatur ist. Wir wissen auch nicht, ob es da noch andere Checks gibt. Es ist schwer zu sehen, ob der Glitch funktioniert hat und was anderes fehlt. Stattdessen haben wir etwas Einfaches zu verstehen. Und das sind der Bootpartition-Header. Es ist relativ einfach zu verstehen. Es ist nicht verschlüsselt, nicht signiert. Man kann alles so ein bisschen erraten, was nicht direkt gegeben ist. Also, was wir uns als Erstes anschauen, ist, dass Partitionsgrößen fällt. Es wird geschaut, dass es kleiner als 0x.de Block im Blöcke ist. Wir haben es herausgefunden durch Versuch und Fehler. Dann haben wir einfach alles durchprobiert. Dann haben wir so eine manuelle Binär-Suche gemacht. Dann haben wir gesehen, dass das größte ist, was funktioniert, bevor es nicht mehr bootet. Falls der Check fehlt, dann stoppt der DCPU einfach. Ansonsten wird der Bootloader gelesen. Was passiert, wenn wir diesen größten Check umgehen können? Hoffentlich gibt es dann ein Buffer-Overflow irgendwo. Warum sonst gibt es diesen größten Check, falls man keinen staatischen Buffer hat? So, was tun wir denn jetzt? Wir schauen uns den Storage-Controller-Traffic an. Wir haben ein MOSFET, was so ein Schalter ist, was den Kurzschluss machen kann, den wir vorhin diskutiert haben. Wir brauchen ein FGDA, ein viel programmierter Gate-Array, was das kontrolliert für das Timing. Das ist der Prozess, um die richtigen Parameter des Glitches zu finden. Wir warten, bis die Boot-Partitionshälter gelesen werden. Dann warten wir noch ein bisschen. Dann wird das den größten Check machen. Das ist, was N ist. Wir fragen uns, wie lange es braucht zwischen dem Lesen des Pakets und dem größten Check. Dann machen wir den Glitch. Wir schließen es kurz für M-Zyklen. Der Grund, warum wir hier sind, ist, wir wussten nicht, was passiert. Je länger man den Glitch durchführt, sind die Resultate sehr verschieden. Wenn man es zu lange macht, dann geht das System einfach aus. Also haben wir hier so ein Skript für jeden Wert von M und versucht einfach verschiedene. Wie implementieren wir das jetzt? Ich habe den ChipWhisperer, den ChipFlisterer genutzt. Das ist eine Open Source Hardware-Hacking-Plattform. Es ist so toll, weil man es Python programmieren kann. Es hat ein FPGA drin und ein MOSFET, was man einzig, was man eigentlich braucht. Außerdem haben wir unseren eigenen Auslöser geschrieben für den Storage Traffic. Wir haben unser eigenes Board gehabt. Warum eigentlich? Eigentlich nur, damit wir all die Kabel zum Vita-Bord zum Storage Controller bauen konnten. So, damit wir auch all die Statusindikatoren kriegen können. Wir haben dieses Board benutzt, um die Search zu dumpen, um die Daten von der Prozesse zu lesen. Das verbindet sich dann zum ChipWhisperer. So sieht es aus, wenn man das zusammengebaut hat. Sehr viel transparente Klebeband. Was ich noch sagen möchte, ist, wir haben tatsächlich die Clock der Vita entfernt und es direkt zum ChipFlister verbunden. Wenn man die beiden Clocks synchronisiert, dann gibt es weniger Drift zwischen den beiden. Dann ist das wiederholbarer, replizierbarer. So sieht es aus, wenn man das zusammengesteckt hat. Ich liebe Klebeband. Das letzte Steck, was wir brauchen, ist von jemandem aus der X-Switch-Community gekommen. Der hat gesagt, wir sollen die Clock noch langsam machen. Wenn man die Clock zu schnell machen würde, dann würde es zu viel Fehler generieren. Also, falls es nicht funktioniert, versucht einfach die Clock langsam anzumachen. Wir haben das die ganze Nacht laufen lassen, als wir am Morgen aufgewacht haben. Dann haben wir einen Fehler gefunden. Das hier ist der Shard 256Hash von der Bootrom. So, Status der Vita in 2018. Wir haben alles gedammt. Den Bootrom ist leider nicht besonders interessant. Keine Schlüssel. Die Angriffsfläche ist sehr klein. Es gibt keinen USB-Stick drin. Wir haben alles gedammt, was wir gefunden haben. Also, was haben wir daraus gelernt? Lass mich ein bisschen philosophisch werden. Sony hat eine lange Geschichte von Krypto-Faelschlägen. Ihr wisst alle wahrscheinlich von denen. Aber wenn nicht, kurze Geschichtslektion. Die PS3 hatte keine Code-Signaturen. Die PS3 hat ECDSA-Faktorisierbar gehabt. In der PlayStation Classic haben sie aus Versehen die privaten Schlüssel für die firmware-Updates mitgeschickt. Aber die Vita ist tatsächlich sehr gut. Das ist eine gute Arbeit, was die Sicherheit angeht. Da kann ich nicht das Gleiche sagen bei dem Marktanteil und der Menge an Games. Aber die Hauptgründe sind, dass sichere Booten einfach sind. Die ganzen kryptografischen Sachen sind ziemlich simpel. Sie verglichen gerade mit anderen Sony-Geräten. Wir haben kaum vom Armprozessor gesprochen. Wo die Games drauflaufen. Aber da sind die meisten modernen Mitigationstechniken drauf. Das war 2012, wo KSLR noch nicht standard war. Und die haben das da schon implementiert. Sie vertrauen nicht einfach der Trustzone. Sie haben einen dedizierten Krypto-Prozessor. Aber nicht jedes perfekt. Und es gibt ein kleines Problem damit, wie sie den Entschlüsselungsschlüssel des Bootloaders gemacht haben. Und das ist der Schlüssel, der jeden einzelnen anderen Schlüssel schützt. Nachdem wir das Bootroom gedammt haben, war natürlich der nächste Schritt, diesen Schlüssel zu finden. Und das ist ein einzelnes Byte, das sich wiederholt. Aber den Vorrag zurückziehen. Bevor wir das gedammt haben, hat unser Freund X, Y und Z, jetzt könnt ihr euch überlegen, ob sein ECO 9 oder 9 Millionen ist, hat versucht den ARS 128 Schlüssel zu Bruteforcen. Aber aus rechtlichen Gründen können wir das nicht mit euch teilen. Also zeigen wir euch mal ein total unverwandtes Bild von Amazon zeigen. Er hat komplett gar nichts mit dem Thema zu tun. Wir müssen uns bei vielen Leuten bedanken. Das sind nur einige davon. Ich will speziell Serpy, aber wenn ich letzte Woche Linux auf der Vita zum Laufen gebraucht habe, was sehr beeindruckend ist, und jetzt versuchen Sie alle Treiber dafür schreiben. Wenn jemand hier interessiert, der helfen will, dann kann ich euch miteinander in Verbindung setzen. Wenn ihr uns beim Nintend Bros. Assembly treffen wollt, alles, was ich erzählt habe, wer da auf GitHub geteilt, wenn ihr mehr wissen wollt, dann ist die Handkaku Wiki eine gute Ressource. Wenn ihr mehr Vita Homebrew schreiben will, dann gibt es das Vita SDK. Da haben wir zu Beginn mitgehofft, das ist eine gute Ressource. Und damit würde ich Zeit für Fragen eröffnen. Hey, great. Thanks a lot. Danke, vielen Dank. Schön zu sehen, wie viel Spaß ihr damit hatte, die zu hacken. Wir haben fünf bis sieben Minuten für Fragen und Antworten. Bitte stelle dich an die Mikrofone. Und wir haben wahrscheinlich hier ein paar Fragen. Ich glaube, bei dem Mikrofon fünf. Ist das an? Ja, okay. Der AIS-Schlüssel für den Bootluder. Ist das ein Witz? Es ist doch überhaupt nicht effektiv. Tja, das war interessant. Also, als wir das gefunden haben, dachten wir zuerst, wir dachten, wir hatten hier einen Debug-Bild. Da muss ein Fehler passiert sein, sie haben uns ein Debug-Bild geschickt. Aber no, das ist der Bootluder, der auf kommerziellen Geräten verwendet wird. Ich glaube, das ist durch die Controller gefallen, weil sie diesen Schlüssel nur verschlüsselt. Sie haben den Kryptoprozessor, zusätzlich zu Food, nur Food kann mit diesem Kryptoprozessor arbeiten. Und der ist für die ganze Verschlüsselung zuständig. Der Schlüssel wird nie in irgendeiner Text-Page oder in irgendeinem Code verwendet. Es ist nur in diesem versteckten Kryptoprozessor drin. Und da hat wahrscheinlich irgendwer den falschen Schlüssel drin gelassen und keiner hat es gemerkt, weil das so gut versteckt war. Eine Frage vom Internet, bitte. Signal, Engel? Kann das, was ich gemacht habe, für die PS4 noch benutzt werden? Wahrscheinlich nicht, nein. Ich glaube, das Design ist exklusiv zur Wieder. Ich glaube, die PS4 hat einen ähnlichen Kryptoprozessor, aber nicht den gleichen. Und die PS4 implementiert gar nicht so viele Sicherheitsmitgationen wie die Vita. Mikrofon 1, vielen Dank für eure Arbeit und euren Vortrag. Ihr habt darüber geredet, wie ihr die Clock manipuliert habt. Habt ihr auch versucht, ihn zu Clock glitchen? Also, da wollte ich nicht zu sehr darauf eingehen, weil es technisch ist. Aber Clock Glitches funktioniert eigentlich, kam nicht, weil es einen facelocked Loop gibt. Und wenn man die externe Clock glitcht, dann wird das von diesem PLL Loop rausgefiltert. Und die meisten Prozessoren haben das heutzutage und darum kann man das nicht mehr nutzen. Mikrofon 3, bitte. Danke. Meine Frage ist ziemlich ähnlich. Ich weiß nicht, ob mein Verständnis von PLLs falsch ist. Soweit ich das verstehe, tut die nur Clock Multiplication oder Division. Das heißt, wenn man die externe Clock ändert, dann sollte auch die interne Clock ändern. Wie weit habt ihr denn die Clock geändert? Das stimmt zwar schon, aber wenn man sich anschaut, wie präzis die Transferfunktion von den PLLs ist, dann, ich weiß nicht mehr, wie es heißt, aber es hat irgendwie verspäteter Antwort. Die Änderungen in der Frequenz sind nicht in Santan und die meisten PLLs sind so entworfen, dass sie nicht schnell ändern und dass damit Schwankungen unterdrückt werden. Und die externe Clock könnte ja etwas Neues beinhalten und die PLLs sollen das ja rausfiltern. Mikrofon 1, bitte. Weil die Hardware und Software relativ ähnlich sind. Geht es auch bei PlayStation TV? Oder ist es nur bei PS Vita? Das wäre cool, das auch mit der PlayStation TV zu machen. Das ist das gleiche Gerät. Ja, ich habe auch ein PlayStation TV, also wenn du zum Assembly kommst, dann kann ich dir zeigen. Mikrofon 3, bitte. Hallo, danke für den Vortrag, sehr interessant. Könnt ihr mir erklären, warum es Octopus heißt? Also, zwei kurze Erklärungen. Eines ist X, sondern Z, der den Exploit gefunden hat. Seine Erklärung war, dass ein Octopus hat drei Herzen und wir haben diese drei kleinen Teile, der Physical Address Table, und ein P zeigt falsch, eins zeigt zum privaten Speicher und eins zum korrektendes, und das sind die drei Herzen. Das macht für mich überhaupt keinen Sinn. Ich habe das Red Con und die Physical Address List, das ist so wie auch die Octopus-Arme, die hier das Memory abgreift. Ihr seht hier auf dem Bild, das sind die drei Teile, die sind drei Herzen. Total sinnvoll. Mikrofon 2, bitte. Meine Frage ist, der ursprüngliche Bootluder, wo ist der gespeichert? Ist es im Fleisch oder im Rom? Das ist eine spannende Frage. Da will ich jetzt nicht drauf nahe eingehen, aber das Bootrom ist nie irgendwie in den Speicher gemappt. Was die Wieter beim Boot abmacht, kopiert sie die Instruktionen für den Boot aus irgendeinem geheimen Hardware-Gebiet, das nie im Überspeicherangreif war, in den S-Rom. Und wenn das Boot RAM startet, dann löscht es immer weiter, die verschiedenen Speicher je nachdem es weitergeht. Letzte Frage. Wenn ihr über die Hardware gedacht habt, wie viel Wieter es bei der Wieter benutzt wird, das ist einfach ein USB-Controller, ein customisierter Konektor, ein customisierter Verbindungsstück.