iPhone 4 jailbreaken, Teil 1: Zugang erlangen

• gala ist ein Projekt zur direkten Implementierung eines iOS-4-Jailbreaks für das iPhone 4, und Teil 1 konzentriert sich darauf, auf älteren Geräten über eine SecureROM-Schwachstelle frühe Codeausführung zu erlangen
• Der iOS-Bootvorgang basiert auf einer Vertrauenskette: SecureROM verifiziert LLB oder iBSS, und jede folgende Stufe verifiziert die nächste; SecureROM selbst kann nach der Herstellung nicht per Update ersetzt werden
• limera1n greift die SecureROM des A4-SoC an, während das Gerät im DFU-Modus auf die Übertragung von iBSS wartet; ein beim Fuzzing von USB-Kontrollnachrichten entdeckter Absturz scheint zu einem Heap-Overflow und zur Ausführung von Shellcode zu führen
• In Anlehnung an pod2gs SecureROM-Dumper wird der Kommunikationsbereich 0x84000000 zusammen mit der USB-Leseanforderung 0xA1:2 verwendet, und der Ablauf zum Übertragen von SecureROM-Dumps und Debug-Werten auf den Host wird nachimplementiert
• Es wurde eine Pipeline aufgebaut, die ein in Rust geschriebenes Payload aus __TEXT,__text eines Mach-O als Shellcode extrahiert und ausführt, doch weil statische Strings in __const abgelegt werden, waren instruction-pointer-relative Adressierung und ein angepasstes Assembly-Layout erforderlich

---

Ausgangspunkt des iPhone-4-Jailbreak-Projekts

• gala ist ein Projekt zum Erstellen eines iOS-4-Jailbreaks für das iPhone 4; dieses Dokument entspricht Teil 1 davon, „Gaining Entry“
• Frühere Erfahrungen mit iOS-Tweak-Entwicklung führten zu Cydia-Distribution, Änderungen an SpringBoard-Funktionen, direkter Nutzung der Objective-C-Runtime und Reverse Engineering von Closed-Source-Binärdateien
• Das Ziel, selbst einen Jailbreak zu schreiben, bestand darin zu verstehen, wie der Jailbreak-Prozess tatsächlich funktioniert
• Diese Arbeit stützt sich stark auf das Wissen, das p0sixninja und axi0mX als Open Source geteilt haben

Auswahl eines alten iPhone und einer Boot-ROM-Schwachstelle

• Der erste Schritt war der Kauf eines iPhone 4 und eines iPhone 3GS bei eBay
• Da aktuelle Xcode-Versionen keine Targets für alte iOS-Versionen zulassen, war der Weg, Apps auf die Art der 2010er Jahre zu bauen und zu installieren, schnell blockiert
  • Auch die Möglichkeit, altes Mac OS X und Xcode in einer VM zu installieren, wurde geprüft, aber verworfen
  • Zudem war unklar, ob Apple Binärdateien für Legacy-iOS-Targets überhaupt noch signieren würde
• Die Alternative war, direkt auf eine Boot-ROM-Schwachstelle zu zielen
  • So ließ sich der Versuch ohne alte Toolchains oder VMs durchführen, nur mit Code auf dem Host-Rechner, der per USB mit dem Gerät interagiert
  • Im Abschnitt Vulnerabilities and Exploits der iPhone Wiki wurde der limera1n-Exploit-Code gefunden

SecureROM und die iOS-Boot-Vertrauenskette

• SecureROM ist in Apples Terminologie die erste Stufe des iOS-Bootprozesses und startet die nächste Bootstufe
• SecureROM kann zwei Komponenten laden
  • Beim normalen Booten startet es aus der Disk-Partition auf NOR den Low Level Bootloader, also LLB
  • Wenn es im DFU-Modus per USB mit einem Computer verbunden ist, kann es im Rahmen von Restore iPhone den Bootloader iBoot Single Stage, also iBSS, empfangen
• SecureROM prüft, ob LLB oder iBSS ein von Apple signiertes und vertrauenswürdiges Image ist
• Danach verifizieren auch LLB und iBSS jeweils die nächste von ihnen geladene Stufe und bilden so eine Vertrauenskette
• Da SecureROM die erste Stufe ist, wird es nicht von einer vorherigen Stufe verifiziert und ist bei der Herstellung in Read-Only-Memory eingebrannt
  • Andere Stufen können durch iOS-Updates ersetzt werden
  • Eine Schwachstelle in einer bestimmten SecureROM-Version bleibt daher dauerhaft auf Geräten bestehen, die mit genau dieser Version gefertigt wurden

Mit limera1n Codeausführung auf einem DFU-Gerät erlangen

• limera1n ist ein SecureROM-Exploit, den geohot 2010 veröffentlichte und als Jailbreak-Tool gleichen Namens verpackte
• limera1n kann verwendet werden, wenn ein Gerät im DFU-Modus per USB auf iBSS vom Host wartet
• Weil die im A4-SoC enthaltene SecureROM verwundbar ist, ist das iPhone 4 ein passendes Ziel
• Wie limera1n genau funktioniert, ist öffentlich nicht vollständig dokumentiert
  • geohot sagte, er wisse nicht, warum es funktioniert
  • p0sixninja stellte Vermutungen zur Theorie an
  • Der Absturz wurde offenbar durch Fuzzing von USB-Kontrollnachrichten entdeckt und scheint auf eine Race Condition hinauszulaufen, die zu einem Heap-Overflow führt und das Einschleusen sowie Ausführen von Shellcode ermöglicht

Speicher auf einem Gerät im DFU-Modus auslesen

• pod2gs SecureROM-Dumper diente als Referenzimplementierung, da er sowohl eine limera1n-Implementierung als auch ein Beispiel-Payload und eine USB-basierte Methode zum Speicherauslesen zeigt
• Der SecureROM-Dumper kopiert den bei 0x0 gemappten SecureROM-Speicher in einen USB-Empfangsbereich und liest die Daten dann per USB-Kontrollnachricht vom Host aus
• Der verstandene Ablauf ist wie folgt
  • Die MMU des A4 mappt den Beginn des SRAM auf 0x84000000
  • Der Host kann mit einem USB-Kontrollpaket mit request type 0x21 und request ID 1 ein iBSS-Image in Blöcken senden
  • Diese Daten werden ab 0x84000000 in den SRAM kopiert, und SecureROM führt einen internen Zähler über die Kopierposition für das nächste Paket
  • Das Gerät antwortet auch auf Kontrollpakete mit request type 0xA1 und request ID 2 und sendet dabei den Speicherinhalt von 0x84000000 an den Host
• Diese Lesefunktion ist besonders nützlich, wenn auf dem Gerät Code ausgeführt werden kann
  • Das Payload kopiert die gewünschten Daten nach 0x84000000
  • Der Host kann sie dann mit der Leseanforderung A1:2 abrufen
• In den Folien von p0sixninjas Hack In the Box Malaysia 2013 steht, pod2gs SecureROM-Dumper basiere auf SHAtter, doch das tatsächliche Utility verwendet eine limera1n-Implementierung
• Mit einer eigenen limera1n-Implementierung gelang erfolgreich ein SecureROM-Dump

Payload-Debugging mit 0x84000000

• Nachdem Codeausführung erlangt war, musste geklärt werden, wo der Shellcode ausgeführt wird, wo sich der Stack befindet und welchen Speicher der Shellcode überschreibt
• Der Leseablauf des SecureROM-Dumpers wurde für Debug-Ausgaben wiederverwendet
  • Das Payload kopiert Werte für Instruction Pointer und Stack Pointer nach 0x84000000
  • Der Host-seitige Code liest diese Werte auf dieselbe Weise wieder aus
  • Damit fungiert der Ansatz über Speicherdumps als eine Art einfaches print()
• Ein automatisiertes Skript dumpt nach dem Ausführen des Exploits die ersten paar Wörter von 0x84000000 und zeigt sie im Ausgabefenster an
• Die bestätigten Werte zeigten die Ausführungsposition des Shellcodes und die Position des Stacks
  • Der Instruction Pointer lag in der Nähe von 0x8402b048
  • Der Stack Pointer lag bei 0x8403bfa0
  • Der Stack Pointer befand sich im normalen von SecureROM eingerichteten Stack-Bereich, und der Instruction Pointer lag im empfangenen Image-Bereich

Rust-Payload und Extraktion von Mach-O-Shellcode

• Statt das Payload vollständig in Assembly zu schreiben, wurde ein Build-System aufgebaut, das ein Rust-Payload erstellt und in Shellcode umwandelt
• Rust stellte die Unterstützung für das Target armv7-apple-ios Anfang 2020 ein, aber mit rustup kann auf eine ältere unterstützende Toolchain umgeschaltet werden
• Beim Kompilieren mit einer höheren Programmiersprache entsteht nicht nur roher Maschinencode, sondern eine Binärdatei mit Metadaten, Informationen zum virtuellen Adressraum, Symboltabellen und Linker-Informationen
• Für den Exploit werden jedoch nur die Bytes benötigt, die in den Speicher injiziert und angesprungen werden; daher wird nicht das gesamte Mach-O benötigt, sondern nur der Abschnitt __text des Segments __TEXT
• strongarm ist eine Bibliothek zur Mach-O-Analyse und wurde im Build-System genutzt, um das Mach-O zu parsen und den Abschnitt __TEXT,__text in eine Datei zu extrahieren
• Die Bytes der extrahierten Datei bilden den Shellcode, den limera1n auf dem Gerät ausführt

Linker- und statische Daten-Probleme

• Normale Binärdateien verwenden OS-Infrastruktur und Konventionen für Einstiegssymbole wie start oder _main, doch für diesen Shellcode-Einsatzzweck werden solche Symbole nicht benötigt
• Der Linker meldet standardmäßig einen Fehler, wenn _main oder start fehlen
• Mit einer Kombination aus den Optionen -U _main, -U start und -static ließ sich eine Mach-O-Datei erzeugen, die kein dyld verwendet
• strongarm war zunächst nicht in der Lage, Binärdateien ohne LC_DYLD_INFO-Load-Command zu verarbeiten, und warf eine Exception
  • Diese Binärdatei verwendet kein dyld und enthält daher kein LC_DYLD_INFO
  • Zur Behandlung wurde ein Patch zu strongarm hinzugefügt
• Als dem Rust-Code statische Strings hinzugefügt wurden, brach das Payload
  • Kompilierte statische Strings werden in __const abgelegt
  • Der Shellcode-Extraktionsprozess behält aber nur __TEXT,__text, sodass __const-Daten nicht in den Speicher geladen werden
  • Infolgedessen versucht der Code, Strings von nicht gemappten Adressen zu lesen, und stürzt ab
• Die Lösung besteht darin, statische Daten in __TEXT,__text unterzubringen und instruction-pointer-relative Adressierung zu verwenden, damit keine stabile Ladeadresse vorausgesetzt werden muss
• Der aktuelle Ansatz definiert Strings in Assembly und übergibt ihre Adresse an den Einstiegspunkt des Rust-Payloads

Die in Teil 1 fertiggestellte Ausführungspipeline

• Die finale Pipeline arbeitet in der folgenden Reihenfolge
  • Das Rust-Payload wird geändert
  • Per Knopfdruck wird das Payload kompiliert
  • Der Shellcode wird aus der Binärdatei extrahiert
  • Ein Runner führt das Payload per limera1n auf einem verbundenen DFU-iPhone aus
  • Der Runner liest automatisch Daten aus 0x84000000, das als Kommunikationsbereich dient, und zeigt sie als Hexdump an
• Zu diesem Zeitpunkt kann auf dem Gerät beliebiger Code ausgeführt werden
• Beliebige Codeausführung ermöglicht theoretisch viele Dinge, doch das Gerät tatsächlich etwas Interessantes tun zu lassen, bleibt ein separater nächster Schritt
• Der nächste Schritt folgt in Teil 2: Bypassing the Bootchain

[GN⁺]

Kommentare auf Hacker News

• Nachdem ich jahrelang nur mitgelesen hatte, habe ich mir endlich einen Hacker-News-Account erstellt, nur um das hier zu sagen. Danke, dass du so klar aufgeschrieben hast, was für viele lange Zeit eine mysteriöse Blackbox war.
  Ich erinnere mich noch sehr genau daran, wie nervös ich war, als ich meinen iPod 4G mit iOS 4 jailbreakte und die Terminalmeldungen nur so durchliefen. Später habe ich in der Mittagspause in der Schule auch die Geräte von Freunden gemacht und hatte immer Angst, aus Versehen ein Handy kaputtzumachen und daraus einen mehrere Hundert Dollar teuren Brick zu machen.
  Rückblickend, Jahre später, war diese „Magie“, Apples Mauern zu durchbrechen und eigenen Code auszuführen, der Auslöser dafür, dass ich mich fürs Programmieren begeistert habe. Allen Beteiligten bin ich zutiefst dankbar.

  • Wenn man in der Tech-Branche arbeitet, gibt es viele Tage, an denen man sie wegen Dingen nicht mehr mag, die man sich vornimmt, aber nicht versteht oder nicht hinbekommt. Trotzdem erinnern mich solche Texte hin und wieder daran, Open Source und die Tech-Community insgesamt nicht aufzugeben.
  • Ich mag das iPhone, aber ich vermisse es, früher auf verschiedene Android-Geräte CyanogenMod aufzuspielen. Das fühlte sich wirklich großartig an.
  • Ich hatte eine ähnliche Erfahrung. Am Ende habe ich selbst angefangen, Jailbreak-Tweaks zu bauen, und genau dadurch bin ich ernsthaft ins Programmieren eingestiegen.

• Vielen Dank für den Artikel. Um so komplexe Konzepte einfach zu erklären, braucht es ein tiefes Verständnis. Beim Lesen kamen schöne Erinnerungen daran hoch, wie ich bis spät in die Nacht an Jailbreak-Projekten herumgehackt habe.

• Das Lesen hat mir durchgehend richtig Spaß gemacht, besonders weil ich bei Reverse Engineering von nativem Code immer noch nicht besonders gut bin.
  Das sieht nach einem tethered Jailbreak aus, weil hier der Systemwiederherstellungsmechanismus genutzt wird, um die Vertrauenskette zu brechen und ein modifiziertes iOS zu booten. Mich würde daher interessieren, wie ein untethered Jailbreak funktioniert. Läuft das so, dass man die Secure-Boot-Kette gar nicht umgeht, sondern unverändert lässt, dann im laufenden System einen privilegierten oder unprivilegierten Prozess exploitet und anschließend eine separate Rechteausweitung macht? Mich interessiert auch, wie Persistenz erreicht wird und wie man die Signaturprüfung des Kernels patcht, ohne die Signaturprüfungen von Bootloader und Kernel selbst anzutasten.

  • Meist wird es so eingerichtet, dass der Kernel während oder kurz nach dem Bootvorgang aus dem Userland erneut exploitet wird. An Techniken, an die ich mich erinnere, gab es etwa das Hinzufügen eines neuen Launch Daemon, das Signieren einer App mit einem Entwicklerzertifikat und das Platzieren von Binärdateien, die ein spezielles Verhalten des dynamischen Linkers ausnutzen, um die Signaturprüfung zu umgehen.

• Ein wirklich hervorragender Artikel. Schön zu sehen, dass du immer noch in der Community aktiv bist.

• Danke, dass du das gemacht hast. Ich habe ein iPhone 4s mit vielen besonderen Fotos darauf, aber irgendwie habe ich die PIN vergessen und stecke seit Jahren in diesem Wartezustand fest.
  Wenn es nicht um die Fotos ginge, hätte ich es einfach zurückgesetzt. Ich frage mich, ob ich damit die PIN zurücksetzen und die Fotos kopieren könnte.

  • Wahrscheinlich eher schwierig. Laut [0] wird der Passcode zum Schutz des Dateisystem-Verschlüsselungsschlüssels verwendet, daher lassen sich die Dateien ohne Passcode nicht entschlüsseln. Ich weiß nicht, ob Fotos verschlüsselt gespeichert werden, aber vermutlich sollte man davon ausgehen.
    Edit: Ich könnte mich irren. In [0] steht auch, dass eine Zeit lang nur der Mail-Speicher verschlüsselt war und sich der Standard erst mit iOS 7 geändert hat. Wenn das iPhone also iOS <= 6 hat, könnte man mit dieser Methode vielleicht auf das Gerät zugreifen und die Fotos kopieren. Das Tool unter [1] könnte helfen.
    [1] https://code.google.com/archive/p/iphone-dataprotection/
    [0] https://darthnull.org/ios-encryption/

• Ein wirklich guter Artikel. Allerdings hat mir die Szene, in der die alte iOS-Oberfläche den Ruhm des skeuomorphen Designs voll zeigt, den Magen umgedreht. Mir wurde wieder bewusst, wie sehr ich John Ive nicht ausstehen kann.

  • Du meinst die Zeit, als Buttons noch wie anklickbare Buttons aussahen? Anders als heute, wo man wegen des miserablen Flat Designs am Ende Bedienungshilfen hinzufügen musste, um die Mängel zu umgehen.
    Vielleicht hätte Jony lieber weiter rasiermesserscharfe Aluminium-Handballenauflagen entwerfen sollen, statt Software zu verantworten.
  • Meiner Meinung nach erreichte das iPhone mit iPhone 4 und iOS 4 seinen Höhepunkt. Danach gab es zwar noch schrittweise Verbesserungen, aber das war der letzte Moment, in dem sich ein neues iPhone wirklich wie ein großes Upgrade anfühlte. Abgesehen von Antennagate passten Hardware- und Softwaredesign einfach perfekt zusammen.

• Ich habe die ersten Teile wirklich mit großem Vergnügen gelesen. Es ist toll, das aus dieser Perspektive nachzuvollziehen. Ich lese selbst Unmengen an Source Code, um herauszufinden, wie andere Leute Dinge wie Exploits umsetzen, und es freut mich, dass andere das auch so machen.

• Ich habe es noch nicht gelesen, freue mich aber darauf. Die am Anfang aufgelisteten Tweaks habe ich alle benutzt, und ich wollte einfach Danke sagen, dass du sie gebaut hast. Frühe iOS-Jailbreaks haben wirklich Spaß gemacht.

• Sehr gut. Ich wollte es ausprobieren, aber leider ist mein altes Gerät von vornherein nicht mehr gebootet.
  Ich habe damals auch Tweaks gebaut, und Jailbreaking fühlte sich wie schwarze Magie an. Selbst nach dem Lesen dieses Artikels fühlt es sich noch ein Stück weit so an.

• Vielen Dank, dass du das so zusammengetragen hast. Ich interessiere mich sehr dafür, solche Dinge zu lernen. Besonders würde ich gern lernen, wie man günstige Wi-Fi-Sicherheitskameras wie mit dafang-hacks mit eigener Firmware „befreit“ oder neue Exploits zum Rooten von Kindle-Fire-Tablets entwickelt.
  Aber erstaunlicherweise sind ausführliche Artikel über diesen Prozess sehr schwer zu finden.