uniques65

L'emuNAND sur la Switch

Les deux CFW principaux sur Switch, Atmosphère et SX OS, disposent tous les deux d'une emuNAND. Le principe de fonctionnement est le même quelque soit le CFW.

Vous verrez souvent le terme d'emuMMC plutôt qu'emuNAND sur la scène Switch, pour la simple raison que sur cette console, c'est l'ensemble de l'eMMC qui est virtualisée (émulée) et non pas simplement la mémoire system. C'est purement et simplement tous les secteurs de l'eMMC qui sont virtualisés, c'est-à-dire les partitions BOOT0 et BOOT1, la GPT et les partitions utilisateurs (PRODINFO, SYSTEM, USER, etc). Quoi qu'il en soit le concept est exactement le même, tout comme la finalité donc personne ne vous en voudra de simplifier l'équation en "emuMMC = emuNAND"

Il est possible de créer deux types d'emuNAND : en "fichier" ou en "partition".

Une emuNAND "fichier", est stockée sous forme de fichiers (les 32Go de la NAND sont découpés en X fichiers dont la taille n'excède pas les 4096 Mo) qui sont écrits sur la partition principale de votre carte SD (par exemple dans le répertoire /sxos/emunand pour SX OS). La partition sur laquelle sont écrits ces fichiers a son propre filesystem (c'est-à-dire qu'elle peut être formatée en FAT32 ou en exFAT par exemple).

Une emuNAND "partition" est stockée sur une partition de votre carte SD qui n'a pas de filesystem (non formaté), c'est simplement de la mémoire contiguë sur le disque, qui peut-être définie par une position de départ (le premier secteur du disque où commence l'emuNAND) et le secteur de fin (le dernier secteur occupé par l'emuNAND), la taille totale étant représentée par "taille = position de fin - position de départ").

Quel type d'emuNAND choisir me direz-vous ?

La meilleure emuNAND, du point de vue de la performance est sans conteste l'emuNAND "partition".

La raison est assez évidente quand on connait un peu comment fonctionne un filesystem. Quand on écrit un fichier sur un filesystem (FAT32 par ex), on écrit physiquement de la mémoire sur le disque, mais de manière fragmentée, ce qui peut dans le temps, augmenter la lenteur d'accès (lecture ou écriture) à la mémoire. Sachant qu'une emuNAND fichier est stockée sur une partition qui a son déjà son propre filesystem et que l'emuNAND à aussi son (ou plutôt ses) propre filesystem, le fait d'empiler les filesystem va réduire l'accès aux données et ralentir le système. La fragmentation augmentant la vitesse d'accès avec le temps, le fait d'avoir une double fragmentation peut encore plus allonger les temps d'accès.

L'emuNAND fichier est en revanche plus facile à manipuler (à copier ou supprimer) puisqu'elle est matérialisée sous forme de fichier.

Donc la réponse à la question dépend en fait de votre utilisation de l'emuNAND. Si vous utilisez par exemple SX OS uniquement pour lancer des XCI (les jeux ne sont donc pas stockés dans l'emuNAND), une emuNAND fichier pourrait être satisfaisante la majorité du temps. Personnellement, je vous recommande l'emuNAND en partition car elle présente plus d'avantages que d'inconvénients de mon point de vue.

Intéressons-nous à ce que contient la NAND de la Nintendo Switch, ou plutôt l'eMMC (la mémoire embarquée). Il n'est pas forcément utile de tout connaitre du contenu de la NAND, cependant si vous êtes amenés à modifier sa structure ou son contenu, les informations suivantes pourront vous être utiles (par ex à la restauration d'un dump, un redimensionnement d'emuNAND, une restauration de save, l'usage d'incognito, etc...).

L'eMMC est une mémoire flash d'environ 29GB qui est structurée de la manière suivante :

Partitions de boot :

• ​BOOT0 (4 Mo)

Première partition de boot, son nom officiel est "BootPartition1Root".

Elle contient :

- La BCT (Boot Configuration Table) : pour simplifier, dans cette mémoire est stockée l'adresse et la configuration du bootloader qui sera exécuté au démarrage de la console.

- Le bootloader (appelé package1). C'est le premier programme exécuté par la console qui va initialiser le matériel et lancer le kernel.

Cette partition est modifiée lors d'une "mise à jour firmware" qui vient modifier le bootloader (pas systématique). Ainsi, il est important d'également faire un dump cette partition (+ BOOT1) lorsque vous effectuez une sauvegarde de votre NAND. Restaurer votre NAND sans les bonnes partitions de boot pourrait empêcher votre console de démarrer, attention donc.

• BOOT0 (4 Mo)

Seconde partition de boot (safe mode).

Partitions utilisateur :

Les partitions utilisateurs sont décrites dans une table de partition (GPT). La première partition débute à l'offset 0x4400.

• PRODINFO (4 Mo)

Egalement appelée CAL0, cette mémoire est écrite lors de l'étape de calibration de la console, en usine.

La partition est entièrement chiffrée (AES-XTS, similaire à BitLocker). Le chiffrement/déchiffrement se fait à l'aide la Bis key n°0.

Elle contient tout ce qui rend la console unique, et donc ce qui permet de l'identifier, de l'authentifier :

- Numéro de série

- Device Id (identifiant unique de la console)

- Adresse MAC

- Tout un tas de certificats et de clés...

Cette partition est souvent altérée dans un souci d'anonymisation. Des outils comme incognito (un peu désuet) viennent effacer tous les identifiants qui "théoriquement" permettraient aux serveurs de big N de vous identifier. Si votre souci est donc d'éviter le ban, sachez qu'Atmosphere propose désormais un option pour démarrer le CFW avec une partition PRODINFO complètement vidée (des zéros partout mais pour de faux  ) donc vous ne devriez pas toucher à cette partition vous même, c'est dangereux et inutile.

Cette partition n'est jamais modifiée par une "mise à jour firmware".

• PRODINFOF (4 Mo)

La partition est entièrement chiffrée (Bis key n°0).

Système de fichier FAT12.

D'autres données de calibration, inutiles au commun des mortels.

Cette partition n'est jamais modifiée par une "mise à jour firmware".

• BCPKG2-1-Normal-Main (8 Mo)

​Cette partition contient le package2, c'est-à-dire le kernel et les sys-modules (et oui tout ça tient dans 8Mo, les codeurs millénials qui n'ont bouffé que du java à l'IUT seraient en PLS devant un tel défi  )

Elle contient également des paramètres de boot supplémentaire (BootConfig pour la TrustZone et l'OS).

Cette partition est généralement modifiée lors d'une "mise à jour firmware".

• BCPKG2-2-Normal-Sub (8 Mo)
• BCPKG2-3-SafeMode-Main (8 Mo)
• BCPKG2-4-SafeMode-Sub (8 Mo)
• BCPKG2-5-Repair-Main (8 Mo)​
• BCPKG2-6-Repair-Sub (8 Mo)

Ces partitions sont toutes plus ou moins des copies de BCPKG2-1-Normal-Main.

Ces partitions sont généralement modifiées lors d'une "mise à jour firmware".

• SAFE (64 Mo)

La partition est entièrement chiffrée (Bis key n°1).

Système de fichier FAT32.

Le nom officiel est "SafeMode", pas plus d'info.

• SYSTEM (2.5 Go)

La partition est entièrement chiffrée (Bis key n°2).

Système de fichier FAT32.

On retrouve ici les programmes systèmes (comme le navigateur, l'eshop, etc) et leurs données de sauvegarde.

Cette partition est toujours modifiée lors d'une "mise à jour firmware".

• USER (26 Go)

La partition est entièrement chiffrée (Bis key n°3).

Système de fichier FAT32.

On retrouve ici les programmes utilisateurs, essentiellement les jeux installés, et leurs données de sauvegarde.

Cette partition peut-être redimensionnée dans le cas d'une emuNAND.

Cette partition n'est jamais modifiée lors d'une "mise à jour firmware".

Dans cette partie nous allons nous intéresser au SoC Tegra X1 fabriqué par NVIDIA, la manière dont le processus de boot fonctionne et comment exploiter le mode RCM pour exécuter du code non signe.

On va rentrer un peu plus dans le hardware et la technique mais je vais tâcher de faire au plus simple.

Vous le savez donc, le SoC de la Nintendo Switch est fabriqué par NVIDIA. Il comprend entre autres éléments :

- Un CPU principal (CCPLEX) ARM 8 coeurs et 8 threads, cadencé à 1.9 Ghz max

- Un CPU dédié au processus de boot et gestion de l'alimentation, appelé BPMP (Boot and Power Management Processor) ou encore COP (Co-Processor).

- Un CPU dédié à la sécurité, appelé TSEC (Tegra Security Co-Processor)

- Un GPU de type Maxwell

- Une petite RAM embarquée dans le SoC appelé IRAM

- Une boot ROM, une mémoire non réinscriptible dédiée au boot. Elle contient du code informatique (software) qui sera exécuté au moment du boot (BPMP-FW). Cette mémoire est sur le SoC et n'est pas accessible de l'extérieur.

- Des contrôleurs périphérique divers, comme eMMC et NAND qui donne par exemple accès à la mémoire de boot qui contient la BCT et le bootloader (BOOT0)

- D'autres contrôleurs (ex USB), Fuses, etc.

Notons aussi que le CPU principal est un processeur ARM de dernière génération, ce qui veut dire qu'il dispose d'une fonctionnalité qu'ARM appelle "TrustZone" qui permet de créer, au sein même du cpu (hardware) une zone dite "de confiance". C'est assez complexe mais imaginez vous que c'est un gardien d'immeuble qui serait le seul à avoir toutes les clés des appartements de l'immeuble. Dés qu'on veut rentrer dans un appartement, il faut passer par ce gardien (c'est vraiment très schématique). Bref, c'est une technologie de cryptographie essentiellement. Pour ceux qui connaissent les modes d'exécution kernel land et user land, sachez qu'il s'agit d'un niveau encore plus élevé, au dessus du kernel (le kernel fais des syscalls vers la TZ).

Détaillons maintenant ce qu'il se passe lorsque vous bootez votre Nintendo Switch. 

Lorsque la console démarre, le BPMP (boot CPU) va exécuter le code présent dans la boot ROM. A ce moment le CCPLEX (main CPU) n'est pas alimenté et n'exécute aucun code. 

La boot ROM détermine d'abord quelle contrôleur permet l'accès à la mémoire de boot. Dans notre cas (Switch) il s'agit de l'eMMC qui contient la NAND et plus particulièrement la partition BOOT0.

Une fois que le contrôleur est correctement initialisé, la boot ROM commence à lire la mémoire de boot (BOOT0). Les premiers blocs de mémoire lus correspondent à la BCT (Boot Configuration Table). Il s'agit d'une structure contenant plusieurs entrées qui décrivent et indiquent :

- comment optimiser l'accès à la mémoire de boot (pour chargement optimal du bootloader)

- comment configurer la SDRAM (optionnel)

- l'adresse où est située le bootloader sur la mémoire de boot

- l'emplacement de la SDRAM (ou IRAM) dans lequel sera chargé le bootloader

- le point d'entrée du bootloader

La boot ROM va traiter la BCT de cette manière :

- Si aucune entrée valide n'est trouvée dans la BCT, démarrage du mode restauration USB (RCM pour ReCovery Mode)

- Reprogrammation du contrôleur de la mémoire de boot en suivant la configuration contenue dans la BCT

- Si la BCT contient une configuration de la SDRAM, reprogrammation du contrôleur SDRAM.

- Lecture du bootloader (nommé package1 sur la Switch) à l'adresse indiqué dans la BCT, chargement en RAM et validation (crypto)

- Si aucun bootloader n'est trouvé, démarrage du mode restauration USB (RCM)

- Saut (jump) vers le point d'entrée du bootloader (instruction processeur pour exécution du bootloader)

Notez bien que la boot ROM ne fait qu'un saut vers le point d'entrée (en RAM) du bootloader. A ce moment, le code s'exécute toujours sur le BPMP (boot CPU). La boot ROM ne boote pas le CCPLEX (main CPU).

Le minimum du hardware est initialisé par la boot ROM, essentiellement le hardware qui gère l'alimentation et la mémoire. D'autre initialisations du hardware devront être faites plus tard par le bootloader afin de lancer le CCPLEX. In fine, l'OS tournera lui sur le CCPLEX.

Si tout s'est bien passé le bootloader est désormais chargé et exécuté, mais arrêtons nous maintenant sur le mode restauration USB (RCM) puisque c'est dans ce programme qu'il existe une faille permettant d'appliquer l'exploit RCM (fusée gelée).

Pour prendre le contrôle de la console en appliquant l'exploit, nous devons donc trouver un moyen de lancer ce mode restauration.

On peut voir dans le processus de boot que je viens de décrire, une première méthode pour lancer le RCM. Il faut donc que le BCT ou l'emplacement du bootloader soit vide ou corrompu afin de lancer le mode RCM.

Si vous ouvrez votre Nintendo Switch et que vous retirez l'eMMC (donc la NAND) vous serez dans cette configuration et votre console démarrera automatiquement en mode RCM. Il faut noter que ce qu'on appelle "l'autoRCM" (cf. partie "eFuses et autoRCM") exploite également ce fonctionnement en venant corrompre chacune des 4 entrées de la BCT afin de forcer le démarrage en RCM.

Cette méthode pour démarrer en RCM est assez simple en théorie mais pas vraiment en pratique pour un utilisateur lambda. Le but n'est pas de démonter son eMMC pour appliquer l'exploit et sans la démonter on ne peut pas non plus la corrompre (autoRCM) puisqu'on ne peut pas encore exécuter du code non signé.

L'étude du code de la boot ROM a permis de mettre en évidence deux méthodes supplémentaires (hardware) permettant de lancer le mode restauration :

La méthode du Jig (court-circuit) nous offre une technique beaucoup plus simple car elle ne nécessite pas d'ouvrir sa console et de démonter quoi que ce soit. C'est donc la méthode que l'utilisateur lambda privilégia. 

Notons que toutes ces méthodes ne sont pas des failles, ce sont bien des méthodes codées dans la boot ROM. Pour le moment on a appliqué aucun exploit, tout est "officiel".

Reprenons maintenant notre processus de boot et mettons nous dans la configuration ou la boot ROM va lancer le mode RCM (quelle que soit la méthode).

Nous sommes donc toujours en exécution sur le BPMP, aucune réduction de privilèges n'est encore mis en place, le programme à tous les droits en quelque sorte. La boot ROM va initialiser le contrôleur USB et charger un driver USB afin de pouvoir communiquer avec un périphérique extérieur via le port USB. Elle charge le programme correspondant au mode RCM, un software (du code) mettant à disposition des fonctions pour traiter les commandes USB.

Cette justement dans une de ces fonctions que ce trouve une faille qui va permettre d'injecter et exécuter du code non signé suite à un écrasement de la pile USB. Pour la faire courte, il existe un certain nombre de commandes USB (control requests) qui sont mal gérées par la bootrom, notamment la commande GET_STATUS. La vulnérabilité réside dans la mauvaise gestion de la taille du buffer transmis avec la commande, qui permettra in-fine d'effectuer un memcpy qui provoquera un dépassement de tampon (buffer overflow). Il est possible que vous n'ayez absolument rien compris à ce que je viens de vous dire, pas d'inquiétude il faut savoir développer pour comprendre ce qu'est un dépassement de tampon. Retenez simplement que la commande vulnérable est exploitée afin de charger et exécuter du code non signé (notre payload) et qu'il s'agit d'une erreur humaine faite par le développeur qui à codé cette partie de la boot ROM, une simple erreur de programmation.

C'est donc ici qu'intervient l'exploit fusée-gelée, on peut donc désormais exécuter un programme maison qui pourra faire absolument tout ce qu'on désire. Le programme n'a aucune restriction, il peut jouer avec tout le hardware maintenant.

Voilà comment on exploite la Nintendo Switch via le mode RCM. La plupart du temps on voudra injecter un custom bootloader comme hekate qui lui même pourra booter un CFW comme Atmosphère.

Il appartient désormais au payload de faire l'ensemble des initialisations hardware et software nécessaires pour continuer le boot et lancer in fine un OS (que ce soit HOS, Android ou Linux).

Sachez pour terminer, qu'une fois l'exploit appliqué, on est encore très loin d'avoir cassé toutes les sécurités de la console, on a simplement pris le contrôle au meilleur moment, avant le chargement du booloader, du firmware, du kernel et plus largement de l'OS.