 Hallo, herzlich willkommen im Übersetzungs-Stream für Deutsch. Dies ist der Vortrag, es ist nicht sicher auf den Straßen, vor allem nicht für deinen 3DS. Hier übersetzen in der Übersetzer-Kabine Alpen und Pete Priority. Hallo, herzlich willkommen. Hier werde ich dieses Mal über 3DS-Hacking reden. Wir werden sehen, wie ich das Protokoll angegriffen habe und Kontrolle über das System bekommen habe. Bevor wir jetzt das genau sagen, werde ich jetzt mal kurz zusammenfassen, wie 3DS-Hacking im 2019 so aussieht. Es gibt viele Explosions im Userland, es gibt ein paar Kernelschwachstellen, die gepatched worden sind und es gibt auch viele Dokumentationen. In den letzten Jahren haben die Leute daran gearbeitet und den Key Scrum da koppelt gemacht. Sie haben es geschafft, die Bootrams zu dampen, auszulesen. Das heißt, jetzt können wir alle geheimen IS-Schüssel das System ermitteln. Und wir haben auch einen permanenten und nicht patchbaren Boot-Exploit gebaut. Und jetzt ist die Frage, kann man diese Sachen nutzen, um Sachen zu attackieren, die bisher dadurch beschützt waren. Als erstes reden wir über StreetPass. Dann reden wir erstmal ein bisschen über das Feature selber und dann sehen wir mal uns an, was möglich ist damit. Was ist StreetPass? Das ist ein lokaler, drahtlos Kommunikationsfeature und damit kann automatisch kommunizieren mit den Systemen von anderen Leuten. Die Idee dieses Features war, dass man Daten teilen kann zwischen Anwendungen auf dem System und so weiter. Das ist ein ziemlich interessantes Feature. Das ist die Ansicht des Features. Wir würden gerne einst dieses Thema mit einem Computer ersetzen. Es wäre schön, wenn wir kaputte Nachrichten senden könnten und schauen, ob wir Remote Code Execution auf dem System kriegen können. Aber um das zu machen, müssen wir erst mal herausfinden, wie das StreetPass Feature funktioniert. Es ist relativ einfach, es funktioniert so wie eine Briefkasten. Es gibt da ein Modul, was das alles behandelt im System. All die Anwendungen haben einen Eingang im Datei-System und dort können sie Dateien bekommen aus diesen Boxen, aus diesem Eingang. Aus diesen Boxen macht das Modul Nachrichten, die weiter verschickt werden. Jetzt ist die Frage, was können wir hier angreifen? Was können wir hier machen? Man könnte zum Beispiel die Anwendung selber attackieren. Aber es wäre natürlich noch viel schöner, wenn man den StreetPass selber attackieren könnte. Dafür müssen wir uns anschauen, wie das StreetPass Protokoll funktioniert. Aber das weiß natürlich niemand so richtig. Es gibt ein bisschen Dokumentation dazu, wie Geräte gepaart werden. Also Systemarmächtigen mit mir kommunizieren. Aber das hat man nie geschafft zu reproduzieren. Es benutzt irgendein unbekanntes Verschließungsprotokoll mit dem IS-Key-Schlüssel aus Slot 0x2. Also schauen wir uns erstmal das Pairing an und versuchen es wieder neu zu bilden. Es ist relativ einfach. Wir haben hier beide Clients und die Rolle des Masses der eine ist Client. Jeder randomisiert eine Client-ID und MAC-Adresse. Dann sendet der Client ein paar Anfragen. Inkl. eine Liste von Applikationen, die StreetPass benutzen wollen. Dann sieht irgendwann der Master so einen Request. Dann schaut sich der Master an, ob es irgendeine Applikationen gibt, die matcht. Dann sendet er eine Antwort. Wenn sich beide einig sind, dass sie miteinander kommunizieren wollen, dann tun sie das. Dann schauen wir uns das Pairing an. Das Pairing ist nicht super komisch. Ich habe versucht es ein bisschen nachzubauen, weil es ziemlich hart ist. Man muss nämlich mit komischen Frames umgehen. Dann müssen wir hier ein paar Callbacks registrieren, um zu schauen, wie sie sind verantworten zu können. Dann sendet der 3DS verschlüsselte Daten. Das passiert in zwei Durchgängen. Wir benutzen einen HMAC-SH1-Alkorithmus über die MAC-Adressen und die Console-ID. Dieser Durchgang ist als Input-Counter für ein AS-CTR 128, das den AS-Key-Slot benutzt. Das können wir bekommen. Der Ausgang dieser Verschlüsselung ist dann der Session-Key für die Kommunikation. Mit NL802.11 kann man diese CCMP-Schlüssel registrieren. Das ist nicht schwierig, dann zu senden und zu empfangen, diese Schlüsselpakete zu empfangen, über RawSockets. Jetzt können wir das Protokoll auseinandernehmen. Schauen wir uns einmal die Struktur der Pakete an, bevor wir etwas RawS-Engineering betreiben. Ich habe jetzt ein paar Pakete hier dargestellt, die ich empfangen konnte. Als erstes kommt ein Header und dann kommen die Daten. Man sieht hier ein paar Magic-Bits, die immer drin sind. Das ist relativ einfach, denn CCD benutzt erkennbare Magic-Vis. Das ist einfach immer, dass der Bebyte wiederholt und sobald man die Struktur der Pakete weiß, dann sieht man, dass es tatsächlich zwei Protokolle sind. Das erste ist der Street-Pass-Transmission-Control-Protokoll. Es ist sehr ähnlich zu TCP, aber nur für lokale Kommunikation. Es ist sehr stabil und macht auch Datensegmentation. Das zweite ist Street-Raten-Message-Transfer-Protokoll. Das sendet die Pakete über das erste Protokoll und macht auch das Austausch in diese Nachrichten möglich über Street-Pass. Man muss jetzt die beiden anschauen. Wir fangen jetzt mal mit dem ersten an, SPTCP. Es gibt nicht viel darüber zu sagen. Man muss dann den Header verstehen und analysieren. Die ersten zwei Bytes sind die Magic, dann kommen ein paar Konstanten. Das ist tatsächlich einfach nur ein Dead Beef. Dann kommen die Flags. Man soll verstehen, was die Flags sind. Dann würde man verstehen, was die Bedeutung der Pakete sind, die man sendet und empfängt. Damit kann man das Protokoll verstehen. In diesem Fall sind die Flags wie TCP. Das heißt, es war sehr einfach zu verstehen, wie dieses Protokoll funktioniert. Was ist mit SPTCP-Sicherheit? Das scheint ganz okay zu sein. Ich habe keine kritischen Bugs gefunden. Aber die Angriffsfläche ist auch nicht so groß. Das heißt, SPMTP ist viel interessanter. Schauen wir uns nun also die Struktur des Nachrichtenprotokolls an. Da gibt es tatsächlich zwei verschiedene Paket-Tippen. Das erste ist ein Infopaket. Das ist im Prinzip einfach nur der Handshake. Das ist einfach nur da, um Informationen zwischen den beiden Piers auszutauschen. Dann kommen die Messagebox-Pakete. Die Nachrichtenpakete enthalten die Daten über die StreetPass-Programme. Das gibt auch die CECD Message for a magic value. Das heißt, hier fängt dann die tatsächlichen Anwendungsdaten an. Sobald man das ausgefunden hat, kann man das Protokoll reproduzieren. Schauen wir uns erst mal die Infopakete an. Hier werden ein Menge an Daten übertaten. Viel, viel Daten mit fester Größe. Nichts bis dann auf der Freundcode, die Merk-Adresse, Datum und Zeit. Das gibt auch Daten mit variablen Größen. Also Applikate, wie viele Anwendungen das gibt, was für Anwendungen es gibt. Die Metadaten der Messagebox und noch viel mehr. Man kann sich überlegen, ob man hier vielleicht ein Buffer-Overflow finden könnte, um Remote-Code-Execution zu bekommen. Jetzt schauen wir uns mal die Boxmetadaten-Parsing an. Diese Funktion parse die Metadaten. Das ist einfach nur ein Followup. Und sie kopieren hier eine Liste von Einträgen auf den Stack. Und sie prüfen nicht die Nummer der Einträge in der Liste. Das ist definitiv ein Buffer-Overflow, aber kann man den auch ausnutzen. Schauen wir uns mal ein Diagramm dazu an. Das ist ein Kopiervorgang. Er hat ein Paketbuffer. Und Memcopy wird jetzt auf jeden Eintrag angewandt. Und alles ist okay. Aber wenn man jetzt mehr Einträge hätte, dann könnten die Einträge auf dem Stack ein paar Sachen überschreiben. Aber es gibt ein Problem. Es gibt ein Problem, weil der Paketbuffer nicht groß genug ist, um erstens die Return-Adresse zu lesen auf dem Stack. Das heißt, wir kopieren halt unkontrolliert Daten. Und das ist ja einfach zu schade. Wir können damit nichts machen. Aber schauen wir uns mal. Aber tatsächlich, wenn wir diese Buffer neben dem Paddingbuffer auf eine Liste geschrieben, die vorher empfangen wurde, das heißt, wir können die Return-Adresse überschreiben. Wir nutzen das jetzt aus. Auf der 3DS gibt es das NX-Bit, aber es gibt keine Stack-Cockeys, aber auch keinen ASLR. Das heißt, es ist sehr direkt, wie man das jetzt macht. Man kann einfach eine ROP-Kette in die Liste legen und einfach eine andere in einem Paket senden und dann den Stack auf diese 2. Kette umleiten. Damit hätten wir Remote-Code-Execution in CECD. Das war ziemlich einfach. Gehen wir weiter zu Messagebox-Paketen. Messagebox-Pakete sind Pakete, die eine Liste von StreetPass-Nachrichten schickt. Es gibt hier, die werden tatsächlich in temporären Dateien gespeichert und die werden dann gepasst, sobald die Kommunikation vorbei ist. Also sie werden gepasst. Schauen wir uns ein paar Seile mal an. Das ist die Funktion, die jetzt diese temporäre Detail lädt. Auch in ein Stack-List, in eine Struktur. Und hier überprüfen sie auch weder nicht die Anzahl der Nachrichten in der Box. Das ist also auch ein neuer, ein anderer Bufferoverflow. Das heißt, wir überfühlen quasi den Array, der Message anzahlen. Schauen wir uns auch hier mal einen Dialgramm an. Auf der rechten Seite gibt es die temporäre Detail und auf der linken Seite ist der Stack. Und wir sehen hier, dass es die Strukturen auf dem Stack gibt. Hier sind die Message-Pointers mit den Pointers, die auf den temporären Dateien Buffer zeigen. Und wir haben Message-Größen. Und wenn wir jetzt eine neue Message-Inzug, dann kriegt man Overflow auf beiden Arrays und man überschreibt eben gewisse Daten auf dem Stack. Sondern ein bisschen beunruhigt, weil wir auch wieder teilweise unkontrolliert Daten auf den Stack schreiben. Man kann die Message-Pointer nicht wirklich kontrollieren. Und man kann auch die Message-Größen nicht wirklich kontrollieren. Man müsste hier Gigabyte an Nachrichten schicken und das können wir dann nicht machen. Aber was können wir tun? Was wir sehen können hier ist, dass man die größte der letzten Datei auf eine beliebige Größe setzen kann. Sie schauen in der Queue, ob die letzte Nachricht, die gepasst wird, tatsächlich in dem Buffer drin ist. Und dann gehen Sie raus, ohne überhaupt einen Return zu machen. Was wir da so machen können, ist, die letzte Nachricht auf eine beliebige Wert zu setzen und dann würde der Pointe auf den Buffer rausgehen und wir könnten eine 32-Bit Value auf den Stack schreiben. Aber wir müssen wissen, was wir schreiben können, was wir schreiben sollen. Leider kann man nicht direkt die Return-Adresse überschreiben, weil wir hauptsächlich unkontrolliert Daten schreiben. Und um an die Return-Adresse zu kommen, müssten wir den kompletten Stack-Frame mit unkontrollierten Daten überschreiben. Oder zumindest teilweise mit unkontrollierten Daten überschreiben. Das Einzige, was ich hier beschreiben konnte, ohne das System ausstoßen zu lassen ist, ist dieser spezielle Variable. Das ist ein Pointer auf eine Critical Section und das ist benutzt, um Synchronisationen zu machen. Und wir können sehen, dass es benutzt wird, nachdem die Datei gepasst wird. Vielleicht können wir damit etwas machen. Das ist der Leaf Critical Section Call. Man sieht hier, dass der Pointer benutzt wird, um so einen Counter zu dekumentieren. Das ist sozusagen den Anzahl der Threats, die diese Critical Section benutzen. Wir können diesen Pointer überschreiben. Indem wir ihn überschreiben, können wir eine beliebige Wert im Speicher überschreiben. Aber dazu müssten wir erst einen Bereich finden, den wir da sinnvoll überschreiben können, um Remote Cued Execution zu erreichen. Und ich habe hier ein bisschen umgeschaut. Und ich habe gesehen, dass das Interessant ist gesehen, in der Funktion, die die Struktur initialisiert, für diese Tempore in Dateien. Das ist die Funktion zur Struktur Initialisierung. Man kann hier sehen diese Variable. Sie haben eine Art von Allocation-Modus implementiert. Und wenn das der Pointer-Modus ist, dann wird er den Pointer nicht befreien, nicht freien. Dann speichert er nicht freigeben. Aber wenn das nicht im Pointer-Modus ist, dann werden sie alle freigeben. Also dass wir den Speicher freigeben. Aber wir können das dekumentieren, indem wir diesen Modus dekumentieren mit der vorigen Funktion. Also wir können uns ein paar Pointer befreien. Und die Daten, die in Message-Pointas drin stehen, schreiben. Und wir können und damit benutzen, um ein paar Chancs zu befreien. Aber wir haben noch ein Problem. Weil wir das jetzt jedes Mal machen, wenn die Temp-Box gepasst wird. Was wir hier tun könnten, ist, die Funktion früh Return zu lassen. Aber dann kriegen wir leider ein Fehler Return Code zurück. Aber das ist tatsächlich kein Problem, weil der Return Code nicht überprüft wird. Also was können wir bisher tun? Wir können eine erste Temp-Box senden. Damit überschreiben wir den Lock und verringern den Allocations-Modus. Dann senden wir eine zweite Box mit einem falschen Header. Dann wird der Pasa früh Return und der Message-Pointer wird nicht geupdatet. Und dann werden alle Pointer im Erreg Freed freigegeben. Aber die Pointer sind dort nicht neu geschrieben worden. Die poinden immer noch in den ersten Schunk von dem ersten Buffer. Das heißt, weil das neu adoptiert wird für unseren zweiten Buffer, das heißt, wir können das benutzen, um einen eigenen Buffer zu frieren. Damit können wir jetzt ein paar falsche Hiebchancen spawnen. Was können wir damit machen? Der 3DS-Hieb ist ziemlich unsicher. Das heißt, wir können damit einen beliebigen Schreibvorgang machen und für jeden Schunk den wir freigegeben. Wir können den ersten Pointer umschreiben. Dann können wir zum Beispiel einen Pointer auf den Stack hinpacken, sodass das nächste Malock einen Pointer zum Stack return wird. Das wird dann benutzt, um die dritte temporäre Datei zu speichern. Das ist vielleicht ein bisschen schwer zu verstehen. Das heißt, hier nochmal eine Illustration, diesbezüglich. Hier ist erstmal unser 1. temporäre Datei im Speicher rechts. Es wird gepasst. Dann wird es auf den Stack geschrieben. Dann wird der Lock-Pointer umgebogen auf den Allocations-Modus. Dann wird Leaf Critical Section aufgerufen. Dann wird der temporäre Buffer gefreet, freigegeben. Und der Allocations-Modus wird dokumentiert. Dann kommt die zweite Datei im Speicher. Dann wird die Buffer des ersten realloziert. Und die Pointer zeigen jetzt unseren Fake-Jungs. Dann wird unser 2. Datei geladen und gepasst. Und dann werden all die Nachrichten gefreet. Und dann wird das dritte temporäre Datei gelesen auf dem Stack. Und dann können wir damit ein Rockchain bauen. Die zweite Remote Code Executioner drin, das war ein bisschen schwieriger. Was das als nächstes ist. Und noch einer. Wieder? Es gibt noch eine Verwundbarkeit im Nachrichtenpasa. Es ist tatsächlich eine SDK Funktion. Das heißt, jede Anwendung die StreetPass benutzt ist verwundbar. Aber diesmal werde ich nicht über alles reden. Das ist jetzt für euch übrig geblieben, um das zu exploiten. Das ist noch eine dritte Remote Code Execution in CECD. Und das funktioniert in jeder Anwendung die StreetPass verwendet. Das gibt uns auch einen dauerhaften CECD-Backdoor. Weil CECD das beim Start immer passt. Und das heißt man kriegt Remote Code Execution soweit das System bootet. Jetzt haben wir Remote Code Execution CECD. Was können wir jetzt damit tun? CECD hat leider nicht viele Privilegien. Es ist ziemlich gut gesandboxt. Wir können nicht das auf das Internet zugreifen oder auf die SD-Karte. Wenn wir mehr Privilegien haben wollen, mehr Rechte haben wollen, dann müssen wir noch irgendwas anderes übernehmen. Und die beste Wahl dafür wäre, den ARM11 und den ARM11-Körnel zu übernehmen. Damit hätte man die totale Kontrolle über diesen Prozessor. Wenn man wirklich komplette Kontrolle über das System haben möchte, dann müsste man auch den ARM9-Prozessor übernehmen. Das ist der Sicherheitsprozessor, wo all die Verschlüsselung drin passiert. Und wir werden später sehen, wie man das macht. Machen wir als erstes den ARM11-Körnel. Reden wir erstmal über IPC Inter-Prozess-Kommunikation. Dort gibt es statische Buffer. Wie macht man IPC? Wir senden ein paar Daten von einem Prozess zum anderen. Mit dem 3DS kann man das auf verschiedene Arten und Weisen tun. Die erste davon ist, wenn man einen großen Buffer senden möchte, dann map man einfach ein paar Teile seines Speichers in den Speichern des Empfängers. Wenn man kleine Bufferbluss senden möchte, kann man auch ein paar statische Buffer registrieren als Empfänger. Der ARM11-Körnel wird dann die Kopien anlegen. Und manchmal gibt es Buffer, die man zum ARM9 senden möchte. Da macht der ARM11-Körnel ein paar Paare von physischer Adresse und Größe in den ARM9-Prozess darüber zu bringen. Das ist ohne MMU der ARM9-Prozess, deswegen physische Adressen. Und die Kopie wird dann von dem ARM9-Prozess gemacht. Lass uns mal ein bisschen über die Verwundbarkeit reden. Diese Verwundbarkeit wurde von Tux-SA gefunden, also nicht von mir. Und jetzt ist die Frage, wie behandelt der Körnel die PXE Buffer? Als erstes schauen sich das Alignment des Zielbuffers an. Dann die Größe und die Rechte. Und am Schluss kopiert es die Sprecher. Aber was hier passiert ist, hier fehlen die Permission Checks, die Rechte Checks für den Zielbuffer. Das heißt, das Ziel kann eine beliebige physische Adresse sein. Das heißt, wir können einfach die MMU-Tabelle überschreiben und den Körnel read write executable machen. An diesem Punkt haben wir dann den ARM11-Körnel übernommen. Aber wir würden gerne noch mehr Rechte haben, weil warum nicht? Wir würden gerne das komplette System kontrollieren. Also, Lass uns auf den Weg machen für das ganze System. Und auch genannt, warum das CCD zu übernehmen die beste Idee schon immer war. Jetzt reden wir mal über Safehacks. Das ist eine Race Condition in der Firmware, wie sie die Head Up haust. Da kann man den ARM9 übernehmen, wenn man den ARM11-Körnel kontrolliert. Das wurde in 950 gefixt für die native Firmware. Aber in der Safe Mode Firmware ist es nicht gefixt, in die man bootet, wenn was schief gegangen ist. Das wurde erst in 11.3 und 11.4 behoben. Es funktioniert nicht mehr, aber es wurde bloß umgangen, nicht tatsächlich gepatched. Also schauen wir uns das mal genauer an. Diese Umgehen, dieser Verwundbarkeit aus. Wir haben einen Flag hinzugefügt auf ARM9. Wenn es auf 1 gesetzt ist, dann panikt der Kernel, wenn der Safe Mode gestartet wird. Dieses Flag wird auf 1 gesetzt, wenn Anwendungen gestartet werden. So wurde es nämlich üblicherweise ausgenommen. Wenn man über die Anwendungen gestartet, über den Anwendungsstaatsrechte bekommt, dann Safe Mode startet. Für manche Anwendungen gilt das nicht, nämlich für das Home-Menü und auch für ein paar System-Module. Und CCD ist ein System-Modul. Das heißt, wir kriegen Remote-Code-Execution ohne eine Anwendung zu starten. Das heißt, das Bullion Flag wird nicht auf 1 gesetzt. Das heißt, wir können selbst Safe Hacks anwenden vom ARM11 Kernel. Am Ende kriegen wir also einen kompletten Remote-Code-Execution ohne User-Interaktion. Das passiert alles im Hintergrund auf jeder Firma-Version. Zu der Zeit, wo das entwickelt worden ist, Nintendo hat es gepasht mit 11.12. Ich denke, es ist jetzt Zeit für eine kleine Demo. Ich mache das jetzt hier nicht live, weil ich den Exploit nicht in die Luft schicken möchte. Also habe ich hier ein kleines Video. Hier ist der Exploit auf meinem Laptop. Die LED leuchtet, um zu zeigen, dass der Exploit läuft. Und jetzt haben wir hier zum Beispiel den Putrom Exploit-Installer gelanscht. Ja, vielen Dank. Jetzt ein paar Sachen, die wir da raus mitnehmen können. Man sollte immer die Return-Values von Aufrufungen überprüfen. Das hätte vermieden werden können. Oder wäre es zumindest sehr schwer geworden ohne diesen Fehler. Man sollte sich nicht hinter Krypto verstecken. An des Tages wird die Verschlüsselung gebrochen werden. Das kommt vielleicht eher früher, als man denkt. Für diesen Fall gab es ein paar dumme Fehler. Das ist einfach nur Buffer Overflows. Es ist schwer zu erreichen. Es ist schwierig, aber es kann zu sehr interessanten Ergebnissen führen. Aber am Ende kriegt man sehr viele interessante Ergebnisse. Dann würde ich sagen, fixst eure Flows und macht richtige Patches. Und nicht einfach so eine Mitication, wie für Safehacks. Es gibt noch viel mehr zu tun auf dem 3DS. Es ist ein sehr interessantes System, darauf zu arbeiten. Es gibt sehr viel zu machen auf dem Open Source Wiki. Das heißt, macht ihr gerne mit. Am Schluss möchte ich ein paar Leuten danken zum Chuxus Age für Lazy Pixie. Er hat mir auch geholfen, diese ganze Kette, das Exploits hinzubekommen. Und auch Hedgehog für seine Unterstützung mit vielen Sachen. Wenn ihr jetzt ein paar Fragen habt, dann bitte. Wir haben noch relativ viel Zeit, also frag bitte. Ich stelle euch bitte ans Mikrofon und los. Keine Fragen? Das Internet hat ein paar Fragen. Wir haben zwei Fragen. Die erste, was für Werkzeuge und Umgebung benutzt du für deine Forschung? Wie kommst du an den ganzen Quellcode ran? Alles auf dem 3DS ist Klosters. Das heißt, man muss alles reverseingenieren. Ich habe EIDA und Gitter benutzt, um die Bannerist Reversen von CCD. Und das ist eigentlich alles. Die zweite Frage. Gibt es eine Prozedur für die Switch, dass das kompatibel mit dem ist, was du hier für die 3DS getan hast? Könnten Sie die Frage wiederholen? Alles, was du getan hast, ist ähnlich auf der Switch. Ich glaube, so etwas ähnliches gibt es auf der Switch nicht. Jedenfalls gibt es nicht so etwas wie Street Pass. Ich weiß nicht, wie die Switch funktioniert. Ich habe bisher bloß Dinge auf dem 3DS gemacht. Das ist die erste Frage aus dem Raum. Vielen Dank für den Vortrag. Hast du wirklich alle drei Exploits gebraucht? Und welches hast du im Ende für die volle Kette benutzt? Hast du wirklich alle drei Exploits benutzt? Oder hast du am Ende nur einen benutzt? Und welche hast du am Ende benutzt? Nein, man hat nicht alle drei Exploits gebraucht. Jedenfalls nicht 40 CD. Man hat bloß einen gebraucht, um die Remote Code Execution zu bekommen. Aber ich habe es spaßig gefunden, einfach noch mehr Exploits zu zeigen. Nächste Frage. Wir haben diese Nachrichten auch an die Anwendung weitergegeben, selbst wenn sie nicht laufen. Es wird ein bisschen lauter sprechen. Also passen die Anwendungen selbst die Messages, wenn sie nicht laufen. Also selbst wenn diese Anwendung nicht läuft, aber nur installiert ist. Also wenn du eine Anwendung mit einem alten SDK hast, so dass dann auch die Gruppen Messages passen. Das war eine Reformulierung der Frage. Das hast du erwähnt, die dritte Methode erwähnt, dass die SDK kaputt ist. Wenn man es in der Anwendung hat, mit diesem alten SDK gebaut hat, wird es dann automatisch die Nachricht passen, selbst wenn es nicht läuft. Selbst wenn man die Betriebssysteme gepatched ist, aber die Anwendung nicht, kann man dann diesen Exploit noch benutzen. Alle Anwendungen, die die alte SDK benutzen, sollten geupdatet werden, die neue SDK zu benutzen. Der Exploit ist trivial, wenn die Anwendung die Nachrichten passt. CCD wurde gepatched. Das heißt, es gibt keine Remote Coach Execution in CCD mehr. Kein Backdoor mehr. Aber man kann wahrscheinlich Anwendungen, Spiele, Exploiten, die die alte SDK benutzen. Könnten Sie noch mal zu einem Slide zurückgehen, wo die Verschlüsselung vorgestellt wird über der Pakete? Genau das hier. Meine Frage ist jetzt, das Einzige hier, dass was man ändert, ist ein Kalender und die Daten. Und die Key immer konstant ist, wenn das CTR ist. Dann macht man einfach nur einen XOR von einem bekannten Blog mit einem Edge-Mark-Ausput. Warum brauchst du überhaupt ein Key hier? Der Ziller ändert sich jedes Mal, wenn man das StreetPass-Kommunikation bestattet. Die Client-IDs werden randomisiert und die Mac-Adressen werden auch randomisiert, bevor man eine neue Kommunikation startet. Warum braucht man diese Seite? Wenn man ein CEC Edge-Mark-Key hat, das sei genug. Wenn man dann einfach nur den Ausgang davon mit dem endgültigen Ausput zu XOR, dann bräuchte man diesen CTR-Part überhaupt nicht. Dann hat man dann einen rohnen Ausput von dem ersten Blog mit dem Key-Slot-TOE, was immer konstant sein wird. Das heißt, man kann einfach ein XOR draufmachen und das endgültige Ergebnis zu bekommen. Ich bin jetzt nicht so... Mir sind jetzt all die kraftografischen Primitiven nicht so super bekannt. Ich kann jetzt das nicht sagen. Ich habe jetzt das hier bloß hingetan, um damit Leute es nachbauen können. Gibt es noch weiter Fragen? Nein, vielen Dank. Damit verabschieden...