PanpanDanton2

• Pour une console patchée, la sysnand doit être en firmware 4.1.0 maximum et ne jamais être connectée aux serveurs Nintendo donc pensé en premier lieu à indiquer un mauvais code Wifi pour pouvoir configurer les DNS et ne pas être touché par le super nag qui empêchera d'utiliser l'exploit (la console demandera une mise à jour même si passage via le mode Recovery). Pour l'emunand, le firmware maximum est  le firmware supporté par le CFW utilisé (toujours faire la mise à jour via Daybreak sur une emunand).
• Pour les consoles non-patchée, le firmware de la sysnand n'a pas vraiment d'importance puisqu'il est toujours possible de faire un downgrade avec plus ou moins de difficultés/pertes de données (méthode via ChoiDuJour/EmmcHaccGen). Ceci dit, si aucune emunand n'est utilisée, ne pas mettre à jour au-delà du firmware supporté par le CFW, ça évitera bien des galères (mise à jour via Daybreak fortement conseillée dans ce cas pour éviter le bannissement). Pour l'emunand, il ne faudra jamais la mettre à jour au-delà du firmware maximum supporté par le CFW utilisé (utiliser toujours Daybreak pour mettre à jour l'emunand) car sinon il faudra attendre sa compatibilité avec celui-ci pour pouvoir la réutiliser (d'autres méthodes peuvent être mises en place pour downgrader l'emunand mais c'est assez complexe). Enfin, n'oublions pas que pour ces consoles l'exploit utilisé ne pourra jamais être patché, l'injection de payload fonctionnera toujours mais c'est le CFW qui peut ensuite être temporairement bloqué par Nintendo après une mise à jour firmware. Du coup, pour ceux qui utilisent une emunand avec une sysnand clean, la sysnand peut être mise à jour sous le dernier firmware de manière officielle sans risque si souhaité (risque de grillage d'Efuses) mais l'emunand doit rester sous le firmware maximum supporté par le CFW (l'emunand ne pose aucun problème au niveau des Efuses (les Efuses Lotus eux par contre peuvent être impactés et impactants) pour rappel et encore une fois, elle doit être mise à jour via Daybreak).
• Attention, quand vous mettez à jour le firmware du CFW, n'oubliez pas que si vous utilisez un thème personnalisé celui-ci peut ne plus être compatible avec le firmware plus récent donc supprimez le thème personnalisé en cas de souci, premier réflexe à avoir. Autre chose, en cas d'utilisation de modules (dossier "titles" ou "contents" du CFW) et en cas d'erreur après une mise à jour (firmware ou CFW) il est possible qu'un ou plusieurs modules posent problème, pensez donc à mettre à jour les modules ou bien supprimer les modules un à un pour savoir s'il n'y en a pas un qui pose un souci (exemples de modules: SX-Autoloader pour SX OS, Sysclk, Emuiibo, etc...).
• Attention, si vous utilisez une carte SD formatée en EXFAT et que vous avez sélectionné le firmware sans le driver EXFAT lors de la mise à jour via Daybreak, il faut utiliser une carte SD formatée en FAT32 pour réinstaller le firmware avec le driver EXFAT via Daybreak (tenter de réinstaller le même firmware et si cela ne fonctionne pas, faire un downgrade sur le firmware inférieur en FAT32 puis faire l'upgrade avec l'EXFAT). Une fois cela fait, on pourra réutiliser la SD formatée en EXFAT. Si vous utilisez une emunand via partition il faudra sauvegarder le contenu de la SD, formater en FAT32, installer le firmware EXFAT sur l'emunand, formater en EXFAT et remettre le contenu sauvegardé au début de la procédure (pour l'emunand via fichiers c'est pareil sauf qu'il pourra être nécessaire de convertir le fichier de la Rawnand pour séparer le fichier en plusieurs fichiers de 4 GO ou moins (notons que l'emunand ainsi splitée fonctionnera de la même façon en EXFAT donc pas besoin de refaire une conversion dans l'autre sens) et après le formatage en FAT32 il faut remettre les fichiers de l'emunand ainsi que les éventuels fichiers de configurations associés sur la SD pour pouvoir relancer l'emunand et la mettre à jour). Notez que mon Ultimate-Switch-Hack-Script contient une méthode simplifiée pour réinstaller le driver EXFAT via la Nand Toolbox, cependant il faut comprendre un peu comment cela fonctionne, voir le tuto sur l'installation manuelle du driver EXFAT dans la liste des tutos de cette FAQ.

• Déjà, lire cette FAQ, tout ne sera pas compris du premier coup et cela est normal mais quelques bases seront là, notamment lire plus attentivement la section expliquant quelques mots de vocabulaire utilisé fréquemment dans le hack Switch et aussi la section des infos générales.
• Savoir injecter un payload sur la console (pour les Switch non-patchées via le mode RCM (Via un PC/smartphone, via un dongle+jig ou via une puce), pour les Switch patchées en firmware 4.1.0 maximum via l'exploit Caffeine par exemple (exploit utilisable aussi pour les Switch non-patchées)), et pour les autres consoles la puce SX Core/Lite.
• Lire ce sujet qui explique clairement que quand on éteints la console, il faut réinjecter le payload par l'un ou l'autre des moyens disponibles et qu'il n'y a donc pas de CFW permanent.
• Faire un dump de la nand via Hekate avant tout et bien sauvegarder ce premier dump, on ne le répètera jamais assez mais ceci est vraiment très important et simplifie bien des choses lors de problèmes rencontrés parfois.
• Dumper les clés de la console via Lockpick-RCM, la procédure est expliquée dans cette FAQ à la section traitant du dump des clés. Ceci est également un impératif à faire avant tout, ces clés pourront peut-être sauver votre console.
• Définir si vous souhaitez utiliser le format EXFAT ou FAT32 pour la SD, l'EXFAT est plus pratique car il gère les fichiers de plus de 4 GO mais par contre il est plutôt instable sur Switch et provoque parfois des corruptions de données qui peuvent être très gênantes.
• Définir quel CFW(s) vous souhaitez utiliser, si vous souhaitez utiliser une Emunand ou non et suivre les tutos appropriés pour l'installation, plusieurs CFW peuvent cohabiter (perso je recommande Atmosphere en premier lieu et pour ceux qui le souhaite, y ajouter SX OS). Pour cela, voir la section "bootloaders et CFWs" de cette FAQ.
• Ensuite, s'intéresser à la section de cette FAQ traitant des homebrews histoire de comprendre rapidement comment cela fonctionne dans l'ensemble.
• Enfin, s'intéresser à la section de cette FAQ traitant des jeux (installation, dump...).

Bonjour

Je vais vous faire un résumé de tout ce que vous devez savoir si vous voulez conserver votre carte SD en Fat32, pour plus de stabilité et de compatibilité homebrew comparé au Exfat qui peut se corrompre par un reboot, l’écriture d un homebrew etc.. Et comment lui copier des jeux de plus de 4G dessus, car le Fat32 est bridé a cette taille max par fichier. Et de créer votre emunand en partition dédié sur SD et de faire son backup en vue d une restauration ou changement de carte SD

Le custom firmware et ses sigpatches

Pour installer des NSP/NZP ou lancer des homebrew vous avez besoin d'un Custom FirmWare (CFW) et de ses sigpatches

Pour ma part je préfère Kosmos, voici le lien ou le trouver. Par la suite vous pouvez le mettre a jours par son updater.
https://github.com/A...Kosmos/releases

Ensuite vous avez besoin des sigpatches de Kosmos, vous les trouverez ici:
https://github.com/J...hekate/releases

Si votre jeu est fake signer il ne sera pas compatible pour l'installation, donc il vous faut ces sigpatches en plus:
https://gbatemp.net/...osphere.521164/


L'emunand

Pour Hekate:

Si vous vous voulez utilisé une emunand, elle doit être obligatoirement en partition dédier. Car sur une partition Fat32 la lecture sera trop longue si vous la faites en fichier car celle-ci est splitté. Et avoir au moins une carte SD de 64G min , plus sont conseillés. Car elle va vous prendre environ 30G sur votre SD. Cette espace ne sera pas perdu car vous pourrez quand même installer vos jeux soient sur l emunand ou sur votre SD . Ou si vous le désirez vous pouvez réduire la taille de la partition user si vous préférez installer vos jeux que sur la SD. Pour ça je vous renvoie vers le tuto de Hyuunkel avec une partie simplifiée par NxNandManager posté par Eliboa si besoin:

http://www.logic-sun...ummc-partition/

Donc pour ce faire faire on doit créer 2 partitions sur la SD en procédant comme suit:

* connecter la carte SD au PC
* appuyer WIN+R et dans l'invite de commande tapez diskmgmt.msc puis OK
* chercher sa SD dans le gestionnaire
* Faire un clic droit sur la SD puis "Nouveau volume simple". Cliquer sur suivant, Attention ici on doit choisir la taille de la partition principale. Il faut lui soustraire la valeur suivante 29856 puis on clique sur suivant. Si vous aviez moins de 32G de partition principal choisissiez le Fat32 si vous avez plus de 32G prenais le NTFS ou EXFAT . Pas de panique on va la passer en Fat32 par la suite
*Sur l'espace non alloué, cliquez sur "Nouveau volume simple" puis suivant,ne rien toucher aux valeurs et au moment ou on vous demande de formater. Prenez bien "Ne pas formater ce volume", suivant , finir.
* Maintenant vous avez 2 partitions, il va falloir formater la première en Fat32.
* Pour ce faire vous avez besoin de guiformat32 que vous trouverez ici
http://www.ridgecrop...m?guiformat.htm
* Lancez le en mode administrateur, puis sélectionnez bien la lettre liée a votre partition principal et vous prenez (32768 octets) puis format
*Finis

Voila maintenant il vous reste juste a créé votre emunand par le biais de Hekate et c'est lui qui va se charger de la mettre en place dans votre seconde partition. Pour ce faire je vous renvoie sur le tuto de Giga300 pour cela:
http://www.logic-sun...nerebacaffeine/
Et de choisir SD partition au lieu de SD file

ATTENTION: Quand vous brancherez votre carte SD par la suite au PC, il vous demandera de formater votre partition contenant votre emunand. Surtout NE JAMAIS CLIQUER SUR OUI

Faire un backup de son emunand qui se trouve en partition

Suite a la release de NXNandManager de Eliboa voila comment procéder:

Il vous faut Lockpick-RCM pour dump vos clés

https://github.com/s...ck_RCM/releases

Et NxNandNanager disponible ici:
https://github.com/e...anager/releases

Commencer par dump vos clés par Lockpick-RCM depuis Hekate

Le fichier prod.keys généré se trouve dans votre dossier switch

Brancher votre carte SD
Lancer NxNandManager

Cliquez sur Option

Configure Keyset, puis import. Chercher votre fichier prod.keys généré Lockpick-RCM. Puis Save

Puis File
Open drive

Double clique sur la partition qui s'ouvre
Puis Full Dump

On patiente le temps du dump

Et voila vous aurez un backup de votre emunand au chaud sur votre PC. Ce qui vous permettra de la restaurer en cas de plantage ou de changement de SD. Il vous suffira juste de refaire la partie préparation de la SD puis de faire full restore dans NxNandManager.
Si vous préférez la remettre par Hekate il faut la dump en 3 parties en procédant comme suit et la réinstallation devra être faite depuis une carte ExFat car la taille de la nand est de 30G ou de splitter celle ci avec le script de shadow256

Dump pour Hekate

Un dump pour Hekate  se compose en 3 fichiers

Boot0

Boot1

Rawnand.bin

Voila comment l obtenir depuis NXNandManager, cliquez sur option puis dump Rawnand only

Ensuite indiquer ou sauvegarder votre fichier rawnand.bin et faire enregistrer

Attendre la fin de l'opération

Pour récupérer votre BOOT0 et BOOT1 il faut procéder comme suit:

Faire un clic droit sur le BOOT0

Puis dump to file

et sauvegarde le

Refaire l opération pour le BOOT 1

Split pour les cartes en FAT32

Commencez par récupérer le script de shadow256 disponible ici

http://www.logic-sun...ch-hack-script/

Une fois la partie configuration et mise a jours de faite procédez comme suit :

Faite 5

Puis 6

Sélectionnez le répertoire ou se trouve votre rawnand.bin

Ensuite indiquez votre répertoire ou stocker le split de votre rawnand.bin

Ensuite choisissez le nombre de fichier pour votre split

Et répondre o pour la question de admosphère

Ensuite patientez , une fois finie vous verrez cela

Voila votre fichier est splitter pour une carte SD en FAT32

Par SXOS:

Il vous suffit simplement de formater votre carte SD en FAT32  par guiformat32. SX OS se chargera de la splitter. On peut créer l'emunand par SX OS sans avoir de licence , mais vous ne pourrez pas utilisez leur soft par la suite

Glissez votre fichier Boot.dat a la racine de votre SD.

https://sx.xecuter.c...beta_v2.9.2.zip

Bootez sur SX OS par le biais de TegraRCM GUI en injectant leur payload.bin

https://sx.xecuter.c...oad/payload.bin

Une fois sur le menu

Cliquer sur option

Puis EmuNand

Puis Hidden Partition on microSD

Patienter le temps de la copie (Attention la Switch doit être full charge)

Une fois finie vous revenez sur le menu et vous pourrez activer celle ci . Si vous êtes un utilisateur SX, sinon désactiver la

Pour l'utiliser par Hekate il va falloir créer un fichier emummc.ini

Pour ce faire vous ouvrez un nouveau document.txt

Vous copiez ceci a l’intérieur

[emummc]
enabled = 1
sector = 0x2
nintendo_path = emutendo

Et vous le renommez en emummc.ini

Vous le placer ensuite dans le dossier suivant de votre SD

emuMMC\emummc.ini

Et vous l activez dans Hekate

emuMMC

Change emuMMC

Et vous cliquez sur votre partition

Copie des jeux et les softs

Jeu de moins de 4G:

Si votre jeu ou votre update fait moins de 4G, juste la copier sur votre SD et l installer par le soft de votre choix. Goldleaf, Tinfoil, OGTinfoil

Jeu de plus de 4G:

Pour ce faire plusieurs solutions s offre a vous:

Le cable usb:
Soit vous acheter un cable USB type A vers USB type C ou si votre carte mere a un port USB type C - USB type C. Les 2 types de câble fonctionnent. Et d'avoir installé les drivers sur votre pc. Vous trouverez le tuto toujours chez notre ami Giga300 dans sa rubrique Goldleaf.
En réseau:

Il faut prendre les logiciels adaptés

En usb :
Goldleaf + Quark.

Cela vous permettra d'explorer votre disque dur sur votre pc pour aller récupérer votre fichier.
https://github.com/X...ldleaf/releases
Pareil je vous renvoie vers le tuto de Giga300 rubrique Goldleaf pour cela
http://www.logic-sun...nerebacaffeine/
Si vous avez un souci, avec l'installation de certain jeu par Quark. Vous pouvez utiliser NS-Usbloader et de choisir Goldleaf dans celui-ci

En réseau si vous n avez pas de cable usb:

OGTinfoil + Ns-usbloader

il vous faut donc :
OGtinfoil dispo ici:
https://github.com/b...nfoil/releases/
Et Ns-Usbloader
https://github.com/d...loader/releases

Ensuite, il vous suffit de lancer NS-Usbloader, de choisir Tinfoil puis net et de rentrer l ip reseau de votre Switch. Elle est disponible dans OGTinfoil si besoin

De choisir votre NSP.
Sur votre switch vous lançait OGtinfoil, puis titlemanagement. Et la vous sélectionnez Network install nsp
Et sur NS-Usbloader vous cliquez sur Envoyer vers NS

A savoir, vous pouvez aussi envoyer vos NSP en USB par OGTinfoil et Ns-Usbloader. Juste sélectionner USB et de prendre USB Install NSP. De plus Il a la possibilité d'installer les NSZ comparé a Goldleaf. Perso j utilise les 2 en fonctions de mon backup

Merci a Giga300 pour son tuto à Eliboa pour NxNandManager pour le dump de votre emunand et son redimensionnement de la partie user à Shadow256 pour la partie SXOS et son script et Hyuunkel  pour son tuto de redimensionnement

Cdt

 

En suivant ce tuto vous allez pouvoir créer une mini emuNAND de 8 Go qui sera compatible aussi bien avec SX OS qu'Atmosphère. Vous pouvez suivre ce même tuto pour créer une emuNAND de la taille de votre choix, mais ici j'ai choisi de vous montrer comment créer une mini emuNAND.

Pré-requis : 

- Il faut un PC sous Windows (64Bits) avec les droits "administrateur".

- Il faut que vous ayez un dump de votre sysNAND (vous pouvez en faire un nouveau via Hekate en suivant ce tuto). Il vous faudra les fichier RAWNAND.bin, BOOT0 et BOOT1

- Il faut que ayez un dump de vos biskeys (vous pouvez le faire en injectant le programme Lockpick_RCM)

- Il faut vaut une carte SD d'une capacité de 16 Go minimum  sur laquelle on va créer l'emuNAND.

- Téléchargez la dernière version de NxNandManager

Etape 1 : Lancer NxNandManager

Extraire l'archive de NxNandManager puis lancer le programme NxNandManager.exe, vous devriez voir ça :

Etape 2 : Créer une NAND redimensionnée.

Maintenant on va créer une nouvelle RAWNAND mais cette fois-ci en redimensionnant la partition USER. Pour cela faîtes "CTRL+SHIFT+R" (ou Options > Resize NAND). Vous devriez voir apparaître cet écran :

Dans "New size for USER" vous allez pouvoir indiquer la taille souhaitée pour la nouvelle RAWNAND. Le programme vous indique la taille minimum de la partition, cette taille peut varier en fonction des NAND, elle correspond à l'espace déjà occupé sur la partition USER de votre NAND. Autrement dit, cela vous empêche de perdre des données existantes sur la partition (sauvegardes, jeux installés, etc).

Si toutefois votre NAND est trop pleine, vous pouvez cocher "Format USER" pour lever cette restriction (mais la partition sera formatée, donc toutes les données supprimées). Dans mon cas, je pars d'un fichier RAWNAND.bin qui a été fait alors que la mémoire de la console était quasi vide (pas de jeux installés) dans je n'ai pas ce problème.

Pour ce tuto, on va faire une emuNAND de 8 Go au total. Aussi, j'adapte la taille de ma partition USER pour que la taille total atteigne 8 GB (à peu près) :

Choisissez l'emplacement et le nom du fichier de destination en cliquant sur Save as..

Dans mon exemple j'ai choisi de nommer le fichier "RAWNAND.resized"

Cliquez ensuite sur Save pour commencer le redimensionnement :

Laissez le programme travailler jusqu'au bout. Ensuite revenez à la fenêtre principale de NxNandManager et ouvrez cette fois-ci fichier RAWNAND.resized via "CTRL+O" :

Une fois ouvert, contrôlez la taille de votre RAWNAND.resized, il doit faire environ 8 Go.

Etape 2 : Créer une emuNAND sur carte micro SD.

Maintenant que vous avez redimensionné votre NAND, on va pouvoir créer l'emuNAND sur la carte SD. Depuis la fenêtre principale de NxNandManager, cliquez dans le menu "Options" sur "Emunand Creation Tool" :

Vous devriez voir cette fenêtre :

Nous allons maintenant devoir ajouter dans la partie "Input NAND" l'emplacement des fichiers BOOT0 et BOOT1 que vous devez avoir de côté (obtenu par un dump de NAND via Hekate). Utilisez les boutons "Select file" :

Ensuite, il va falloir choisir le type d'emuNAND que vous souhaitez faire. Personnellement, je recommande fortement le type "SD Partition" et c'est celui-là que nous allons utiliser dans le tuto.

Vous pouvez aussi choisir "SD File (AMS)" pour Atmosphère ou "SD File (SX OS)" pour SX OS, le fonctionnement est peu ou prou identique.

Insérez maintenant votre carte SD dans le lecteur de votre PC. Vous devriez la voir apparaître dans la liste "Select target disk".

Attention : Veillez à avoir sauvegardé tout ce que vous avez besoin de conserver avant de lancer la création de l'emuNAND car toute la carte SD va être formatée.

Dans mon exemple, j'ai pris une carte SD de 64 Go :

Le programme vous indique la taille de votre emuNAND (en vert) et la taille de la partition "utilisateur" qui sera créée sur votre carte SD, la partition qui contiendra Hekate, AMS ou SX OS, homebrew, etc (en bleu/violet) 

Quand vous êtes prêts, cliquez sur "Create emuNAND", une popup vous avertira que toutes les données existantes sur votre SD vous être effacées, validez. Laissez le programme travailler jusqu'au bout :

Une fois terminé, ouvrez l'outil de "Gestion des disques" Windows, vous devriez retrouver votre carte SD :

L'emuNAND correspond à la partie non allouée. L'autre partition en FAT32 pourra accueillir SX OS ou Hekate, homebrews, etc.

Optionnel (formater la partition utilisateur en exFAT)

Si le driver exFAT est installé sur votre NAND d'origine, vous pouvez formater la partition utilisateur en exFAT (E: dans mon exemple), mais ce n'est pas obligatoire :

Etape 3 : Booter son emuNAND sur la Nintendo Switch

Maintenant, il vous faut déplacer tous les fichiers nécessaires pour lancer SX OS ou Hekate+Atmosphère (comme pour le CFW en sysNAND) sur la partition utilisateur (E: dans mon cas) :

Dans le cas de SX OS vous n'avez besoin que de boot.dat et license.dat logiquement. Ici j'ai tout ce qu'il me faut pour lancer via Hekate ou SX OS.

Maintenant vous pouvez retirer la SD de votre PC et l'insérer dans la Nintendo Switch.

Booter via SX OS

Depuis votre injecteur de payload favori, injectez SX OS comme vous le faites habituellement pour booter en CFW. Restez appuyé sur VOLUME+ au moment de l'injection, vous devriez voir un bouton "Emunand enabled" :

Cliquez sur Boot custom FW et vous devriez booter sur votre emuNAND.

Booter via Hekate

Depuis votre injecteur de payload favori, injectez Hekate comme vous le faites habituellement pour booter en CFW.

Cliquez sur emuMMC :

Cliquez ensuite sur "Migrate emuMMC" :

Hekate devrait trouver votre emuNAND, cliquez sur Continue.

Ensuite cliquez sur "Change emuMMC" puis sur "SD RAW 1" et validez :

De retour sur l'écran précent (Close), vous devriez voir "Enabled!" en vert :

Retournez à l'écran d'accueil de Hekate et cliquez sur "Launch" :

Enfin, cliquez sur "CFW (EMUMMC)" et vous allez booter votre emuNAND

Une fois l'emuNAND bootée via Hekate ou SX OS 

Rendez-vous dans les paramètre de la console et vérifiez la taille de votre emuNAND et carte SD dans  "gestion des données" :

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 ?

Spoiler

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.

 

Spoiler

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

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

- Que contient la NAND ?

- Aller plus loin : SoC Tegra X1 NVIDIA, boot et exploit RCM

Tu peux aussi activer incognito via la toute dernière version de NxNandManager.

Petit tuto rapide :

- Brancher la Switch au PC en mode RCM

- Ouvrir TegraRcmGUI (installer le driver dans "Settings" si jamais utilisé), aller dans Tools puis sélectionner "Mount eMMC RAWNAND". Cliquer sur l'icone de memloader (clef usb).

- Ouvrir NxNandManager v2.0, (GUI) aller dans "File" puis "Open drive". Un disque devrait s'afficher, le sélectionner.

- Dans NxNandManager, la NAND devrait s'ouvrir. faire d'abord un backup de la partition PRODINFO sur son PC (clic droit sur la partition, puis "Dump to file...")

- Une fois le backup fait (très important), aller dans "Options" puis "Incognito". Lire l'avertissement puis cliquer sur Yes.

- Au message de confirmation, appuyer sur le bouton POWER de la console pendant 5 secondes.

- Rebooter la switch, incognito est installé

edit : tu peux aussi activer incognito sur l'emuNAND, dans NxNandManager, ouvrir le fichier 00 dans le repertoire \emuMMC\SD00\eMMC\ de la SD.

[Tuto Complet] : Restaurer la NAND d'une Switch avec SX OS / SX PRO et Hekate

 
 
 
Bonjour, je vais vous expliquer comment restaurer un dump de la nand grâce à SX OS / SX PRO et Hekate.
 
On nous explique toujours comment dumper la nand de la switch mais jamais l'inverse. Aujourd'hui je vais vous expliquer comment restaurer la nand de manière claire et précise, et encore un GRAND MERCI à @annimmalus et @oob qui m'ont expliqué comment faire et également à @shadow256 qui m'a corrigé et revu mon tuto car l'orthographe se n'est pas mon point fort mais j'essaie de faire de mon mieux.


Ce que nous voulons tous savoir c'est : Qu'est-ce qu'on fait exactement de ces 3 fichiers (rawnand.bin, BOOT0 et BOOT1) après avoir dumpé la nand.

C'est ces trois fichiers qui vont permettre de restaurer la nand donc de remettre la switch à neuf en cas de problème.

- rawnand.bin - 29,1 Go (30 535 680 Ko)
- BOOT0 - 4,00Mo (4096 Ko)
- BOOT1 - 4,00 Mo (4096 Ko)


Question : Qu'est-ce qu’il faut savoir sur la NAND?

Quand vous utilisez votre console, toutes les actions que vous faites sont enregistrées dans la mémoire de la console (la nand) (lancement d'un CFW, installation d'un jeu en NSP, lancement d'un jeu en XCI...).


Question : A quoi sert le dump de la nand et la restauration de la nand?

Le dump de la Nand est une copie complète du système de la console (tickets, paramètres, profiles et jeux installées dessus le cas échéant) permettant de restaurer celle-ci en cas de problèmes.
Note importante, le dump d'une nand est associé à une console, la restauration d'un dump de nand d'une console sur une autre console provoquera le brick (la console ne fonctionnera plus) de celle-ci.
Attention, si votre console est bannie, cela ne changera rien de restaurer la nand, la console sera toujours bannie car c'est du côté des serveurs de Nintendo que ça se joue sur ce point.
Pour le dump de la nand complète il vous faut au minimum une carte micro SD d'une taille de 32go formaté au format exFAT !


Question : Quelle est la config de ta console @inconnux ?
De mon coté j'utilise actuellement une Nintendo Switch en sysNAND 6.1.0 + emuNAND 9.1.0 avec SX OS 2.9.3 BETA inclus.

Revenons à notre sujet...

Donc voici comment restaurer la nand d'une Switch avec SX OS / SX PRO et Hekate :

Placer les fichiers rawnand.bin, BOOT0 et BOOT1 dans Carte Micro SD:\backup\restore (si cela ne fonctionne pas, il faudra les mettre dans Carte Micro SD:\backup\un_nombre_hexadécimal_généré_par_Hekate\restore).

Ça doit faire comme ceci :
Carte Micro SD:\backup\restore\rawnand.bin
Carte Micro SD:\backup\restore\BOOT0
Carte Micro SD:\backup\restore\BOOT1

Ensuite :
Télécharger Hekate, décompresser le fichier télécharger et mettre le fichier hekate_ctcaer_4.2.bin (le nom du fichier pourra être différent selon la version d'Hekate téléchargée) à la racine de la carte micro SD.

Ça dois faire comme ceci :
Carte Micro SD:\hekate_ctcaer_4.2.bin

Ensuite, booter sur SX OS (tester avec la version 2.3 de SX OS)

Une fois le menu de démarrage de SX OS affiché, aller dans "Options" , "Payloads" et cliquer sur le fichier .bin, donc ici hekate_ctcaer_4.2.bin

Une fois dans le menu de "[hekate - CTCaer mod v4.2]" (la version pourra être différente selon la version d'Hekate téléchargée)

Se déplacer sur "Tools..." avec les touches de volume "+" et "-" et validé avec le bouton "Power" de la console et aller ensuite dans "Restore..." pour restaurer la nand puis pour finir dans option "Restore eMMC Raw GPP" attendre 10s et appuyer sur "Power" de la console pour validé et attendre que la barre grise atteint les 100% ensuite attendre que la barre vert atteint les 100% dès que c'est fait il y aura écrit :

Finished and verified

Press and key...

Appuyez ensuite sur le bouton "Power" de la console puis allez ensuite dans "Restore eMMC BOOT0/1"attendre 10s et appuyer sur "Power" de la console pour validé attendre que la barre vert atteint les 100% dès que c'est fait il y aura écrit :

Finished and verified

Press and key...

Appuyez ensuite sur le bouton "Power" de la console

C'est bon vous pouvez redémarrer la console vous avez restaurez la NAND de votre console

--

A VOIR AUSSI :

La FAQ qui contient un grand nombre d'informations.

Ce tuto pour Dumper la nand de @Hackstore59 (Pour dumper la nand de la switch avec SX OS ou Hekate)

Cette news sur SX OS 2.0 de @eliboa dans laquelle on parle de l'emunand inclue dans la sysNAND.

Moi je ne ferais pas ainsi, voici comment je procèderai à ta place:
- Au cas où, sauvegarde des sauvegardes de jeux via Checkpoint ou EdiZon, perso ma préférence va plutôt vers ce dernier.
- Création de l'emunand tout de suite, on s'en fou qu'elle soit clean elle.
- Activation de la licence SX OS si pas encore fait et vérification du bon fonctionnement de l'emunand créée en la lançant, ne rien installer dessus pour le moment.
- Suppression du dossier "emutendo" créé juste avant par l'emunand, renommage du dossier "nintendo" en "emutendo" histoire de récupérer les jeux déjà installés le cas échéant sans se refaire l'installation normalement.
- Restauration du dump de ta nand sur ta Sysnand via Hekate.
- Boot en OFW via SX OS (maintenir la touche "volume +" pendant le démarrage jusqu'à se que le menu permettant le choix de booter en OFW s'affiche).
- Mise à jour du firmware de la Sysnand via les serveurs de Nintendo.
- Voilà, maintenant faire comme bon te semble, ceci dit je déconseille la restauration des sauvegardes de jeux sur la Sysnand car il m'a semblé lire un jour que ceci pouvait être détecté par Nintendo, si tu souhaites jouer en ligne via la Sysnand il vaut mieux la garder vraiment clean.

merci à toi aussi

Très intéressant tout ça. Je pourrais être dans la me^me configuration que l'auteur.

Mais non, j'ai bien intégré tout les sujets dont il est question ici.

 

Vous auriez un tuto pour reprendre tout ça depuis 2ans?

 

J'suis en v8.0.1CFW sur sys & emuNand, et comme l'auteur, ma gamine me tanne tous les jours pour que je lui installe Animal Crossing. Ls cours d'école je vous jure, une plaie. Donc, je dois mettre à jours tout ça, mais il y a tellement de trucs à éviter pour pas faire de connerie qu'il faut que je prépare tout ça et que je lise un max.

Ici et là, j'ai vu des problème de dernière minutes avec atmosphere, ou Hekate (je passe par Hakate pour lancer le fusee-gelee). Je dois aussi virer les thème, et c'est pas une mince affaire cette manip.

Donc, je cherche un tuto pas forcément hyper pointu, plutôt une feuille de route qui répertorirait tous les cas de figures possible, des plus fréquents, au plus particulier. Vous auriez ça en stock s'il vous plait?

Salut, pour partir sur des bases saines:

-archive tes saves avec dbi.

-formatte ta sd.

-remet hekate, atmo et les sigpatch a jours.

-refait une emunand sur une partition cachée avec hekate.

-met la a jours en 13.2.1 via daybreak.

-remet tes jeux et saves via dbi.

Tout ce dont tu as besoin (sauf les sigpatch) est ici:

https://nh-server.gi...o/switch-guide/

J'utilise SX os depuis que c'est sorti quasiment, avant l'emunand j'avais desactivé toute connexion au wifi, j'ai utilisé des NSP et des XCI, puis lorsque est arrivé l'emmuNand j'ai réinitialisé la console, fait un back up de la Sysnand que j'ai garder et installé l'émuNand.

Depuis je me bat avec ma femme car elle utilise pour fortnite et moi je doit rebooter la console avec le jig et tout à chaque fois, mais aucun ban à déploré pour l'instant. L'émunand est un bon moyen de passer sous le radar mais attention à ce que vous avez fait avant, logiquement même en ayant réinitialisé ma switch il devrai rester des traces de mes NSP mais pour le moment RAS et j'ai du bois à porté de main !

Banni également après avoir fait des mises a jours et installation de hbg.
Utilisant jamais le online je ne faisait pas tres attention mais nintendo est super reactif sur les bans

Si tu jouais pas en ligne tu na rien perdu et honettement quand j'y pense avec tout se que rapporte le hack de la console c'est rentable. 

Atmosphere s'auto-protège en redirigeant les logs durant son utilisation se qui fait que la télémétrie n'est normalement pas affectée donc c'est pas toujours facile de savoir s'il faudrait ou non bannir une console alors que si tu installes un NSP non signé là il n'y a aucune question à se poser. Faut pas oublier que pour bannir Nintendo doit être à peu près certain de se qu'il fait car devant des tribunaux ça peut mal se passer pour eux aussi pour diverses raisons si des bannissement abusifs ont lieu. Une autre stratégie qui est utilisée est le bannissement par vagues, les serveurs repèrent les consoles à bannir mais n'appliquent pas immédiatement la sanction, ceci permet de rendre l'identification des causes du bannissement très difficile d'où le fait de toujours préciser que rien n'est jamais certain au niveau du bannissement lorsqu'on hack une console et qu'on va en ligne.

Je pose ça là, ça peut aider pour comprendre comment fonctionne le ban et quels sont les risques (extrait d'un guide qui date un peu mais toujours d'actualité)

Nintendo Switch - Les risques liés au hack

Les risques liés à la garantie constructeur et à la violation de la propriété intellectuelle

Nous n'allons pas y aller par quatre chemins, si vous modifiez le contenu de votre console (hardware ou software) et qu'elle vient à tomber en panne, il y'a de forte chance que sa réparation ne soit pas prise en charge par la garantie constructeur. La formulation est intentionnellement générale car nous verrons plus tard que toutes les modifications ne sont pas forcément détectables par Nintendo et que certaines pratiques sont plus ou moins risquées.

S'agissant de la violation de la propriété intellectuelle, elle s'applique lorsque vous reproduisez ou diffusez du code protégé par le droit d’auteur. Un exploit ou un programme écrit dans le but de hacker une console n’est pas en soi illégal, en tout cas au regard de la propriété intellectuelle. Les possibilités de violation de la propriété intellectuelle sont nombreuses mais en tant que simple utilisateur vous n’avez pas grand-chose à craindre. Ce sont majoritairement les hackeurs et développeurs qui sont concernés. Même si la plupart d’entre eux préfèrent utiliser du code libre à 100%, ils sont parfois amenés à réutiliser du code propriétaire dans leurs exploits ou leurs programmes. En tant qu’utilisateur, ce que vous devez savoir, c’est qu’il vaut mieux éviter de partager un programme si vous avez un doute sur sa légalité. De la même manière, évitez de diffuser des clés de décryptage (telles que les masterkey qui permettent de décrypter le contenu des cartouches de jeu) obtenues en violation des protections DRM (Digital Rights Management)

Les risques liés à l'accès aux services en ligne de Nintendo

Qui n’a jamais croisé, sur un forum ou salon de discussion, un utilisateur inconsolable après avoir rapporté ne plus pouvoir utiliser les services en ligne de sa console préférée ? Le risque de « ban » (bannissement) existe depuis l’avènement des consoles connectées et de la dématérialisation. Et c’est toujours le cas sur la Nintendo Switch, le risque est même encore plus important que sur les générations précédentes de consoles.

Pour bien comprendre les risques encourus, il faut d’abord comprendre ce qu’on entend par « services en ligne » sur une Nintendo Switch.

On peut distinguer deux types de services en ligne :

- Le CDN (content delivery network) de Nintendo. Il permet le téléchargement des jeux et DLC depuis l’eShop, ainsi que le téléchargement des mises à jour firmware et celles de vos jeux.

- Les services en ligne de jeux (pour jouer en multi online sur Mario Kart ou Splatoon pour ne citer qu’eux).

Il existe donc logiquement deux types de ban possibles. Le premier, appelé « ban CDN », empêche l’utilisateur de télécharger la moindre jeu eshop (payant, gratuit, démo), DLC ou une mise à jour. Le second, appelé plus sobrement « ban » (car avant l’ère Switch, il n’en existait pas d’autres sur les consoles Nintendo), vous empêche donc d’utiliser les fonctionnalités en-ligne d’un jeu vidéo, qu’il soit édité par Nintendo ou non. Pour plus de clarté dans la suite du guide, appelons-le « ban online ».

Le ban le plus courant pour les utilisateurs de consoles hackées est le « ban online », Nintendo applique une politique intransigeante concernant l’accès aux  services en ligne pour les jeux, et il facile de comprendre pourquoi. Personne n’aime jouer en ligne contre un cheater qui fausse complètement les règles du jeu et enlève tout le fun des parties multi. Vous ne voudriez pas non plus que votre enfant puisse tomber sur du contenu inapproprié pendant ses sessions de jeu online, tout ça à cause de petits malins qui modifient leur avatar avec du contenu pornographique (comme ça a été le cas avec Super Mario Odyssey). Par conséquent, dès lors que Nintendo détecte une console modifiée, il bannit la console pour l’accès au online, c’est imparable et quasi-automatique.

Le ban CDN est moins courant mais beaucoup plus contraignant. Une fois votre console bannie du CDN vous pouvez dire adieu à toutes les mises à jour automatiques pour les jeux (officiels ou backup) et pour la console. Vous serez alors contraints de tout faire manuellement. Pas de panique, il existe des techniques qui permettent d’installer manuellement des mises à jour de jeux, DLC, et maj firmware. Ces techniques ne sont cependant pas toutes « user-friendly » (à l’heure actuelle en tous cas) et vous devrez mettre les mains dans le cambouis pour les appliquer.

Ce type de ban n’était pas pratiqué par Nintendo, jusqu’à aujourd’hui. Sur 3DS ou WiiU par exemple, le CDN est beaucoup moins sécurisé et il est tout à fait possible d’en télécharger anonymement du contenu. C’est pourquoi on trouve ce qu’on appelle des « freeshop », c’est-à-dire des programmes qui vous permettent d’explorer le contenu du CDN et d’en télécharger gratuitement n’importe quel titre (un eshop alternatif en quelque sorte).

Mais ne vous y trompez pas, même si nous verrons qu’il existe des freeshop pour la Nintendo Switch, il est impossible de télécharger anonymement depuis le CDN Switch, IMPOSSIBLE. Quoi que vous puissiez lire sur le sujet, retenez bien cela. Nintendo a tiré les leçons de ses erreurs passées et a incorporé un certificat unique (un petit fichier contenant une clé cryptographique inviolable) dans chacune des Switch produites à l’usine. Lorsque votre console envoi une requête au CDN (pour télécharger la dernière maj. de votre jeu préféré par exemple), elle transmet aussi ce certificat unique (obligatoire sinon la requête est refusée). Dès lors, Nintendo peut savoir précisément quelle Switch se connecte au CDN et quel contenu elle télécharge (et donc savoir si le jeu que vous téléchargez à bien été acheté).

Pour en revenir aux freeshop qui circulent un peu partout pour la Switch, sachez que leurs développeurs ne sont pas magiciens, ces outils ne fonctionnent pas sans certificat. Certains freeshop vous proposent d’utiliser votre propre certificat (il faut alors préalablement l’extraire de votre console), d’autres freeshop utilisent un certificat intégré au programme (mais qui a forcément été extrait d’une console) si bien que tous les utilisateurs de ce freeshop utilisent le même certificat. En aucune manière je ne vous conseille d’utiliser ces outils. Si toutefois la tentation est trop grande, utilisez toujours un freeshop qui n’utilise pas votre certificat.

edit 02/2019 : Attention, maintenant Nintendo applique le super ban, c'est-à-dire qu'il bannit systématiquement le online et le CDN, attention donc.

Les risques liés aux dump de cartouche

Il existe un troisième type de ban, le “ban cartouche”. Quoi, késako, encore un autre ban ? Je viens de vous expliquer que Nintendo a ajouté un certificat unique dans chaque Switch. Et bien sachez qu’il a fait de même avec les cartouches de jeu.

L’europe a peut-être été plus épargnée, mais Nintendo lutte depuis longtemps contre les contrefaçons de cartouche, notamment en asie. La solution mise en place par la firme a donc été d’ajouter un certificat unique dans chaque cartouche de jeu produite (deux cartouches de Super Mario Odyssey produites sur la même chaîne de fabrication auront chacune un certificat unique).

A l’instar du ban CDN, lorsque vous utilisez un jeu sur cartouche (alors que votre Switch est connectée à internet), Nintendo en mesure de savoir précisément quelle cartouche de jeu vous utilisez (pas simplement quel jeu, mais quelle cartouche précisément). Il peut donc vous interdire l’accès aux services en lignes pour cette cartouche de jeu (autrement dit, il s’agit d’un ban online mais pour un certificat de cartouche plutôt que de console).

Et là vous allez me dire : et alors ? n’ai-je pas le droit de prêter ma cartouche à un ami ou de la revendre ? pourquoi Nintendo irait bannir ma cartouche ?

Effectivement, il est tout à fait possible qu’un parfait innocent, n’ayant jamais hacké une console de sa vie, fasse l’acquisition d’une cartouche (d’occasion) dont le certificat est banni ! Oui oui vous avez parfaitement compris ^^

C’est pourquoi ce type de ban est extrêmement rare, c’est la dernière “cartouche” que sort Nintendo pour contrer le piratage (oui, j’ose cette blague toute pourrie).

Prenons un exemple pour mieux comprendre. Un gentil pirate achète une cartouche de jeu neuve chez son revendeur habituel. Il rentre chez lui et fait un dump (une copie) de sa cartouche. Il est important d’avoir à l’esprit que lorsqu’on fait un dump de cartouche, on copie aussi le certificat qu’elle contient. Maintenant que notre gentil pirate à fait un backup, il se dit qu’il n’a plus besoin de sa cartouche et la revend d’occasion. Mais il ne s’arrête pas là, comme c’est vraiment un gentil pirate, il partage son dump avec la communauté sur internet (quoi de plus facile après tout, un torrent et c’est parti !). Ok notre pirate est sympa mais il n’a jamais lu ce guide “pour les nuls” et n’a pas supprimé le certificat contenu dans le dump avant de le mettre en ligne. Maintenant il est trop tard, le dump a été téléchargé des dizaines voire des centaines de fois. C’est justement là que ça devient dangereux. Nintendo ne va pas bannir un certificat si vous partagez votre dump avec un ou deux amis (mais qui sait ce que ces derniers en feront ?). En revanche, si un nombre conséquent de personnes utilisent la soit-disant même cartouche, et de surcroît au même moment, Nintendo va sortir le carton rouge et bannir le certificat de ladite cartouche. Le malheureux dans toute cette histoire, c’est le pauvre type qui a acheté sa cartouche d’occasion et qui n’y est absolument pour rien.

Comprendre la NAND 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 système d’exploitation du 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 :

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

Comment se prémunir des différents types de ban

Maintenant que vous connaissez parfaitement les différents types de ban, voyons quels sont les moyens que vous pouvez mettre en œuvre pour vous en prémunir.

Commençons par le ban cartouche. Vous l’avez sans doute compris de vous-même, le meilleur moyen de ne pas voir sa cartouche bannie est de ne pas la dumper ou de ne pas diffuser le dump. Restrictif mais efficace.

Si toutefois vous souhaitez absolument partager votre dump, sachez qu’il est possible de supprimer le certificat présent dans le dump en modifiant directement le fichier binaire (des outils existent pour le faire).

Enfin pour éviter les mauvaises surprises, essayez toujours les services en ligne d’un jeu avant d’achetez une cartouche d’occasion à un particulier

Il est plutôt facile de se prémunir contre le ban CDN, nous l’avons vu précédemment. Il suffit de ne jamais utiliser les freeshop qui circulent sur le net (ou a défaut, seulement ceux qui n’utilisent pas votre certificat privé). Pour télécharger des jeux piratés, préférez les releases des grandes team Warez telle que BigBlueBox qu’on trouve sur internet.

Le ban online est très difficile à éviter dans la mesure où la Nintendo Switch ne dispose pas encore d’une emuNAND qui puisse être complètement isolée d’internet. Toute installation de jeux, lancement de jeux, modification de sauvegarde, bref tout ce qui peut modifier votre NAND de manière non conventionnelle peut être détecté par Nintendo. Il faut savoir aussi que la Switch génère beaucoup de logs, notamment lors de crash. Ces logs sont conservées dans votre NAND et transmises à Nintendo lorsque votre Switch est connectée à internet. Il est donc très facile pour Big N de retracer l’historique de vos utilisations.

Vous l’aurez compris, il n’y a actuellement aucun moyen réellement efficace pour de se prémunir d’un ban online.

On peut toutefois réduire le risque en limitant les données écrites sur la NAND par le CFW. Par exemple, il est préférable de lancer un backup de jeu présent sur votre carte SD (sans l’installer, au format XCI) plutôt que d’installer le jeu sur le système (comme un jeu normal), car l’installation écrit durablement sur votre NAND alors qu’un lancement de jeu depuis la SD (XCI) ne laisse que peu de traces (éventuellement des logs ou rapports mais rien de permanent)

Enfin, comme un peu d’humour n’a jamais fait de mal à personne, je terminerai en précisant que le meilleur moyen de vous prémunir d’un ban est de vous auto-bannir vous-même ! C’est le 4ème type de ban, « l’auto-ban ». En coupant tout accès internet à votre console (en la laissant en mode avion par exemple), vous vous épargnerez l’horreur provoquée à la lecture d’un message d’erreur synonyme de bannissement .

Très bon résumé des infos sur le sujet, cependant maintenant sous Windows avec NXNandManager il est très facile de dumper et redimensionner la partition USER (le résultat sort dans un fichier à restaurer ensuite et on peut directement redimensionner soit la RAWNAND ou soit le dump complet de l'emunand) donc la partie obligatoire du passage par Linux ou Mac ne l'est plus au final.

PS: J'ai ajouté un lien vers ce tuto dans mon tuto avancé sur l'emummc d'Atmosphere.

En effet, NxNandManager offre une solution plus facile pour redimensionner la NAND.

Soit en passant par Ultimate Switch Hack Script en version CLI.

Soit en utilisant NxNandManager en version GUI :

- Ouvrir la NAND qu'on veut redimensionner

- Dans Options, choisir Resize NAND

- Renseigner la taille voulue pour la partition USER et le fichier de destination puis lancer le redimensionnement

// Tuto V3 :

Hello,

Voici l'explication compléte du redimensionnement de l'emummc partition de A à Z.

Dans ce tuto, j'utilise la commande "DD" également utilisable sous linux/mac.

L’exécutable windows se trouve ici : http://www.chrysocom...oads/dd-0.5.zip


Information I (Optionnel) - Composition emuMMC :

1 secteur = 512 octets

Boot0 : Offset : 0 à 3FFFFF
Boot0 : Secteur 0x2000 (0x0000-0x1FFF) = 8192
Taille : 8192 x 512 = 4194304 o = 4096 Ko = 4 Mo

Boot1 : Offset : 0 à 3FFFFF
Boot1 : Secteur 0x2000 (0x2000-0x3FFF) = 8192
Taille : 8192 x 512 = 4194304 o = 4096 Ko = 4 Mo

Rawnand : Offset : 0 à 747BFFFFF
Rawnand : Secteur 0x03A3E000 (0x00000000-0x03A3DFFF) = 61071360
Taille : 61071360 x 512 = 31268536320 o = 30535680 Ko = 29820 Mo

Emummc : Offset 0 à 7483FFFFF
Emummc : Secteur  0x03A42000 (0x00000000-0x03A41FFF) = 61087744
Taille : 61087744 x 512 = 31276924928 o = 30543872 Ko = 29828 Mo

Composition emummc :
= Boot0 : Offset 0 à 3FFFFF // Secteur 0 à 8191
+ Boot1 : Offset 400000 à 7FFFFF // Secteur 8192 à 16383
+ Rawnand Offset 800000 à 7483FFFFF // Secteur 16384 à 61087743

Information II (Optionnel) - Composition de la Partition emuMMC :

Lors de la création de l'emuMMC en mode partition (par hetake), ce dernier laisse un "tampon" avant le commencement de l'emuMMC.

il faut donc le prendre en compte lors de la création de la partition et ne pas juste créer une partition de la taille de l'emuMMC !!!

// Partition emuMMC (0xe0) :

Taille par défaut :61120512 secteurs x 512 = 31293702144 o = 30560256 ko = 29844 Mo
= Tampon : 32768 secteurs
Taille Tampon : 32768 x 512 = 16777216 o = 16384 ko = 16 Mo
+ emummc : 61087744 x 512 = 31276924928 o = 30543872 Ko = 29828 Mo
 

I - Sauvegardes des jeux :

Attention : Lors de la manipulation du redimensionnement et/ou du déplacement de l'emuMMC, l'emplacement physique des sauvegardes va être modifié et certaine peuvent se retrouver effacé, ou corrompu.

En résultera une erreur au lancement des jeux après déplacement / redimensionnement.

1) Utiliser l'homebrow Checkpoint et faire une sauvegarde de tous les jeux.

Note :si les jeux installé n'ont pas été lancé au moins une fois : l'homebrow crash.

2) Effacer les sauvegarde la console (celle de la partition user) et conserver celle créer dans sd:\\switch\checkpoint\

3) A la fin des manipulations du tuto : Réintégrer les sauvegardes via chekpoint (si besoin en lançant les jeux au préalable)

II a - Nouveau emuMMC (sysnand) :

Dans le cas de la création d'une nouvelle emuMMC (basé sur Sysnand).

1) Soit :

- passer par la switch et payload hekate pour faire le backup sysnand

- mettre la carte µSD dans le PC et l'ouvrir avec NxNandManager 3

2) Récupérer les backups de la carte µSD puis fusionner les fichiers avec la commande :

copy /b BOOT0+BOOT1+rawnand.bin.* emummc.bin

_

Information III (Optionnel) - séparation de l'emuMMC (boot0 + boot1 + rawnand) :

En cas de besoin l'emuMMC peut toujours être séparé :

Mode "lent" (octet) :

dd bs=1c count=4194304 if=emummc.bin of=boot0.bin --progress
dd bs=1c skip=4194304 count=4194304 if=emummc.bin of=boot1.bin --progress
dd bs=1c skip=8388608 count=31268536320 if=emummc.bin of=rawnand.bin --progress

Mode "moyen" (secteur) :

dd bs=512 count=8192 if=emummc.bin of=boot0.bin --progress
dd bs=512 skip=8192 count=8192 if=emummc.bin of=boot1.bin --progress
dd bs=512 skip=16384 count=61071360 if=emummc.bin of=rawnand.bin --progress

Mode "rapide" (ko) :

dd bs=4096k count=1 if=emummc.bin of=boot0.bin --progress
dd bs=4096k skip=1 count=1 if=emummc.bin of=boot1.bin --progress
dd bs=4096k skip=2 count=7455 if=emummc.bin of=rawnand.bin --progress

_

II b - Backup emuMMC (déjà existant) :

1) Sur la carte SD : ouvir le fichier (original) : SD:\\emuMMC\emummc.ini

2) Récupérer le secteur de départ de l'emunand (ou emuMMC) en hexa :
Exemple sur une 128go : sector=0xae88000

3) Convertir le secteur hexadécimale en décimale
Par exemple : http://sebastienguil...vertisseur.html
ae88000 (le 0x n'as pas d'incidence) => 183009280

4) Identifier la sd :
- soit via le gestionnaire de périphérique
- soit un outil de partitionnement tel que "MiniTool Partition Wizard" (que je recommande)
- soit avec la commande DD (téléchargé au début du tuto) :

 dd --list

_

Dans mon exemple la sd est \\?\Device\Harddisk5

5) Backup emuMMC : Ligne de commande DD :

Secteur de départ d'emuMMC : 183009280
Nombre de secteur d'emuMMC : 61087744

Attention la commande (pourtant logique) suivante ne fonctionnent pas avec une carte sd ou clé usb :

dd bs=512 skip=183009280 count=61087744 if=\\?\Device\Harddisk5 of=emummc.bin --progress

Il faut utiliser à la place :

dd bs=512 skip=183009280 count=61087744 if=\\.\physicaldrive5 of=emummc.bin --progress

Note : "5" étant le numéro de la partition trouvé à l'étape II b 4.

6) Backup emuMMC : copie rapide :

Pour passer au mode "rapide" (vu en partie Information III), on peux diviser le nombre de secteur par 8192.

Secteur de départ d'emuMMC : 183009280 / 8192 = 22340
Nombre de secteur d'emuMMC : 61087744 / 8192 = 7457

Taille du bloc de copie : 512 x 8192 / 1024 = 4096

dd bs=4096k skip=22340 count=7457 if=\\.\physicaldrive5 of=emummc.bin --progress

_

Attention ! : ce mode "rapide" nécessite un nombre entier !

Si on tombe sur un nombre à virgule, on peux rediviser successivement par 2, jusqu’à un entier.

Exemple : 19E2F000 = 434302976

434302976 / 8192 = 53015,5 => Fail

434302976 / 4096 (8192 / 2) = 106031 => ok donc on peux continuer (sinon on redivise 2048,1024 etc...)

61087744 / 4096 =14914

Taille du bloc de copie : 512 x 4096 / 1024 = 2048

dd bs=2048k skip=106031 count=14914 if=\\.\physicaldrive5 of=emuMMC.bin --progress

_

Information IV (Optionnel) - Départ de la partition :

Comme évoqué en partie "information II", le secteur de départ de la partition peut-être trouvé :

1) Dans les propriété de la partition via un outil comme "Partition Wizard".

2) Si on soustrait le tampon du secteur de départ emummc (trouvé en partie II b 3)

183009280 - 32768 = 182976512
Secteur de départ de partition initiale : 182976512

III - Resize user : V2 - NxNandManager

MAJ : la toute nouvelle version de NxNandManager, permet d'effectuer cette étape, très simplement et sous windows [merci à eliboa].

L'ensemble du tuto est donc désormais faisable sous windows .

Note : Je laisse disponible l'ancienne méthode tout en bas du tuto pour ceux qui serait intéressé !

1) Télécharger NxNandManager 3

2)  Ouvrir la NAND qu'on veut redimensionner

3) Dans Options, charger le fichier clé de la console (récupéré via payload Lockpick_RCM)

4) Dans Tools, choisir Resize NAND

5) Renseigner la taille voulue pour la partition USER et le fichier de destination puis lancer le redimensionnement

IV - Restauration / Migration carte SD :

A présent que nous avons l'emunand resize, il faut l'écrire sur la carte SD, et cela pas au même endroit qu'elle était au départ...

Ce qui permet également d'effectuer une migration vers une carte SD de plus grande capacité .

0) Dans le cas d'un changement de carte SD :

Créer la partition fat32 : taille = {total carte sd} - {partition emummc}*

* Non obligatoire mais pour rappel {partition emummc} = tampon (voir partie "Information II") + emummc (resize ou non)

1) Avec l'outil de votre choix, on supprime l'ancienne partition emmuMMC (elle peut être "non formaté" ou dans un système "other" selon la méthode de création initiale)

2) On créer une partition de la taille de l'emunand resize, puis on réattribue l'espace gagné à la FAT32.

3) Optionnel : Pour respecter le tampon vu partie "Information II et IV" :
On fait donc l'opération inverse avec le secteur de la nouvelle partition resize :

Secteur de départ de partition resize : 216530944
Tampon : 32768
Secteur de départ emunand resize : 216530944 + 32768 = 216563712
Conversion en hexa : 216563712 : ce88000

4) Optionnel :Si on veux respecter encore plus le mode de création de hekate, on peux modifier le type de partition (toujours avec partition wizard).

0x7 : Unformatted

0xe0 : Other (utilisé par hekate)

Note : sur certaine version de partition wizard, on ne peux pas saisir la lettre du type de partition, l'astuce consiste donc juste à saisir "99" (pour 0x99) et de faire "+" pour passer a A0 et "++++...."jusqu'a "e0"

5) Optionnel : pour vérifier qu'il n'y a pas d'erreur sur le secteur :
Numéro de secteur x 512 /1024 / 1024 / 1024 = Taille (Go) qu'on devrait avoir sur la FAT32 resize.
Exemple : 216530944 x 512 /1024 /1024 / 1024 = 103.25
J'ai bien désormais une partition FAT32 de 103Go.

6) Dans SD:\emuMMC\emummc.ini on renseigne :
sector=0xce88000

(uniquement pour la partition de mon exemple bien sur... mettre vos propres valeurs).

7) Et enfin, on renomme et écrit l'emunand (emummc) resize :
 

dd bs=512 seek={nouveau_secteur_de_depart_emunand} if=emummc.bin of=\\.\physicaldriveX --progress

_

Attention : idem qu'en partie "II B 5" certaine commande ne fonctionne pas :

dd bs=512 seek=216563712 if=emummc.bin of=\\?\Device\Harddisk5 --progress
dd bs=512 seek=32768 if=emummc.bin of=\\?\Device\Harddisk5\Partition1 --progress
dd bs=512 seek=32768 if=emummc.bin of=\\?\Device\HarddiskVolume8 --progress

_

Exemple fonctionnel :

dd bs=512 seek=216563712 if=emummc.bin of=\\.\physicaldrive5 --progress

Si quelqu'un se pose la question, le seek est bien de 216563712 (dans mon exemple) et non pas de 216563712 -1 = 216563711.
On pourrait effectivement se dire que le secteur de départ de l'emunand étant 216563712 on doit "sauter" 216563711 secteurs... Seulement le disque commence au secteur 0 et non 1, du coup le secteur de départ de l'emunand est bien 216563712 mais c'est le 216563713 ème secteur du disque et donc on "saute" bien 216563712 (de 0 à 216563711).

Comme en partie "II b 6", on peux accélérer l'écriture : 216563712 / 8192 = 26436

dd bs=4096k seek=26436 if=emummc.bin of=\\.\physicaldrive5 --progress

_

8) Optionnel : vérification
On peux vérifier (avec un éditeur hexa) que l'emuMMC commence bien au secteur 216563712.
Note : il y a 1 secteur "vide" au début de l'emuMMC, donc les datas commencent à 216563712 + 1 = 216563713 (ou 216563714 eme secteur).

9) Si on à migré la carte SD et donc effectué l'étape "IV - 0" :

Attention : cette étape dois être impérativement réalisé AVANT le moindre boot Atmosphere sur la console !!! (sinon il faudrat tout réinstaller)

- Copier l'intégralité du contenu de la partition Fat32 de l'ancienne carte SD vers la partition FAT32 de la nouvelle carte SD à l'exception du fichier emummc.ini (SD:\\emuMMC\emummc.ini).

Note : Passer par une copie intermédiaire sur le PC si on possède 1 seul lecteur de carte.

V - Conclusion :

On peux même réduire beaucoup plus sans problème, j'ai testé avec user 3Go.

@ bientôt ^^

----------

Obsolète :

III - Resize user : V1 - Script python linux/mac only

Pour resize la partition User, j'utilise le script de ce "tuto" :
http://www.logic-sun...mmc-atmosphere/

Disponible ici :
https://gist.github....75f2720a1e5e486

Basé cette source :

https://pastebin.com/vPY4HLdV

Attention : contrairement au tuto et malgré mes très nombreuses tentatives il m'a été impossible de le faire fonctionner sous windows.
Il faudra donc passer sur un PC linux ou une machine virtuel pour cette étape :/.

1) Placer le script "resize-user.py", "emummc.bin" et "prod.keys" dans un dossier.

2) Puis exécuter successivement :

sudo su
apt update
apt install python3
apt install python3-pip
apt upgrade python3-pip
pip3 install --upgrade pip
pip3 install --upgrade setuptools
pip3 install -U python-mbedtls
sudo chmod 777 *
sudo python3 resize-user.py emummc.bin X prod.keys

X étant le nombre de Go souhaitez pour la partition user.

Sera ajouté à cette taille + 2.6 Go des autres partitions (system, etc.)