Une fois n'est pas coutume la Team Reswitched nous informe via Discord comment elle a pu obtenir le bootrom de la Nintendo Switch.
Pour faire cela elle a utilisé plusieurs dispositifs matériels :
- Un prototype Jetson (SOC Tegra K1- GPU NVIDIA Kepler avec 192 coeurs CUDA/ Processeur quad-core NVIDIA 4-Plus-1 ARM Cortex-A15) pour environ 550 euros
- Un ChipWhisperer (un dispositif de recherche pour automatiser les processus de glitching) pour environ 230 euros
- FPGA environ 85 euros
- Des transistors, des nappes, des drivers pour 50 euros
- Un oscilloscope (optionnel)
- Un analyseur logique (optionnel)
Donc vous le voyez il faut au minimum 1000 euros de matériel pour parvenir à un tel résultat.
hedgeberg - Aujourd'hui à 6:28
Le verrouillage est temporaire juste pour les besoins de cette explication. Tout d'abord, cela va permettre d'expliquer ce qui est exactement bootrom et pourquoi il ne peut être obtenu par d'autres moyens.
...
hedgeberg - Aujourd'hui à 6:29
Faites-moi savoir si je fais des erreurs flagrantes ou si j'ai raté quelque chose, absolument
Donc, parlons de Tegra : quand il s'agit du tegra, toute l'exécution commence par le BPMP, sous ce nom se cache le Boot et le Power Management Processor (un ARM7TDMI). Pour ceux d'entre vous qui se sont intéressé à "jamais vu", cela devrait vous sembler familier: c'est la même chose !
Fondamentalement, le BPMP est chargé de tout configurer sur le TX1 afin que les choses soient sûres et prêtes à être exécutées quand il est temps que l'OS commence à fonctionner sur l'AP (Processeur Application). L'AP est un processeur aarch64 à 4 coeurs où fonctionne presque tout le système d'exploitation, et pour le reste nous n'en parlerons pas vraiment car tout ce qui nous intéresse est avant que cela soit actif .
Donc, quand nous parlons de bootrom, nous parlons du tout premier code à exécuter sur le BPMP. C'est un ensemble d'instructions brûlées dans le silicium sur la couche physique en utilisant ce qu'on appelle un "masque", essentiellement un ensemble de fils métalliques qui sont utilisés pour coder 1 ou 0. En outre, il existe un ensemble de "eFuses", c'est-à-dire des fusibles qui sont utilisés pour stocker de façon permanente et irréversible des informations en usine avant que l'appareil ne soit expédié. Les eFuses contiennent des patches pour le bootrom afin que NVIDIA puisse réparer les bogues de bootrom avant d'expédier le SoC sans fabriquer un nouvel ensemble de masques et de refaire toute la production de la puce. En outre, la clé de démarrage sécurisée (aka SBK) et d'autres informations importantes sur la console sont stockées dans les eFuses.
Le bootrom est généralement un gros désordre de code spaghetti et il est responsable de choses importantes. Par exemple, le bootrom lit la BCT (boot config table) à partir du Flash NAND et l'utilise pour déterminer ce qui est dans la NAND et ce qui est sûr à démarrer. Dans le Switch, seules les entrées BCT signées par Nintendo peuvent être chargées, car le TX1 vérifie l'entrée BCT en utilisant la cryptographie RSA. C'est un code complexe et à haute responsabilité, c'est généralement là où beaucoup de vulnérabilités soignées finissent, et les fabricants le savent, donc ils verrouillent l'accès au bootrom avant qu'ils ne pivotent pour exécuter ce que nous appelons le "stage 1 bootloader "ou Package1 sur la Switch. L'idée est que si les pirates n'ont pas accès au code, ils ne peuvent pas trouver de vulnérabilités.
Cela nous laisse 2 options :
1. Trouver un exploit dans le bootrom qui nous permet de vider le bootrom avant lockout, et le faire sans le code réel se fait essentiellement à l'aveugle.
2. Empêchant en quelque sorte le verrouillage du bootrom est de "tromper" le processeur pour qu'il prenne un chemin ou un ensemble d'instructions qu'il n'aurait jamais eu s'il fonctionnait correctement.
3. Il y a aussi une troisième option, la décapsulation ou le «décapsulage», mais c'est un processus absurdement coûteux qui est hors de portée d'une équipe comme la nôtre.
La première solution est possible, le TX1 est un SoC vraiment très complexe avec des milliers de routes de fuzzing potentielles. En tant que tel, la solution 2 est idéale. Mais la question est alors, comment pouvons-nous réellement provoquer une des 2 situations ?
Idéalement, nous atteindrions un point où, lorsque notre code commencera à s'exécuter, le bootrom ne sera pas bloqué, et nous pourrons le supprimer dès que notre code commencera à s'exécuter.
Cela signifie que nous avons besoin de 2 choses : faire sauter le verrouillage réel, et l'exécution de code qui permet de lire.
Pour cela nous ne devons donc pas utiliser une Switch mais une plateforme Jetson, car sur Switch le code doit être signé par Nintendo, sur la carte de développement nVidia pas besoin de signer, et ce sont les mêmes SoC employés. Le code BootRom est le même quelques patchs sont différents.
Le lock (la sécurisation) du BootRom est réalisé par le BootRom lui même sur le Jetson. L'idée est de sauter cette instruction ou de corrompre son fonctionnement. Dans ce cas, ce serait l'opération de stockage dans le BPMP, si nous sautons cette instruction, ce registre n'est jamais écrit, et quand nous obtenons l'exécution, nous pouvons lire dans l'espace que le bootrom cherche comme si nous écrivions dans n'importe quelle autre région de la mémoire.
En fait, l'idée est que si nous pouvons sauter par-dessus cette instruction tout en laissant le bootrom continuer à s'exécuter, quand nous atterrissons dans le firmware BPMP que nous contrôlons sur le Jetson, nous serons en mesure de lire le bootrom. C'est là que le "glitching" entre en jeu.
Le glitching est essentiellement le processus d'injection d'une sorte de bruit contrôlé (oui, c'est un abus de langage) sur l'alimentation électrique pour corrompre le fonctionnement du processeur. Les processeurs sont conçus pour fonctionner avec une certaine gamme d'opérations, avec un certain nombre de constantes environnementales. Ainsi, par exemple, ils s'attendent généralement à travailler dans une plage de -25 ° C à 100 ° C ou dans une telle plage, et en dehors de cette plage, leur comportement peut devenir imprévisible et erratique.
On comprend que cela pourrait être difficile à mettre en place, cependant, avec un FPGA (Field Programmable Gate Array) et un grand mosfet à grande vitesse, nous pouvons très rapidement et précisément changer la tension d'alimentation qui est mise à la disposition du BPMP. Ce genre de pépin est appelé une "panne de courant" ou "pince crowbar", l'idée étant que vous êtes en train de forcer la valeur que vous voulez pour une courte période de temps.
Si le BPMP n'a pas une tension suffisamment élevée pour pouvoir fonctionner correctement, les données à l'intérieur seront corrompues. Coupez la tension pendant trop longtemps, et vous arrêterez le processeur comme un moteur pourrait caler si vous coupez l'alimentation en gaz. Tirez la tension vers le bas pendant trop peu de temps, et les capacités internes qui existent sur les grilles des transistors à l'intérieur du SoC n'ont pas le temps de changer réellement. Mais, si vous atteignez un point idéal en termes de timing, vous pouvez créer une situation où quelques bits peuvent changer à différents endroits.
Disons, par exemple, que vous avez corrompu le registre du compteur de programmes tout comme il était incrémenté au bon moment. Vous pourriez provoquer une sur-incrémentation, en ignorant les instructions. Cet événement n'est pas susceptible de se produire réellement, mais c'est un exemple facile à conceptualiser. Les processeurs modernes sont extrêmement complexes, l'exécution d'une instruction nécessite de longs pipelines de pré-traitement, et les différentes étapes de ces pipelines peuvent avoir des effets différents si elles sont modifiées.
Comme nous n'avons pas le bootrom, nous ne savons pas exactement où l'instruction que nous voulons ignorer se positionne.
Une fois que vous avez modifié la carte pour qu'elle soit prête pour l'attaque, et que vous ayez votre charge utile prête à fonctionner sur le bpmp, vous devez trouver la bonne position dans le temps pour provoquer la corruption désirée, de sorte que vous voulez quelque chose pour automatiser ce processus.
C'est là qu'entre en jeu le chipwhisperer, qui est un matériel d'un hacker nommé Colin O'Flynn, conçu pour faciliter le processus d'automatisation.
Avec lui, il est question de fouiller de manière aléatoire jusqu'à ce qu'à un redémarrage, la charge utile arrive à lire dans l'espace bootrom. C'est aussi siple que de le décharger sur UART.
En même temps, la Team travaille sur le glitching pour obtenir l'exécution du code sur Switch BPMP pour obtenir des choses comme keyblobs (comme Derrek) mais c'est un processus beaucoup plus complexe. Au lieu de cibler une écriture de registre, nous avons ciblé une branche qui vérifiait si la clé RSA stockée dans une entrée BCT était correcte, incitant le processeur à accepter un BCT que nous avons signé au lieu de Nintendo.
Après analyse, le flux est différent, le glitch de tension est meilleur pour attaquer des choses comme des hashs et des opérations crypto, des variables qui utilisent beaucoup de puissance. Le glitch permet aussi d'affecter des calculs ou des adresses.
Enfin la Team explique pourquoi l'option 3 est difficile à mettre en oeuvre, expliquant que le 22 nm complique l'analyse, les SoC modernes sont de plus en plus petites, protégés par une largeur d'atome de carbone, 10 couches de câblages métalliques, au dessus des transistors et du substrat, et que pour analyser physiquement la puce, il faut analyser chaque couche, il faut gratter chaque couche, dissoudre chaque couche à l'époxy, et cela demande souvent de sacrifier plusieurs consoles pour le faire correctement.
En conclusion, la Team explique que ce n'était pas terriblement complexe à mettre en place, le glitch bootrom n'a pas besoin de BTC, et après avoir synchronisé en utilisant un FPGA pour traiter les commandes eMMC, ils ont pu lire via les eMMC, pour déclencher l'attaque sur le TX1.
Il faut analyser le temps qui s'écoule entre la fin d'une lecture et le début d'une autre pour essayer de déterminer quels chemins de code sont exécutés. Cela semble facile à partir d'un niveau élevé parce que, globalement, le concept est assez simple, mais il a fallu environ 200 heures au moins pour que le système atteigne un point où il était juste «opérationnel».
Tout est là : Pastebin.com
[MULTI] Zelda Twilight Princess natif avec la 1.0.0 de Dusk