Edit 12/12/2019 : modification du guide pour y ajouter une partie sur les concepts d'OFW/CFW et d'emuNAND.
Edit 21/01/2020 : ajout d'explication spécifiques à l'emuNAND Switch (quel type d'emuNAND choisir) et ajout d'explications sur le principe de fragmentation.
Edit 23/07/2020 : ajout de la partie "Aller plus loin" qui décrit plus en détail le SoC, le processus de boot et l'exploit RCM
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. Pour suivre assidûment ce forum depuis deux ans maintenant, et au vu des différentes questions ou mauvaises interprétations qu'on peut voir par ci, par là, je ne peux que conseiller à tout débutant d'assimiler ces concepts avant d'aller plus loin. Vous voilà prévenus ^^
- 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.
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.
*Si vous ne voyez pas ce qu'est le concept de filesystem ou de fragmentation et que ça vous intéresse de comprendre, je vais essayer de vous l'expliquer le plus clairement possible (mais il faut s'accrocher un petit peu) :
1) Le bloc :
Votre disque dur (ou carte SD) est en fait découpé en plusieurs blocs (ou secteurs) de taille bien définie (par exemple 1 bloc = 512 octets). Par exemple prenons un disque qui fait 1024 blocs de 512 octets, sa taille totale est donc de 512 Ko. Le bloc est l'unité physique la plus petite du disque, on ne peut pas écrire moins qu'un bloc lorsqu'on veut écrire sur le disque (c'est pareil pour la lecture). Même si je veux écrire uniquement 128 octets sur le disque, j'écrirais en fait 512 octets (dont pas mal de zéros inutiles). De la même manière si je veux écrire 600 octets sur le disque, j'écrirais en réalité 2 blocs (soit 1 Ko).
2) Le cluster :
Voilà pour la description physique d'un disque. Mais quand on manipule des fichiers (et des dossiers), il faut ajouter une couche logique pour décrire comment est organisée la mémoire sur le disque, un "filesystem". Pour la suite on va utiliser le filesystem bien connu FAT32 mais la plupart des FS fonctionnent de la même manière. Un filesystem décrit le disque en unité logique (qui n'existe pas physiquement) qu'on appelle un "cluster". Un cluster est défini par une taille exprimée en blocs, pour le FAT32 1 cluster = 32 blocs (soit 32 x 512 o = 16 Ko). C'est d'ailleurs bien parce qu'il y a 32 blocs par cluster que ce FS s'appelle FAT32 (il existe aussi FAT12 ou le FAT16).
Bon, reprenons notre disque de départ qui fait 1024 blocs (512 Ko). En unité logique FAT32, il fait donc 32 clusters (1024 / 32 blocs par clusters = 32 clusters). Notre disque peut donc être représenté comme une liste de clusters : cluster n°0, cluster n*1, cluster n°2, etc jusqu'au cluster n°31.
3) La table d'allocation et la fragmentation
Bien, après tout, le découpage en unité logique (cluster) ressemble au découpage physique du disque mais en ajoutant une deuxième couche. La particularité d'un FS réside en fait dans la façon qu'il a d'organiser les données sur le disque. Le plus simple pour comprendre est de prendre l'exemple d'un fichier qui fait 64 Ko. Il faut donc 4 clusters pour stocker le fichier (4 x 16 Ko = 64 Ko). Quand on veut écrire ce fichier dans un FS FAT on va pouvoir écrire ces 4 clusters n'importe où sur le disque, il ne suivront pas forcément. Par exemple notre fichier peut avoir comme adresses : cluster n°4, cluster n°21, cluster n°22 et cluster n°30. Voilà, c'est ça la fragmentation, votre fichier n'est pas une succession de clusters contiguës sur le disque mais sont écrits là où il reste de la place sur le disque, parfois sur des clusters qui ne se suivent pas. Par contre, si on trouve 4 clusters disponibles et qui se suivent, on va écrire le fichiers sur 4 clusters contiguës (cluster n°3, n°4, n°5 et n°6 par ex).
Cette explication suffit pour comprendre la fragmentation. Il faut juste aussi avoir en tête que le niveau de fragmentation augmente avec le temps, c'est une sorte d'entropie de la mémoire, une désorganisation qui augmente avec le temps (sauf si on "défragmente").
Cela dit, vous êtes peut-être curieux de savoir comment fait réellement le filesystem pour organiser la mémoire de manière fragmentée ? Bon, c'est pas forcément hyper abordable comme concept alors je vais essayer de vulgariser au mieux ^^.
Si je formate mon disque de 1024 blocs en FAT32 (donc 32 clusters, soit 512 Ko) je me rendrai compte que la taille disponible n'est pas vraiment de 512 Ko mais d'un peu moins (par exemple 480 Ko, soit 30 clusters). Pourquoi ? Tout simplement parce qu’il faut bien de la place pour décrire la manière dont les données sont organisées sur le disque (c'est ça en fait le filesystem). Pour cela on a besoin de décrire l’organisation dans une table qui dans notre exemple occupe les 2 clusters qui nous manque par rapport à la taille total du disque (32 clusters). Notre table occupe donc les deux premiers clusters du disque et les "vraies" données occupent les 30 clusters suivants. Le FAT32 désigne en fait une "table d'allocation des fichiers" dont l'unité logique (le cluster) occupe 32 blocs (File Allocation Table = FAT, 32 pour 32 blocs par clusters). Une table d'allocation de fichier c'est en fait un tableau à une dimension (une liste, un vecteur de données), dont chaque case décrit un vrai cluster de données. Dans notre exemple notre table d'allocation fait donc 30 cases. Chaque case porte en elle plusieurs informations :
- une adresse (c'est la position de la case dans le tableau) : elle permet de déduire l'adresse physique réelle du cluster qui est décrit par cette case (une adresse à l'extérieur de la FAT donc).
- une valeur : qui peut correspondre (entre autre) à l'adresse physique du prochain cluster qui constitue la chaîne de cluster d'un fichier courant.
Nous l'avons vu, un fichier est décrit par une chaîne (liste) de clusters et pas seulement par un nombre de clusters, puisqu'ils ne se suivent pas forcément. Quand on veut lire un fichier il faut connaitre sa chaîne de cluster. Pour la connaitre, il faut passer par cette FAT qui contient justement toutes les chaines des fichiers qui sont décrits par le filesystem. La taille d'une case de notre tableau d'allocation est très petite (4 octets pour le FAT32, plus petite qu'un bloc donc) et peut avoir une valeur différente de l'adresse du prochain cluster. On peut avoir une valeur qui signifie "c'est la fin d'un fichier" ou bien "ceci est un cluster disponible". Bref, on tout ce qu'il faut pour décrire comment est organisée la mémoire, combien de clusters sont occupés, combien sont disponibles et quelle est l'adresse réelle de chaque cluster (l'adresse de la vraie donnée du fichier).
Voici une représentation d'une table d'allocation :
Il y'aurait pas mal d'autres choses à vous expliquer pour décrire toute cette table. Pour le rapprocher de mon exemple précédent, il faut juste comprendre qu'une case de ma table est représentée par 4 cases dans celui-ci (une case = 1 octet). On peut voir que la chaîne bleue représente un fichier non fragmenté (sa taille est de 6 clusters) alors que la chaîne jaune correspond à un fichiers fragmenté (sa taille est de 7 clusters). Les cases en blanc (groupés par 4 puisque qu'une case fait 4 octets) correspondent à des clusters disponibles.
Pour simplifier un peu tout ça, quand vous allez lire ou écrire un fichier, vous allez en fait parcourir une table d'allocation pour obtenir ou écrire une chaîne de cluster qui vous permettra ensuite d'aller réellement lire/écrire les données du fichiers aux adresses qui sont données par cette chaîne de cluster.
Mais pourquoi s'embêter à organiser la mémoire de cette façon ? Pour deux raisons :
- la première raison (qui explique la table d'allocation) c'est que lorsque vous souhaitez écrire un nouveau fichier sur votre disque, vous n'avez pas envie de parcourir tous les clusters de votre disque (qui peut s'exprimer en To) pour savoir quel cluster est disponible (pas déjà occupé par un autre fichier). Ce serait beaucoup trop long!. De la même manière, quand vous voulez supprimer un fichier, vous ne voulez pas supprimer physiquement la donnée. Ce serait un non sens puisque la mémoire physique (les blocs) sur votre disque ne disparaît pas, au mieux elle peut être remplacée par plein de zéros pour indiquer qu'elle est vide. Donc en réalité quand vous supprimez un fichier sur votre disque, vous ne supprimer que ses adresses dans la FAT, chaque case que votre fichier occupe dans la table d'allocation est remplacé par la valeur "je suis un bloc disponible". Voilà pourquoi supprimer un fichier c'est beaucoup plus rapide que quand vous l'écrivez.
- la deuxième raison (qui explique la fragmentation) est que si vous choisissiez d'écrire chaque fichier comme une succession de clusters contiguës, au fur et à mesure que votre disque va vivre (multiples créations et suppressions de fichiers), vous allez avoir de plus en plus de mal à trouver suffisamment d'espace contiguë pour stocker les gros fichiers alors même que vous aurez assez de cluster disponibles au total pour le stocker, mais non contiguës. En fragmentant les fichiers en petites unités logiques (clusters) vous êtes certains de toujours pouvoir écrire un fichier du moment que le nombre total de cluster disponible le permet.
Voilà vous savez tout. Vous comprenez qu'un filesystem, c'est obligatoire pour organiser la mémoire sur un disque qui va vivre dans le temps et pour que l'accès aux données se fasse le plus rapidement possible. L'inconvénient, c'est que plus un fichier est fragmenté sur le disque, plus la vitesse de lecture sera lente. Autrement dit, plus la chaîne de clusters d'un fichier est une succession de plages de clusters, plus la lecture sera lente. Voila par exemple le classement que j'obtiendrais pour plusieurs combinaisons de chaînes de fichiers classées du plus rapide à lire au moins rapide (tous les fichiers font 4 clusters) :
- fichier 1 : cluster 5 à cluster 8
- fichier 2 : cluster 1 à cluster 3 + cluster 9
- fichier 3 : cluster 0 + cluster 4 + cluster 10 à 11.
Il n'y a qu'une seule plage de cluster à lire dans le fichier 1, 2 dans le deuxième et 3 dans le dernier.
- 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 64 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).
[color=#ff0000]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.
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ûles à 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), 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.
- 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 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.
Modifié par eliboa, 24 juillet 2020 - 14:10.
?
