 Und jetzt möchte ich unsere erste Spiegel und das Thema, das er übernimmt, IOS Kernel Exploitation Archaeologie. Herzlichen Applaus für den Vortragenden. Also, als erstes möchte ich euch danken, dass ihr hier seid. Wie ich gerade schon vorgestellt wurde. Es ist ein vorgeschrittener Vortrag, also ich entschuldige mich schon mal voraus, falls es nicht interessant sein sollte. Also ein paar Sachen über mich selbst. Von den ganzen Sachen sind die Sachen, Sie sind die Sachen auf der Folie am Interessanten, also aber ignoriert es ganz andere. Worüber ich reden werde, ich werde über den IOS 7 Exploit reden. Das war ein Jailbreak. Es wurde von den IVATES rausgebracht am 22. September 2013. Es hat die IOS Systeme 7 bis 7 1 B3 unterstützt. Und die ganzen unterstützten Geräte waren zum Beispiel das iPhone 5S. Das war zum Beispiel das erste 64-Bit-Gerät von Apple außer noch der Fernseher. Und ich habe das Ganze neu implementiert. Also ich war nicht wirklich an dem Fehler interessiert, sondern an den Techniken, die verwendet wurden. Also ich habe das Ganze reverse engineered und angefangen zu verstehen. Und an einem bestimmten Punkt habe ich es neu implementiert, also das Denkan Exploit neu implementiert. Also das hier ist in meinen Notizen über das Projekt, das ist kein Walkthrough durch ein Jailbreak. Ich werde mich zuerst auf die Probleme fokussieren, dich bekommen und wie ich sie behoben, also wie ich es geschafft habe, darüber hinwegzukommen. Und ich hoffe, wenn ihr gerade an IOS-Körnel forscht, dann könnt ihr da hoffentlich was Interessantes mitsehen. Also die generelle Outline ist, ich werde erst etwas über das IOS 7 erzählen, um so ein bisschen die Grundlagen zu setzen. Dann über den eigentlichen Fehler, also den Kernelback, dann werde ich lange über mein Debugging-Setup reden. Das ist nämlich der Schritt, wo in meiner Meinung nach die anderen Talks über Handy-Exploits ein bisschen zu kurz kommt. Weil das ist so ungefähr die Hälfte von der Arbeit. Und dann werde ich noch über meine Reimplementation reden. Also von dem Exploit. Und am Ende hoffe ich mal, dass ihr was aus dem Vortrag mitnimmt. Also es wurde am 22. September rausgebracht, also vor vier Jahren. Also das ist die Archäologie in dem Titel des Vortrags. Und wenn man dem ganz ein bisschen geflug gefolgt ist, hat man das ganze Drama um Geohot mitbekommen. Ob Geohot seinen Exploit vor den Jailbreak rausbringen, wie man es verkaufen wollte. Und Diskussion über jemand, mit jemand darüber, der eben Geld dafür angeboten hat. Geohot hat ähnliche Fehler verwendet, wie die Jailbreak. Also es gab wirklich viel Drama. Aber nach dem Jailbreak, also ein paar Stunden danach, also wenn dein Handy, wenn der Jailbreak war installiert, ein Piracy App, wer das sich des Herrn Jannes geguckt hat, es wurde in der 3. Partie App installiert, die einen raubkopierten App store angeboten hat. Und natürlich hat das viel Probleme erzeugt, weil das dann gar nicht viel Problem hat. Und was wirklich die beiden getrennt hat, war diese Twitter-Post. Und es macht nicht wirklich Sinn. Also es heißt, wir haben den Tag Store in China ausgeschaltet komplett aufgrund von den Raubkopie-Problemen. Also man wusste nicht, was los war, man wusste nicht, ob das irgendwie mit dem Jailbreak zusammenkam oder also was heißt dieses Fernlöschen? Also wie, wie wollt ihr die ganzen raubkopierten Programme loswerden? Also es ist ein Super-Tweet, finde ich. Also nach diesem Evasion 7 Jailbreak, hat Geohot ein Essay geschrieben über den User-Land-Teil. Also hat er analysiert, wie das funktioniert und er hat da aufgehört, als er Route hatte. Also er schreibt in seinem Write-Up Evasion 7, dass das war im Prinzip das Binary, das den Exploi gemacht hat, war sehr gut obfuscated. Also das war tatsächlich so, ja. Das ist der erste Jailbreak, der bewusst obfuscation eingesetzt hat. Also einerseits um diese Piracy-Apps zu verstecken und andererseits um zu verstecken, was der Kernel-Bug war, der ausgenutzt wurde durch den Jailbreak. Also Posix Ninja, der den Kernel-Bug effektiv gefunden hat, soweit ich weiß, hat über diesen Bug was geschrieben und er schreibt soweit, bis er von GDP ein Crash-Lock erhält. Also er sagt nicht, wie man den Bug ausnutzen kann. Also ich wollte das Binary-Selbst-Reverse-Engineern um den Exploi zu verstehen. Also ich wollte mir insbesondere diese Obfuscation genau anschauen und das war eine große Herausforderung, das zu deobfuscaten. Und ich wollte verstehen, wie genau das Ausnutzen der Lücke von Statten geht im Kernel. Der Jailbreak wurde im Dezember 2013 rausgebracht und ich habe im Februar 2014 angefangen. Also ich hatte daneben ja noch einen normalen Job und also ich habe höchstens zwei Tage pro Woche in diesem Projekt gearbeitet. So wie war meine Ausstattung? Ich hatte ein iPhone 4, die haben ein Butrom-Bug, das heißt Linebrain, da kann man beliebig unsignierte Kernels laden durch diesen Bug. Das heißt man kann sehr leicht Kernel-Debugging einrichten auf diesem iPhone. Also ich hatte ein iPhone 4 mit iOS 7.0.6. Also denkt dran, das ist noch 32-Bit-Architektur und ich hatte noch ein iPhone 5s, auch mit dem gleichen iOS drauf und das habe ich verwendet, um meine ganzen, was ich herausgefunden habe, zu verifizieren. Und das ist auch ein AM64-Gerät. Also ich glaube, das war das einzige AM64-Gerät auf dem Markt bis dahin. Ja und eben die Version 7 war die, die ich analysiert habe. Also das Lustige auf dieser Slide hier ist, ja gut, dass es nicht wirklich besonders lustig war, was das schmerzhaft war, dass mir viele schlaflose Lechennächte bereitet hat, also noch einige Dinge über die Obfuscation. Nicht alle Funktionen von BinaryOne obfuscated, aber einige wichtige schon. Das waren die, die den Bug im Kernel ausgenutzt haben, die Heapmanipulation gemacht haben und so andere zentrale Dinge. Also mir wurde gesagt, dass spätere Version diese Obfuscation nicht mehr drin hatten, aber das habe ich selbst nicht gesehen. Also ich war bis zu diesem Zeitpunkt in E schon fertig mit meiner Reverse Engineering, also. Wie ich schon gesagt hatte, der Kernel Bug, der Evation 7 Untethered Binary wurde von POSIX Ninja gefunden und er sagt, das sieht man auch auf der iPhone Wikipage, hat er im Prinzip dieses sechszeilige Bash Script verwendet. Also er macht im Prinzip Device Notes mit bestimmten Argumenten hier mit Major und Minor Numbers. Also um es auf den Punkt zu bringen, um dahin zu kommen, um diese Device Notes erstellen zu können, muss man außerhalb der App Sandbox sein, die auf iOS vorhanden ist und man braucht Route Rechte. Also das ist der User Land Part vom Evation 7 Exploit. Das werde ich jetzt nicht genau ausführen, wie man das macht. Also wir fangen da an, wo man schon aus der Sandbox ausgebrochen ist. Also das ist der Code hier aus der Version des XNU Kernels mit dem Bug. Also hier sieht man die Open Funktion, die wird immer aufgerufen, wenn im User Land Code ein PTMX Device öffnet. Dann wird diese Funktion aufgerufen. Das Wichtige hier ist, das Dev wird komplett vom Benutzer kontrolliert und das wird nicht überprüft. Und dann gibt es diese IOCTL Funktion, die diesen Wert verwendet, ohne dass der Wert überprüft wird. Also es sei nicht ein Fehler, den User Import zu validieren. Also ich habe noch hier den PTMX IOCTL Struct. Dieses Array da, dieser Zustand, dieses Zustand Struct, ist global im Kernel. Und dieses Stück IOCTL List hier ist im Kernel heap. Und das ist ein Array von PTMX IOCTL Structs. Das ist das hier unten. Das Wichtige hier, das werde ich dann immer wieder erwähnen, es hat hier ein Pointer auf ein PTTTY Struct. Also wir können den Index ins Array kontrollieren. Was können wir damit anfangen? Hier sieht man, dass PTMX IOCTL Funktion, gibt einfach das zurück, was durch den Index darauf verwiesen wird. Dann gibt es hier diese PTI Variable, die da rausgelesen wird. Also das kann man kontrollieren, TP hier kann man kontrollieren. In anderen Teilen des Kernel Codes ruft man das, wird das wieder und wieder aufgerufen. Also da gibt es viele Dinge, die man anschauen muss, wenn man weiß, hier gibt es ein Bug und man versucht den jetzt auszunutzen. Also gut, noch etwas Wichtiges hier, dieses PTMX, diese Funktion hier. Die macht auch die Allokation dieses Structs hier, das PTY hier. Das ist wichtig, weil das baue ich dann später. Ein weiteres Wichtiges Detail, dieser Bug erlaubt einen, man kann die Größe von diesem Array hier kontrollieren. Also seht ihr das hier? Also wenn man das PTMX Device öffnet, kann man dieses Array immer größer machen. Und das sieht man hier bei diesem Grow Vector. Also es ist egal, wie groß das hier ist. Das Wichtiges, die Größe des Arrays in bytes, kannst du als Nutzer kontrollieren. Also der, der diesen Bug ausnutzen will. Also das hier ist nicht von meinem Exploit, aber wenn ich jetzt ein Open mache von diesem PTMX Device, dann heißt das, es geht hier in Calox 64 und wenn ich jetzt das 17 mal mache, dann geht es auf 128, wenn ich 33 mal diese Funktion ausführe, dann geht es auf 192 und so weiter. Also ich konnte also entscheiden, in welcher Calox Zone dieses Array kommt. Also wenn ihr das nicht kennt, Calox Zones, das könnt ihr euch so vorstellen wie Container für Hip-Objekte im Kernel-Hip. Alle können von verschiedenen Typen sein, aber alle sind jeweils von der gleichen Größe. Also Calox 64 hat Versine-Structs von 64 bytes. Also alle sind eben dann genau 64 bytes groß. Also ich habe mit dem Debugging angefangen vom Untethered Binary in Userland zuerst mal mit GDB und da habe ich gemerkt, dass eigentlich nichts funktioniert hat. Zu dem Zeitpunkt hatte Apple angefangen von GDB zu LLDB zu wechseln und als ich dann gesehen habe, dass nichts funktioniert, also zum Beispiel wenn man Breakpoints setzt, dann werden die nicht gehittet oder halt Stepping ging auch nicht. Zum Teil konnte man nicht mal ans Binary attachen. Also heißt ich habe dann auf LLDB gewechselt mit einem Debug-Server und es war ein bisschen besser. Was ich da am Rumpröbeln war, ist mein iPhone 4 Gerät in ein Recovery Loop geraten und ich konnte das nicht wieder herstellen. Das heißt, ich musste eine saubere, neue Installation machen, aber zu diesem Zeitpunkt gab es nur iOS 7.1 von Apple. Also ich konnte nicht die Version installieren, die diesen Kernel-Bug hatte. Aber ich konnte halt auch nicht das Gerät nicht wieder herstellen, weil das war das einzige Gerät, auf dem ich Kernel die buggen konnte. Also habe ich halt auf 7.1 abgegradet. Aber dieser Exploit funktioniert halt nicht auf iOS 7.1. Was ich eigentlich machen wollte, war ein iOS 7.1 Gerät zu buden, aber mit einem 7.06 Kernel. Und dafür konnte ich den Library-Bug ausnutzen, um beliebige Kernel zu buden zu können. Das Problem war, dass RedSnow nur bis zu iOS 6 unterstützt hatte. Und iOS 7 wurde halt nicht unterstützt. Das heißt, ich habe den ganzen Rest mal auf der Seite gelassen und erst angefangen RedSnow's Exploit anzuschauen. Also das war damals noch Close Source. Also habe ich halt angefangen das zu Reverse-Engineeren, um diesen zu patchen. So dass es iOS 7 unterstützt. Da habe ich wohl ein Monat damit verbracht. Und dann habe ich gemerkt, ja, da komme ich irgendwie nirgendwo hin. Es gab viel, das ich nicht wirklich verstanden habe. Und ja, habe eigentlich damit aufgehört. Zu diesem Teilspunkt habe ich danach OpenSnow gefunden. Das war eine Anstrengung von Winocm RedSnow als OpenSource Exploit auszuführen. Es hat funktioniert, aber jetzt war mein Problem, dass ich keine arbitrary Länge von Bootargumenten mitgeben konnte. Also in iOS sind die wirklich sehr wichtig, weil wenn man bestimmte Bootargumente übergibt, kann man Signing Checks ausschalten und auch das Kernel Debugging anmachen. Also deswegen will man eigentlich arbitrary Länge von Bootargumenten mitgeben. iOS 7 hat 39 Zeichen benutzt, also hat OpenSnow auch nicht mehr unterstützt. Also was ich jetzt gemacht habe, ich habe iBack gepackt. Das ist der Teil, der den Kernel lädt. Und ich habe den Pointer von den Bootargs auf eine andere Stelle gesetzt, wo ich mehr Platz zum Schreiben hatte. Und dann konnte ich eine arbitrary Länge von Bootargumenten mitgeben. Also ich hatte ein iPhone 4 mit iOS 7.1 und ich habe mit OpenSnow den 7-Point-Kunnel gebotet. Und eine Notiz, die man hier machen sollte, ist, als ich mit OpenSnow versucht habe zu arbeiten, habe ich währenddessen auch das iVation 7 Binary File reverse ingeniert. Und was der exploit gemacht hat, er hat den Kernel gepatcht, um Kernel Debugging anzumachen. Aber an einem Punkt habe ich gesehen, dass die Debugging nicht angemacht wird. Also man hat die Verbindung herstellen können, und es ist ja auch so, als würde es funktionieren, aber wenn es dann nutzen wollte, und man zum Beispiel Breakpoints setzen wollte, dann ist das Ganze einfach eingefroren und es ging nichts mehr. Also das war noch was, was ich machen musste. Also wir haben dann das Kernel Debugging schon auch hingekriegt, aber es war nicht ganz so einfach. Also manchmal haben die Breakpoints funktioniert und man hat versucht, irgendwelche Schritte auszuführen. Aber manche liefen es einfach weiter. Das war so, als hätte man continue getippt. Und wenn man jetzt zu lange gebraucht hat, dann musste man das Gerät neu starten und noch mal von 0 anfangen. Und wenn man die Kommandas zu schnell geschickt ist, ist das Ganze auch wieder eingefroren und muss das auch wieder neu starten. Also es war eine tolle Zeit. Also ich habe ähnliche Sachen gemacht mit iOS 6 und ich erinnere mich daran, dass es sehr viel leichter war Das Problem ist, nutzen die Apple Debugger wirklich LLDB oder benutzen sie was anderes. Also jetzt konnte ich das Evasion 7 binary wirklich debuggen von der User-Seite und von der Kernel-Seite und jetzt konnte ich es zur Laufzeit analysieren und zur selben Zeit konnte ich aber auch reverse-engineeren im IDA. Also an dem Punkt ging es an Züge. Also ich habe dann die TTY Structure gefunden und damit konnte ich dann schreiben und lesen auf dem Speicher. Also es war sehr interessant. Ich habe irgendwie so was erwartet, was zum Beispiel im Evasion 6 Jailbreak drin war, wo sie irgendwelche Heaps-extractors haben. Also hier habe ich eine Aufgabe zu reverse-engineeren und habe es neu implementiert. Es hat natürlich nicht von Anfang an funktioniert und ich habe nicht von Null angefangen, sondern ich habe aber ich werde das in den folgenden Schritten erklären, wie ich dorthin kam und wie es funktioniert. Also zu dem Punkt hatte ich jetzt das Verständnis, wie der Back funktioniert, eine generelle Idee, wie man das gerade exploten könnte und wenn man das schon mal gemacht hat, dann wisst ihr, dass man viel Stiftung und Papier braucht, um Ideen zu entwickeln, dann funktioniert es nicht, dann muss man nochmal von vorne anfangen, man braucht, es ist ein iterative Prozess, der wirklich anstrengend ist. Also man sitzt dann nächtelang dran, bis morgens um fünf und probiert es aus und es funktioniert wieder nicht und dann experimentiert man nochmal und das wiederholt sehr häufig. Aber jetzt drehen wir mal darüber, wie man die Schwachstelle ausnutzt. Also um Gedächtnis nochmal zu erfrischen, also in grobem war es ein ungültiger Indexback und ich konnte kontrollieren, in welcher Karlobzone es enden konnte, aber ich konnte es nicht wieder reduzieren. Also das ist jetzt Code aus der Funktion. Was es macht, es anlockiert eine neue Struct und nutzt dann um neue Sachen dort hinzuschreiben. Also die Struct hier... Also ein paar Sachen über die Technik, die ich hier benutzen wollte. Also es ist wie mit Kopi-Technik, also es wurde von Down and Mant vorgestellt. Also was sie praktisch machen ist, sie trenkeln den Hieb mit irgendwelchen Structs und gehen davon aus, dass irgendwas die Struct korruptieren wird und was man dann praktisch hat ist, also man liegt praktisch Kern und Memory. Also dahin kommt man dann an die Daten, die oben oder unter dem Element liegen. Also wenn ich hier ein Element anlegt und dann wieder frei kippt, also wenn das dann wieder anlockiert, dann landet es auf einem anderen Teil des Speiches und damit kriegt man den Hieboflug hin. Also man korruptiert eine Struct und hat dann einen Hieboflug. Also was war die Idee? Die Idee war, also die PIS aus CT analyst in Nexbuck und um dann eine Relative League von Kern und Speichchen hinzubekommen. Also das war mein erstes Versuch. Also das Endziel ist natürlich aber es war natürlich nicht ganz sauber Idee, aber wenn man am Anfang anfängt und dann die Code fadet sieht und die Sachen, auf die man schreiben kann und wie die weiter benutzt werden, dann hat man nicht so ganz konkrete Sachen im Kopf, aber man hat so eine Idee, wo interessante Dinge passieren könnten. Aber dann reden wir jetzt mal über die Schritte für die Ausmutzung der Schwachstelle. Also Schritt 1 ist man schmeißt viele WMAP Copystructs auf den Kern und hat mich entschieden, auch in der Colour 256 Zone zu arbeiten. Warum ich das genommen habe? Also durch das Kerneldebugging habe ich gesehen, dass diese Colour Zone nicht wirklich benutzt wird. Also nicht vom Kernel und auch nicht vom Exploit. Also das war gut, weil es bedeutet, dass man eine bessere Kontrolle darüber hat als die anderen Sachen, die da auch noch die Sachen drauf schreiben, als wenn irgendetwas anders noch reinschreibt. Also habe ich mich entschieden, die Zone zu nutzen. Natürlich habe ich die 384 Zone ignoriert, weil dort die TTY Structs lagen. Also das Erste, was ich machen wollte, ist das hier. Am Anfang schmeißt man WMAP Copystructs auf den Heap und man kontrolliert den Inhalt und die Größe. Also wirklich nur ihr Größe spielt eine Rolle. Also man schmeißt 256 bytes und man gibt dann jedes zweite WIR frei. Und so kann man die Liste wachsen lassen zu 256 bytes und dann geht es in einen der freien Slots hier. Der Code, um so was zu machen, sah so aus. Was es praktisch macht, es erstellt. Wenn ihr hier die Markenmessages seht, der Größe ist 256, der Buffer spielt hier keine Rolle und man schickt einfach Nachrichten. Und nachdem man die drauf geworfen hat, und dann gibt man jeden zweiten frei, wie hier, um diese freien Plätze zu bekommen und um diese freien Sache zu bekommen, gibt man diese Out-of-Line-Messages hier aus. Und nachdem man die Löcher erzeugt hat, lässt man die Array auf 256 bytes wechseln. Das macht man öffnet, das Dev-PDM-X-Device. Wie oft spielt keine Rolle, aber es lässt es anwachsen. Genau, das ist was wir im ersten Schritt machen. Und im zweiten Schritt macht man an der Karloc 88 Zone. Also man schmeißt wieder die Structs drauf, aber diesmal natürlich mit 88 bytes. Und dann erzeugt man wieder diese Löcher in dieser Bälle. Und dann löst man die Schwachstelle aus, indem man einen falschen Index übergibt. Und wenn man den Kernel, was Falsches mitgibt und dort gibt es dieses Muster von frei benutzt, frei benutzt, dann gibt man einen Index auf einen der freien Plätze. Ich weiß nicht, wo das ist, aber ich weiß, dass es in dieses Muster fällt. Und damit kann ich die Schwachstelle auslösen. Also merkt euch, ihr kontrolliert hier diesen Index. Also man zeigt ihn auf und ich lasse ihn dorthin zeigen, wo ich weiß, dass oben drüber ins Freie ist. Ich kenne die Adresse nicht, aber ich weiß den relativem Abstand in bytes, weil ich natürlich den Hieb selber, also die Struktur selber erzeugt habe. Also sieht so aus. Also das ist mein erster Schritt. Und das ist dann das zweite auch in der Kallog 88-Zone. Und wenn das allokiert wird, geht es in einen der freien Plätze. Und dann der Bug an sich, was wir hier sehen, dann geht es her und speichert es dorthin, wo der Index steht. Also wo der Index hin zeigt. Aber erinnere euch, wir kontrollieren das hier. Und wir kontrollieren, dass kein Data fällt, also von der VMAP CopyStruct. Und damit habe ich die Adresse rechts. Das ist dann wie der Hieb aussieht. Also hier ist der Code, das sieht praktisch aus wie Schritt 2. Man erzeugt die Hiebstruktur, diesmal nur in 88. Und dann gibt man die zweite WFrei. Und dann kann man hier mit der Zeile die Schwachstelle ausnutzen. Die Indexnummer hier ist praktisch, was relativ dorthin zeigt. Also ich habe jetzt die Adresse von dem IOCTL struct, was eine Adresse auf der Kallog 88-Zone ist, über die VMAP CopyStruct hier. Also was ich jetzt mache, ich fange einfach diese Nachricht. Und im Innerhalt sehe ich die Adresse in der Kallog 88-Zone. Also hier machen wir das, ich empfange einfach alle Nachrichten. Und das hier ist meine Adresse. An diesem Punkt, das Einzige, was ich bis jetzt habe, ist die Adresse hier. Also die Adresse von diesem Hiebslot. An dem Punkt schaue ich jetzt nach anderen Code-Faden, die den ungültigen Index, was das noch beeinflusst. Und was ich noch gefunden habe, war ein Code-Path, der noch einen Ride freigegeben hat. Aber um dahin zu kommen, muss ich noch ein paar andere Sachen machen. Das Einzige, was ich wusste, ist die Adresse. Also jetzt werde ich euch erklären, wie wir zu diesem Ride kamen. Also ich räume den Kallog 56-Zone auf. Spray es noch mal, genau wie vorher schon, mit WMAP Copy. Noch mal mache ich neben dem PIS-IOCTL-List-Array, habe ich dann entsprechend eine WMAP Copy-Struct. Aber dieses Mal schreibe ich eine Payload in die WMAP Copy-Structs mit dieser Fake-PTMX-IOCTL-Adresse. Also der erste Teil ist ja ein Pointer zu einem IOCTL-Struct. Und dass die Adresse, die da liegt, vom Pointer, kann ich brauchen für ein Fake-TTY. Also dann die Kallog 88-Zone aufräumen und wieder sprayen mit WMAP Copy-Structs. Und an dieser Stelle brauche ich als Payload diese Fake-TTY-Struct. Das Problem hier ist allerdings, das TTY-Struct ist 56-bytes und Kallog 98 ist natürlich nur 88-bytes groß. Also mit den Elementen der ersten 88-bytes konnte ich nicht zu einem Ride kommen. Also ich musste irgendwie eine andere Art finden, um mein gefälsches TTY-Struct zu haben im Heap. Also ich konnte ja nicht in einer anderen Kallog-Zone arbeiten, weil ich wusste ja nur die Adresse auf dieser Kallog 88-Zone. Ich hatte nichts anderes, worauf ich aufbauen konnte. Das heißt, ich habe angefangen mit viel komplizierten Heap-Anordnungen zu spielen. Also anstatt nur ein Heap zu sprayen, wollte ich ein Muster aus zwei kontrollierten Teilen haben. Also ich konnte nicht WMAP Copy-Struct brauchen für diese zwei. Das geht nicht, weil WMAP Copy-Struct hat hier ein Header. Also habe ich halt die Kernel Heap Exploitation Slides gelesen von Ionix und da habe ich gemerkt, dass ich mit XML-Properties von Länge 98 das ausnutzen konnte, von diesem JPEG-Triba. Und ich konnte in zweites WMAP Copy-Struct in den 88-Jahr-Bereich legen und der zweite Teil vom Fake-TTY-Struct konnte dann da drin sein. Also immer noch nicht zu 56 Bytes insgesamt. Aber halt der wichtige Teil, der mich interessiert, passt da rein. Also einige Dinge über die TTY-Structs, immer das TTY-Structs, das ist so eines, wie ich eben in der Kallog 88-Zone anlegen wollte. Das ist, wo das IOC-TTY-Struct drauf zeigt. Also hier wollte ich, was das letzte Ding hier ist, dieses C-List-Struct wollte ich dieses CL-Unscore-CS kontrollieren und das gibt mir dann beliebige Rights. Ich habe damit ein bisschen rumgespielt, um beliebige Schreibzugriffe implementieren zu können, aber das ging nicht, weil später hätte man dann dafür noch andere Teile des TTY-Structs gebraucht und darauf konnte ich nicht drauf zugreifen. Also das war nicht wirklich stabil und ich habe das also nur verwendet, um einen relativen Schreibzugreff zu machen. Das gehen wir mal weiter, hier aufs Heap-Layout. Das ist jetzt Teil 3. Was denkt dran? Ich habe die Kallog 256-Zone mit WMAP Copy Freeze gesprayed, einfach damit ich dieses PIS-IOC-TTY-L-Listen neben WMAP Copy-Struct link konnte. Ihr wisst, ich kann den Inhalt von dem kontrollieren. Also habe ich darin diesen PTMX-IOC-TTY-L, diese Adresse reingetan, die ich ja weiß, und das ist ja ein gültiger Index und der zeigt halt hierhin. Und diese Adresse hier liegt die Adresse, die ich in der vorhergehenden Abschnitt ja herausgefunden habe. Das zeigt dann auf die Kallog PTH-Zone. Was ist da drin? Das ist ein WMAP Copy, gefolgt von XML-Properties und das kommt hier immer so anwechselnd. Und alle diese haben diese Fake-TTY-Datenstruktur drin. Das sieht dann so aus. Also als das hier zeigt auf das K-Data-Element da, und der Rest, also dieses Ding hier, diese zwei zusammen ist die Fake-TTY-Struct einig. Ein WMAP Copy und daraus folgt ein XML. Und wo ist jetzt dieses CS? Wo zeigt das hin? Das zeigt wieder relativ, also ich kenne halt keine Adressen, aber ich kann relative Adressen verwenden, weil ich weiß, wie die Anordnung auf dem Hip aussieht. Das zeigt auf Kallog-Size vom benachbarten WMAP Copy-Struct, weil ich will diese WMAP Copy-Technik verwenden, die ich vorher erwähnt hatte. Also wie sieht der Code jetzt aus? Das hier ist der Spring, das haben wir schon ein paar Mal gesehen. Dann gibt es hier den Freeze. Ne, das ist es nicht. Das ist die Zuweisung. Ja, das Freeze habe ich hier nicht. Also ich meine, spielt auch keine Rolle, haben wir ja vorher schon gesehen. Also das hier ist das Spring der Kallog-88 Zone. Das Wichtige hier ist, was ich euch zeigen wollte, ist bei jedem Schritt habe ich zwei Allocations gemacht. Einerseits das WMAP Copy-Struct da, mit einem MAP Message, und das Zweite ist dieses XML Properties. Das wird auf den Hipgespray, wenn man das Device öffnet, dieser Apple JPEG Driver. Und das ist da der Inhalt von diesen XML Properties, das im Prinzip die zweite Hälfte der fake TTY Struct mit diesem C underscore CS-Pointer, der mir Schreibzugriff gibt. Dann sieht man hier diese fake TTY Setup Funktion. Ja, und hier sind wir im zweiten Abschnitt. Und das sieht man, wie das fake TTY erstellt wird. Also das ist das hier im Code. Und das hier ist dieser Offset, auf den ich schreiben wollte. Und das kommt ins K-Data vom JPEG Nachbarten WMAP Copy-Struct. Also das sieht dann so aus, im Hip. Also, nachdem wir das so gemacht haben, wie in Stufe 3, lösen wir nochmal den Invalid Index Array Buck aus. Aber diesmal machen wir das mit diesem Index Device. Ich mache das immer mit einem Master Index Device, aber man muss es auf einem Slave-PTX Device machen. Das passiert hier. Dann schreibt man einfach in den entsprechenden Deskriptor, den C underscore CS, den man ja kontrollieren kann. Und dann schreibt es halt, was auch immer man schreiben will. Und was will ich machen? Ich will im WMAP Copy-Struct eine neue Größe für die Calox Size hineinschreiben in die benachbarte WMAP Copy-Struct. Also, wenn man jetzt das alles zusammensetzt, bis hierhin, habe ich also eine kontrollierte Überschreibung von WMAP Copy-Struct. Da kann ich ja im Prinzip ein arbitrary Leak haben, ich kann KSLR slide bauen und ein Hip-Overflow bauen. Also so kann man diese Primitiven zu einem Exploit zusammenstecken. Ich weiß ja also den Ort im Kernel-Hip. Und das haben wir schon in Stufe 1 und 2 gefunden. Wir brauchen das nur, um rauszufinden, wo das PTMXIoCTL-Struct ist. Da müssen wir die Adresse finden. Um jetzt erfolgreich darauf aufzubauen, hätte man viel nützlichere Primitiven. Das nützlichste ist, alles bis hierhin war ohne Code-Injection oder so. Wir haben noch keine Code da reintun können, weil da gibt es halt so Kernel-Selbst-Schutzmechanismen. Also, wenn man so weit ist, wie kann man jetzt PC-Kontrolle erhalten? Also man mit Hip-Overflows das erreichen. Also wenn man den Hip-Anordnung kontrollieren kann, dann kann man Iocit-Objects anlegen und halt Iocit-Objects teilweise überschreiben. Da kann man auch beliebige Rights machen. Also mit dem Arbitrary-Read kann man die V-Tables des Iocit-Objekts auslesen. Dann kann man das modifizieren und so hat man dann beliebige Rights. Also von da dann zu einem ganzen Jailbreak zu kommen. Gleich jetzt nicht in diesem Talk, aber es ist nicht mehr so kompliziert. Also nach all dem, wie nice, das ist eigentlich dieser Exploit zu dem echten Evasion-Send-Kernel-Exploit. Ich würde sagen, es ist wohl was ziemlich anderes. Aber es ging mir auch nicht darum, das genau nachzubauen. Ich wollte einfach mal ein bisschen mit dem Hip rumspielen und komplizierte Hip-Anordnungen zu erstellen und sehen, ob ich den Kernel verstehe. Also das war das in der Übung. Was habe ich gelernt? Also was habe ich gelernt, das wirklich überraschende für mich war, war, dass ich bis dahin, also ich konnte es wirklich nicht glauben, dass Apple das Debugging über KDP macht. Es war wirklich, es lief nicht stabil, wenn man die Sachen zu schnell geschickt hat, ist abgestürzt, wenn man zu lange gebraucht ist, abgestürzt wird. Ich denke, ich konnte nicht glauben, dass Apple-Engineure das wirklich benutzen. Also es war wirklich schwer, das auf dem Kernel zu machen. Aber natürlich meine ich damit nicht, dass man das Ganze nicht anfassen sollte. Also die Geräte sind interessant und es ist schwer, sie zu hacken, aber es macht, also ich denke, es macht deswegen umso mehr Spaß. Und wenn ihr noch Bugs findet, cool und am besten meldet ihr sie auch noch. Also es gibt nicht viele Sachen, die offen sind. Der ganze Code ist closed source, die Bugs sind closed source. Und Leute, die daran arbeiten, sollten sich irgendwie miteinander austauschen. Also das sind ein paar Leute, mit denen ich geredet habe, und wenn ich das an einem Apprät gearbeitet habe. Und das ist praktisch alles, was ich vorstellen wollte. Vielen Dank fürs Zuhören und wir nehmen es gerne Fragen. Thank you, ART-P, for the talk. So we have prepared microphones, one, two, three and four. Also wir kommen zu Fragen aus dem Publikum. Signal Angel, I think, when you have questions, you can give me a hand sign. Vielleicht hat der Signal Angel eine Frage. Also fangen wir mal an. And please ask questions and no comments, that's time after the talk. Go ahead. Thanks for an awesome talk. Danke für den Talk. Ich habe eine Frage über Heapspraying. War dein Heapspraying wirklich stabil? Also wenn es nicht funktioniert habe, ist dann das Gerät abgestürzt? Also ich habe es hier nur nicht ausprobiert, aber es lief eigentlich ziemlich stabil. Ich habe ziemlich viele Tests dazu gemacht, weil das war so der Test, den ich verwendet habe. Also so 80 Prozent oder 90 Prozent. Also 9 aus 10, man hat funktioniert und wenn nicht, dann ist alles gerade abgestürzt. Da musstest du das in den mir einen bestimmten Zustand bringen, um den Exploit neu anzufangen. Ja, du hast da recht. Also bei Jemalspray habe ich viele Objekte von bestimmten Größen, die auf dem erzielt. Um eine neue Seite auf der Colour beim Colour zu bekommen. Also ich, auch wenn ich erzählt habe, dass die 266 nicht so benutzt war, es gab trotzdem noch Sachen. Also wenn man am Anfang viel gesprayt hat, dann konnte man sich erstellen, dass das Ganze auf einer neuen Seite erzeugt wurde, wo nicht so viel Störung vom Kondel drin ist. Dann microphone 1, please. Also danke für deinen tollen Talk. Meine Frage ist, heute ist es schwer, VM Copy zu verwenden. Das glaube ich, deprecated jetzt aus Securitygründen. Siehst du eine Möglichkeit, was anderes zu verwenden, um mit den gleichen Effekt zu erzielen? Die VM Copy-Technik, also ich glaube, die ist jetzt inzwischen total tot. Also ich meine, ich habe da schon Sicherheitslücken gelesen und ein Apple-Jailbreak-Triber wurde gefunden. Apple ist eine der vier Treiber, die man aus dem Container erreichen kann. Also ich denke, ich sage zwar nicht, dass da keine Bugs drin sind, aber da das viel genutzt wird, also, aber wenn da welche sind, wird es sehr schwierig zu finden. Eine Frage vom Internet. Wie lange hat dich diese ganze Recherchearbeit getaugt, gebraucht so, von Anfang bis zum Ende? Du hast gesagt, du machst das Nebenarbeit. Nein, nein, es hat keine zwei Wochen gebraucht, also zwei bis drei Monate. Also ich habe, wie ich vor dem Event habe, ich habe, glaube ich, ein Monat, einfach nur an dem Red Snow rumgespielt, um das Ganze mit iOS zum Laufen zu kriegen. Also ich hätte jetzt den Teil nicht gezählt zum Exploit-Part, aber der reine Exploit-Part, so ungefähr sieben Wochen, aber nur mit zwei bis drei Tagen pro Woche, also nicht komplett noch. Gratulation zu deinem Talk, es war sehr spannend, ich mache den sehr. Diese Technik, um den Bug auszunutzen, war das bei ODBS, die auch dabei. Die VMAG-CopyStrucks exzitiert nix vor, außer dem XMU-Körnel. Aber das Interesse, was man daran mitnehmen kann, ist, wenn man komplexe Heap-Arranges machen kann, wenn er Allocate versteht. Also den Prozess, den ich beschrieben habe, also mit den Löchern und mehreren Sachen gleichzeitig anzulegen, kann man, also damit kriegen wir, also mit Toten um Schachstellen auszunutzen, die überall funktionieren. Ich habe da einen Satz gesehen, reported the bugs nicht. Ich will verstehen, wie du dazukommst, das zu sagen, weil das ist ziemlich wichtig für Firmen, dass sie wissen, dass es bugs gibt in ihren Produkten. Also, damit sie ihre Produkte besser machen können. Also, es ist sehr, sehr nützlich für Forscher und es gibt ja auch Entitäten, die viel zahlen für bugs. Also, ich habe dazu nicht viel zu sagen, außer wenn man so was machen will und die bugs werden gemeldet, also es macht keinen Spaß. Also, ich habe dazu nicht viel mehr zu sagen. Okay, Signal Angel, do we have another question from the internet. Okay, then please a big round of applause for our speaker.