Comment la DevTeam a conquis l’iPhone

• En 2007, le premier iPhone ne pouvait pas être activé sans souscrire chez AT&T aux États-Unis, et l’iPhone Dev Team a publiquement cherché un moyen de l’utiliser chez d’autres opérateurs uniquement par logiciel
• Le travail s’est structuré en 6 jalons : déchiffrement du firmware, contournement de l’activation, obtention des droits en écriture, construction d’une toolchain ARM/Mach-O, exécution d’apps tierces et déverrouillage opérateur
• Les premières percées ont été l’analyse du ramdisk et du DMG chiffré contenus dans .ipsw, ainsi que l’accès à l’écran d’accueil via une faille de rejeu dans la vérification d’activation de lockdownd
• Les droits en écriture ont été obtenus en chargeant un ramdisk et un kernelcache en Recovery Mode, puis en modifiant fstab et Services.plist pour accéder au système de fichiers racine au lieu de rester limité à /root/Media via afcd
• Le déverrouillage final a été automatisé avec anySIM, qui vidait, patchait puis réinjectait le firmware du baseband avant d’exécuter AT+CLCK="PN",0,"00000000", et Apple a réagi le 27 septembre 2007 avec le firmware v1.1.1

---

L’iPhone de 2007 et l’objectif de la DevTeam

• Apple a lancé l’iPhone le 29 juin 2007, au prix de 499 $ pour le modèle 4 Go et 599 $ pour le modèle 8 Go
• À la sortie de la boîte, l’iPhone était inactif et n’affichait que l’écran Connect to iTunes, l’utilisateur devant souscrire un abonnement AT&T dans iTunes
• Même après l’inscription, l’appareil restait verrouillé sur AT&T
• Aucun lancement initial de l’iPhone n’était prévu au Canada, et Apple n’a conclu un accord avec Rogers que le 11 juillet 2008, en même temps que l’iPhone 3G
• L’iPhone Dev Team s’est réunie avec pour objectif de faire fonctionner l’appareil chez n’importe quel opérateur uniquement par logiciel, en publiant fréquemment ses avancées sur le blog iphone.fiveforty.net
  • Le 3 juillet 2007, 8 mises à jour ont été publiées entre minuit et 21 h

Les 6 jalons de la DevTeam

• Pour utiliser un appareil verrouillé comme un smartphone ordinaire, les étapes suivantes étaient nécessaires
  • Accès en lecture pour comprendre le système : Break DMG Password
  • Sortir de l’état inactif : Bypass Activation
  • Accès en écriture pour modifier le système : Get Write Access
  • Working Toolchain pour créer des exécutables personnalisés
  • Unlock pour permettre au baseband de se connecter à n’importe quel opérateur
  • Une app pour automatiser l’ensemble du processus : Enable Third-Party Applications
• D’après la Wayback Machine, au 6 juillet 2007, 2 jalons sur 6 étaient terminés, et le parcours s’est achevé le 12 septembre 2007
• Sur la page d’état archivée le 25 septembre 2007, Decrypt Firmware, Bypass Activation, Get Write Access, Get Working Toolchain, Enable Third-party Applications et Unlock Phone étaient indiqués comme terminés

Analyse de .ipsw et lecture du système de fichiers

• Pour restaurer l’appareil, iTunes téléchargeait une archive iPhone Software avec l’extension .ipsw, qui était en réalité un fichier zip
• iPhone1,1_1.0_1A543a_Restore.ipsw contenait une image de récupération img2, un dossier Firmware lié au baseband, le noyau iOS kernelcache et deux gros fichiers DMG
  • L’archive de restauration iOS complète pesait environ 105 MiB
• Le premier DMG, 694-5259-38.dmg, était le ramdisk utilisé lors de la restauration, et n’était pas chiffré, donc montable avec dd
• Le ramdisk n’était pas le système de fichiers iOS complet, mais il permettait de voir dans /private/etc/master.passwd les mots de passe de mobile, l’utilisateur exécutant les apps, et de root, qui exécutait les autres processus
• Le second DMG, 694-5262-39.dmg, était le système de fichiers iOS utilisé en fonctionnement normal, et il était chiffré
  • La clé a été trouvée dans /usr/sbin/asr du ramdisk
  • Comme il s’agissait d’une clé et non d’une passphrase, hdiutil ne pouvait pas être utilisé, et la DevTeam a écrit son propre outil de déchiffrement, vfdecrypt.c
  • Après déchiffrement, ils ont obtenu un accès en lecture à l’ensemble du système de fichiers d’exécution

Contournement de l’activation

• L’activation normale impliquait iTunes, le serveur Apple albert.apple.com et lockdownd sur l’iPhone
  • iTunes collectait le DeviceID, l’IMEI et l’ICCID de l’appareil
  • Il regroupait ces trois valeurs dans un token envoyé au serveur Apple
  • Le serveur Apple signait ce token avec une clé privée avant de le renvoyer
  • lockdownd, en attente sur USB, vérifiait le token avec la clé publique d’Apple
  • Si le token venait bien d’Apple et correspondait aux informations de l’appareil, l’état passait à Activated
• PhoneActivationServer de dvdjon patchait iTunes pour accéder au serveur d’activation en HTTP au lieu de HTTPS, puis redirigeait les requêtes vers son propre serveur
• Le point clé n’était pas de créer un nouveau token signé, mais de rejouer le même signed token capturé lors d’une activation réussie, quelle que soit l’entrée
• Selon la présentation de George Hotz, lockdownd ne vérifiait pas si le DeviceID, l’IMEI et l’ICCID de la réponse correspondaient aux valeurs réelles
• La DevTeam a créé des tools en CLI lisant un signed token codé en dur depuis un plist pour l’envoyer à l’iPhone, puis a amélioré cela avec iPhoneInterface, fonctionnant sans iTunes

Droits en écriture et jailbreak

• Un iPhone activé pouvait recevoir via iTunes des fichiers comme de la musique ou des photos, mais le processus d’upload afcd était enfermé dans une chroot jail limitée à /root/Media
• Seule la partition utilisateur était montée en lecture/écriture (rw), tandis que la partition système était en lecture seule (r)
• L’objectif était de sortir de la chroot jail et d’obtenir l’écriture jusqu’à la partition système, d’où le terme jailbreaking
• Le démarrage de l’iPhone se divisait entre mode normal et Recovery Mode
  • En mode normal, la chaîne était BootROM → LLB → iBoot → Kernel → Normal Mode, chaque étape vérifiant la signature de la suivante
  • Le Recovery Mode s’arrêtait à l’étape iBoot, puis iTunes chargeait un ramdisk, un kernelcache, etc. en RAM pour entrer en mode restauration
• La DevTeam a étudié dans iTunesMobile.dll la façon dont iTunes écrivait sur le système de fichiers pendant une restauration, identifiant des commandes comme mount, umount et ditto
• iPHUC était un outil CLI communiquant avec un appareil en Recovery Mode via des méthodes non publiques de iTunesMobile.dll
  • L’utilisateur plaçait l’appareil en Recovery Mode
  • Le ramdisk était transféré à l’appareil et chargé en RAM
  • Le kernelcache était envoyé, puis le noyau démarré en pointant vers le ramdisk
  • L’appareil passait alors en Restore Mode
• La procédure réelle de jailbreak reposait sur la modification de fstab et Services.plist
  • Dans fstab, la partition système était modifiée pour être montée en rw plutôt qu’en lecture seule
  • Dans Services.plist, un second service afcd était créé avec / comme racine au lieu de /root/Media
  • Après redémarrage, iTunes pouvait voir l’ensemble du système de fichiers via afcd2, et les partitions système comme utilisateur devenaient lisibles et modifiables
• Par la suite, l’activation et l’accès en écriture ont été automatisés dans l’application de bureau Mac OS X INdependence

Toolchain et apps tierces

• Peu d’informations publiques existent sur la toolchain et l’exécution d’apps tierces, mais au moins 12 personnes ont participé au travail
• Le 19 juillet 2007, une binutils toolchain ciblant ARM était prête, permettant à la DevTeam d’exécuter sur l’iPhone des programmes écrits par elle-même
• La première application autonome Hello World a été compilée avec la ARM/Mach-O Toolchain de Nightwatch puis exécutée sur l’iPhone
• GeoHotz a expliqué que la combinaison Mach-O + ARM n’existait pas auparavant hors d’Apple et qu’il avait fallu l’écrire soi-même
• Un autre objectif de la toolchain était de reconstituer MobileTerminal.h, exposant des fonctions non publiques de iTunesMobile.so, afin de communiquer avec afc sans lancer iTunes
• Certaines présentations affirment que le noyau vérifiait la signature des exécutables avant execl, mais la synthèse indique que ce n’était pas le cas sur le premier iPhone et que cela semble avoir été introduit avec la v1.1.1

Déverrouillage du baseband et anySIM

• L’iPhone se divisait entre la partie smartphone exécutant iOS et la partie baseband gérant téléphone et modem
  • Les deux systèmes avaient chacun leur RAM, CPU, stockage, firmware et oscillateur
  • Ils échangeaient des commandes AT via une ligne UART montée sur /dev/tty.baseband
• La commande AT nécessaire au déverrouillage était connue très tôt
  • AT+CLCK="PN",0,"xxxxxxxx"
  • xxxxxxxx était la NCK (Network Control Key), supposée unique à chaque appareil
  • Le nombre d’essais était limité à 3 à 10, après quoi le firmware pouvait verrouiller matériellement l’appareil sur AT&T
• Le baseband possédait lui aussi un BootROM et une chaîne de confiance, avec vérification de signature
• MuscleNerd expliquait que le baseband n’avait pas de filet de sécurité de type DFU/Recovery Mode, donc une mauvaise manipulation de la NOR ou d’une image pouvait endommager l’appareil de façon permanente
• En juillet 2007, la DevTeam a rétroconçu le baseband contenu dans .ipsw et analysé aussi /usr/local/bin/bbupdater dans le ramdisk pour comprendre les commandes permettant d’envoyer un nouveau baseband
• Le premier outil CLI, iUnlock, nécessitait plusieurs fichiers comme le firmware dumpé nor et ICE03.12.06_G.fls
• Ensuite est arrivée l’application plus simple anySIM, qu’il suffisait de copier sur le téléphone avant de l’exécuter d’une simple pression sur un bouton
• anySIM fonctionnait dans l’ordre suivant
  • Ouverture de /dev/tty.baseband et configuration des paramètres du modem
  • Dump du baseband de 4 MiB, c’est-à-dire la NOR, dans /tmp
  • Chargement du baseband en RAM
  • Chargement du secpack ICE03.12.06_G.fls depuis le ramdisk
  • Patch des commandes du baseband en RAM pour permettre le déverrouillage avec n’importe quelle NCK
  • Réupload du baseband patché
  • Exécution de AT+CLCK="PN",0,"00000000" puis AT+CLCK="PN",2

L’astuce -0x400

• Le firmware baseband patché n’aurait normalement pas dû passer la vérification de signature, et l’upload aurait donc dû échouer
• Le contournement utilisait un décalage minus 0x400
• GeoHotz a expliqué que les 0x400 premiers octets n’étaient pas utilisés avant la vérification de signature, ce qui permettait de commencer l’écriture 0x400 octets plus tôt
• D’après des explications ultérieures de lecteurs de Hacker News, le baseband recevait le nouveau firmware par blocs allant jusqu’à 0x800 octets
  • Il ne stockait pas les 4 MiB complets en RAM avant de vérifier le checksum puis d’écrire en flash
  • Les octets reçus étaient écrits immédiatement en flash, seuls les 0x400 premiers étant tamponnés en RAM
  • Une fois l’upload terminé, le baseband vérifiait le checksum
  • En cas d’échec, les 0x400 premiers octets tamponnés n’étaient pas écrits en flash et étaient simplement jetés
• La méthode -0x400 consistait d’abord à écrire des données poubelles 0x400 octets avant l’emplacement du firmware d’origine, puis à envoyer les 4 MiB du firmware
  • Le checksum échouait, ce qui faisait jeter les 0x400 octets poubelles
  • Mais le reste du nouveau firmware avait déjà été écrit en flash au bon endroit

Fin du parcours et début du jeu du chat et de la souris

• Les instructions complètes de déverrouillage logiciel ont été publiées le 12 septembre 2007
• Des cas de réussite par continent ont été publiés en même temps, y compris un cas canadien
• Apple a rapidement publié le firmware v1.1.1 de l’iPhone le 27 septembre 2007
• La barre de progression de la DevTeam a été réinitialisée à 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
• C’est à ce moment qu’a commencé le jeu du chat et de la souris entre Apple et la communauté de hack de l’iPhone, et il s’est poursuivi par la suite

[GN⁺]

Commentaires sur Hacker News

• C’est une méthode courante dans les mises à jour de firmware. Les 0x400 octets du début sont un en-tête que le chargeur de l’étape précédente doit vérifier avant de démarrer cette étape, donc on peut recevoir les données et écrire librement, à condition de ne pas écrire l’en-tête
  Sans en-tête, cela ne mène pas à une exécution de code, donc c’est sûr, et à la fin, si la signature complète est vérifiée avec succès, on écrit l’en-tête pour rendre l’image entière valide
  L’astuce ici consiste à écrire d’abord 0x400 octets de déchets 0x400 octets avant l’emplacement d’écriture voulu. Cette partie est traitée comme un en-tête, donc seulement mise en tampon sans être réellement écrite, tandis que le reste des données transmises est effectivement écrit à l’endroit voulu. Ensuite, la vérification de signature échoue, et comme les 0x400 premiers octets non désirés n’ont pas été écrits, c’est gagné
  • La partie appelée « mode de récupération » était, il me semble, appelée à l’époque mode DFU. C’était « Device firmware update », et je ne suis plus certain, plus de 15 ans après, qu’on parlait alors de « recovery »
  • iZsh(https://x.com/izsh1911) le saurait peut-être aussi, mais j’ai perdu le contact avec lui il y a plus de 10 ans
• Comme toujours avec Fabien, c’est très bien écrit et extrêmement détaillé. Je me souviens avoir vu l’analyse de cette protection de l’iPhone à l’époque, et ça a vraiment été un long voyage depuis
  J’aimerais bien qu’on m’explique un peu plus aussi le décalage de -0x400 appliqué avant l’écriture des données, pour que tout devienne parfaitement clair
  • Le décalage de -0x400 semble fonctionner à peu près comme ça
    avec Seek(fd, 0xA0020000 - 0x400);, on se place 0x400 avant l’endroit où les données doivent être écrites, puis avec SendWrite(fd, foo, 0x400, false);, on remplit de zéros les 0x400 premiers octets qu’on voudrait écrire
    Ensuite, avec SendWrite(fd, fw, fwsize, true);, on remplit le reste avec les vraies données et on appelle SendEndSecpack(fd);. L’iPhone copie alors les données après les 0x400 octets, c’est-à-dire l’ensemble des données qu’on voulait écrire, puis tente une vérification de signature, qui échoue. Si cette vérification avait réussi, les 0x400 premiers octets laissés à zéro auraient alors été copiés eux aussi
• Pour l’histoire, c’est moi qui ai créé iPHUC, et j’ai trouvé ce nom à 19 ans. Quelqu’un qui utilisait le pseudo « nightwatch » a joué un rôle clé dans les premiers jailbreaks et dans l’invention du terme « jailbreak », et c’était vraiment un plaisir de travailler avec lui
  Si je me souviens bien, c’est aussi lui qui s’occupait du PDF ou de l’exploit TIFF qui a débloqué la PSP. Je crois qu’il vivait quelque part en Amérique du Sud, probablement en travaillant dans une université, mais c’est à peu près tout ce que je sais
  C’était une période vraiment amusante et j’ai énormément appris. En revanche, George Hotz a mis en danger la sécurité de plusieurs personnes qui l’aidaient à accéder à de la documentation en japonais, malgré des demandes répétées de ne pas le faire, et c’était extrêmement frustrant ; c’est d’ailleurs la raison pour laquelle la dev team a fini par quitter le projet
  • Ça me rappelle qu’il y avait aussi quelqu’un qui utilisait le pseudo « pineapple » parmi les personnes qui m’ont aidé à comprendre l’architecture ARM. À l’époque, ARM était relativement nouveau, ce qui explique pourquoi il y avait autant d’ananas dans les premières interfaces. C’étaient vraiment de bonnes personnes, et je regrette de ne pas être resté en contact avec elles
  • Dans la mesure où cela peut être raconté sans risque de poursuites en diffamation, j’aimerais bien en entendre davantage sur la façon dont George Hotz a mis la sécurité des gens en danger
• Le fait de concaténer le DeviceID, l’IMEI et l’ICCID pour créer un jeton, de l’envoyer au serveur Apple albert.apple.com pour le faire signer avec la clé privée d’Apple, puis de faire vérifier cela côté appareil par lockdownd avec la clé publique d’Apple afin de passer à l’état « Activated », cela ressemble à une sorte de précurseur de OAuth
• Ah, la bonne époque. Quand le hack de l’iPhone était facile… ou plutôt, non, pas facile, mais bien plus facile qu’aujourd’hui
• Je me demande avec quel outil le diagramme a été fait. Ça a l’air basé sur du texte et peut-être même meilleur que mermaid
  • J’utilise https://asciiflow.com
  • On dirait Monodraw. C’est repassé sur HN il y a quelques jours aussi
• Petite anecdote dont je me souviens : j’étais sur le canal IRC lorsque la sortie de iPhone OS 1.1 a bloqué le jailbreak. L’une des méthodes trouvées à l’époque consistait à revenir à la version 1.0.2, à jailbreaker le téléphone, puis à faire un lien symbolique du répertoire /root/Media, accessible depuis iTunes, vers /
  Ce lien persistait pendant la mise à niveau, et ensuite, après la mise à jour du firmware, on pouvait accéder à rootfs. À l’époque, cela s’appelait iPhone OS, pas encore iOS
• Sur les premiers iPhone, on dirait que le « S » signifiait sécurité. Il fallait bien sortir un premier produit, après tout
  C’est un peu pareil chez les constructeurs automobiles. Mieux vaut éviter les premiers millésimes d’un nouveau produit ou d’une nouvelle plateforme
  • Il n’y a jamais eu de consensus sur ce que signifiait le « S », et Apple ne l’a jamais expliqué officiellement. « Successor », « Second » et « Speed » semblent tous plausibles, mais il n’y a pas de vraie réponse
    En général, le « S » indiquait surtout une mise à niveau mineure par rapport au modèle de base