 Wir sind Problem und Kati und wir sind auch froh um jede Form von Feedback auf Twitter unter dem Hashtag C3T. Vielen Dank, ich bin Timstar und ich werde heute meinen Vortrag downgrading alles von Pasta Present halten. Es geht um die iOS Bootkette und wie sie sich über die Versionen verändert hat. Ich werde über SSH Blobs und AP Tickets sprechen. Ich spreche über die Downgrade Methoden, die es so in der Vergangenheit gab. Das ist ihrem G3, ihrem G4 Teilformat und spreche über das Seepause Problem an Basement Downgrading und spreche über Probleme bei den neuen 64-Bit Geräten. Ihr seht hier die iOS Bootchain, die iOS Bootkette, was da passiert. Wir haben hier im Prinzip zwei Pfade. Wir haben einmal den normalen Boot und den DFU-Modus. Der DFU-Modus ist der, der gewählt wird, wenn ein System geupgraded wird. Was ihr hier sehen könnt, ist der Bootraum zuerst, dann die beiden Stage Bootloader. Das sind dann IBSS und IBEC. Für 64-Bit Geräte gibt es dann noch die Seepause Bootstage. Wenn ihr über die DFU-Bute geht, dann wird eben einer RAM-Disk und Kernel gebotet und das wird genutzt, um das System wieder herzustellen. So, spreche mal ein bisschen über iOS-Geschichte. Wir hatten das iPhone 2G mit iPhone OS 1 bis 3 und die waren vorsigniert und das Downgrading war einfach möglich, auch herstellerseitig. Mit dem iPhone 3G hat sich das dann geändert, während es unter iOS 2 und 3 noch gleich war. Unter iOS 4 hat Apple dann SAS-H-Checks eingebaut und dann war das Downgrade nur noch möglich mit ein paar Hecks. Also schauen wir uns mal an, wie die Bootchain auf einem iPhone 3G unter iOS 4 funktioniert. Ich spreche jetzt nur über iPhones, aber das passt auch auf iPods und iPads, wenn es halt die gleiche Hardware ist. So, was ihr hier sehen könnt, ist, dass die Bootkomponenten sich, je weiß, checken. Das heißt, der First Stage Bootloader checkt den Second Stage Bootloader und so weiter. Aber ihr seht hier genau ein Ding. Der Bootraum checkt eben nicht die First Stage, egal ob IP oder IBSS. Und das heißt, wir könnten die verändern. So, was sind also nun diese SAS-H-Blobs? Apple hat die eingeführt, um kontrollieren zu können, welche Version von iOS auf eurem Gerät installiert ist. Und die werden von Apple angefragt, jedes Mal, wenn ihr euer Gerät wiederherstellt. Und das ist im Prinzip ein signierter Hirsch der Firmware von eurem Gerät und die ECID und ist damit eindeutig für jedes Gerät. So, wenn wir uns jetzt SAS-H und MG3 angucken, seht ihr auf dem linken Bild einen Baum mit einigen Einträngen und da sind einige Texte, die besonders interessant sind. Diese MG3 Texte sind unter anderem diese, die ihr auf dem rechten Bild seht, die wir euch aus dem iPhone Wiki habe, die iBoot Version, welche Version vom Chip wieder sehen können. Und wir sehen unter anderem SAS-H. Und SAS-H ist ein RSA-verschlüsselter SHAR1-Hash von der Datei. Das heißt, wenn man das mal in einem Hexeditor aufmacht, sehen wir ein paar IMG3-Tags. Und einen, den ich hier hervorgehoben habe, ist ein SAS-H-Tag. Und unter diesem SAS-H-Blob seht ihr einen Zertifikat, das Apple's Public Key beinhaltet, das man nutzen kann, um die Signature auf dem SAS-H-Blob zu verifizieren. In der iOS-Geschichte ging es dann weiter mit dem iPhone 3GS und iPhone 4, wo sie im Hardware forcierte SAS-H Überprüfung implementiert haben und seit iOS 5 hat Apple das Ganze erweitert um AP-Tickets. Das schauen wir uns dann erst später. Also die Bootkette auf Geräten iPhone 4, iPhone 3GS vor iOS 5 sah im Prinzip genauso aus wie wir es eben schon kannten, nur dass eben der Bootrom die SAS-H-Blobs verifiziert. Das ist auch der einzige große Unterschied. Wie downgraden wir jetzt diese Geräte unter iOS 3 und 4? So, SAS-H-Blobs sind ja einfach nur eine signierter Hasch von der Firmware. Und das heißt, wenn wir jetzt einfach Replay-Attacken fahren, speichern wir uns den SAS-H-Blob mit den bekannten Tools, z.B. Tiny Umbrella Studio oder iFace, und wenn Apple sie dann eben nicht mehr signiert, weil irgendwie der Fenster abgelaufen ist, kann man sie einfach replayen, indem man eine Man in the Middle-Attacke darauf fährt. So, mit AP-Tickets. Was kam da jetzt dazu? AP-Tickets sind ASN1 formatierte Container, die EZ, eine Border-D und Chip-ID beinhaltet, Hashes von den ganzen Boot- und Firmware gefeiert und ein kryptographisches Einmal-Token, ein Nonz, das zusammen mit, das eben zusammen in diesem EMG-3 Image gepackt ist. Das heißt, auf 32 Bit-Geräten unter iOS 5 und später, das wurde halt auch im Nachhinein für die andere Geräte entführt, haben wir Bootchecks für die SAS-H-Blobs, aber danach kommen immer AP-Ticketchecks. Und zusätzlich im DFU-Modus findet eben eben die Erstellung dieses Nonze statt. Und das wird weiter durchgereicht. Und wenn man da jetzt den Firmware überschreiben möchte, muss man eben dieses Nonz irgendwie extrahieren und dann könnte man eben da eine Attacke fahren. Das ganze Checkout das AP-Ticket, aber es checkt das Nonz nicht, also der DFU-Modus. Er kann diesen Nonz nicht checken, weil wenn man das Nonz einfach so generieren würde, das würde ein neues Ticket anfragen. Und weil das Gerät der Boot-Lauder ist, dann geht es nicht möglich. Und das ist auch okay so. So, so sieht ein AP-Ticket aus, wenn man das mit ISS-1 dekodiert. Auf dem linken sieht man das so entdekodiert. Und auf dem rechten sieht man halt die genaue Liste der Device-Values. Man hat eine verschiedene Menge von Hashes und die korrespondieren mit denen die im Bild manifest stehen. Die, die ich markiert habe, da gerade ist das Apple-Logo-Hash und dann sieht man das Nonz und die Eiboot-Version und einigen anderen Kramen. Und am Ende ist noch die Signatur. Und unter der Signatur ist noch ein Set V-Card, mit dem man das ganze Signal, das am Ende signieren kann. Wenn man das in einem G3-File packt, dann ist es nichts besonderes, das sieht so aus. Man sieht das CAB, das ist der Identifier. Das ist sozusagen nur das AP-Ticket, menig. Und all diese Infos in einem Dokument über das Gerät zu speichern, ist halt so, dass speichert dann halt alles an einem Ort auch. Wie downgraden wir jetzt? Wir haben Limerane. Limerane ist ein Bootraum-Explode von Geohot. Das läuft bis zum iPhone 4. Und im iPhone 4s geht es leider nicht mehr. Und wir können das Bootraum halt damit booten lassen, egal, was wir wollen. Wir können das IP-Ticket patchen, in IBSS und Iback checken. Und dann kann man mit IBSS und IBC booten, ohne IP-Ticket. Danach restoren wir das vorhergespeicherte IP-Ticket und dann wird das nonz beim normalen Bootvorgang nicht geprüft. Und so, das hier ist eine Visualisierung, wie man mit Limerane downgraded. Man hat vielleicht das Bootraum. Man schickt das gepatchede IBSS und so und so und so. Und am Ende, wenn man mit dem relevanten IP-Ticket startet, dann ist alles okay. Und das System sieht es als valide an. Und was ist mit den neueren Geräten, wo wir Limerane nicht benutzen können? Hier habe ich noch ein paar Hintergründe dazu. Die Firmen-Dateien werden verschlüsselt. Und nach dem Kernel-Boot-Vorgang ist diese Decryption nicht mehr möglich. Bei allen Geräten vor iPhone 4s ging das noch und mittlerweile ist es aber in der Hardware deaktiviert. Um die Kies zu bekommen, die man braucht, kann man iBoot oder iBoot-Vorm benutzen. In der Jabra Community haben wir einige Leute, die private iBoot-Exploits haben. Und wir haben Leute, die private Hardware-Hacking-Techniken haben und die können halt diese Firmen-Welt-Kies abziehen. Und diese mit uns zu teilen, die findet man am iPhone Wiki. Die sind für ganz, ganz viele Geräte und iOS-Varianten verfügbar, nicht für alle, aber für die meisten. Dann haben wir K-Loader bei Windows-CM. Das kann ein Image aus dem Kernel-Modus bootstrappen. Dann kann man sozusagen zu den Bootloader zurückspringen mit IBSS. Jetzt haben wir diese alte Möglichkeiten. Wir haben Odysseus, ist eine Technik von Xerob. Er nutzt einen Jailbreak. Okayloader und Bootstrap zur IBSS. Ich nenne es KDFU-Mode, Kernel-DFU-Modus. Es ist ähnlich zu Pwn-DFU mit Limerain. Es wird einfach nur buten, und das kann man auch machen, wenn man ein entschlüsseltes IBSS patcht. Im Kernel-Modus hat es halt einfach die K-Loader-Modus-Variante. Man kann dann keine Firmware-Files mehr entschlüsseln. Die Lösung dafür ist, dass wir eine Custom-Firmware machen, dass die bereits entschlüsselten Dateien schickt. Dafür brauchen wir IBSS, I-Back, RUM-Disk, Kernel- und Filesystem, und diesen dann entschlüsselt. So sieht das aus, wenn wir Odysseus benutzen. Das Erste, was wir hier haben, ist der normale Bootvorgang. Und Altmeans meint vor dem ... Und dann haut man den Kernel, lässt einen K-Loader laufen, und hat dann IBSS und gepatcht. Nach außen verhält sich das genauso, als ob es in KDFU-Modus ist. Und das heißt, weil man das ansonsten nicht unterscheiden kann, nennen wir es halt KDFU-Modus. Dann würde man einfach einen normalen Restore laufen lassen mit einem validen AP-Ticket. Dadurch, dass hier das non-signoriert wird, können wir eben boten. So, was ich hier noch nicht erwähnt habe, ist das Baseband-Problem. Das Baseband ist ein Prozessor, der Kommunikation mit dem Mobilfunknetz regelt und ausführt. Und das ist separat. Und das Down-to-Graden ist derzeit nicht wirklich möglich, weil sich da die Sicherheit stark verbessert hat. Und die Leute interessiert es mittlerweile auch nicht mehr so stark, das Baseband-Down-to-Graden, weil mittlerweile eben die meisten Telefone frei verfügbar sind und dementsprechend die Nutzer nicht mehr so interessiert sind und da irgendwelche SIM-Unlocks durch ein Baseband-Hack zu bekommen. Aber aus den alten Tagen hat sich immer noch die allgemeine Praxis etabliert, dass man das Baseband nicht update, wenn man IOS upgraded, sodass man eben noch die alten Vulnerabilities im Baseband behält, obwohl man eine neue IOS-Version hat. Und aus diesen Zeiten kennen wir noch, dass viele nicht standard, nicht von der Apple vorgesehene Kombination aus IOS und Baseband funktionieren. Manche funktionieren nicht, aber die meisten funktionieren schon. So, wir wissen also, dass das neue IOS und das alte Baseband funktionieren, aber wir wissen auch, dass es funktioniert, wenn es genau andersrum ist, wenn der Abstand nicht zu groß ist. So, das heißt, in Odysseus benutzen wir genau diese Sache. Auf dem iPhone 4s ist das Baseband-Firmware auf einem Preisystem installiert. Das heißt, man muss die Firmware so patchen, dass sie eben das alte Baseband nicht updateet. Das heißt, man holt sich das alte Baseband vom Telefon, modifiziert dann die Firmware mit dem alten Baseband, aber der neuen Firmware und flasht das dann da drauf. So, dann gibt es noch Odysseus OTA, also over the air, durch die Luft, seit iOS 6.1.3 signiert Apple over the air Updates für iPhone 4s und iPad 2. Und das gleiche gilt auch für iOS 8.4.1 und einige andere Geräte. So, Apple Signs 6.1.3 für diese zwei Geräte, weil man eben nicht von iOS 5 direkt auf iOS 6 updaten kann. Und so wird dann eben irgendwie ein Upgrade Path hergestellt. Das gleiche gilt dann eben auch für iOS 8.4.1. Die Idee mit Odysseus OTA ist dann eben ein neues OTA-Ticket zu erstellen und auch ein neues Baseband-Ticket für den Rester zu erstellen. Das erlaubt uns tatsächlich dann, das Baseband wiederherzustellen, weil wir da keine gültige Signature für erstellen konnten, aber das geht jetzt so. Das wurde von Xerope und Mia ungefähr zur selben Zeit festgestellt. Wir haben unterschiedliche Techniken genutzt. Ich patche die Firmware-Bandels und er hat einen Kommando-Zeim-Parameter zu iDevice-Restaurern, zugefügt, wo man eben das ein anderes Manifester übergeben kann. Aber es ist im Prinzip dasselbe und wir kommen zum selben Ergebnis. Und das normale OTA-Ticket unterscheiden sich halt nur durch den RAM-Discash. Und das ist aber gar nicht relevant, wenn wir eben über Kailo oder Updaten. Und wenn wir das über das Update passiert, dann sind wir über iTunes Updaten. So, was sind dann die Limitationen von Odysseus? Es funktioniert nur für 32 Bit-Geräte und man braucht Firmware-Keyes, weil das Gerät eben nicht, weil das Gerät die Firmware ansonsten nicht entschlüsseln kann. So, man muss dann eben auch eigene Bandels erstellen und diese ganzen Patches machen und speziell die Firmware-Keyes und die Bandels sind gar nicht verfügbar für alle Kombinationen von iOS und Geräten. Und dann stellt sich noch die Frage, was ist eigentlich mit 64-Bit-Geräten? Denn auf den 64-Bit-Geräten hat Apple auf das IMD4-Format gewechselt und wir haben einen neuen Find, nämlich den Secure Enclave-Prozessor, der in den ganzen neuen iOS 64-Bit-Geräten verwendet wird. Der wird zum Beispiel für Touch ID, Dateisystemverschlüsselung verwendet und es ist Voraussetzung dafür, dass das Gerät buden kann, weil man eben ansonsten das Dateisystem nicht entschlüsseln könnte. So, es hat außerdem seine eigene kriptografische NONS im AP-Ticket, die sich auch im AP-Ticket befindet und da gibt es bisher keine bekannten Exploits. Dafür tut mir leid. Aber wenn wir uns das IMD4-Dateiformat anschauen, wie gesagt, es ist halt ein ASN1-formatierter Container, DER-encodiert und ein signiertes IMD4 ist dann eben ein Payload, IM4P und ein, ja, das sind zum Beispiel ein Bootfile, iBoot etc. und dann noch ein Manifest IM4M und das ist im Grunde genommen vor allem das AP-Ticket. Und das Interessante hierbei ist, dass jedes IMG4-File eine Kopie vom Manifest hat. Das heißt, wir brauchen nicht das IMG4-File für Tickets und das IMG4-File-File-File-System. Und das ist vielleicht, warum sie eine Kopie von dem Ticket für jedes File haben. So, ja, schauen wir jetzt mal das IMD4-File-Format genau an. Auf der linken Seite sieht man eine Entschlüsselung des Files mit den verschiedenen Inhalten. Das ist über SAP OS gemacht. Und dann hat man das SAP und dann hat man das Keyback. Das Keyback ist ein verschlüsselter Schlüssel, der entschlüsselt werden kann, um dann die Firma zu entschlüsseln. Darunter steht das Manifest, was man braucht. Auf der rechten Seite sieht man das doch mal deutlich viel besser. Und das sieht man dann, wenn man das genau sieht, wenn man das hier sassstellen lässt. Und ich werde durch diesen einzelnen Dingen noch mal ganz genau ... Die BNCH ist die AP NONS für das AP Ticket. Und dann hat man noch gerätespezifische Dateien. Ein Unik-Device-Identifier, der das Ticket genau zuweist. Dann hat man noch die SAP NONS. Und SAP VN ist die Server NONS, die NONS, die die Server herstellt. Ein Ticket mit den gleichen Parametern, aber man kriegt immer eine neue davon. Soweit ich weiß, wird diese Datei eigentlich für nix benutzen. Darunter haben wir noch verschiedene Hashes von den verschiedenen Dateien, beispielsweise für BATZ0. So sieht die Bootchain aus auf 64-bit-Devices, wenn man auf den normalen Weg geht. Das einzige, was sich da wirklich geändert hat, hier hat sich halt das AP Ticket geändert. Und wenn man im DFU-Modus geht, dann wird das AP Ticket gecheckt und dann wird eine AP NONS hergestellt, so wie eine SAP NONS, und das wird dann in das Ticket gesteckt. So, jetzt haben wir gesehen, wie viel sich verbessert hat und jetzt ist die Frage, können wir immer noch downgraden? Und ja, wir können das. Jetzt machen wir mal ein Downgrade-Plan für 64-bit-Geräte. Wir wissen, dass Baseband und IOS nicht zusammen passen müssen und funktioniert das auch für SAP. Das wäre natürlich cool. Jedes IMG4-Datei enthält ein AP Ticket, aber müssen die unbedingt die gleichen sein. Schauen wir nochmal auf unserem Plan. Was ich jetzt hier gemacht habe, ist, ich habe ein kleines Tool gebaut. Alles, was es tut, ist, das ist die AP NONS und die SAP NONS aus dem Gerät in den verschiedenen Modi zieht. Ich habe das mal mit meinem iPhone 4S ausprobiert und habe all diese NONSes mal ausgelesen für AP und SAP NONS. Was ich dann gemacht habe, ist ein Ticket angefragt für diese NONSes auf dem Gerät und da habe ich den TSS-Checker für benutzt und habe dieses Ticket auf IBSS geschrieben und habe das IBSS gecharted. Dann habe ich noch mal geguckt, welche NONSes generiert wurden und dann habe ich festgestellt, dass sich diese nicht ändern. Und dann habe ich dieses Ticket auf IBSS gesteckt und dann habe ich das gleiche wieder gemacht und wieder hat sich die NONS nicht geändert und deshalb ist es etwas, wo wir gut arbeiten können. Wir bekommen im DFU-Modus IBSS und IBSS und da haben wir die gleiche NONS und das gilt auch für IBSS und IBSS. Die SAP NONS ist komplett ignoriert in IBSS und IBSS. Es ist nur wichtig, wenn man SAP botet. Es könnte Sinn machen, aber naja, was passiert, wenn man voraussehen könnte, wie die API NONS aussieht? Das Tool heißt Prometheus, das ist von mir. Nehmen wir mal an, wir könnten die API NONS voraussehen. Was wir dann machen könnten, wäre ein Ticket für die NONS-Anfragen, die dann später generiert wird und solange sie nicht signiert ist und dann können wir sie einfach noch mal regenerieren und dann können wir die NONS nehmen, die wir vorbekommen haben. Das bringt uns auf diese Replay-Attacke, die klassische, und dann können wir bis zum RAM-Disputen. Wir können nur bis zum RAM-Disputen, weil es immer noch SAP gibt und bei SAP funktioniert es leider nicht. Was wir hier machen, ist, dass wir ein neueres, signiertes SAP-Booten und dann können wir dieses neue SAP-Boot und das signierte SAP-Booten fixen. Das könnte alles fixen, würde ich sagen. So sieht Prometheus aus. Wenn man das Ganze bootet, mein Boot in den ILB, und dann über iBoot, da wird IP-Check gecheckt, und wenn man den Home-Button hält, dann kommt man in Recovery-Modus beim Boot. Dann hält es da an, und dann tun wir ein bisschen Wudu und dann generieren wir das AP-Nons, wo wir das Ticket schon vorher gespeichert haben, und dann tun wir das in iBack und dann tun wir das Gleiche für die anderen Modi. Und was wir dann machen, ist, dass wir das signierte SAP in SAPOS, weil das ja dann angenommen wird, das SAP-Nons. Und dann machen wir normalen Restore mit dem AP-Ticket, was wir gespeichert haben. Und dann restoren wir das andere SAP-Ticket mit einem neuereren AP-Ticket. Jedes IP... Ja, so, jetzt bleibt noch die letzte Frage. Wie können wir denn jetzt das AP-Nons vorher sagen, weil darauf basiert das Ganze, was wir hier eben vorgestellt haben? Wir können jetzt das AP-Nons also das ganze, was wir hier eben vorgestellt haben. So, schauen wir uns mal diese OTA-Update-Prozedur an. Also, wenn man das Telefon nimmt und dann in Einstellungen Updates auswählt, lädt es normalerweise erst die Bootfiles runter und speichert die Amdisk im Speicher und setzt dann einige Bootparameter und rebootet dann. Und man braucht eben einen AP-Ticket zum booten. Das heißt, man kann keinen AP-Ticket-Anfragen während wir im Recovery-Modus sind. Das heißt, wir müssen es vorher machen. Und das heißt, irgendwas im AP-Ticket muss vorhergesagt, muss gespeichert werden. Und das heißt, wir machen jetzt eine Anfrage für einen AP-Ticket und nutzen es dann beim nächsten reboot. Also, müssen wir diese Stelle da irgendwie finden, wo das gespeichert wird. Im NVRAM finden wir dann eine Stelle im Kernelcash von iOS 10. Apple hat gnädigerweise iOS 10 unverstößelten Kernelcash geschickt. Und das heißt, wir müssen eigentlich noch rausfinden, wenn wir aus diesem Dump hier was diese ganzen Werte konkret heißen. So, und wenn man nach io nvram auf opensauce.apple.com sucht, dann findet man so eine Variable-Entabelle, wo diese gezeigten Elemente halt immer erst ein String sind, dann ein Typ und dann eine Permission und dann einen Zählerwert. Und das heißt, wenn wir uns jetzt den Kerneldump angucken, dann finden wir ein paar Mal eben diesen Typ String. Und eine Permission Kernel Only. Also, nur ein Kernel Permission, was ein bisschen blödes, aber das können wir mit einem Kernel Patch beheben. Das heißt, wir können also den NVRAM benutzen, um diese Variable zu beschreiben. Wie voraus sagen wir, wir setzen sagen wir jetzt diese AP in uns voraus. Der Generator wird eben im NVRAM gespeichert und wird dann konsumiert nach dem Reboot. Entweder iTunes macht das oder der On-Device-Updater. Und das generiert dann eben diese nonns beim Boot. Man kann das eben nicht nochmal generieren, sondern es muss nicht zweimal die gleichen nonns generieren, sondern es wird immer eine neue nonns generiert. Und das heißt, so sieht dieser Generator dann aus. So, das heißt, was ich jetzt zeige, ist ein bisschen wie eine Demo, aber tatsächlich dann doch nur ein Bild. Was ich hier gemacht habe, ist, ich habe zuerst einen nonns von, ich habe zuerst einen nonns angefragt, dann gebe ich mir die ganzen Argumente aus dem NVRAM aus, dann lasse ich nonns-Enabler laufen, das eben den Kernel patcht. Wenn ich mir jetzt nochmal den NVRAM anzeigen lasse, dann passiert auf, zeigt auf einmal, wird der nonns angezeigt, aber wir können ja auslesen. So, der nonns ist jetzt 20-Bite groß, das heißt, wir haben sehr viele Möglichkeiten, um das irgendwie zu bruteforzen. Der Generator auf der anderen Seite ist nur 8-Bytes groß und das ist schon nur noch 2 hoch 64 Möglichkeiten, was noch immer ziemlich viel ist. Man ist vielleicht der NSA, aber wir haben definitiv keinen Ansatz hier, aber ich habe ja diese ganzen Sachen erst im Nachhinein ausgerechnet. Also, was mein Ansatz ist, wir setzen das Gerät in Recovery-Modus, ließ dann eben den nonns und rebutet nochmal. Ließt nochmal den nonns, rebutet nochmal und das habe ich ungefähr 2 Stunden laufen lassen und es gab mir ungefähr 2000 nonnses. Und wenn wir uns die nonnses mal genauer anschauen, dann hier auf der rechten Seite, dann sehen wir da zuerst die nonns in der ersten Spalte, dann in der zweiten Spalte, wie oft sie generiert wurde und in der dritten Spalte die prozentueller, alle Anteil der nonns. So, die blaue, die ich markiert habe, ist jetzt nicht unbedingt die öfteste, aber die, die ich meine liebste ist, deswegen habe ich die markiert. Und das heißt, wir sehen, dass hier ungefähr 5 nonnses, ungefähr 20 Prozent der allergenerierten nonnses ausmachen. Außerdem habe ich auf Twitter ein bisschen rumgefragt, ob andere Leute das auch noch ausprobieren können. Und wir haben gesehen, dass tatsächlich mehrfache iPhone 5S die gleichen nonnses oder die gleichen nonnses generiert haben. Und das hat auch funktioniert mit einigen iPad Airs auf ähnlichen iOS-Versionen, also iOS-Versionen, die nah dran waren. Ich habe es nicht auf 32-Bit-Geräten versucht. Ich habe es auf 64 Bit-Geräten, also späteren Geräten versucht. Aber diese generieren keine Kollisionen. Lustig hierbei ist auch, dass ich Kollisionen auf iOS 9.3, 10, 10.1, 10.2 gesehen habe. Aber ich habe keine Kollisionen auf iOS 9.1 und 9.0 gesehen. Und das heißt, vielleicht hat Apple irgendwie in iOS 9.3 hier einen Bug eingeführt. So, das heißt, sieht also so aus, dass Kollisionen für einige Geräte möglich sind. Und das kann halt benutzt werden, ohne einen Jailbreak das System zu downgraden. Das heißt, was ihr machen müsst, diese Tests auch laufen lassen und dann AP Tickets für dieses spätsifische nonns herauszufinden. So, das heißt, das Downgrade-Szenario. In diesem Fall wäre ja ohne Jailbreak, dass man zu einem neuen iOS upgraded, dann rausfindet, welchen nonns am öftesten generiert wird und dann fragen wir einen AP Ticket für ein altes iOS an, während es eben noch signiert ist, weil das alte iOS Image noch für einen bestimmten Zeitraum signiert ist und das muss man eben auch in diesen Zeitfenster machen, in dem das alte nonns signiert ist, damit man dann nochmal downgraden kann. So, wir downgraden dann, wenn das Signature-Fenster sich schließt, also davor logischerweise, und können dann eben mit unseren gesammelten nonns eben downgraden. Ich muss hierbei sagen, dass zum aktuellen Zeitpunkt funktioniert, dass zum aktuellen Zeitpunkt die iOS 9 Downgrades funktionieren, aber das iOS 10 Zapp ist nicht kompatibel zu iOS 9 und deswegen funktioniert dann das Downgrade nicht. Also macht das besser nicht. Prometheus hat trotzdem noch einige Limitationen, dass es verlässt sich zum Beispiel darauf, dass halt das Baseband, Zapp und iOS Version nicht genau offen voneinander abhängen, sondern halt eben dieser Unterschiede möglichst sein kann und diese Checks können jederzeit hinzugefügt werden. Zapp und Baseband müssen dann auf der letzten signierten Version sein, das funktioniert vielleicht nicht mit älteren Versionen von iOS und das App nonns muss halt immer noch vorhersagbar sein und Apple könnte das halt eben ändern, wenn sie das zum Beispiel mit einem, den Generator mit einem Salt versetzen und dann hätten wir eben, weil eben das alles verschlüsselt, ist keine Möglichkeit, dieses Salt zu bekommen und könnten eben deswegen kein Downgrade mehr durchführen. So, was könnte man in der Zukunft noch an möglichen Downgrades machen? Das AP-Ticket-Sicherheit ist mit Sicherheit eine gute Idee, auch wenn das Downgrade dann nicht direkt funktioniert. Das heißt, ja, vielleicht geht es dann trotzdem irgendwann in der Zukunft. Es wird definitiv auch zukünftig irgendwelche Bugs geben in dem Bereich und deswegen sichert eurer AP-Tickets. Die Tools, die man hierbei braucht, TSS Checker, das ist ein Tool, um eben AP-Tickets von Apple anzufragen mit vielen Möglichkeiten das einzustellen, also die nonns, die Zapp nonns und so weiter, ob man ein Baseband-Ticket will, richtig eine ganze Menge an Sachen, die man da einstellen kann. Und das ist so das einzige Tool, was ich hier in dem Bereich gefunden habe. Ihrem G4-Tool ist ein weiteres Tool, das benutzt wird, um Ihrem G4, vor 4p und einem für M-Files Anzeigen benutzt wird. Das heißt, ja, ihr könnt damit eben diese ganzen Dateien inspizieren, habt ihr auch auf meinen Screenshots gesehen. Die Future Restore ist das Tool, um eben die Prometheus-Downgrade-Methode durchzuführen. Und das heißt, ihr müsst einfach nur das Eis-Version und die Baseband-Version spezifizieren. Diese ganzen Tools sind Open Source oder werden Open Source werden. Bei Letzten werde ich kurz nach diesem Vortrag veröffentlichen. An diesem Stelle möchte ich Nikias danken, der eben den Future Restore zum Laufen gebracht hat, was eine ziemlich haarige Angelegenheit war. Und vielen Dank. Und jetzt ist Zeit für Fragen und Antworten. Wenn es jetzt Fragen gibt, dann kommt bitte zu den Mikrofonen und stellt eure Fragen. Wenn ihr jetzt gehen möchte, dann ist das okay, aber seid bitte leise und nehmt Müll mit, wenn ihr welchen habt. Die erste Frage kommt von da ganz hinten. Danke, meine Frage ist ein bisschen einfach, aber wenn nun eine Szene bist, warum hacken die niemals wirklich die Hardware? Vielleicht tun sie das, aber warum? Ich denke, es gibt einige Leute, die Hardware-Hacks machen. Ich weiß, dass ein paar Leute Hardware-Hacks machen, um halt eben die Firmware-Kies zu bekommen. Aber ich denke, wahrscheinlich ist das so, weil Hardware-Angreifen, nicht für die durchschnittlichen Nutzer Praktikabelle ist. Man kann den das vielleicht erklären, aber da müssen sie es immer noch irgendwie umsetzen. Und deswegen sind wir halt hauptsächlich fokussiert auf Software. Warum will man grad downgraden? Ich habe mich das auch schon selber ein paar Mal gefragt, aber es sieht so aus, als ob viele Leute tatsächlich downgraden wollen würden. Zum Beispiel, wenn man ohne jailbreak downgraden kann, könnte man gerade jetzt downgraden von der aktuellen iOS Version 10.2 und mit all dieser ganzen Voodoo-Magie könnte man auf iOS 10.1 runter downgraden. Und es gibt zum Beispiel gerade nur ein jailbreak für iOS 10.1, aber nicht für 10.2. Ich weiß nicht so recht, viele Leute sagen, neue Versionen sind langsamer, deswegen downgraden sie, um erhöhte Geschwindigkeit zu haben. Vielleicht will man das haben. Wir nehmen noch eine Frage von hier vorne. Ich habe eine Frage über nonzes. Es gibt nonzes, die häufiger sind als andere. Ist das richtig? Hast du schon herausgefunden, warum das so ist, ob es da irgendwelche bestimmten Gründe für gibt? Ich habe da noch nichts wirklich reingeguckt. Was ich gemacht habe, ist, ich habe einfach ausprobiert. Das heißt, wenn man ein iPhone 5 ist, auf iOS 9.3, irgendwas nimmt, dann findet man eben diese Häufungen, die ich in der Zeit habe. Ich habe mich gewundert, dass es überhaupt funktioniert hat und habe deswegen noch nicht weiter danach geguckt. Das war auch meine Frage, aber kann ich noch das Bild von dem nonz collision slide haben? Ich glaube, da sind sogar noch... Ich glaube sogar, es gibt einen... Ich glaube, da sind sogar noch... Ich glaube, da sind sogar noch... Ich glaube, da sind sogar noch... Ich glaube sogar, es gibt einen... Noch mehr davon auf Reddit. Da hat jemand die ganzen verschiedenen Bilder, die ich auf meinem Blog gezeigt habe, zusammengefügt und da aufbereitet, ist irgendwo auf Reddit. Eine weitere Frage aus dem Internet. Funktioniert das auf allen 64-Bit-Geräten? Ja, ich glaube schon. Also die einzige Sache, die das so wirklich auf dem iPhone 7 blockieren würde, wäre, ist, dass ich... Ja, also was das iPhone 7 aufgemacht hat, ist, dass sie das Baseband geändert haben und ich habe da noch nicht die Änderung für die neue iPhone 7 Baseband-Film mehr gemacht. Ich weiß noch nicht, dass der Weicherschutzmechanismus iOS das iPhone 7 hat. Ich vermute, dass es funktionieren würde auf allen 64-Bit-Geräten oder eben auch auf dem iPhone 7. Es könnte sogar auf allen 32-Bit-Geräten funktionieren, aber da habe ich es noch nicht ausprobiert. Danke für den Talk. Meine Frage ist... Das ist eine sehr dumme Frage eigentlich. In den Folien hast du uns gezeigt, dass man auf allen Geräten von 935 bis 933 funktionieren soll. Und in der ersten Frage funktioniert das auch mit iOS 10. Hab ich da irgendwas falsch verstanden? Meinst du diese Folie? Ja, also die Aussage dieser Folie ist, dass sich Leute mit iPhone 5s auf iOS 935 hatte und diese nonzgeneriert haben. Und die Häufungen waren halt dieselben auf diesen ganzen Geräten. Aber das iPhone 5s erstellt außerdem nonzis- oder nonz-Kollision auf 10.1, 10.2 und 10.1, 10.2. 10.0, 10.1, 10.2, aber es sind halt einfach andere. Danke für den Talk. Es geht noch mal um die nonzis. Du hast gesagt, du hast noch nicht reingeschaut, wie die generiert werden. Aber ist das Code, der generell reversibel ist, wie schwer wäre es, um rauszufinden, wie die generiert werden? Ja, also wenn du das Gerät buchst, dann ist es so, wenn du das Gerät buchst, also wenn du das Gerät buchst und eine nonz davon anfragst, dann wäre das eine nonz, die vom bootloader, also von iBoot generiert würde. Das heißt, du wirst es da iBoot dampen und ihren random number generator reverse-engineieren. Ich habe ja einfach mir den Generator angeguckt und herausgefunden, dass sie eben dieses little encoding benutzen. Und wenn man diesen bytes dann hast, dann hätte man den nonz. Das ist auch genau das, was TSS Checker tut, wenn man den nonzis checkt. Und es würde dann, aber ich habe nicht weiter reingeguckt, wie iBoot diese nonzis generiert. Aber man könnte über iBoot die entsprechenden nonzis generieren. Ich glaube, es gibt keine Entschlüsselten. Ich glaube, es gibt eine Möglichkeit, wie man ein iBoot von iOS 8-Geräten auf 64-Bit dampen kann. Für 32-Bit gibt es da entschlüsselte Fernwares, aber da habe ich nicht weiter eingeguckt. Wir fokussieren uns hier auf 64-Bit. Ist es möglich, die Diebstahlsicherung zu umgehen, wenn man das Ganze downgraded? Nein, das ist nicht möglich, denn nachdem du downgradest oder nach einem Restore allgemein, muss man das Gerät noch mal aktivieren. Das ist komplett separat von dem Upgrade-Downgrade-Schutzmechanismus. Früher hast du gesagt, dass diese Basebands normalerweise genutzt werden, um das an bestimmten Anbieter zu koppeln. Und aktuell wird das ja nicht gemacht. Was ist denn im Baseband? Wofür nutzt man das aktuell? Ja, so weit ich das verstehe, hast du eine andere Art Sortie-Chip. Und das Baseband ist eine ganz andere Sortie-Chip, die eben die Kommunikation mit dem GSM-Netzwerk und so weiter regelt. Und wenn ich eben irgendwelche Anrufe mache, die LTE benutze und so weiter, nutze ich eben diesen Chip. Und das Baseband ist eben das Betriebssystem in diesem Baseband. Ist da Speicher drin? Könnte da kriptografisch interessante Daten drin sein? Wahrscheinlich schon. Wahrscheinlich sind da von den Netzbetreibern Informationen drin. Aber das ist jetzt nichts, wo der Nutzer irgendwie Zugriff drauf hätte. Danke für den Talk. Ich wollte fragen, ob deine Möglichkeit für Kailor oder auf 64-Bit-Geräten ist. Ehrlich gesagt, keine Ahnung. Hast du schon mal ein Gerät gebrickt? Ob ich schon mal ein Gerät gebrickt habe? Nee, nee, habe ich nicht. Any other questions? Now is your chance. Yes, please. Du hast gesagt, dass es nicht möglich ist, von 10 auf 9, 3, 5 runterzuladen. Kannst du da nochmal drüber sprechen? Also, diese Folien habe ich gemacht, als iOS 9 noch signiert war. Deswegen habe ich fälschlicherweise angenommen, dass man eben das Downgrade machen könnte. Aber die Sache ist halt, dass man die iOS 10 selbst auf iOS 9 Firmware nutzen kann. Und das klappt halt nicht. Denn ganz am Ende vom Restore geht es kaputt und gibt eine Fehlermeldung. Aber ganz am Ende funktioniert halt der Restore einfach nicht. Ich weiß nicht, ob man unbedingt da ein Datei-System hat in dem Zustand, aber man hat keinen Telefon, dass man da irgendwie benutzen könnte, dann in dem Zustand. Ich mag wieder eine dumme Frage sein, aber nach dem Downgrade ist die Nutzerdata immer noch auf dem Gerät oder ist das alles gelöscht? Das ist eine gute Frage. Das ist in der Tat ein Restore. Das heißt, man kann beim Restore die Daten alle löschen. Es gibt auch Upgrades, wo man eben nicht die Datenpartition löscht. Ich habe eine Option in Future Restore, also diesem Tool, dass ein Fleck setzt, damit die Datenpartition nicht gelöscht wird. Das heißt, man könnte Downgrading versuchen, mit diesem Fleck gesetzt. Aber ich weiß nicht, ob das eine wirklich gute Idee ist, ob es vielleicht Sachen kaputtmachen oder auf Sync bringen würde. Vielleicht könnte es funktionieren. Kann man das SAP vor dem Updaten sichern und das dann nutzen, wenn man den Downgrade gemacht hat auf einer frühen Version? Nein, kann man nicht, weil wenn wir wieder herstellen, dann booten wir ja die RAM-Disk im DFU-Mode und wir booten eben auch das SAP OS und wenn wir das SAP OS als SAP Betriebssystem geboten haben, können wir das Downgrade nicht starten. Das heißt, das normale Downgrade wiederherstellt eben das Dateisystem wieder her und uns einen separaten Prozess um das SAP wiederherzustellen. Hier müssen die nonsense übereinstimmen und das ist ein separater Wiederherstellungsprozess. Warum ist das Basement so schwer zu exploiten? Ich sage jetzt nicht, dass das Basement so schwierig zu exploiten ist, aber ich habe das Gefühl, dass viele Leute gar nicht erst reingucken, weil ich wüsste auch gar nicht, was ich jetzt damit machen würde. Ich sehe nicht so wirklich den Anwendungsfall dafür. In der Theorie könnte man das Basement exploiten, versuchen das zu downgrade. Man könnte auch das alte iOS patchen, sodass das neue Basement, die neue Basement API, versteht. Es ist bestimmt machbar, aber es gibt den einfachen Weg, dass man einfach darauf hofft, dass es funktioniert. Was für welches Software? Welches Firmware? Die Frage ist, welche Firmware kümmern sich darum, die Firmware auf das Gerät zu spielen usw. Ich glaube nicht, dass man das so einfach machen kann, man muss möglicherweise die SEP Firmware exploiten und die daran hindern, das SEP zu downgraden. SEP kümmert sich um wirklich viele Sachen, und um das nicht zu updaten, müsste man es wahrscheinlich exploiten. Da habe ich nicht weiter reingeguckt. Okay, dann verabschieden wir die Übersetzer uns auch. Wir freuen uns jederzeit über Feedback unter dem Hashtag.