Parlons d’un sujet très tabou dans le monde de la sécurité iOS. Il y a quelques mois Motherboard dévoilait que certains hackers utilisaient les prototypes d’iPhone pour faire de la recherche.

Prototypes d’iPhone

Il y a trois types d’appareils considérés comme prototypes :

  • EVT : Engineering Verification Test
  • DVT : Design Verification Test
  • PVT : Production Validation Test

Les deux premiers sont les plus intéressants puisqu’ils permettent de faire debugging de bas niveau appelé Serial Wire Debugging. Le troisième type d’appareil est juste un appareil de production défectueux qui n’a pas passé les tests de qualité. Et qui se retrouve uniquement avec un firmware d’usine : Switchboard.

Ceux ayant la possibilité de faire du SWD sont ceux ayant un mode de production Development ou un mode de sécurité Insecure. Ils ont un identifiant CPFM (Chip Fusing Mode) à 00 ou 01. On peut obtenir Fusing Mode grâce à PurpleSnif

iPhone 5C EVT

J’ai reçu une carte mère d’iPhone 5C EVT. J’ai échangé la carte d’un iPhone 5C de production par celle-ci. Puis j’ai démarré l’iPhone.

Celui-ci tourne sur une version de Switchboard équivalente à iOS 7.0 (11A93840I). Si vous avez un câble permettant une connexion série, vous pouvez aussi obtenir un shell-over-serial. Il suffit d’ajouter l’argument de démarrage suivant : serial=3.

Serial Wire Debug

A l’aide de certains câbles , on peut communiquer avec l’interface SWD de l’iPhone de développement. SWD est une alternative à JTAG pour ARM. Cela permet d’accéder à la mémoire de l’iPhone en lecture et écriture, mais aussi au registres. On peut charger de nouvelles images non-signées pour exécuter nos propres payloads.

iBoot dumping

Pour dumper l’iBoot il faut passer l’iPhone en recovery. Vous pouvez le faire avec enter_recovery. Celui-ci redémarre en mode recovery et affiche le logo d’iTunes à l’écran. Via la console on peut voir que l’iPhone est bel et bien en recovery mode

A l’aide d’Astris, l’outil interne d’Apple utilisé pour faire du debugging de bas niveau, on va pouvoir stopper exécution du CPU pour récupérer l’image de l’iBoot.

Il nous suffit maintenant d’utiliser la commande embarquée dans Astris : save name addr size. Pour cela il nous faut l’adresse de base de notre image ainsi que sa taille.

Pour cela rien de plus simple. A l’aide des informations contenues dans le fichier memmap.h du code source de l’iBoot qui a fuité, j’ai repris ces données pour dans un script Python pour éviter de tout calculer :

#!/usr/bin/python3

SDRAM_BASE = 0x80000000
SDRAM_BANK_LEN = 0x20000000
SDRAM_BANK_COUNT = 2
SDRAM_END = SDRAM_BASE + (SDRAM_BANK_LEN * SDRAM_BANK_COUNT)

PANIC_SIZE = 0x00004000
PANIC_BASE = SDRAM_END - PANIC_SIZE

IBOOT_SIZE = 0x00100000 - PANIC_SIZE
IBOOT_BASE = PANIC_BASE - IBOOT_SIZE

print("iBoot base : %s" %  hex(IBOOT_BASE))
print("iBoot size : %s" %  hex(IBOOT_SIZE))

Pour la taille j’ai préféré prendre la même que celle des images iBoot de production.

λ ~ » python3 iboot_addr_base.py 
iBoot base : 0xbff00000
iBoot size : 0xfc000
λ ~ » python3 -c "print(hex(317 * 1000))"
0x4d648

Il reste plus qu’à récupérer l’image.

On vérifie qu’on a bien récupéré l’image de l’iBoot :

λ ~ » xxd iboot.bin
[...]
000001e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000200: 6942 6f6f 7420 666f 7220 6e34 3861 702c  iBoot for n48ap,
00000210: 2043 6f70 7972 6967 6874 2032 3031 332c   Copyright 2013,
00000220: 2041 7070 6c65 2049 6e63 2e00 0000 0000   Apple Inc......
00000230: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000240: 4445 5645 4c4f 504d 454e 5400 0000 0000  DEVELOPMENT.....
00000250: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000260: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000270: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000280: 6942 6f6f 742d 3139 3430 2e31 2e32 3000  iBoot-1940.1.20.
00000290: 0000 0000 0000 0000 0000 0000 0000 0000  ................

Debugging

Astris va ouvrir un port pour chaque cœur. Cela permet de faire du remote debugging à l’aide de GDB. Si vous avez un appareil avec SEP, vous pourrez aussi attacher le debugger dessus.


Cette histoire de prototypes et de sondes JTAG/SWD reste encore très secrète au vu de l’obscurité du business, du prix de vente de ces appareils et des câbles.

Nyan Satan a fait un thread sur les câbles SWD : https://twitter.com/nyan_satan/status/1090989650280398849?s=20.

Le fameux article de Vice : https://www.vice.com/en_us/article/gyakgw/the-prototype-dev-fused-iphones-that-hackers-use-to-research-apple-zero-days

Dès qu’il sera disponible, je mettrait un lien vers un article sur une sonde JTAG particulièrement intéressante.

J’aurais pû faire une analyse sur des appareils plus récents, mais chaque chose en son temps (cf la première image du post) ;)


Si vous avez besoin d’infos ou souhaitez corriger des erreurs, vous pouvez me ping sur Twitter : matteyeux.