 All right, let's start with our next talk in the security track of the Crayons Communications Congress. Lasst uns mit unserem Niesc-Vortrag starten, auf der Security-Schiene, iOS Straybreaking in der Vergangenheit bis heute, der Timster hat schon mal darüber geredet vor 2 Jahren, er wird euch erklären, wie die Begriffe alle so sind und wie man um die Sicherheitsmaßnahmen von Apple umgehen kann. Bitte eine große Runde Applaus. Vielen Dank. Hallo Riemann. Hallo. Ich bin Timster und ich werde über Jailbreaking in iOS reden. Und welche Leute reden werden, was ist Jailbreaking? Ich werde euch wissen, wie das damit angefangen hat, wie das weitergegangen ist. Ich erzähle euch mal noch weitere Begriffe, tethered, untethered, semi-tethered, semi-untethered. Ich werde ein bisschen über Hardware, Schutzmaßnahmen reden, KPP, KTRR und PAC. Ich sage auch, was das Ziel von Jailbreaking ist und was Kernelpatches sind, was man damit machen kann und wie Jailbreaking in der Zukunft aussehen wird. Wer bin ich? Ich bin Timster. Mein erstes iPod Touch habe ich iOS 5.1 bekommen. Seitdem habe ich mit Jailbreaks gespielt. Ich habe ein bisschen selber daran geforscht. Ich hatte vor eigenen Jailbreaks zu machen. Vor zwei Jahren habe ich über iOS Downgrading von des vergangenen Zukunfts geredet. Es gab ein paar andere Projekte, über die ich gearbeitet habe, zum Beispiel für iOS 8.1 bis ganz vielen verschiedenen Sorten von Jailbreaks und selbst ein Jailbreak für die Apple Watch. Was ist denn dieses Jailbreaking aus dem Empfängnis ausbrechen übersetzt? Wir versuchen, Kontrolle über das Gerät zu gewinnen, was wir besitzen. Wir wollen die Sandbox aus der Sandkiste ausbrechen. Wir wollen Rout bekommen. Wir wollen Codesignung ausführen können. Wir wollen Codesignung ausschalten, damit wir selber Binarys ausführen können. Am populärsten ist es, dass man schöne Tweaks installieren kann. Manche Leute installieren auf Jailbreaks, um die Sicherheit zu analysieren. Zum Beispiel um Dinge zu debaggen. Dafür braucht man Jailbreak. Was sind diese Tweaks? Tweaks sind normalerweise Änderungen von User Space Programmen, zum Beispiel Springboard, das ist der Launcher, da sieht man, Springboard ist der Launcher, da sieht man die verschiedenen Icons. Und so was könnte man dann zum Beispiel verändern, wenn man einen Jailbreak hat. Das waren die Anfänge von Jailbreaking. Was auch dabei ist, ist häufig Cydia. Cydia ist DPKG, das ist ein Package Manager. Und Cydia ist ein DOE für diesen Package Manager. Es heißt zwar dezentralisiert, aber es ist zentralisiert, weil man die App öffnet und da schon Apps da sind, aber man kann es auch dezentralisiert, weil man andere Repositories hinzufügen kann. Man kann Tweaks kriegen. Normalerweise kann man Brust aus dem App Store herunterladen, aber mit Cydia kann man überall herladen, so wie in Debian. Die Vortrag ist strukturiert, wie dieser Tweet hier darstellt. Es gibt drei verschiedene Zeitalter von Jailbreaking. Es gibt das goldene Zeitalter, das industrielle Zeitalter und das postapokalyptische Zeitalter. Ich werde euch jetzt durch die verschiedenen Stufen von Jailbreaking durchdenken. Beim ersten Jailbreak vom ersten iPhone haben wir doch nicht den Bootrom angegriffen. Das erste war einfach ein Buffer Overflow und eine Bibliothek vom iPhone. Das ist eine Library, die benutzt wird, um Bilder zu analysieren. Das wurde von Safari benutzt und wurde dazu benutzt, um Code auszuführen. Das war das erste Mal, dass Software, die nicht von Apple kam, auf einem iPhone ausgeführt wurde und Leute haben Anwendungen installiert. AppTap zum Beispiel, die wie ähnlich waren wie Cydia, die wurden benutzt, um Spiele oder Anwendungen zu installieren. Am Anfang war nämlich nicht möglich, irgendwie Anwendungen zu installieren. Das heißt, der App Store wurde erst mit iOS 2 in Zug geführt. Dann war dann die goldenen Zeit. Es ging um den Bootrom. Leute haben sich den Bootprozess angeschaut und haben diese Gerätfirma Upgrade Modus im Rom gefunden. Der bekannteste Bootrom-Exploit war Lime Ring und das war ein Back in der Hardware. Das konnte von der Software nicht verändert oder verbessert werden. Das konnte bis iPhone 4 verwendet werden. Es gab auch noch ein paar andere Jailbreak. Wir waren nicht der Einzige, aber als wir das benutzen, konnte man das einfach immer weiter benutzen. Später, eine neue Hardware-Version des iPhone 4s wurde das dann gefixed und mit diesem Bootrom war wie Tethered Jailbreak entstanden. Man musste es in einen speziellen Modus starten und da kann unsignierte Software über USB geladen werden. Aber wenn man das Gerät neu startet, muss der Computer den Exploit wieder ausführen und den unsignierten Code auszuführen und der Bootloader geladen werden kann und der veränderte Kern. Darum war der Jailbreak mit dem Computer verbunden. Ein Tethered Jailbreak-Phone kann überhaupt nicht buten, wenn kein Computer da ist, weil der Jailbreak den Kern im Dateisystem verändern würde, um die Performance zu steigern, damit, wenn man das angeschlossene Boot startet, muss man nur ein sehr kleines bisschen Code per USB übertragen und der ganze Rest kommt vom Dateisystem. Das zerstört den Vertrauensystem, wenn der Bootloader startet und die Signatur überprüft, dann wäre diese ungültig und es würde nicht mehr buten. Ohne Computer butet das Phone dann nicht mehr. Dann wurde eine Idee von einem semi-angeschlossenen semi-tethered Jailbreak. Es ist aufgekommen. Was wir anders machen, ist, wir modifizieren nicht den Kernel auf dem Dateisystem. Wir schauen uns den Bootloader überhaupt nicht an und wenn man dann mit einem Computer bootet, muss man den gesamten Bootloader, den ersten Schicht, die zweite Schicht, den E-Boot und dann den Kernel per USB nachladen, um einen Jailbroken-Modus zu buten. Wenn man neu startet, wird das ganz normal in einem nicht Jailbreak-Mode gebooted. Wenn man keine Tweaks oder Modifikation installiert, die kritische Systemkomponenten verändern, wenn man die Signatur von gewissen Binärdateilen, also Programmen verändert, dann wird das nicht mehr im normalen Modus buten. Die Programme würden da nicht funktionieren. Das war dieser goldenen Zeitalter. Bis nächstes, der das industrielle Zeitalter mit Beginn von 4S und iOS 5, hat Apple diesen Bootraum-Bug repariert und der Ganze funktioniert nicht mehr. Außerdem wurden AP-Tickets und andere Sachen hinzugeführt und das ist eine Idee von Downgrading. Vorher konnte man einfach eine alte Version installieren, die angreifen. Aber danach konnte man nicht mehr eine alte Version vom iOS installieren. Wenn ihr euch mal anschauen wollt, wie das mit dem Boot funktioniert, könnt ihr euch den zwei Jahre alten Vortrag anschauen, wo wir uns näher anschauen, wie das Ganze funktioniert. Dann schauen wir uns dieses Mal gar nicht an. Die Binärdateilen, also die Boot-Binärdateilen, sind verschlüsselt und bis vor kurzem war sogar der Kernel verschlüsselt und eine wichtige Entschlüsselungskie ist in den Geräten und wir können den nicht normal herankommen. Es gibt keinen öffentlichen Fall, wo diese Schlüssel herausgefunden wurden. Wahrscheinlich ist es also unmöglich. Alte Boot-Dateien wurden beim Boot-Modus vom vorherigen Bootloader entschlüsselt und vor dem iPhone 4S konnte man mit dem der Hardware-Systemen reden, sobald Kernel-Modus erreicht wurde. Jetzt wird aber dieser iOS-Engine ausgeschaltet und deswegen können Bootloader-Dateien überhaupt nicht mehr entschlüsselt werden, außer man hat eine Code-Execution im Bootloader. Das heißt, jetzt wird dieses Entschlüsseling von Bootloader deutlich komplexer geworden. Deswegen wurden viel mehr User-Land-Systeme angegriffen und jetzt kann es nicht mehr tethered sein. Das heißt, früher war es immer noch jailbroken, wenn es ein Reboot durchgeführt würde. Wir können zum Beispiel eine Konfigurations-Dateien irgendwo hinzugeführt, die Bugs ausführen und dann ein jailbroot gemacht. Das heißt, sie wurden mehrere Bugs hintereinander gehängt und darum kriegt man dann eine Persistenten-Systeme auf dem Gerät. Das hat sich geändert, nachdem Apple-Kostnose-Developer-Accounts eingeführt hat mit iOS 9. Das erlaubt allen Leuten mit einer Apple-ID für sieben Tage zu bekommen. Das heißt, man kann einfach ein Programm ausführen auf sein physisches Gerät. Das ging früher nur, wenn man einen bezahlten 400-Dollar-Developer-Access bekommen hat. Aber jetzt kann man einfach nach sieben Tagen eine neue Certificate kriegen und dann kann man das immer wieder tun. Das reicht komplett, wenn man Apps entwickelt. Das hat zu semi-anteilwert jailbrakes geführt. Initial Code execution ist nicht mehr ein Problem, also dass man am Anfang Code ausführen kann. Das heißt, die jailbrakes haben sich mehr darauf konzentriert, um Kernelbugs zu explodieren, die man von innerhalb der Sandbox ausführen konnte. Die werden dann als IPA-Installable-App verteilt. Leute mussten das selber signieren und dann ausführen. Das heißt, man rebooted es in nicht jailbraken Modus, aber man kann es wieder hinkriegen mit einem Computer. Apple hat seitdem immer mehr Schutzmaßnahmen eingeführt. Mit iOS 5 kommt ASLR dazu und Kernel-ASLR, das ist Adressraum zu Randomisierung. Mit iPhone 5S gibt es 64-Bit TPUs, das ist zwar keine Sicherheitsmaßnahme, aber trotzdem ändern sich die Experts. iOS 9 mit iOS 9 kam Kernel Patch Protection. Das hat versucht, den Kernel immutabel zu machen, also nicht enderbar. Der nächste Schritt war mit iPhone 7 mit Kernel Text Only Region, das heißt KTIR, da ging es darum, dass der Kernel-Code nicht mehr modifiziert war. Mit iOS 11 wurden die 32-Bit Bibliotheken rausgenommen, damit hat man auch ein paar Sicherheitswirken rausgeworfen. Irgendjemand musste dann einen Xploit in 64-Bits neu komplieren, mit dem iPhone XS kam Pointer Authentication Code dazu, also Pointer Authentifizierungs Code. Ich werde darüber in den nächsten paar Slides reden. Was ist Kernel Patch Protection? KPP nennt Apple watchtower Wachtum. Es schaut sich den Kernel an und löst ein Kernel-Panning aus, wenn Änderungen entdeckt werden. Die Idee ist, dass es den Kernel davon abhält, gepatcht zu werden. Wie funktioniert das? Wachtower läuft auf dem EL3 in Arm-Exception Level 3. Das ist eine Art rechte Level und 3 ist der höchste. Man kann Exceptions nutzen, um Händler-Code von höhereben Ebenen zu kochen. Man kann wiederkehren Ereignisse, die den Watchtower auslösen. D.h. wir haben links ein Watchtower, der so aussieht wie ein Leuchtturm. In der Mitte haben wir den Kernel, dem Level 1, das ist etwa, wie der Kernel aussieht. Wie kpp funktioniert? Ein Event kommt von Size-to-Time, von dem New Zealand, wegen der Floating-Panning-Abratung. Das triggert ein eigenes Watchtower, scannt den Kernel. Falls alles okay ist, geht es wieder zurück in den Kernel und dann am Schluss wieder zurück in den User-Space. Aber mit einem modifizierten Kernel würde der Watchtower die Änderung erkennen und paniken. Die Idee ist, dass Kernel gezwungen ist, den Watchtower zu aufzurufen, weil ansonsten die FBU komplett geblockt wird. Das Problem ist, der Kernel ist in Kontrolle, bevor der Watchtower aufgerufen wird. So wurde es dann umgegangen. Die Idee ist, wir kopieren den Kernel im Kernel, wir modifizieren den kopierten Kernel, dann modifizieren wir den Page-Tables, um den gepatcheden Kernel zu benutzen. Falls die FBU dann ein Inspection triggert, dann gehen wir zurück zu der unmodifizierten Kopie in den Watchtower. Wenn der Watchtower fertig ist, dann gehen wir natürlich wieder zurück zum modifizierten Kernel. So sieht das dann aus. Wir kopieren den Kernel im Speicher, wir patchen die modifizierten Kernel, dann tauschen wir die Page-Tables, um das, was wir benutzen, zu ändern. Wenn wir den FBU-Event kriegen, dann switchen wir die Page-Tables wieder zurück, und dann kriegen wir den Call zum Watchtower, der Watchtower scans den unmodifizierten Kernel, und dann gehen wir wieder zurück zum gepatcheden Kernel und fertig. Das Problem hier ist Time of Check versus Time of Use. Das funktioniert auf I5, 5S, 6S, 6S und das ist nicht wirklich patchbar. Mit Iphone 7 und higher haben wir KTRR, das verbessert das Ganze und hat ein weniger patchbaren Kernel. Wie funktioniert KTRR? KTRR ist ein Speicherkontroller, der alle schreibt zu nur lesen Regionen. Es sind ächste CPU-Bereiche, die ausführbare Bereiche speichert. Sie definieren einen Bereich der Read-Only-Region. Wir haben einen Bereich, wo man nur lesen kann und wir haben einen speziellen Bereich für ausführbaren Arbeitsspeicher. Hier haben wir die CPU, den Arbeitsspeicher hier unten und wir setzen die Region, wo man nur lesen darf, während wir boten. Das wird vom Hardware-Manager-Memory-Controller verifiziert und alles innerhalb ist nicht schreibbar und alles außerhalb kann man schreiben. Und die CPU hat diese Register, die den Anfang und den Ende definieren und die ausführbare Region ist ein Teil der nur lesbaren Bereich. Alles außerhalb kann nicht von der CPU ausgeführt werden. Alles, was innerhalb ist, kann nicht modifiziert werden. Und das ist nicht wirklich umgangen worden. Es gibt eine Umgehung, aber die definiert nur, wie das fest, wie das ordentlich, wie das eingerichtet wurde und das wurde gefixt und jetzt geht das nicht mehr. Dann haben wir wenn wir noch jailbrakes, wie funktioniert das? Nein, die arbeiten einfach um, haben wir keine Kernelpatches und das ist, wie KTR jailbrakes funktionieren. Die patchen den Kernel einfach nicht. Bevor wir uns das näher anschauen, können wir uns anschauen, was früher von Indian Kernels verändert wurde. Generell wollen wir Code-Signing ausschalten, wir wollen die Sandbox ausschalten, wir wollen das System schreibbar machen und wir wollen Veränderungen, so kriegen das gewisse Veränderungen funktionieren. Und ich wollte eine Liste von Kernelpatches machen, die wir uns einfach anwenden können, aber die Patches sind ziemlich unterschiedlich zwischen unterschiedlichen jailbrakes und ich könnte auch nicht mehr eine Liste von denen erstellen, die von unterschiedlichen jailbrakes sind, die ich gearbeitet habe. Das heißt, es gibt keine generelle Liste, man gibt versuchen diese Art oder andere, eine andere und ein Schälter in der vollen Liste mache ich als Beispiel eines Patches, und zwar Helix. Helix hat nur prüft den ICANN-HasDee-Bagger, das ist ein Boot und Variable im Kernel und wenn man das auf wahr setzt, dann wird die Sandbox reduziert. Das heißt, um kurz ein Ding auszuschalten, brauchen wir mehrere Schritte. Außerdem, seit iOS müssen wir Mount überschreiben, weil dort definiert ist, dass das Routefile-System nicht mit Schreibrechten gemountet werden kann. Außerdem können wir das Routefile-System nicht ohne No-To-ID schreiben, das heißt, wollen wir auch entfernen und wenn wir die beiden ausschließen, können wir das Routefile-System read-write, mountain, aber wir können dem noch nicht draufschreiben, außer wir patchen Lightweight-Volume-Manager, das müssen wir auch nur in iOS 9 bis 10.3 machen. Später, wenn Sie ein neues Teilsystem benutzen, müssen wir das nicht mehr machen. Außerdem ist da eine Variable proc-en-force, die müssen wir auf 0 setzen, um Code-Signing auszuschalten. Das ist eine der Sachen, die wir machen müssen. Eine weitere Flagge ist Disable-CM-Enforcement, das müssen wir auf 1 setzen, damit mit Code-Signing ausgeschaltet wird, um Reiterstritte. Dann gibt es noch einen, der kümmert sich über die Verifikation von Codes-Signation. Der wird mem-copy benutzt und eine Idee ist es mit einem Stop vom mem-copy-Mach. Mem-Copy-Mach, wenn man Arbeitssprache auf Vergleich macht und es wird einfach so geschrieben mit einem Stückchen Code, das immer 0 zurückgibt. Ich weiß nicht genau, was es macht, der Patch ist ziemlich alt, zurück zu Yalu, aber wenn man das benutzt, kann man einen unsignierten Code ausführen, darum ist es da. Es schickt, erlaubt jeden, die Wiederüberprüfung von Code-Pages überprüfen. Ursprünglich war das für Stibagen, weil da auch Code während des Ausführens verändert werden muss, um Breakpoints zu setzen. Dass wir hier versuchen, ist, dass einfach Tricks funktionieren. Da hat Helix auch noch einen weiteren Patch der Update-XVE-Funktion überprüft. Das ist damit eine Federnachricht auszuschießen in ein paar Prozessen. Es zerstört auch Sandboxing und deswegen, wenn man mit Helix inserdiert und sprichern die Sachen in ihren globalen Ordnern und ihren Sandbox-Ordnern. Also, den zerstört mir noch ein paar Checks bei Make-Policy, wenn man die Sandbox reduziert. Außerdem, wenn ich näher anschauen wollte, wie das funktioniert, leider ist Helix nicht open sourced und ich werde es nicht open sourced, aber es gibt zwei sehr, sehr ähnliche Projekte, die open sourced sind. Das ist Double Helix. Das ist ziemlich gleich, aber für 64-Bit Geräte, die KPP-Beinhalte, das heißt Patch in Kernel und Jailbreak Time, das ist die Uhr. Helix ist für iOS 10 und Jailbreak Time ist iOS 11, das heißt viel Patch Code ist der gleiche. Das heißt, wenn ihr euch das näher anschauen wollt, schaut euch diese beiden an. KPP, das ist Jailbreak. Die Idee ist, den Kernel nicht zu modifizieren, sondern zu verändern die Daten. Also, zum Beispiel, wir wollen das Route-Datei-System wieder am Mountain. Wir haben hart kodierte Checks, die versorgen, dass das Route-Datei-System nicht mehr schreibbar in den Mountain werden kann. Im Kernel gibt es eine Struktur, die das Route-Datei-System anzieht. Wir können diese Struktur ein bisschen verändern und dann können wir etwas sagen, hey, mount dieses Route-Datei-System noch mal und dann setzen wir die Flaggen wieder. Wir haben diese hart kodierten Checks und Gang. Um Cod-Signing auszuschalten und Sandboxen auszuschalten, gibt es unterschiedliche Herangehensweisen. Ein Vertrauenscash ist, die kümmert sich darum, dass das Cod-Signing läuft. Weil das Steaman muss auch signiert sein. Wir haben einen Hund und Ei-Problem. Darum ist im Kernel eine Sammlung von erlaubten Dateien, von Hash's von erlaubten Dateien. Darauf können wir schreiben und wir können da unser eigenes Hash hinzufügen, um ein Datei auszuführen. Ein weiterer Herangehensweise von Jay-Bagdy im neuen ist, dass ein Prozess läuft. Jay-Bagdy, der die Prozesse, wenn sie starten, verändert. Das heißt, sobald der Prozess startet, wird der Prozess angehalten. Man geht in den Kernel, schaut die Struktur an und entfernen die Struktur, die sagen, hey, zerstöre diese Prozess, wenn die Cod-Signing nicht funktioniert. Wenn das gemacht wurde, dann wird der Prozess weiter gestartet und der läuft dann einfach weiter, weil er schon als vertrauenswürdig markiert ist. Und eine dritte Herangehensweise, die von Bazette gezeigt wird, ist M4D im Benutzerumfeld komplett zu übernehmen. Das heißt, wenn man ein Mac-Port zu Launch diebe kommt, zu M4D, kann man so tun, als sei man das. Immer, wenn gefragt wird, ist das vertrauenswürdig, sagt man, yo, das ist in Ordnung und führt es außen. Darum müssen wir keinen Kernel-Modul überhaupt anfassen. Was kann in der Zukunft passieren? Kernel-Patches sind nicht mehr möglich und sind nicht mehr notwendig, weil wir können den Kerneldaten verändern und den Kernel überhaupt nicht involvieren. Aber wir sind immer noch nicht fertig. Wir haben immer noch postapokalyptische Herangehensweisen oder postapokalyptik-Codes PACK, also PACK steht für Point-Authentifikationscodes. Point-Authentifikationscodes werden von iPhone 6s benutzt und das ist eine strengere Version von Stack-Authentifikationen. Das ist ähnlich zu Message-Authentifikationen, aber für Point-Authentifikationen. Das heißt, wenn ihr Message-Authentifikation-Codes kennt, dann könnt ihr das so ähnlich. Die Idee ist, dass man die Daten mit dem Kontext zusammen und den Secret Key häscht. Das ist zum Beispiel die Return Value oder Stack-Pointer. Funktions-Pointer sind wichtig oder Dinge aus dem V-Table. Wenn wir uns anschauen, wie PACK implementiert ist, dann sehen wir die Funktionsprolog links und wenn wir das rechts daneben anschauen, dann sehen wir einfach noch ... Zudem tun wir erst die Authentication bevor irgendetwas anderes passiert und dann kriegen wir eine Signatur und wenn wir wieder rausgehen aus der Funktion, dann schauen wir uns die Signature wieder an und schauen, ob die beiden Signaturen gleich sind. Wenn das so ist, dann return wir, ansonsten kriegen wir ein Hardware-Fault. So sieht es aus mit 64-Bit-Pointers. Man nutzt nicht alle vorhandenen Bits. Zum Beispiel, wenn wir Memory-Tagging benutzen, dann haben wir sieben Bits mit Memory-Tagging oder 15 Bits ohne Memory-Tagging. Die grundsätzlich Idee von PACK ist, Rob-ähnliche Attacken zu verwenden, Return-Orientated Programming. Man kann nicht mehr den Stack kaputt machen. Wir können nicht mehr die Return-Adresse ändern weil wir jeden einzelnen dieser Pointer signieren. Aber das können wir nicht, weil wir die Pointer nicht kennen. Wir können nicht mehr die Return-Value verändern und auch nicht zwei davon zoppen. Wie können wir das umgehen? Ich weiß nicht, wie. Mal gucken, vielleicht. Aber wir können uns anschauen, wie es implementiert ist. Wenn wir uns die Armslides anschauen, dann sehen wir das PACK, berechnet wird von einem Pointer, einem 64-Bit-Context und einem Secret Key. Der Algorithmus P kann entweder Karma sein oder irgendwas Implementationsdefiniertes. Die Arminstruktion versteckt dann diese tatsächlichen Implementierung. Es gibt zwei mögliche Angriffstrategien. Wir können direkt auf den Primitiven gehen, Kryptografisch angreifen oder wir können die Implementierung angreifen. Falls wir die Implementierung angreifen, können wir uns nach Signierprimitiven umschauen, um Dinge zu signieren. Entweder für beliebigen Kontext oder vielleicht für einen fixierten Kontext. Wir können auch uns nicht authentifizierten Code anschauen. Zum Beispiel das, was PACK aufsetzt, ist wahrscheinlich noch nicht dadurch geschützt. Vielleicht ist dieser Code noch da. Was wir auch probieren könnten, ist, einen Pointer zu ersetzen, die den gleichen Kontext haben. Das ist wahrscheinlich nicht möglich für Return-Values, aber vielleicht für V-Tables. Oder vielleicht auch mit eurer eigenen cleveren Idee. Ich möchte hier sagen, dass es nicht so besonders sinnvoll ist, den kryptografischen Primitiv anzugreifen. Wenn wir PACK anschauen, dann lohnt es sich eher, die Implantation anzugucken als die Kryptografie dahinter. Wenn wir uns dieses Karma näher anschauen, das ist eine der möglichen Implantationsmethoden für PACK zu benutzen, ist eine veränderbare Blog-Cypher. Das heißt, man kriegt einen Input und einen Tweak und kriegt einen Blog. Als ich mir näher angeschaut habe, habe ich festgestellt, dass Karma potenziell ein paar Angriffsmethoden hat. Wenn es irgendwelche in der Zukunft gibt, wahrscheinlich, das, was ich glaube, komplett irrelevant sind bei der Sicherheit auf PACK. Warum? Wenn wir, ich mache nur ein paar Beispiele, die in den nächsten paar Zeilen werden, ein bisschen mit Mathe voll sind, das ist nicht zu komplex. Wenn wir jetzt PACK definieren, als eine Funktion, die ein 128-Bit Input benutzen und das auf einen 15-Bit Output verifizieren, oder wir können besser definieren, einen 69-Bit Input nehmen, der auf ein 128-Bit Key benutzt, weil wir diese Pointer länger haben, weil der Bereich, wo die Signatur steht, wir hätten wahrscheinlich den Sack-Pointer als Situation benutzen. Er wird auch ... Ja. Dann haben ... definieren wir einen Angreifer mit folgenden Fähigkeiten. Der Angreifer kann ein Teil der Pointer und Signaturpaare beobachten und wir können das irgendwie bekommen, also Humbug irgendwo und für Leute, dass wir ein Teil des Stacks veröffentlichen lesen können. Da sind ein paar signierte Pointer. Darum können wir ein Paar ... Wir können es mit einem Paar anschauen und wir können jetzt auch davon ausgehen, dass ein Angreifer den Kontext leicht verändern können. Das heißt, die Situation, wo der Angreifer vielleicht den Stack durch ein paar weitere Funktionen verschieben kann, sodass wir zwei Signaturen für den selben Pointer sehen können, damit unterschiedlich ins Kontext. Das könnte eventuell hilfreich sein. Aber immer noch sehen wir, dass ein Angreifer, ein kriptografischer Angreifer, immer noch sehr schwach ist. Die einzige andere kriptografische Problem, dass wir haben, könnten wären Kollisionen. Leute, die mal im letzten Vortrag gesehen haben, wissen Sie, dass ich Kollisionen lieber. Wir haben 84-Bit Pointer, 84-Bit Kontext und 128-Bit Schüssel. Wir schauen das an. Wir haben 15-Bit vom Output und es bedeutet, dass wir zwei hoch 209 möglichen Kollisionen haben, weil wir so viele Bits auf so wenige Bits weiter produzieren. Erst wenn wir die Pointer reduzieren, weil im Endeffekt haben wir wahrscheinlich 30 Bits vom Pointer, die wirklich benutzt werden, haben wir immer noch zwei hoch 181 Kollisionen. Das sind immer noch sehr viele Kollisionen. Aber leider sind zufällige Kollisionen nicht sonderlich sinnvoll, außer wir können sie erraten. Wir können wissen, welches werden. Lass uns mal ein paar kriptografische Sicherheit vom MAC ins Einschauen. Lass uns mal ein MAC mit folgenden Komponenten sein, also Message-Authentifikationscode. Wir haben ein MAC, das ist ein Signierer und ein Verifizierer. MAC hat ein Key, der ist einfach nur da, weil wir ihn brauchen, das sind einfach N-Bits, die magisch erscheinen. Und MAC ist eine Funktion, wir können die Nachricht hinzufügen und die N-Bitten langer Nachricht hinzufügen und wir kriegen eine Signatur T, ein Message-Authentifikationscode, ein Nachricht-Authentifikationscode. Verify kriegt eine Nachricht und eine Signatur und gibt wahr zurück, wenn die spast und sonst falsch, wenn da irgendwie ein Fehler ist. Und wenn Kriptographen beweisen, dass etwas richtig ist, dann spielen sie Spiele. Und jetzt mein Lieblingsspiel, das nennt sich Macforge-Spiel, links haben wir den Spiel Meister, der Forge spielt und rechts haben wir den Angreifer. So, das Spiel beginnt damit, dass der Macforge-Game-Master den Angreifer darüber informiert, wie viele Bits benutzen werden soll. Er sagt, hey, wir machen Macforge mit 46 Bitten Nachrichten. Der Angreifer weiß jetzt, wie groß die Nachrichten sind. Dann generiert der Game-Master den Schlüssel. Der Angreifer kann nun bis zu Q-Nachrichten auswählen von M-Bit Länge und kann sie zum Game-Master zurück schicken und der wird Signaturen zurück senden. Und jetzt hat der Angreifer die ganzen Nachrichten, die er generiert hat sehen, die ganzen Signaturen, der zu passen. Und das jetzt der Angreifer tunen kann, ist eine weitere Nachricht auswählen, die er bis jetzt noch nicht gesendet hat und irgendwie auf einen gültigen Signatur dafür finden. Und wenn er das tunen kann, dann sendet er sie rüber und wenn das wirklich stimmt für diese Nachricht dann gewinnt er das Spiel und ansonsten verliert er das Spiel. Und wir sagen, eine Mech ist sicher, wenn die Wahrscheinlichkeit, dass ein Angreifer dieses Spiel gewinnen kann, nicht relevant ist. Wir reden jetzt nicht darüber, was da der Grenzwerte ist, aber wenn man einfach rät, dann passt das nicht. Es ist nicht signifikant. Was wir jetzt sehen, ist eine Mech, die um sicher zu sein, dass hier sicher sein muss. Aber für unseren Pack-Angreifer haben wir dieses Oracle gar nicht. Das heißt, unser Angreifer für Pack ist noch schwächer als das. Warum haben wir dieses Oracle nicht? Weil wenn wir dem Angreifer beliebige Nachrichten signieren lassen, dann würde der Angreifer überhaupt nicht versuchen müssen, diesen Key zu fälschen. Man könnte einfach alle Nachrichten, die er signiert haben, die Hinten und signierte Punkte zurückbekommen. Weil dann müsste die Frischschüsselung gar nicht aufgreifen. Das heißt, was ich hier definieren möchte, ist, dass der Pack-Angreifer nicht so stark ist wie ein Mech-Angreifer. Das heißt, alle sicheren Mech können auch ein sicheres Pack sein. Aber auch ein unsicheres Pack kann immer noch, eine unsichere Mech kann immer noch ausreichend sicher sein und die Mech sind schon sehr bekannt. Und ich bin jemand, der etwas macht, weil er weiß, wie wir das machen sollen. Und ein 90-Tag-Ein-Pack-Algorithmus-Design, denn wird es sehr wahrscheinlich sicher sein. Das heißt, anstelle diese Krypto anzugreifen, sollten wir die Implementationsangriffe lieber anschauen. Wir können entweder schauen, wie die Krypto selber implementiert ist, aber was ich mir da besonders anschauen möchte, ist, wie das Pack im Code benutzt wird. Das heißt, vielleicht sind der Signations-Orake, vielleicht ist das unauthentifizierte Code. Und das ist, was wir uns anschauen müssen, wenn wir irgendwie Pack umgehen wollen. Jetzt, um nochmal anzuschauen, wäre willkommen, zukünftige iPhone-Hacks werden wahrscheinlich überhaupt nicht versuchen, KTRR zum gehen. Und keinen gar nicht versuchen, den Kernel-Code zu modifizieren. Weil wir können alles, was wir machen wollen, um den Endbenutzern damit zufrieden ist, ohne den Kernel zu modifizieren. Außerdem werden Leute Bar-Probleme haben, wenn ein Export mit Pack schreiben wollen, weil das wird entweder ein Pack und nicht anexploitable oder nicht mehr benutzbar machen oder sehr schwer machen. Vielleicht ist es, wenn wir den Kernel komplett umgehen, weil J-Brakes, die nur im User-Lens sind, sind möglich. Vielleicht müssen wir Roy anschauen, was die einfachen, eingrößten Tosen sind. Einfach mal anschauen, was da möglich ist. So, das war's. Vielen Dank für Ihre Aufmerksamkeit. Und jetzt haben wir ein bisschen Zeit für Fragen. Thank you, Teamster. If you would like to ask a question, please line up on the microphones in the room. We do not have a question from the Internet. Wir haben keine Frage aus dem Internet. Eine Frage von dort drüben. Hallo. Ich würde gerne wissen, was dein Kommentar bezüglich ist, dass J-Breaking gar nicht mehr was so ein Ding ist, weil man so viele Sicherheitssachen kaputt macht, dass das alles nur unsicherer macht. J-Breaking, ich glaube nicht, dass J-Breaking irgendwie heutzutage das Telefon unsicherer macht. Natürlich, wenn man den Kernel patcht und die Sicherheitsfeatures ausschaltet, das fühlt also, dass es weniger sicher ist. Aber wenn wir uns anschauen, was wir hier haben mit dem Unpatch-Beeren-Könne, dann ist die größte negative Seite, dass wir nicht mehr die aktuellste Version von SourceJay benutzen können, weil wir die Box darin haben wollen, um ein J-Break ausführen zu können. Ich glaube nicht, dass wenn wir ein KTRR-Gerät haben, dann wird die Sicherheit reduziert. Nur, dass wir eine vereiltete Version haben, das ist der unsichere Teil davon. Okay, danke. Mikrofon Nummer 2. Könntest du zurückgehen zu den Möglichkeiten des Gegners? Was wir tun können, ist ein paar Pointer- und Signaturen beobachten können. Warum ist das kein Oracke? Weil wir die Nachrichten selber wählen können. Aber ja, wenn man das Spiel sich anschaut, dann kann sich der Angräfer viele Nachrichten ausdenken. Und es kriegt eine Signatur. Der Pack-Angräfer hingegen kann nur sehr wenige Nachrichten sehen und die der zugehörigen Signaturen. Und er kann wenige, gar nichts darüber herausfinden, welche Nachrichten überhaupt signiert werden sollen. Also, das ist nicht so stark. Haben wir noch eine Frage aus dem Internet? Sieht nicht so aus. Ja, bitte. Keine Frage aus dem Internet. Ich sehe auch niemanden an den Fragen. Bitte einen schönen Applaus für Teamstar. Damit verabschieden wir...