[Switch] - Concepts basiques du hack Switch

 

Introduction
Ce guide à pour but de présenter et d'expliquer de manière assez simple (mais complète) les différents concepts du hack Switch, en tout cas ceux que vous devriez connaitre avant de vous lancer dans l'aventure du hack de cette console. Ce guide vous permettra d'assimiler des concepts importants et souvent mal maîtrisés ou mal compris comme le fonctionnement des Efuses.

Ce guide est repris du guide posté sur ce sujet sur Logic-sunrise.

OFW / CFW c'est quoi ?
Signification des acronymes :
OFW = Official firmware (firmware officiel)
CFW = Custom firmware (firmware personnalisé)


On comprend donc qu'un CFW est un firmware fait maison et qui permet de faire des choses que le firmware officiel ne fait pas.
L'OFW est lancé lorsque vous allumez votre console de manière classique (power).
Le CFW est lancé lorsque vous appliquer un exploit permettant d'injecter un bootloader (hekate, Fusée, SX Loader).

OK, mais c'est quoi un firmware ?

Un firmware est un programme informatique qui est embarqué dans un appareil électronique (la Switch dans notre cas) et qui permet de faire fonctionner l’ensemble des éléments matériels de cet appareil.

Une fois n’est pas coutume, il est peut-être plus facile de comprendre en utilisant des anglicismes : “un firmware est un software embarqué dans du hardware”. C’est d’ailleurs pour cette raison qu’il porte ce nom, l’adjectif firm (ferme en français) décrivant bien la consistance à mi-chemin entre le soft (mou) et le hard (dur).

Le firmware permet non seulement de faire fonctionner le matériel (on pourrait voir ça comme un ensemble de drivers pré-installés) mais il permet également de faire évoluer le matériel, justement via les fameuses mises à jour firmware. Par exemple le support du format SDXC (pour les cartes SD) a été ajouté bien après la sortie de la console (03/2017), justement via une mise à jour firmware.

Il est important de comprendre que le firmware au sens strict est distinct du système d’exploitation. Beaucoup de personnes ont tendance à confondre firmware et système d’exploitation, ce pour deux raisons :
- La première est que l’utilisateur n'interagit pas directement avec le firmware. A l’inverse, l’utilisateur peut facilement se représenter ce qu’est un système d’exploitation puisqu’il interagit avec et que bien souvent l’OS dispose d’une interface graphique (comme Windows ou Android).
- La seconde raison tient du fait qu’un firmware tel que celui embarqué dans la Switch, n’existe pas de la même manière dans un PC classique, du moins il ne propose pas autant de fonctionnalités. Si on voulait faire l’analogie avec un PC, on pourrait dire que son firmware est le BIOS. Mais le BIOS n’est en vérité que le firmware de la carte mère. Dès lors, c’est le système d’exploitation qui va gérer tous les accès aux autres matériels, notamment grâce aux fameux “drivers” qu’on installe pour pouvoir communiquer avec les périphériques. On voit donc ici que la frontière entre OS et firmware est assez floue et dépend du système dont nous parlons. Beaucoup de fonctionnalités que propose le firmware de la Nintendo Switch le seraient au travers du système d’exploitation sur un PC.

Le CFW, dans la pratique

Vous devez maintenant avoir une bonne idée de ce qu’est un custom firmware (CFW). C’est donc un firmware alternatif, développé sur la base du firmware officiel mais proposant des modules personnalisés. Il s’agit généralement de faire sauter les restrictions et vérifications (qui empêchent de lancer ou d’installer du contenu non officiel). Il peut également permettre de virtualiser une NAND (emuNAND). 

Au risque de me répéter, je voudrais une nouvelle fois préciser que le firmware est différent du système d’exploitation. En l’absence d’emuNAND, la console utilisera le même système d’exploitation, qu’elle soit démarrée en OFW ou en CFW. En revanche, en présence d’emuNAND, nous avons deux systèmes d’exploitations différents, chacun installé sur sa NAND respective. Cependant, on utilisera souvent (moi le premier) les termes OFW et CFW dans leur définition plus large en incluant l'OS (avec le kernel), mais aussi parfois le bootloader. C'est le cas notamment quand on parle de "mise a jour firmware"

A ne surtout pas confondre...
avec la sysNAND et l'emuNAND que nous allons voir tout de suite. Ce sont deux concepts complètement différents. Le firmware désigne une ensemble de programmes informatiques tandis que la (sys/emu)NAND désigne une mémoire morte.

Comprendre l'emuNAND et les risques liés à l’absence d’emuNAND
Si vous avez déjà hacké une 3DS ou une PSP, vous devez être familiarisé avec le concept d’emuNAND et de sysNAND. Nous allons tout de même reprendre les choses depuis le début pour ceux qui ne connaissent pas ces concepts.

La NAND c’est quoi ?

Le terme « NAND » est devenue un mot valise pour parler de mémoire flash (celle de vos carte SD, clés USB ou disques durs SSD). Il s’agit de mémoire à base de semi-conducteurs, non volatile (c’est-à-dire que les données sont conservées même sans alimentation électrique, à la différence de la RAM qui est volatile) et réinscriptible. Pour la petite histoire lorsque est apparue la mémoire flash à la fin des années 80, il en existait deux types : la NOR et la NAND. Du fait des coûts élevés de fabrication de la NOR, seule la mémoire NAND a subsisté. Aujourd’hui, quasiment toutes les mémoires de masses externes utilisent la NAND.

Voilà pour le rappel historique. Appliquée à la Switch, la NAND désigne donc la mémoire interne embarquée dans la console, celle qui contient le système d’exploitation, les jeux installés et les sauvegardes.

Si vous avez bien suivi mes explications, vous aurez compris qu’une carte SD est également une mémoire NAND. Nous allons voir que ce détail a son importance. Sachez toutefois que dans le monde du hack, on réserve souvent le terme NAND à la mémoire sur laquelle est installée le système. Pour distinguer la mémoire interne de celle de la mémoire externe (SD) on parlera d’eMMC (Embedded MultiMedia Card ou carte mémoire intégrée) par opposition à la MMC (carte mémoire).

Le concept d’emuNAND

Le concept d’emuNAND a été inventé afin de limiter les risques inhérents au hack lorsque vous utilisez un CFW. Le principe est simple : il s’agit de virtualiser (ou émuler) une NAND qui sera dédiée au custom firmware (CFW).

Concrètement, lorsque vous allumez votre Switch, que ce soit en bootant sur l’OFW (firmware officiel) ou le CFW, le firmware indique au système d’exploitation où se trouve la mémoire physique qui lui est dédiée, en l’occurrence dans la mémoire flash embarquée (eMMC). C’est-à-dire que quand le système d’exploitation veut écrire sur la mémoire de votre Switch (pour installer un jeu par exemple), le firmware redirige toute les données vers la mémoire eMMC (la mémoire embarquée).

Voilà pour le fonctionnement normal. Maintenant imaginez que le CFW, plutôt que de diriger les données vers la mémoire eMMC (embarquée), choisisse de la rediriger vers la mémoire MMC (la SD), ça serait plutôt pratique vous ne trouvez pas ?
En bien c’est ça l’emuNAND. Vous vous retrouvez donc avec deux NAND ! La première, la sysNAND est la mémoire disponible lorsque vous lancez la console en OFW, la seconde, l’emuNAND est réservée pour l’utilisation d’un CFW :



Attention, je ne l'ai pas indiqué dans ce schéma mais le CFW peut très bien communiquer avec la sysNAND. On peut choisir de booter le CFW soit en sysNAND, soit en emuNAND.

En présence d’emuNAND, lorsque vous installez un jeu via le CFW, il n’est installé que sur votre carte SD. Vous n’y aurez jamais accès via l’OFW (et vice-versa). Autre exemple, vous pouvez très bien paramétrer une connexion WiFi sur votre sysNAND mais activer le mode avion sur votre emuNAND. Ainsi vous isolez le système d’exploitation d’internet quand vous utilisez le CFW (pour éviter le ban) alors que vous pouvez continuer à mettre à jour vos jeux officiels et jouer en ligne via l’OFW.

En l’absence d’emuNAND, la même NAND est partagée par l’OFW et le CFW si bien qu’un jeu (non officiel) installé sur votre CFW apparaîtra aussi dans le menu Home de votre OFW. Sans emuNAND, absolument tout est partagé : les paramètres, les titres installés, les sauvegardes, etc.

Vous comprenez donc que l’absence d’emuNAND ne permet pas de cloisonner l’utilisation « légale » de la console de son utilisation « illégale ». En somme, si vous souhaitez profitez des services en lignes pour vos jeux officiels et à la fois lancer des backup de jeu, mieux vaut avoir deux consoles (et un bon porte-monnaie).
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.

Les eFuses et le mode autoRCM
Dans cette partie, je vais vous expliquer ce que sont les eFuses, à quoi il servent et les avantages et inconvénients du mode autoRCM. Si vous voyez quelque chose à ajouter n'hésitez pas à m'en faire part dans les commentaires et je mettrai à jour ce guide.

eFuse c'est quoi ?
Ce sont des nano fusibles intégrés dans la puce Tegra (NVIDIA) qui équipe la Nintendo Switch. Ces fusibles grillent (ou brûlent) après une mise à jour firmware. Il s'agit d'un dispositif anti downgrade.
La Nintendo Switch dispose de 32 eFuses (ils sont vraiment microscopiques) :

Lorsque vous démarrez votre console normalement, le bootloader (tout premier programme exécuté) vérifie que vous avez bien le bon nombre de fuses grillés en fonction de votre version de firmware :

Par exemple :
- Si vous tentez de démarrer votre console en FW 6.0 et que votre nombre de fuses grillés est à 6 (ou moins) alors ça va vous en griller un de plus (ou plusieurs, jusqu'à arriver à 7)
- Si vous tentez de démarrer votre console en FW 5.1 et que votre nombre de fuses grillés est à 7 alors ça affichera un écran noir (bootloader panic) et vous serez bloqués.

Vous comprenez donc que ce dispositif est là pour empêcher de downgrader le firmware d'une console.
Si vous avez installé une emuNAND, notez bien que le contrôle des fuses ne se fait que sur la version de firmware installée sur votre sysNAND.

Connaître son nombre d'eFuses
Hekate propose une fonction permettant de connaitre son nombre d'eFuses grillés. Injectez simplement Hekate puis dans "Console info" sélectionnez "Print fuse info" :

Pourquoi vouloir préserver ses eFuses ?
La seule bonne raison de préserver ses eFuses est de vouloir downgrader sa console, c'est-à-dire installer une version de firmware plus ancienne que celle installée sur votre console. Ok, mais quel est l'intérêt de downgrader sa console ?

La raison la plus évidente est de pouvoir un jour profiter d'un exploit qui ne fonctionnerait que sur certaines versions de firmware. Il existe un exploit chain nommé "déjà vu" qui permet de démarrer un CFW sans passer par l'exploit RCM et donc sans avoir besoin d'un Jig ou dongle. Cet exploit chain est pour le moment réservé aux firmware <= 4.1 (sous le nom de cafeine/nereba, voir ce tuto si votre firmware est compatible. Si vous n'avez pas préservé vos eFuses, vous ne pourrez pas profiter de cet exploit.

Si au contraire vous n'avez que faire de pouvoir profiter d'un nouvel exploit plus simple à utiliser, alors vous n'avez pas vraiment d'intérêt à préserver vos eFuses.

Notez bien que même si vous ne préservez pas vos fuses, il sera tout de même possible de downgrader votre firmware mais vous ne pourrez le lancer que par un custom bootloader, et donc appliquer l'exploit RCM à chaque démarrage. Ce qui évidemment ne présente plus aucun intérêt pour un futur exploit.

Attention : il n'est pas possible de préserver les eFuses d'une switch patchée. La suite de ce thread s'adresse à ceux qui disposent d'une Switch non patchée (usinée avant Juillet 2018).

Comment contourner le contrôle/grillage des eFuses ?
Etant donné que c'est le bootloader qui contrôle et grille les eFuses au démarrage, la seule manière de contourner ce contrôle est d'utiliser un custom bootloader tels que Hekate, Fusee ou SX Loader (pour ne citer qu'eux). En effet, ces bootloaders sont injectés dans la console via l'exploit RCM (fusée gelée), avant que le bootloader officiel ne soit exécuté. Ils viennent donc remplacer le bootloader officiel.

En théorie, il suffit donc de toujours démarrer/redémarrer sa Switch en mode RCM pour ne pas griller ses fuses. Seulement en pratique il n'est pas évident de ne jamais booter sur le bootloader officiel. Lorsque votre console vous demande de redémarrer (après une mise à jour) il faudrait systématiquement refuser et faire un hard shutdown (appui long de 15 sec sur le bouton POWER) puis démarrer la console en mode RCM. De plus, sur une console à l'arrêt, il suffit simplement d'appuyer par inadvertance sur le bouton POWER pour lancer le bootloader officiel.

C'est pourquoi les développeurs ont inventé le mode autoRCM.

autoRCM, c'est quoi ?
Cela consiste à bricker intentionnellement sa console afin qu'elle ne puisse plus démarrer sur le bootloader officiel. Plus précisément le bootloader va entrer en mode panic puis passer automatiquement en mode recovery "RCM", sans avoir besoin d'un jig ou d'un court-circuit dans le joycon. Cela peut paraître surprenant de bricker intentionnellement sa console mais c'est la seule façon efficace de se prémunir d'un grillage de fuses. Mais soyez rassurés, la méthode consiste simplement à altérer quelques bits inutiles dans la partition BOOT0 de votre NAND. Cette méthode est totalement réversible et laisse votre NAND propre une fois le mode autoRCM désactivé.

Ce mode autoRCM peut être activé via les custom bootloader comme Hekate ou SX Loader ou bien via le payload briccmii.
L'homebrew ChoiDuJourNX, qui permet d'installer manuellement un firmware, active également ce mode par défaut. Notez bien que lorsque ChoiDuJourNX est lancé depuis l'emuNAND, l'autoRCM ne s'activera pas (même si l'application peut le laisser penser).

Attention : ne jamais activer le mode autoRCM sur une Switch patchée (non vulnérable à l'exploit RCM, aka Fusée Gelée), sans quoi vous allez bricker votre Switch sans jamais pouvoir la debricker simplement.

Les avantages :
Empêche de démarrer le bootloader officiel et donc empêche de griller ses eFuses
Permet de se passer du Jig/court-circuit et de la combinaison de touche (POWER + VOL UP) pour démarrer en mode RCM.
Dans une moindre mesure, empêche de démarrer facilement sur le firmware officiel qui fait beaucoup plus de télémétrie qu'un CFW (donc plus de risque de ban)


Les inconvénients :
L'inconvénient majeur de ce mode est le risque de se retrouver avec une batterie déchargée. En effet il n'est pas simple de distinguer une Switch éteinte d'une switch en mode RCM (écran noir, pas de réaction aux commandes digitales). Si vous ne faites pas attention, votre console va rester en mode RCM et se décharger petit à petit jusqu'à être complétement déchargée. Le hic, c'est qu'une console brickée avec 0% de batterie ne peut plus se recharger normalement, c'est très long, il faudrait pouvoir l'allumer correctement en bootant sur le firmware pour qu'elle puisse être rechargée mais l'autoRCM nous en empêche !
La fonction "éteindre" de l'OS de la Switch ne fonctionnera pas correctement et fera basculer votre Switch sur le mode RCM (donc on revient au problème de batterie). Le seul moyen fiable pour l'éteindre complètement est de rester appuyé 15 secondes sur le bouton POWER.
Pour une Switch éteinte, un simple appui sur le bouton POWER ou le simple fait de la connecter via USB à un PC ou dongle va démarrer la console en mode RCM, ce qui là encore, va décharger votre batterie.


Pour éviter les problèmes de batterie, je vous conseille de ne pas tenter d'éteindre totalement votre console (sauf si vous allez la rallumer tout de suite après) mais la laisser en veille, elle se déchargera moins vite.

Les idées reçues sur les fuses et le downgrade

Les concepts de fuse et d'autoRCM n'étant pas forcément tout le temps bien compris, on trouve désormais régulièrement des tutos qui comportent soit des idées reçues soit carrément de fausses informations.
Quelques vérités à rétablir :
Il est faux de dire que booter sur l'OFW (firmware officiel) va brûler des fuses. Comme indiqué précédemment, c'est le bootloader officiel, celui contenu dans la partition BOOT0 de la NAND (nommé package1) qui contrôle et brûle les fuses. C'est un programme qui gère le boot de la console mais ce n'est pas ce qu'on appelle communément l'OFW, ou le stock firmware qui est un terme dédié à la version du kernel et de l'OS (Horizon) non modifié. Même si peut concevoir le terme "firmware" comme très générique, puisque ce qu'on appelle communément une "mise à jour firmware" peut aussi bien désigner une modification du code du système d'exploitation, du kernel, des sysmodules, ou même du bootloader, il serait trop restrictif de cantonner l'OFW au seul bootloader (qui par ailleurs à aussi sa propre version de programme). Quoi qu'il en soit, les custom bootloaders comme Hekate ou SX Loader peuvent tout à fait lancer l'OFW tout en préservant les fuses. Il est donc faux de dire que booter l'OFW brûlent les fuses, c'est un raccourci pour dire que booter via le bootloader officiel (donc de manière classique, en appuyant sur POWER) brûle les fuses.
Il est faux de dire que lorsqu'on à brûlé ses fuses, on ne peux plus downgrader sa console. Là encore il suffit de passer par un custom bootloader comme Hekate pour booter sur une NAND "downgradée". Il serait plus exact de dire qu'en brûlant ses fuses puis en ayant downgradé sa console, elle ne bootera plus via le bootloader officiel (c'est vrai que c'est plus long et moins intuitif ^^).
Il est faux de dire qu'en mettant à jour son firmware via ChoiDuJourNX on préserve ses fuses. Seul l'autoRCM permet de préserver ses fuses. ChoiDuJourNX active l'autoRCM par défaut, mais cela reste une option. Et si l'utilisateur désactive l'autoRCM par la suite, bye bye les fuses au prochain coldboot via le bootloader officiel...


Que faire si ma console ne démarre plus suite à un downgrade de firmware ?
Si vous n'avez pas activé le mode autoRCM alors que vous avez downgradé votre firmware (via l'installation d'un firmware inférieur ou la restauration d'un dump de NAND avec un firmware inférieur), et que vos fuses sont en mismatch alors vous ne verrez qu'un écran noir lorsque vous allumerez la console normalement.

Dans ce cas il faudra passer par un custom bootloader tel Hekate ou SX Loader pour démarrer votre OFW (firmware officiel), et ce jusqu'à temps que votre version de firmware et votre nombre de fuse ne soit plus en mismatch.

Que faire si ma batterie est déchargée à cause de l'autoRCM ?
Il est possible qu'il reste un tout petit peu de jus dans votre batterie pour injecter un payload mais pas assez pour lancer le CFW. Il existe une technique très simple et éprouvée qui fonctionne dans ce cas : il faut injecter votre bootloader préféré et dès qu'il est injecté, connecter le chargeur secteur à la Switch, ce qui lui donnera assez de jus pour lancer le CFW. Dès qu'Horizon OS est chargé, votre batterie commencera à se recharger.

Si votre batterie est vraiment à plat, essayez de la brancher sur secteur le temps qu'elle se charge (min 45min/1heure) pour avoir assez de jus pour injecter un payload. Si ça ne fonctionne pas, Il faudra démonter votre batterie, la remonter dans une autre console, cette fois-ci non brickée (sans l'autoRCM d'activé) et la recharger avant de la replacer dans sa console d'origine.

eFuses LOTUS

Les eFuses LOTUS sont des fuses de la puce du port cartouche, qui est une puce différente du SoC Tegra, et est en charge des communications avec le port cartouche de la console.
Ces eFuses fonctionnent peu ou prou de la même manière que les eFuses du SoC. Ils sont brûlés à chaque mise à jour du firmware LOTUS (le firmware du port cartouche donc). Lorsque la version du fw et le nombre de fuses LOTUS ne correspondent pas, le port cartouche est alors rendu inopérant.
La grosse différence avec les eFuses du SoC, c'est qu'il est impossible de contourner le contrôle des fuses LOTUS. Il n'existe pas d'exploit bootrom pour cette puce comme c'est le cas pour le Tegra X1. Aussi, il faut bien comprendre que lorsque votre firmware LOTUS est mis à jour (en même temps que la maj du fw principal, comme ça a été le cas pour les fw 4.1 et 9.0 et d'autres par la suite), votre port cartouche ne fonctionnera plus si vous downgradez le firmware principal de votre console.
Pour empêcher votre port cartouche d'être mis à jour en CFW, il est possible d'appliquer un patch "nogc" (qui se configure dans BCT.ini par exemple pour le bootloader d'Atmosphère, disponible aussi pour Hekate) qui bloque le port cartouche (et donc sa mise à jour) lors de l'utilisation d'un CFW.
Attention cependant il n'existe pas de patch "nogc" qui fonctionne sur SX OS, ce dernier ayant sans doute besoin que le firmware du port cartouche soit à jour afin que le loader XCI de la TX fonctionne avec tous les jeux.
Soyez donc très vigilant également au fuses LOTUS si vous souhaitez un jour profiter de votre port cartouche sur un FW plus bas que votre celui sysNAND ou emuNAND actuel.

Que contient la NAND ?
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 de 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 une 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".

Aller plus loin : SoC Tegra X1 NVIDIA, boot et exploit RCM
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 signé.
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 :
- Via une combinaison de touche (POWER et VOL+) associée à un court-circuit au niveau joycon (méthode du Jig)
- Via une valeur (bit 2) positionnée dans un registre du PMC (power management control). Il faut déjà un programme qui tourne sur le BPMP pour appliquer cette méthode (c'est ce que fait hekate pour rebooter en mode RCM).
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égira. 
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.
C'est 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 bootloader, du firmware, du kernel et plus largement de l'OS.