157 réponses à ce sujet

[shadow256]

Là je sèche, j'ai refait personnellement tout le tuto qui a bien fonctionné comme je le décris. Pour résumer les choses:

• Obtention des Bis Keys de la console, de ton côté tu les a normalement donc çà s'est OK.
• Création du package via ChoiDuJour, OK aussi avec le package que je t'ai fourni en MP.
• Utilisation de Memloader pour monter la RAWNAND et initialisation des Bis Keys dans HacDiskMount, le test doit être OK pour toutes les Bis Keys.
• Remplacement des partitions "bcpkgxxx" grâce à HacDiskMount et les fichiers contenus dans le package de ChoiDuJour.
• Bien vérifier que les fichiers cachés soient bien affichés ainsi que les fichiers système, pour atteindre ces options faire le raccourci clavier "Touche Windows+r", taper "control folders", appuyer sur "Entrer" et les options se trouveront dans le second onglets de la fenêtre qui va s'afficher.
• Montage de la partition "SAFE" et suppression des éventuelles données qui s'y trouve. On démonte ensuite la partition.
• Montage de la partition "SYSTEM", suppression des données qui s'y trouvent, copie des fichiers pour cette partition contenu dans le package créé par ChoiDuJour et démontage de la partition.
• Montage de la partition "USER", suppression des données qui s'y trouvent, copie des fichiers pour cette partition contenu dans le package créé par ChoiDuJour et démontage de la partition.
• Extinction de la console et montage de la partition "BOOT0" via Memloader.
• Lancement de Etcher et flash de la partition "Linux UMS" par le fichier "BOOT0.bin" contenu dans le package de ChoiDuJour. Fermer Etcher une fois fait.
• Extinction de la console et montage de la partition "BOOT1" via Memloader.
• Lancement de Etcher et flash de la partition "Linux UMS" par le fichier "BOOT1.bin" contenu dans le package de ChoiDuJour. Fermer Etcher une fois fait.
• Sur une SD vierge formatée en FAT32, copier le dossier "bootloader" de Hekate 4.6, copier le fichier "hekate_ipl.ini" du package de ChoiDuJour dans le dossier "bootloader" et copier le fichier "fsxxx.kip1" du package de ChoiDuJour à la racine de la SD.
• Par n'importe quelle méthode (sauf via SX Loader ou Hekate bien sûr), lancer le payload (le fichier bin) de Hekate 4.6, aller dans "Launch configuration" (le premier menu) puis lancer la configuration "fsxxx" (normalement la dernière configuration).

Si absolument tous les points de ce tuto sont réalisés alors ça doit fonctionner. Le seul point qui pourrait poser problème ici serait que le dump que tu as utilisé pour restaurer la partie RAWNAND ne soit pas le dump de la bonne console, en effet dans ce cas les partitions PRODINFO et PRODINFOF ne seraient pas les bonnes mais je ne pense pas que se soit le problème ici car tu avais réussi à déchiffrer le dump de la RAWNAND grâce aux Bis Keys de la console, se qui normalement confirme que s'est bien le bon dump.

[FilDuch]

Merci de prendre tout ce temps pour m'aider à trouver une solution.

 

Je vais revoir tous les points que tu cites et je t'en donnerai confirmation.

 

Le problème semble se situer entre la sortie du mode RCM et le démarrage de l'OS. Soit la console reste en RCM ou soit elle semble se bloquer. Présentement, je ne pense pas que le hardware est en cause et ChoiDuHourNX est l'origine du problème.

 

Je te tiens au courant d'ici la fin de la journée

[FilDuch]

J'ai repris tous les points listés  et je les ai tous effectués dans l'ordre avec succès.

 

Question :

 

  - en cas de succès, quelle devrait être l'image affichée après le démarrage de la configuration (fsxxx") ?

 

D'après ma compréhension,

 

  - la rawnand est composée des partitions BCPKG2-1-Normal-Main, BCPKG2-2-Normal-Sub, BCPKG2-3-SafeMode-Main, BCPKG2-4-SafeMode-Sub, BCPKG2-5-Repair-Main, BCPKG2-6-Repair-Sub, PRODINFO, PRODINFOF, SAFE, SYSTEM & USER.

 

  - Toutes ces partitions sont crées initialement par ChoiDuJour (excepté BCPKG2-5-Repair-Main et BCPKG2-6-Repair-Sub) pour une version donnée de l'OS final (dans mon cas 5.1).

 

  - Les Bis Keys sont initialisées par HacDiskMount pour les partitions PRODINFO, PRODINFOF, SAFE, SYSTEM & USER dans la switch.

 

  - Les partitions de l'EMMC (BCPKG2-1-Normal-Main, BCPKG2-2-Normal-Sub, BCPKG2-3-SafeMode-Main, BCPKG2-4-SafeMode-Sub) sur la switch sont remplacées par celles générées par ChoiDuJour

 

  - Le contenu des partitions restantes de l'EMCC (SAFE, SYSTEM et USER)  est remplacé par celles générées par ChoixDuJour et préalablement effacées de leur contenu

 

Toute cette description pour bien contrôler que j'ai compris ce que je faisais.

 

Je ne comprends pas trop bien ta remarq

[FilDuch]

ue "le dump que tu as utilisé pour restaurer la partie RAWNAND ne soit pas le dump de la bonne console". N'ayant pas utilisé le dump de la rawnand sauvegardé initialement, je n'ai fait que laisser ChoiDuJour m'en recréer un de base puis y ajouter les Bis Keys propres à la switch en copiant le tout sur la switch? Juste ou faux ?

 

Déroulement des faits :

 

  - acheté une switch qui était en version 5.?

  - avant "bricolage", mise à jour à la version 6.01 officielle et sauvegarde complète (rawnand & Boot0/1) à double

  - la switch a fonctionné environ une année sans problème

  - apparition de nouveaux jeux demandant une version plus récente de l'OS

  - tentative de migration par ChoiDuJourNX de 6.01 à 8

  - échec de la migration et perte de la switch

  - tentative de restore des deux sauvegardes

  - échec des restores et tentative de reconstruction selon ton tuto

  - échec de reconstruction

 

Je suis en mode "endurance" et j'y crois toujours car je ne vois pas pourquoi cela ne devrait pas fonctionner.

[Niko343]

Salut filduch j'ai exactement le meme probleme que toi si jamais tu trouve une solution je te remercirais de m'en parler...

[shadow256]

@FilDuch :

Bon alors pour la rawnand c'est OK, tu as bien compris comment ça se passe. Par contre tu as bien affiché les fichiers cachées ainsi que les fichiers système dans Windows?

Après tu ne parles pas de la restauration de BOOT0 et de BOOT1, je suppose que tu le fais via Etcher comme décrit dans le tuto?

Ma remarque concernant le dump restauré et les Bis keys n'est pas très importante, j’émettais juste la possibilité que le dump provienne d'une autre console et que même en forçant comme un malade la restauration via ChoiDuJour ça pourrait déconner si PRODINFO et PRODINFOF n'était pas ceux de la console mais comme je le précise cela est exclu puisque tu as pu déchiffrer le dump grâce à tes Bis keys et NXNandManager, confirmant que les clés sont celles de la console.

Lors du lancement de "fsxxx" via Hekate il ne doit y avoir que du texte qui défile, aucun logo ou image de Kosmos ou quoi que se soit.

Enfin là j'arrive au bout de se qui peut être testé, j'ai épuisé tous les scénario possibles que j'ai en tête, j'ai moi-même refait le tuto sur ma console et j'ai effectivement eu des bugs avec les dernières versions de Hekate ou des fichiers de configuration personnalisés, par contre en suivant le tuto depuis la restauration de la nand (RAWNAND, BOOT0 et BOOT1) jusqu'au lancement via Hekate 4.6 et les fichiers de configuration du package de ChoiDuJour ça a rebooté sans problème donc je ne sais plus trop quoi tenter maintenant.

Modifié par shadow256, 22 septembre 2019 - 22:28.

[FilDuch]

Effectivement j'ai bien fait la manip concernant les fichiers cachés.

 

Boot 0 & 1 effectué selon le tuto (succès).

 

On va partir de l'hypothèse que la rawnand et les Boot0 & 1 sont corrects (et ils pouvaient bien toujours l'être également après la tentative avec ChoiDuJour). Cela veut dire logiquement que le problème est ailleurs et qu'il faut chercher autre chose pour trouver LA solution. Si l'on regarde un peu plus en détail, on s'aperçoit qu'il y a "autre chose" que la rawnand et les Boot0 & 1 et, pour le moment, la voie des partitions RPMB ET GPP est peut-être une piste. Je m'intéresse également à GPTRestore. Je pense toujours qu'il y a un problème dans la séquence de démarrage (ce qui suit RCM) et c'est là qu'il faudrait chercher.

 

Scénario plausible (d'après moi) :

 

  - ChoiDuJourNX perturbe quelque-chose au niveau de la séquence de boot

  - Les tentatives de restores des backups effectués avec succès n'aident en rien (normal,  ce n'est pas le problème)

  - Les tentatives de reconstruction de la rawnand et Boot0 & 1 échouent (normal, ce n'est pas le problème)

 

Bon tout ça c'est bien beau mais j'ai encore pas mal de connaissances à acquérir afin d'aller un peu plus loin. Peut-être que quelqu'un aurait une idée ?

 

Bien à vous tous dans ce forum qui me tient à flot.

[shadow256]

Alors la séquence de démarrage de la Switch, en gros, c'est le programme de la boot rom (non modifiable) qui passe la main ensuite à BOOT0, ensuite ça passe sur BOOT1 et enfin sur les éléments de la RAWNAND, on ne peut agir sur aucun autre élément que BOOT0, BOOT1 et la RAWNAND.

GPT_Restaure ne sera pas utile je pense, s'il y avait un problème à ce niveau là HacDiskMount aurait averti d'un souci.

[FilDuch]

Ok, merci pour les précisions.

 

Je rajoute par rapport à ce que j'ai écrit concernant le scénario plausible :

 

  - En suivant le tuto, tu arrives à tout reconstruire : ça confirme la qualité de ton tuto et il existe bel et bien une différence de l'état de départ entre ta switch et la mienne. C'est cette différence que je dois encore trouver (et la corriger).

 

Je vais maintenant uniquement me concentrer sur la séquence de démarrage, plus particulièrement celle qui passe la main à l'OS (entre le mode RCM et ... l'autre). J'ai cherché des informations détaillées concernant ce point mais je n'y suis pas encore arrivé. Aurais-tu éventuellement d'autres sources intéressantes sur le sujet à m'indiquer ?

 

 - Il semble que la partie du primaire du boot ne soit pas modifiable par le public (stockée en ROM (enfin plutôt EPROM ou EEPROM je pense)). Par contre je pense que, comme sur un PC, il est modifiable par le fabricant qui sait comment faire.
    Dans tout les cas, ChoiDuJourNX n'a donc pas eu la possibilité de le modifier.

 - Je n'ai pas encore eu officiellement la réponse mais je pense que la GPT est la table des partitions de l'eMCC Si elle était corrompue, d'autres problèmes auraient apparus. Le GPTRestore n' amènerai rien de nouveau et n'a rien amené de nouveau (j'ai essayé)

 

Les partitions de l'eMMC sont BOOT0, BOOT1, RPMB ET GPP (USER). La GPP (USER) contient les "sous-partitions" PRODINFO, ..., USER). BOOT0, BOOT1 et GPP (USER) étant supposés valides, il reste plus que la RPMB.

 

J'écris un peu comme je pense et ça m'aide à penser. Je vais maintenant comprendre ce qu'est la RPMB et savoir si elle pourrait être l'origine de mon problème.

 

@+

[eliboa]

 - Il semble que la partie du primaire du boot ne soit pas modifiable par le public (stockée en ROM (enfin plutôt EPROM ou EEPROM je pense)). Par contre je pense que, comme sur un PC, il est modifiable par le fabricant qui sait comment faire.

    Dans tout les cas, ChoiDuJourNX n'a donc pas eu la possibilité de le modifier.

 - Je n'ai pas encore eu officiellement la réponse mais je pense que la GPT est la table des partitions de l'eMCC Si elle était corrompue, d'autres problèmes auraient apparus. Le GPTRestore n' amènerai rien de nouveau et n'a rien amené de nouveau (j'ai essayé)

 

Les partitions de l'eMMC sont BOOT0, BOOT1, RPMB ET GPP (USER). La GPP (USER) contient les "sous-partitions" PRODINFO, ..., USER). BOOT0, BOOT1 et GPP (USER) étant supposés valides, il reste plus que la RPMB.

- Oui la bootrom est, logiquement, non réinscriptible. Bref, c'est pas de là que vient ton problème.

- La GPT est bien la table de partition de la RAWNAND. La GPT primaire est à l'offset 0x200 de RAWNAND et le backup à l'offset 0x747BFFE00 (pour une eMMC de 32 Gb). Comme indique shadow, HacDiskMount te l'indiquerais si tu avais un problème de GPT corrompue.

- A ma conaissance, il n'y a pas de RPMB sur l'eMMC de la Switch, si ?

 

Pour moi, le problème viendrait du bootloader (package1) dans BOOT0 mais je ne saurai dire ce qui ne va pas.

J'ai rapidement parcouru le fil. A un moment donné NxNandManager ne reconnaissait pas tes partitions BOOT0/1, est-ce toujours le cas ?

Modifié par eliboa, 23 septembre 2019 - 10:21.

[FilDuch]

Hello eliboa,

 

- Sur un PC on parle également de ROM mais en fait il s'agit majoritairement de EPROM (on peut faire évoluer la version du BIOS). Je ne sais pas ce qu'il y a dans la switch mais, comme je l'ai écrit, ce ne peux être la source de mon problème car ChoiDuJourNX est incapable d'y modifier quoi que ce soit.

 

- Sous Hecate, je vois sous "eMMC Partitions" la RPMB d'une taille de 4096 kb

 

NXNandManager reconnait bien les Boot0/1. Il m'indique par exemple que l'autoRCM est "on" dans Boot0

[Niko343]

Bonjour à tous,
Plus personne a d'idées pour réparé nos switchs ?

[FilDuch]

La piste RPMB (Replay Protected Memory Block) n'est pas la cause du problème. Nintendo ne l'a pas implémentée pour la switch.

 

Je continue à suivre la piste du démarrage de l'OS (qui passe au moins par Boot0) et je posterai des nouvelles quand j'en auraient.

 

@Niko343 : il serait intéressant de savoir comment en es-tu arrivé là et ou exactement tu es arrivé. Peut-être que le recoupement du déroulement des étapes nous donnerai des informations supplémentaires ? Moi c'est semble-t'il la mise à jour de l'OS (6.01 à 8) par ChoiDuJourNX qui a provoqué la situation. La non possibilité de pouvoir réutiliser les sauvegardes pourrait tendre à me faire penser que ChoiDuJourNX n'a pas modifié uniquement Boot0/1 et la rawnand.

[eliboa]

Pour moi c'est le bootloader (package1) qui doit être foiré. Il est dans BOOT0 et est chiffré. Le kernel et les sysmodules (package2), qui sont dans les partitions BCPKG2, pourraient aussi être en cause mais je crois plus au bootloader qui est foireux. Si j'étais toi et que je voulais vraiment avoir le fin mot de l'histoire, je recompilerais un bootloader open source (Hekate ou Fusée) en y ajoutant des traces pour voir exactement à quel moment survient le problème. Bon après quand tu as un backup de NAND qui te sauve, faut vraiment avoir avoir envie de creuser ^^

Modifié par eliboa, 25 septembre 2019 - 22:17.

[FilDuch]

Merci eliboa pour ces informations et ce conseil.

 

A titre d'information, même avec des sauvegardes complètes et avoir essayé au moins à trois reprises de tout réinitialiser par ChoiDuJour, la switch refuse toujours de démarrer.

[shadow256]

Pour moi c'est le bootloader (package1) qui doit être foiré. Il est dans BOOT0 et est chiffré. Le kernel et les sysmodules (package2), qui sont dans les partitions BCPKG2, pourraient aussi être en cause mais je crois plus au bootloader qui est foireux. Si j'étais toi et que je voulais vraiment avoir le fin mot de l'histoire, je recompilerais un bootloader open source (Hekate ou Fusée) en y ajoutant des traces pour voir exactement à quel moment survient le problème. Bon après quand tu as un backup de NAND qui te sauve, faut vraiment avoir avoir envie de creuser ^^

Là se qui me gêne dans l'histoire est que BOOT0, BOOT1 et les bcpkg jusqu'au 4 sont intégralement reflasher via la méthode ChoiDuJour donc ils ne peuvent pas être incorrectes, tout comme SAFE, SYSTEM et USER qui sont nettoyés durant la procédure. Du coup par déduction il reste bcpkg 5 et 6, PRODINFO et PRODINFOF qui peuvent poser un souci, pour le reste on est sensé avoir un truc au moins fonctionnel non? Comme tu es plus calé que moi au niveau de la nand de la Switch et de son fonctionnement tu auras peut-être des infos que je n'ai pas, moi pour résoudre le souci j'ai tout essayé avec eux mais sans succès malheureusement.

[eliboa]

Oui peut être aussi CAL0 (prodinfo) qui peut être foireux tu as raison. Quand je faisais des test en rechiffrant et restaurant le prodinfo d'une autre console, j'ai pu m'apercevoir que quand prodinfo est pas nickel la console boote pas du tout. Il me semble que je voyais tout de même le logo Nintendo au boot. Mais bon CAL0 est jamais modifié c'est pas son but donc je pense pas qu'une maj fw aille mettre la grouille la-dedans. PRODINFOF ne contient que des logs écrites pendant la calibration de la console. BCPKG2-5 et BCPKG2-6 ne contiennent que le package2 du factory reset et n'ont jamais besoin non plus d'être réécris. 

 

@FilDuch à un moment donné tu disais que tu arriverais pas à dumper toutes les clés avec Lockpick ? Est-ce que ça fonctionne maintenant ? Parce que si Lockpick RCM arrive pas à dumper toutes les clés, y'a des chances que le package1 soit en cause. Ca peut aussi venir de la crypto si tu as foiré quelque chose avec les clés quand tu as généré via ChoiDuJour (je dis ça, j'émet des hypothèses hein ^^).

Modifié par eliboa, 25 septembre 2019 - 23:07.

[FilDuch]

@eliboa :

 

  - tout d'abord, j'aimerais revenir sur un de tes écrit "Il est dans BOOT0 et est chiffré". Pour moi, Boot0 n’apparaît pas comme chiffré (je le vois dans NXNandManager) ?

  - il semble y avoir deux boot programmes (dans Boot0 & Boot1)

  - j'ai essayé de tracer le démarrage en modifiant hekate_ipl.ini en y ajoutant "debugmode=1". Aucune différence et je ne sais pas trop comment compiler une nouvelle version de hekate

  - il ne semble pas que je sois seul au monde avec mon problème : https://gbatemp.net/...-launch.525115/ Malheureusement il n'y a eu aucune fin heureuse à l'histoire

  - je n'arrive toujours pas à tourner sans erreur  lockpick (6 x keyblob 0/1/2/3/4/5/6 corrupt et failed to derive package2 key et missing fs keys skipping es/ssl keys)

 

Les clefs que j'ai donnée au script ultimate-switch-hack-script-master sont celles que j'avais sauvegardées au moment ou je venais d'acquérir la console. Les BIS keys ont été dérivé avec les informations dumpées par Hekate section "print  fuse info & print kfuse info

[eliboa]

@FilDuch,

- les partitions BOOT ne sont pas chiffrées nativement en tant que partitions, à la différence de PRODINFO/F, SAFE, USER et SYSTEM qui sont chiffrées en AES-XTS avec les BIS keys. C'est un chiffrage de disque qui se fait cluster par cluster (comme le fait bitlocker sous Windows). BOOT0 contient par exemple la BCT qui n'est pas chiffrée. En revanche, BOOT0 contient aussi le package 1 qui lui est chiffré avec d'autre clés. Le package1 est déchiffré par le package1ldr qui lui aussi est dans BOOT0 et non chiffré.

- BOOT1 contient aussi un package1 mais il s'agit de celui du SafeMode.

- pour compiler Hekate, Atmosphère ou des homebrews, je te conseille d'installer DevKitPro (choisir le développement Switch + 3DS à l'installation sinon il manquera devkitARM).

- vu le message que lockpick te donne, tu sembles avoir des keyblob (dans BOOT0 il me semble) qui sont mauvais ou corrompus et donc le bootloader n'arrive pas à dériver les clés permettant de déchiffrer le package2 (kernel et sysmodules). Le problème vient donc bien de tes partitions BOOT mais difficile de t'en dire plus. Peut-être que quelque chose a foiré pendant la génération via CDJ (ou mauvaises clés utilisées).

 

  

Modifié par eliboa, 26 septembre 2019 - 08:55.

[FilDuch]

Merci beaucoup pour toutes ces informations.

 

Juste pour essayer de comprendre : si je pars d'une switch avec rien (pas de boot0, boot1 et rawnand et pas de backup), comment trouver les clefs communes ? J'ai lu qu'il est relativement facile de les trouver sur la toile. Est-ce la solution ?

 

De mon coté, j'essaye de reconstruire à partir de rien excepté le fichier prod.keys que j'avais pris soin de sauvegarder avant de tout casser. Je ne vois pas pourquoi les clefs seraient corrompues ou non valides maintenant. Ayant suivit pas à pas (excepté la partie Lockpick) le tuto, j'arrive à l'exécuter sans erreur. Chose étrange, lorsque j'essaye de réaliser la partie ChoiDuJour par moi-même en donnant prod.keys au complet ou juste les clefs nécessaires, ChoiDuJour refuse de me générer le package en m'indiquant des erreurs. La partie "génération du package" se déroule par contre sans problème si je passe par le tuto et que j'introduit le prod.keys au complet. Que fait le tuto de différent par rapport à moi ?