Aller au contenu


shadow256

Inscrit(e) (le) 05 juin 2015
Déconnecté Dernière activité aujourd'hui, 16:08
*****

Sujets que j'ai initiés

[tuto avancé] - Emunand Atmosphere, tout se qu'il faut savoir

16 juin 2019 - 18:38

Bonjour,

Ce sujet va servir à centraliser le maximum d'infos sur le fonctionnement de l'emunand d'Atmosphere apparu avec la version 0.9.0 de celui-ci (utilisé via Fusee Primary ou via Hekate). Si vous avez des infos ou des corrections à proposer, n'hésitez pas à m'en faire part via ce sujet et j'ajouterai/corrigerai tout cela dans ce premier message.

Note: L'emunand via fichiers est bien plus lente que l'emunand via partition, ceci sera corrigé dans une futur version d'Atmosphere. Pour l'emunand via fichiers en FAT32, la SD doit être formatée avec des clusters de 32K.

Note 2: Pour redimensionner la partition USER et avoir pas mal d'infos intéressante sur l'emunand via partition plus particulièrement, voir ce sujet dans lequel les choses sont plutôt bien résumées.

Pour tester les dernières versions compilées d'Atmosphere, voir cette page. Je met également à disposition ce projet Github sur lequel je compilerai la dernière version d'Atmosphere le plus régulièrement possible, le projet ressemble clairement à une release officiel d'Atmosphere. Pour récupérer la dernière version, il suffit de cliquer sur ce lien. Voilà, maintenant je pense qu'on est équipé pour les tests.

Avant de commencer, merci à tous les participants qui ont aidés ou fait des tests pour faire des retours sur ce sujet.

0: Prés-requis:

On doit disposer d'un dump complet de la nand contenant donc les fichiers "BOOT0", "BOOT1" et "rawnand.bin" (ce dernier peut être splitté en plusieurs parties, d'ailleurs ceci est plutôt conseillé pour éviter des soucis de compatibilité entre le FAT32 et l'EXFAT, le fichier peut donc être au minimum splitté en 8 parties). Dans mon Ultimate Switch Hack Script, une fonction permet de splitter un dump de nand non splitté assez simplement. Pour savoir comment récupérer ces fichiers, vous pouvez consulter ce tuto qui utilise Hekate ou ce tuto qui utilise NXNandManager (dump possible sans nécessiter ni SD ni Hekate).

1: Méthodes pour Fusee Primary:

1.1: Emunand via fichiers:

Une fois les fichiers nécessaires acquis, créer un dossier sur la SD, préférablement en lui donnant un nom sans espace ni caractères spéciaux. Par contre, ce dossier peut aussi se trouver dans des sous-dossiers mais encore une fois, éviter les espaces et caractères spéciaux dans les noms. Pour l'exemple, on va dire que le dossier sera "emummc/8.0.1".

Une fois le dossier créé, créer un dossier "eMMC" (sans les guillemets et bien respecter les majuscules et minuscules) et y mettre les fichiers du dump à l'intérieur de celui-ci. Le dossier "eMMC" créé devra donc au moins contenir le fichier "boot0", "boot1" et "00", si le dump de la rawnand n'est pas splitté, il faudra tout de même le nommer "00" et si le dump est splitté, la suite des fichiers devra être nommé "01", "02", etc...

Une fois cela mis en place, il faut appliquer l'attribut d'archive au dossier "eMMC", pour se faire on peut faire un clique droit sur le dossier et cocher la case "archive" puis cliquer sur "OK" ou alors on peut aussi utiliser la commande "attrib +a chemin_du_dossier" pour ceux qui préfèrent la ligne de commandes. Notez que ceci n'est pas obligatoire car Atmosphere semble s'en occuper lui-même si cela n'est pas fait.

Enfin, il ne reste plus qu'à configurer le fichier "emummc/emummc.ini" avec les valeurs adéquat, voir la suite pour plus d'infos sur la structure de ce fichier.

1.2: Emunand via partitions:

1.2.1: Création via Linux (recommandé):

Merci à @Linkynimes et à @Thetoto pour les infos.

Partitioner la carte sd en 2 partition, la première c'est la principale en fat32/exfat, la seconde de 32go (un peu plus pour être sur). Faut bien cet ordre sinon ça ne boot pas... Il faut également des partitions principales et pas des partitions logiques. Pour configurer la SD correctement, Gparted fera parfaitement le travail.

Ensuite on assemble tout les fichiers du dump de la nand dans un seul fichier:
cat BOOT0 BOOT1 rawnand.bin > emunand.bin

Ou si on a une rawnand en plusieurs parties:
cat BOOT0 BOOT1 rawnand.bin.* > emunand.bin

Ensuite on copie le fichier créé grâce à dd sur la partition physique dédiée à l'emunand sur la SD, /dev/sdXN étant la partition de 32 go:
dd bs=4M if=emunand.bin of=/dev/sdXN status=progress && sync

Récupérer le secteur de début de la bonne partition avec fdisk, le convertir en hexadécimal. Moi j'ai çà :

sudo fdisk -l
Résultat de la commande:

Périphérique   Amorçage    Début       Fin Secteurs Taille Id Type
/dev/mmcblk0p1              2048  55009279 55007232  26,2G  b W95 FAT32
/dev/mmcblk0p2          55042048 122241023 67198976    32G  b W95 FAT32

Ma partition de 32GO c'est /dev/mmcblk0p2, le début c'est 55042048 -> en hex -> 0x347E000.

Enfin, faire le emummc/emummc.ini , un exemple avec le strict minimum:

[emummc]
enabled = 1
sector = 0x347E000 (ce qu'on a récup avec fdisk)


1.2.2: Création via Windows:

En suivant ce petit tuto, vous formaterez votre carte SD en supprimant tout ce qui y est enregistré. Assurez-vous de sauvegarder le contenu de votre carte SD au préalable. Formater le mauvais lecteur (lecteur PC) gâchera énormément les choses. Assurez-vous que vous savez quel lecteur est votre carte SD!

Connectez votre carte SD à votre PC.

Appuyez sur WIN + R et tapez diskmgmt.msc puis cliquez sur OK.

Localisez votre carte SD et supprimez toutes les partitions de ce disque (il ne devrait s'agir que d'une partition).

Faites un clic droit sur la carte SD et sélectionnez "Nouveau volume simple". Cliquez sur Suivant jusqu'à ce que vous puissiez définir la taille du volume.

Prenez le nombre suggéré et soustrayez 29828. utilisez le nombre obtenu comme taille pour le volume et créez-le. Vous vous retrouverez avec une partition au début et un espace non alloué à la fin.

Cliquez avec le bouton droit de la souris sur l'espace non alloué et sélectionnez "Nouveau volume simple". Cliquez sur Suivant, laissez la taille suggérée, puis, sélectionnez "Ne pas formater ce volume", puis terminez.

Nous avons maintenant nos 2 partitions, mais nous avons toujours besoin de formater notre première partition en FAT32 en utilisant guiformat.

Faites un clic droit sur le fichier guiformat et sélectionnez Démarrer en tant qu'administrateur.

Sous "Lecteur", sélectionnez la première partition que vous venez de créer (utilisez la lettre du lecteur pour formater le bon lecteur), sélectionnez la taille d'allocation 32768, cochez le formatage rapide et appuyez sur Démarrer.

Enfin, il est possible d'installer Msys 2.0 et de le lancer pour pouvoir suivre les instructions de la partie 1.2.1, c'est de loin la méthode la plus simple à faire.

2: Méthode via Hekate:

2.1: Emunand via fichiers:

Voir cette excellent tuto qui couvre l'ensemble de la méthode avec également la façon de lancer les exploits et comment mettre à jour l'emunand via ChoiDuJourNX, merci à @giga300. On a aussi ce tuto, ça couvre une bonne partie des choses.

2.2: Emunand via partitions:

Merci à @Linkynimes pour les infos.

En suivant ce petit tuto, vous formaterez votre carte SD en supprimant tout ce qui y est enregistré. Assurez-vous de sauvegarder le contenu de votre carte SD au préalable. Formater le mauvais lecteur (lecteur PC) gâchera énormément les choses. Assurez-vous que vous savez quel lecteur est votre carte SD!

Connectez votre carte SD à votre PC.

Appuyez sur WIN + R et tapez diskmgmt.msc puis cliquez sur OK.

Localisez votre carte SD et supprimez toutes les partitions de ce disque (il ne devrait s'agir que d'une partition).

Faites un clic droit sur la carte SD et sélectionnez "Nouveau volume simple". Cliquez sur Suivant jusqu'à ce que vous puissiez définir la taille du volume.

Prenez le nombre suggéré et soustrayez 29828. utilisez le nombre obtenu comme taille pour le volume et créez-le. Vous vous retrouverez avec une partition au début et un espace non alloué à la fin.

Cliquez avec le bouton droit de la souris sur l'espace non alloué et sélectionnez "Nouveau volume simple". Cliquez sur Suivant, laissez la taille suggérée, puis, sélectionnez "Ne pas formater ce volume", puis terminez.

Nous avons maintenant nos 2 partitions, mais nous avons toujours besoin de formater notre première partition en FAT32 en utilisant guiformat.

Faites un clic droit sur le fichier guiformat et sélectionnez Démarrer en tant qu'administrateur.

Sous "Lecteur", sélectionnez la première partition que vous venez de créer (utilisez la lettre du lecteur pour formater le bon lecteur), sélectionnez la taille d'allocation 32768, cochez le formatage rapide et appuyez sur Démarrer.

Placez tous vos fichiers atmosphere / hekate / NYX sur la première partition, car cette partition sera votre carte SD classique. La seconde partition deviendra votre emuMMC.

Enfin, démarrez Hekate 5.0 / NYX, sélectionnez emuMMC> Créer emuMMC> Partition SD> Continuer.

3: Le fichier "emummc/emummc.ini":

Note: Si Hekate est utilisé pour créer/manipuler l'emunand normalement il ne sera pas nécessaire d'éditer le fichier de configuration manuellement, Hekate se charge de le faire.

Ce fichier est un simple fichier texte qui peut être édité via le bloc-notes ou tout autre éditeur de texte, pour le créer simplement on peut se rendre dans le dossier "emummc" de la SD, faire un clique droit dans un espace ne contenant pas de fichier, dérouler le menu "nouveau" puis choisir "document texte". Attention tout de même car si l'option "masquer les extentions des fichiers dont le type est connu" de Windows est activée (se qui est le cas par défaut), le fichier n'aura pas le bon nom et donc ne sera pas détecté, veuillez donc désactiver cette option (une recherche sur internet devrait suffire à trouver comment faire cela). En ligne de commandes sinon, on peut créer simplement le fichier en tapant la ligne "copy nul lettre_de_la_sd:\emummc\emummc.ini" (ne pas copier les guillemets).

Voici la structure de base du fichier:











[emummc]
enabled =
id =
sector =
path =
nintendo_path =


Maintenant, décortiquons ligne par ligne:

[emummc]

Rien à dire de particulier, c'est juste l'indication de la section concernant la configuration de l'emunand.
 

enabled =

Ici, on défini si l'emunand est à activer ou non, 0 signifie que l'emunand est désactivée et 1 signifie que l'emunand est activée.
 

id =

Cette ligne sert à définir l'ID Hexadécimal de l'emunand (la valeur commence donc toujours par 0x), par exemple la ligne pourrait être, sans les guillemets, "id = 0x09AF" (quatre caractères max pour l'ID sont pris en compte).
 

sector =

Cette ligne sert à définir le secteur démarrant la partition contenant l'emunand si le choix de l'utilisation de ce type d'emunand a été fait. Cette valeur est également une valeur Hexadécimal et doit donc toujours commencer par 0x. Si l'utilisation d'une emunand via fichiers a été préférée, cette ligne doit ne pas figurer dans le fichier de configuration si tel est le cas ou bien elle peut commencer par un ";" (sans les guillemets), signifiant que la ligne est un commentaire et donc ne sera pas prise en compte.
 

path =

Cette ligne définie le chemin du dossier contenant le dossier "eMMC" qui lui-même contient les différentes parties du dump de la nand servant à démarrer l'Emunand, par exemple la valeur pourrait être, toujours sans les guillemets, "path = emummc/8.0.1". Si le choix d'une emunand via partition a été fait, cette ligne doit ne pas figurée dans le fichier de configuration ou doit être commentée avec un ";" (sans les guillemets).
 

nintendo_path =

Cette ligne sert à définir le dossier "nintendo" utilisé par l'emunand, par défaut ce dossier sera "emummc/Nintendo_XXXX" (XXXX sera remplacé par l'ID de l'emunand) mais il est aussi possible de définir le chemin que l'on souhaite, par exemple "emutendo".

4: Aller plus loin:

On a un tuto pour redimensionner la partition "USER" pour un dump utilisé pour l'emunand sur cette page.

Il est aussi possible d'avoir une emunand via partition compatible avec SX OS et Atmosphere en même temps, pour cela il faut créer l'emunand via partition avec SX OS (même pas besoin de la licence pour cela) puis, dans le fichier "emummc\emummc.ini" régler la valeur "enabled" sur "1", la valeur "sector" sur "0x2" et la valeur "nintendo_path" sur "emutendo". Voilà, une emunand via partition réglée simplement, sans prise de tête et compatible avec SX OS et Atmosphere, le meilleur des deux mondes est à vous (bien-sûre il faudra acheter la licence SX OS pour booter l'emunand via ce CFW).
Note: Une méthode alternative pour faire cette emunand compatible SX OS/Atmosphere est de créer l'emunand via partition via SX OS puis d'utiliser Hekate, aller dans "EmuMMc" puis d'utiliser l'option "migrate emummc" et se sera fait, merci à @Ochidoris pour le partage de cette méthode.

Pour info voici le contenu du fichier "emummc\emummc.ini" à avoir pour la dual emunand:

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

Voilà, si on le souhaite on peut rajouter le "id" mais il n'est pas obligatoire du tout.

[Switch] GCDumpTool 1.1.0

06 juin 2019 - 12:42

DarkMatterCore propose la version 1.1.0 du homebrew GCDumpTool, le homebrew open-sources permettant de copier le contenu des cartouches Switch.

Pas mal de grosses évolutions pour cette version, voici le changelog plutôt imposant de celle-ci:
  • Replaced the application icon with a new, stylish one made by RattletraPM. Thanks a lot!
  • Gamecard base application icons are now retrieved and displayed in the menu.
  • L/ZL/R/ZR buttons can now be used to change the displayed base application info if a multigame cart is inserted, instead of displaying everything right away.
  • The Nintendo Extension shared font is now used to display bitmaps representing controller buttons and sticks instead of just using text to reference them.
  • Replaced the mbedtls-based AES and SHA-256 implementations with functions from the hardware accelerated cryptography API from libnx.
  • Added an option to generate split XCI dumps using a directory with the archive bit set, just like split NSP dumps. It will only appear if "Split output dump" is enabled.
  • Fixed ETA calculation.
  • Enabled ETA calculation in full HFS0 partition data dumps.
  • Fixed CRC32 checksum calculation for gamecard certificate dumps.
  • Added Program NCA RomFS section parser:
    • Supports filesystem dumping, filesystem browsing, manual file dumping and file splitting. Enjoy datamining your gamecards!
    • Compatible with multigame carts. You'll be able to choose which base application RomFS will be dumped/browsed from a submenu.
    • Output files will be saved to: "sdmc:/[GameName] v[GameVersion] ([TitleID]) (RomFS)/".
  • Added high contrast directory/file icons from GNOME project to file browsing modes (HFS0 / RomFS).
  • Fixed the NSP generation code (based on 4NXCI / hacPack):
    • Delta Fragment NCAs are now discarded.
    • The SHA-256 checksum is recalculated for every NCA content after being modified, resulting in new NCA IDs.
    • The ACID public key is replaced in the NPDM section from the Program NCA. All the related NCA/PFS0 Superblock SHA-256 hashes are recalculated.
      • The NPDM signature in the Program NCA header is now replaced as well.
    • The content records from the Application CNMT are updated with proper SHA-256 hashes and new NCA IDs. All the related NCA/PFS0 Superblock hashes are recalculated.
    • NACP XMLs are now generated as well.
    • Because of all these changes, the CRC32 checksum can't be calculated until the dump procedure is complete.
      • If this option is enabled, the application will take extra time after the NSP dump has been completed to calculate the CRC32 checksum. Nonetheless, you'll be able to cancel this procedure.
      • A warning message will appear in the NSP dump menu if CRC32 checksum calculation is enabled to inform the user about this extra step.
      • Furthermore, the output CRC32 checksum will be different on each new dump. This is because the NPDM signature in the Program NCA header uses a random seed.
    • This effectively makes the generated NSPs only need ES patches to work. ACID patches shouldn't be needed anymore.
  • Added NSP dumping support for Patch and AddOnContent title types with gamecards that include bundled Updates/DLCs:
    • The information displayed in the main menu now shows how many Updates/DLCs are bundled in the inserted gamecard (per application and in total).
    • If a bundled gamecard update features a populated Rights ID bitfield, both its Ticket and Certificate will get added to the output NSP.
    • Additionally, the NSP dump menu has been divided in three subcategories: base application, update and DLC.
      • Each submenu will only appear if the inserted gamecard holds at least one title belonging to the category it represents.
      • If only the base application is included, like most gamecards, choosing the NSP dump option in the main menu will take you right to the base application dump menu.
      • Once you enter a submenu, you'll be able to choose exactly which title to dump belonging to that category.
    • Output update NSPs will not be modified in any way. Thus, unlike NSPs from base applications and DLCs, their CRC32 checksums will always be the same.
  • Fixed the minimum system version field size in the extended CNMT header struct. Thanks to @0Liam !
  • Changed the naming convention for output NSP dumps:
    • Base application: "sdmc:/[GameName] v[GameVersion] ([TitleID]) (BASE).nsp".
    • Update: "sdmc:/[GameName] v[UpdateVersion] ([UpdateTitleID]) (UPD).nsp".
      • If a matching base application isn't found: "sdmc:/[UpdateTitleID] v[UpdateVersion] (UPD).nsp".
    • DLC: "sdmc:/[GameName] v[DLCVersion] ([DLCTitleID]) (DLC).nsp".
      • If a matching base application isn't found: "sdmc:/[DLCTitleID] v[DLCVersion] (DLC).nsp".
  • The application is now able to retrieve the NCA header key and perform NCA key area decryption at runtime, using the SPL services. Thus, is isn't needed to run Lockpick beforehand anymore to dump NSPs (nor to dump/browse RomFS data).
  • If the inserted gamecard includes a bundled update, its version number will now be used in the output filename for XCI, HFS0 and gamecard certificate dumps.
  • Minor improvements to the file splitting code.
    • Additionally, the filename for the current part will now be displayed and updated for all operations if file splitting is enabled.
  • The application update feature will now use the launch path from argv if it's available. Otherwise, it defaults to "sdmc:/switch/gcdumptool.nro".
  • Cosmetic fixes to the UI layout.
  • NCM service resources are now properly closed.
  • Removed unnecessary service (de)initializations.
Big thanks to PatrickD85, unvaluablespace, wartutor and Slim45 for testing these changes!

Vous pouvez télécharger cette nouvelle version via cette page du projet Github.

Tuto - Dump/Restauration de la nand sans Hekate, juste via un PC sous Windows

25 février 2019 - 03:25

Bonjour,

Ce tuto va expliquer comment dumper ou restaurer la nand d'une Switch directement via le PC. L'avantage de faire comme cela est de ne plus être limité par le format de la SD ou sa taille donc cela évite, par exemple, d'avoir des dumps splittés et donc plus facilement utilisable ensuite sur Hekate. Cela peut aussi permettre de modifier un dump splitté plus facilement, d'activer/désactiver l'auto-RCM de la partition BOOT0 immédiatement, etc...

Je n'expliquerai pas ici comment passer en RCM, veuillez consulter la FAQ pour savoir comment faire cela.

Pour le tuto de dump via Hekate, voir ce sujet et pour le tuto de restauration de nand via Hekate (même si le départ passe par SX OS la fin passe par Hekate) voir ce sujet.

Prés-requis:
  • Une Switch et un câble USB pour pouvoir la relier au PC. Attention, le câble USB doit aussi supporter le transfert de données, certains câbles ne supportent que la charge et ceux-ci ne fonctionneront donc pas.
  • Un PC sous Windows 7 minimum.
  • Le logiciel NxNandManager.
  • Le payload Memloader, il est inclue dans TegraRcmGUI ou dans mon Ultimate Switch Hack Script qui contient aussi NxNandManager.
  • Au moins 30 GO d'espace disque à l'endroit où le dump de la Nand sera fait (cas de dump évidemment et cas d'un dump complet, sinon l'espace nécessaire est fonction de se qui doit être dumpé).
1) Explication sur le fonctionnement de Memloader:

Ce payload peut être utilisé pour de multiples choses mais ici je vais juste décrire son utilité pour ce tuto. Comme ce payload est clairement le point central de ce tuto, je ferais souvent référence à cette partie par la suite car je ne vais pas tout réexpliquer à chaque fois.

Il va permettre de monter une partie de la nand en tant que périphérique de stockage sur le PC pour que l'on puisse ensuite travailler dessus.

Attention: Ne jamais, mais vraiment jamais, essayer de formater le lecteur monté via Memloader, ceci est précisé car Windows le proposera à chaque fois que le lecteur sera monté donc je le redis, ne jamais formater un lecteur monté via Memloader, vous êtes prévenus.

Note importante: Pour éteindre la Switch une fois un lecteur monté, il suffit de maintenir le bouton "Power" de la console pendant une dizaine de secondes. Attention, ne jamais éteindre ou débrancher le câble USB de la console tant que des opérations sont en cours sous peine de brick.


Dans TegraRcmGUI, ces fonctions se trouvent dans l'onglet "Tools", il faut sélectionner une option puis cliquer sur "Mount". Voici se que font les différentes options:
  • eMMC BOOT0 (DANGEROUS): Monte la partition BOOT0, elle correspond au fichier BOOT0 dumpé via Hekate.
  • eMMC BOOT1 (DANGEROUS): Monte la partition BOOT1, elle correspond au fichier BOOT1 dumpé via Hekate.
  • eMMC rawNAND (DANGEROUS): Monte la RawNand, elle correspond au fichier "rawnand.bin" dumpé via Hekate. Cette partition est celle qui contient quasiment toutes les données et elle contient aussi différentes partitions mais pour l'instant on ne va pas s'en soucier.
Dans mon Ultimate Switch Hack Script, on peut soit utiliser l'option "Monter la nand, la partition BOOT0, la partition BOOT1 ou la carte SD" du menu principal puis choisir la partition à monter ou alors aller dans "Fonctions à utiliser occasionnellement", puis "Nand toolbox", "Charger une partie de la nand avec Memloader" et sélectionner la partition à monter (je conseil d'utiliser cette seconde solution pour ce tuto car les autres outils que l'on va utiliser se trouvent dans ce menu). La différence avec TegraRcmGUI est juste que se que j'appelle "nand de la Switch" est appelé "EMMC RawNAND" dans TegraRcmGUI.

2) NxNandManager:

On va maintenant parler de ce second protagoniste principal de ce tuto qui est le programme qui va permettre d'effectuer les opérations sur les partitions montées via Memloader (CF partie 1).

Ce programme possède deux modes de fonctionnement, soit en mode graphique (appelé mode GUI) qui est le mode par défaut quand on lance l'application via un double-clique sur le fichier principal ou soit en mode console (appelé CLI). Je ne vais pas ici décrire le fonctionnement en mode CLI mais sachez que c'est ce mode très pratique que j'utilise dans mon Ultimate Switch Hack Script.

Je ne pense pas avoir besoin de décrire les options qui se trouve dans le menu "Fonctions à utiliser occasionnellement", puis "Nand toolbox" de mon Ultimate Switch Hack Script, elle sont assez explicite et en français donc ça devrait aller, il faudra juste comprendre la logique que j'expliquerai en partie 3. De plus, les étapes sont bien décrites à chacune d'entre elle, il faut juste prendre le temps de lire. La seul chose à savoir est qu'il faut lancer l'Ultimate Switch Hack Script en tant qu'administrateur (Windows 8 et supérieurs) pour que NxNandManager et donc le script puisse fonctionner correctement.

Par contre, décrivons un peu l'interface graphique de NxNandManager:

On a en premier lieu la barre de menu se trouvant en haut du logiciel, quand on ouvre le logiciel on a accès seulement au menu "File" qui contient les options "Open file..." (ouvre un fichier de dump) et "Open drive..." (ouvre la partition montée via Memloader).

Une fois que l'on a ouvert soit un fichier ou soit la partition de la console, on a un tableau récapitulant les partitions contenu dans le fichier/périphérique chargé. En faisant un clique droit sur un des éléments du tableau, on peut soit dumper l'élément vers un fichier ("Dump to file...") ou soit restaurer l'élément via un fichier de dump déjà effectué au préalable ("Restore from file..."). On s’aperçoit également que le menu "Tools" de la barre de menu est maintenant accessible, il contient les options "Full dump" (dump l'ensemble des partitions du dump chargé), "Full restore" (restaure la nand chargée via un fichier de dump effectuée au préalable) et possiblement d'autres options selon le type de dump/nand chargée, voir ci-après.

Si on charge une partition BOOT0, le menu "Tools" contiendra l'option "Disable autoRCM" ou "Enable autoRCM" permettant respectivement de désactiver l'auto-RCM ou de l'activer. Il est à noter que les libellé pour dumper ou restaurer la partition sont un peu différent que quand on charge un fichier "rawnand.bin", ils deviennent respectivement "Dump" et "Restore" (ceci est également valable pour la partition BOOT1).

Note: Les options du menu "Tools" sont aussi accessibles via des boutons directement intégrés à l'interface graphique.

3) Logique de fonctionnement:

En réalité, elle est assez simple. Pour l'imager, je vais dire que je veux sauvegarder le dump d'une de mes consoles puis le restaurer ensuite.

Voici donc se qu'il faut faire pour le dump, expliquer pour le mode GUI de NxNandManager:
  • Charger la partition "BOOT0" via Memloader (CF partie 1).
  • Sélectionner la console via le menu "File" puis "Open drive..." (elle sera nommé "\\.\PhysicalDriveX" ou "X" est un numéro).
  • Aller dans "Tools" puis "Dump", aller dans le dossier dans lequel le dump doit être sauvegarder et nommer le fichier. Je conseil de nommer ce fichier "BOOT0" pour des raisons de compatibilité avec Hekate.
  • Valider le choix et attendre la fin du processus. Une fois terminé, on peut éteindre la Switch.
  • Charger la partition "BOOT1" via Memloader (CF partie 1).
  • Sélectionner la console via le menu "File" puis "Open drive..." (elle sera nommé "\\.\PhysicalDriveX" ou "X" est un numéro).
  • Aller dans "Tools" puis "Dump", aller dans le dossier dans lequel le dump doit être sauvegarder et nommer le fichier. Je conseil de nommer ce fichier "BOOT1" pour des raisons de compatibilité avec Hekate.
  • Valider le choix et attendre la fin du processus. Une fois terminé, on peut éteindre la Switch.
  • Charger la partition "Rawnand" via Memloader (CF partie 1).
  • Sélectionner la console via le menu "File" puis "Open drive..." (elle sera nommé "\\.\PhysicalDriveX" ou "X" est un numéro).
  • Aller dans "Tools" puis "Full dump", aller dans le dossier dans lequel le dump doit être sauvegarder et nommer le fichier. Je conseil de nommer ce fichier "rawnand.bin" pour des raisons de compatibilité avec Hekate.
  • Valider le choix et attendre la fin du processus, celui-ci peut durer assez longtemps selon le matériel. Une fois terminé, on peut éteindre la Switch.
Maintenant, pour la restauration, c'est très simple, il suffit de reproduire les mêmes étapes que décrite juste au-dessus mais on utilise l'option "Restaure" à la place de l'option "Dump" ("Full restore" à la place de "Full dump" pour la partie rawnand).

Note: Pour le cas de la partition BOOT0, il sera possible de désactiver ou d'activer l'auto-RCM de celle-ci lorsqu'elle sera chargée dans NxNandManager, soit avant le dump ou soit après la restauration, CF la partie 2 pour l'explication de l'utilisation de cette fonctionnalité.

Note 2: Pour utiliser un dump splitté (découpé en plusieurs parties, par exemple le dump fait via SX OS ou un dump fait par Hekate sur une SD formatée en FAT32) pour la restauration, il suffit d'indiquer au logiciel le premier fichier du dump splitté et il faudra aussi que le reste du dump se trouve dans le même dossier que le fichier indiqué. Pour charger un fichier de dump splitté dans le logiciel pour pouvoir éventuellement le modifier, les règles sont exactement les mêmes.

Pour une utilisation via mon script la logique est la même, charger la partition sur laquelle on souhaite travailler, effectuer l'opération ou les opérations souhaitées puis éteindre la console et recommencer pour la partition suivante.

4) Aller plus loin:

En fait, NxNandManager permet d'aller bien plus loin que cela. Par exemple, il peut activer/désactiver l'auto-RCM de la partition BOOT0 chargée, il peut extraire une partition d'un dump déjà effectué, restaurer une partition spécifique de la Rawnand, par exemple on pourrait vouloir restaurer la partition PRODINFO de la Rawnand après l'utilisation du homebrew Incognito. Alors oui, on pourrait restaurer toute la rawnand mais bon c'est d'une part beaucoup plus long et de deux cela oblige à revenir dans un état antérieur sur beaucoup de chose alors qu'on peut faire autrement.

On peut aussi travailler sur un fichier de dump d'une des trois partie de la nand, par exemple pour désactiver l'auto-RCM d'un fichier de dump du BOOT0 avant sa restauration sur le périphérique. on peut aussi remplacer une partition d'un fichier de dump de la rawnand, par exemple pour préparer quelque chose de spécifique avant la restauration sur le périphérique mais ceci ne sera utilisé que dans des cas très particulier, en général la partie 3 devrait être suffisante pour la plupart des utilisateurs pour faire les opérations souhaitées.

Si vous souhaitez en savoir plus et que vous n'êtes pas anglophobe, je vous invite à lire le readme du Github de NxNandManager, tout y est décrit.

Il faut également savoir que mon Ultimate Switch Hack Script est capable d'exploiter pleinement les fonctionnalités de NxNandManager, que se soit les fonctions plus basiques ou les fonctions plus avancées.

5) Remerciements:

Un grand merci à @eliboa qui a vraiment travaillé dur sur ce projet de NxNandManager et je le remercie d'autant plus d'avoir intégré un mode CLI qui m'a permis d'intégrer ensuite très simplement toutes les fonctionnalités de ce logiciel à mon Ultimate Switch Hack Script, le rendant encore plus complet qu'il ne l'est déjà. Merci à lui également pour TegraRcmGUI qui est clairement une des références de lanceur de payloads sur la scène Switch, je crois qu'avec çà tout est dit. Je remercie également tous les autres acteurs de la scène open-sources Switch sans qui bien évidemment tout ceci ne serait pas possible, ils sont bien trop nombreux pour être tous cités à chaque fois mais le respect est là.

Test et fonctionnement du AceNS Pro

27 janvier 2019 - 10:15

Test du AceNS Pro

Introduction

Bonjour à tous,

Je vais vous présenter un dongle+jig appelé le AceNS Pro. Le site officiel de ce dongle se trouve à cette adresse. Contrairement au AceNS Loader que j'avais déjà testé, celui-ci fonctionne plutôt comme un dongle SX Pro. Cela signifie que la licence pour Ace OS est incorporée au dongle.

Avant de commencer ce test et pour être totalement transparent, je tiens à préciser que le AceNS Pro (abrégé ANSP pour la suite du test), m'a été envoyé gratuitement en échange d'un test. Je précise également que ce dongle n'apporte rien pour les consoles patchées sur lesquelles ce dongle ne fonctionnera pas plus que les autres.

Note : N'hésitez pas à consulter également la FAQ pour des compléments d'informations au sujet du hack Switch, beaucoup de choses y sont répertoriées.

Description

Le ANSP a un design équivalent au AceNS Loader. Il se présente sous la forme d'un rectangle. Le port USB type C mâle se trouve sur un des côté de la longueur du rectangle alors que le port USB type B femelle se trouve à son exact opposé. Sur l'une des "faces" du dongle il y a un jig qui peut être facilement retiré et de l'autre côté un faux bouton (reste du design du AceNS Loader) et une led dont nous verrons le fonctionnement dans la suite du test. Enfin, une petite boîte permet de ranger le dongle ainsi que le câble USB type B vers USB type A. Selon le site officiel, le dongle embarque une batterie Li-Ion permettant de garder le dongle inutilisé (en stand by) pendant 4 mois avant de le recharger et le dongle met une heure et demi pour être complètement rechargé. Il est à noter que le câble USB fourni est un tout petit peu plus long que celui fourni avec le AceNS Loader, d'un ou deux centimètres mais ce câble peut être facilement remplacer par un câble utilisé par beaucoup d'anciens smartphones tournant sous Android.

Quelques photos du AceNS Loader mais le design étant le même pour le ANSP je ne referai pas de photo de ce dernier, cela me semble bien inutile :





1545389183-img-20181219-162613.png

1545389286-img-20181219-162742.png

1545389303-img-20181219-162755.png


Fonctionnalités

Comme je l'ai dit en introduction, ce dongle fonctionne comme le SX Pro et SX OS, à savoir qu'une licence d'utilisation est livrée avec le dongle pour le CFW Ace OS. Pour que cela fonctionne, il faut donc télécharger le fichier de l'OS sur le site officiel donné en début de test, décompresser le fichier à la racine de la SD (ceci donnera un fichier "boot.dat" qui se trouvera donc à la racine de la SD).

Pour lancer le CFW ensuite, la procédure reste identique que pour tous les dongles, à savoir passer la console en RCM grâce au jig que l'on va insérer dans le rail du joycon droit jusqu'au bout (ne pas forcer pour ne pas abîmer les pins de la console) et démarrer la console en maintenant la touche "volume +" et en appuyant une seconde sur le bouton "Power" (étape facultative pour ceux en auto-RCM bien-sûre, ceux-ci n'ont qu'à appuyer sur "Power" pour lancer la console en RCM sans avoir même besoin du jig). L'écran restera noir, ceci est normal. Ensuite on insère le dongle et le payload sera injecté. Une fois le payload injecté (le CFW lancé), on peut retirer le jig et le dongle de la console, ceux-ci ne serviront plus jusqu'au prochain redémarrage de la console.

Note: On peut utiliser le câble USB fourni pour recharger le dongle, la led sera verte lorsque le dongle se recharge; elle sera bleu lorsque le dongle tentera d'injecter le payload sur la console via l'USB type C (ne pas brancher le câble pour charger le dongle en même temps qu'une injection du payload).

Une fois le CFW démarré pour la première fois, celui-ci va créer un fichier "licence_request.dat" à la racine de la SD, ce fichier est unique pour chaque console et pour chaque dongle. Ce fichier peut servir à activer le CFW via cette page, on upload le fichier "licence_request.dat" sur le site et celui-ci retournera un fichier "licence.dat" qu'il faudra mettre à la racine de la SD et dont je conseil également de faire une copie au cas où. On peut également activer le CFW en allant dans l'album de la Switch et en suivant les instructions d'activation (la console doit être connectée à internet pour faire cela) mais perso je recommande plutôt la première méthode d'activation. Attention, je pense que la licence n'est compatible qu'avec une seule console, cela signifie que si vous changez de console le dongle ne servira plus à rien et dans ce cas c'est vraiment le cas, voir la suite pour comprendre pourquoi je dis cela. Une fois la licence sur la SD, le CFW pourra être utilisé pleinement et le démarrage ne nécessitera plus d'activer la licence tant que le fichier "licence.dat" se trouvera à la racine de la SD (notez que ce fichier peut être transféré sur une autre SD si vous en changez, la licence n'est compatible qu'avec une console mais il n'y a pas de limitation par rapport à la SD utilisée sur celle-ci).

Mais dis-moi Jamy, on dirait bien la procédure d'activation de SX OS, même les noms de fichiers sont les mêmes et seul le site d'activation de la licence est différent?
Et bien oui, tout simplement parce que le Ace OS est clairement un SX OS hacké (seul les couleurs des menus sont différentes) mais attention, les licences ne sont bien évidemment pas compatible entre les deux CFWs, tout comme charger le Ace OS avec un SX Pro ou le payload pour lancer SX OS (SX Loader) ne peut lancer Ace OS et inversement. Du coup, pour lancer le Ace OS, il n'est possible de passer que par le dongle ANSP car le Ace Loader n'est pas disponible en dehors du dongle, à la différence du SX Loader qui lui est distribué par la team Xecuter. Bref, inutile d'aller plus loin, le fonctionnement du Ace OS est le même que le SX OS et il dispose des mêmes fonctionnalités (Chargement des XCI, Emunand, installation de NSP, lancement de homebrews, prise en charge des cheats, lancement de payloads situés à la racine de la SD, dump de la nand, activation/désactivation de l'auto-RCM... (voir la FAQ et les tutos épinglés dans cette section du forum pour avoir plus d'infos sur les fonctionnalités de SX OS et comment s'en servir)), rien de plus que SX OS.

Conclusion

Personnellement je pense qu'il vaut mieux prendre une licence de SX OS officielle et un autre dongle comme le AceNS Loader ou le NS Atmosphere ou même la pose d'une puce pour ceux qui sont intéressés par cette dernière option plutôt que d'acheter ce dongle dont on ne sais pas si le support sera au rendez-vous, kit à payer un CFW je pense qu'il vaut mieux prendre celui de la team Xecuter plutôt qu'un hack de ce CFW qui est payant, nécessite obligatoirement le dongle ANSP pour être lancé et qui n'apporte rien de plus mis à part de la limitation.

De fait, je ne recommande pas ce dongle car je le trouve peu utile et finalement il ne coûtera pas moins cher que l'achat d'une licence SX OS officielle et d'un dongle comme le AceNS Loader ou le NS Atmosphere qui eux permettent aussi de lancer d'autres CFWs/payloads, je ne recommande pas non plus le SX Pro car personnellement je n'aime pas trop le système de condensateurs en guise de batterie, c'est difficile à changer en cas de panne et je le trouve trop cher de toutes façons. Après, nous verrons bien les évolutions et le suivi de ce ANSP par la suite et je mettrai à jour ce test si les choses changent.


Test du AceNS Pro

24 janvier 2019 - 02:43

Test du AceNS Pro

Introduction

Bonjour à tous,

Je vais vous présenter un dongle+jig appelé le AceNS Pro, le site officiel de ce dongle se trouve à cette adresse. Contrairement au AceNS Loader que j'avais déjà testé, celui-ci fonctionne plutôt comme un dongle SX Pro se qui signifie que la licence pour Ace OS est incluse au dongle.

Avant de commencer ce test et pour être totalement transparent, je tien à préciser que le AceNS Pro (abrégé ANSP pour la suite du test), m'a été envoyé gratuitement en échange d'un test. Je précise également que ce dongle n'apporte rien pour les consoles patchées sur lesquelles ce dongle ne fonctionnera pas plus que les autres.

Note: N'hésitez pas à consulter également la FAQ pour des compléments d'informations au sujet du hack Switch, beaucoup de choses y sont répertoriées.

Description

Le ANSP a un design équivalent au AceNS Loader. Le ANSP se présente sous la forme d'un rectangle. Le port USB type C mâle se trouve sur un des côté de la longueur du rectangle alors que le port USB type B femelle se trouve à son exact opposé. Sur l'une des "faces" du dongle il y a un jig qui peut être facilement retiré et de l'autre côté un faux bouton (reste du design du AceNS Loader) et une led dont nous verrons le fonctionnement dans la suite du test. Enfin, une petite boîte permet de ranger le dongle ainsi que le câble USB type B vers USB type A. Selon le site officiel, le dongle embarque une batterie Li-Ion permettant de garder le dongle inutilisé (en stand by) pendant 4 mois avant de le recharger et le dongle met une heure et demi pour être complètement rechargé. Il est à noter que le câble USB fourni est un tout petit peu plus long que celui fourni avec le AceNS Loader, d'un ou deux centimètres mais ce câble peut être facilement remplacer par un câble utilisé par beaucoup d'anciens smartphones tournant sous Android.

Quelques photos du AceNS Loader mais le design étant le même pour le ANSP je ne referai pas de photo de ce dernier, cela me semble bien inutile:






1545389183-img-20181219-162613.png

1545389286-img-20181219-162742.png

1545389303-img-20181219-162755.png


Fonctionnalités

Comme je l'ai dit en introduction, ce dongle fonctionne comme le SX Pro et SX OS, à savoir qu'une licence d'utilisation est livrée avec le dongle pour le CFW Ace OS. Pour que cela fonctionne, il faut donc télécharger le fichier de l'OS sur le site officiel donné en début de test, décompresser le fichier à la racine de la SD (ceci donnera un fichier "boot.dat" qui se trouvera donc à la racine de la SD).

Pour lancer le CFW ensuite, la procédure reste identique que pour tous les dongles, à savoir passer la console en RCM grâce au jig que l'on va insérer dans le rail du joycon droit jusqu'au bout (ne pas forcer pour ne pas abîmer les pins de la console) et démarrer la console en maintenant la touche "volume +" et en appuyant une seconde sur le bouton "Power" (étape facultative pour ceux en auto-RCM bien-sûre, ceux-ci n'ont qu'à appuyer sur "Power" pour lancer la console en RCM sans avoir même besoin du jig). L'écran restera noir, ceci est normal. Ensuite on insère le dongle et le payload sera injecté. Une fois le payload injecté (le CFW lancé), on peut retirer le jig et le dongle de la console, ceux-ci ne serviront plus jusqu'au prochain redémarrage de la console.

Note: On peut utiliser le câble USB fourni pour recharger le dongle, la led sera verte lorsque le dongle se recharge; elle sera bleu lorsque le dongle tentera d'injecter le payload sur la console via l'USB type C (ne pas brancher le câble pour charger le dongle en même temps qu'une injection du payload).

Une fois le CFW démarré pour la première fois, celui-ci va créer un fichier "licence_request.dat" à la racine de la SD, ce fichier est unique pour chaque console et pour chaque dongle. Ce fichier peut servir à activer le CFW via cette page, on upload le fichier "licence_request.dat" sur le site et celui-ci retournera un fichier "licence.dat" qu'il faudra mettre à la racine de la SD et dont je conseil également de faire une copie au cas où. On peut également activer le CFW en allant dans l'album de la Switch et en suivant les instructions d'activation (la console doit être connectée à internet pour faire cela) mais perso je recommande plutôt la première méthode d'activation. Attention, la licence n'est compatible qu'avec une seule console, cela signifie que si vous changez de console le dongle ne servira plus à rien et dans ce cas c'est vraiment çà, voir la suite pour comprendre pourquoi je dis cela. Une fois la licence sur la SD, le CFW pourra être utilisé pleinement et le démarrage ne nécessitera plus d'activer la licence tant que le fichier "licence.dat" se trouvera à la racine de la SD (notez que ce fichier peut être transféré sur une autre SD si vous en changez, la licence n'est compatible qu'avec une console mais il n'y a pas de limitation par rapport à la SD utilisée sur celle-ci).

Mais dis-moi Jamy, on dirait bien la procédure d'activation de SX OS, même les noms de fichiers sont les mêmes et seul le site d'activation de la licence est différent?
Et bien oui, tout simplement parce que le Ace OS est clairement un SX OS hacké (seul les couleurs des menus sont différentes) mais attention, les licences ne sont bien évidemment pas compatible entre les deux CFWs, tout comme charger le Ace OS avec un SX Pro ou le payload pour lancer SX OS (SX Loader) ne peut lancer Ace OS et inversement. Du coup, pour lancer le Ace OS, il n'est possible de passer que par le dongle ANSP car le Ace Loader n'est pas disponible en dehors du dongle, à la différence du SX Loader qui lui est distribué par la team Xecuter. Bref, inutile d'aller plus loin, le fonctionnement du Ace OS est le même que le SX OS et il dispose des mêmes fonctionnalités (Chargement des XCI, Emunand, installation de NSP, lancement de homebrews, prise en charge des cheats, lancement de payloads situés à la racine de la SD, dump de la nand, activation/désactivation de l'auto-RCM... (voir la FAQ et les tutos épinglés dans cette section du forum pour avoir plus d'infos sur les fonctionnalités de SX OS et comment s'en servir)), rien de plus que SX OS.

Conclusion

Personnellement je pense qu'il vaut mieux prendre une licence de SX OS officielle et un autre dongle comme le AceNS Loader ou le NS Atmosphere ou même la pose d'une puce pour ceux qui sont intéressés par cette dernière option plutôt que d'acheter ce dongle dont on ne sais pas si le support sera au rendez-vous, kit à payer un CFW je pense qu'il vaut mieux prendre celui de la team Xecuter plutôt qu'un hack de ce CFW qui est payant, nécessite obligatoirement le dongle ANSP pour être lancé et qui n'apporte rien de plus mis à part de la limitation.

De fait, je ne recommande pas ce dongle car je le trouve peu utile et finalement il ne coûtera pas moins cher que l'achat d'une licence SX OS officielle et d'un dongle comme le AceNS Loader ou le NS Atmosphere qui eux permettent aussi de lancer d'autres CFWs/payloads, je ne recommande pas non plus le SX Pro car personnellement je n'aime pas trop le système de condensateurs en guise de batterie, c'est difficile à changer en cas de panne et je le trouve trop cher de toutes façons. Après, nous verrons bien les évolutions et le suivi de ce ANSP par la suite et je mettrai à jour ce test si les choses changent.

Edit: Et bien il y a tout de même un support pour ce dongle qui pour l'instant est compatible 8.1.0 et inférieur mais bon, toujours pas le payload pour lancer le CFW modifié autrement que via le dongle donc ce CFW est vraiment uniquement compatible avec les Switch non patchées puisque pas possible d'avoir le payload. Pour le reste, mon avis reste le même.