Multi-Amorçage iOS

Avertissement: Certaines étapes présentées dans ce tutoriel interviennent sur des composantes de bas-niveau qui contiennent parfois de l'information critique permettant le bon fonctionnement de l'appareil. Une simple erreur peut «bricker» définitivement l'appareil, donc le rendre totalement inutilisable.
Aussi, attendre le prochain «Jailbreak» avant d'essayer sur les appareils pouvant accueillir la dernière mise à jour d'iOS.
Suivre ce tutoriel à vos propres risques.

Partie Amorçage «Untethered» (A)

Cette partie décrit les étapes à exécuter au niveau de la chaîne de démarrage «flashée» pour mettre en place un amorçage untethered (autonome) des différentes systèmes d'exploitation iOS installés sur l'appareil.
Dans la séquence d’amorçage de type «Tethered», chacun des éléments impliqués dans le démarrage doivent être envoyés à l’appareil iOS par une connexion USB.
Un périphérique externe relié à l’appareil est toujours nécessaire pour envoyer ces éléments et exécuter les commandes d’amorçage. Les chargeurs d’amorçage utilisés sont la SecureROM (mode DFU matériel) en tant que niveau 0, iBSS pour le premier niveau ainsi qu’iBEC pour le second niveau.
Tous attendent que le niveau suivant leur soit envoyé par USB. On met l’appareil en mode DFU (niveau 0), celui-ci attend iBSS (premier niveau) puis le valide avant de l’exécuter s’il le reçoit.
Ensuite, iBSS (premier niveau) attend iBEC (second niveau) puis le valide avant de l’exécuter s’il le reçoit. C’est ainsi de suite pour les autres éléments y compris le kernel.
Dans la séquence d’amorçage de type «Untethered» que nous allons voir en détail dans cette partie, chacun des éléments impliqués dans le démarrage sont «flashés» dans une partition cachée de la mémoire NAND nommée «firmware».
Les chargeurs d’amorçage utilisés sont la SecureROM (mode normal) en tant que niveau 0, LLB (Low-Level Bootloader) pour le premier niveau ainsi qu’iBoot pour le second niveau. Ces chargeurs d’amorçage possèdent une caractéristique supplémentaire par rapport à ceux impliqués dans le mode DFU.
En effet, ceux-ci embarquent des fonctions leur permettant d’interagir avec la mémoire NAND tel que la possibilité d’aller y chercher les autres éléments d’amorçage.
Par exemple, la SecureROM (mode normal, niveau zero) recherche le LLB (premier niveau) dans la section «firmware» de la NAND puis elle le valide avant de l’exécuter.
Ensuite, LLB (premier niveau) recherche iBoot (second niveau) dans la section «firmware» de la NAND puis le valide avant de l’exécuter. C’est ainsi de suite pour les autres éléments sauf le kernel.
Celui-ci est chargé d’une façon particulière. Le chargeur d’amorçage iBoot possède des fonctions lui permettant d’interagir avec le système de fichiers sur la NAND, celui dont les fichiers qui composent le (ou les) système(s) d’exploitation se trouvent.
Le kernel est stocké comme un fichier quelconque nommé «kernelcache» dans un répertoire du système iOS. Ces fonctions permettent à iBoot de pouvoir charger le fichier du kernelcache à partir de ce répertoire spécifique qui se trouve dans le système de fichiers sur la NAND.
Certains niveaux d’amorçages des deux chaînes (DFU et normal) sont en quelque sorte compatibles entre eux. C’est-à-dire qu’il est possible d’exécuter un chargeur d’amorçage du mode normal à partir d’un du mode DFU et vice-versa.
Par exemple, il est possible d’exécuter iBoot (niveau 2, mode normal) à partir d’iBSS (niveau 1, mode DFU). Le contraire est aussi possible, il est possible d’exécuter iBEC (niveau 2, mode DFU) à partir du LLB (niveau 1, mode normal).

Il est aussi possible de faire une sorte de transfert de chaîne, par exemple exécuter iBEC (niveau 2, mode DFU) à partir d’iBoot (niveau 2, mode normal) et vice-versa.


Dans le but d’implanter un multi-amorçage de type «Untethered», nous allons utiliser la séquence d’amorçage de type «Untethered» dans la méthode suivante. Il est à noter qu’il y a plusieurs méthodes possibles pour y arriver, dont certaines pourrait faire l’usage de la séquence d’amorçage DFU.
Tel que mentionné ci-haut, la séquence d’amorçage de type «Untethered» recherche les autres éléments d’amorçage dans la section «firmware» de la NAND et en fait l’exécution lorsque ceux-ci sont trouvés.

1) Télécharger le fichier de mise à jour de l'appareil (.ipsw) qui correspond à la version d'iOS désirée comme système d'exploitation secondaire.
On retrouve tous les versions d'iOS disponibles pour chacun des appareils sur TheiPhoneWiki, à l'adresse suivante:
Téléchargement des firmwares iOS

Il faut s'assurer que les clés de décryption pour ce firmware soient disponibles, sinon le multi-amorçage sera très limité (seulement pour les appareils vulnérables à un exploit de bas-niveau).
En cliquant sur le numéro de révision (build number) d'une version d'iOS sur TheiPhoneWiki, on arrive sur la page qui contient les clés de decryption si celles-ci sont disponibles. Dans mon cas, celles pour iOS 6.1.3 (10B329) pour l'iPhone 4 (iPhone 3,1 - N90AP) sont disponibles.
Cette version d'iOS peut alors être utilisé dans le but de faire un dual-boot iOS 7.1.2 (primaire) avec iOS 6.1.3 (secondaire).
Télécharger le fichier de mise à jour (.ipsw), renommer l’extension en .zip puis extraire celui-ci à l’aide d’un logiciel approprié. Un dossier qui contient tout le contenu du fichier .ipsw devrait alors être présent.

2) L’implantation du multi-amorçage peut rapidement devenir un véritable désordre, il faut y aller de manière structurée.
Créer un dossier nommé «[Appareil iOS] Multi-Amorçage» à un endroit simple d’accès dans le système de fichiers de l’ordinateur, par exemple sur le Bureau.
Dans ce dossier, créer un nouveau dossier pour chaque système secondaire qui seront installés sur l’appareil. Dans mon cas, je vais seulement créer un dossier «iOS 6.1.3».
Dans chacun de ces dossiers, créer deux nouveaux dossiers soit «Original» et «Patché». Le dossier «Original» contiendra les fichiers originaux et le dossier «Patché» contiendra les fichiers modifiés.





3) Dans le dossier résultat de l’extraction du fichier .ipsw, transférer le fichier «kernelcache.[Security Fusing].[BoardID].img3» vers le dossier «Original» crée précédemment à l’étape 2.
Ensuite, naviguer vers /Firmware/all_flash/all_flash.[BoardID].[Déploiement] puis transférer les fichiers suivants vers le dossier «Original» crée précédemment à l’étape 2.
applelogo@[résolution de l’écran].[Système sur Puce].img3
recoverymode@[résolution de l’écran].[Système sur Puce].img3
DeviceTree[BoardID].img3
iBoot.[BoardID].[Security Fusing].img3
LLB.[BoardID].[Security Fusing].img3
manifest
Le contenu du dossier «Original» devrait être semblable au contenu de celui présenté sur cette capture d’écran.
Erreur d'affichage de la photo

4) Obtenir l’outil xpwntool pour décrypter les données du «tag» DATA de ces conteneurs IMG3. Il est possible d’utiliser la version d’xpwntool incluse dans les outils la méthode Odysseus.
Il faut ensuite obtenir les clés de décryption, celles-ci unique pour chaque appareil et chaque version d’iOS.
Sur TheiPhoneWiki, on sélectionne un appareil puis on clique sur le numéro de révision (build number) d'une version d'iOS. On arrive sur la page qui contient les clés recherchées.

5) Utiliser l’outil xpwntool pour décrypter les données du «tag» DATA de ces conteneurs IMG3.
En utilisant un terminal en ligne de commande, définir le dossier «Original» en tant que répertoire courant.

pmbonneau-mac#cd [chemin du dossier «Original»]
pmbonneau-mac#xpwntool [entrée, conteneur IMG3 avec données encryptées] [sortie, conteneur IMG3 avec données décryptées] -iv [IV] -k [clé] -decrypt
Exemple concret d’utilisation d’xpwntool pour décrypter l’iBoot d’iOS 6.1.3 (10B329) pour l'iPhone 4 (iPhone 3,1 - N90AP).
pmbonneau-mac#xpwntool iBoot.n90ap.RELEASE.img3 iBoot.n90ap.RELEASE_dec.img3 -iv b559a2c7dae9b95643c6610b4cf26dbd -k 3dbe8be17af793b043eed7af865f0b843936659550ad692db96865c00171959f -decrypt
Adapter puis exécuter cette commande pour chacun des conteneurs IMG3 encryptés qui se trouvent dans le dossier «Original».
pmbonneau-mac#xpwntool LLB.n90ap.RELEASE.img3 LLB.n90ap.RELEASE_dec.img3 -iv e719a869fbb2a2265f78af5551842991 -k 681f1b336ce0edc1832d0064b73e8b095033c161fef947df9f663a75f10525fd –decrypt
pmbonneau-mac#xpwntool DeviceTree.n90ap.img3 DeviceTree.n90ap_dec.img3 -iv 4a44e07427942e3f0769cd2fb748f60e -k 19dc906dbea48840bb32c20add34ac2ac3c2e599370b9b0964a13212dd8aa7e4 –decrypt
pmbonneau-mac#xpwntool applelogo@2x.s5l8930x.img3 applelogo@2x.s5l8930x_dec.img3 -iv 02c61d93a817034d49edb0ad1ef4e77e -k ac48545272fa0c0bd806d9e9e9f3d923e650f5d114b1f9aeef4dd2da326e680c –decrypt
pmbonneau-mac#xpwntool recoverymode@2x~iphone.s5l8930x.img3 recoverymode@2x~iphone.s5l8930x_dec.img3 -iv ce172d5bf5c8a981cc7f3b748aef06db -k 3a0c613f70305a962738717a203988db879dce0d2866a2cc0c87258e0fb7d5ad –decrypt
pmbonneau-mac#xpwntool kernelcache.release.n90 kernelcache.release.n90_dec -iv 8f0e033069987ea966ef21cbd57ab385 -k 62c4d022a02d2c000b51705796d11661610c85f0b09f98ac0322d78a12463227 –decrypt
Le contenu du dossier «Original» devrait être semblable au contenu de celui présenté sur cette capture d’écran.
Erreur d'affichage de la photo








6) Théorie complexe, mais importante à bien comprendre pour la suite
Chaque élément de démarrage est encapsulé dans un conteneur IMG3 qui peut être sous deux états, soit encrypté ou décrypté.
Si l’on ouvre un conteneur IMG3 sous l’état encrypté en utilisant un éditeur hexadécimal, on remarque que seul les données du «tag» DATA sont encryptés. Les autres «tags» ne le sont pas puisque les chargeurs d’amorçage ont besoin de ces informations avant de décrypter les données du «tag» DATA et d’exécuter celles-ci.
En effet, les chargeurs d’amorçage utilisent cette information pour l’amorçage en chaîne.
Les deux «tags» que l’on va étudier sont l’entête IMG3 ainsi que TYPE. Ce sont les deux premiers «tags» d’un conteneur IMG3, donc possiblement les deux premiers à être pris en considération.
Erreur d'affichage de la photo
Prenons un iBoot quelconque, analysons l’entête IMG3 ainsi que le «tag» TYPE. On remarque que l’attribut «magic» de l’entête IMG3 correspond à la donnée du «tag» TYPE, soit «tobi».
Erreur d'affichage de la photo
Puisque les appareils iOS sont du ARM little-endian, il faut faire un «byte-shifting» de cette représentation en mémoire pour obtenir la représentation réelle. On obtient donc «ibot». On sait qu’iBoot (chargeur d’amorçage de second niveau) est exécuté par le LLB (chargeur d’amorçage de premier niveau) lors du démarrage en mode normal.
La question est de savoir comment le LLB s’y prend pour aller chercher le conteneur IMG3 d’iBoot dans la section «firmware» de la NAND parmis tous les éléments de démarrage qui s’y trouve. C’est par la lecture de la donnée de ces deux «tags» que la différence se fera.
En effet, le LLB recherchera s’il y a un conteneur dans la section «firmware» de la NAND dont les données des deux étiquettes magiques sont «tobi». Une fois celui-ci trouvé, le LLB vérifie les signatures, décrypte les données du tag «DATA», puis procède à l’exécution.
Si aucun conteneur porte l’étiquette magique «tobi», le LLB se retrouve dans son «fail-safe» soit le Soft-DFU. Il adopte alors un comportement similaire à l’iBSS du mode DFU, c’est-à-dire qu’il attend un conteneur IMG3 par USB.
Une fois sous l’exécution d’iBoot, le procédé de recherche des images pour les autres éléments de démarrages tels que le logo de démarrage, le device tree, le logo du mode de récupération (Recovery Mode) et autres se fera du même principe que la recherche du conteneur d’iBoot par le LLB.
Seule l’image du kernel est recherchée par un procédé particulier. C’est par l’utilisation de l’outil kloader que l’on peut exécuter le LLB décrypté de l’instance d’iOS secondaire à partir de l’instance d’iOS courante (primaire). Il y a cependant un problème lorsque l’on «kload» ce LLB directement, c'est-à-dire sans «patches».
En effet, l’appareil va «planter» et il faudra redémarrer celui-ci par un «hard-reset». Même si l’on «patch» ce LLB pour qu’il ignore les signatures d’iBoot, ce problème sera toujours présent.
Regardons en détail ce qu’il se produit dans le bas-niveau de l’appareil lorsque l’on «kload» ce LLB. Voici les caractéristiques de celui-ci :
a) Decrypté avec entête IMG3 (seulement les données du «tag» DATA sont décryptées).
b) Patches pour empêcher la validation des signatures sur iBoot appliqués.
On «kload» ce LLB, l’appareil «plante». Par défaut, ce LLB recherche le conteneur IMG3 d’iBoot dont les données des deux étiquettes magiques sont «tobi» dans la section «firmware» de la NAND parmis tous les éléments de démarrage qui s’y trouvent.
Il parvient à trouver celui-ci, donc tente d’exécuter l’image (les données du «tag» DATA). Le processus de restauration du système iOS primaire «flash» les conteneurs avec l’image encrypté dans la section «firmware» de la NAND. C’est l’appareil qui en fera la décryption lors du premier démarrage puisque le LLB du système primaire peut faire appel au co-processeur AES.
Dans une seconde instance (après l’usage de kloader), il n’est pas possible de faire appel à ce co-processeur AES. La décryption des images est alors impossible pour la seconde instance d’iOS.
Dans notre cas, le LLB essai de décrypter l’iBoot qui est encrypté, mais n’y parvient pas puisqu’il est impossible d’accéder au co-processeur AES. C’est ce qui provoque le «plantage» de l’appareil.
Afin de résoudre ce problème, il faut «patcher» la fonction qui exécute iBoot dans le LLB «kloadé» de façon à ce que celle-ci recherche une autre image à exécuter que celle d’iBoot encryptée. Ce «patch» consiste à altérer l’étiquette magique à rechercher, «ibot» dans ce cas-ci pour iBoot. On remplacera celle-ci par «ibob» par exemple.
Regardons en détail ce qu’il se produit dans le bas-niveau de l’appareil lorsque l’on «kload» ce nouveau LLB. Voici les caractéristiques de celui-ci :
a) Decrypté avec entête IMG3 (seulement les données du «tag» DATA sont décryptées).
b) Patches pour empêcher la validation des signatures sur iBoot appliqués.
c) Patch pour la recherche d’un conteneur autre que «ibot».
On «kload» ce LLB, l’appareil devrait entrer en «Soft-DFU» mode. En effet, celui-ci ne trouvera pas de conteneur IMG3 d’iBoot dont les données des deux étiquettes magiques sont «bobi» dans la section «firmware» de la NAND parmis tous les éléments de démarrage qui s’y trouve puisque nous n’avons pas «flashé» le conteneur d’iBoot avec les deux étiquettes magiques «bobi».
Ce conteneur n’est donc pas présent, le LLB se place dans son «fail-safe». Admettons que ce conteneur «bobi» est présent (nous allons étudier comment «flasher» des conteneurs additionnels dans la section «firmware» de la NAND plus loin), le LLB devrait exécuter celui-ci.
L’écran de l’appareil devrait alors s’allumer, puis devenir tout blanc après quelques secondes. Il est à noter que la section des données du «tag» DATA des conteneurs additionnels que nous allons «flasher» plus loin doit être décryptée, car tel que dit ci-haut, la seconde instance d’iOS n’a pas accès au co-processeur AES pour la décryption.
Nous sommes alors dans l’exécution d’iBoot, soit le chargeur d’amorçage de second niveau. L’appareil affiche un écran tout blanc qui est en fait le logo du «Recovery Mode» qui n’a pas été correctement chargé. Certains éléments tels que le logo de démarrage (on a pas vu celui-ci lorsque iBoot a commencé son exécution) ainsi que le DeviceTree n’ont pas été correctement chargés.
En effet, ceux-ci rencontrent le même problème que ci-haut, soit celui rencontré par le LLB pour le chargement d’iBoot. Le logo de démarrage n’a pas été correctement chargé puisque iBoot recherche le conteneur IMG3 du logo de démarrage dont les données des deux étiquettes magiques sont «logo» dans la section «firmware» de la NAND parmis tous les éléments de démarrage qui s’y trouvent.
Même pour le logo du «Recovery Mode», sauf que les données des deux étiquettes magiques recherchées sont «recm». C’est aussi le cas pour le DeviceTree, les données des deux étiquettes magiques recherchées sont «dtre».






Il faut alors «patcher» les fonctions qui exécutent ces éléments de démarrage dans iBoot de façon à ce que celles-ci recherchent d’autres images à exécuter que celles de l’instance d’iOS primaire. Ces «patches» consistent à altérer les étiquettes magiques à rechercher, par exemple «logo» pour le logo de démarrage.
On remplacera celle-ci par «logb» par exemple. On devra alors plus tard «flasher» un second logo de démarrage, mais decrypté dont les deux étiquettes magiques sont «logb» à la place de «logo». C’est le même principe pour le logo du «Recovery Mode» ainsi que le DeviceTree.
Il faut qu’il y ait cohérence entre le conteneur recherché ainsi que les deux étiquettes magiques. Admettons que les conteneurs «logb» ainsi que «dtrb» (DeviceTree secondaire) sont présents dans la section «firmware» de la NAND. On «kload» à nouveau le LLB, celui-ci devrait exécuter iBoot et l’écran de l’appareil devrait allumer avec le logo de démarrage.
Si tel est le cas, c’est que la cohérence entre le conteneur recherché ainsi que les deux étiquettes magiques est correcte. Quelques secondes plus tard, le logo du «Recovery Mode» devrait s’afficher (ou non, j’ai toujours eu certains problèmes avec). Si rien n’apparaît à l’écran (pas de logo de démarrage), il y a peut-être un problème de cohérence.
Il est à noter que les logos sont facultatifs, mais pas le DeviceTree. C’est à l’étape de l’exécution du kernel secondaire que nous allons pouvoir vérifier cela, mais certains éléments de démarrage doivent être préalablement «flashés» dans la section «firmware» de la NAND pour faciliter la recherche de «bug» potentiels.
Avec tous les étapes à réaliser pour implémenter cette méthode de multi-amorçage, il est simple de faire un oubli. Si l’on désire seulement faire le «debug» du multi-amorçage, seul le DeviceTree secondaire doit être minimalement «flashé». Ceci fera un amorçage de type «Tethered», mais avec la chaîne d’amorçage du mode normal.
Il sera possible d’envoyer le conteneur de l’iBoot à un chargeur d’amorçage de premier niveau en «Soft-DFU Mode» par l’intermédiaire d’une connexion USB. Lors de son exécution, iBoot fera ses routines de recherche puis de chargement des conteneurs tout comme s’il était exécuté depuis la section «firmware» de la NAND.


7) Appliquons sur ces conteneurs IMG3 décryptés, les «patches» nécessaires à l’exécution du multi-amorçage iOS. Aller sur la page web de téléchargement des «patches» que l’on retrouve ici.
Choisir la version d’iOS qui correspond à celle du fichier .ipsw téléchargé à l’étape 1, puis télécharger l’archive .zip en cliquant sur le lien. Dans mon cas, je télécharge celle d’iOS 6.1.3 (10B329) pour l'iPhone 4 (iPhone 3,1 - N90AP).
Ces archives .zip contiennent les fichiers texte suivants :
iBoot.n90ap.RELEASE.txt
LLB.n90ap.RELEASE.txt
DeviceTree.n90ap.txt
applelogo@2x.s5l8930x.txt
recoverymode@2x~iphone.s5l8930x.txt

Selon le modèle de l'appareil ainsi que la version de l'instance secondaire d'iOS, ces fichiers .txt peuvent être accompagnés d'un fichier binaire .bin portant le même nom. Ces fichiers .bin contiennent des blocs de modifications pré-faits pour celles qui sont plus complexes. Ceci permet de diminuer le risque de faire une erreur en procédant à l'application des modifications puisqu'il est possible d'utiliser les fonctions copier et coller sur le bloc d'octets concerné au lieu d'écrire chaque octets un par un.







Dans chacun de ces fichiers texte, l’on retrouve les différentes «patches» à appliquer sur le conteneur IMG3 décrypté correspondant. Par exemple, les «patches» qui se trouvent dans le fichier iBoot.n90ap.RELEASE.txt s’appliquent sur iBoot.n90ap.RELEASE_dec.img3.
Un fichier texte qui contient les «patches» d’un conteneur quelconque ressemble à ceci :
Erreur d'affichage de la photo
La première ligne contient les informations concernant le type de l’image, la version d’iOS qui contient cette image ainsi que l’appareil qui supporte celle-ci.
Ensuite, le reste du fichier est un tableau dont on retrouvera tous les «patches» appliquées sur le conteneur concerné. Ces «patches» sont représentés par des adresses avec leurs séquences d’octets correspondantes. Ce sont les différences entre la version originale et modifiée dont j’ai fait l’extraction à l’aide d’un logiciel nommé HexCmp que l’on peut acheter ici, HexCmp


Le tableau est divisé en deux colonnes. La première colonne «Original» contient les octets originaux du conteneur décrypté original. La seconde colonne «Modifié» contient les octets modifiés qu’il faudra appliquer sur ce conteneur décrypté original. Chaque ligne contient deux informations, soit l’adresse ainsi que la séquence d’octets affectée.
Les octets entre crochets [] que l’on retrouve dans certaines lignes de la colonne «Modifié» sont des variables, c’est-à-dire que la valeur hexadécimal de ces octets peut être changée pour que la logique de l’implantation du multi-amorçage soit cohérente. À l’extrême droite, l’on retrouve une lettre (A, B, C, etc.) qui identifie chaque ligne.
On retrouve une description de chaque modification variable (celles entre crochets []) à la toute fin du fichier texte. Par exemple, la ligne identifiée par la lettre A est associée à la description identifiée par la lettre A.
Commençons par appliquer les «patches» sur le LLB (Low-Level Bootloader). Pour ce faire, l’utilisation d’un éditeur hexadécimal est requise. Exécutons HxD, puis ouvrons le fichier décrypté LLB.[BoardID].[Security Fusing]_dec.img3 qui se trouve dans le dossier «Original». Ensuite, il faut appliquer toutes les «patches» présentes dans le fichier texte correspondant à ce conteneur.
Dans mon cas, la première se trouve à l’adresse 0x00000988 et l’octet concerné est 0x74. Dans HxD, aller dans le menu «Recherche», puis «Atteindre». Dans la fenêtre d’«Atteindre», saisir l’adresse à atteindre, soit 00000988. HxD devrait alors nous mener vers cette addresse dont l’octet associé est 0x74.
Erreur d'affichage de la photo
On regarde ensuite dans la colonne «Modifié» du fichier texte qui est associée à cette adresse.
On remarque que la valeur 0x62 est entre crochets [], donc celle-ci est variable. La lettre que l’on retrouve à l’extrême droite de la ligne est «A» et l’on retrouve à la fin du fichier texte une description qui correspond à cette ligne «A». Le quatrième octet de l'étiquette magique à rechercher dans la section «firmware» de la NAND pour le conteneur IMG3 d'iBoot.
C'est une valeur qui doit représenter un caractère ASCII. Dans ce cas, on doit remplacer 0x74 par la valeur hexadécimale d’un caractère ASCII quelconque. Pour appliquer une certaine logique dans la structure du multi-amorçage, utilisons les caractères ASCII représentant les lettres minuscules de «b» jusqu’à «z». En effet, ceci permet de différencier plus facilement les différentes chaînes d’amorçage que nous allons installer sur l’appareil.
Par exemple, «b» (seconde lettre de l’alphabet) identifiera tous les éléments de la chaîne d’amorçage secondaire, «c» (troisième lettre de l’alphabet) identifiera tous les éléments de la troisième chaîne d’amorçage dans le cas d’un triple-amorçage et ainsi de suite. Prenons la table ASCII (que l’on peut retrouver avec une recherche sur Google), puis recherchons la valeur hexadécimale pour la lettre minuscule «b».
La valeur hexadécimale associée est 0x62. On doit alors remplacer 0x74 qui se trouve à l’addresse 0x00000988 par 0x62. La première modification sur le LLB est alors complétée. Passons à la suivante qui se trouve à l’adresse 0x00010010 et la sequence d’octets concernée est 0xFF 0xF7 0x6C 0xFC. Dans HxD, aller dans le menu «Recherche», puis «Atteindre». Dans la fenêtre d’«Atteindre», saisir l’adresse à atteindre, soit 00010010.
HxD devrait alors nous mener vers cette addresse dont l’octet associé est 0xFF. On regarde ensuite dans la colonne «Modifié» du fichier texte qui est associée à cette adresse. Dans ce cas, on doit remplacer cette séquence de quatre octets soit 0xFF 0xF7 0x6C 0xFC par 0x00 0x20 0x18 0x60. Les deux modifications que nous devons apporter sur le LLB sont alors complétées. Dans HxD, aller dans le menu Fichier, puis choisir Enregister sous.
Choisir le dossier «Patché» que nous avons créé à l’étape 2 en tant que destination. Ce procédé doit être répété pour les autres conteneurs décryptés qui se trouvent dans le dossier «Original», c’est-à-dire pour iBoot, le DeviceTree, le logo de démarrage ainsi que le logo du «Recovery Mode».
Faire le DeviceTree en dernier, car des modifications supplémentaires présentées à la prochaine étape doit être complétée avant d’enregistrer celui-ci dans le dossier «patché».






8) Selon les instances d'iOS qui seront impliquées dans le multi-amorçage, vérifier la compatibilité du keybag système à partir du tableau de compatibilité entre les formats du keybag système.
Si le résultat obtenu à la suite de la lecture du tableau est "Compatible", exécutons HxD, puis ouvrons le fichier décrypté DeviceTree[BoardID]_dec.img3 qui se trouve dans le dossier «Original».
Appliquer seulement les modifications «A» et «B» qui se trouvent dans le fichier DeviceTree.n90ap.txt sur le conteneur du DeviceTree actuellement ouvert dans HxD puis aller à l'étape 10 (ne pas faire l'étape 9).
Si le résultat obtenu à la suite de la lecture du tableau est "Incompatible", faire l'étape suivante (faire l'étape 9).


9) Une modification supplémentaire doit être apportée au conteneur du DeviceTree, en lien avec un éventuel problème au niveau du keybag système qui sera discuté en profondeur vers la fin de la partie B de ce tutoriel. En effet, nous devons y ajouter une contrainte qui évite la mise à jour de l’effaceable-storage lorsqu’il y a generation d’un nouveau keybag système.
Attention, cette modification est très importante. Si celle-ci est oubliée et il y a generation d’un nouveau keybag système plus tard dans la procédure, le système iOS principal ne sera plus en mesure de démarrer et l’appareil devra être restauré à la dernière version d’iOS signée.
Utiliser l’outil xpwntool pour décrypter et extraire les données du «tag» DATA pour le conteneur IMG3 du DeviceTree. L'extraction permet d'obtenir un fichier binaire qui contient uniquement les données du «tag» DATA, c'est-à-dire sans le conteneur IMG3.
En utilisant un terminal en ligne de commande, définir le dossier «Original» en tant que répertoire courant.

pmbonneau-mac#cd [chemin du dossier «Original»]
pmbonneau-mac#xpwntool [entrée, conteneur IMG3 avec données encryptées] [sortie, conteneur IMG3 avec données décryptées] -iv [IV] -k [clé]
Exemple concret d’utilisation d’xpwntool pour décrypter et extraire les données du DeviceTree d’iOS 6.1.3 (10B329) pour l'iPhone 4 (iPhone 3,1 - N90AP). Pour procéder à l'extraction des données du DeviceTree, le paramètre «-decrypt» doit être omis lors de l'utilisation d'xpwntool. Ceci fait en sorte que le fichier de sortie contiendra uniquement les données du «tag» DATA, sans l'encapsulation IMG3.
pmbonneau-mac#xpwntool DeviceTree.n90ap.img3 DeviceTree.n90ap_dec.dat -iv 4a44e07427942e3f0769cd2fb748f60e -k 19dc906dbea48840bb32c20add34ac2ac3c2e599370b9b0964a13212dd8aa7e4
Pour appliquer cette modification, exécutons HxD, puis ouvrons le fichier décrypté DeviceTree[BoardID]_dec.dat qui se trouve dans le dossier «Original». Aller dans le menu «Recherche», puis «Rechercher». Dans la boîte de texte, saisir «content-protect» puis appuyer sur la touche «entré». HxD devrait trouver une occurrence.
Erreur d'affichage de la photo
Dans l'archive .zip qui contient les «patches» nécessaires à l’exécution du multi-amorçage iOS téléchargée à l'étape 7, répérer le fichier DeviceTree.n90ap.bin puis ouvrir celui-ci dans HxD. Ce fichier contient l'entrée «no-effaceable-storage», les données associées à celle-ci ainsi que deux balises («content-protect» et «AAPL,phandle») utiles pour une application cohérente de la modification.
C'est l'ajout de l'entrée «no-effaceable-storage» dans le DeviceTree qui permet de contourner le problème occasionné par la génération d'un nouveau «keybag» système.
Faire une sélection de tous données binaires contenues dans ce fichier binaire .bin, puis «copier».
Erreur d'affichage de la photo
Retourner dans le fichier DeviceTree.n90ap_dec.dat, faire une sélection à partir de «content-protect» jusqu'à «AAPL,phandle», puis «coller en insérant».
Erreur d'affichage de la photo
L'insertion de l'entrée «no-effaceable-storage» dans le DeviceTree devrait ressembler à ceci.
Erreur d'affichage de la photo
Dans HxD, aller dans le menu Fichier, puis choisir Enregister sous. Choisir le dossier «Patché» que nous avons créé à l’étape 2 en tant que destination.
Il faut ensuite encapsuler à nouveau le DeviceTree modifié dans un conteneur IMG3 pour que le chargeur d'amorçage de second niveau (iBEC, iBoot) puisse être en mesure de charger celui-ci.
Pour y parvenir, utilisons l'outil IMG3Maker développé par Winocm. Celui-ci permet de construire un conteneur IMG3 qui encapsulera les données binaires fournies en entrée.
Une version compilée pour iOS de l'outil IMG3Maker se trouve dans le paquet «iOS-kexec-Utils» qui est disponible sur mon «repository» (source) Cydia http://pmbonneau.com/cydia.
Un appareil iOS avec «jailbreak» sera donc nécessaire pour installer puis exécuter IMG3Maker. Il est aussi intéressant d'installer le paquet OpenSSH pour avoir un accès en SSH sur l'appareil puisque l'outil IMG3Maker fonctionne en ligne de commandes. Sinon, il est toujours possible d'utiliser le protocol AFC2 pour transférer le fichier DeviceTree.n90ap_dec.dat vers l'appareil et utiliser MobileTerminal pour exécuter IMG3Maker.
Procéder à l'installation d'«iOS-kexec-Utils» à partir de mon «repository» (source) Cydia http://pmbonneau.com/cydia.
Téléverser par SSH ou bien par AFC2, le fichier DeviceTree.n90ap_dec.dat vers le dossier /tmp de l'appareil.
Avec l'aide d'un terminal SSH tel que PuTTY par exemple, ouvrir une connexion sur l'appareil puis exécuter IMG3Maker avec les paramètres suivants.
iPhone-4-N90AP-iOS-712#img3maker -t dtrb -f /tmp/DeviceTree.n90ap_dec.dat -o /tmp/DeviceTreeB.n90ap.img3
Erreur d'affichage de la photo
Télécharger le fichier /tmp/DeviceTreeB.n90ap.img3 de l'appareil vers le dossier «Patché» que nous avons créé à l’étape 2.
Ouvrir dans HxD, le fichier DeviceTreeB.n90ap.img3 téléchargé précédemment qui devrait être situé dans le dossier «Patché».
Appliquer toutes les modifications qui se trouvent dans le fichier DeviceTree.n90ap.txt sur le conteneur du DeviceTree actuellement ouvert dans HxD. Prendre note que les modifications «A» et «B» qui se trouvent dans ce fichier concernent l'étiquette magique de l'entête du conteneur IMG3 ainsi que celle du «tag» TYPE. Le paramètre -t de l'outil IMG3Maker permet de définir celles-ci directement lors de la construction du conteneur.


10) Enregistrer le conteneur modifié dans le dossier «Patché».
Toujours dans l’application d’une certaine logique dans la structure du multi-amorçage, renommer les fichiers modifiés qui se trouve dans le dossier «Patché» de cette façon.
applelogoB@[résolution de l’écran].[Système sur Puce].img3
recoverymodeB@[résolution de l’écran].[Système sur Puce].img3
DeviceTreeB[BoardID].img3
iBootB.[BoardID].[Security Fusing].img3
LLBB.[BoardID].[Security Fusing].img3
Ajouter la lettre B dans le nom de fichier des conteneurs, si par exemple «b» (seconde lettre de l’alphabet) identifie tous les éléments de la chaîne d’amorçage secondaire. Ceci facilite le «debug».
La chaîne d’amorçage secondaire peut maintenant être «flashée» dans la section «firmware» de la NAND.








11) Il est assez simple de controller les conteneurs qui seront «flashés» dans la section «firmware» de la NAND lors du processus de restauration. Pour ce faire, ouvrir le fichier «manifest» qui se trouve dans le dossier «Original» en utilisant NotePad++ (recommandé) ou tout autre éditeur de texte. Le contenu du fichier «manifest» ressemble à ceci.
Erreur d'affichage de la photo
Tous les fichiers présents dans cette liste seront «flashés» lors du processus de restauration. Plus précisément, ceux-ci sont rassemblés en un bloc unique, soit le «NORData» et celui-ci est ensuite envoyé vers l’appareil par le processus de restauration. À la base, on retrouve dans cette liste les éléments d’amorçage de l’instance primaire d’iOS.
Le processus de restauration ne contrôle pas les fichiers additionnels dans la liste, celui-ci les rassemble tous pour former le «NORData» et «flash» le tout dans la section «firmware» de la NAND. Cette section est toutefois limitée en taille. Si le «NORData» est trop volumineux, le processus de restauration retournera une erreur et l’appareil redémarrera dans le «Recovery Mode» de l’instance primaire d’iOS.
Dans le but d’implanter un multi-amorçage de type «Untethered», il faut «flasher» les éléments d’amorçage des autres instances d’iOS avec ceux de l’instance primaire. Les éléments d’amorçage secondaires «flashés» seront ceux qui se trouvent dans le dossier «Patché», soit ceux qui sont décryptés et modifiés.
Ajoutons les éléments suivants à la liste, soit dans le fichier «manifest» sans écraser ceux de l’instance primaire.
applelogoB@[résolution de l’écran].[Système sur Puce].img3
recoverymodeB@[résolution de l’écran].[Système sur Puce].img3
DeviceTreeB[BoardID].img3
iBootB.[BoardID].[Security Fusing].img3
Erreur d'affichage de la photo
Il n’est pas nécessaire d’ajouter le LLB dans la liste des conteneurs à «flasher», car celui-ci sera exécuté par kloader à partir du système de fichiers de l’instance primaire d’iOS.
Enregistrer le fichier «manifest» modifié dans le dossier «Patché».
Ce dossier devrait alors ressembler à ceci.
Erreur d'affichage de la photo







12) Ajoutons ces conteneurs IMG3 dans le dossier \Firmware\all_flash\all_flash.[BoardID].production\ qui se trouve dans le fichier .ipsw de la version d’iOS primaire. L’utilisation du logiciel 7-zip est conseillée pour faire ceci.
Dans mon cas, la version d’iOS primaire sera iOS 7.1.2 (11D257) pour l'iPhone 4 (iPhone 3,1 - N90AP), soit la dernière version signée par Apple disponible pour cet appareil. L’amorçage de l’instance primaire sera de type «Untethered».
Le fichier «manifest» qui est déjà présent dans le fichier .ipsw doit être remplacé par celui modifié à l’étape précédente.
Une fois ceci complété, s’assurer que tout est cohérent entre les fichiers présents dans la liste du «manifest» et les fichiers présents dans le répertoire \Firmware\all_flash\all_flash.[BoardID].production\.
Par exemple, le processus de restauration échouera si le nom d’un fichier est présent dans la liste, mais pas dans le dossier \Firmware\all_flash\all_flash.[BoardID].production\.

13) Utilisons l’outil idevicerestore pour restaurer le fichier .ipsw modifié sur l’appareil. Cet outil est une alternative à iTunes pour exécuter des opérations de restauration sur les appareils iOS. Ce fichier .ipsw modifié pourrait être restauré sur l’appareil à l’aide d’iTunes sans l’utilisation d’un exploit de bas-niveau, mais celui-ci ne semble pas «flasher» les conteneurs additionnels d’après certaines expériences.
En utilisant idevicerestore, les conteneurs additionnels seront «flashés». Plaçons l’appareil en »Recovery Mode» en appuyant sur le bouton «home», puis en branchant le câble (dont l’autre extrémité est reliée à l’ordinateur). L’appareil devrait alors afficher le logo du «Recovery Mode».
Utilisons idevicerestore comme suit :
pmbonneau-mac#idevicerestore –e [Fichier .ipsw à restaurer]
L’option –e signifie «erase», donc tout le contenu de l’appareil sera effacé. Soyez certains que cet appareil ne contient pas de données importantes avant de continuer.
Par exemple, pmbonneau-mac#idevicerestore –e C:\Users\Pierre-Marc\Desktop\iPhone 4 Multi-Amorçage\ iPhone3,1_7.1.2_11D257_Restore.ipsw
Le processus de restauration devrait démarrer. Si tout c’est bien déroulé, l’appareil devrait redémarrer sous setup.app (l’application de configuration qui est exécutée au premier démarrage). Vérifier dans la console d’idevicerestore si les conteneurs IMG3 additionnels ont bien étés «flashés».
On remarque sur cette capture d’écran que les conteneurs IMG3 additionnels ont bien étés pris en considération.
Erreur d'affichage de la photo


Ceci complète la partie A, soit la mise en place des séquences d’amorçage secondaires. La partie B traitera de l’implantation du multi-amorçage au niveau «Userland».

Partie «Userland» (B)




Copyright © 2017 — Pierre-Marc Bonneau

Conditions d'utilisation