4 réponses à ce sujet

[Flork3]

Bonjour à tous,

 

Pas de bug de mon coté, mais juste quelques questions pour renforcer mes connaissance sur le sujets, merci à ceux qui prendront le temps d'y répondre (Et Shadow 256 s'il traine dans les parages

 

1. Hekate permet de démarrer en official firmware sur la sysnand, mais quel interet ? C'était également proposé en mode "stock" sur la puce SX OS il à longtemps.
Puisqu'il suffit d'éteindre la console et de la rallumer. l'auto boot ne fonctionne que si on redémarre la console, pas arrêter et rallumer. Car je me dis qu'il y à un risque de visibilité de Nintendo sur la sysnand ensuite. 

2. J'ai la chance d'avoir que des switch non patchée, du coup, me concernant aucun souci de mettre à jour la sysnand, tant que je laisse mon emunand à la bonne version de firmware pris en charge par hekate et atmosphère. Je viens encore de mettre a jour la sysnand en 20.0.1 (oui utile me concernant pour laisser le petit jouer à fortnite en ligne, sinon la console et le jeu le demande) et je démarre sans souci la switch en mode RCM-hekate-emunand sans souci. Ma question, est-ce également possible pour les consoles pucée ? Car pas de RCM.
 

3. Downgrade : J'ai cru comprendre qu'avec les clés obtenues avec lockpit possible de le faire. Mais sachatn que cela passe par Daybreak utilisé sur atmo (partons du principe par encore mis à jour) comment est-ce possible. Que ce soit le downgrad de la sysnand mais surtout de l'Emunand ?
 

4. Souvent des gens ont apres une mise à jour ce bug à l'écran écrit : Rouge : Unknown pkg1 version / HOS version not supported / or EmuMMC corrupted  /  Trying backup bootloader  Found pkg1 20250206151829 / Unknown pkg1 version / Failes to launch HOS ..... press any key....   
Est-ce à cause de la mise en jour de la sysnand avec aucune Emunand donc, forcement ca bloque car atmo pas à jour ? Ou autre bug, car le HOS c'est bien le firm officiel de mémoire, ? 
donc :

. Le payload a bien trouvé un fichier pkg1 (composant essentiel du système de la Switch) Mais il n’a pas pu le décrypter, ce qui est une erreur typique lorsque :

• Le fusee-primary.bin est obsolète par rapport à la version du firmware installé,

• Les keys ne sont pas à jour (indispensables pour décrypter pkg1),

• Ou que le fichier pkg1 est endommagé.

Comment résoudre ce problème ?

5. Différence entre le mode RCM des non patchée et le boot de la puce, qui de mémoire autoboot sur hekate ? Du coup comment lancer la sysnand sans CFW ? Comment avoir le choix en fait ?

 

Merci à tous !

Modifié par Flork3, 06 mai 2025 - 17:56.

[shadow256]

1: Pratique pour les consoles équipées de puces qui, comme tu le remarques un peu plus loin, démarre sous Hekate automatiquement (bon pas très juste, elles démarrent en fait sur un payload nommé et mis à un endroit sur la SD). Aujourd'hui les puces ont cependant une fonction qui permet d'annuler le leur action et donc de démarrer la console normalement (maintien des deux touches de volume puis appuie sur Power pendant une demi-seconde et relâcher les touches de volume dès qu'on voit le premier logo Nintendo). Tu as aussi ceux qui sont en auto-rcm (plus nombreux qu'on croit) et donc démarrent sur un payload, etc..., en fait les cas peuvent être nombreux pour utiliser cette fonction. Et enfin pourquoi ne pas le permettre puisque de toutes façons il faut permettre le lancement du CFW sur la Sys-nand, après tout ça ne coûte pas grand chose. Enfin pour ce point on notera qu'utiliser une configuration de type "stock" et utiliser la fonction "Reboot OFW" ne fait pas la même chose, en effet une config "stock" relance le démarrage normale de la console alors que le mode "stock" s'appuie un peu sur Atmosphere pour faire son travail (je ne vais pas entrer dans les détails). Et pour finir non aucun risque de visibilité de Nintendo, quand l'emunand est lancée elle est totalement isolée de la Sys-nand et inversement (bon Nintendo pourrait techniquement lire le contenu de la SD et repérer une emunand mais juridiquement se serait je pense très risqué dans beaucoup de pays d'aller lire comme ça n'importe où sur la SD pour analyser des données), lors d'un redémarrage la RAM est vidée dès le démarrage du firmware.

2: Ici il faut distinguer les deux modèles principaux de console, les Erista (patchés ou non, numéro de série commençant par "XA") et les Mariko (tous les autres modèles). Sur les Erista aucun souci même avec une puce, le fonctionnement est globalement le même sur une patchée que sur une non patchée. Pour les Mariko là ça change à cause du warmboot qui est une sécurité supplémentaire, dans ce cas si on met à jour la sysnand on pourra la lancer grâce au "Reboot OFW" dans Hekate mais par contre ça peut perturber le fonctionnement de l'emunand (le warmboot n'est pas toujours mis à jour) mais ceci peut se contourner en lançant Atmosphere via son payload (même via Hekate) et en utilisant la fonction "Reboot OFW" de Hekate qui saura redémarrer la console. Voilà pourquoi dans mon pack j'ai entre autres choisi de mettre un auto-boot dans Hekate sur le payload de démarrage d'Atmosphere, ainsi on évite bien des problèmes et il suffit de l'annuler avec la touche "vol-" pour utiliser le "Reboot OFW". Une fois que Hekate et Atmosphere sont à jour sur la SD et donc compatible avec le dernier firmware là plus aucun souci, le fonctionnement revient à la normal. Notes qu'ici je peux potentiellement me tromper sur le fonctionnement exact des modèles Mariko car je ne met que très rarement ma sysnand à jour et si je le fais les autres éléments sont déjà compatibles.

3: Si la console est capable de démarrer sur Atmosphere il suffit d'utiliser Daybreak avec n'importe quel firmwware pour l'installer sur la nand sur laquelle Atmosphere a été lancé, je ne comprends pas trop ton interrogation ici. Après le downgrade manuel c'est une autre histoire et oui cela peut nécessiter les clés (sur Mariko cela nécessite les clés) mais il y a des phases sur PC avant donc là c'est pas la même et je ne vais pas tout détailler ici déjà parce que moi-même je ne comprends pas tout au fonctionnement interne de EmcHacGen, je sais juste l'utiliser.

4: Ceci arrive quand Atmosphere n'est pas à jour par rapport à la nand sur lequel on le lance, c'est tout. Donc dans ce cas soit on downgrade manuellement la nand souhaitée (procédure de débrickage sans suppression de données) ou on attend qu'Atmosphere soit compatible, pas d'autre solution.

5: La puce (sauf puces de type Trinket pour les consoles non patchées) lance en fait un payload situé sur la SD comme j'ai expliqué plus haut et on recommande de lancer Hekate car il gère ensuite certaines choses pour démarrer d'autres payloads ou éléments correctement, surtout sur les modèles Mariko. Donc pour démarrer en OFW soit on annule le fonctionnement de la puce comme j'ai expliqué plus haut ou on utilise "Reboot OFW" dans Hekate. Pour les puces de type Trinket là ça peut changer un peu car selon la programmation de la puce on peut vraiment avoir des comportements différents, cependant aujourd'hui on fait plutôt en sorte qu'elles aient plus ou moins le même comportement que les autres puces en lançant le payload "payload.bin" à la racine de la SD avec un montage sans auto-RCM (on strap donc la puce pour effectuer le comportement du jig, ainsi en appuyant sur "vol+" et "Power" on lance la puce et en appuyant juste sur "Power" on lance la console normalement), cela permet d'avoir le fonctionnement le plus simple possible; et pour le fichier du payload sur la SD on met le payload de Hekate pour les mêmes raisons que sur les autres consoles, il est un payload qui permet ensuite de faire tout se qu'on veut via son interface se qui simplifie les choses. Alors après je ne vais pas tout détailler sur les puces type Trinket car beaucoup de possibilités existent (on peut par exemple directement programmer le payload dans la puce mais pour le mettre à jour c'est chiant, on peut fonctionner sur des lancement de 6 payloads différents un peu à la manière de certains dongle, on peut faire des montages différents associés à des programmations particulières pour obtenir une façon de fonctionner différente, etc...).

Note: HOS est l'OS de la Switch, Atmosphere s'appuie dessus et réécrit une grande partie de ses comportements mais HOS reste la base, Atmosphere n'est pas un OS à part comme l'est Linux ou Android.

Note 2: Pour préciser un peu plus sur les puces type Trinket, elles fonctionne uniquement sur les consoles non patchées en utilisant la faille USB, en gros se sont des dongles internalisés à la console mais la base du fonctionnement est la même qu'injecter un payload en USB.

Voilà, j'espère avoir répondu à tes interrogations de manière assez précise, si tu veux éclaircir des points n'hésites pas.

Modifié par shadow256, 06 mai 2025 - 20:07.

[Flork3]

Merci Shadow, toujours au top  !
 

J'ai bien quelques précisions à te demander
 

1. Donc ok, le mode stock pas très utile, autant redémarrer en OFW tout simplement. Et je parlais du risque d'écriture sur la sysnand en lançant le mode stock sur hekate.

2. Donc là si je pige bien, logiquement toujours accès à hekate, ca ne bloque pas son lancement avec la puce, mais parfois l'accés à l'emuNand peut etre corrompu, mais jamais la sysnand. En effet, par hekate on peut reboot en OFW. Donc le message d'erreur de mon point 4 correspondrait au boot sur l'emunand ou eventuellement au boot sur sysnand en sollicitant atmosphere dans les 2 cas. Mais au reboot, ca relance hekate et hop on choisi OFW le temps qu'atmosphère se mette à jour.  DOnc pour les mariko, si maj de la sysnand on reste sur la sysnand... et on patiente

Par contre quand tu dis : "Voilà pourquoi dans mon pack j'ai entre autres choisi de mettre un auto-boot dans Hekate sur le payload de démarrage d'Atmosphere" bas du coup c'est contradictoire, sur les pucée vaudrait mieux pas d'autoboot, pour lancer hekate puis choisir emunand dans launch, comme ca en cas de bêtise avec la maj de la sysnand, on peut booter en OFW et donc éviter d'avoir le message d'erreur en point 4 que je cite. Ca va a chaque fois sinon autobooté avec le choix de l'emunand probablement mais surtout avec atmosphere et conduire au message d'erreur, en boucle.  Les moins doués seraient moins perdus. Qu'en penses tu ? On ne reboot pas souvent sa switch sauf pour les modder ou testeurs.

3. Je pensais au gars qui a mis son emunand en 20.00 ou 20.0.1, pour lui permettre de downgrade. Idem sur la sysnand pour les pucée, histoire avec le warmboot de revenir en arrière si bêtise. Mais ok on parle de reconstruction de nand et donc la galère. Pourtant regarde ici ca parait si simple...    Ton avis sur cette vidéo : 
 

Flork

Modifié par Flork3, 06 mai 2025 - 22:09.

[shadow256]

1: Normalement le mode stock n'écrit rien et ne laisse pas de traces mais comme je le précise il est de toutes façons préférable d'utiliser l'option "Reboot OFW" sauf cas très spécifiques.

2: Oui, soit on met à jour la sysnand et là ça peut devenir galère sur l'emunand ou soit on attend sagement la nouvelle version d'Atmosphere et de Hekate pour mettre à jour la sysnand. Ou troisième choix on met à jour la sysnand mais faut utiliser le payload d'Atmosphere pour le lancer, s'il a une emunand classique elle sera utilisée et pour lancer la sysnand en mode stock on fait "Reboot OFW". Et non mon auto-boot est le meilleur choix de config, il démarre le payload d'Atmosphere et pas une config de Hekate, les deux n'ont pas le même fonctionnement et dans ce cas c'est Atmosphere lui-même qui se charge des éléments à démarrer, si tu passes par une config de Hekate (config "fss") alors tu va tomber sur le problème de warmboot là où ma technique permet normalement de l'esquiver si ma théorie est bonne mais comme je l'ai dit ça je ne sais pas trop car j'ai jamais trop testé ce genre de cas personnellement.

3: Seule solution pour downgrade directement via la Switch, pouvoir booter sous Atmosphere sinon pas moyen de lancer Daybreak donc faut avoir une version d'Atmosphere compatible avec le firmware sur lequel on est. Sinon c'est passage par une phase de débrickage (pas de reconstruction de nand là c'est encore autre chose), c'est pas si difficile à faire même manuellement quand on connait un peu et ça peut pas mal s'automatiser en s'appuyant sur mon Ultimate-Switch-Hack-Script et sa fonction de débrickage. D'autres moyens sont éventuellement possibles avec par exemple un script TegraExplorer si on a mis à jour l'emunand mais pas la sysnand, dans ce cas on peut imaginer récupérer le firmware de la sysnand pour le transférer sur l'emunand, potentiellement faisable mais perso je ne me risquerai pas à créer un tel script qui pourrait faire des dégâts si mal utilisé par l'utilisateur. Après la vidéo est en espagnol, je ne comprends pas bien cette langue et voir la vidéo avec mes problèmes visuels est plutôt pénible et en plus il n'y a aucune description, du coup pas moyen de savoir se qu'il fait vraiment.

Note: Normalement si bien protégée l'emunand ne peut pas se mettre à jour toute seule c'est impossible, si ça se produit alors il y a une très mauvaise configuration des éléments et pour ma part maintenant je ne donne plus de support à ceux qui mettent à jour l'emunand sur des firmwares incompatibles car je considère que c'est fait au pire volontairement, au mieux qu'il y a eu une config manuelle mais en allant pas lire mes tutos qui détaillent comment sécuriser les choses (suivre une vidéo Youtube par exemple est la pire chose à faire vu la quantité de vidéos médiocres au pire, incomplètes au mieux sur le sujet). J'ai fait beaucoup de tutos en français et j'ai tenté de centraliser beaucoup d'infos au même endroit, maintenant si les gens ne veulent pas lire bah ils se démerdent c'est plus mon problème, moi après tout mes consoles fonctionnent très bien et étrangement n'ont jamais eu de problèmes très bizarres.

Modifié par shadow256, 07 mai 2025 - 00:27.

[Flork3]

Merci pour ces éclairages Shadow256

A bientôt j'aurai surement d'autres questions