157 réponses à ce sujet

[FilDuch]

C'est ce que j'ai fait, mais le résultat n'est pas positif (essayé en 6.1 & en 5.1). Tout se passe corerctement lors de ces deux étapes. Rien n'y fait, c'est comme si il y avait un problème lors du démarrage de l'OS Nintendo (un peu comme MBR sous PC). Je continue à chercher ce qui pose problème (le matériel semble ok et la reconstruction intégrale n'y fait rien). C'est ailleurs que le soucis se situe il me semble.

[shadow256]

Là par contre si tu as testé toutes les solutions que je t'ai proposé en plus en MP je ne vois pas comment t'aider d'avantage, si tu fais tes tests avec une carte SD formatée en EXFAT essais de la formater en FAT32 plutôt, on ne sait jamais, ça peut marcher.

[FilDuch]

J'ai essayé de créer une carte SD en FAT32 par le tuto mais rien ne s'écrit sur la SD (ça reste indéfiniment à la ligne "copie en cours...") Même scénario si je tente EXFAT. Ca fonctionnait auparavant (il y a quelques jours).

 

J'essaye de traquer toutes les erreurs et j'ai remarqué que pour obtenir les clefs BIS (clefs liées à ma switch et non celles "générique" pour tous), je dois passer par un "Print fuse info" et un "Print TSEC keys" pour ensuite injecter les fichiers générés (fuse_cached.bin & tsec_keys.bin) dans "Derive BIS keys". Il devrait être aussi possible d'utiliser la commande TegraRcmSmash.exe -w biskeydump.bin mais le message d'erreur "keyblob decrypted using current SBK & TSEC keys not valid!" s'affiche. Le message d'erreur pourrait provenir d'un Boot0 non consistant consécutif à un état de l'autorcm ??? Ca vous dit quelque-chose )

 

Bonne soirée à tous

[FilDuch]

Le problème concernant la carte SD en FAT32 sembleêtre maintenant réglé.

 

Aussi bien biskeydump que Lockpick_RCM me retourne des erreurs lors de leur exécution. Quelqu'un pourrait me confirmer que ces deux programmes peuvent bien fonctionner avec une console de jeux qui n'est plus en état de fonctionner normalement ?

 

Lockpick me retourne des keyblob 0 à 5 corrupt & Failed to derive package 2 keys & Missing FS key. Skipping ES/SSL keys

[shadow256]

Ouai alors je pense que là le souci est important donc soit tu fais quelque chose d'incorrect pendant le tuto de la restauration de la nand via ChoiDuJour ou soit le problème est que ta nand est corrompu, ceci dit si c'était la seconde solution normalement le tuto de ChoiDuJour ne pourrait être effectué. Là on dirait que Lockpick-RCM (pas Lockpick au passage, se sont deux choses différentes, le premier est un payload et le second un homebrew) ne trouve pas des éléments essentiels pour dériver les clés se qui me fait dire que la restauration de la nand ne se passe pas bien pour X ou Y raisons, après par contre je serai bien incapable de te dire où ça cloche exactement.

[FilDuch]

J'ai bien compris la différence entre LockPick (.nro) et LockPick-RCM (.bin) et j'essaye d'utiliser avec succès LockPick-RCM car je ne peux pas en l'état passer par LockPick.

 

Faire quelque-chose de pas correct en suivant le tuto, c'est bien possible. J'avais pensé, peut-être à tort, que le tuto était justement fait pour m'aider à reconstruire une nand & Boot0/1 corromps. Comme il faut passer par la lecture des clefs (je pense que c'est discutable) avant de pouvoir reconstruire une nand propre, je ne vois pas trop comment faire. Ton tuto semble bien spécifier l'ordre me semble-t'il : lecture des clefs pour ChoiDuJour puis génération de la nand ainsi que Boot0/1 ?

 

Suis-je totalement faux dans mes dires ?

 

Merci en tout cas de me permettre d'y voire un peu plus claire.

[shadow256]

Le tuto de ChoiDuJour sert effectivement à reconstruire un firmware à partir de "rien", du moins à partir de bien peut de choses. Dans l'ordre il faut avoir les Bis Keys de la console (normalement tu les as celles-ci et elles servent au moment d'écrire sur la nand) ainsi que certaines clés énumérées dans le tuto pour créer le package via ChoiDuJour mais ces clés ne sont pas uniques à la console contrairement aux Bis Keys. Une fois les clés obtenues il faut créer le package via ChoiDuJour, écrire les différents éléments selon les procédures indiquées dans le tuto et enfin démarrer une fois avec le patch nocmac (élément créer par ChoiDuJour). C'est un tuto très précis, il ne faut prendre aucune liberté par rapport à celui-ci, il faut le suivre très scrupuleusement.

[FilDuch]

Effectivement, mes BIS keys me sont connues et j'essaye d'obtenir celles nécessaire pour ChoiDuJour (certaines autres dont les noms sont connus de presque tous). Je pense les avoir enregistré avant de casser ma switch mais ChoiDuJour me retourne des erreurs et ne créé plus ce dont j'ai besoin pour continuer la procédure.

 

Je suis scrupuleusement ton tuto et procède par ordre (je ne vais pas à la prochaine étape tant qu'une erreur subsiste). L'étape 3, intitulée "Récupération des clés de chiffrement pour Hactool ou ses dérivés", demande de récupérer les clefs afin de pouvoir les fournir à ChoiDuJour. C'est cette étape que je n'arrive pas à franchir. Aussi bien LockPick-RCM que biskeydump ne fonctionne. Je ne peux donc pas continuer.

 

Que fais-je de faux ?

[shadow256]

Probablement rien pour le coup, au pire je sais que tu as une seconde console, tu peux te servir de celle-ci pour récupérer les clés permettant la création du package de ChoiDuJour. Les seuls clés importantes à garder pour ta console brickées sont les Bis Keys, le reste tu peux les récupérer d'une autre console.

Modifié par shadow256, 18 septembre 2019 - 16:34.

[FilDuch]

Ok,

 

Je pense (peut-être à tord) qu'il n'est pas possible de récupérer les clefs "communes" en utilisant lockpick-rcm ou biskeydump si la switch est totalement "malade" (pas de valid rawnand.sys & Boot0+1). On les trouve soit "simplement" sur la toile (car elles sont les mêmes pour toutes les consoles) ou soit on les a déjà dumpées (c'est mon cas). Je les ai utilisées mais Choidujour me sort l'affichage suivant :

 

C:\Users\Toto\Desktop\ChoiDuJour>ChoiDuJour.exe --keyset=keys.txt "FW 5.1"

 

ChoiDujour 1.1.0 by rajkosto

uses hactool by SciresM (https://github.com/SciresM/hactool)

visit https://switchtools.sshnuke.net for updates and more Switch stuff!

 

Using source firmware files from folder FW 5.1

      1 [main] hactool 38356 dtable::stdio_init: couldn't make stderr distinct from stdout, Win32 error 6

C:\Users\Philippe\Desktop\ChoiDuJour\FW 5.1\014600c0d509e5ac49eed34eaef62b28.cnmt.nca is missing Title ID or Content Type in hactool output!

 

Le .nca manquant ne fait effectivement pas partie du package récupéré pour la 5.1

 

J'ai peut-être un formatage inadéquat du fichier keys.txt qui contient 12 clefs dans mon cas ?

[shadow256]

Tu récupères le firmware via cette page? Pour ton fichier de clés je ne sais pas, moi je fais tout via mon script qui s'occupe de créer et de gérer tout ces éléments donc j'ai strictement rien à faire, il m'avertis de se qui manque ou de se qui ne va pas si nécessaire donc depuis le temps j'ai totalement oublié se qu'il faut dans les fichiers, de toutes façons c'est noté dans le tuto.

Non, si ta console est vraiment bien brickée alors tu ne pourras pas récupérer les clés communes (et même les Bis Keys ça peut poser problème), par contre il me semblait que tu avais une seconde console sur laquelle il est possible de les récupérer, sinon effectivement sur internet ces clés sont facilement trouvables.

[FilDuch]

Je récupère les firmwares sur https://team-xecuter...rmwares.129233/  et ça semble être les mêmes.

 

J'ai effectivement deux consoles et le résultat des dumps effectués ont donné les mêmes valeurs (tout au moins en ce qui concerne les clefs communes). Ce sont celles là que j'essaye d'injecter dans choixdujour mais le format du fichier keys.txt est peut-être inadéquat.

 

Quand j'utilise ton script (option "Préparer un firmware pour la mise à jour manuel avec ChoiDuJour?", il m'est demandé le fichier keys.txt. Quand je le lui donne, ça donne :

 

 Fichiers clés non trouvé, veuillez suivre les instructions.

 

Veuillez renseigner le fichier de clés dans la fenêtre suivante.

Appuyez sur une touche pour continuer...

        1 fichier(s) copié(s).

Traceback (most recent call last):

  File "keys_management.py", line 250, in <module>

    create_choidujour_keys_file(sys.argv[2])

  File "keys_management.py", line 171, in create_choidujour_keys_file

    keys_source_list = test_keys_file(keys_file)

  File "keys_management.py", line 87, in test_keys_file

    sha256_list[i][1] = hashlib.sha256(binascii.a2b_hex(item[1].lower().encode('utf-8'))).hexdigest()

binascii.Error: Odd-length string

[1596] Failed to execute script keys_management

Il semble que le fichier de clés nécessaire à ChoiDuJour n'ait pu être créé, veuillez vérifier votre fichier de clés et relancer le script.

Pour vous aider, regarder les clés incorrectes qui se sont affichées juste avant.

Appuyez sur une touche pour continuer...

 

Je pense que mon fichier contenant les clefs (12 entout) n'est pas valide (format : "clef = 16 ou 32 caractères hexa") ?

[shadow256]

Juste indiques-lui le fichier de clés complet que tu dump sans le modifier, par contre il faut que tu passes par les paramètres du script pour le supprimer (option "supprimer le fichier de clés utilisé par Hactool"). Je pense que tu modifies mal manuellement le fichier de clés se qui pose problème.

[FilDuch]

J'avais mis un bon moment à comprendre que lorsqu'un fichier des clefs a été enregistré, il n'était plus possible d'en utiliser un autre. J'avais donc du manuellement effacer keys.txt dans \tools\hactool_based_programs.

 

Merci, ça fonctionne effectivement si on lui indique le prod.keys sans modification. Par contre je ne sais pas trop pourquoi. Le fichier copié sous \tools\Hactool_based_programs semble correspondre un à un à l'original. Peut-être qu'il est patché (--fspatches ...) ou modifié avant traitement dans ton script par ChoiDuJour.

 

Je me retrouve maintenant au début de l'étape " Installation du firmware et réinitialisation de la console". Quand j'injecte memloader (V3) et que je sélectionne  l'option "ums_emmc", le message suivant s'affiche :

 

Read 194 bytes from 'ums_emcc_ini', parsing

Cannot find = separator in kv pair '       >' on line 0, skipping

 

Pour avoir déjà effectué deux fois la procédure au complet (6.01 et 5.1 en ExFAT), je trouve cela étrange. Je ne peux interprété le fichier ums_emmc_ini.bin car il est chiffré binaire. Une idée peut-être ?

 

Le but recherché maintenant c'est de voir le résultat en 5.1 FAT32

[shadow256]

Salut,

Bon je pense, enfin, avoir trouver pourquoi la réinitialisation via ChoiDuJour pose problème, il faut utiliser Hekate 4.6 au moment du premier démarrage (quand on boot fsxxx.kip). En utilisant la dernière version de Hekate ça semble poser problème et provoquer un écran noir, ayant refait le tuto pour tester j'ai effectivement eu ce comportement alors qu'avec Hekate 4.6 le boot a fonctionné. J'avais pas refait ce tuto depuis un moment et je pensais que a fonctionnait encore avec les dernières versions de Hekate mais bon il semblerait que non.

Pour ton souci via Memloader là par contre je ne sais pas, en plus le fichier de configuration ne doit pas comporter l'extension ".bin". Si tu utilise mon script pour monter la partition "rawnand" il se passe quoi?

Enfin, pour ton interrogation sur le fichier de clé copié par mon script il est normal que se soit le même que ton "prod.keys" fourni, mon script fait juste un traitement pour en extraire les clés nécessaires à ChoiDuJour car ce dernier n'aime pas qu'on lui fournisse des clés qu'il ne connaît pas et il bloque le traitement quand il en voit une.

[FilDuch]

Hello,

 

Effectivement ta remarque concernant la version de Hekate correspond assez exactement à ce que j'avais écrit le 12 septembre :

 

Voilà, j'ai effectué sans erreur tout le tuto et je suis arrivé à l'étape 6 (premier démarrage). Sous hecate, l'option "launch" me propose soit "stock" ou soit *s_601_exfat_nocmac_nosigch". Si je choisi l'option deux, je me retrouve dans l'image "Atlas NX KOSMOS The All-inOne Package" pendant un certain temps (environ 30 secondes) puis tout devient noir.

 

J'avais utilisé la version 5.01 de Hekate, ça confirme tes dires.

 

Maintenant il ne me reste "plus" qu'à arriver une nouvelle fois au bout de ton tuto et je vais choisir le format exFat et 6.01 Apparement les choses ne se passe plus comme avant et j'ai remarqué un problème (que j'avais pas avant) au niveau de memloader.

 

Je me suis trompé lors de l'écriture "ums_emmc_ini.bin" et il s'agissait de "ums_emcc_ini"

 

En ce qui concerne mon fichier prod.keys, il ne contient que les clefs strictement nécessaire et qui correspond à ce que l'on trouve sur la toile ainsi qu'à ton écrit. Le problème est donc situé ailleurs (?)

 

Si je t'ai bien compris, tu me demandes de monter la partition "rawnand" par ton script, Je ne sais pas si cela correspond à ce que tu attends :

 

 Quelle partie de la mémoire souhaitez-vous monter?

 

1: Nand de la console (rawnand).

2: Carte SD.

3: Boot0.

4: Boot1

Tout autre choix: Retour au menu précédent.

 

Sélectionner la mémoire à monter: 1

*********************************************

***    CONNECTEZ LA SWITCH EN MODE RCM    ***

*********************************************

1) Connecter la Switch en USB et l'éteindre

2) Appliquer le JoyCon Haxx : PIN1 + PIN10 ou PIN9 + PIN10

3) Faire un appui long sur VOLUME UP + appui court sur POWER (l'écran restera noir)

En attente d'une Switch en mode RCM...

TegraRcmSmash (32bit) 1.2.1-3 by rajkosto

Unknown key 'pwroffHoldTime' for BOOT section on line 12, skipping

Wanted device not connected yet, waiting...

Looking for devices matching the pattern *VID_0955&PID_7321*

Opened USB device path \\?\usb#vid_0955&pid_7321#5&2a753ff6&0&9#{aa0dbd45-3117-f331-5c49-76bf65225042}

RCM Device with id 0082050B0000001889283E6401101062 initialized successfully!

Uploading payload (mezzo size: 92, user size: 124088, total size: 190304, total padded size: 192512)...

Smashing the stack!

Smashed the stack with a 0x7000 byte SETUP request!

Switching to command mode due to READY.

Sending C:\Users\Philippe\Desktop\Ultimate-Switch-Hack-Script-master\tools\memloader\mount_discs\uboot/ums_emmc.scr.img (86 bytes) to address 0x80100000

Sending C:\Users\Philippe\Desktop\Ultimate-Switch-Hack-Script-master\tools\memloader\mount_discs\uboot/u-boot.elf (450879 bytes) to address 0x80110000

Booting AArch64 with PC 0x80110000...

BOOT command sent successfully! Exiting.

 

Le disque devrait être monté sur votre système. Pour le démonter, éjecter le périphérique à l'aide du bouton "retirer le périphérique en toute sécurité" situé sur la barre des tâches en bas à droite puis forcer l'extinction de la Switch en maintenant le bouton POWER pendant 10 secondes (Attention à ne pas écrire/lire de données pendant cette opération sous peine d'endommager gravement les données de votre nand/sd).

Pour explorer la mémoire interne de la Switch vous devez utiliser l'outil HacDiskMount lancé en tant qu'administrateur (nécessite d'avoir les biskey pour décrypter les données mais non nécessaire pour faire un dump de la nand). Si vous souhaitez faire un dump de la nand via cette méthode, le dump peut prendre du temps (environ trois heures).

 

Parfois, le disque n'est pas reconu automatiquement. Vous devez ouvrir le gestionnaire de périphérique, trouver le périphérique avec un point d'exclamation nommé "Périphérique d’entrée USB" (testé sous Windows 7), faire un clique droit dessus, cliquer sur "Mettre à jour le pilote...", cliquer sur "Rechercher automatiquement un pilote mis à jour" puis cliquer sur "Fermer". Le périphérique devrait maintenant être utilisable.

Souhaitez-vous lancer le gestionnaire de périphérique? (o/n):

 

Je ne vois apparaître aucun nouveau device (sous Windows10)

 

Cette étape fonctionnait auparavant.

[shadow256]

Alors je pense donc que le lancement via Memloader (celui de mon script) a fonctionné, maintenant tu devrais pouvoir utiliser HacDiskMount. Tu as utilisé la bonne fonction et le script semble s'être déroulé correctement d'après se que je vois, après faudrait savoir se que t'affiche ta console en parallèle. Si tu n'arrives vraiment pas à le lancer n'hésites pas à restaurer le dump de ta nand que tu as (même s'il ne fonctionne pas en l'état) puis de refaire le tuto de ChoiDuJour à partir de l'étape 5 et avec le pack que je t'ai fourni.
Edit: Autre façon de savoir si la partie de la nand est montée correctement, si le message de formatage nécessaire s'affiche cela signifie qu'elle est bien montée sur le système.

Sinon je t'ai fourni via les messages privés un pack contenant se qu'il faut pour restaurer (pack créé via ChoiDuJour et Hekate 4.6 avec le fichier de configuration spécifique à la restauration via ChoiDuJour), vraiment j'insiste sur le fait d'utiliser le firmware 5.1.0 et pas un firmware supérieur.

Modifié par shadow256, 21 septembre 2019 - 22:00.

[FilDuch]

Voilà, j'ai réussi à reconstruire le tout en 5.1 (avec extension exFAT) et lorsque je redémarre avec hekate V4.6, l'image Atlas NX / KOSMOS / The All-in-One Package (avec la sorte de galaxy sur la gauche) reste figée... A noter qu'au niveau de TegraRcmGUI, la console reste en mode RCM.

[shadow256]

Faut juste avoir les fichiers de Hekate 4.6 ainsi que le fichier de configuration généré par ChoiDuJour (à mettre dans le dossier "bootloader") et le fichier "fsxxx.kip1" à la racine de la SD, elle ne doit contenir absolument rien d'autre. Ensuite booter le payload de Hekate 4.6 et booter la configuration "fsxxx". Là dans se que tu sembles décrire tu as le logo de Atlas donc tu as mis d'autres choses sur la SD se qu'il ne faut pas faire, vraiment n'avoir que se que je dis dans ce message sur la SD.

[FilDuch]

Exact, j'ai essayé les deux variantes :

 

  - variante une : avec le contenu ayant pour source l'établissement de la SD via ton script (profil Atmosphère recommandé (option 2)) -> résultat décrit dans mon message précédent

  - variante deux : avec juste le strict nécessaire que tu m'as conseillé ->

 

    - Initializing...

 

      Identified pkg1 ('20180220163747'),

      keyblob version 4

 

    Loaded pkg1 and keyblob

 

    puis l'écran reste figé et la console reste en mode RCM (en vert sur TegraRCM)