 So, zusammen willkommen zu meinem Talk, Fuzzing the Phone in the iPhone. Das Telefon im iPhone nimmt Anrufe entgegen, bekommt die SMS entgegen und ist auch für die Internetverbindung zuständig, wenn ihr nicht gerade im WLAN seid. Das generelle Fuzzing, wie ich machen werde, ist wahrscheinlich ein bisschen schwer zu verstehen, für die meisten von euch. Ich werde also ganz zu Anfang anfangen, was Fuzzing ist, was der Basement ist usw. Also alle für euch, die doch nicht das mit dem Konzept von Fuzzing vertraut sind, im Endeffekt schickt man da einen ganzen Haufen an zufälligen verschiedenen Messages an einem bestimmten Interface und völlig zufällig und schaut raus, was dann zurückkommt. So in dem Beispiel haben wir das mit zwei Phonen gemacht, wir schicken also etwa 400 Messages pro Sekunde rüber und machen, was passiert. Warum machen wir das Ganze und schauen wir uns erst mal das Angreifermodell an. In einem modernen Telefon gibt es zwei verschiedene Hauptkompetenzen, es gibt zum einen die Hardware mit vielen, vielen ICs und da drüber ist dann das Betriebssystem, die Software und viele, viele Anwendungen. Aber in der Praxis ist es nicht ganz so einfach, weil die selbst die ganzen ICs so kompliziert sind, dass sie selbst ihre eigenen kleinen Betriebssysteme haben, um die da zu probieren. Das heißt, man hat Code Execution sogar auf diesen einzelnen Chips Programme, die ausgeführt werden, kleine. Die also auch entsprechend geschützt werden müssen. Was macht man also, wenn man in solchen Chips Codes ausgeführt wird, wenn man in einem Base Chips ist, wie kommen wir davon weiter bis in den Betriebssystem rein? Das Einfachste wäre dann beispielsweise in den Brunnen, da hatten einfach zwei Ändern, wie sie im Räuer kommen, aber brauseich Leute sind sowieso schon ziemlich selten. Von daher gucken wir uns zu dessen einen anderen Weg an, wie wir direkt ins Betriebssystem kommen. In general, der Trafikmanipulation ist generell den Datenverkehr zwischen zu manipulieren, ist etwas, was man auch generell machen kann außerhalb des, also man kann es im Internet machen, man kann es im Kernnetzwerk machen und gibt viele, viele Wege, diesen Datenverkehr zu verändern, zu manipulieren. Insbesondere, wenn man gleich ein ganzer Stand ist, ein State Level Actor, man kann Websites modifizieren auf dem Bitenden, es gibt das Subsystem von Basisstationen, Mobilfunkbasisstationen, die man angreifen kann und natürlich während die Daten über die Lufs unterwegs sind, also per Punkt unterwegs sind und wenn es auch nur den kleinsten Problem in der Verschlüsselung der Übertragung gibt, dann kann man natürlich auch die Verschlüsselung selbst anbreifen. Und für alle auf das braucht man eigentlich keinen Baseband-Exploit, da gibt es wesentlich okayere Sachen. Es gibt auch zwei weitere Talks über Eingriffe auf das SS7-Protokoll, das Kernnetzwerk, das die verschiedenen Mobilfunk-Probeite miteinander verbindet. Das kann man zum Beispiel auch nutzen, um Anrufe abzufangen, Anrufe zu belauschen und endlich mit Daten. Das sind Eingriffe, die kürzlich durchgeführt werden und man benutzt es speziell um Leute auszuspionieren. Also für all das brauchen wir keinen Baseband-Exploit, Baseband-Exploit braucht man also im wesentlichen, um in das Betriebssystem reinzukommen. Frage also, was sind also die besten Strategien hier? Wenn wir es also nicht über den Browser machen, was sonst können wir noch machen? Also sprich, wir müssen uns auch mal über die Sprich, wir müssen also nicht in den Verkehr zur Webseite rein, es muss also etwas anderes geben. Wenn wir also Remote Code Execution in Chips haben und wollen das Betriebssystem, gibt es da ein Interface. Und wir müssen also gucken, was in diesem Interface wirklich ausgenutzt werden kann, gehackt werden kann, explodiert werden kann aus diesem Chip. Die Interfaces sind also auch aus einer Reverse-Engineering-Ferspektive sehr interessant. Wenn wir also einfach nur rumschauen wollen, schauen wollen, wie das Ganze funktioniert. Wenn wir also einen Sprechenden, wenn wir also praktisch in unser iPhone-System rein gucken, dann sehen wir da bereits viele, viele Messages, die ausgetauscht werden in iPhone und den Base on Chips. Und wenn wir praktisch da rein kommen, dann können wir also diese Messages, die Datenpakete auch manipulieren, verändern, um da reinzukommen. Wenn man also an so etwas arbeiten will, ist also die Frage, wie kann man überhaupt an? Und eine Methode, die da genutzt werden kann, ist phasing. Also wenn wir erstmal ein Interface identifiziert haben, müssen wir erstmal prüfen, ob das tatsächlich das Richtige ist, dass wir suchen. Also können wir zwar schon ein paar Beispiele ändern, gucken, was sich ändert. Und können prüfen, ob dann irgendwas, wenn etwas nicht so ist. Wenn was gucken macht, können wir gucken, ob das vielleicht ein Sicherheitsproblem darstellt. Also wir gucken uns jetzt als nächstes Phasing für Draht und für Punktprotokolle, Datprotokolle an und da werde ich auch gleich ein bisschen meckern müssen. Also ein Phasing. Also wir haben ja einen einfachen Bildformat Phaser und wir gucken uns den also aus einer Phasenperspektive an und schauen, welche Funktionen da ausgeführt werden. Wir können das also praktisch mit vielen verschiedenen Bildern durchprobieren und gucken, welche verschiedenen Routinen da ausgeführt werden. In seinen Images können wir verschiedene Bilder, hier in dem Fall, mischen, modifizieren und so weiter. Wir werden feststellen, dass in den meisten Stellen die gleichen Routinen wie vorher ausgeführt werden. Aber in einigen Fällen werden wir tatsächlich feststellen, dass wir tatsächlich in den Image-Parser-Code in neue Stellen rein springen. Und das wird das Ganze dann interessant. Eine andere Methode kann sein, wenn wir nicht so genau wissen, wie ein Dateiformat aussieht. Zum Beispiel nicht genau wissen, wie die JPEG-Spitifikation aussieht. Wir nehmen also dann eine große Menge Bilder, die mehr oder minder in Ordnung sind, also den Standardkonform sind. Wir fahren sie da durch, einen Mann schicken sie ein Image-Parser ab und zu. Wir stellen fest, dass das Ganze kräft. Und dann merken wir uns an, bei welchen Bilden tatsächlich diese beiden Methoden können wir dann ganz auch kombinieren, je nachdem, was für eine Sorte von Input wir haben und wie unser Ziel aussieht. So, wie sieht das Ganze für einen Protokoll aus? In deinem Protokoll aus haben wir vielleicht sehr, sehr komplizierte verschiedene Status haben. Zum Beispiel können wir uns mitten in einem Telefonanruf befinden. Und in so einem Fussing können wir vielleicht einzelne Bits oder Bites ändern. Und dann hätten wir eine entsprechende Modifizierung. Das ist also ein sehr einfacher Anfang. Es ist sehr einfach, einfach mal ein paar Bits zu ändern, was sie ändert, aber das Ganze ist auch sehr énervierend, weil man das Ganze während echter Telefonanrufe oder SMS oder so bekommen muss. Eine andere Methode ist die Injektion. Wir beobachten also tatsächliche Messages und dann schicken wir die gleichen Messages in Leichmultifiziert nochmal, mit Änderungen und Änderungen und Änderungen und gucken uns, was dann tatsächlich passiert ist. Das Problem ist hier, dass wir keinen Zustand uns merken. Das heißt, das iPhone kann sich vielleicht ein Datum anfragen, aber das dann antwortet der Gip nur dann mit einem Datum und dann verarbeitet das Datum. Aber das ist immer noch sehr interessant. Wir können bestimmte Zustände nicht erreichen ohne SIM-Karte oder so, aber man kann das immer noch sehr schnell machen. Um die Probleme also zusammenzufassen, wenn man dieses Protokoll fasst, dann gibt es sehr viele verschiedene Zustände und nur mit initiierten Paketen kann man nicht alle Zustände erreichen. Das zeigt sich auch in sehr einfachen Sachen wie ein Trace-Replay, also wenn man das wieder abspielt, ich habe einen Telefonabendrupp-Foof und ich zeichne alle Pakete auf und ich kann auch die Coverage aufzeichnen auf dem iPhone, welche Code fahre ausgewertet und welche nicht. Und im zweiten Schritt würde man dann Pakete wieder einspielen, aber das Einzige, was man wieder einspielen kann, sind die Pakete zu dem Smartphone, nicht die andere Richtung und dann kriegt man immer also viel weniger Abdeckung im Code. Man kriegt wegen diesen fehlenden Zuständen und wenn man das nochmal macht, dann ist man vielleicht in einem anderen Zustand und kriegt nochmal andere Abdeckungen. Man macht das genauso gleiche zwei Mal, aber kriegt unterschiedliche Abdeckungen, das ist das Schlimmste. Das heißt, selbst wenn wir aufgezeichnete Nachrichten wieder abspielen, kriegen wir nicht die gleiche Abdeckung. Schauen wir uns mal ein Beispiel solcher Injection an. In diesem Video seht ihr, wie ich in dem Unicorn-Netzwerk mit einem iPhone 8 bin. Es hat natürlich 5G und wir machen sehr viel Fuzzing. Und was da interessant ist, ist, dass man vielleicht viele Zustände abklappert in einer Kondition, die eigentlich nicht möglich ist. Man hat vielleicht Netzwerkverbindungen verloren, während man eine Pin bestätigen muss oder andere Sachen. Um das Merkant zusammenzufassen, einige Zustände kann man nicht erreichen, nur indem man Pakete initiiert. Das heißt, selbst wenn wir einen sehr guten Corpus an Eingaben haben, dann verpassen wir vielleicht immer noch 80% vom Code, aber wir können trotzdem fassen. Wir müssen nur im Kopf verhalten, dass wir nicht alles fassen können. Wir haben bei SEMO andere kamlose Protokolle angeschaut und wir hatten einige Werkzeuge zum Fuzzing bereits. Das fortgeschrittene heißt Frankenstein. Und was Jan gemacht hat, ist, die Firma zu emulieren und an einen Delegthaus zu verbinden. Und das hat er erst die Firma angeschaut. Und da waren einige Symbote bekannt und auch einige Informationen über Register. Und dann nehmen Frankenstein einen Snapshot, eine Momentaufnahme mit einigen dieser Register des Modems. Und damit kann man dann ein virtuelles Modem bauen und die Eingabe fassen, als ob sie tatsächlich über Funk einkommen würde. Und da wird auch die Firma emuliert, mit infosive mehreren Threads zwischen denen gewechselt wird. Und das ist sogar an ein Linux Host angebunden. Das heißt, Linux wird auch ein bisschen gefasst damit, während die Firma eigentlich gefasst wird. So, auch das Problem damit ist, dass die Basement-Firma größer ist wie die Bluetooth-Firma oder noch größer. Und wir haben gar keine Symbole davor. Das heißt, es ist viel Arbeit, das zu konsumisieren. Und selbst wenn man das alles machen würde und die ganze Arbeit nicht machen würde, dann könnte man nur sagen, wir hätten Codausführung im Baseband, wir hätten noch nicht Privilegien im Betrieb zu sehen, was drüberlegt. Das nächste interessante Werkzeug hat Steffen gebaut. Und Steffen hat ein Buzzer gebaut, basierend auf D-Trace und AFL. D-Trace ist ein Werkzeug, das Abdeckung auf dem Funktioneimble im Mac OS Kernel anbietet. Und man kriegt auch etwas Blockabdeckung auf im User Space. Man hat also zusammen mit AFL oder AFL++ als Fuzzer, das kann man auf jedes Programm im Mac OS anwenden. Das ist etwas schneller als Frieda, zumindest schneller als die, die er erfüllend hat. Und man kriegt ein paar Tausend Fälle pro Sekunde, selbst auf einem ziemlich alten iMac. Das heißt, in unserem Labor hatten wir einen alten iMac 2012 dafür. Und das hat da funktioniert. Aber das Problem ist, man hat Bluetooth und Wi-Fi. Er hat Bluetooth gefasst und das Produkt ist sehr unterschiedlich. Er hat also keinen neuen Fehler mit AFL gefunden. Und im Kernel Space hat man auch nur diese Abdeckung auf der Funktionsebene. Er hat aber trotzdem, obwohl er keine Bugs in Wi-Fi, WLAN oder Bluetooth gefunden hat, er hat eine CVE bekommen, weil D-Trace Bugs hat. Also irgendwas ist, haben wir zumindest dabei ausgekommen. Auf iOS geht das nicht abwärkt. Man könnte es vielleicht zu funktionieren bringen mit etwas Arbeit, aber es wäre viel Arbeit. Aber vermutlich ist es einfacher, einfach Frieda im iOS User Space zu verwenden. Währenddessen, weil Jeff'n das alles zusammengebaut hat, hat Wang Yu Probleme im Mac OS, Bluetooth und WLAN-Tribe gefunden und war da sehr erfolgreich, um vielleicht zu uns. Das ist wirklich schade. Ich glaube, was er gemacht hat, ist viel besseres Zustandsmodellierung. Also wie die Nachrichten miteinander interagieren und was wichtig ist, um bestimmte Funktionen zu erreichen. So, was bleibt noch übrig? Normalerweise heißt Fasen, das Basemand Fasen, dass man die Firmware modifizieren muss oder die Firmware emulieren muss. Man muss sehr komplizierte Spezifikationen über Software Defined Radio wenn man tatsächlich mehr Funke fassen will. Wenn irgendetwas profitär ist, dann muss man das Protokoll reverse-engineieren und da kann man insgesamt sehr viel Zeit und Geld verspenden, um nur sehr einfache Forften zu betreiben. Oder man kann Frieda verwenden und damit fassen. Und alles, was man dafür tun muss, ist ein paar Zeilen Code in JavaScript zu schreiben. Also kein Schatz. Frieda. So, Dennis war der erste in unserem Team als Student, der ein Faser basierend auf Frieza gebaut hat. Frieda. Und das heißt Toothpicker. Und es hängt sich in diese Verbindungen in die Protokolle des Bluetooth-Demons rein. Man kann sich das den oberen Teil vorstellen als ein Block. Das heißt, die Protokolle sind in dem Bluetooth-Demon implementiert, aber wir wollen die bestimmten Protokolle-Händler fassen. Und um die Abdeckung zu erhöhen, stellt er eine rituelle Verbindung und spielt den Bluetooth-Demon vor, dass es eine Verbindung zu einem Gerät gibt. Und der Chip sagt dann, ich kenne die Verbindung nicht. Das heißt, da ist auch etwas Abtraktionen in der Inne, damit die Verbindung nicht abgebrochen wird. So, das ist ein ziemlich einfaches Tool, aber es hat viele Probleme gefunden und es gab sogar einige Probleme in den Protokollen selbst, die sich auch auf macOS beziehen, also nicht nur iOS-Box, sondern auch in macOS hat Dennis damit gefunden. Und das hat mich zum Überlegen gebracht. Das hat funktioniert nur mit 20 Fahnen pro Sekunde, aber wir haben immer noch Bluetooth-Probleme mit dieser Geschwindigkeit gefunden. Warum? Zuerst, wenn man Bluetooth über Funk tatsächlich fassen will, dann werden diese Verbindungen nach fünf oder so ungültigen Paketen abgebrochen. Das heißt, über Funk zu fassen ist sehr ineffizient. Mit Frieda kann man diese Funktion rauspatschen, damit sie weg ist. Und dann sind die virtuellen Verbindungen auch sehr wichtig. Es sind sehr, sehr wichtig, um die Abdeckung zu haben. Wir verpassen immer noch sehr viel Abdeckungen mit diesem Fasing, aber es ist ein großer Vorteil, verglichen mit diesen anderen Ansätzen zu fassen, wo man nur Pakete initiiert. Und es gibt auch ein Problem hier, wenn man eine virtuelle Verbindung hat, kann es sein, dass die virtuelle Verbindung Verhalten auslöst, dass man über Funk gar nicht auslösen kann. Das heißt, alles, was man findet, muss man noch mal bestätigen, dass es auch über Funk tatsächlich funktioniert. So, zumindest die inkonsistente Abdeckung ist in Two Thicker auch behoben, weil Two Thicker alles fünf Mal in Folge macht. Aber das Problem ist, wenn man eine Reihe von Paketen hat, die einen bestimmten Back produziert mit mehreren Paketen, ist das nichts, was dieser Mutator kennt und nichts, was man direkt in Two Thicker hat. Und aus diesem Grund hatte ich ein bisschen Sorgen, vielleicht haben wir da sehr viel verpasst, das heißt, soweit ich den Eindruck hatte, dass wir bestimmte Zustandinformationen verpassen, hatte ich die Idee, dass wir in aktiven Verbindungen bestimmte Bytes verwenden. Das ist ein Faser, den ihr auf der Tastatur Eingabe ersetzt und gesehen, was passiert. Also, ich habe das ein paar Wochen laufen lassen, auch mit verschiedenen Protokollen, um zu sehen, ob es da mit anderen Protokollen entsprechende Schwierigkeiten gibt, ob es Fehler gibt. Hier seht ihr das Gleiche mit Airpods. Ihr hört da ein paar Knacker, und bei Musik würden man ziemlich gute Geräusche hören. Ich habe es also ein paar Wochen laufen lassen, aber es hat keine Bugs gefunden, die Two Thicker vorher nicht auch schon gefunden hat. Und ich glaube, dass nicht daran, dass das, weil wer nur diese paar Verbindungen hatten und jede diese Verbindung, muss ich praktisch alle von Hand erst mal fairen müssen. Alles, was ich machen konnten, was ich erreichen konnte, ist, dass die Tonqualität meiner Airpods ziemlich ziemlich schlecht ist, aber das ist kein entsprechender Sicherheitsmeldung wert. Aber das kann man immer in Arbeitsspeicher schreiben können, aber da gibt es auch entsprechende andere Methoden. Also nach all dem habe ich gefragt, was ist jetzt tatsächlich noch übrig für Fussing, wenn wir noch nicht mal ein Bluetooth-Bass finden? Und was haben wir da? Und da haben wir das iPhone-Bassband oder genau gesagt die iPhone-Bassband, von da gibt es nur nicht zwei. Es ist über die Qualcomm-Chap. Die sind im Wesentlichen in den Geräten, die in den USA verbreitet sind. Es nutzt das Qualcomm-MSM-Interface und das ist ganz gut dokumentiert. Da gibt es sogar Quellcode-Dokumentationen. Also einfach zu verstehen und einfach auszuwerten. Andererseits fast allen Geräten, die wir hier auf meinem Tisch hatten, gibt es Intel-Chips und wobei genau gesagt sind es davon einige Teil jetzt bei den Baseband-Chips von Apple übernommen wird. Das ist also das praktisch alle Geräte, die in der EU verbreitet sind. Die nutzen ein spezielles Protokoll namens Apple Remote-Invocation und es gibt praktisch keine Informationen darüber im Internet. Ich habe es heute nochmal überprüfen, praktisch nichts auf Google. Es gibt also keine öffentliche Forschung darüber. Es ist praktisch komplett dokumentiert und es wird praktisch nur von Apple selbst verwendet. Die Komponenten, die wir uns also angucken und pausen werden, ist genannt, wird genannt Kompcenter. Das ist also praktisch das equivalent zum Wi-Fi-Demon, aber halt für Telefonie. Es ist in einer Sandbox. Aber es hat eine ganze Menge XPC-Interfaces. Die nächsten Teil, den wir haben, ist, dass es da so zwei verschiedene Sorten von Libos gibt. Je nachdem, welcher Baseband-Chip verwendet ist, verbaut ist und dementsprechend werden unterschiedliche Libos verwendet. Deshalb müssen wir verschiedene Code-Fahde untersuchen. Alles davon läuft allerdings im User-Space. Das heißt also, dass praktisch in beide Libos reinkneppen können. Es gibt immer noch eine ganze Menge, dass das im Körner stattfindet. Aber es gibt so ein paar Management-Informationen, die nach Kompcenter verwendet werden, aber es gibt praktisch nicht die RO-Daten, die RO-Netzwerk-Daten, die RO-Audiodaten, also praktisch nicht über das Telefongespräch oder die Webseite, die ihr aufmacht. Das ist tatsächlich drin. Und das letzte ist, die sind nicht direkt darüber über Funk verwendet, sondern praktisch das läuft entsprechend über das islamante R-Interface. Es gibt immer noch jede Menge Interaktionen zwischen den beiden. Das heißt, bestimmte Messages nach QMI und AI werden darüber verwendet. Aber das heißt, je nachdem wie eure Exploitschein aussieht, kann man entweder direkt vom R-Interface in die Libos reinkommen oder man muss erst die Basebandsoftware knacken und von da aus dann weiter in die Libos ist. Also der Code von QMI hat viele viele Assertions. Also alles, was das Protokoll betrifft, die Paketlängen, Protokollversionen usw., werden alle über Assertions geprüft. Das heißt, sobald etwas falsch drin ist, wird sofort Common Center abgebrochen. Terminiert und heilt. In der Praxis heißt das, wenn das Protokoll vollivaliert ist, dann macht das keinen Unterschied. Aber wenn ein Angriff stattfindet, dann bricht es sofort ab. Das heißt, in Praxis werden also tatsächlich eine Angriff stattfindet, mit dem stimmt der Fall, da der Anruf verloren geht oder die Internetfamilie kurz zusammen bricht. Im Gegensatz dazu, beim AI Protokoll ist ein Parter der komplett unterschiedlich funktioniert. Also was immer es kommt, es versucht es zu parten, es bricht Common Center nicht ab. Das heißt, man kann viele komische Dinge schicken und es pass und pass und pass vermutlich, weil die ganzen Entwickler davon froh waren, als es einmal funktioniert hatte, als einmal das tatsächlich Protokoll passen konnte und danach nie wieder angefasst hat. Aber was heißt das jetzt? Es hat ein sehr wundlegendes Format und als ich das erste was ich gemerkt habe, was es gefasst hat, war, dass es das Block hatte, sich immer beschwert, dass die Sequence Nummer falsch ist. Das heißt, ich habe als erstes mal geguckt, dass ich die Sequence Nummern richtig hinkriege. Also anscheinend erwartet im Bereich von 0 bis 7, 7 Effekterdissimal und danach fängt an, komisch zu werden. Das heißt, die Sequence Nummer in verschiedenen Bits und nicht fortlaufend und das sieht alles aus, als hätten sie diese Sequence Nummern zugefügt, um eine bestimmte Waste-Condition zu vermeiden. Keine Ahnung, was da passiert ist. Ich habe also den Entschuldigen Code geschrieben, ich habe die Sequence Nummer richtig hingekriegt und dann in dem Replay habe ich festgestellt, eigentlich braucht man das gar nicht. Selbst wenn die Sequence Nummer falsch ist, dann wird weiter ausgeführt, passt der Pasa weiter, egal ob die Sequence Nummer richtig oder falsch ist. Es gibt also ein paar andere Probleme noch, wenn man die ersten vier Magic Bites falsch sendet oder dann sieht so aus, als würde das Paket im Endeffekt zwar ignoriert wird, aber erst nachdem es gepasst wurde. Da es ein Propektiasprotokoll ist, kann man nicht wirklich brauchen, aber Tobias arbeitet gerade in einem entsprechenden Wireshark-Modul. Das heißt, in Wireshark werdet ihr dafür bald ein entsprechendes Tool haben. Schauen wir uns also an, was passiert, wenn wir das passen. Ich rate euch davon ab, das mit eurem Gerät zu machen. Und insbesondere nicht an dem iPhone, was ihr das nicht benutzt, weil ihr wahrscheinlich sehr viel kaputt machen könnt. Ich dagegen weiß genau, was ich mache. Ich fahre so einfach auf Pakete, aber so genau weiß ich dann doch nicht, was ich tue. Also die einzige Richtung, die ich mir angucke, ist die Richtung vom Paket zum iPhone. Aber ich fahre so nicht die Antworten vom iPhone zum Baseband. Damit ich mir beim Baseband-Shift nicht zu viel komische, nicht zu viel kaputt mache. Aber es kann immer noch passieren, dass aufgrund von merkwürdigen komischen Antworten des iPhones da immer noch was kaputt geht. Also ich habe also anscheinend auf die Art und Weise trotzdem ein iPhone zu bricken. Aber ja, also auf Qualcomm-Sips habe ich es geschafft, in Bootloop zu kommen, nach ein paar Stunden auf dem Intel iPhone habe ich es beinahe gebrickt, aber nicht komplett. Das Problem hier ist, wenn man das Baseband-Debut-Probe irgendwie aktiviert, dann schreibt es sehr, sehr viel in die ICDP, also in die entsprechende Debaktformate von Intel rein. Und alle paar Minuten erstellt es noch mal neue 500 Megabyte-Lockdaten. Und wenn man das also nicht regelmäßig löscht, dann wird die Disk sehr, sehr schnell schon voll. Und ein iPhone benimmt sich sehr, sehr merkwürdig, wenn der Speicher fast voll ist. Man kann es anscheinend zu verwenden, aber viele Dinge funktionieren dann nicht mehr. Man kann nicht mehr PSSA einlocken, was es für mich durchaus ein Problem ist. Man kann also daher also noch nicht mal irgendwelche Dateien wieder löschen. Als das einzige was ich noch machen konnte, war das iPhone Neuboden. Dabei wurden ein paar Dateien gelöscht und dann kam ich dann doch wieder da dran. Also sprich, wenn ihr das probiert, seid vorsichtig. Und praktisch sie setzen sich dann sehr stark auf seinen Smartphone zurück. Ihr seht hier ein Smartphone, das wirklich, wirklich aktiviert werden will. Und während dem SMS-Fashing kann man vielleicht sogar Flash-Nachrichten kriegt. Wenn man auf die Hilfenachricht kriegt, dann ist es irgendwie schwarz auf Graus, hat wahrscheinlich nie jemand getestet. Und wenn man ein gesperrtes iPhone hat, kann man immer noch diese 7 Menüs und 7 Nachrichten zeigen über der Sperre. So, das heißt, ich muss mich etwas korrigieren. Fast das. Gerne. Wirklich. Es macht sehr viel Spaß. Vielleicht nicht auf eurem Haupt-Handy. Aber es wird euch Spaß machen. Aber zuerst müsst ihr natürlich einen Faser bauen. Wie baut man sich so eine Software? Den ersten Faser, den ich verwendet hab, ist der erste, den ich für Bluetooth verwendet hab. Ich verwendet die bestehenden Byte-Stream-Protokolle und dann ändert einzelne Bits und Bytes. Das heißt, es hat, es kennt sich sehr über den Zustand aus, aber das musste auch mich selber anrufen, SMS schreiben, Flugmodus anschalten, alles was man sich vorstellen könnte. Das ist einfach sehr langweilig. Aber es hat auch sehr interessante Probleme gefunden, die ich mit den anderen Fasern noch nicht gefunden hab, weil es Zustände erreichen kann, nur indem man Paket erschickt. Das heißt, es war zumindest sehr erfolgreich. Und ich hab damit so 3 Tage oder so lange gefasst und das hat schon Probleme gefunden. Das ist sehr unterschiedlich als beim Bluetooth-Faser. Das heißt, es scheint in Common Center mehr Bugs zu geben. Dann hab ich Apple also geschrieben, hey, ich hab diesen sehr hässlichen 10-Zahlen-Code-Faser gefunden. Schaut mal, was ihr gefunden hat. Ist das nicht toll? Und hier habt ihr die Crash-Logs. Und das ist natürlich einfach zu reproduzieren, weil ich nur 3 Tage gefasst hab und hab die meisten von diesen Abstürzen mehrere Male gekriegt, also hier bitte schön, ihr habt hier meinen Faser. Und das war vermutlich ziemlich dumm. Es ist nicht wirklich so einfach. Also es ist nicht so einfach diese Abstellungen zu reproduzieren. Zuerst ist das Skript so generisch, dass es mit auf allen iPhones mit einem Intel-Trip funktioniert. Das heißt, ob ich jetzt ein iPhone 7 11 habe, es funktioniert. Aber die Absturz-Logs, die ich habe hängen, sind sehr unterschiedlich, je nachdem, ob es vor iPhone A12 war, also iPhone 7 8 oder iPhone 11 oder later. Das heißt, man kann die gleichen Logs nicht so einfach reproduzieren. Und es hängt auch sehr von der SIM-Karte ab. Das heißt, selbst auf einem passiven iPhone, wenn man keine aktiven Anrufe tätig, kriegt man unterschiedliche Ergebnisse. Ich habe also mein Passiven mit einem einzelnen SIM-Karte angefangen, die gar keinen Telefonvertrag hatte oder darf vertragen und habe schon einige Sachen gefunden. Aber es verhält sich vielleicht sehr anders mit nur leicht anderen Konfigurationen. Jetzt hören wir uns einen Null-Pointer an, den es gewohnt hat und der wurde in iOS 14.2 gefixt. Das heißt, ihr hört jetzt eine Schleife, die da drin ist. Was ihr seht ist, ich rufe die Deutsche Telekom an und wir haben diesen Text Guten Tag und herzlich Willkommen beim Kundenservice der Telekom. Und dann rufe ich nochmal an und habe einen Absturz und jetzt hören wir uns den Absturz an. So, nur für den Soundeffekt habe ich auch ein anderes aufgenommen, das hier ist mit AldiTalk. Weil diese ersten Ergebnisse so viel verbrechen waren, habe ich dann entschieden, die neueste Toolfreaker-Version zu verwenden und sie zu erweitern. Und das habe ich dann Icebreaker verwendet, weil die Intelchips auch Ice heißen. Ich habe diesen latest Toolfreaker Alpha ganz stable geklunt und das läuft auf dem iPhone selber ohne Interaktion mit macOS oder Linux, das heißt, es muss nichts über USB austauschen und verwendet auch AFL++, was ein schnellerer Immunator, glaube ich, ist als das andere. Das heißt, das ist ein viel besseres Design aus der FSB, aber AFL++ hat sich nicht als der beste ausgestellt, wie dieses Protokoll. Das heißt, die meiste Zeit hat es damit verbracht, nur die ersten Magic Bytes zu Blutforzen. Es hat sich auch nicht ausgekannt mit Paketreinfolge, das heißt, es hat nur diese ersten 4 Bytes geblutforst. Und das nächste Problem ist, dass aus irgendeinem Grund, als die ersten 4 Bytes und dünftig waren, hat bis der Pause viel langsamer geworden. Das heißt, ich hatte weniger als 6 Stunden und es gab auch es hat sich nicht ausgekannt in Ice Picker mit dem Zustand. Das heißt, Ari macht manchmal dieses Interface aus und der Faser hat es nicht mitbekommen und einfach weiter versucht. Also habe ich in das Log geschaut, nachdem der Faser mehr als 6 Stunden keine neue Abdecken gefunden hat und ich habe mir nicht gefragt, ob ich etwas mit dem Faser fahre und es sieht so aus, als schick der Faser Infos, die einfach nicht geeignet sind. Das kann man natürlich optimieren, AFL++ kann hier viel machen. Man kann eben sagen, so sieht das Protokoll aus und man kann auch als Überzeugung dieser 4 Magischen Bytes nicht zu beforsten, aber dafür ist das ganze Teil neu kompiliert und das hat auf Deniz Maschinen kompiliert, aber auf meinem nicht, weil mein Xcode Beta in einem komischen Zustand war und einige von euch sagen jetzt vielleicht, ja, installiere doch einfach ein neues Xcode, aber es dauert so lange, dass den nächsten Faser zu schreiben einfach erschien. Aber trotzdem diese Version von Ice Picker war interessant für mich, weil es das erste Mal, wo ich gesehen habe, dass die Faser-Initialisierung mit Abdeckung funktioniert und auch, dass mein Replay wieder abspielen mit verschiedenen iPhones Version funktioniert. Also ich habe das auf einem iPhone 2 aufgenommen und auf einem iPhone 7 wieder abgespielt. Es war also nicht nutzlos, aber ich habe mich entschieden diese Konfiguration nicht zu verwenden. Also habe ich einen einfachen Faser geschrieben und ich habe mich alles geportet, das auf iOS selber läuft. Ich habe das Design etwas vereinfacht, dass man es einfacher kogen kann und habe den Faser auf Dienungslaufen lassen und dann Frida auf iOS verwendet. Das kann nicht alle Zustände und Abstürze, die ich mit dem ersten Faser gesehen habe, reproduzieren, aber die meisten Konten reproduziert werden. Ich habe keine Abdeckung gemacht und keine Intelligenz-Mutation, nur sehr grundlegende Mutation und der Injection. Das war aber sehr schnell. Statt den 20 Fan hatte ich jetzt mehr 400 pro Sekunde. Es ist sogar schneller als die iPhone Plus Variante. Und ich kann zumindest die Langfelder und Sequenznummer und so weiter korrigieren, bevor ich das Paket initiere. Es hat keine so tollen Mutation, aber deshalb muss ich zumindest einen guten Koffus sammeln mit vielen Anrufen und vielen Slims und ich muss die Reihenfolge auch aufzeichnen, damit ich das später abspielen kann. Diesen Faser habe ich gegen ein paar iPhones parallel über mehrere Wochen laufen lassen und das hat viele interessante Crashes gefunden. Das ist jetzt also mein Hauptfaser. Ich wollte aber immer noch bestätigen, dass diese Abdeckung nicht zusammen kein Problem war. Also habe ich diesen Publically Release-Toothbacker geklont und der verwendet den Radarm-Summitate, der sehr langsam ist, aber der macht etwas dauerer Mutationen zumindest für Protocol-Fuzzing. Es immer noch kennt nur einzelne Pakete und vielleicht immer geht fünfmal hintereinander, um Abdeckung zu bestätigen und ein anderes Problem ist, dass es viele von diesen Abstürzen von Comcenter nicht findet. Das heißt, es passiert oft, dass Comcenter abstürzt und dann, wenn man den Absturz nicht mit Frieda hat, dann muss man den Faser nochmal starten, aber man muss auch die Dateien und den Koffus, der zu einem Crash gefühlt hat, löschen, sonst findet man den Crash einfach wieder. Das habe ich ein paar Wochen laufen lassen auf einem iPhone 7, hat aber leider keine neuen Crashes gefunden. Das heißt, ich kann zumindest davon ausgehen, dass langsameres Phasen mit Abdeckung keine Verbesserung ist. Aber die Mutationen, die das erstellt hat, waren ziemlich nützlich, wie man es hier sieht. Ihr könnt diese Telefonnummer da das Rollen sehen. Es hat eine sehr lange Telefonnummer korrekt generiert in irgendeiner TLB-Struktur und es ist sehr interessant, das zu sehen. Das könnte man also nicht erreichen, wenn man nur Bits und Bites umkehrt. Ein großes Problem, dass die alle diese Faser haben, inklusive der Two-Spicker vom Anfang, ist, sie haben keinerlei Memo-Tanatisation, das Framework, das sie also nutzen in iOS ist Melox Stack Logging. Ich habe das auch auf Common Center verwendet. Das Problem ist, hier ist, dass es den Speicherverbrauch sehr stark vergrößert. Das heißt, sogar wenn man konfiguriert, dass es mehr Speicherverfolgung stellt, ist das, was tatsächlich verwendet, wird es trotzdem beim Starten sofort vom Memo-Tanatisation abgeschossen. Ich habe also gerade geschafft, eine der Xcode-Libos der entsprechenden dafür zu verwenden. I don't, ich weiß nicht, ob das tatsächlich so vorgesehen ist, aber wenn man das tatsächlich mit Common Center verwendet, dann crashes sofort. Bereits wenn es Konfigurationslateien versucht zu passen. Das alles hat also nicht so ganz funktioniert. Das heißt also für uns, dass die Faser in bestimmten Typen nicht gar nicht erst finden kann, was bei der Verwaltung betrifft. Alle Faser, die ich also erstellt habe, sind jetzt nicht perfekt, aber die haben verschiedene Caches gefunden. Schauen wir mal, was diese Caches also an. Die erste, was wir sehen, ist hier die Zahl ist hier 42. Das heißt ja, also aufgehört, als ich 42 erreicht habe zu sammeln. Ich habe also auch Frida-Caches herausgefiltert. Das heißt, in Summe habe ich also bestimmte Gesamtanzahlen questioned, dann eine Zahl, die tatsächlich reproduzierbar sind und dann kann ich nochmal prüfen, ob sie in den letzten iOS-Version 15.3 organisiert worden sind. Dann habe ich verschiedene Farben hier, die für die Intel-Libraries und für die Qualcomm-Libraries. Und für die Qualcomm-Libraries habe ich jetzt nicht so viel Zeit, Zeit darauf verwendet zu fassen. Zum einen, weil ich nicht so viele Qualcomm- iPhones hatte und zum anderen wegen den ganzen Assertions gehe ich davon aus, dass sie viel, viel weniger Probleme haben. Die Location-Themen auch hier als große Graue, große Rechteck hier entpackiert, weil die Location-Themen auch ein paar Pakete hier von bekommt und praktisch direkt bekommt und von daher auch durchaus auf besprechende Fassungen reagiert. Ich habe viele, viele andere Caches, einige davon sogar tatsächlich reproduzierbar. Es gibt zum Beispiel Wireless-Radio-Manager-Themen, die man über ein Intel-Package crashen kann. Es ist uns mittlerweile auch repariert und dann ist noch ein anderen interessanten Crash, die ich zufällig gefunden habe und zwar wohl bei Qualcomm und bei den Intel-Libraries. Die ist mittlerweile auch gefixt und einige Caches passiert nur bei Qualcomm. Ich weiß allerdings nicht, ob das nur ein Qualcomm-spezifisch Geschichte ist oder ob das sich nur zufällig beim Parsing so ergeben hat. Der Mobile-Internat-Sharing-Demon hat ein Problem, wo beim Parsing von verschiedenen Kontroreaktionen bringt. Ich habe das relativ früh gefrüht und mir war allerdings nicht bewusst, dass so viele verschiedene andere da an der Stelle question. Dann habe ich das also entsprechend an Apple gemeldet und die haben mir geantwortet, ja, ja, wissen wir und wir haben das in einer Beta tatsächlich schon kurz vor deinem Report repariert. Ein anderer interessanterer Crash ist im AI Cell-Monitor und der Cell-Monitor ist etwas, was passiv im Hintergrund läuft die ganze Zeit und es passt zum Beispiel GSM und UMTS Zelleninformation. Ich fand das aus ohne, dass ich eine SIM-Karte davon hatte. Ich habe das an Apple reportiert. Ich weiß jetzt noch nicht mal, ob es überhaupt über das Funke-Interface-Luft-Interface auslösbar ist. Es ist mittlerweile gefixt in iOS 14.2. Ich habe viele, viele E-Mails mit Apple ausgetauscht. Ich habe gedacht, der ist was nicht repariert. Der Grund dafür war, dass die entsprechenden Funktionen stellt sich heraus, dass es da zwei verschiedene Wachs an der gleichen Funktionen gibt. Ich hatte gedacht, gleiche Funktion, gleicher Crash, der Wachs ist nicht gefixt. Also aber in Wirklichkeit das Hochqualitativer Code, das heißt, es gibt's mehr als ein Wachs pro Funktionen und die hatten in einer gefixt. Ich glaube allerdings, dass die anderen nur relativ einfache Quäste sind, die nicht explotet werden können. Die enden Geschichte ist, es gibt viele, viele mehr Wachs, die repariert werden müssen. Einer davon erhöhen nur die Stabilität. Ein paar andere sind aber auch noch ganz interessant. Ich habe also euch erzählt, dass es ein ganz einfacher Fasser ist. Sie besagten den Alpen. Ich gehe davon aus, dass einige von euch mit ihren alten iPhones, die nicht mehr unbedingt angefangen haben, so was zu schreiben. Also, wie können wir also einen Fasser schreiben, einen Fasser schreiben, der durch das hat und in entsprechende guten States reinkommt? Also wenn ihr in Frieda Fasing reinkommt, dann ist sehr viel davon limitiert durch die Kapazität, durch die Rechenleistung des iPhones. Das heißt auch, dass man sich sehr schnell die Batterie leer macht. Das heißt, es ist sehr wichtig, dass die Fasser eine hohe Leistung haben. Also, sehr wichtig anzugucken, wo sind Flaschenhälse, wo verliert ihr die meiste Zeit? Also, sprich, hier bei unserem einfachen Beispiel Fasscase-Effekt und kann das hochdrehen bis auf 20.000 Fasscases per Second. Also, ein Student von mir hat also einen komplett anderen Fassing, ein komplett anderen Fasser gefasst, bei meinem iPhone ausprobiert und es lief tatsächlich mit 20.000 Fasscase pro Sekunden. Ich habe gedacht, nee, das kann nicht sein, aber tatsächlich so, schnell geht das. Das hängt also ja an dem Design von Frieda an. Das erste, was man also macht, ist, dass man einen Palsencrypt schreibt, was auf Linux und macOS läuft. Ich hatte also ein paar Funktionen hier. Es hat das OnMessage Callback Funktion. Die brauchen wir später. Ihr registriert das einfach. Ihr ladet also entsprechende Frieda-Skript. Das Skript kann dann sogar Funktionen auf eurem iPhone aufrufen. Dafür ladet ihr ein zweites Skript auf eurem iPhone. Ihr initiiert das in den Zielprozess. Zum Beispiel kann es die Senderfunktion nutzen, um Dinge hin und her zu schicken. Es kann Funktionen exportieren über IPC. Sodass ihr dann also das Ganze passiert über JSON. Also die Realisierung und das heißt, ihr könnt z.B. keine Hack-Data senden oder Binarvianatendaten direkt senden, sondern es ist praktisch inkludiert und dekodiert werden muss dafür. Es ist auch alles über USB. Das heißt, ihr seid auch durch die maximale Geschwindigkeit um USB beschränkt. Das heißt natürlich, wenn ihr die entsprechenden C-Bindings von Frieda nutzt. Auf dem iPhone ist es als Python. Aber je mehr ihr praktisch von dem JSON-Part und USB-Part wegnehmt, desto besser ist es. Das entsprechende Paar sieht so aus. Ihr seid also eine Lüge. Ihr definiert also diese entsprechende Inbound-Message- Coreback-Funktion. Die Argumente, eine Payload, eine Länge hat, sieht ein bisschen kryptisch aus. Dann könnt ihr aber nicht diesen Interceptor hinzufügen. Denn ihr wollt zum Beispiel, weil ihr die Sequenznummer richtig hinkriegen wollt oder den gleichen. Dann ruft ihr dieses Inbound-Message-Coreback von AII einfach auf und schickt es raus. Das kann also alles anders aussehen. Also wenn ihr das also über RPC, über eure Python-Script oder Lecture ausstürzt, dann kommt ihr vielleicht auf 500 Fast-Cases pro Sekunde. Oder wenn ihr das Ganze in dem, das hier Invis-Message-Coreback in einem lokalen, in der Polar-Einschleife läuft, dann kommt ihr tatsächlich auf 22.000 Fast-Cases pro Sekunde auf exakt dem gleichen Device. Die Unterschiede ist, dass die JSON-Serialisierung und das USB macht halt einen ziemlichen Unterschied. Ich habe ein paar Mehr-Messungen mitgemacht. Traurigerweise gibt es auf dem iPhone 8 einen Bug, der mich davon abhält, Coverage zu sammeln. Was ihr aber sehen könnt hier, ist im ersten Teil, wenn ihr zum Beispiel einfach nur die Funktion aufbucht, dann kriegt ihr auf dem iPhone 7 17.000 Fast-Cases pro Sekunde. Und wenn ihr das tatsächlich dann auch wirklich sammelt kommt ihr runter auf 250 und das heißt, ihr müsst praktisch fragen, ob euch das Wert ist zu euch. Oder wenn ihr diese Zeile hier guckt, wenn ihr einfach nur diese entsprechenden Zeile dir drückt, kommt und die einfach nur ausgibt auf eurem Laptop, dann kriegt ihr immer noch eine sehr, sehr starke Verlangsamung von zwischen dem Javascript auf dem iPhone und dem Python auf eurem Laptop. Also, wenn ihr also diese Remote SMS-Injektionen habt, die ich vorhin beschrieben habe, dann fällt ihr runter auf 500 Fast-Cases pro Sekunde ohne jedes Kavage. Wenn ihr dann den Kavage ständig müsst, die Abdeckung mehr ist, dann geht es runter auf 100 Fast-Cases pro Sekunde. Wir sehen das Optimum hier. Und weil der entsprechende Mutator aber ziemlich langsam ist und weil er die Kavage-Information noch auswerten muss, werden es dann im Endeffekt nur 20 Fast-Cases pro Sekunde. Also, das ist der Vergleich hier von warum die Sammlung vom Kavage zu sammeln nicht unbedingt Sinn macht und warum es nicht unbedingt die beste Idee ist, auch wenn es einfacher ist, den Mutator auf eurem Laptop zu beschreiben. Das wird entsprechend wenn ihr also guckt, wie es aussieht nach den ganzen Fast-Cases, also wenn ihr versucht, die SMS zu füllen, dann seht ihr keine Chance mehr. Einzige Chance hier ist, dass ihr euer iPhone praktisch komplett auf Werk einstellt und zurücklett. Also, jetzt gibt es noch eine Frage- und Antwort-Fession und wenn ihr die verpasst, dann bin ich auch per E-Mail oder per Twitter zu erreichen.