La chaîne du démarrage en mode DFU (iBSS.n90ap.RELEASE.dfu et iBEC.n90ap.RELEASE.dfu):
Lorsqu'un maillon de la chaîne du démarrage est incorrectement signé ou en erreur, l'appareil se met au «Fail-Safe» du maillon précédent. Par exemple, l'appareil se placera en mode Recovery (le «Fail-Safe» d'iBoot) si le kernel échoue la validation des signatures
et de l'intégritée que doit faire iBoot avant de lancer celui-ci.
a) Mode normal
SecureROM --> LLB --> iBoot --> DeviceTree + Kernel --> Système de fichiers sur NAND
b) Mode DFU
SecureROM --> iBSS --> iBEC --> DeviceTree + Kernel --> RamDisk ou système de fichiers sur NAND
Pour les versions d'iOS 4.x et antérieures, le kernel est envoyé puis chargé directement à partir d'iBSS. Ceci fait en sorte que pour ces versions, il est alors possible de ne pas utiliser l'iBEC dans le processus d'amorçage en mode DFU.
Si l'on observe la taille des fichiers iBSS.n90ap.RELEASE.dfu et iBEC.n90ap.RELEASE.dfu de ces versions d'iOS, l'on remarque que leur taille ainsi que leur contenu sont très semblables.
Pour ce qui est des versions d'iOS 5.x jusqu'à celles d'aujourd'hui, l'iBSS place l'appareil dans un mode appelé «Soft-DFU» pour «Mode DFU logiciel» qui est en quelque sorte une extension logiciel du mode DFU matériel (SecureROM). La fonction principale de ce mode DFU logiciel est
de recevoir l'iBEC, puis de vérifier s'il est bien signé. Le même principe s'applique pour la chaîne de démarrage sur NAND (mode normal).
La SecureROM (chargeur d'amorçage de niveau 0 aussi nommée BootROM) :La SecureROM est une mémoire d'environ 64ko qui est en lecture seule. Celle-ci se retrouve dans le Système sur Puce (SoC pour System on Chip), aussi nommé A4, A5, A5X et autres selon l'appareil. Le code contenu dans la SecureROM est le premier chargeur d'amorçage de toute la chaîne de confiance et c'est le seul qui est matériel. Il s'exécute lors du démarrage d'un appareil iOS, c'est-à-dire aussitôt que l'on appuie sur le bouton d'allumage. Celui-ci est gravé lors du processus de fabrication de l'appareil ce qui fait en sorte qu'il est impossible même pour Apple d'apporter des modifications à celui-ci. ROM veut dire Read Only Memory, une mémoire en lecture seule qui est donc non-modifiable. Pour ce qui est de «Secure», deux théories possible. Premièrement, étant donné que ce code est non-modifiable puisqu'il est stocké dans une mémoire en lecture seule, il sera toujours possible d'y faire appel en cas d'une mauvaise manipulation de l'iPhone qui l'empêcherait de démarrer normalement. C'est le mode DFU (Device Firmware Update) qui se trouve à être aussi le «Fail-Safe» de la SecureROM. Ce mode permet de charger en mémoire une chaîne de démarrage minimale et non-persistente (perdue lors du redémarrage) dans le but de pouvoir démarrer sur un RamDisk (une sorte de mini système d'exploitation) qui peut être utilisé pour la restoration du système iOS. Le mode DFU est donc une sécurité puisqu'il permet, grâce au chargement d'un RamDisk, de réinstaller les chargeurs d'amorçages logiciels ainsi que le système iOS pour remettre en fonction le mode normal lorsque celui-ci est corrompu ou incorrectement signé.
Deuxièmement, la SecureROM est capable grâce à un système de certificats de valider les signatures et l'intégrité de la partie suivante du démarrage, soit le LLB pour le mode normal et l'iBSS pour le mode DFU dans le but de s'assurer que c'est bien du code approuvé par Apple qui est exécuté. Particularités de la SecureROM : Son «Fail-Safe» : Le mode DFU matériel La chaîne de démarrage «patchée» Le LLB (chargeur d'amorçage de premier niveau) : Le LLB (Low-Level Bootloader) est le chargeur d'amorçage suivant la SecureROM pour le démarrage sur NAND (mode normal). L'intégritée de celui-ci est vérifiée par le système de validation des signatures présent dans SecureROM avec l'aide d'un blob SHSH distribué par le serveur de signatures d'Apple.Les deux rôles principales du LLB : 1) LLB recherche l'APTicket et le vérifie à l'aide d'un blob SHSH distribué par le serveur de signatures d'Apple. 2) LLB recherche une image de type iBoot dans la section «firmware» de la NAND et valide celle-ci à l'aide de l'APTicket avant de l'exécuter. Si LLB ne trouve pas d'image de type iBoot dans la section «firmware» de la NAND ou ne parvient pas à valider celle-ci, l'appareil se place dans le «Soft-DFU Mode» et peut recevoir et exécuter iBoot ou iBEC (chargeurs d'amorçage de second niveau) si la signature est valide. La sécurité des appareils iOS au niveau du démarrage. La SecureROM est dans une mémoire ROM, gravée dans l'appareil, donc non-modifiable. Étant donné que celle-ci vérifie si le LLB est bien signé au démarrage en mode normal, il est alors très difficile (pour ne pas dire impossible, puisqu'il ne faut pas oublier le hacking) de «patcher» ce dernier pour annuler la vérification des signatures du niveau suivant, soit l'iBoot. Le LLB doit vérifier si celui-ci est correctement signé aussi. L'iBoot étant alors validé, il empêche l'utilisateur de charger un kernel modifié qui annulerait les restrictions au niveau de l'interface utilisateur d'iOS comme le fait d'empêcher l'exécution d'applications non-approuvées par Apple (autres que celles disponible dans l'App Store). Ce principe de chaîne de confiance dont chaque maillon est responsable de la vérification du suivant s'applique tant pour le démarrage en mode normal qu'en mode DFU (pour une restoration par exemple). En mode DFU matériel, la SecureROM vérifie si l'iBEC ou l'iBSS est bien signé avant de l'exécuter. Si la vérification est correcte, l'iBEC ou l'iBSS vérifiera si le kernel chargé est valide à son tour. Si oui, celui-ci sera exécuté puis fera la validation du ramdisk avant de le démarrer.
De cette façon, Apple s'assure que ce tout ce qui est installé sur les appareils qui sont destinés à être vendus est approuvé (correctement signé) et officiel. La validation par signature numérique permet aussi d'empêcher toute tentative de downgrade et d'installation de firmwares modifiés ou non-approuvés sur les appareils destinés aux consommateurs puisque les signatures ne seront pas valides à l'endroit où la simple modification de la chaîne sera fait. Il est important de noter que la détection de signatures invalides fait en sorte que l'appareil tombe dans le «fail-safe» de la partie de la chaine du démarrage qui a fait la validation. Note : L'astérix (*) devant le nom d'un élément de démarrage signifie qu'un patch lui est appliqué.