 Samuel arbeitet für Google Project Zero, für Webbrowser und Mobilgeräten Verwundbarkeiten und er war Teil des Teams, die einige der Verwundbarkeiten in diesem Talk, die er in diesem Talk vorstellen wird. Vor allem Verwundbarkeiten, die ohne User-Act-Interaktion stattfinden und entfernt ein iPhone mit einer iMessage-Nachricht komprimitieren können. Bitte einen großen Applaus für Samuel. Okay, danke. Willkommen bei meinem Talk. Ein Hinweis, bevor ich anfange. Ich habe nur eine Stunde. Das heißt, ich musste einige Details rauslassen, aber es wird auch einen Blog-Post geben. Der hat auch viel mehr Details. Und in diesem Talk, ich wollte alles irgendwie reinkriegen und deswegen habe ich ein paar Details rausgelassen. Also das ist über iMessage und einiges trifft auch auf andere Messenger zu. Aber wir kontaktieren uns auf iMessage. Was ist iMessage? Das ist ein Messenger-Service von Apple. Da haben wir im vorigen Talk auch schon was darüber gehört. Und soweit ich weiß, es ist standardmäßig angeschaltet, sobald jemand sich mit seinem Account in ein iPhone einloggt, was die meisten Leute machen, weil sonst kann man keine Apps runterladen. Und interessanterweise kann jeder an jeden anderen Message schicken. Es ist also wie SMS oder Anrufe. Und wenn du das machst, dann kommt eine Notifikation, die man hier auf dem Screenshot sehen kann, die das bedeutet, dass irgendwelche Verarbeitung stattfindet. Und das ist also standardmäßig aktiviert. Und das ist ein zero-click-act-attack-Service. Also es passiert, ohne dass der User irgendwas machen muss. Und auf dem rechten Screenshot sehen wir, dass man Nachrichten von unbekannten Sendern empfangen kann. Da sagt er, das steht ja nur, dieser Sender ist nicht in deinen Kontakten, aber die ganze Verarbeitung findet trotzdem statt. Die Architektur von dem ganzen System, das sieht ungefähr aus, wie iMessage strukturiert ist. Nicht besonders interessant eigentlich. Das ist die Apple Cloud Server. Und dann hast du den Sender und den Empfänger und die sind beide mit diesen Service verbunden. Und das war es eigentlich auch schon. Der Content, der Inhalt ist Ende zu Ende verschlüsselt. Das finden wir super, super gut. Das heißt aber auch, dass Apple diese Exploits weder erkennen, noch blockieren kann, weil die ja schließlich verschlüsselt sind. Und das ist interessant festzustellen. Wie sieht ein iMessage-Angriff aus? Was brauchen wir vorher? Der Angreifer muss die Telefonnummer oder die E-Mail-Adresse des Apple-Accounts wissen. Das iPhone muss in der Standardkonfiguration sein. Also iMessage darf nicht deaktiviert sein. Und das iPhone muss mit dem Internet verbunden werden. Und das sind ganz schön wenige Voranmenungen, die wir brauchen, um diesen Exploit auszuführen. Weil es gibt ganz schön viele iPhones. Nach ein paar Minuten hat der Angreifer volle Kontrolle über das iPhone. Das braucht so fünf bis sechs Minuten. Und das funktioniert komplett ohne visuelle Anzeigen. Also man kann das so machen, dass auch keine Notifikation während diesen Angriffs kommt. Aber bevor wir jetzt auf den Exploit kommen, müssen wir die Verwundbarkeit prüfen. Und dafür müssen wir erst mal Reverse-Engineering betreiben. Also da wollte ich mir erzählen, wie wir das Ganze angesetzt haben. Und die erste Frage, die man sich vielleicht fragt, ist, welchen Dämon oder welcher Service kümmert sich um iMessages? Und eine Art, die es rauszufinden, ist, du kann man sich einfach nur fragen. Du schaust deine Prozessliste auf deine Mac an, weil der Mac kann ja auch iMessages empfangen. Und dann stopf so einen dieser Prozesse und dann siehst du, ob iMessages immer noch ankommt. Und wenn nicht, dann hast du wahrscheinlich den Prozess gefunden, der irgendwie mit iMessages verbunden ist. Und wenn du das machst, dann findest du iMagent. Und klingt schon so ein bisschen verwandt damit. Und wenn du ihn anschaust, dann hat er auch eine iMesh-Library, die er lernt. Das sieht schon sehr relevant aus. Und dann kannst du auch diese Library in Ida laden. Hier oben rechts sieht man das. Und dann findest du viele Handler, die zum Beispiel dieser Message Service Session Handler. Und dann kannst du da mal Breakpoint setzen. Und in diesem Breakpoint siehst du die Messages, wie sie reinkommen. Du kannst sie ausdrucken, anzeigen, ändern und so weiter. Also eine super Art und Weise, da anzufangen. Und wenn du von dort anfängst, dann wirst du natürlich die Fragen, wie schauen diese Messages aus? Das heißt, du kannst sie einfach mal ausdrucken in deine Konsole. Wenn sie reinkommen, dann Handler. Auf der rechten Seite sieht man hier, wie diese iMessages aussehen. Also werden sie versendet werden. Die sind als P-List encodiert. Das ist ein Apple-Format. Ich stelle das vor wie JSON oder XML. Und ich denke, einige Felder sind selbsterklärend. Also P sind die Participants, die Teilnehmer. Das ist ich. Ich sende eine Nachricht an einen anderen Account, der auch mir gehört. Du hast T, das ist der Textinhalt. Also hier, hello 36 C3. Du hast Version, die Version. Du hast auch aus irgendeinem Grund eine XML oder html fällt. Was wahrscheinlich so ein Legacy-Dings ist, das wird als XML geparst. Aber das sieht schon ein bisschen komplex aus. Also man hätte vielleicht erwartet eine einfache Nachricht, die einfach nur ein Text ist. Tatsächlich sendet er dieses Dictionary über das Internet. Dann schauen wir doch mal ein bisschen genauer, was dafür Angriffsfläche ist. Mit dem Reverse-Engineering, wenn man sich dann Handler genauer anschaut, dann gibt es zwei spannende Keys. ATI und BP. Und die enthalten NSKeed Unarchiver Daten. Das ist wieder ein proprietäres Apple-Format. Es ist ziemlich komplex. Hatte schon einige Bugs in der Vergangenheit. Auf der linken Seite hier seht ihr ein Beispiel für eines dieser Archive. Auch das wird in einer P-List encodiert. Und es ist dann eigentlich ein großes Array, in dem ihr das Objekt ein Index hat. Wie beispielsweise hier, die Index 7 ist die klasse NSSharedKeyDictionary. Und der Schlüssel 1 ist eine Instands dieser Klasse. Das Ganze ist also ziemlich mächtig. Was es aber für uns bedeutet, ist, dass dieses Serializer 0-Click-Angriffsfläche ist. Weil er wird gepasst ohne irgendwelche Benutzerinteraktionen. Gut, ich habe gesagt, es ist ziemlich komplex. Es unterstützt sogar Dinge wie zyklische Referenzen. Man kann ein Objektgraph senden, in dem Art auf B zeigt und B zurück zu A zeigt. Aus irgendeinem Grund, wenn man das wollte. Natalie hat einen super Blog-Post geschrieben, in dem sie das in mehr Details erklärt. Was ich hier habe, ist nur ein Beispiel für die API, wie man die benutzt. Hier unten auf der Slide. Wenn ihr Objectives C nicht kennt, diese Klammern hier sind einfach Calls. Also was es auch in der letzten Zeit tut, ist, es ruft diese unarchived Objective auf Glass auf. Ihr seht auch, man kann hier eine Whitelist mitgeben. In diesem Fall wird es also nur Dictionary Strings und Daten entpacken. Das schaut also eigentlich schon mal gut aus. Interessanterweise, wenn man hier tiefer reingrebt, dann stimmt das leider nicht ganz. Weil das erlaubt auch alle Unterklassen zu decoden. Also wenn wir einen Unterdictionary haben, das vom NSDictionary erbt, dann kann das hier auch decodiert werden. Was ein bisschen unintuitiv ist, weil das lässt die Angriffsfläche natürlich explodieren. Man hat also nicht nur sieben Klassen, die decodiert werden können, sondern vielleicht 50. Das ist der Punkt, auf den wir uns fokussiert haben, als Natalie und ich Dinge angeschaut haben. Das schaut am Komplex aus. Wir haben eine ganze Reihe von Verwundbarkeiten gemeldet auf der linken Seite. Die eine, für die ich einen Exploit geschrieben habe, das war dieses 19.17, haben wir am 29. Juli gemeldet. Ich wurde kurz darauf die Bücke geschlossen. Wir haben noch das fokussiert, weil sie am einfachsten schienen. Wahrscheinlich könnten auch die anderen angriffen werden. Es hätte wahrscheinlich einfach mehr Arbeit auf dem Hieb herfordert. Apple hat relativ schnell eine Mitigation implementiert, die den Code nicht aus einem Message aufgerufen werden lässt. Was das tut, es erlaubt nicht weiter, Subklassen zu decodieren, was ich vorher erwähnt hatte. Das ist eine ziemlich gute Mitigation, blockiert ungefähr 90% der Angriffsfläche. Und in iOS 13.2 wurde dann ein voller Fix implementiert. Zu diesem Zeitpunkt war es aber nur noch lokale Angriffsfläche. Gut, was ist der Bug? Es ist ein Initialisierungsproblem in der Dekodierung. Der verwundbare Teil ist ein NSSharedKeyDictionary, das in der Whitelist ist. Deshalb darf es dekodiert werden. Schauen wir uns an. SharedKeyDictionary mit etwas Pseudocode in Python. Es ist ein Dictionary mit dem Zweck, Schlüssel zu Werten aufzulösen. Der Lookup ist sehr einfach. Es schaut nach einem Key im SharedKeySet und benutzt dann diesen Index, um den Wert in einem Array aufzurufen. Der größte Teil der Magie passiert also im SharedKeySet. Und was dort passiert, ist ungefähr, es wird ein Hash vom Schlüssel berechnet. Der Schlüssel wird verwendet, um einen Index in einer RankTable zu finden. Und wenn dieser Index gültig ist, also wenn es ein Match zurückkommt, dann wurde ein richtiger Index gefunden. Wenn nicht, kann es zu einem anderen SharedKeySet zurückfallen. Und diese Berechnung wiederholen. Es schaut also schon einigermaßen komplex aus. Wieso braucht es diese Rekursion? Erschließt sich mir nicht genau, aber es ist hier. Also schauen wir uns doch an, wie das Ganze schiefgehen kann. Hier haben wir InitWithCoder. Das ist der Konstruktor für SharedKeySet in der Decodingphase. Und das scheint eigentlich ziemlich solide zu sein. Es nimmt Wert ja aus einem Archiv. Und speichert sie als Felder in diesem SharedKeySet. Ich gehe hier durch den Code in einzelnen Schritten, um aufzuzeigen, wo etwas falsch laufen kann. Wir beginnen also mit SharedKeySet1. Das impliziert, dass dann weiteres sein wird. Und momentan ist alles auf 0 initialisiert. Wir führen die erste Programmzeite aus. Namki wird gesetzt. Wir sehen interessante Werte kommen. Soweit so gut. An diesem Punkt können wir Namki auf alles setzen. Weil es erst in ungefähr drei Zeilen validiert wird. Momentan also noch nicht. Das ist okay. Und hier kommt nun ein Rekursionsschritt, in dem ein anderes SharedKeySet geprüft wird. Erdekodiert wird. Das ist ebenfalls gefüllt mit nullen. Und wir starten wieder oben. Namki ist 1. Das ist okay. Dann wird der Rekursionsschritt gekodiert. Und hier machen wir jetzt ein Kreis für das zweite SharedKeySet. SharedKeySet 2. Das sagen wir, dass dessen SharedKeySet 1 ist. Das funktioniert. Der SharedKeySet 1 hat besonderes Handling dafür und macht einen Zyklus. Und damit können wir lossegen. Danach dekodiert das SharedKeySet 2. Es sieht soweit so gut aus. Und nun macht es ein paar Sicherheitsprüfungen, um sicherzustellen, dass dieses SharedKeySet jeden Key aufrufen kann. Es tut das für jeden Key. In diesem Fall Key1. Key1. Und auch hier geht es in die RankTable. 42 ist größer als die NamTable. Das heißt, der LookUp klappt also nicht. Fällt also zurück. Und an diesem Punkt nimmt es das Hex 41, 41, 41 als Index und vergleicht es mit ffff. Was aufgeht. Und vergleicht dann den NullPointer mit ffff, ffff, ffff mal 8. Und ruft dann an diesem Punkt ungültigen Speicher auf und stürzt ab. Das rührt davon her, dass in diesem Fall SharedKeySet 1 noch nicht validiert wurde. Und das ist genau der Bug, den wir exploiten werden. Ich habe hier Checkpoints, um sicherzustellen, wo wir sind. Momentan haben wir eine Verwundbarkeit im NSUnarchiver, die wir über ein Message aufrufen konnten. Schauen wir uns nochmal die LookUp-Funktion an, die wir vorhin schon gesehen hatten. Hier, der fette Text, dort stürzen wir ab. Keys ist ein NullPunkter-Index-Kontroll der Fallends. Und was dann passiert, das Resultat dieses Speicherzugriffs wird als Objective-C-Objekt verwendet. In der Realität ist das nicht Python, sondern Objective-C. Wir rufen dann eine Methode, zum Beispiel, is a string auf. Und irgendwann rufen wir den Destruktor die Alloc auf. Das Ding, von dem wir lesen, wird also wie ein Objective-C-Objekt aufgerufen, behandelt werden. Und das ist unsere Exploit-Primitive. Gut, wie nutzen wir das aus? Die Art und Weise, wie wir das ausnutzen, sieht ungefähr so. Das ist ein falsches Objective-C-Objekt im Speicher, das du referenzierst. Also, wir können da eine arbiträre, absolute Adresse referenzieren. Und da hatten wir gern ein falsches Objective-C-Objekt. Das hat immer einen Pointer zu seiner Klasse. Und diese Klasse hat eine Methodentabelle, die Funktionspointer zu diesen Messages hat. Das heißt, wenn wir diese gesamte Datenstruktur felschen, also ein Fake-Objekt und eine Fake-Klasse, dann ist passiert das, dass, wenn sobald der Prozess unsere Fake-Klasse irgendwie aufruft, dann haben wir Codausführung erreicht. Und dann ist echt Game Over. Und das wird unser Ziel sein für diesen Exploit. Hier haben wir zwei verschiedene Arten von Adressen. Auf der linken Seite haben wir Heap-Adressen oder Daten eigentlich. Und auf der rechten Seite in diesem NS-String-Ding haben wir Bibliotheks-Adressen oder Code-Adressen. Einfach weil, und auf iOS kannst du nicht, da kannst du keine schreibbaren Code-Regionen haben. Das heißt, wir müssen existierenden Code wieder benutzen. Und deswegen müssen wir wissen, wo die Bibliotheken liegen. Und das ist genau das Problem, das wir jetzt haben werden, weil dieses Ding ist ASLR. Das heißt, das ist ein Adressraum-Layout zufälliger Verschuldigung. Das heißt, der verstiebt den Adressraum im Speicher zufälliger Weise. Und das heißt, wir sehen uns, wir sehen den virtual memory von einem Prozess bevor ASLR. Und da ist alles immer auf derselben Adresse gemapped. Das heißt, wenn du die selbe Adresse auf verschiedenen iPhones hast, ohne ASLR wäre diese Library immer an der gleichen Stelle. Der Heap und der Stack und alles über das Gleiche. Also das wäre echt, echt einfach, weil alles ist immer das Gleiche. Mit ASLR ist alles verschoben. Und deswegen sind die Adressen alle randomisiert, zufällig verteilt. Und das macht es deutlich härter, das zu auszunutzen. Das heißt, wir müssen ASLR umgehen. Denn diese Idee werden wir mal in zwei Teile aufteilen. Die Heap-Adressen, kriegen wir auf eine andere Art und Weise als die Bibliotheks-Adressen. Und okay, wie kriegen wir jetzt die Heap-Adressen? Wir benutzen das ganz einfach, du kannst Heap-Spraying benutzen, das ist eine alte Technik. Seit 15 Jahren wird die eingesetzt. Und das funktioniert immer noch heutzutage. Die Idee ist, dass du einfach ganz viel Speicheralozi ist. Zum Beispiel, das ist da auf der rechten Seite. Und man kann es testen. Und was da passiert ist, es aloziiert 256 Megabyte Speicher auf dem Heap. Und danach wird eine Adresse, also da sind viele, aber hier benutze ich das 1.1 und dann 7.0. Das ist die Adresse, wo ich meine Daten finde. Und damit spamsst du, dann sprayst du einfach 256 Megabyte zu mit dieser Kontrolladresse. Das ist malerweise für diesen ersten Teil des Exploits. Die Frage ist noch, wie kann man Heap-Spray über Einmessage machen? Aber das funktioniert, weil NSKID Unarchaver großartig ist und lässt eine so viel seltsame Sachen machen, die man ausnutzen kann für Heap-Spraying. Der Blockpost wird dann noch mehr Details haben. Okay, also die haben wir jetzt. Wir haben die Heap-Adressen. Wir haben die Bibliotheks-Adressen. Und dann gehen wir jetzt zurück zu dem Wirtlern-Adressraum. Auf IOS und MacOS auch sind die Bibliotheken, also zum Beispiel hier diese drei Libraries. Wirklicherweise sind es natürlich viel mehr. Hundert davon, die sind alle vorgelinkt. Die sind prälig in einem binary Blob. Das ist der YLD Shared Cache, Dynamically Loaded Shared Cache. Zwischen Abhängigkeiten werden da schon vor, auf der Compile-Zeit, vor ausgelöst. Deswegen haben wir es schneller zu laden. Und wir haben also diesen riesigen binären Blob. Und das hat alles, was wir brauchen. Das hat den ganzen Code. Das hat alle die ganzen Rob-Gadgets. Und das hat diese ganzen Klassen, die wir brauchen. Und das heißt, wir müssen nur wissen, wo der YLD Shared Cache liegt. Wenn du da so ein bisschen dich reingräbst oder die Dokumentation ansehst, dann findest du raus, dass es immer zwischen diesen beiden Adressen gemapped ist. Also zwischen Hex 18 und dann vielen Nullen und dann 28 und vielen Nullen. Das heißt, es gibt nur ungefähr 4 Gigabyte Platz, wo die YLD liegen kann. Und die Zufälligkeitsgranularität ist 0x4000 in Hex. Das heißt, IOS benutzt große Rampages für diese Granularität. Das heißt, es ist relativ grob verteilt. Aber was am interessantesten eigentlich ist, ist, dass auf dem selben Device der YLD Shared Cache wird nur einmal pro Bootvorgang randomized. Das heißt, wenn du zwei Prozesse hast, dann ist der Dilt Cache immer an der selben Stelle. Und der geteilte Cache ist also immer an der gleichen Stelle. Und das macht es natürlich super interessant. Und auch außerdem ist dieser Cache 1 Gigabyte groß. Er ist gigantisch. Das heißt, er ist gar nicht so schwer in dieser 4 Gigabyte Region zu finden. Also das ist also unsere Aufgabe jetzt. Wir haben diesen Adressraum, wir haben den Shared Cache und alles, was wir brauchen, ist, was ist dieser Abstand hier. Jetzt machen wir eine Art Experiment. Wir hatten ein Oracle, das uns sagen würde, dem wir eine Adresse geben würden und dann könnte uns das sagen, ist diese Adresse gemapped, und zwar von einem anderen Computer aus, von Remote aus. Wenn wir das haben, dann ist es super einfach, dieses Problem zu lösen, weil alles, was wir machen müssten, ist, gehen wir einfach in 1 Gigabyte Schritten zwischen diesen beiden Adressen und dann irgendwann finden wir eine valide Adresse. Vielleicht nach 3 Schritten finden wir hier eine und von dort machen wir einfach nur eine Binärsuche, weil wir wissen, dass irgendwo zwischen hier und dem grünen und dem roten App-File, da fängt der Shared Cache an und da können wir eine Binärsuche machen und dann finden wir die Start-Adresse in logorhythmischer Zeit, also Sekunden, Minuten, wie auch immer. Offensichtlich ist also die Frage, woher kriegen wir dieses Orake? Das klingt etwas seltsam. Also schauen wir jetzt mal an Bestätigungen an iMessage, genau wie andere Messaging-Apps auch. Also wie so ziemlich alle, schickt eine Bestätigung für verschiedene Dinge zurück. iMessage hat Spitz-Lieferbestätigungen und Lesebestätigungen. Die Lieferbestätigung sagt, das Gerät hat die Message erhalten und Lesebestätigung heißt, dass der Benutzer die Benutzerin tatsächlich die App geöffnet und die Message angesehen hat. Man kann Lesebestätigungen ausschalten, aber soweit ich weiß, kann man die Lieferbestätigungen nicht ausschalten. Hier auf der linken Seite sehen wir einen Screenshot. 3 verschiedene Nachrichten sind gesendet worden und die haben 3 verschiedene Zustände. Bestätigung und eine Lesebestätigung bekommen. Die 2. Nachricht ist als Angeliefert markiert. Das heißt, sie hat eine Lieferbestätigung bekommen und die 3. Nachricht hat keine Bestätigung bekommen. Warum ist das nützlich? Auf der lichtenden Seite haben wir ein bisschen Pseudocode von dem iM-Adagent, wie er eben Nachrichten behandelt, wenn er diese Bestätigungen sendet. Wir sehen hier, dass es zuerst mal die P-List mit den Message-Staaten durchpasst. Dann passiert dieser Anarchivsschritt und das ist der Bug, den wir jetzt auslösen während Anarchiv. Nur dann sendet es tatsächlich diese Lieferbestätigung. Das heißt, wenn wir einen Bug während dem Anarchiv auslösen können, dann haben wir einen Side-Channel von einem Bit, der uns sagt, wenn der crashed, dann sehen wir nämlich keine Empfangsbestätigung. Wenn wir keinen Crash auslösen, dann kriegen wir eine Empfangsbestätigung. Ein Bit an Informationen. Und das wird unser Orakel sein. Idealerweise haben wir eine Vorwirkbarkeit, die uns dieses perfekte Orakel gibt, dass sie sagt, ist diese Adresse gültig oder nicht. Also crash immer dann, wenn diese Adresse gemappt ist. In der Wirklichkeit kriegst du dieses perfekte Orakel, nicht aus diesem Bug. Auf der richten Seite siehst du die echte Orakelfunktion für diese Verwundbarkeit. Das heißt, es muss gemappt sein, aber es benutzt auch den Wert, den es liest. Das heißt, es wird nur dann nicht crashen, wenn der Wert entweder null ist oder hat das meistwertigte Bit gesetzt oder wenn es ein wirklich ernsthafter Pointe auf ein Object C-Objekt ist. Das heißt, diese Funktion ist etwas mehr komplex, aber die gleiche Idee funktioniert immer noch. Man kann sich immer noch binär suchen und den Crash damit auslesen und zwar in logaritmischer Zeit. Es braucht nur so fünf Minuten und dann muss ich euch nochmal auf den Blog-Post verweisen. Gut. Das ist also die Zusammenfassung, wir von Remote um ASLR drumkommen. Wir tun also diesen Linear-Scan. Wir prüfen, ob wir eine Bestätigung zurück erhalten und das erste Mal, wenn wir eine Bestätigung erhalten, dann wissen wir, die Adresse ist gültig. Von diesem Punkt starten wir diese Suchphase, die in ungefähr logaritmischer Zeit die genaue Startadresse findet. Es gibt hier ein paar normale Fragen, die man stellen kann. Die erste ist offensichtlich. Kann man diesen Agenten wirklich einfach 20-mal nacheinander abstützen lassen? Die Antwort ist, ja. Es gibt keine Anzeige, die dem Benutzer sichtbar machen würde, dass dieser Dienst abgestürzt ist. Das einzige, was man machen kann, ist irgendwo in die Crash-Locks gehen in Settings und Privacy. Und dann sieht man die Crash-Locks. Das tut aber keiner. Die zweite Frage ist, standardmäßig ist iPhone konfiguriert, Crash-Locks zu Apple zu senden. Ist das kein Problem? Ich habe das kurz angeschaut. Es scheint, als ob iOS höchstens 25 Crash-Locks pro Service sammelt. Die Funktion ist nicht als Security-Feature ausgelegt. Das bedeutet aber auch, dass ein Angreifer einen Resource-Exhaustion-Bug einsetzen kann, um diesen Dienst zum Beispiel 25-mal abstützen lassen kann und erst dann mit dem Exploit anfängt. Das heißt, da würde keine Spur des Exploits in den Locks landen. Die dritte Frage ist, ob man das einfach repanieren könnte, indem man die Lesebestätigung, die Sendebestätigung sehr schnell sendet. Das war auch mein erster Vorschlag an Apple. Ich habe dann aber herausgefunden, das funktioniert nicht ganz, dass man die Lesebestätigung erzielen kann. Wenn ein Dienst mehrmals abstürzt, dann wird er verlangsamt und startet erst ein paar Sekunden oder ein paar Minuten später wieder. Das heißt, anhand des Timings, wenn man eine Lesebestätigung erhalten würde, könnte man den selben Angriff weiterhin ausführen, einfach ein bisschen anders. An diesem Punkt starte ich die Demo. Die Demo hat zwei Teile. Und ich schau mal, wo sie ist. Ich habe hier ein iPhone. Mit Quicktime kann man den Bildschirm hier auf den Projektor bringen. Das ist ein iPhone XS. Vom letzten Jahr, Version 12.4, das ist ungefähr ein halbes Jahr alt, ist die letzte verwundbare Version. Momentan sind keine Nachrichten in Messages. Und jetzt schauen wir mal. Ich hoffe, dass das Wifi funktioniert. Was man hier sieht, ist, der Exploit hockt sich mit Friday in ... Wir kriegen Sendbestätigung. Der Exploit funktioniert so, dass er die Messages mit Friday auf MacOS hockt. Und jetzt spezifische Marker sendet. Und der Friday-Hook ersetzt dann diese Nachricht mit der aktuellen Payload. Nun prüft es diese Adressen. Es ist nicht zu langsam, würde ich mal sagen. Und hier werden immer neue Nachrichten angezeigt. Das ist schon das Ende der ersten Stufe. Das war ziemlich schnell. Das hat man in gültiger Interesse gefunden. Im ersten Probing-Schritt. Nun hat es 21.000 Kandidaten für die Basiserreste des Sharedcash. Und fängt an mit einer Binärsuche mit einer neuen Kandidatin. Und jetzt hat es noch 10.000 Kandidaten. Und es ist ziemlich schnell. Ziemlich effizient. Während das läuft, machen wir hier weiter. Wir sind also hier. Wir können jetzt ungültige Objekte erstellen. Wir haben alle Adressen, die wir brauchen. Und eins, eins gefolgt von 7.0. Und indem wir das tun, können wir Kontrolle über den Programmzähler erreichen und dann wirklich Standardfunktionen benutzen, wie man sie in jedem Export macht. Man wechselt zum Stack, führt etwas return-oriented Programming aus und geht in seinen eigenen Code zurück. Es gibt noch ein Problem. Es gibt ein neues Sicherheitsfeature von Apple, das erstmals in diesem Device implementiert wurde von 2018. Und die Idee ist, das benötigt Unterstützung von Prozessor, die Idee ist, dass man eine kriptografische Signatur in den obersten Bits eines Pointers speichern kann. Ganz links seht ihr hier einen Rohnpointer, die die obersten Bits sind null, und das Adressraum so funktioniert. Nun gibt es ein paar Instruktionen, die ein Pointer signieren können. Und entweder die benötigen einen Kontext oder nicht. Sie benötigen aber einen Key, der nicht im Speicher, sondern in einem Register ist und speichern dann diesen Pointer in den höchsten Bits, was ihr hier auf der rechten Seite seht, in grün. Bevor wir diesen Pointer jetzt benutzen, authentisiert der Code diesen Pointer mit einer anderen Instruktion. Und wenn diese Instruktion scheitert, dann wird der Pointer ungültig gemacht und die folgenden Instruktionen wird einfach abstürzen. Das ist diese BL-Brunch and Link Instruction, einen Funktionscall seinem Funktionspointer, die aber erst authentisiert wird. Und genau an dieser Stelle wird der Prozess abstürzen wenn der Pointer nicht authentisiert werden kann. Das heißt, für uns Rob funktioniert nicht mehr, weil Return Oriented Programming bedeutete, dass wir eine Reihe von Pointers in existierendem Code fälschen mussten. Das können wir hier aber nicht mehr, weil ein Angreifer diese Signaturen nicht generieren kann. Hier scheitert unser Exploit. Das Rote, was ihr hier seht, diese ungültige Objective C-Klasse mit einem Funktionspointer, das funktioniert nicht mehr, weil wir diese Signaturen halt nicht berechnen können. Gut, was tun wir? Eine Möglichkeit, die immer noch existiert, ist, dass dieser Klasspointer, der wird auch als Eiserpointer, der ist nicht geschützt mit Pack. Das heißt, wir können Instanzen von bestehenden, existierenden Klassen fälschen. Wir können ein gefälschtes Objekt haben, das aber eine richtige Klasse zeigt, die richtige signierte Message Point das hat. Das funktioniert weiterhin. Und damit können wir bestehende Messages aufrufen mit Kontrollfunktionen, die an einem Ort sind, wo sie nicht sein sollten. Wir können diese Messages als Gadgets einsetzen. Gut, was können wir damit tun? Eine sehr interessante Message, die wir aufrufen können, ist Dialog, der Destruktor eines Objekts. Die meisten Objective C-Exploitation Scenarios haben eine Dialog-Methode. Es gibt ungefähr 50.000 davon in diesem Shared Cache, die wir aufrufen können. Es ist davon auszugehen, dass ein oder ein paar davon wirklich interessant sind, weil die Invoke-Methode aufrufen. Eine NS Invocation ist eine gebundene Funktion. Die hat ein Zielobjekt, eine Methode, die aufgerufen werden soll. Und alle Argumente, die mitgegeben werden. Sobald man diese Aufruft, diese NS Invocation, wird über den Destruktor die entsprechende Zielmethode aufgerufen. Wir können also ein gefälsches Objekt mit einem gefälschen Destruktor machen und über eine NS Invocation aufrufen, was wir wollen. Ihr seht hier wieder diesen Schild. Den habe ich in den Slides für Instanzen, wo Apple etwas gehertet hat. In diesem Fall hat Apple NS Invocation gehertet. Es geht also nicht mehr ganz so einfach, um das zu missbrauchen in unserem Weg. Wir sind am Punkt, wo wir beliebige Objective C-Methode aufrufen können. Was ist mit Sandboxing? Wenn wir Sachen reverse-engineern und herausfinden, welche Services werden von einem Message benutzt, dann haben wir das auf der rechten Seite hier. Wir haben diverse Services, die meisten davon sind Sandbox. Das heißt, der rote Rahmen heißt, die sind in einer Sandbox. Lustigerweise ist Springboard. Macht auch NS Anakai was daf. Und zwar ist Dekudit in BP-Key. Wir müssen die Verwundbarkeit auch auslösen. Springboard ist nicht in einer Sandbox. Das ist der Haupt UI-Pod-Prozess des iPhones. Das zeigt den Welcome-Screen und die ganzen I-Cons usw. Was das bedeutet, ist, dass wir einfach nur Springboard angreifen können. Dann kriegen wir Code-Execution außerhalb der Sandbox. Wir müssen uns über die Sandbox keine so großen Sorgen machen. Das ist repariert in iOS 13. Das heißt, wir können Objective-C-Methoden außerhalb der Sandbox ausführen. Das heißt, wir können Benutzerdaten ansehen. Wir können das Mikrofon und die Kamera ausmachen. Das funktioniert alles super durch Objective-C. Aber was wir eigentlich wollen ist, wir wollen das gar nicht alles machen, sondern wir wollen einen Taschenrechner haben. Mit diesem Objective-C-Aufruf können wir das machen, indem wir das Tier der Call, der startet, die Taschenrechner-App. Das heißt, wir gehen jetzt zurück zur Demo. Der Bypass hat tatsächlich die Hälfte der Leute, da kam etwas zurück. Und jetzt haben wir nur mit einer Nachricht am Schluss einen Kandidaten gehabt für den Shared Cache. Hex 186780 und so weiter. Jetzt bereitet es den Heapspray vor. Das ist natürlich alles, der zusammengehackt. Wenn du das wirklich sinnvoll machen willst, dann musst du zum einen den ganzen Heapspray in einer Nachricht schicken. Ich bin nur faul. Und das ist wahrscheinlich auch zu groß. Eine andere Sache ist, dass ich denke, dass du wahrscheinlich nicht wirklich Springboard angreifen würdest, weil Springboard sehr empfindlich ist. Und wenn es mich crasht, dann startet eine UI neu. Das heißt, wahrscheinlich würdest du in Wirklichkeit im Agent angreifen und dann einen Sandbox-Ausbruch exploit durchführen. Denn dieser Bug bringt dich auch raus aus der Sandbox. Das sollte also machbar sein. Die letzte Nachricht ist wohl angekommen. Er freht sich kurz ein, aber schau, es funktioniert. Okay, das war unsere Demo. Der ist sehr zuverlässig, diese exploit. Weil da nicht viel Heapmanipulation involviert ist, außer dieser eine Heapspray, der relativ kontrolliert ist. Okay. Was bleibt uns jetzt noch übrig? Eine Sache, die du machen kannst, ist du den Kernel angreifen, wenn du das möchtest. Da muss man mit zwei Problemen umgehen. Also meinen Code-Signing. Du kannst auf iOS keinen unsignierten Code ausführen. Und der Workaround dafür ist, dass du GIT-Pages in Safari ausprobierst. Aber wir sind nicht in einem Web-Kontext hier. Deswegen machen wir stattdessen, wir gehen nach JavaScript Core und machen einige Zaubertricks, um System Calls nach JavaScript zu überbrücken. Und dann implementieren wir den Kernel exploit in JavaScript. Das braucht nicht weitere Vulnerabilities. Also wir müssten keinen JavaScript Core backfinden dafür. Die Idee ist, dass wir Pwn.js machen. Viele von euch kennen das. Vielleicht wurde erst mal für Edge benutzt, weil die auch was mit GIT, also just in times, compile JavaScript machen. Was ich also gemacht habe, ist, dass ich Sockpacken von Net benutze. Also dieses CVI-Nummer, die auf dieser Version 12.4 funktioniert. Das ist der Auslöser dafür. Ich habe nur den Auslöser portiert. Ich habe nicht das ganze den ganzen exploit reimplimitiert. Dieser Trigger löst eine Kernel Panic aus. Das ist sehr schön kurz, was sehr nett ist. Und wenn du das aus JavaScript aus ausführen möchtest, dann geht es dir nur um drei Sachen. Zum einen brauchst du die SysCalls. Die sind hier in Fett gedruckt. Da sind vier verschiedene Systemcalls hier. Also das sind nicht viele. Und die musst du von JavaScript aus ausführen können. Und die anderen Sachen, die du brauchst, sind diese Konstanten, Soxtream, AFInit6 und so weiter. Aber die können wir einfach die Werte nachgucken und dann das letzte, was wir brauchen, ist diese Datenstrukturen. Hier S-O-N-P-X-Extension. Das braucht ein paar Integra-Werte für Pointers. Und dann... Das ist die Magie, die hier passiert. Du nimmst SockProport.C und dann holst du die extra-histoodiesysyscalls raus. Es gibt eine Objective C-Nachricht, die du aufrufen kannst, die DSM dir gibt. Und was das dir erlaubt ist, dass du native C-Funktionspointer bekommst, die signiert sind. Weil vorher konnten wir nur Objective C-Methoden aufrufen, aber jetzt müssen wir SysCalls aufrufen. Die sind in C-Rapper-Funktionen geschrieben. Mit DSM können wir signierte Pointer zu C-Funktionen bekommen. Dann müssen wir noch JavaScript core betreten. Mit diesem Message-Call können wir das machen. Im JS-Context evaluates Scripts. Damit können wir JavaScript ausführen. Wir müssen mit dem Speicher ein bisschen rumspielen, ein paar Speicheradressen korrumpieren. Das ist nur so ein Standard-Browser-Exploit, denke ich mal. Wenn du das machst, dann hast du das hier. SockPuppet.js. Man kann so ein bisschen meinen JavaScript-API, die Memory Buffer alluzieren kann, kann man sehen. Und Speicherplatz beschreiben und Integer-Konstanten hat. Und sonst sieht es nicht viel anders von den ursprünglichen Auslöser aus. Das können wir jetzt auf den iMessage-Exploit draufbauen. Aufbauen auf diesem Primitivum der Objective C-Message-Course. Das sollte einen Kernel-Exploit aufrufen können. Und damit das Gerät völlig zu komprimitieren, ohne benutzte Interaktionen weniger als 10 Minuten. Also das war der erste Teil. Wie funktioniert dann der Fix? Was ich jetzt habe, ist einige Vorschläge. Wie man Dinge besser machen könnte. Einige Dinge, die wir jetzt haben, sind, wie man sich mit dem iMessage-Exploit wie man Dinge besser machen könnte. Eines der ersten Dinge ist der iESLR, die Umgehung von iESLR, die auf ein paar Mechanismen sich aufstutzt. Das funktioniert ähnlich auf anderen Plattformen. Zum Beispiel Android hat auch das Problem, dass das Mappings an derselben Reste sind über verschiedene Prozesse. Das betrifft auch andere Messenger, die ähnliche Leasebestätigungsmöglichkeiten haben. Der erste Punkt, schwaches iESLR, das sollte nicht so einfach sein. Theoretisch, sollte iESLR viel stärker sein, viel zufälliger sein. In der Realität ist es dieser kleine rote Bereich auf der rechten Seite. Theoretisch könnte das große grünen Rechteck nebenan sein. Das nächste Problem mit iESLR ist, dass einmal pro Boot gemacht wird. Ihr seht also, dass für verschiedene Prozesse, die dieselben Dinge am selben Ort sind, das ist wahrscheinlich schwieriger zu korrigieren, an diesem Punkt viel darauf aufbaut, dass das so ausschaut. Es würde wahrscheinlich viel Performance brauchen, um das umzubauen. Vielleicht findet ein guter Engineer eine Möglichkeit, das zu korrigieren. Das dritte Problem sind Leasebestätigungen, die erstaunlicherweise den Seitenkanal öffnen können. Und das kann genug sein, um iESLR auszuhebeln. Das andere Messenger gehe ich davon aus, dass sie dasselbe Problem haben. Was hier funktionieren könnte, ist entweder diese Funktion zu entfernen, oder sie von einem anderen Prozess zu senden, damit man dieses Timing-Ding nicht machen kann. Oder sogar vom Server aus zu senden, wenn der Server schon die Zustellmeldung sendet. Das ist ein kleines bisschen beschissen, aber es ist wahrscheinlich auch so, dass es in einer Sandbox laufen sollte. Das würde dann bedeuten, dass der Angreifer einen vollen Exploit braucht, um aus der Sandbox rauszukommen. Sandboxing kann auf der anderen Seite, aber auch Information Leaks, offensichtlicher machen. Es ist wahrscheinlich auch so, dass es ein Blogpost von Natalie über CV 2019 8646 gibt. Sie hat es geschafft, Springboard dazu zu kriegen, ArtTP-Requests an einen Server zu senden, die Fotos, Daten und so weiter enthielen. Wenn Springbox in einer Sandbox laufen würde, wird das viel schwerer gewesen. Das ist also nicht nur über diesen zweiten Breakout, sondern auch für andere Sicherheitsfunktionen. Sandboxing sollte aber nicht alleine als Sicherheitsbundery, also Sicherheits-Schnittstelle dienen. Schlussendlich etwas wie der NSKID Angreifer Bug würde auch als Sandbox Escape-Möglichkeiten anbieten. Schließlich, dass es in einer Sandbox, wenn der Code für die ganze Zero-Click-Angrifffläche offengelegt wird, wird aber wahrscheinlich nicht. Ein letztes Ding ist, es wäre nicht schlecht, diese Angreiffläche von Null-Click-Angreiffläche zu Ein-Click-Angreiffläche zu machen. Hier am Beispiel von Threema, es ist so, wie es schön, ein Prompt zu haben, wenn man Messages von Sendern erhält, von denen man noch keine Messages bekommen hat. Threema erlaubt es zum Beispiel. Weiter, der Service, der Dienst Neustartfunktion wird wahrscheinlich noch relevanter werden, wenn Speichertagging eingeschaltet wird. Das auch ausgehebelt werden kann, wenn man mehrere Möglichkeiten hat. Wenn ein kritischer Dienst 10-mal abstürzt, wäre es vielleicht nicht falsch, den nicht neu zu starten. Das braucht aber sicher noch ein bisschen mehr jenseits, weil wir wollen auch nicht irgendwelche Funktionen für den Nutzer ausschalten. Wäre aber sicher eine gute Idee, da ein Limit zu haben, damit genau diese Orakel nicht mehr möglich sind. Kommen wir zum Schluss. Null-Click-Exploits sind ein Ding, die sie existieren. Leider. Es ist möglich, Speicherkorruptions-Bugs von Remote auszunutzen, ohne ein zusätzliches Information-Leak für den Nutzer. Wenn man die richtigen Hebel betätigen würde, könnte das deutlich schwerer gemacht werden. Aber wir brauchen sicher mehr Reduktion der Angesfläche, insbesondere bei Null-Click-Angesflächen. Vielen Dank für eure Aufmerksamkeit. Wir haben Zeit für Fragen. Wir haben Zeit für Fragen. Wenn ihr im Raum seid, dann stellt euch bitte an ein Mikro. Und wir haben möglicherweise auch Fragen aus dem Internet. Eine kurze Erinnerung. Alle schönen Dinge funktionieren mit expliziter Zustimmung. Das beinhaltet hier am CCC auch Fotos. Wenn ihr ein Foto macht, dann benötigt ihr explizite Zustimmung aller Leute, die drin vorkommen. Wir haben eine Frage vom Internet. Das Internet fragt, hat Apple dir irgendeine Belohnung gegeben und war es ein neues iPhone? Wir haben keine Art von Belohnung bekommen, aber das wollten wir auch gar nicht. Ich habe kein neues iPhone bekommen. Ich benutze immer noch Mainz. Das ist ein T-10S. Heute hat man Models. Heute hat man Models. Das kann damit bezwungen werden, wenn das die Frage ist. Eine Frage von Mikro 3. Hallo. Ich habe nur eine Frage. Ich habe nicht wirklich verstanden, wie der Fix im Prozess die Leserbestätigung vom Server senden würde von einem anderen Prozess. Wenn du die richtige Adresse erwischst, dann funktioniert das Ding. Wenn es funktioniert, dann würde man die Sendebestätigung weiterhin erhalten und sonst nicht. Auf diese Art schicke ich diese eine Nachricht, die crasht. Dann bekomme ich entweder eine Lieferbestätigung oder nicht. Wenn der Server die Lieferbestätigung schickt, bevor er sie an das iPhone weitergibt, dann kriege ich immer eine Lieferbestätigung. Deswegen könnte ich nicht herausfinden, ob meine Nachrichten einen Crash auslösen oder nicht. Das wäre die Idee dahinter, aber die Frage ist dann, werden dann richtige Leute eine Nachricht schicken und die kommt nicht beim Empfänger an, dann, ja genau, das ist ein Hack, das nicht perfekt. Und der Server könnte einfach nur diese Bestätigung schicken, nachdem sie herausgeschickt worden sind über TCP-Acc oder so. Was im Kernel passiert, aber das ist ein Hack, das stimmt schon. Das ist ein Kompromiss. Wir haben eine Frage von Mikro2. Hallo. Danke für den Talk. Zwei Fragen. Erstens, ist OS X auch ein Kandidat für diesen Buck? Und zweitens, kann man verschiedene Geräte auseinander unterscheiden mit dem RSLR Bypass? Also, Meco ist auch davon betroffen, genau dieser spezifische Exploit würde genauso laufen, weil der Adressraum ein bisschen unterschiedlich aus, aber man könnte das definitiv zum Laufen bringen und es auch effektiv besüglich verschiedene Devices. Damit habe ich nicht rumgespielt, aber ich könnte mir vorstellen, dass es möglich sein könnte, dass es verschiedene Devices sind und wer das Device gerade gecrashed ist, aber das habe ich noch nicht untersucht. Danke. Wir haben immer noch Zeit für mehr Fragen und eine von Mikro1. Danke für den Talk. Kurze Frage. Du hast gesagt, dass der Exploit ohne irgendeine Notifikation ausgeführt werden kann. Wie würde das aussehen? Das habe ich mir kurz angeschaut, wie das funktionieren könnte. Also, zum einen kann man Teile der Nachricht herausnehmen, sodass sie nicht geparst werden kann beim Prozessieren und dann wird sie einfach weggeworfen, weil es davon ausgeht, dass es Mülldaten sind. Und die andere Sache ist, dass sobald du die letzte Nachricht kriegst, sobald du der Codeausführung kriegst, kannst du Notifications am Zeigen hindern, weil das ja danach passiert. Das heißt, bevor du Codexikrischen kriegst, kannst du die Message nicht... Danach kann man dann... Dann kann die Nachrichten dann schlecht aussehen, sodass die Parsing-Stufe dann fehlschlägt. Wir haben noch ein paar Fragen. Wenn ihr euch nicht hinter ein Mikro stellen möchtet, dann könnt ihr über das Internet fragen. Mikro4, bitte. Hi. Du hattest ein paar Vorschläge, um die Angriffsfläche zu verkleinern. Auch Vorschläge, die du Apple oder Google empfehlen würdest, damit zu machen, was die sehen können. Logging irgendwas in die Richtung. Ich habe die Liste dieser Explosion Apple geschickt und der Blog-Post hat auch noch ein bisschen mehr Informationen. Aber ich habe Ihnen genau diese Sachen gesagt. Wie einfach war das die Frage? Hab ich das richtig verstanden? Aber einige dieser Reduktionen in der Angriffsfläche schienen auf dem Gerät zu laufen. Und ich habe mich gewundert, ob es irgendeine Monitoring-Stufe beim Anbieter geben könnte. Ja, das ist sehr schwer wegen der End-zu-End-Verschlüsselung. Das heißt, der Server sieht immer nur verschlüsselten Mühe und hat keine Art und Weise zu wissen, zu wissen, ist das ein Bild, ist das Text, ist das ein Exploit. Das heißt, auf dem Server glaube ich nicht, dass man viel machen kann da. Ich glaube, es muss immer auf dem Device sein, im Endeffekt. Und eine Frage aus dem Internet. Wie geht man mit Angriffsflächen-Mapping um? Reverse-Engineering. Rumspielen, das Message-Format ansehen. In diesem Fall war das relativ offensichtlich, wo die Angriffsfläche ist. Es gibt einfach nur die verschiedenen Schlüssel dieser Nachricht, herausfinden, und wie die verarbeitet werden. Dann anschauen, wer am kompliziertesten aussieht und denen zuerst angreifen. Das haben wir im Endeffekt gemacht. Eine Frage von Mikro 2. Hallo. Wie lange haben du und deine Kollegin daran weitergeforscht, bis es lief? Also, das herausfinden, der Dings war, dass sie ungefähr drei Monate darauf verbracht. Und die Ausnutzung dieser Verwundbarkeit. Da hatte ich schon so eine ungefähre Idee, wie ich diese Ausnutzung angehen wollte. Das heißt, das hat mich ungefähr eine Woche gebraucht. Aber ich hatte da schon sehr lange darüber nachgedacht, während wir die Verwundbarkeiten immer noch gesucht hatten in den vorigen zwei bis drei Monaten. Eine Frage von Mikro 3. Es gibt eine Bedrohung, dass das Angriff von einem iPhone in einem Angriffsgerät umgewandelt werden könnte? Natürlich, das kann man machen. Du hast die volle Kontrolle. Das heißt, du hast Zugriff auf die Kontakte und du kannst ein Message heraus schicken. Die Frage ist, ist es notwendig. Also, weil du kannst ja diese Nachrichten von ... Du brauchst keine iPhone, um diese Nachrichten zu schicken. Aber ich glaube, theoretisch wäre das möglich. Haben wir noch Fragen aus dem Internet? Bleibt das Telefon nach dem Restart kompromittiert? Nein, da ist keine Persistenz in diesem Exploit. Da habe ich gerade von der Stunde auch ... Hat jemand darüber gesprochen? Das heißt, da müsstest du diesen Exploid von ihm ... weiter benutzen. Wenn ihr Fragen im Raum habt, dann stellt euch Peter ein Mikro. Haben wir noch etwas aus dem Internet? Ja. Du hast den interessantesten Bug in iOS gefunden. Was ist das Nächste, an dem du arbeiten wirst? Gute Frage. Ich kenne mich nicht wirklich selber, aber ich glaube, ich werde bei diesen Zero-Click-Angriffen noch ein bisschen bleiben und deren Reduktion ... ... mit tapferen Leuten im Raum, hat das Internet mehr Mut? Wie lange geht das ... ... das Entdecken einer Verwundbarkeit? Und wie läuft der Prozess ab? Also, die Frage ist, wie lange braucht dieser Ausnutzungsprozess? Ja, das ist generell schwierig zu beantworten, weil da gibt es ja Reihare am Rumhacken und Lernen und so weiter, die man eigentlich bedenken muss. Aber wie ich gesagt habe, ich hatte schon so eine ungefähre Idee, wie dieser Exploit aussehen könnte. Und dann war das die Implimentation nur noch ein, zwei Wochen. Der erste Teil, also, ein Message, reverse zu engenieren und den NSKeed Anarchiver zu reverse engenieren, das hat sehr viele Monate gebraucht und war sehr notwendig, um diesen Ausnutzung, diesen Exploit zu schreiben. Das heißt, diese Exploit Primitives, die wir benutzt haben, die verunstalten auch den NSKeed Anarchiver. Wir haben vielleicht zwei kurze Fragen von Mikro 4. Ich bin nicht besonders vertraut mit IOS's virtuellen Adressraum. Du hast zwei Hybrigionen gezeigt und ich habe mich bewundert, wieso gibt es zwei davon? Okay, das ist nur ein kleines Detail, aber ich glaube, es gibt initial eine Hybrigion, die unterhalb des Shared Caches ist und wenn der dann voll ist, der Shared Cache, dann macht er noch eine zweite Hybrigion, ue oberhalb des Shared Caches. Und deswegen, wenn die eine dann komplett ihren Platz verbraucht, dann gibt es halt eine zweite, und die ist dann ue oberhalb des Shared Caches. Das ist, glaube ich, das Bild, das du gemeint hast. Das war die deutsche Übersetzung von Messenger Hacking Remote iPhones über iMessage kompromittieren von Samuel Groß vom 36. Chaos Communication Congress. Euer Übersetzer war...