[Switch] - SX Core/Lite ou HWFly, tout se qu'il faut savoir
On va ici tenter de résumer les diverses infos concernant le fonctionnement des puces SX Core/Lite et HWFly selon les différents modèles de consoles sur lesquelles elles peuvent être posées.
De base, la puce recherche le fichier "boot.dat" à la racine de la SD et tente de l'exécuter. Ce fichier ne peut être que le "boot.dat" de SXOS ou celui du SX Gear.
Avec ce firmware, la console recherche un payload nommé "payload.bin" placé à la racine de la SD et tentera de le lancer. Personnellement, je recommande d'utiliser Hekate comme payload de lancement car il permettra ensuite d'avoir accès aux payloads placés dans le dossier "bootloader\payloads" sur la SD.
Attention: Avec le firmware Spacecraft, la licence SXOS livrée avec la puce SX Core/Lite ne fonctionnera plus.
En maintenant le bouton "volume +" de la console au démarrage du premier menu de SXOS, un menu apparaitra. Outre la possibilité de lancer le CFW ce menu contient un menu "options" qui est très pratique (permet de dumper la nand, de créer une emunand ou encore de lancer un payload placé à la racine de la SD).
Pour lancer un payload il faut donc passer par ce menu d'options puis pour les consoles Erista uniquement aller dans le menu "SX Core" et faire "Clean Up" et accepter de faire le nettoyage et enfin revenir une fois en arrière, aller dans les payloads et lancer le payload souhaité. La phase "Clean Up" est très importante et à faire à chaque fois que la console est redémarrée grâce à la puce sur les consoles Erista qui peuvent facilement griller des Efuses si cette étape n'est pas respectée.
Note: Pour les consoles Mariko c'est un peu différent, la phase "clean up" doit être faite une fois puis lancer Hekate et enfin Atmosphere. Normalement cela ne fonctionnera pas donc il faut éteindre la console, mettre en place les fichiers du SX Gear pour lancer Hekate au démarrage de la console et enfin lancer Atmosphere. J'ai encore des difficultés à identifier le fonctionnement exact de cette procédure mais il faut tenter ce genre de choses et essayer les différentes façons de lancer Atmosphere, une fois que ça passe ça fonctionnera sans problème.
Personnellement, le seul payload que je conseil de lancer via cette méthode est Hekate puis ensuite de lancer le payload voulu (pour rappel les payloads sont à mettre dans le dossier "bootloader\payloads") car SXOS a une façon de lancer les payloads qui peut souvent causer des problèmes, par exemple Lockpick-RCM fonctionne souvent mal en le lançant via SXOS directement et Atmosphere à partir de la version 0.20.0 pose aussi des soucis.
Note pour les consoles Mariko: Sur ces consoles le redémarrage à chaud sur un payload n'est pas possible (on ne peut par exemple pas utiliser le homebrew Payload_launcher), de fait certains homebrews ne fonctionneront pas pour lancer un payload avec ces versions de consoles (par exemple Haku33, il faut donc utiliser des techniques un peu détournées comme expliqué sur ce sujet.
Ici nous avons donc le fichier "boot.dat" qui remplace celui de SXOS qui est lié à un fichier "boot.ini" qui contient le chemin du payload à lancer, par défaut il s'agit du payload nommé "payload.bin" et placé à la racine de la SD.
Pour utiliser cette méthode de lancement, remplacer les fichiers sur la SD pour mettre en place les fichiers du SX Gear, ni plus ni moins. Une fois cela fait le payload pointé par le fichier "boot.ini" se lancera.
Comme pour la section concernant le lancement de payload, je conseil d'utiliser Hekate au lancement puis de lancer le payload souhaité (voir la section de lancement de payloads de ce sujet pour plus de détails).
- Ne jamais activer l'auto-RCM.
- Ne pas utiliser ChoiDuJour-NX (à remplacer par Daybreak qui n'est lançable que via Atmosphere par contre), particulièrement pour les consoles Mariko pour lesquelles il pose des soucis avec la partition "BOOT0", empêchant Atmosphere de fonctionner correctement ensuite.
- Ne pas utiliser Incognito (méthode via Tinfoil, Incognito-RCM, Incognito ou encore NXNandManager) sur les consoles Mariko car cela brick la partition PRODINFO et empêche la console de démarrer. La seule méthode est, pour Atmosphere, d'utiliser le fichier "exosphere.ini" placé à la racine de la SD et de le configurer comme suit:
[exosphere]
blank_prodinfo_emummc=1
blank_prodinfo_sysmmc=1
- Pour les consoles Erista, ne pas faire le "Clean Up" avant de lancer autre chose que SXOS (à faire à chaque redémarrage de la console si celle-ci redémarre grâce à la puce), exception faite si vous avez flashé Spacecraft.
- Ne pas faire le dump de la nand et des clés.
- Ne pas utiliser d'emunand, ceci n'est pas obligatoire mais est très vivement recommandé (emunand via "hidden partition" recommandée).
- Ne pas lancer Android ou Linux sur une console Mariko, pour l'instant ces systèmes ne sont pas adaptés pour ces consoles et risquent d'endommager le matériel plus qu'autre chose.
Ici il est très probable qu'un bug d'Efuses se soit produit (en lançant un payload incorrectement par exemple), regardez donc avec Hekate le nombre d'Efuses grillés (menu "Console infos" puis "Fuses" et regarder le nombre contenu dans "burn fuses"). Si vous avez un nombre du genre "15 - 0" alors cela signifie que vous êtes en firmware 12.0.2 et ceci est normal, par contre si vous voyez un nombre du genre "15 - 10" alors un problème s'est produit et il est donc peu probable que vous puissiez un jour redémarrer la console en mode officiel (sauf en passant par l'option "stock" de Hekate, c'est pas parfait mais bon faute de mieux...
La solution ici est de refaire une partition BOOT0 adaptée aux consoles Mariko, par exemple à l'aide du logiciel EmmcHaccGen et des clés de la console puis de la flasher sur la nand.
Si ChoiDuJour-NX n'a été utilisé que sur l'emunand et que la sysnand se trouve sur le même firmware, il est possible de dumper le BOOT0 de la sysnand et de remplacer la partition BOOT0 de l'emunand par celui-ci.
Si aucune des solutions ci-dessus n'a fonctionné, il faudra trouver un dump de BOOT0 d'une console Mariko sur le firmware à lancer pour le remplacer.
Ici on va partir du fait que la nand est totalement HS et qu'aucun dump n'est à disposition, si vous avez certains des éléments certaines choses ne sont donc pas à faire ou peuvent un peu différer.
Bon déjà, il faut savoir que la console ne pourra plus jamais se connecter aux serveurs de Nintendo car le PRODINFO est perdu.
Commençons par le dump des clés, le mieux étant de posséder une autre console sur un firmware supérieur ou égal au firmware 7.0.0 et du même type que la console ciblé (Erista pour Erista, Mariko pour Mariko car si on inverse ça risque de ne pas fonctionner correctement). Si vous en possédez une, mettre la nand de l'autre console sur la console à réparer et dumper les clés via Lockpick-RCM (ne pas oublier le "Clean Up" sur les consoles Erista avant de lancer le payload et passer par Hekate si passage via le menu de SXOS). Si vous n'avez pas d'autre console à disposition, il faudra générer un firmware supérieur ou égal au firmware 7.0.0 grâce à EmmcHaccGen (attention à bien générer des firmwares pour le type de console ciblé) puis flasher les partitions "BOOT0", "BOOT1" et les partitions "BCPKG*" sur la nand (ces partitions ne nécessitent pas de clés car elles ne sont pas chiffrés) puis dumper les clés (même règles sur le "Clean Up" qu'énoncées un peu avant). Je ne détaillerai pas comment flasher ces éléments, regardez le Github de Hekate pour savoir comment faire.
Une fois les clés dumpées le débrickage se passe comme pour n'importe quel autre console, par exemple via
cette méthode (attention encore une fois à bien générer un firmware pour le type de console ciblé) et un firmware égal à celui se trouvant sur la nand qui a servie à dumper les clés (cette seconde condition ne semble pas obligatoire mais je n'ai pas pu faire de tests assez avancés pour éliminer totalement ceci, la chose certaine est qu'il faut flasher un firmware supérieur ou égal au firmware 7.0.0). Un autre point qui diffère, Memloader ne fonctionne pas sur ces consoles donc on pourra utiliser TegraExplorer pour copier les fichiers au bon endroit sur la nand.
Si les clés posent un souci, là l'opération est plus délicate car il faut avoir un dump d'une nand déchiffrée, le chiffrer avec les bonnes clés et enfin le réinjecter puis effectuer l'étape précédente. Dans ce cas et si on a plus le PRODINFO original de la console (autrement il suffit juste de le réinjecter sur la nand), il y a également autre chose à faire, regénérer un PRODINFO pour la console grâce au payload ProdinfoGen. Pour cela on a donc deux possibilités:
- Si on dispose d'un PRODINFO doneur (par exemple celui d'une console déjà bannie), on le déchiffre puis on le renomme "donor_prodinfo.bin" et on le met dans le dossier "switch" de la SD (si le PRODINFO donneur provient d'une console Mariko il faudra aussi les clés de la console donneuse, le fichier est à nommer "donor.keys" et est aussi à placer dans le dossier "switch"); on y mettra également le fichier "prod.keys" de la console à débricker s'il ne s'y trouve plus. On lance le payload ProdinfoGen puis on utilise l'option "Generate from donor". Si tout se passe bien, un fichier "generated_prodinfo_from_donor.bin" est créé, on le chiffre avec les clés de la console et on le réinjecte sur la nand.
- Si on ne dispose pas d'un PRODINFO donneur, on mettra juste le fichier "prod.keys" de la console à débricker dans le dossier "switch", on lance le payload ProdinfoGen, on utilise l'option "Generate from scratch", on chiffre le fichier "generated_prodinfo_from_scratch.bin" généré par le payload avec les clés de la console et enfin on injecte ce fichier sur la nand.
Je rappel que pour beaucoup de ces actions vous pouvez utiliser
l'Ultimate-Switch-Hack-Script (peut créer un firmware avec EmmcHaccGen facilement, chiffrer/déchiffrer une nand ou parties d'une nand, etc...).
Si un problème survient, par exemple durant le flashage du firmware Spacecraft (voir
cette page pour plus d'infos sur ce firmware, la puce peut être totalement brickée (d'ailleurs merci le connecteur USB tout pourrit de la puce).
Pour l'instant je ne vais donner que les sujets en anglais car je n'ai pas encore testé par moi-même, on a donc
ce sujet qui contient des infos intéressantes et
cette vidéo.
Je rappel que je n'indique ici que se qui diffère entre une console équipées d'une puce SX Core/Lite d'une console non patchée non équipée d'une puce SX Core, pour le reste cela fonctionne de la même façon donc les infos de
la FAQ ou de
ces infos de base restent globalement valables, notamment celles concernant la création d'une emunand ou l'installation d'Atmosphere ou d'installation de contenus.
Pour les anglophones, voici
cette page qui explique comment installer Atmosphere selon différentes configurations possibles.
