Tutoriels : Concepts basiques du hack Switch

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".