 Unser vortragender Quartier ist Teil des Projektes Checkbrain. Sie schauen sich Jailbrains von iOS-Geräten an, von iPhones. Und iPhone haben eine reduzierte Funktionalität. Und sie können nicht geroutet werden, also Administrationsrechte darauf zu bekommen. Aber technische Benutzer versuchen, ab und zu Route-Grechte zu bekommen. Und es gibt da Ratze- und Maus-Spiel zwischen Leuten, die die Route-Grechte bekommen und das Apple sie wiederzumacht. Dieser Jailbrake ist ein spezifisches, ganz besonders, weil er nicht fixbar ist. Quartier wird uns vorstellen, seine Arbeit vorstellen und auch das Problem erklären, und was sie darüber herausgefunden haben. Also, großen Applaus für Quartier. Danke. Also, heute rede ich über den einfachen Trick, den Secure-Raum hast. Dieser Vortrag wurde schon POC gehalten vor Checkbrain. Wir waren ein bisschen zu spät hinter der Deadline. Man hat ein bisschen länger gedauert, aber ist jetzt verfügbar und Checkbrain.in. Ich bin Luca, Todesco und Quartier. Also, auch bekannt ist Quartier. Ihr könnt mich im IRC.cragspy.com finden. Im Hashtag Ted-Kanal auf Twitter findet ihr mich unter meinem Händel, der jetzt hier zu sehen ist. Ich bin ein unabhängiger Sicherheitsforscher, insbesondere im Bereich IOS. Und mein Hintergrund ist, dass ich IOS-Hecke in der amerikanischen Hacking-Szene seit ich iPhones entdeckt habe. Aber heute bin ich hier für mehr, also bin ich nur für mich hier. Sondern der Vortrag wäre nicht möglich, ohne die Arbeit, die viele Leute dahin gesteckt haben. Ich werde Axiomax die Personen, die die Sicherheitslücke veröffentlicht haben, die wir hier benutzen. Und Laila, die es auch gefunden hat und Checkerain. Und auch dem ganzen Checkerain-Team, das für Monate daran gearbeitet hat, um die Infrastruktur richtig fertig zu bekommen, dass wir eine so starke Vulnerability in ein einfach benutzbarer und zuverlässigen Jailbreak für jeden zu verwandeln. Und das Checkerain-Team ist eine Gruppe von IOS-Forscher. Das sind mehr als nur die, aber das sind die großen Leute, die da beitragen. Und das Wissens-Team, das Wissensmenge dafür ist groß. Es ist möglich, dass das beste Team, mit dem ich jemals zusammengearbeitet habe in meinem ganzen Leben. Und ich glaube, es ist sehr wichtig, sich hier aufzunennen. Und vielen Dank, dass wir zusammengearbeitet haben. Ein tolles Ergebnis. Ja, auch viel Arbeit gewesen. Also, was ist Securon? Securon ist der erste Code, der ausgeführt wird, in das iPhone gestartet wird. Und es ist eine vereinfachte Version von IOS-Bootloader. Und dieser Code ist sehr wichtig, weil er in den Arbeiten in den ROM Read Only Memory geschrieben wird. Und das ist das vertrautste Code, der jemals auf dem Anwendungsprozess auf dem Phone laufen wird. Das Ziel von Securon ist es, ein Image vom Flash-Speicher zu laden. Für den kompletten Bootloader-Eilboot in den Arbeitsspeicherladen, um da reinzuspringen. Es ist relativ einfach, aber es macht viel Signaturen, es überprüft Signaturen und alles. Es beinhaltet auch Sicherheit-Recover-Methodiken, die es ermöglicht, Phones von einem unbootbaren Status zu bekommen. Und diesen Modus kommt man natürlich erst mal in eine spezielle Tastenkombination drückt, während das Handy sich gerade bootet. Und ich werde jetzt auch kurz sagen, dass Securboot, also ich werde Securboot regelmäßig erwähnen, hier in unserem Vortrag. Und IOS war eines der Pioniere der Sicherheits- und Bootfunktionalitäten, die das Ziel unsignierten Codes zu laden, das ist etwas, wo wir bei IOS die ganze Zeit schon hinterher sind. Und das beginnt mit Securboot. Immer wenn etwas geladen wird, wird es sicher, wird es überprüft. Das ist seit dem ersten iPhone so. Ja, das ist der Gegner von Jailbreaking Nummer 1. Und Jailbreaks wollten hier dran vorbeikommen oder wollten weiterkommen. DFU-Protokoll ist ein relativ einfaches Protokoll, das USB implementiert. Das Ziel ist es, einem Gerät zu ermöglichen Daten vom Haus zu bekommen. Und da das eine vereinfachte Version vom Bootloader ist, soll das sehr einfach sein. Und Grundlegend ist eine spezielle Anfrage, die man das Gerät schicken kann, mit ein paar bisschen Daten, die hinten dran gehängt werden. Sobald der Übertragung fertig ist, kann man eine Sequenz von anderen Befehlen schicken, die dem Gerät sagen, dass es diesen Image sputen soll. Es gibt aber auch andere Wege, DFU-Modus zu verlassen. Ein spezieller Request zum Beispiel, DFU-Abrechen, den USB-Stick ausschaltet und den neu initialisiert. Wie ich gesagt habe, ist das über USB implementiert. Und ich sage euch jetzt, was dieser Control Transfer ist. Es wird quasi genutzt, um ein paar Kommandos vom Host auf das Gerät zu senden. Man kann ein bisschen Daten mit senden, mit der Anfrage. Es gibt ein paar von diesen Control Transfers, die jedes Gerät haben muss, laut USB-Standard. Und es startet mit einem Setup-Paket, wo drinnen zum Beispiel ein Request-Type drinnen ist. Dann ein B-Request-Feld, was für eine Art von Requestes sein soll. Und ein paar andere Felder. Aber für uns ist das interessanter hier W-Länge. Falls W-Länge nicht null ist, dann kommt nach dem Setup-Paket eine Datenphase. Hier wird der Host dann Daten an das Gerät senden. Und wie ich gesagt habe, das ist der Weg mit dem der Host über DFU, dem Gerät Datensendet. Wenn die Richtung auf In-Gesetz ist, dann kriegt der Host stattdessen Daten vom Gerät, aber das hängt vom Request-Type halt ab. In der Datenphase werden die Daten aufgeteilt in Chancs zwischen 8 und 64 bytes. Und es kommt dann auf die USB-Geschwindigkeit an und es werden 6 Zell gesendet. Nachdem der Transfer fertig ist, gibt es eine Statusphase, das markiert das Ende vom Control Transfer und das ist dann ein Paket von Länge 0. In iBoot, in dem USB-Stack, drinnen gibt es einen temporären Buffer für diese Daten und die Daten werden da immer reingerem beim Copied, sobald sie empfangen werden. USB und DFU arbeiten nebeneinander. Sobald man DFU in DFU reingeht, wird USB angeschaltet und dann wird dieser temporäre Buffer allokated. Sobald das passiert, gibt es einen Punkte auf diesen Buffer in einer globalen Variable und der USB-Stack wird dann halt die Daten reinschreiben. Aber wenn man DFU wieder ausschaltet, dann wird der USB-Stack den Buffer wieder freigegeben. Wenn wir diesen Buffer jetzt freigegeben, dann wird die globale Variable, wo die Daten hingeschrieben werden, nicht wieder auf 0 gesetzt. Das ist dann möglicherweise eine Use-After-Free-Verwundbarkeit. So, jetzt die Schritte, wie man dahin kommt. Erst macht man einen USB-Control-Request mit einer Datenphase und während dieser Datenphase unterbrechen wir den Transfer. Dann machen wir einen neuen USB-Request mit einem DFU-Abruch, dann wird der USB-Stack wieder ausgeschaltet und der Buffer wird gefreet und dann versucht es die Daten zu laden, aber es gab keine legitimen Daten hier. Das heißt, das Image wird nicht geladen und DFU wird wieder in DFU reingegangen. Und dann versucht DFU weiter da Daten reinzuschieben, aber der Pointer ist jetzt ein wilder Pointer, da ist es schon freigegeben worden. Das heißt, die Daten werden neu benutzt von dem letzten Set-Up-Paket, was wir gesetzt haben in der früheren DFU-Phase. Sobald das passiert, werden die Daten weiter auf diesen Pointer geschrieben. Um das jetzt hinzubekommen, brauchen wir sehr große Kontrolle über den USB-Stack. Dafür haben wir einen Host-Shield genutzt und aus dem haben wir den USB-Stack in MacOS dazu gebracht, von der Spezifikation abzuweichen. Der zweite Versuch war nicht deterministisch. Viele USB-Stacks werden dir sagen, wie viele Daten weitergegeben worden sind und so kriegt man mit, ob der Transfer fertig geworden ist oder nicht. Es ist nicht 100% sich zuverlässig, leider. Das ist das Bild vom ursprünglichen Set-Up, aber es gibt hier ein Problem. Wenn wir jetzt diese Schritte folgen, dann wird es nicht funktionieren, außer auf zwei bestimmten Geräten. Das passiert so, weil es dort noch ein DFU-Abbruchfunktion, dass es dort in der DFU-Abbruchfunktion ein Back gibt. Dort gibt es einen eigenen Task, welcher sich um den USB-Stack kümmert und dort wird die Taskstruktur immer gelegt auf dem Hip, jedenfalls, wenn ein DFU-Abort passiert. Sobald man von einem anderen Task da reinkommt, oder es einen Tag zurückgeht, werden die Register in dieser Struktur gespeichert werden. Wenn wir diesen Task neu starten, werden diese Register wieder aus dem Speicher geschrieben. Dieses Use After Free würde in Theories ermöglichen, direkt in diese Register zu schreiben, aber das ist nicht der Fall, weil die Rights passieren in der Taskstruktur des aktuell funktionierenden Tasks. Und man kann die Register nicht überschreiben, weil die sind in den Hardware-Registern zu diesem Zeitpunkt. Und wenn man abgibt, dann werden sie zurückgeschrieben in die kaputte Struktur. Das heißt, die Korruption wird überschrieben und gelöscht. Aber Tasks haben auch eine interne Linked-Liste, von der den Nächsten zu ausgeführten Tasken ausgewählt wird. Und man kann eine falsche Taskstruktur erstellen im Arbeitsspeichern mit dem Freeride-Krimitive die Linkliste korribieren. Dass das nächste Mal, wenn das USB-Task zurückgeht, einen Scheduler wird als in Branche, die von uns kontrollierten Pointer gehen. Und darüber können wir Code ausführen, weil der Heap auf Secure-Rom lesbar schreibbar und ausführbar ist. 32-Bit-Roms können diese Strategie nicht benutzen, genauso wie A7, A10, A10x, A11 und A11x. Die können diese Strategie nicht benutzen. Es gibt keine Struktur. Das Struktur liegt dabei vor. Es bricht nicht ab, weil es alles Deterministisch genug ist, dass wenn DFU verlassen wird und DFU wiedergestartet wird, ist alles wieder gleich. Und der Buffer wird wieder an die Selbststelle reallokiert. Wir müssen eine Art und Weise finden, um aus dieser Debatte Terminismus ausbrechen können, um wirklich ein Use-after-Free-Szenario zu bekommen, wo etwas schreiben, was nicht einfach nur so liebe Daten sein soll. Und AXIOMAX hat die Secure-Rom-Implementation angeschaut und hat festgestellt, dass der Heap mehr oder weniger ganz fun ist. Wir können diese Möglichkeit nehmen, um Heap von Ski zu benutzen. Wir brauchen eine kontrollierte Allokationsprimitive oder Mechanismus. Und wenn wir einen USB-Transfer senden, dann ist da eine zugehörige Struktur, die im Heap gespeichert wird. Und wir können mehrere USB-Transfere gleichzeitig haben, in diesem Fall Transfer von dem Gerät zum Haus, die zur gleichen Zeit laufen. Zum Beispiel, wenn ihr Daten vom Gerät antwortet, dann wird das Gerät die Daten nicht sofort beantworten, wenn der Haus nicht bestätigt, dass die Daten angekommen sind. Und immer, wenn man in so einer Situation ein Setterpaket sendet, wo kein Knacking ist, dann bleibt es einfach eine Weile hängen. Und das gibt uns die Möglichkeit, Melok aufzurufen und das Free zu verzögern, bis es aufgegeben ist oder bis die Storage-Kondition den Deadlock aufbeendet ist. Und bis es dann heruntergefahren wird. Und wir müssen halt den ganzen USBs der runterbrechenden, aufbauen. Und um das zu machen, muss ein Back-in-the-State-Maschine, statt das Maschine von dem Gerät, benutzt werden. Es hat spezifische Funktionen, die nie freigemeldet werden. Also diese Funktionen basieren auf Paketen, die eine Länge von 0 haben. Wenn wir Daten von unserem Gerät und den Host kopiert haben, dann wird die Struktur ein leeres Paket senden, wenn das der Request fertig ist oder der USB-Stack heruntergefahren werden soll. Das Problem ist, dass wenn wir den USB-Stack wirklich ausschalten oder herunterbauen, dann wird das Paket weggesendet werden, das leere Paket gesendet werden, aber es wird nirgendwo ankommen, weil es später mit 0 überschrieben werden wird. Und dieses Leak kann abhängig gegründet werden, weil leere Pakete nur gesendet werden, gewisse Konditionen gesendet werden. Zum Beispiel Requests, die nicht mehr als 64 bytes sind, kriegen Ringen ein Paket mit der Länge von 0 und sein DevOps-Paket. Wir können dieses Missbrauchen um einen speziellen State vom Heap erstellen, damit wir einen Loch haben wollen. Genau der Größe, das Melok den iBuffer wahrscheinlich dorthin schreibt. Und jedes USB-Request-Struktur wird auch einen Pointer haben zu unserer Rücksprung-Adresse, die aufgerufen wird, wenn die Struktur freigemacht wird. Wir können ein paar reallokieren, anstelle von unseres alten Buffers, und wenn wir unseren UseAfterFree-Schreib-Vorgriff machen, können wir diesen Funktionspointer definieren und den richtigen Branch gehen, wenn wir das nächste Mal DFU auf DFU zugreifen. Dies kann bald A9X, A10, A10X und A11 benutzt werden, die Prozessortypen. Bei älteren Geräten wie zum Beispiel A7 ist diese Technik nicht benutzbar, weil jede einzelne Transfer dieser Daten liegt. Aber wir können mehrfach Daten aufinitialisieren, bis es fast voll ist, bis auf den Wert, die Größe, die wir für das nächste Mal brauchen. Das heißt, wir haben eine spezifische Größe, am Ende des Heaps, und Melok würde den Platz benutzen. Das heißt, wir können einen ganzen Checkmate herbeifügen führen. Aber bisher können wir nur Code ausführen. Was wir wirklich haben wollen, ist ein Bootkit, dass wir normal weiter booten, anstelle von einfach nur im sicheren Raum und DFU-Modus bleiben, um das Gerät zu jailbreaken. Und wie können wir so ein Bootkit entwickeln? Wir haben Code, können Code ausführen, und wir können die Hauptfunktion von Securaum wieder in den Sprang springen und dann wird über Flash gestartet. Und eventuell wird der Bootloader in den Kernel booten, und sobald das passiert, wird es versuchen, in den Einstiegspunkt zu branchen. Das heißt, unser Ziel ist es, den Kernel so zu patchen, in dem Moment, wo der Kernel im Arbeitsspeichel liegt, nachdem es validiert wurde. Und es ist immer noch voll lesenschreibbar, und wenn die Leute wissen, dass der Kernel später nicht mehr beschrieben werden kann. Aber zu diesem Zeitpunkt ist es ein bisschen schwer zu treffen, insbesondere wenn unterschiedliche Versionen, unterschiedliche harte Versionen benutzt werden. Und patchführende Funktionalitäten war sehr hilfreich, wie wir sie benutzen können, um einen langfristig wartbaren Jailbreak zu haben. Das heißt, wir haben ein Boot-Trampolin gemacht, das ist der letzte Ball, das Boot-Rom-Eiboot schreibt, und das wird den vorherigen Bootloader überschreiben, dass spätere Bootloader den Arbeitsspeicher nicht, dass er nicht ausgelesen werden kann. Das ist vorschaltlich Zugang zu dem Bootloader haben. Außerdem wird er die IMU ausschalten und setzt auch viele Register zurück. Auch Register, die sonst nicht irgendwo benutzt werden. Das heißt, wir können auch dieses Trampolin dadurch finden, dass wir genau diesen Befehl finden. Der ist deterministisch, nur genau in dieser Funktion sind Boot-Trampolin. Wir haben Schalkehaut, die diese lookdynamisch findet und auspatscht. Aber es gibt auch ein Hühner- und Hund-Eib-Problem, weil das Trampolin wird den aktuellen Bootloader überschreiben und es muss realisiert werden und woanders, um sicherzustellen, dass es sich nicht selber überschreibt. Es gibt eine Region, die dafür reserviert ist, aber bei Secure-Rom insbesondere ist das Trampolin manchmal, wenn es erst realisiert, kurz bevor es benutzt wird. Und weil es ein ROM ist, kann man es nicht patchen. Wir können Secure-Rom-Execution, bevor irgendetwas davon funktioniert, passiert. Das heißt, es ist relativ schwierig, dieses Trampolin wirklich zu modifizieren. Aber wir können Secure-Rom in SRAM kopieren und wir können die Seitentap-Pagetable so verändern, dass der Bereich nicht überschrieben wird und geben den an den schreibbaren SRAM weiter. Aber in manchen Geräten ist nicht ausreichend freier SRAM-Speicher verfügbar. Aber in den Fällen können wir Strategien machen, dass z.B. erhiebkleiner gemacht wird oder dass wir mehr verfügbaren SRAM bekommen, da wir mehr L2-Cache dafür reservieren. Aber wir müssen eigentlich nur eine einzelne Seite benutzen, also sehr wenig Code. Zusätzlich dazu braucht man auch noch einen Bereich, wo wir unseren Sharecode hinschreiben können. Aber wir sind immer noch beschränkt durch den freien SRAM. Und wir müssen auch noch den normalen Bootprozess verfolgen, was auch noch SRAM benutzen können. Vielleicht können wir DRAM benutzen, aber der ist noch nicht initialisiert wie ihren SICKRAM läuft. Der S-Level-Bootloader initialisiert das dann. Aber dieser Modus hat auch noch ein Soft-DFU-Modus, wo DFU simuliert wird. Das erlaubt uns, noch mehr Daten zu Geräte hochzuladen und damit können wir beliebig viel Daten in DRAM zu tun. Und das heißt, wir haben nicht mehr das Problem mit dem SRAM. Das Problem mit DRAM ist, dass iBoot große Teile davon löschen wird. Wir haben dreckigen Workaround gefunden, welche B0 hockt und schaut, ob es mit unserem Shell-Code als Parameter aufgerufen wird. In diesem Fall sagen wir, dass es einfach nichts zu ist. Und wenn wir das Trampolin hocken und B0 hocken, dann können wir das nächste Trampolin erreichen. Das wird immer wieder gelöscht. Das heißt, wir müssen es jedes Mal neu hocken. Vor A10 gibt es nur zwei Stufen, A10 und später. Am Ende wird der Körnel vorbereitet und das Trampolin wird wieder benutzt, um den Entry Point zu starten. Das heißt, da müssen wir noch ein bisschen mehr arbeiten, um den eigentlichen Körnel Entry Point zu finden. Und wir patchen uns da so rein, dass unser eigener Shell-Code ausgeführt wird anstatt das Secure Monitor. Und damit können wir auch verhindern, dass die ursprünglichen Stufen werden rausgepatchen. Wir können jetzt den Körnel patchen, aber weil wir ganz viele verschiedene Geräte supporten, ist die einzige gute Strategie, alle unsere Patches dynamisch zu organisieren. Aber weil wir unseren Exploit so gemacht haben, wie wir gemacht haben, ist alles noch sehr, sehr langsam, weil wir noch keine MMU oder Caching haben. Das heißt, es wird sehr schnell, sehr langsam. Und deswegen machen wir die MMU erstmal an und das macht dann DRAM wieder cachebar. Und dann ist unser Patchfinder wieder schnell. Unser Patchfinder macht jetzt ein relativ old-schooliges, nämlich wir können Dinge patchen, die Körnel, die Jailbreaks nicht mehr patchen konnten, wegen KTR und so. Das heißt, wir können wieder read write executable code maten können. Das war jetzt für Jailbreakers seit 4 Jahren nicht mehr verfügbar. Aber Körnel patching ist nicht alles, was wir brauchen. Sobald wir den Körnel gebotet haben, wollen wir weiterhin Code execution Rechte haben, um den Jailbreaken Status zu behalten. Und das ist sehr schwierig an der Stelle, weil man dafür ein Data System Treiber bräuchte. Wir können einen kleinen RAM-Disk in unseren Shale Code reintun und den Gerätebaum und die Körnel-Boot Argumente ein bisschen verändern, damit unser Data System als das Route Data System benutzt wird. Das endresultat war das hier, unser erster Patchfinder. Wir haben mit Securum Code Execution angefangen. Dann sind wir weitergegangen bis zu EL0 User Mode Execution. Die RAM-Disk muss ziemlich klein sein, weil DFU-Transfers nicht schnell sind und man viele Sekunden warten muss. Außerdem gibt es noch Uheberrechtsprobleme. Wir sollten nicht Apple Code schippen mit unserer RAM-Disk. Das ist problematisch, weil es keine dynamischen Linker gibt und ein paar User Mode Bibliotheken braucht. Das ist eine dynamische Linker, der nicht dynamisch linkt, sondern es mountet das echte Data System mit einem Union-Mount über unsere Dings. Damit haben wir die normalen Apple-Bibliotheken und können dynamisch linken usw. Dann können wir das alles machen bevor die echte PID eins ausgeführt wird. An diesem Punkt ist das Route-Data-System noch read-only. Das wollen wir so behalten, bis der User das ändert. Aber wir wollen auch ein paar extra Dateien da rein tun, um eine Shell zu bekommen und damit User-Paket-Menscher installieren können, falls ihr das brauchen. Das heißt, wir brauchen die Private-Var-Partition. Das Problem ist, das ist auch die Partition, wo die User-Daten gespeichert sind. Das Problem ist, die Partitioner ist verschlüsselt und die Datenverschlüsselung muss dafür initialisiert sein und dafür ist launch die Fahrten fortlich. Das heißt, wir müssen Code-Execution noch später bekommen, immer noch früher im Bootprozess. Dann machen wir weiter mit dem Union-Mounting und dann machen wir dann ein kleines DMG über User-Lib-Exec-Gereien und damit können wir irgendein System-Demon überschreiben. Wir haben uns System-Stack ausgewählt, weil es zum richtigen Zeitpunkt läuft, selbst über verschiedene IOS-Versionen hinweg. Das war relativ schwer rauszufinden und am Ende sind wir aber auf diesen Demon gekommen. Sobald wir diese Code-Execution hatten, dann können wir wieder EXEC-VI aufrufen auf der initialen RAM-Disk und das User-Lib-Exec-Ding an-mounten. An diesem Punkt ist der Status des Systems gut und wir können weiterbooten. Wir können entweder forken, um unser eigenes Code auszuführen und dann unseren Code weiterhin dazuhaben. Dann warten wir, bis USB an ist und warten auf den Host, bis er die entsprechenden Daten runtergeladen hat, sodass man ein SSH-Demon hat und ein paar Jailbreak-Installations-Routinen. Das Resultat ist jetzt, wir können eine Routshell auf einem beliebigen iPhone bekommen, zu jedem iPhone, was dazu verwundbar ist, auf jeder Version. Sobald wir in der Springboard die Daten zeigen, können wir unseren Check-Crain-App hinzufügen. Wir haben auch ein paar Zukunftspläne für das Ganze hier und wir würden gerne ganzen von einem Jailbreak zu etwas weiteres entwickeln. Bootloader, PC-Devices, für normale Räte, die es ermöglichen und eine beliebige Kernel-Motorene zuzufügen, z.B. auch Joule-Booting und eventuell sogar Linux und Windows auf einem iPhone zu booten. Daran arbeiten wir immer noch, aber wir haben Pawn-Pongo-OS. Das haben wir vorher nur kurz genannt. Wir veröffentlichen es heute so wirklich zum ersten Mal. Das ist ein kleines Pre-Boot-Ausführbaus, ein Betriebssystem, das vom Check-Crain-Team erstellt wurde und es genau für Apple-Polls laufen soll. Wir können Module mit USB dazu laden und werden dagegen gelingt werden, gegen alle Sachen von Pawn-Pongo-OS gebudet werden. Wir konnten den Patcher zu so einem Modul laden. Das heißt, es ermöglicht, dass Leute unsere Infrastruktur benutzen, um ihre eigene Sachen auszuführen und für Sicherheitsforschung. Und das war's. Danke. Das war's auch von uns aus der Übersetzer-Kabine. Wir waren Franz T. und Alpen. Wenn ihr Fragen im Internet stellt, wie wurde dieses Exploit gefunden, wird da immer noch Forschung hineinfließt? Dieser Bug wurde von verschiedenen Leuten gefunden. Die Person, die den Bug gefunden hat, publiziert hat, und die Person, die den Bug erinnert hat, hat es durch Diffing herausgefunden, weil Apple ein Patch dazu publiziert hat. Es gibt eine zwei Jahre Verzögerung zwischen Apple, die es herausfinden und was anderes ins Silizium gepatcht werden kann. Das heißt, die Person, die den Bug erinnert hat, hat es durch Diffing herausgefunden, weil Apple ein Patch dazu publiziert hat. Das heißt, die Person, die das Silizium gepatcht werden kann, ich weiß nicht, ob es noch mehr Bugs gibt in einem Eiboot, und sagt mir Bescheid, wenn du irgendwas findest. Danke. Es gibt Fragen auf die Microphones. Weitere Fragen? Hallo, toller Vortrag. Ich habe so viel Arbeit noch nicht gesehen, so was geschickt zu haben. Wenn der Hauptfrage heute ist, was vermutet ihr, dass Check-Rain-Windows darauf läuft? Vielen Dank, schon mal im Vorhinein. Wir haben daran schon ziemlich hart gearbeitet, und Check-Rain ist zurzeit nur für MacOS verfügbar. Ich hoffe, es wird bis zum Ende auf Linux verfügbar sein. Die Windows-Versionen daran haben wir noch nicht viel gearbeitet, aber wir haben schon ein paar Achievements, ein paar Erfolge dort gehabt. Wir können schon ein paar Geräte damit boosten, vielleicht in den nächsten paar Monaten. So, there's another question on Microphone 4. Ja, Roses sind rot, Violetten sind blau. Windows 88 Check-Rain, wann? Ich habe diese Frage gerade beantwortet, aber gutes Meme. Vielen Dank. Noch eine Frage aus dem Internet. Jemand hat sich gefragt, wo der SOS gehört? Zurzeit ist Check-Rain close to us, aber das Team-Plans ist versucht, es zu open-sossen. Und Pango, es wird wahrscheinlich das Erste sein, was geopensoss ist, und es wird nach und nach mehr davon verfügbar gemacht wird. Über das nächste Jahr hinweg wird das wahrscheinlich alles open-soss sein. Ihr könnt auf meinen Twitter schauen oder auf den Check-Rain GitHub. Danke. Das war's dann vom uns großen Runde Applaus und Feedback für die Besetzung des Hashtags C3T auf Twitter.