Multi-Amorçage iOS

Partie Amorçage «Untethered» (A)

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.


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.

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.

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».

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 :

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.

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.

Partie «Userland» (B)