Forums GAMERGEN

d accord,
je verrais bien plus tard en attente d'autre version
désolé si c'ete pas ici que je devais poster ca
en tout cas merci beaucoup pour la réponse

Il te faudrait tester les sigpatches en lien plus haut dans un premier temps mais ce serait bizarre car tu aurais un message avec DBi. Les patches FS permettent de corriger le système de fichier et de rendre possible l’exécution de fichiers NSP modifiés et/ou non signés. Les patches ES permettent de corriger le service eticket pour installer les NSP modifiés et/ou non signés.

Tu aurais un problème avec les patches FS. Hors la dernière archive prend en compte les derniers patches FS car les ES n’ont pas changé.

Bonjour. Une autre petite question. Quand j'ibjecterais hekate, ça me modifiera la sysnand ou pas ? (en gros est ce que ça resterais ds la sysnand ou alors ça la laisse clean comme si j'avais jamais fais de modifications etc)

Le bin de Hekate ne modifie pas la NAND. Ce qui modifie la NAND, c’est l’installation de NSP, certains homebrews, le mode autoRCM et autres.

OK. Pourtant c'est un truc qu'on injecte donc ça entre bien quelque part ? À moins que ça ne soit ds un endroit genre une mémoire cache ?

Toutes les questions posées depuis ont leur réponse dans la FAQ qu’il faut lire pour comprendre un peu mieux car là je vais résumer grossièrement !

Le hack n’est pas permanent et si tu redémarres ta console, tu te rends bien compte que rien n’est installé sauf les fichiers NSP (qui eux ne fonctionneront pas puisque le hack n’est pas actif). Le fait d’injecter un payload permet de loader et cela depuis ta SD et non depuis la console. Pour Hekate qui est un custom bootloader, c’est ainsi (et pour d’autres également).

En revanche, en fonction de ce que tu utilises, cela laisse des traces dans la télémétrie d’où le fait de ne pas utiliser sa sysNAND pour les aspects underground et de créer une emuNAND. Les deux sont déliées.

Pour Hekate, il utilise un bootloader personnalisé qui n’est pas celui de Nintendo d’où le fait de ne pas aller sur le online. Il possède trois mode de boot qui utilisent son bootloader donc la connexion est à éviter. En démarrant la console normalement, elle utilise le bootloader de Nintendo. Le hack n’est plus actif.

Rien est installé lorsqu’il s’agit d’utiliser un payload (fichier bin) qui se charge de loader depuis la SD et non depuis la console.

Comme dit plus haut, ce qui modifie la NAND, c’est l’installation de NSP, certains homebrews comme RetroArch, le mode autoRCM car il se charge de corrompre la boot et autres.
La sysNAND, c’est la NAND système de la console et l’emuNAND, c’est la NAND système sur la SD. Donc pour éviter de modifier la NAND système de la console avec l’underground, on crée et on utilise une emuNAND.

Et si par exemple au lieu de hekate, j'injecte le payload original fusee, atmosphère bootera dans la sysnand ou l'emunand quand j'allumerais la console après l'avoir éteinte complètement? Je pars du principe bien sûr que j'ai créée une emunand et que j'ai déjà lancé une fois atmosphère sur mon emunand.

Si tu choisis d’utiliser directement Fusée, la configuration proposée est de lancer le CFW sur l’emuNAND. Pour t’en assurer, tu peux vérifier en mettant un thème différent, gris pour la sysNAND et noir pour l’emuNAND. Je conseille d’utiliser Hekate mais chacun fait ce qu’il veut.

Oui c'était juste le cas où j'ai à faire un jour une fausse manip via l'appli mobile rekado. Je passerais par hekate perso aussi mais suffit d'une fausse manip et boom

Ceci reste à vérifier mais sauf si j’ai loupé un épisode entre temps, il me semble qu’en ayant créé une emuNAND via Hekate, il s’est occupé de configurer les fichiers .ini utiles. Et pour le vérifier, il suffit de changer les thèmes.

Malgré tout, je conseille Hekate pour tout.

Oui je passerais par hekate c'était juste une question au cas où j'aurais à faire une fausse manipulation.

Pour différencier sysNAND et emuNAND, il y a la possibilité de changer de thème. Ainsi, à l’issue du boot, tu sais où tu te situes.