Wie das DevTeam das iPhone eroberte

• Das erste iPhone von 2007 ließ sich ohne einen US-AT&T-Vertrag nicht aktivieren, und das iPhone Dev Team suchte öffentlich nach einem rein softwarebasierten Weg, es mit anderen Mobilfunkanbietern zu nutzen
• Die Arbeit ließ sich in sechs Meilensteine gliedern: Firmware entschlüsseln, Aktivierung umgehen, Schreibzugriff erlangen, eine ARM/Mach-O-Toolchain aufbauen, Drittanbieter-Apps ausführen und den Carrier-Lock entfernen
• Der erste Durchbruch war die Analyse der ramdisk und der verschlüsselten DMG in .ipsw sowie der Zugriff auf den Home-Bildschirm über eine Replay-Schwachstelle in der Aktivierungsprüfung von lockdownd
• Schreibzugriff wurde erlangt, indem im Recovery Mode ramdisk und kernelcache geladen und anschließend fstab und Services.plist geändert wurden, sodass statt des auf /root/Media beschränkten afcd das Root-Dateisystem bearbeitet werden konnte
• Das endgültige Unlocking wurde mit anySIM automatisiert, das die Baseband-Firmware dumpte, patchte und erneut hochlud sowie AT+CLCK="PN",0,"00000000" ausführte; Apple reagierte am 27. September 2007 mit Firmware v1.1.1

---

Das iPhone von 2007 und das Ziel des DevTeam

• Apple brachte das iPhone am 29. Juni 2007 auf den Markt; der Preis lag damals bei 499 $ für das 4-GB-Modell und 599 $ für das 8-GB-Modell
• Ein frisch ausgepacktes iPhone zeigte nur den Bildschirm Connect to iTunes und war nicht aktiviert; Nutzer mussten in iTunes eine AT&T-Mitgliedschaft abschließen
• Auch nach der Anmeldung blieb das Gerät auf AT&T gesperrt
• Für Kanada gab es zunächst keinen Starttermin für das iPhone; Apple einigte sich erst am 11. Juli 2008 zusammen mit dem iPhone 3G mit Rogers
• Das iPhone Dev Team fand sich mit dem Ziel zusammen, das Gerät rein per Software mit jedem Mobilfunkanbieter nutzbar zu machen, und veröffentlichte auf dem Blog iphone.fiveforty.net regelmäßig Fortschritte
  • Am 3. Juli 2007 erschienen zwischen 0 Uhr und 21 Uhr acht Updates

Die 6 Meilensteine des DevTeam

• Um ein gesperrtes Gerät wie ein normales Smartphone zu nutzen, waren folgende Schritte nötig
  • Lesezugriff zum Verständnis des Systems: Break DMG Password
  • Aus dem nicht aktivierten Zustand herauskommen: Bypass Activation
  • Schreibzugriff für Systemänderungen: Get Write Access
  • Eine Working Toolchain zum Erstellen eigener Binärdateien
  • Unlock, damit das Baseband sich mit jedem Mobilfunkanbieter verbinden kann
  • Eine App zur Automatisierung des gesamten Ablaufs: Enable Third-Party Applications
• Laut Wayback Machine waren am 6. Juli 2007 zwei von sechs Meilensteinen abgeschlossen, und die Reise endete am 12. September 2007
• Auf der am 25. September 2007 gecrawlten Statusseite waren Decrypt Firmware, Bypass Activation, Get Write Access, Get Working Toolchain, Enable Third-party Applications und Unlock Phone als abgeschlossen markiert

Analyse von .ipsw und Lesezugriff auf das Dateisystem

• iTunes lud zur Wiederherstellung des Geräts ein iPhone Software Archive mit der Endung .ipsw herunter; diese Datei war ein ZIP-Archiv
• In iPhone1,1_1.0_1A543a_Restore.ipsw befanden sich das Wiederherstellungs-Image img2, der Baseband-bezogene Ordner Firmware, kernelcache als iOS-Kernel sowie zwei große DMG-Dateien
  • Das komplette iOS-Wiederherstellungsarchiv war etwa 105 MiB groß
• Die erste DMG, 694-5259-38.dmg, war die bei der Wiederherstellung verwendete ramdisk und nicht verschlüsselt, sodass sie sich mit dd mounten ließ
• Die ramdisk war nicht das vollständige iOS-Dateisystem, erlaubte aber in /private/etc/master.passwd die Passwörter für den App-Benutzer mobile und für root, unter dem die übrigen Prozesse liefen, einzusehen
• Die zweite DMG, 694-5262-39.dmg, war das im Normalbetrieb verwendete iOS-Dateisystem und verschlüsselt
  • Der Schlüssel wurde in /usr/sbin/asr auf der ramdisk gefunden
  • Da es sich nicht um eine Passphrase, sondern um einen Schlüssel handelte, ließ sich hdiutil nicht verwenden, daher schrieb das DevTeam das eigene Entschlüsselungswerkzeug vfdecrypt.c
  • Nach der Entschlüsselung bestand Lesezugriff auf das vollständige Laufzeit-Dateisystem

Aktivierung umgehen

• An der normalen Aktivierung waren iTunes, der Apple-Server albert.apple.com und lockdownd auf dem iPhone beteiligt
  • iTunes sammelte DeviceID, IMEI und ICCID des Geräts
  • Die drei Werte wurden zu einem Token zusammengefasst und an den Apple-Server gesendet
  • Der Apple-Server signierte das Token mit einem privaten Schlüssel und schickte es zurück
  • Das per USB wartende lockdownd prüfte das Token mit dem öffentlichen Apple-Schlüssel
  • Wenn das Token von Apple stammte und zu den Geräteinformationen passte, wechselte der Status auf Activated
• PhoneActivationServer von dvdjon patchte iTunes so, dass der Aktivierungsserver per HTTP statt HTTPS angesprochen wurde, und leitete die Anfrage auf einen eigenen Server um
• Entscheidend war, kein neues signiertes Token zu erzeugen, sondern per Replay einfach dasselbe signed token aus einer erfolgreichen Aktivierung unabhängig von den Eingaben zurückzugeben
• Laut George Hotz prüfte lockdownd nicht, ob DeviceID, IMEI und ICCID in der Antwort mit den echten Werten übereinstimmten
• Das DevTeam schrieb CLI-tools, die ein hartkodiertes signed token aus einer plist lasen und an das iPhone schickten; später wurde das zu iPhoneInterface weiterentwickelt, das ohne iTunes funktionierte

Schreibzugriff und Jailbreak

• Ein aktiviertes iPhone konnte über iTunes zwar Dateien wie Musik und Fotos empfangen, aber der dafür zuständige Prozess afcd war per chroot jail auf /root/Media beschränkt
• Nur die Benutzerpartition war mit Lesen/Schreiben (rw) gemountet, die Systempartition hingegen nur lesbar (r)
• Ziel war es, aus dem chroot jail auszubrechen und auch auf die Systempartition schreiben zu können; daraus entstand der Begriff jailbreaking
• Der iPhone-Start war in Normal Mode und Recovery Mode aufgeteilt
  • Im Normal Mode verlief die Kette BootROM → LLB → iBoot → Kernel → Normal Mode, wobei jede Stufe die Signatur der nächsten prüfte
  • Der Recovery Mode stoppte auf der iBoot-Stufe; iTunes lud dann ramdisk, kernelcache und weitere Komponenten in den RAM und wechselte in den Restore Mode
• Das DevTeam untersuchte in iTunesMobile.dll, wie iTunes während der Wiederherstellung auf das Dateisystem schrieb, und fand Befehle wie mount, umount und ditto
• iPHUC war ein CLI-Werkzeug, das über nicht öffentliche Methoden aus iTunesMobile.dll mit Geräten im Recovery Mode kommunizierte
  • Der Nutzer versetzte das Gerät in den Recovery Mode
  • Eine ramdisk wurde an das Gerät übertragen und in den RAM geladen
  • kernelcache wurde gesendet und der Kernel so gebootet, dass er auf die ramdisk zeigte
  • Das Gerät wechselte in den Restore Mode
• Der eigentliche Jailbreak erfolgte durch Änderungen an fstab und Services.plist
  • In fstab wurde die Systempartition so geändert, dass sie nicht nur read-only, sondern rw gemountet wurde
  • In Services.plist wurde ein zweiter afcd-Dienst angelegt, der nicht /root/Media, sondern / als Basis verwendete
  • Nach dem Neustart konnte iTunes über afcd2 das komplette Dateisystem sehen, und sowohl System- als auch Benutzerpartition waren les- und schreibbar
• Später wurden Aktivierung und Schreibzugriff mit der Mac-OS-X-Desktop-App INdependence automatisiert

Toolchain und Drittanbieter-Apps

• Über die Toolchain und die Ausführung von Drittanbieter-Apps ist öffentlich nicht viel bekannt, aber mindestens zwölf Personen arbeiteten daran mit
• Am 19. Juli 2007 war eine auf ARM zielende binutils toolchain fertig, sodass vom DevTeam selbst geschriebene Programme auf dem iPhone liefen
• Mit Nightwatchs ARM/Mach-O Toolchain wurde die erste eigenständige Hello World-Anwendung kompiliert und auf dem iPhone ausgeführt
• GeoHotz erklärte, dass die Kombination aus Mach-O und ARM außerhalb von Apple zuvor nicht existiert habe und deshalb selbst geschrieben werden musste
• Ein weiteres Ziel der Toolchain war, MobileTerminal.h nachzubauen, das nicht öffentliche Funktionen aus iTunesMobile.so freilegte, um ohne laufendes iTunes mit afc zu kommunizieren
• Einige Vorträge behaupten, der Kernel prüfe die Signatur einer ausführbaren Datei vor execl, aber beim ersten iPhone war das offenbar noch nicht so und wurde anscheinend erst mit v1.1.1 eingeführt

Baseband-Unlock und anySIM

• Das iPhone bestand aus dem unter iOS laufenden Smartphone-Teil und dem Baseband für Telefon- und Modemfunktionen
  • Beide Systeme hatten jeweils eigenen RAM, CPU, Speicher, Firmware und Oszillator
  • Sie tauschten AT-Befehle über eine an /dev/tty.baseband gemountete UART-Leitung aus
• Der für das Unlocking nötige AT-Befehl war schon früh bekannt
  • AT+CLCK="PN",0,"xxxxxxxx"
  • xxxxxxxx war der NCK (Network Control Key) und galt als für jedes Gerät einzigartig
  • Die Zahl der Versuche war auf 3 bis 10 begrenzt; danach konnte die Firmware hart auf AT&T gesperrt werden
• Auch das Baseband hatte ein BootROM und eine Chain of Trust mit Signaturprüfung
• MuscleNerd erklärte, das Baseband habe kein Sicherheitsnetz wie DFU oder Recovery Mode; Fehler an NOR oder Image konnten das Gerät daher dauerhaft zerstören
• Im Juli 2007 reverse-engineerte das DevTeam das Baseband aus der .ipsw und analysierte außerdem /usr/local/bin/bbupdater auf der ramdisk, um die Befehle zum Hochladen eines neuen Basebands zu verstehen
• Das erste CLI-Tool iUnlock benötigte mehrere Dateien wie die gedumpte Firmware nor und ICE03.12.06_G.fls
• Später erschien die einfachere App anySIM, die sich auf das Telefon kopieren und per Knopfdruck starten ließ
• anySIM arbeitete in folgender Reihenfolge
  • Es öffnete /dev/tty.baseband und setzte die Modemparameter
  • Es dumpte das 4 MiB große Baseband, also das NOR, nach /tmp
  • Es lud das Baseband in den RAM
  • Es lud das secpack ICE03.12.06_G.fls von der ramdisk
  • Es patchte den Baseband-Code im RAM so, dass jeder NCK zum Entsperren akzeptiert wurde
  • Es lud das gepatchte Baseband erneut hoch
  • Es führte AT+CLCK="PN",0,"00000000" und AT+CLCK="PN",2 aus

Der -0x400-Trick

• Die gepatchte Baseband-Firmware hätte die Signaturprüfung eigentlich nicht bestehen dürfen und das Hochladen hätte fehlschlagen müssen
• Der Umweg nutzte einen Offset von minus 0x400
• GeoHotz erklärte, dass die ersten 0x400 Bytes bis zur Signaturprüfung nicht verwendet würden; deshalb beginne man das Schreiben einfach 0x400 Bytes früher
• Spätere Erklärungen von Hacker-News-Lesern zufolge empfing das Baseband neue Firmware in Blöcken von maximal 0x800 Bytes
  • Es speicherte nicht erst die gesamten 4 MiB im RAM, prüfte dann die Checksumme und schrieb danach in den Flash
  • Empfangene Bytes wurden sofort in den Flash geschrieben, nur die ersten 0x400 Bytes wurden im RAM gepuffert
  • Nach Abschluss des Uploads prüfte das Baseband die Checksumme
  • Schlug sie fehl, wurden die gepufferten ersten 0x400 Bytes nicht in den Flash geschrieben, sondern verworfen
• Die -0x400-Methode schrieb zunächst 0x400 Bytes Müll vor die eigentliche Firmware-Position und schickte danach die 4 MiB Firmware
  • Die Checksumme schlug fehl, sodass die 0x400 Bytes Müll verworfen wurden
  • Der Rest der neuen Firmware war jedoch bereits an die korrekte Position in den Flash geschrieben

Abschluss und das anschließende Katz-und-Maus-Spiel

• Die vollständige Anleitung für das reine Software-Unlock wurde am 12. September 2007 veröffentlicht
• Gleichzeitig wurden erfolgreiche Fälle aus verschiedenen Kontinenten gezeigt, darunter auch ein Beispiel aus Kanada
• Apple veröffentlichte schnell am 27. September 2007 die iPhone-Firmware v1.1.1
• Der Fortschrittsbalken des DevTeam wurde auf Decrypt 1.1.1, Get Write Access 1.1.1, Activate 1.1.1, Unlock 1.1.1, Enable Third-party Applications 1.1.1 zurückgesetzt
• Von da an begann das Katz-und-Maus-Spiel zwischen Apple und der iPhone-Hacking-Community und setzte sich danach fort

[GN⁺]

Hacker-News-Kommentare

• Bei Firmware-Updates ist das ein gängiges Verfahren. Die ersten 0x400 Byte sind ein Header, den der Loader der vorherigen Stufe prüfen muss, bevor er diese Stufe bootet. Man nimmt also Daten entgegen und schreibt sie frei, schreibt aber den Header nicht.
  Ohne Header führt das nicht zur Codeausführung und ist daher sicher. Am Ende wird die Gesamtsignatur geprüft; wenn sie besteht, wird der Header geschrieben und das gesamte Image damit gültig gemacht.
  Der Trick hier besteht darin, zunächst 0x400 Byte Müll 0x400 Byte vor der gewünschten Schreibposition zu schreiben. Dieser Teil wird als Header behandelt, nur gepuffert und nicht tatsächlich geschrieben; der Rest der übertragenen Daten wird tatsächlich an die gewünschte Position geschrieben. Danach schlägt die Signaturprüfung fehl, und da die ursprünglich unerwünschten ersten 0x400 Byte nicht geschrieben werden, ist das ein Erfolg.
  • Der Teil, der als „Recovery Mode“ bezeichnet wurde, hieß damals meiner Erinnerung nach DFU-Modus. Das stand für „Device Firmware Update“, und ob man das damals „recovery“ nannte, weiß ich nach mehr als 15 Jahren nicht mehr sicher.
  • iZsh (https://x.com/izsh1911) wüsste es wahrscheinlich auch, aber ich habe vor über 10 Jahren den Kontakt verloren.
• Wie man es von Fabien kennt, ist der Artikel gut geschrieben und sehr detailliert. Ich erinnere mich, wie ich damals zugesehen habe, als diese iPhone-Schutzmechanismen analysiert wurden; seitdem war es wirklich ein langer Weg.
  Die vor dem Schreiben der Daten angewendete -0x400-Verschiebung wäre vermutlich vollständig geklärt, wenn sie noch jemand genauer erklären würde.
  • Die -0x400-Verschiebung scheint ungefähr so zu funktionieren:
    Mit Seek(fd, 0xA0020000 - 0x400); sucht man 0x400 vor die Stelle, an die die Daten geschrieben werden sollen, und füllt mit SendWrite(fd, foo, 0x400, false); die ersten 0x400 Byte, die man schreiben möchte, mit Nullen.
    Anschließend füllt man mit SendWrite(fd, fw, fwsize, true); die restlichen Bytes mit den eigentlichen Daten und ruft SendEndSecpack(fd); auf. Das iPhone kopiert die Daten nach den 0x400 Byte, also alle Daten, die man schreiben wollte, und versucht dann die Signaturprüfung, die fehlschlägt. Wäre die Signaturprüfung erfolgreich gewesen, wären auch die ersten 0x400 Byte, die als Nullen belassen wurden, zu diesem Zeitpunkt kopiert worden.
• Zur historischen Einordnung: Ich habe iPHUC gebaut, und den Namen habe ich mir mit 19 ausgedacht. Jemand mit dem Nick „nightwatch“ war eine der treibenden Kräfte hinter dem frühen Jailbreak und dem Begriff „jailbreak“, und die Zusammenarbeit mit ihm war wirklich angenehm.
  Soweit ich mich erinnere, war er vermutlich auch für den PDF- oder TIFF-Exploit verantwortlich, mit dem die PSP entsperrt wurde. Er lebte und arbeitete irgendwo in Südamerika, vermutlich an einer Universität, aber mehr weiß ich nicht.
  Das war eine wirklich spannende Zeit, und ich habe viel gelernt. Allerdings hat George Hotz die Sicherheit einiger Leute gefährdet, die beim Zugang zu japanischen Dokumenten geholfen hatten, obwohl er wiederholt gebeten wurde, das nicht zu tun. Das war sehr frustrierend und war letztlich der Grund, warum das Dev Team das Projekt verließ.
  • Mir fällt ein, dass es jemanden mit dem Nick „pineapple“ gab, der mir geholfen hat, die ARM-Architektur zu verstehen. ARM war damals noch relativ neu, deshalb tauchten in den frühen UIs viele Ananas-Motive auf. Das waren wirklich gute Leute, und ich bedauere, dass ich den Kontakt nicht gehalten habe.
  • Soweit es ohne Risiko einer Verleumdungsklage möglich ist, würde ich gern mehr darüber hören, wie George Hotz die Sicherheit von Menschen gefährdet hat.
• Die Struktur, bei der DeviceID, IMEI und ICCID aneinandergereiht werden, um ein Token zu erzeugen, das dann an Apples Server albert.apple.com geschickt und mit Apples privatem Schlüssel signiert wird, woraufhin lockdownd auf dem Gerät es mit Apples öffentlichem Schlüssel prüft und den Status auf „Activated“ setzt, klingt wie ein Vorläufer des heutigen OAuth.
• Ach, die guten alten Zeiten. Als iPhone-Hacking noch einfach war … na ja, nicht einfach, aber deutlich einfacher als heute.
• Ich frage mich, mit welchem Tool das Flussdiagramm erstellt wurde. Es wirkt textbasiert und sieht vielleicht sogar besser aus als mermaid.
  • Ich benutze https://asciiflow.com.
  • Sieht nach Monodraw aus. Das war vor ein paar Tagen auch wieder auf HN.
• Eine Anekdote, an die ich mich erinnere: Ich war im IRC-Channel, als die Veröffentlichung von iPhone OS 1.1 den Jailbreak blockierte. Eine der damals gefundenen Methoden bestand darin, auf 1.0.2 downzugraden, das Telefon zu jailbreaken und dann das über iTunes zugängliche Verzeichnis /root/Media als symbolischen Link auf / zu setzen.
  Dieser Link blieb während des Upgrades erhalten, und nach dem Firmware-Update konnte man auf rootfs zugreifen. Damals hieß es noch nicht iOS, sondern iPhone OS.
• Beim frühen iPhone scheint das „S“ für Sicherheit gestanden zu haben. So läuft es eben, wenn man versucht, ein erstes Produkt auf den Markt zu bringen.
  Bei Autoherstellern ist es ähnlich. Von einem neuen Produkt oder einer neuen Plattform sollte man die ersten Modelljahre besser nicht kaufen.
  • Es gibt keinen Konsens darüber, wofür das „S“ stand, und Apple hat es nie offiziell erklärt. „Successor“, „Second“ und „Speed“ wirken alle bis zu einem gewissen Grad plausibel, aber eine echte Antwort gibt es nicht.
    Üblicherweise war „S“ eine Kennzeichnung für ein kleines Upgrade gegenüber dem Basismodell.