Comparaison de Kloader avec l'Exploit BootROM

Voir Les KexecUtils de Winocm pour iOS pour comprendre la base du fonctionnement de kloader.

Pour les exemples suivants avec l'outil kloader, supposons que nous utilisons un iPhone 4S (N94AP) avec iOS 8.4 installé dessus.
Note : L'astérix (*) devant le nom d'un élément de démarrage signifie qu'un patch lui est appliqué.
Premièrement, kloader est un utilitaire en interface ligne de commandes que l'on retrouve pas dans l'AppStore puisque celui-ci n'est pas approuvé et signé par Apple. L'appareil doit donc être jailbreaké pour permettre l'exécution du code non-signé minimalement au niveau du kernel. De plus, le jailbreak doit «patcher» le Task_for_pid du kernel pour permettre à kloader de lire et écrire dans la région VM. Pour ce qui est du cas de l'iPhone 4S sous iOS 8.4, l'outil grand public permettant le jailbreak de cette version est TaiG. Suite au jailbreak, la chaîne de démarrage en mode normal de l'appareil ressemble à ceci.
SecureROM (RELEASE) --> iOS 8.4 LLB (RELEASE) --> iOS 8.4 iBoot (RELEASE) --> DeviceTree (validé) + iOS 8.4 Kernel (RELEASE) --> Système iOS 8.4 (non-validé).
Il est alors possible de transférer l'utilitaire kloader sur l'appareil, puis de lancer celui-ci avec les fichiers exécutables IMG3 requis. Très important, kloader fonctionne seulement avec des fichiers IMG3 decryptés parce que la clé AES GID devient inaccessible à la fin de la chaîne de démarrage initiale, soit lorsque le kernel démarre.
On désire rétrograder ("Downgrader") vers iOS 6.1.3 cet iPhone 4S actuellement sous iOS 8.4 jailbreaké en utilisant la méthode Odysseus. En résumé, celle-ci consiste à utiliser kloader pour initier la restauration d'un ancien firmware toujours signé ou encore, dont les signatures SHSH ont étés sauvegardées. Pour l'iPhone 4S et l'iPad de deuxième génération, Apple
distribue toujours les signatures d'iOS 6.1.3 pour que les mises à jour vers le dernier iOS en Over-The-Air soient toujours possible à partir d'un appareil sous iOS 5.
On passe alors l'iBSS* (RELEASE) décrypté d'iOS 6.1.3 en argument à kloader.
Nous en somme au même point qu'avec l'utilisation d'un exploit BootROM dont l'iBSS* (RELEASE) est chargé, c'est à dire que les images non-signés sont permises à partir de ce point. L'appareil reçoit puis charge l'iBEC* (RELEASE décrypté, suivi du DeviceTree (non-validé) + Kernel* (RELEASE) decrypté
et enfin le Ramdisk modifié et decrypté qui permettera la restauration d'iOS 6.1.3 ou du firmware personnalisé.
La chaîne de démarrage ressemblera à ceci.
kloader / iBSS* (RELEASE) --> iBEC* (RELEASE) --> «Second» Kernel (RELEASE) --> Système de fichiers du second iOS ou utilisation d'un Ramdisk
Si au lieu d'iBEC, on charge puis exécute iBoot, l'accès à la clé AES GID ne sera toujours pas possible. Il faudra donc toujours fournir des images décryptées, sinon kloader voit que du n'importe quoi.
Prenons en note que si un firmware personnalisé dont tous les images qui seront flashées dans la section firmware de la NAND ne sont pas signées (rétrograde vers une version non-signée par exemple), l'appareil sera coincé en mode DFU au redémarrage et il faudra obligatoirement restaurer une version signée d'iOS.

Limites de kloader :
a) La chaîne de démarrage doit être brisée (jailbreak) minimalement au niveau du kernel et ce, idéalement de façon untethered pour permettre le lancement de kloader. Cela signifie qu'un système iOS correctement signé doit être préalablement installé, ce qui occasionne un certain inconvénient puisqu'il faudra toujours attendre qu'un jailbreak au niveau du kernel soit developpé. Si un exploit de plus bas niveau (BootROM et iBoot) est utilisé, alors l'usage de kloader devient inutile sauf pour l'exécution d'un multi-amorçage «untethered».
b) Kloader permet seulement de lancer des exécutables IMG3 decryptés, puisque la clé AES GID est désactivée lors du démarrage initial (signé). C'est plus précisément le kernel qui va désactiver cette clé, comme on peut le voir dans cette chaîne du démarrage qui représente un jailbreak régulier «userland».
SecureROM (RELEASE) --> LLB (RELEASE) --> iBoot (RELEASE) --> DeviceTree (validé) + Kernel* (RELEASE) et clé AES GID désactivée (pendant le démarrage du kernel) --> Système iOS (non-validé)

Pour les prochains exemples avec Limera1n, supposons que nous utilisons un iPhone 4 (N90AP) avec iOS 7.1.2 installé dessus.
Note : L'astérix (*) devant le nom d'un élément de démarrage signifie qu'un patch lui est appliqué.
Premièrement, il y a une vulnérabilité dans le protocole USB du mode DFU dans le Système sur Puce (SoC) A4 dont l'iPhone 4 (N90AP) et certains autres appareils en sont munis. L'exploit public permettant d'utiliser cette vulnérabilité se nomme Limera1n.
On désire rétrograder ("Downgrader") vers iOS 6.1.3 cet iPhone 4 actuellement sous iOS 7.1.2 pas jailbreaké.
On éteint, puis on place l'appareil en mode DFU. Il est donc possible d'y injecter le code de Limera1n avec l'aide d'un outil tel que RedSn0w, iREB, TetheredBoot Utility, etc. Une fois le code de Limera1n injecté, le début de la chaîne de démarrage (mode DFU) ressemble alors à ceci.
Mode DFU, SecureROM (RELEASE + Limera1n) => SecureROM* (RELEASE). L'appareil est maintenant dans ce que l'on appelle le «PwnDFU Mode». Le processus de validation des signatures pour l'élément suivant de la chaîne du démarrage en DFU est ignorée.
ARTICLE À SUIVRE

Copyright © 2017 — Pierre-Marc Bonneau

Conditions d'utilisation