[Switch] - composition du hack Switch
Cette page a pour but d'expliquer les différents types d'éléments que l'on retrouve dans le hack Switch, du payload aux homebrews en passant par le CFW, les modules, les overlays et certaines autres choses plus spécifiques.
Le payload est un fichier dont le nom se termine par ".bin" et est la première chose qu'on lance ou qui est lancé. La plupart du temps c'est le payload Hekate qui est utilisé, celui-ci pouvant ensuite lancer d'autres payloads stockés sur la SD il est préférable d'en passer toujours par lui.
Un payload est un programme qui peut faire bien des choses différentes comme lancer un CFW, dumper les clés de la console, exécuter des scripts, etc... Un payload ne dispose pas d'une interface graphique très poussée en général et il vise un but très précis sans trop se disperser.
Comme exemple de payloads il y a donc Hekate, Fusee qui sert à lancer Atmosphere (officiellement on devrait toujours le lancer via ce payload, cependant Hekate utilise une façon alternative de lancer Atmosphere qui permet de configurer plus précisément son lancement se qui peut parfois être très pratique), TegraExplorer qui permet d'exécuter des scripts et aussi de dumper le firmware ou de formater la SD ou encore de dumper le firmware de la nand, Lockpick-RCM qui est uttilisé pour dumper les clés de la console se qui peut être très utile pour faire certaines réparations comme un débrickage, Incognito-RCM qui sert à supprimer les éléments permettant d'identifier la console dans le PRODINFO. Il existe d'autres payloads mais ceux-ci sont les principaux que l'on retrouve souvent.
Aujourd'hui Atmosphere est le seul CFW existant sur Switch. Il est constitué de différentes parties dont un payload pour le lancer, son noyau ainsi que des modules. Maintenant il intègre même certains homebrews comme Daybreak qui sert à mettre à jour le firmware.
Il est à savoir qu'Atmosphere ne permet pas de lancer du contenu piraté, il est nécessaire d'y ajouter des patches spécifiques pour contourner ces protections, ces patches sont appelés sig_patches, je ne rentrerai pas plus dans le détail sur ce point.
Associé au Homebrew Loader qui est un module spécifique permettant de charger les homebrews et au Homebrew Menu qui est un homebrew spécifique permettant d'avoir une interface avec le Homebrew Loader pour lancer les homebrews de manière conviviale Atmosphere permet donc d'exécuter différents homebrews. De la même façon pour lancer les overlays on a le module Nx-ovlloader et l'overlay TeslaMenu.
L'emunand est une image de la nand indépendante de celle-ci et elle se trouve sur la SD (on pourrait la mettre sur la nand mais bon l'intérêt resterai limité).
La nand d'une Switch se compose de trois grandes parties , celles gérant le démarrage qui sont les parties BOOT0 et BOOT1 et la troisième partie, la plus grosse que l'on nomme RAWNAND ou RAW_EMMC ou GPP_RAW_EMMC, qui se compose de différente partitions (certaines chiffrés par les clés de la console nommées bis_keys que l'on peut récupérer avec Lockpick-RCM et d'autres non). Les partitions les plus importantes sont PRODINFO (contient les informations permettant d'identifier la console), SYSTEM qui contient le firmware de la console ainsi que les profiles et autres paramètres de la console et enfin la partition USER qui contient les jeux installés sur la nand, les captures d'écran si celles-ci ne sont pas redirigé sur la SD et les sauvegardes des jeux. Enfin un dossier "nintendo" se trouvant sur la SD sert à installer des jeux sur la SD ainsi qu'à stocker les captures d'écran si celle-ci sont redirigées sur la SD.
L'emunand c'est la même chose, elle se constitue des mêmes éléments, qu'elle soit via partition ou via fichiers. Via partition les trois parties de la nand sont écrites à la suite sur cette partition et en mode fichier on aura au moins trois fichiers représentant les trois parties de la nand. Et dans tous les cas on aura aussi un dossier ayant la même fonction que le dossier nintendo de la nand (il sera placé dans un chemin différent du dossier "nintendo" à la racine de la SD utilisé par la nand, mixer les deux ne doit jamais être fait). Et tout ceci est indiqué à Atmosphere dans le fichier "emummc/emummc.ini".
Pour en savoir plus sur l'emunand vous pouvez consulter cette page sur le fonctionnement de l'emunand d'Atmosphere qui détail notamment la façon de fonctionner du fichier "emummc/emummc.ini".
Ils peuvent s'apparenter aux services d'un système d'exploitation. Un module peut s'exécuter dès le démarrage du CFW et se terminer ensuite (par exemple Sys-patch ou Bootsound-NX), s'exécuter automatiquement en permanence (par exemple MissionControl, Sys-CLK, Ldn_mitm) ou encore s'exécuter lorsqu'on en a besoin (par exemple Emuiibo).
Les modules peuvent donc remplir beaucoup de tâches différentes et il faudra souvent se référer aux instructions du projet en question pour savoir exactement comment il fonctionne. Un module peut s'interfacer avec un homebrew et/ou un overlay qui permettra de le configurer.
Les modules étant par défaut lancés automatiquement au lancement du CFW ils sont souvent responsables des erreurs au démarrage de celui-ci, souvent lors d'une mise à jour firmware ou d'Atmosphere rendant incompatible le module qui provoque donc une erreur. Les modules sont situés dans le dossier "atmosphere/contents", ils ont un numéro à seize chiffres hexadécimaux en guise de nom de dossier et le dossier contient au moins un fichier nommé "exefs.nsp" qui est le module en question (un dossier "flags" contenant un fichier servant à donner des instructions sur le moment d'exécution du module et un fichier "toolbox.json" servant à identifier le module peuvent se trouver dans le dossier du module). En cas d'erreur au démarrage du CFW (après le second logo en général durant se qui correspond au logo "Nintendo Switch" donc juste avant que le système soit accessible) il est indiqué un TitleID qui peut correspondre à un module, dans ce cas il faut chercher ce nom de dossier dans le dossier "atmosphere/contents" et le déplacer ou le supprimer pour régler le problème si le module n'a pas eu de mise à jour bien sûr.
Il existe d'autres façons d'exécuter des modules (via des fichiers se terminant par ".kip") mais celles-ci n'étant plus standards elles ne seront pas abordés ici.
Les homebrews sont des fichiers qui se terminent par ".nro", se sont des programmes que l'on exécute lorsqu'on en a besoin et ils peuvent couvrir une multitudes de fonctions (émulateur, lecteur vidéo, lecteur d’e-book, mise à jour du firmware, dump d'une cartouche, installation de contenus, etc...).
Par défaut Atmosphere est accompagné des fichiers "atmosphere/hbl.nsp" qui est le module Homebrew Loader permettant de charger un homebrew et le fichier "hbmenu.nro" qui est le homebrew permettant de pouvoir choisir le homebrew que l'on souhaite lancer. Par défaut on peut accéder au Homebrew Menu de différentes façons, la première et la moins recommandée est de passer par l'album du menu principal de la Switch (mode applet, les homebrew ne profitent pas de toutes la ram de la console donc certains homebrews ne fonctionneront pas ou fonctionneront mal si on les exécute de cette façon), la seconde façon est de lancer un jeu en maintenant le bouton "R" et la troisième est d'installer un NSP contenant le Homebrew Loader. Voici se qu'il se passe lorsqu'on lance un homebrew:
- On lance le Homebrew Menu de la façon souhaité, en réalité on appel le Homebrew Loader sans paramètre et celui-ci est dans ce cas configuré pour lancer le homebrew (hbmenu.nro" situé à la racine de la SD donc le Homebrew Menu se lance.
- On choisi le homebrew à lancer, cette fois le Homebrew Loader est appelé avec un paramètre contenant le chemin du homebrew à lancer.
- Par défaut lorsqu'on quitte un homebrew celui-ci nous renvoi vers le Homebrew Menu et le cycle continue ainsi jusqu'à se qu'on quitte le Homebrew Menu.
La façon de lancer le Homebrew Loader peut être configuré dans les fichiers de configuration d'Atmosphere, via le fichier "atmosphere/config/override_config.ini" (on trouve un exemple de ce fichier ainsi que des autres fichiers de configuration d'Atmosphere dans le dossier "atmosphere/config_templates").
Par principe les homebrews se trouvent dans le dossier "switch", soit à la racine de ce dossier ou soit dans un dossier portant le nom du nro à lancer (par exemple un homebrew "test.nro" peut être placé dans un dossier "test" du dossier "switch", personnellement c'est cette configuration que je recommande). Pour les fichiers pouvant servir de paramètres au homebrew il peuvent se trouver dans le dossier du homebrew ou dans le dossier "config/nom_du_homebrew", cette seconde façon de faire semble devenir la convention mais n'a rien d'obligatoire.
Se sont en fait des homebrews mais conçus pour une interface spécifique qui est rapide d'accès. Lorsque le module Nx-overlay et l'overlay TeslaMenu sont en place alors on accède à l'interface permettant de lancer nos overlays avec la combinaison de touches "L+R3+flèche bas".
Un overlay est un fichier se terminant par ".ovl" et est à placer dans le dossier "switch/.overlays". Pour le reste ils peuvent, comme les homebrews, remplir tout un tas de fonctions et ils servent souvent à paramétrer des modules comme Emuiibo par exemple mais cela peut aussi servir à activer/désactiver les cheats pour un jeu avec l'overlay Edizon_overlay.
La combinaison de touches pour lancer le menu des overlays peut être configurée dans le fichier "config/tesla/config.ini" mais il n'est pas recomandé d'y toucher et ce fichier n'est pas livré avec le module ni le menu des overlays donc ceci ne sera pas plus développé ici.
C'est un module un peu particulier avec son système de plugins, moins utilisé que les overlays il y a tout de même certaines fonctions intéressantes comme le plugin permettant d'augmenter les FPS d'un jeu.
Comme je ne connait pas bien ce module je ne développerai pas plus cela ici.
Via Hekate il est possible d'installer et d'exécuter Android ou Linux. Ceci nécessite des étapes particulières d'installations et de mises en place qui peuvent, avec pas mal d'efforts, se coupler à l'emunand et tout ce petit monde peut se côtoyer mais là il faudra faire pas mal de choses manuellement.
Lors du lancement d'Android ou de Linux Hekate lance un "payload" qui va chercher dans certains fichiers de configuration de l'OS à lancer la ou les partitions à lancer pour le système puis le système s'exécute de manière indépendante au système de Nintendo.
