 Also willkommen zu unserem letzten Vortrag heute und es geht über Konsolenhacking und das ist wahrscheinlich der Grund, warum ich heute hier seit. Es hat eine lange Tradition hier auf dem Kongress. Wir haben viele coole Sachen hier schon gesehen mit der Xbox, mit der Playstation, mit eigentlich fast allem. Aber heute haben wir einen Team, was sich mit dem Nintendo 3DS auseinander gesetzt hat und jetzt bitte Applaus für die Vortragenden. Hallo, ich bin Smeyer, das ist Pluto und das ist Derek und heute werden wir über unsere, unsere Hack von der Nintendo 3DS, wie das Ganze aufgebaut ist, wir gehen über die Hardware auf Bau auf, dann über die Software und wir geben euch so einen groben Überblick, wie die, wie das ganze System funktioniert und dann gehen, also dann werden wir in fast jedes, jedes Sicherheitslevel einsteigen und alle knacken. Also, wie ihr wahrscheinlich wisst, der originale 3DS wurde 2011 rausgebracht. Es ist ein bisschen unterausgerüstet. Es hat einen, zweimal einen AM11 CPU, ein GPU, es ist rückwärtskompatibel mit dem Nintendo DS und dann kam der neue 3DS in 2014, 2015. Es war der, es war praktisch der, der gleiche, der gleiche DS, aber mit, mit, mit mehr Prozesse, so einen Kern, mehr RAM, schnellere Prozesse, aber selbe Software. Es hat ein bisschen exklusiv Software, aber nicht viel. Wie ist die Hardware aufgebaut? Also, das ist, worüber wir jetzt reden werden. Also, im Generalen, hier haben wir den oberen Teil, wo wir zuerst rangehen werden. Das ist der AM11 Überblick. Das ist der Hauptprozesse der hat das, da läuft das Betriebssystem drauf. Es hat vier Kerne. Es, darauf laufen die Spiele, die ganzen Applikationen. Wenn irgendwas, wenn irgendwas mit 3DS macht und man sieht es, dann läuft es auf dem Prozessor. Es hat Zugang zu dem, dem ganzen Speicher, dem, auch das FC RAM. Das sind 128 oder 256 Megabyte, je nachdem, welches Modell das ist. Das ist, das RAM ist aufgeteilt in drei unterschiedliche Regionen. In die Applikationregion, in die Systemregion, wo die ganzen Systemapplikationen laufen, die ganzen kleinen Sachen, die im Hintergrund laufen. Zum Beispiel das ganze Menü, was im Hintergrund läuft und zum Beispiel den Web-Brause. Und dann hat es die Basseregion, weil da hat es die ganzen, die Kernelmodule, die Bassemodule. Und dann haben wir den Web-Ram der den ganzen Kernelcode enthält und die meisten Strukturen des Kernels auch. Das ist auch ein interessantes Ziel. Dann haben wir den unteren Teil. Das ist der AM9 Teil der Hardware. Da haben wir im Wesentlichen ein, das ist eine völlig getrennte CPU, die Zugriff hat auf, na ja, also sie führt also eigentlich den gleichen Kernel aus, der gleiche Code mehr oder weniger. Einige reinere Funktionen führt einen einzelnen Prozess aufs Prozess 9 genannt. Und darüber hinaus ist die Rolle des AM9 Zugriff auf zur Hardware zu auszuhandeln, die vielleicht in Sicherheit etwas sensitiver ist. Also Zugriff auf alle Speichermedien, also hier den dauerhaften Speicher, die SD-Karte und macht alle möglichen Kryptosachen auch, was wirklich wichtig ist und das läuft auf Hardware. Also wir haben diesen Hardware-Keyscrambler, der benutzt wird, um Geheimnisse in der Hardware zu speichern. Man hat zwei verschiedene Schlüssel und diese zeigen einen normalen Schlüssel und dieser wird direkt in die Hardware-Implementierung des Verschlüsselungalgorithmus hinein gespeist, sodass wir nie den kompletten Schlüssel sehen, was ein bisschen ärgerlich ist. Und darüber hinaus haben wir im AM9 den Zugriff für allen Speicher ohne jede Beschränkung. Er hat auch seinen eigenen Speicher, der vom IM11 nicht zugegriffen werden kann. Dieser internen Speicher enthält all diesen Code, all die Daten und auf diese Weise können wir den AM9, also nicht aus dem AM11 heraus übernehmen mit Expert. Das ist also im Wesentlichen eine Sicherheits-CPU. Dies gibt uns nun vier Sicherheitslevels. Wir haben die IM11-Userland-Modus. Darüber dann, oder darunter, den AM11-Kernel, der also volle Privilegien auf dem AM11 hat, und dann haben wir AM9-Userland und AM9-Kernel. Das ist also die Theorie und in der Praxis ist es so, dass der Mikro-Kernel-System einen System-Call hat, den wir nennen in SWC-Hintertür. Das ist ein Funktions-Pointer, der eine Funktion im Kernel-Mode ausführt. Also ihr braucht nicht nur einen Exploit. Wenn ihr Zugriff auf diesen Scholar, braucht ihr keinen Exploit. Nun, auf dem AM11 ist es so, dass keine Applikation jemals Zugriff hat, aber auf dem AM9 haben wir Zugriff darauf. Und das bedeutet, dass von hier aus wir eigentlich Userland und Kernel-Mode nicht unterscheiden müssen. Das ist im Grunde das Gleiche. Wir haben AM9 nur noch im Kernel-Mode. Das ist also schön. Nun, was die Kryptografie angeht, das System grundlegend, ist es so, dass alles, was unterschrieben werden kann, unterschrieben ist oder signiert. Und dies wird nicht nur zur Installationszeit gecheckt, sondern auch während der Laufzeit. Und das ist etwas, was man im Kopf behalten muss. Also alles, was verschlüsselt werden kann, wird verschlüsselt. Alles, was jetzt spezifisch gemacht werden kann für die Konsole, für die Kryptografie, wie Autorizierung, wie das interne, die interne, der interne Fernumte Speicher, die Daten auf dem SD Speicher oder Safe Games, Extra-Daten, externe Daten für Spiele, das wird alles Konsole spezifisch gemacht und Game-Karten spezifisch. Das ist also auch ein bisschen ärgerlich. Und dieses wird natürlich alles vom AM9 behandelt mit der Kryptohatware. Wir müssen also da hinkommen, wenn wir irgendetwas Interessantes machen wollen. Das nächste Mal gehen wir durch den ersten Layer. AM11, Userland, Exportation, Ausnutzung, ein Fuß bereit in die Tür dieses Systems bekommen. Wir müssen also erstmal einen Eintrisspunkt bekommen. Gibt Probleme? Naja, also es gibt Herausforderungen. Eine der Herausforderungen ist, dass das System implementiert, strikte Daten, Ausführung, Verhinderung, Data Execution Prevention. Also Speicher ist entweder lesbar, leschreibbar oder lesausführbar. Es gibt keine Möglichkeit für Internet-Applikationen, neue Seiten als vollzugreifbar zu markieren, weil alle System Calls da ausgeschlossen sind, außer hochprivilegierte Systemmodule. Eine andere Sache ist, dass es gibt keine Address-Space-Location-Vanomisation. Also dadurch werden nun Vorrundbekeiten von Safe Game absolut leicht zugreifbar. Wir haben hier keinen Schutz, solange wir über die Data Execution Prevention herüberkommen können. Und alle Safe Games sind sowohl verschlüsselt als auch identifiziert, spezifisch für die Game Card. Also wenn es um eShop-Spiele geht, ist es sehr ärgerlich. Wir können diese nicht benutzen als Eintrisspunkte, weil wir nicht die richtigen Codes generieren können. Glücklicherweise ist es so, dass die 3DS WebKit ausführt. Das ist schön. Wir können das immer benutzen. Also wo wir benutzt wird, ist es recht viele Plätze. Also z.B. in dem Webbrowser, den man im Hauptmenu erreichen kann oder in der YouTube-Applikation. Man kann also einfach das ganze checkt, aber nicht nach DNS Korrektur, sondern man kann einfach Traffic umleiten. Das ist im Moment noch nicht benutzt, aber vielleicht in der Zukunft. Aber das Tolle ist auch noch, dass es eine sehr alte Version von WebKit benutzt. Wenn man jetzt hergeht und sich ein paar Patches aussucht, kann man sich das ganze schön zusammenstellen. Und dann gibt es sehr viele Fehler, die es wurde von sehr vielen Leuten benutzt. Es gibt sehr viele Wege, aber es ist gezeigt, dass es ein sehr zuverdächtiger Eintrittspunkt ist. Cubing Ninja haben wir auch als Eintrittspunkt benutzt, weil es Nutzer erlaubt, Level zu teilen durch QR-Codes. Und es ist auch noch sehr schlecht im Auslesen dieser Level. Also was man machen kann, kann man hergehen und seinen eigenen QR-Code erstellen, was dazu führt, dass das Spiel dann abstürzt. Also sobald wir drin sind, müssen wir uns daran erinnern, dass wir unsere eigene Code noch nicht ausführen können. Also die offensichtliche Lösung dafür ist Rob. Für die, die sich damit nicht auskennen ist, man baut sich seinen eigenen Stack und kann dann eigene Snippets ausführen, die man implementiert. Also man kann dann einfach irgendwo hinspringen, also zum Beispiel zu dieser Instruktion, was einem erlaubt, seine eigene Regisse zu laden und dann zu was anderes springt. Und das ist dann eine Möglichkeit, Code auszuführen, was sehr weit benutzt wird. Aber das ist halt sehr nervig und sehr begrenzend. Es kann zwar genug sein, um einen Exploit auszuführen, um Sachen auszuführen, aber es ist nicht genug für Homebrew. Zum Beispiel, wir haben keinen Zugriff auf den Systemcall, auf den wir gerne zugreifen würden, um den Rahmen neu zu schreiben. Das Ganze hat auch Libraries, die aber mit der Checks... ...Signis sind und die wir im Moment noch nicht mehr formulieren können. Was man hier sehen kann in der GPU, hat man Zugriff nicht nur zum Grafikremmen, sondern auch zum Vrem. Was werden, dass sich das Ganze anguckt, mit den ganzen verschiedenen Speicheregionen. Das Ganze ist in dem Ganzen drin, was in dem Adressbereich des CPUs liegt. Man sieht hier natürlich Applikationscode, der Zugriff drauf hat. Der Grund, dass der Prozess der Zugriff auf die GPU hat, ist, dass man zum Beispiel auf Texturen zugreifen kann und solche Sachen oder Buffers. Und der Grund, dass man darauf schreiben kann, dass das Ganze irgendwo girendet werden muss und der Hauptspeicher enthält Applikationscode und weil das physische Layout hier völlig deterministisch ist, selbst wenn das nicht wäre, könnten wir die Fähigkeiten der GPU nutzen, um zu das zu suchen, worauf wir was befinden wollen. Also wir können jetzt die Application Text überschreiben und dadurch ein Exploit bekommen. Also haben wir dann also Code Ausführungen, unseren eigenen Code können wir ausführen, was großartig ist. Aber wir haben immer noch die Sandbox, in der wir eingesperrt sind. Wir haben also die Data-Extractive-Kism- Prevention überwunden, aber wir können nur die aktuelle Applikationen, die aktuelle, sichere Daten unserer Applikation lesen und darauf zugreifen. Wir können nur zugreifen auf einige Services und System Calls, was auch eine Beschränkung als Reaktion ist. Wir können das Speicher-Layout nicht ändern, wir können nicht weitere ex-Ausführbare Pages uns holen. Wir sind also relativ beschränkt. Was wir tun ist jetzt uns anschauen, welche anderen CPUs wir noch haben können, nutzen können. Wir haben natürlich eine völlig getrennte Speicherregion, die wir modifizieren können und wir haben die Systemregionen. Das Systemregion enthält das Home-Menü, den Internet-Browser und ein einzelnes System-Modul, das NS heißt. Ich denke, das heißt Nintendo Shell, wir wissen es nicht genau. Schauen wir uns das also mal an. Wir haben hier diesen NS-Code, außerhalb dieses Schnittpunkts für die GPU. Wir haben hier noch Heap, Menus auf dem Heap, also gehen auch über den Bereich der GPU heraus. Also wir können aber nicht alles erreichen. Die Idee ist ja also hier, naja, also wir haben, was interessant ist hier, dass der Schnittpunkt oder der Abschnittpunkt sieht. Es sieht nach Hause, dass Nintendo davon wusste und die Zugriffsrechte, aber dagegen nichts getan hat. Es sieht nach Hause, dass sie es nicht verstanden haben, was wir damit machen können, was ziemlich viel ist. Was wir also im Moment haben, ist ein Menu Hub, was wir haben, wir dumpen den Heap und das ist C++ Code und wir suchen uns diese Objekte in diesem Heap und versuchen diese zu überschreiben. Jetzt suchen wir uns ein Objekt, was durch irgendwas ausgeführt wird, durch irgendwas im Menü und wir stellen jetzt unseren eigenen gefählten virtuellen Table und wir haben jetzt aber immer noch keine Code Execution im Homemenü, aber wir können jetzt z.B. ein paar Sachen machen, z.B. einen neuen System Service, der heißt NSS, er kann jeden Prozess killen oder neuen erstellen und es gibt uns Zugriff auf die SD-Card und es lässt uns alles ausschmeißen und entschlüsseln mit jedem Spiel auf diesem Nintendo DS, obwohl Nintendo erst neue Kryptografie angeführt hat, weil dann das Homemenü anscheinend dazu Zugriff braucht und wir können jetzt auch alle externe Date bearbeiten. Jetzt konnten wir unseren Homebrew Launcher installieren. Also ein Homebrew Launcher ist eigentlich nur ein Dienst, der im Hintergrund läuft und im Hintermenü läuft. Es ist auch geschrieben in Rob, was ein bisschen eklig, aber es funktioniert. Der Service kümmert sich um den Homebrew-Prozess. Wenn man killt das Menü, dann öffnet man neue und übernimmt dann das Ganze. Und was wir jetzt machen, sind die ganzen neuen Möglichkeiten, die wir jetzt haben, über Handels darauf zuzugreifen. Der Service kümmert sich auch um solche Sachen wie z.B. dass der Homebutton gedrückt wird und solche Sachen. Jetzt können wir jetzt jeden Code ausführen in jeder App, die wir wollen. Wir können also jedes Game modifizieren, z.B. Spiele aus Japan, die bis jetzt noch nicht woanders auskam. Wir können z.B. einfach Codes setzen, drüber patchen und dann woanders hinspringen mit dem Adress Speicher um das Ganze zu lösen. Das andere ist, was wir machen können, ist, dass wir auf jede Daten von jedem Spiel zugreifen können. Somit können wir damit auf jeden Speichestand von jedem Spiel zugreifen, weil wir das Homebrew in diesem Recht ausführen können. Damit haben wir eine bessere Möglichkeit, Code zu platzieren, die wir ausführen. Ein weiterer Eintrittspunkt ist ein Menü Hack, das man hergeht und den Fehler im Layout Code ausnutzt, was wirklich cool ist, weil man den Code direkt ausführen kann, wenn man die DS startet, was natürlich cool ist. Natürlich gibt es ein Zelda Game, was exploitable ist und dann gibt es natürlich noch andere Spiele, wo man genügend Eintrittspunkte finden kann für Code Execution. Okay, was machen wir jetzt über die Nintendo Shell? Es ist ein sehr attraktives Ziel, weil es Zugriff auf Titel downgraden kann. Was eigentlich nicht gedacht war, aber du kannst damit Spiele installieren oder den installieren. Man kann hier ein Versionscheck überwinden und ein Downgrading hier im Systemtitel auslösen und dadurch auch Exploits nötig bekommen, sobald man also auf jeden Fall so lange man Zürcher Profis und Service hat. Es gibt hier eine Region, mit der man teilweise Dinge tun kann. Das ist interessant. Leider, aber können wir hier die Daten nicht lesen, aber vielleicht können wir das irgendwohin bewegen, wo wir dann das doch lesen können. Aber was zu tun können, ist eine Instanz von NS-Killen und dann etwas stattdessen ausführen, dann wieder NS ausführen und es dadurch unter die Grenze bekommen, unter die Speicherkranze. Danke. Aber unklicherweise ist es nicht so einfach. Das funktioniert nicht. Wir brauchen nämlich MS, um NS neue auszuführen. Also das ist ein bisschen doof, das nervt. Aber wir können außerdem nicht mehr fache Instanzen derselben Titel ausführen. Aber interessanterweise ist es so, die 3Ds hat ein interessantes Feature, den sogenannten Safe Mode. Das ist eine zweite Firmware, die eine Version der regulären ist und die zeigt einen Haufen von Kopien, von Systemtiteln, den meisten jedenfalls. Und das gibt es ihnen dann eine andere ID. Und die Grundidee ist, dass die dann da richtig zur selben Zeit laufen können, weil das vielleicht nicht bemerkt wird. Aber das wird dann doch bemerkt, man kann also jetzt keine Safe Mode Version gleichzeitig normalen Personales Titels ablaufen lassen. Aber irgendwie mit NS, das sieht man vielleicht nicht so genau, aber auf der Folie, aber wir haben hier einen regulären Titel in NS und wir haben Safe Mode NS direkt hier. Und irgendwie wurde dann also eine 3DS Version. Wir haben also jetzt einen separate Title ID, die zur selben Zeit WNS des regulären NS ausgeführt wird. Wir lassen nun es also laufen, sammeln genug Daten, sodass es sich nach der Grenze befindet und lassen dann das neue NS Safe Mode ablaufen. Das ist dann außerhalb des Bereichs der GPU, man kann es übernehmen und Zugriff darauf bekommen. Das ist also schön, eher ein Versehen als ein richtiger Exploit, aber wie auch immer. Das gibt uns nun einige System Calls, auf die wir Zugriff haben. Wir können also unsere eigenen Services hier hausten, mit denen wir eigene Exploits dann schreiben können, um andere Services dann zu vorzutäuschen oder die Intellität zu übernehmen. Und wir haben nun Zugriff zu all diesen Services hier, was großartiges. Wir können hier Systemtitel herunter stufen und dies läuft alles im Hintergrund, was immer sehr hilfreich ist für Homebrew. Das einzige Problem hier ist, dass es nur für N3DS ist. Es braucht diesen neuen NS-Titel und wir können hier ziemlich hohe Privilegienstufen erreichen, aber immer noch im Userland bleiben. Und es gibt ähnliche Angriffe, wenn ihr interessiert seid daran, könnt ihr ROHACS suchen, was ähnlich ist. Nun wird Derek euch etwas sagen über die Ausnutzung des AMF Kernels. Also, hallo Leute. Als erstes werde ich euch ein paar kurze Einsichten in den Kernel geben und dann werde ich euch erklären, wie man den Kernel, wie man die neueste Version des AMF Kernels exploiten kann. Also, das war Nintendos erster Gaming Console Kernel. Davor gab es kein Kernel, sondern die Spiele wurden direkt auf der Hardware ausgeführt. Es gab zwar einen Kernel für die Wii, ein Mikro-Kernel, der auf dem Security-Prozesse lief, aber das war, aber der wurde nicht von Nintendo geschrieben. Also, das ist ihr erster Kernel. Und der Kernel ist, ist dazu gedacht, dass Threads, dass es Threadsafe ist und dass er damit auf mehreren Prozessoren, Kernen gleichzeitig laufen kann. Es gibt ca. 130 Systemaufrufe. Das sind recht viele in meiner Meinung nach, aber normalerweise, wenn man, wenn man aber Code-Ausführung in der Nutzerumgebung des AMF Kernels bekommen hat, hat man nur Zugriff auf 50, hat man nur ca. Zugriff auf 50 diese Befehle. Es gibt einen Grund dafür, den werde ich später erklären. Intern der Kernel funktioniert mit C++ Objekten. Also, hier sind so ein paar Beispiele für Systemaufrufe. Hier haben wir also Creads Simler Form, das einfach nur ein gleiches Objekt erstellt im Kernel und es gibt ein, es gibt ein Händel zurück für die Nutzerumgebung und wenn man irgendeine, irgendwelche Operationen auf diesem Händel ausführen will, muss man den Händel dem Kernel übergeben und der Kernel wird das ganze dann in der Tabelle nachschauen, um das ursprüngliche C++ Objekt dazu zu finden. Es gibt also zwei unterschiedliche Artenmemorie zu allokieren. Es gibt das FC RAM und es gibt auch ein Slapheap, wo die, wo alle C++ Objekte gespeichert werden und das Slapheap ist in der, in dem XC RAM, was auf dem AM, auf dem AM11 Speich ist, wo der ganze Kernel Code liegt. Es gibt außerdem noch ein IPC System. IPC ist ein Inter-Prozess-Communication-System. Es erlaubt einem mit, es erlaubt, Prozessionen untereinander miteinander zu reden, zum Beispiel, dass verschiedene Services miteinander reden können, als Beispiel der GSP Service oder der File System Service, die miteinander reden wollen. Also lass uns mal die Sicherheit anschauen. Der Kernel ist wirklich klein. Es sind ca. nur 200 Kilobyte Code, was es originaler AM Code ist und es gibt ungefähr nur 1000 Funktionen. Also sie haben wirklich versucht, die Codegröße wirklich klein zu halten und das macht es wirklich schwer, Bugs in dem Ganzen zu finden, da es so wenig Code ist. Und man hat nicht viel Möglichkeit, sich auszusuchen, was man ausnutzen müsste. Es gibt keine Symbole in dem Kernel. Also wenn man Strings drauflaufen lässt, würde es einem nur den Namen eines C++ zurückgeben, aber es gibt keine Funktion dazu. Wir früh gesehen haben, es ist für physikalisches isoliertes Speicher, was natürlich eine gute Idee war. Sonst wäre es natürlich leicht beschreibbar gewesen von der GPU und alle Objekte haben Reference Counting. Das ist ähnlich zu C++ Shared Pointer, wo jedes Objekt ein kleines Feld besitzt, ein Zähler fällt und jedes Mal, wenn der Kernel ein Objekt benutzen will, wird dieser Zählerstand 1 hochgezählt. Und wenn der Link nicht benötigt wird, wird der Counter wieder um 1 reduziert. Und wenn der Counter 0 erreicht, wird das Objekt automatisch gelöscht. Also sie versuchen, und ich bin nicht ganz sicher, ob das ein Sicherheitsfeature ist, aber es gibt mehr als 100 Panic Calls im Kernel. Das ist jede zehnte Funktion im Durchschnitt. Und sie haben die Syscall Zugriffsrestriktion. Also wie ich gesagt habe, hat man nur Zugriff auf ca. 50 Systemaufrufe. Und die ganzen Interessanten sind natürlich deaktiviert. Als Beispiel, man kann zum Beispiel nicht ausführbare Speichesite mapen. Auf der anderen Seite gibt es kein ASL, aber bei jedem großen Kernel Update. Außerdem gibt es keine Stack Protektion. Und das Userland ist die Nutzung, die immer mehr. Also sobald man Zugriff auf den Programm Counter hat, kann man einfach in den Nutzerbereich springen und dort einfach Seiten ausführen, die dort liegen. Also man muss nicht Rob im Kernel ausführen. Aber sie haben versucht, eine Ausführverhinderung zu haben. Sie markieren ausführbare Kernel Pages als ausführbar in der Page Table. Also schauen wir es mal an. Die orangen Teile sind Kernel Code Parts. Und wir sehen können, wenn man sich an der ersten orangen Linie orientiert, mapped zu einer physikalischen Adresse. Und es ist nicht als ausführbar markiert. Doch die ist als ausführbar markiert. Man hat Zugriff darauf. Und man hat im Kernel Modus dann Zugriff darauf natürlich, aber nur lesen Zugriff auf diesen Speicher. Ausführbar und nur lesbar. Dies ist also korrekt. Aber wenn man jetzt schaut, wenn man sich die zweite Zelle dieser Page Table, dieses Dumps von der Page Table anschaut, dann seht ihr, dass es einen weiteren Abschnitt gibt, der den gesamten W-Ramen abdeckt. Und dieser wird gemapped als Leseschreib und ausführbar. Das macht nicht richtig Sinn. Also im Wesentlichen haben wir völlig nutzlose Data Execution Prevention. Also um zusammenzufassen, es gibt keinen Schutz gegen Exploits. Wenn wir einen ausnussbaren Bug finden, ist es ziemlich wahrscheinlich, dass wir Codausführung im Kernel-Mode erlangen können. Also lasst uns diesen Bug finden. Ich fing an mit einer Betrachtung der SWC-Tabelle. Dies ist das Interface sozusagen zwischen Kernel-Land und User-Land. Dies zeigt all die System Calls, die im Kernel verfügbar sind. Wir haben mit was wie normale System Calls für Memory Management. Wir haben hier lesbare, schreibbare Pages. Wir können Seiten spiegeln für andere Memory Management-Geschichten. Es gibt Konfigurationen für Threads. Man kann nach der Wahl, ob Core benutzt wird für die Ausführung eines Threads. Wir haben einen sehr großen Bereich von Synchronisationsobjekten. Also Kernel-Mutex und all diese Sachen. Und wir haben natürlich auch Inter-Protest-Kommunikations-Recasts, könnt Nachrichten an Services schicken. Und es gibt einen noch weiterentwickelten Abschnitt, der noch weiterentwickelt ist, der von Services hauptsächlich benutzt wird, weil die Antworten müssen auf IPC-Request in der Protest-Kommunikation. Es gibt direkt ein Speichersuch auf das Kernel. Es gibt Cash-Kontrolle. Es gibt noch eine Anzahl von Debug-System Calls, die einfach normales, rohes Debugging sind. Also Prozess, Speicherlesen, Schreiben, Memory Management. Dort hat man eigentlich keinen Zugriff in der Verkaufsversion. Da wird es nicht wirklich benutzt. Und ein letzter Abschnitt ist der Privilegiette-Abschnitt, der enthält all die sehr interessanten System Calls, die gestatten Prozesse zu erzeugen, Memory-Mapping auszuführen oder ausführbaren Speicher zu mappen. Dann leider können wir diese vorgeschrittenen Debug und privilegierten System Calls nicht benutzen. Naja, dies würde erfordern, dass wir Services ausnutzen oder exploiten. Und das ist einfach mehr Arbeit, die wir bisher nicht leisten konnten. Dies lässt uns also beschränkt uns also auf den normalen System Calls, aber IPC Inter-Prozess-Kommunikations scheint hört sich wirklich interessant an, aber ist leider voll von Panik aufrufen. Ja, außerdem gibt es nicht so viel, was man angreifen kann, weil was Synchronisationsobjekte angeht. Wir haben also nur diese interessanteren System Calls für lokales Speichermanagement. Theoretisch gibt es eine Menge hier, was man durcheinander bringen kann. Vieles, was hier schiefgehen kann. Und wir haben außerdem ungeprüften Direkt-Zuruf auf den Speicher für die CPU. Also vielleicht können wir irgendetwas Sinnvolles Nützliches damit anfangen. Also schauen wir uns mal den Memory Allocator an. Es gibt zwei Typen von Memory Allocators Speicherzuteilern. Wir haben einer der regulären, womit der normale Heap gemapped werden kann für VMalloc in C zum Beispiel. Und wir haben dann den linearen Allocator für CPU-Texturen oder GPU-Texturen. Wenn Speicher also hier physisch zusammenhängend sein muss, dann nehmen wir den linearen Speicherzuteiler. Dann gibt es das FC RAM Memory Layout, das FC RAM Speicher Layout. Das hatten wir vorher, wir haben diese drei Regionen. Und jede Region hat ihre eigenen, selbst im eigenen Satz von freien Seiten. Also wie wird das verwaltet? Wie bleibt man da auf dem laufenden? Wir haben diesen Regionsdiskriptor, der Dimensionen wie Basisadresse und Größe enthält. Und wir haben auch Pointer zum ersten freien Stück Speicher in dieser Region. Und jeder, also alle freien Speicherstücke, die wir ihr Memchunks nennen, haben einen Header gleich am Anfang. Und dieser sagt dem Colonel im Wesentlichen, wie groß dieser Memchunk ist und ist außerdem ein Link in eine doppelt verlinkte Liste, sodass wir also den nächsten und vorigen Speicherplatz als Pointer haben. Dieses sieht also ungefähr so aus. Ihr habt hier die roten Teile, das sind die freien Memchunks und die grünen Teile sind Speicher, der bereits zugeteilt worden ist. Also Zuteilung ist relativ einfache Sache, nicht sehr kompliziert. Das erste ist, dass die Zuteilungsfunktion und das erste, was die Zutailungsfunktion tut, ist den nächsten freien Pointer. Vom Ursprungsdiskriptor zu laden und für normalen Speicher, regulären Speicher geht der Code einfach durch die Liste, folgt den Pointer und addiert die Größen auf, bis die gewünschte Größe erreicht wird. Für linearen Speicher würde man einfach ein passendes Memory-Chunk gesucht, um sicherzustellen, dass es sich um Speicher in einem Stück handelt. Und wenn das gefunden worden ist, wird dann der Nxt Pointer auf diesen letzten Memchunk, dieses letzten Memchunks, der Nxt Pointer dieses Memchunks, wird auf 0 gesetzt. Dann haben wir also das Ende der Liste markiert und dann wird ein Pointer zu diesem ersten Memchunk zurückgegeben. Schauen wir uns also das von einer Sicherheit, von der Perspektive der Sicherheit an. Es gibt ein Problem, wir haben hier Kernelstrukturen im FC RAM, das ist ein Problem, denn wir haben dadurch einen, wir haben nämlich direkt einen Speicherzugriff daraus, darauf über die GPU. Es gab einen Angriff durch Yellows 8, der Memchunk Hacks heißt. Was er tat, ist im Wesentlichen, dass er Memchunkheader über den direkten Speicherzugriff der GPU überschrieb, diese Schwachstelle ausnutzte und hatte dann also einen beliebigen Schreibzugriff auf den Kernel, wenn zumindest dann, wenn Speicher freigegeben wird, weil Nxt und previous Pointer dann modifiziert wurden. Und unglücklicherweise wurde diese aber gefixt von Nintendo mit einem Update 930 vor etwa einem Jahr, Dezember 2014 und der neue Kernel wird nun jeden Memchunkheader erst mal prüfen vor der Zuteilung Größe und Nxt und previous Pointer, sodass also theoretisch alles gefixt ist. Und in valide Pointer oder in valide ungültige Speichergrößen führen einfach zu einer Kernel Panic, ja also in der Thürie. Aber wenn man sich einen System Call für den Control Memory anschaut, da haben wir Zugriff darauf. Dies ist einer der normalen System Calls. Es macht grundlegende Dinge wie mappen oder freigeben von leschreibbaren Speicherseiten, aber nicht ausführbaren natürlich. Es nimmt sich eine Adresse und Größe und ein Operator, ein Operat Operations Code als Parameter, der dem Kernel sagt, was geschehen soll, mappen, freigeben oder was auch immer. Dieser Code führt erst mal einige einfachen Checks auf der Adresse aus und dann letztendlich wird er eine sehr große Funktion aufrufen. Ich nenne diese Funktion einfach Kern Control Memory. Was Kern Control Memory tut, ist, es ruft die Sprecher Zuteilungsfunktion auf und wird dann einen Memchuck-Header-Pointer erhalten, wie wir vorher gesehen haben. Und dann geht der Code durch alle zugeteilten Memchunks und mapt sie in den Userspace. Und es ist außerdem einige Blockinformationen für den, für das Kernel Process Objekt. Da haben wir so ein Problem. Offensichtlich haben wir hier eine Race Condition. Wir können überschreiben, Memchunk-Header können wir überschreiben, nachdem sie zugeteilt worden sind. Also wir könnten versuchen, die GPU zu benutzen, aber die ist tatsächlich sehr langsam. Wir müssten sie bitten, wir müssten den Service bitten, Speicher zu lesen. Und ja, wir müssen dann zu diesem sehr großen IPC Kernel Code gehen. Der wird wahrscheinlich zu langsam sein. Zuteilung ist sehr, sehr schnell. Also bleiben wir erst mal oder graben wir noch ein bisschen tiefer. Ich versuchte hier zu konstruieren, wie das Health Code in C aussieht. Dies ist der erste Schritt. Er versucht hier Speicher zu zuteilen. Für dieses Beispiel haben wir nur regulären Speicher zugeteilt oder erbeten. Und wenn wir dann einen Memchunk gefunden haben, was das bedeutet, dass das nicht, wenn wir keinen Memchunk gefunden haben, also keinen Speicher mehr haben, damit diese sehr interessante Dual-Schleife ausgeführt. Ja, es ist viel Code. Ich weiß nicht, ob man das überhaupt lesen kann. Gehen wir also schnell durch diesen Code. Da gibt es die Seiten, es wird hier von dem Memchunk-Header gelesen, werden, die werden eine physikalische Adresse kommentiert und dieser Adresse wird nach Userland gemapped mit einer Memmap Funktion. Und dann geht es zum nächsten Memchunk hier und wird dann auch die Userland virtuelle Adresse aktualisieren und dann den Speicher löschen oder freigeben oder leschen. Also was ist hier das Problem? Das Problem ist, dass das Mapping dieses Memchunks in Userland, dass das ausgefüllt wird und nachdem gemapped ist, wird das hier auf der nächsten Pointe zugegriffen und wenn wir jetzt von einem anderen CPU Core auf diesen Speicher zugreifen und überschreiben, was wir können, weil er im User Space ist, dann könnten wir also Kernel Pages in User Space mappen und dann gibt es aber einige Probleme. Dies erfordert wirklich perfektes Timing. Es gibt nur ein sehr kleines Zeitfenster, um dieses Überschreiben durchzuführen. Wir haben außerdem, brauchen außerdem eine Memchunk-Struktur im Next-Pointer. Also dies zu machen, um sicherstellen, dass wir perfektes Timing bekommen, kam ich auf das K-Address-Arbiter Oracle, das eigentlich für Thread-Synchronisierung benutzt wird. Das kümmert uns nicht, aber es versucht von einer vom Parameter Address zu lesen und gibt ein Fehler zurück, wenn Address oder Address nicht für den User zugreifbar ist und wir können das benutzen, diesen System Call, um sicherzustellen, dass der Speicher gemapped ist in das Userland und wenn er gemapped ist, versuchen wir sofort ihn zu überschreiben. Also ein letztes Problem, wir müssen hier ein Memory-Chunk injizieren im Kernel. Ich habe das mit dem Slab Heat, das versucht. Wir können einfach einige Kernel-Objekte erzeugen, ihre Members setzen, um ein gefälschtes, ein gefägten Memchunk-Header zu erzeugen. Dies ist der Slab Heap. Wir haben hier C++-Objekte, virtuelle Pointer und einige Attribute. Der Slab Heap ist im Wesentlichen einfach ein sehr großes Array von C++-Objekten und was ich hier zugegangen getan habe ist, ich habe die Attribute verändert und sie benutzt als Memchunk-Header. Ich biege den Next-Pointer um auf dieses Objekt und das mapt dann mehrere C++-Objekte in das Userland und das ist wirklich sehr schön, denn wir haben hier mehrere Free-Table-Pointer, die wir einfach überschreiben können. Das bedeutet, dass wir Codausführung erreichen. Also um zusammenzufassen, wir erstellen einige Kernel-Objekte, bitten den Kernel um Speicher. Wenn er zugreifbar wird, patchen wir den Next-Pointer, überschreiben diese gemapten Slab-Heap-Pages, dann nehmen wir ein System-Call, der den Handel schließt, um diese Kernel-Objekte zu deallokieren, die wir im Schritt 1 erstellt haben, sodass dann letztendlich eine Vtable-VTable-Funktion aufgerufen wird und dann einfach in unsere modifizierte VTable-Funktion springt und dann haben wir also Arm11 Level Zero Codausführung erreicht. Also und ich, jetzt wird Pluto uns erzählen, was man alles Tolles machen kann, wenn man Arm11 Codexecution hat. Hallo Leute, also ich werde über der Arm9 reden. Los geht's. Also der Arm9 ist auch dazu benutzt, um alte DR-Spiele auszuführen. Sie haben also den Arm9 benutzt, um die Rückwärtskompatibilität zu behalten und als Sicherheitsprozess, wenn 3DS-Spiele ausgeführt werden. Und es, darauf läuft eine reduzierte Version des ARM Kernels. Es gibt keine MMU, es gibt eine MPU mit acht Regionen, die man konfigurieren kann. Man kann nichts darin ausführen und so weiter, aber es ist nicht gerade genau. Und sie haben gerade nur acht und sie haben deswegen nicht genügend Platz gehabt und da ist nicht mehr ausgegangen. Und man kann Text schreiben und man kann auf Data und Stack zugreifen, der ausführbar ist. Also, wann immer man Code in Arbitr-Speich-Adressen schreiben kann, dann kann man Code überschreiben. Das sind Sachen, die man nicht auf einem Sicherheitsprozess haben will. Also, los geht's. Im Moment, so wie es aussieht, gibt es viele Exploits über die Jahre, aber viele wurden behoben und viele haben einfach nur das normale Commandinterface benutzt, aber in diesem Fall benutzen wir eine andere Herangehensweise. Auf dem 3DS ist das Speicher zugeordnete, ist unterteilt in drei Bereiche. Es gibt in einem neuen exklusiven Eingabe-Ausgabe-Bereich, in dem geteilten IO-Bereich und nur AM11-Bereich. Dank zu den anderen zwei haben wir volle Kontrolle über den AM11. Also, können wir irgendwie den geteilten Memory-Speicherplatz nutzen, um den AM9 zu exploiten? Wir gehen zu dem Interface, das alte DS-Spiel ist, das ist nämlich in dem geteilten Speicherbereich. Wieso ist nicht sicher, weil es warum es da ist? Aber sie haben es da auch sogar im Grund. Und es ist nur der AM9, der die Region benutzt, aber der AM11 hat trotzdem Zugriff drauf. Wenn man also ein Kassett einschiebt, beginnt es dabei, den Titel zu lesen, in dem es diesen magische Nummer irgendwo hinschreibt und es fragt nach. Und es gibt diese Schleife, die man da sehen kann. Es wartet praktisch darauf, dass ein Bit freigegeben wird und ein anderes gesetzt wird. Dann wartet es noch für ein Bit und es gibt keine Kontrolle auf dem Buffer, weil es immer 200 bytes sind, also so sollte das passen. Also, was würde passieren, wenn wir jetzt das Kontrollregister des AM11 überschreiben, um zum Beispiel für 4000 bytes zu fragen? Wir haben also einen schönen Buffer-Übelauf. Können wir da mit die Daten kontrollieren? Also, die Daten kommen von der Kassette, die man einsteckt. Also müssen wir unser eigenes DS-Spiel Kassette bauen. Es gibt diese alte Platine, was pass me und wo man alte Karten reinstecken kann, was dann den Header modifiziert. Die gibt es online, die kosten 5 Dollar und es gibt unter noch einen FPGA. Das habe ich gebaut und es funktioniert. Es ist sehr anfällig, ich kann es nicht empfehlen. Und hier ist, wie ich es gelötet habe, nicht gerade meine beste Arbeit. Aber das gibt uns einen neuen Code-Ausführung. Aber wir wollen was Besseres. Also, wie sieht die Kette des Vertrauens aus? Also, die Idee dieser Kette ist, dass man den allen Code verifiziert, der ausgeführt wird, wenn er geladen wird. Der 3DS hat die kürzeste Kette des Vertrauens, die es gibt. Es gibt ein Bootloader, der das Image vom NAND-Lad und dann dazu springt. Auf dem neuen 3DS gibt es eine Ebene mehr, auf einem ARM-Layer, was nochmal Verschlüsselung macht. Wir nennen das AM9-Loader. Die Theorie, die Nintendo wasch ich hatte, ist, wenn wir nochmal einen Level mit Verschlüsselung einbauen und die Schlüssel austauschen, können die Leute nicht knacken. Aber sie hatten keinen Platz, um die Schlüssel irgendwo abzuspeichern. Also haben sie es im NAND gespeichert. Aber die NAND ist damit mit einem Schlüssel verschlüsselt, der aus dem OTP stammt. Später kann man also auf den OTP zu greifen, damit den Key laden und damit alles entschlüsseln. Also, das sieht sicher aus. Aber hier ist ihre Implementation. Sie rechnen hash, lesen den Schlüsselsektor vom NAND und laden ihn. Es ist eine isolierte Speicheregion. Und dann generisieren sie mehrere Unterschlüssel und kontrollieren nochmal, ob das der richtige Schlüssel ist. Also selbst wenn es versucht, das auszutauschen, würde es nicht klappen. Und dann entschlüsseln sie das AMM-Benerfall und dann springen sie zu diesem Startpunkt. Aber sie haben vergessen hier den Speicher wieder zu löschen. Also, diese Implementation ist praktisch nutzlos. Nintendo hat es natürlich in Ordnung gebracht, weil sie haben mehrere Schlüssel im NAND versteckt. Die nächste Idee war genau dasselbe. Man berechnet den Schlüssel, man lädt es vom NAND, man errechnet einen zweiten Schlüssel. Dann entschlüsselt man die AMM-Binary dann mit dem zweiten Schlüssel, dann löscht man diesmal den Key zu schlauen und geht dann weiter im Bootprozess. Diesmal haben sie vergessen den zweiten Key zu löschen, mit dem wir das binary... Also, was wir machen können, ist den zweiten Schlüssel austauschen. Der Neunler wird entschlüsselt und man springt dazu. Wenn sie sich die Kordierung von dem ganzen an guckt, eine Brunch Instruction, irgendwelche Zufallstaten einstreiben, wenn wir genügend Schlüssel ausprobieren, würde es irgendwann eine Brunch Instruction geben zu irgendeinem Speicher. Also, wenn wir jetzt sehr, sehr, sehr viele zwei Key-Nummer-Zwei-Werte ausprobieren, dann kommen wir irgendwann dahin, wo wir wollen. Dies ist hier das NAND, das Flash-Speicher einer unmodifizierten 3DS. Es gibt einen kleinen Key-Schlüsselabschnitt hier in Blau markiert, der enthält diese Schlüssel, über die wir reden. Und dann gibt es zwei Firmware-Partitionen, eine als Backup, falls eine irgendwie korrompiert wird. Also, dass das Gerät nichts gebrickt wird. Wir installieren jetzt unseren eigenen Schlüssel, installieren das größte Firmware-Binary, das wir haben in der ersten Firmware-Partition und halten die mit der Verwundbarkeit in Partition 1, der zweiten Partition. Und dann tun wir unser Payload über die Firmware 0, die erste, dann buten wir neu und was passiert? Der Bootroom, der einem neuen wird ausgeführt, der letzt die erste Firmware in Partition, also die Nummer 0, mit unserem Code in den NAND. Weißt das nicht, dass unser Code dabei ist? Das wird dann entschlüsselt. Es sieht gut aus, da ist der Stubb des IM9-Loaders, dann kommt das verschlüsselte Binary und dann kommt unser Payload. Aber, Bootroom checkt den Hash, oder? Und das schlägt fehl, also denkt es, dass die Partition korrompiert worden ist. Nun wird die kleinere Firmware darüber geladen, wir haben hier unseren Payload, also noch im Speicher, eben zur Bootzeit. Und dann wird Firmware 1 entschlüsselt, die kleinere Firmware hat immer noch den IM9-Loader und springt dann zum IM9-Loader, weil der Hash in diesem Fall erfolgreich berechnet wird. Und der IM9-Loader wird nun unseren korrompierten Schlüssel aus dem NAND entschlüsseln. Da kommt dann Müll bei heraus, wird dann dorthin springen und hoffentlich springt das dann zu unserem Code. Also, das gibt uns einen neuen Code-Ausführung vom Code Boot sehr, sehr früh. Wir können dies benutzen, um einige Keys zu benutzen, die später nicht mehr erreichbar sind, weil sie gelöscht worden sind. Es wird ein bestimmtes Speichagegen benutzt für die Entschließungs-Engine. Der Speicher wird später gelöscht, sodass man die Schlüssel nicht neu erzeugen kann. Aber, hiermit können wir tatsächlich diese beiden Schlüssel erhalten. Und diese heißen der Firmware 6 Safe Key und der Firmware 7 NCCH Key. Okay, ein Bonus. Und dann haben wir über die IS-Engine gesprochen, die hier für die Kryptografie überall benutzt wird. Und die wird für alles mehr oder weniger benutzt, all die üblichen Block-Cypher-Modes. Und diese hat zwei Sicherheitsfeatures. Die Schlüssel sind nur schreibbar, sehr nützlich. Man schreibt Entschlüssel und kann ihn nie mehr zurücklesen. Was bedeutet, dass man durch den Bootraum die Schlüssel ausfüllen kann oder eintragen kann. Und sie dann später nicht mehr auslesen kann für einen Dump. So bleiben die Schlüssel geheim. Selbst wenn wir die neuen Hacken, selbst wenn wir Coda-Ausführungen erreichen, dann kriegen wir immer noch nicht die Schlüssel. Und dann gibt es den Keys Scrambler, das ist eine optionale Funktion. Der eigentliche Schlüssel wird im Verbraugenden berechnet. Wir kennen den nicht. Die Schlüssel wird niemals der CPU übergeben oder gezeigt. Wir haben diese beiden Schlüssel und bekommen einfach einen neuen Schlüssel und wir wissen nicht, was dieser Schlüssel ist. Dies führt uns zu einer Situation ähnlich wie bei den isolierten FPUs, wo wir also darum bitten können, etwas zu entschlüsseln, aber nicht überniemals die Schlüssel bekommen. Wir wollen aber dieses Schlüssel haben. Wir wollen Dinge entschlüsseln. Wir haben also zwei Schlüssel Kx und Ky. So nennen wir sie beide 128-Bit. Der normale Schlüssel wird wie folgt abgeleitet. Diese mit einer Funktion, die unbekannt ist in Hardware, also Insilition implementiert worden ist. Und selbst wenn wir X und Y kennen, können wir nicht den normalen Schlüssel herausbekommen und Dinge nicht entschlüsseln, ohne dass wir die 3DS darum bitten. Aber wir können diese Hardware-Engine anstoßen. Wir können, was wir hier also sehen, ist das Ente-Bit vom X Schlüssel und das Ente-Bit vom Y-Key das gleiche Ergebnis liefern. Und wir finden also, dass die Funktionen, nach der wir suchen, eine Funktion nur einer einzigen Variable ist, dass exklusiv oder zwischen X und 2 rotiert, rotiert nicht geschiftet, exklusiv oder verknüpft mit Y. Wir haben immer noch einen unbekannten Schlüssel, aber wir wollen das G. Geben wir ein Stück zurück. Der Keyscrumbler wird benutzt für Dinge wie Mii-QR-Codes. Alles wirklich, also Netzwerk-Protokolle. Es gibt eines namens 3DS für das Downloaden von Spielen über Wi-Fi, das für temporäre Spiele. Das wird alles unterstützt, aber wir haben das Wii, der Schütz Aldis, hat aber nicht hier den Schlüssel in Hardware. Müssen also davon ausgehen, dass die Wii den normalen Schlüssel, den regulären Schlüssel hat. Okay, wir haben also eine Tabelle, in der wir die gemeinsam Schlüssel eintragen. Die sind die 3 Keys, die mit der Wii U geteilt werden. Da, wo die X und Y Schlüssel gesetzt werden auf der 3DS, 2 davon werden von der firmware gesetzt. Wir können also die Keys, die vom Bootraum gesetzt werden, nicht lesen. Dieser ist uns verschlossen, wir können ihn nicht lesen. Aber können wir noch G-House finden? Schauen wir mal. Ich möchte hier erst mal einen Lob ausbrechen für Shuffle 2 und Failoverflow, die die Wii U gehackt haben und uns geholfen haben, die Wii U-Schlüssel zu extrahieren. Vielen Dank. Nun haben wir Key Y und wir haben von der Wii U den damit korrespondierenden Normalschlüssel. Aber Key X ist immer noch unbekannt und falls G von T schlecht ist, dann wird eine kleine Änderung in Key Y nur eine kleine Änderung im normalen Schlüssel auslösen. Und ja, das ist Bad Spoiler, das ist das Ergebnis. Schauen wir uns die Daten an. Wenn wir einen Bit in Y austauschen oder flippen, umkippen, dann ist das Ergebnis nur 1 oder 2 Bit flipps und die im normalen Schlüssel und diese geflippten Bips sind in Positionen entweder 87 oder 88, manchmal 89, aber niemals 86. Dies erinnert mich an so etwas wie einen Adira, wo wir einen Carry Bit haben, das weitergetragen wird nach oben, aber niemals nach unten. Also raten wir mal, dass dies vielleicht ein Adirmodulist oder eine Adirungsfunktion ist. Ja, es ist eine Adierung mit einer Rotation, Addition mit Rotation, also T plus C mit einer konstanten C, die wir nicht kennen, dann 87 Stellen rotiert nach links, dann stecken wir es unsere Originalformel. Wir kennen Key X nicht, erinnert euch daran, weil die durch den Buton gesetzt ist, wir haben Schüssel X nicht, wir haben eine Konstante C nicht, weil die im Silizium hart encodiert ist. Also trotzdem, wenn wir unsere Formel anschauen und hier die Ungleichheit anschauen, diese Ungleichung, die wir durch das Rotieren erhalten, wir lassen sozusagen die Rotation rückgängig rückwärts ablaufen, nehmen das zurück und dann bekommen wir dies hier, CnC auf beiden Seiten ab, dann bekommen wir dies hier und dies ist nun das Exor von verschiedenen Schlüsseln mit dem selben X-Wert rotiert nach links. Wenn wir das eine Weile anschauen, dann sehen wir, wenn Y0 und Y1 zwei verschiedene Teile von Schlüssel Y, wenn die gleich sind, außer in einer Bitposition, dann wird das X oder, das exklusive Oder, am kleinsten für den Wert, der das gleiche Bit hat an der Position, nämlich das X, was dieselben Bitwert hat an der Position, wo sich die Y unterscheiden, es hört sich kompliziert an, aber es ist, also X ist 0, wenn der Input verschieden ist, wenn es gleich ist, bekommen wir 0 und das ist dann kleiner. Wenn wir uns das anschauen, wenn wir dies 128 mal durchführen, dann können wir alle 128 Bits von KX auf diesen Weg bekommen und wenn wir KX bekommen, können wir die Silikonkonzentration, Konzentration C berechnen, sodass wir am Ende den Key Scrumbler herausgebrochen haben und außerdem den geheimen Bootchrom Key Schlüssel X für den Slot als Bonus bekommen haben und auch habe ich hier, ich habe, ich habe pinnig die Konstanten in den Folien, weil ich euch das als Übung lassen wollte. Als der neue 3DS rauskam, haben sie sich beeilt und haben ein paar interessante Sachen, ein paar interessante Fehle drin gelassen und zum Beispiel eine frühe Version der NFC-Krypto, die später setzt wurde und die erste Implementation benutzt einen normalen Schlüssel und in der neuen Version wurde es geändert, wurde zu Key Y geändert. Also gaben sie uns beide Schlüssel jeder der 3DS Firmware zerlegen kann, kann auch diese Ausführung machen, um das ganze umzusetzen der Angriff gegen NFC zu fahren. Okay, zurück bei einer Zusammenfassung, also ich würde jetzt ganz schnell den Schluss machen, also die Dinge, die wir heute besprochen haben. Zunächst mal, es ist eigentlich ziemlich offensichtlich, aber okay, habe Geduld mit mir. Also wir haben hier Physischen-Zugriff für jede Applikation, selbst wenn man denkt, dass ihr es gestützt habt, habt ihr wahrscheinlich irgendwas vergessen. Also das ist sehr gefährlich, Access-Zugriff auf Physischen-Spächer zu geben. Geteilte Input-Output ist gefährlich, wir wissen nicht, was diesen Input-Output kontrollieren kann, deswegen sollte man sehr sehr vorsichtig sein. Außerdem sollte man Daten nicht nur vor der Entschlüsselung checken, das ist gefährlich, wenn man den Key nicht checkt, der vielleicht modifiziert werden könnte. Schlechte Idee. Gespeicher in der Hardware sind eine schlechte Idee, aber wenn ihr die dann freigibt, das funktioniert es nicht. Also wir reden jetzt hier vielleicht an den VUTalk vor zwei Jahren. Wir dachten nicht unbedingt, dass es hier unbedingt ein Feature für die Konsole, für Homebrew sein würde, aber jetzt mit dem Aufkommen von Smartphones, jeder kann einen abschreiben für irgendein Gerät und das Millionen für Menschen verkaufen. Aber wir sind nicht dieser Meinung. Es ist ein Jahr her, dass wir 3DS Homebrew gesehen haben. Dies soll sich eigentlich bewegen, bedenkt euch mal, dass sich das bewegt. Es gibt also einen Haufen von 3DS Homebrew, großartig, wir haben hier sehr hart daran gearbeitet, viele Menschen sind dabei, es ist eine große Community, die sich darum bemüht. Wir wollen also einfach nur sagen, wir möchten mehr Developer, wenn ihr uns also hier bei uns mitmachen wollt, es gibt eine sehr reifende Community Reverse Engineering, der Hardware macht Spaß, wenn man keine Dokumentation hat. Software Reverse Engineering macht Spaß, wir können immer mehr Engineers gebrauchen, Leute, die coolen Chips machen. Also ja, noch etwas. Und eins noch, letztlich gab es eine Welle von Patches von Nintendo, die Sicherheitslücken schließen, was wirklich nervig war, z.B. für unsere Browserangriffe. Und eine von Joseph hat eine sehr hart daran gearbeitet, hat es geschafft, die Browserangriffe wieder zurückzubringen. Es sollte irgendwie vor 10 Minuten rausgekommen sein und nicht nur das, sondern wir haben auch noch Ironhacks für Spiele, die man einfach runterladen konnte, das wurde auch in Ordnung gebracht. Es gibt aber jetzt auch noch eine Möglichkeit, dass aus dem E-Shop runterladen konnte und wir bringen das jetzt raus. Genau, also das sollte rauskommen, wenn wir fertig sind. Genau, es ist ein kostenloses Spiel, es kommt aus, er laupt im Homebrew und er hat jetzt gerade noch eine Version rausgebracht, die auch gerade rauskommt. Wenn du einen 3DS hast, hol's dir. Wenn ihr einen Freund habt, macht genau selbe, weil das ist wahrscheinlich nicht für immer da. Wir wollen uns bei Yellow's Aid bedanken, der sehr viel Arbeit daran gesteckt hat und Zeit. Ohne ihn wäre das wahrscheinlich nicht möglich gewesen und vielen Dank an den Nintendo Homebrew Channel, vielen Dank an alle, die heute hier waren und wenn ihr irgendwelche Fragen habt, ich glaube nicht, dass wir viele Zeit haben, aber wir versuchen's.