[TUTO]Faire un backup de sa Nand avec Hekate

[florent]

Justement la somme ne fait pas cette taille.

Merci pour le tuyau, je vais voir avec le nxNandmanager.

[badablek]

tu as donc ta réponse, si le dump ne fait pas la taille exacte 

tu as un souci avec ta microSD, donc fais hyper attention !

[Val29810]

Bonjour,
Je viens d'acheter une Switch qui a été hackée par le vendeur. Je me demandais si je pouvais faire le dump de la Nand via ce tuto même si la console a déjà été modifiée ? J'ai un peu peur qu'elle brick un jour et je ne voudrais pas avoir à utiliser haku33 pour tout nettoyer et recommencer le tuto du hack... J'aimerais juste m'assurer que le backup pourra être utilisé si ma console crash. Je ne me soucie pas d'éventuel ban futur de la part de Nintendo car je compte l'utiliser seulement via atmosphère. Merci de votre aide.

[badablek]

salut,
 

il faut bien se rendre compte que le hack sur Switch est de nature temporaire et ne modifie pas le système. Donc oui, tu peux tout à fait faire un backup maintenant. C'est d'ailleurs un peu le dilemme de l'œuf et de la poule. Pour dumper sa sysMMC, il faut hacker sa console, donc, dans l'absolu, tout dump de sysMMC provient d'une console qui a déjà été hackée, que ce soit dans la seconde qui suit ou 3 mois après.

 

et il n'y a pas de bonne ou mauvaise façon de hacker sa console. Donc la notion de "nettoyer" n'a pas de sens. La seule différence entre un dump dès le début du hack et un dump quelques jours ou mois plus tard, c'est que la sysMMC peut avoir été "salie" par l'installation de contenus non légitimes si aucune emuMMC n'a été mise en place. Et c'est dans ce cas en particulier qu'on peut parler de "nettoyage" pour tenter de supprimer toute trace de ce qui pourrait avoir été installé.

[Val29810]

Merci pour ta réponse.

J'ai lu qu'il ne fallait pas lancer atmosphere directement depuis son ordinateur car cela laisserait des traces dans la Sysnand, c'est-à-dire en lançant fusée.bin via Tegra RCM contrairement à lancer atmosphere depuis Hekate en plaçant le fichier sur la carte sd. Tu peux confirmer ?

Je débute dans le hack et je ne sais pas trop ce qu'il a fait auparavant. Je vois qu'il y a un dossier emuMMC sur la carte SD qui est assez volumineux donc je pense que l'Emunand a été faite au préalable et que les payload se lancent sur ce système. Comment s'assurer que c'est bien le cas ? En démarrant la console via l'OFW, je ne vois aucun jeu d'installé alors qu'il y en a sur le CFW. Si je comprends bien en l'absence d'Emunand, les jeux installés s'afficheraient aussi dans le menu home en OFW ?

Désolé pour ces questions qui semblent peut-être simplistes mais comme je n'ai pas hack la console moi même, j'ai un peu dû mal à comprendre la fonction des différents fichiers présents sur la carte sd et l'utilisation des différents payloads...

[badablek]

J'ai lu qu'il ne fallait pas lancer atmosphere directement depuis son ordinateur car cela laisserait des traces dans la Sysnand, c'est-à-dire en lançant fusée.bin via Tegra RCM contrairement à lancer atmosphere depuis Hekate en plaçant le fichier sur la carte sd. Tu peux confirmer ?

non, je ne confirme absolument pas. Ce sont des ragots colportés par des personnes qui n'ont vraiment rien compris au hack. Le processus de boot, peu importe la forme qu'il prend, n'influence en rien la sysMMC, jamais.

J'ajouterais que s'il y a bien un truc qui ne laisse pas de trace, c'est bien Atmosphère.


et oui, ta console a été correctement préparée avec une emuMMC. Ton dump sysMMC sera donc tout ce qu'il y a de plus propre.
Tu peux ouvrir bootloader/hekate_ipl.ini et copier/coller son contenu dans un message, que je regarde comment ça a été paramétré. Mais avec un dossier emuMMC qui pèse ses 29Go, c'est que ça démarre bien dessus. Et tu as parfaitement compris que si tu bootes normalement et que tu ne vois rien, c'est bien que c'est installé "ailleurs" (dans l'emuMMC)

[Val29810]

Ok parfait et encore merci.

J'ai ouvert le fichier demandé et voici le contenu:
[config]
autoboot=0
autoboot_list=0
bootwait=0
autohosoff=0
autonogc=1
updater2p=1
backlight=100

[sysMMC]
fss0=atmosphere/package3
kip1patch=nosigchk
atmosphere=1
emummc_force_disable=1
icon=bootloader/res/icon_payload.bmp

[emuMMC]
fss0=atmosphere/package3
kip1patch=nosigchk
emummcforce=1
atmosphere=1
icon=bootloader/res/icon_payload.bmp

[Stock]
fss0=atmosphere/package3
emummc_force_disable=1
stock=1
icon=bootloader/res/icon_switch.bmp

[badablek]

c'est classique, reste à voir ce que tu choisis pour démarrer.

c'est cependant dommage :

• qu'autoboot ne soit pas activé
  
• que les entrées sysMMC et emuMMC soient toutes les deux dispo (si tu fais une emuMMC, ce n'est certainement PAS pour démarrer Atmosphère sur la sysMMC)
  

Perso je ferais les modifications suivantes :

Code : Tout sélectionner

[config]
autoboot=1
autoboot_list=0
bootwait=0
autohosoff=0
autonogc=1
updater2p=1
backlight=100

[emuMMC]
fss0=atmosphere/package3
kip1patch=nosigchk
emummcforce=1
atmosphere=1
icon=bootloader/res/icon_payload.bmp

[Stock]
fss0=atmosphere/package3
emummc_force_disable=1
stock=1
icon=bootloader/res/icon_switch.bmp

entrée sysMMC supprimée (inutile vu que tu passes par une emuMMC)
autoboot à 1 avec autoboot_list à 0 → indique à Hekate qu'on charge automatiquement la première entrée (emuMMC)


et je mettrais également autonogc à 0 parce que ça ne sert à rien de bloquer le port cartouche en emuMMC (sauf si tu comptes avoir une différence de version entre sysMMC et emuMMC). Ce truc a été implémenté au cas où il "golden firmware" serait trouvé (à une époque très lointaine où des failles logiciels étaient utilisables...ça remonte à avant le firmware 4.0.0)

avec autonogc à 1, tu ne peux pas utiliser de cartouche sur ton emuMMC.

[Val29810]

Super merci beaucoup. Désolé pour ce temps de réponse mais je ne suis pas souvent sur le forum !