157 réponses à ce sujet

[Bibiz]

@SuperFilDuch, as-tu essayé de démarrer ton firmware via hekate en faisant Launch>Stock ?

[SuperFilDuch]

@Bibiz, quand je le fais, j'ai le message d'erreur "Unknow PKG1 version. Failed to launch firmware"

 

J'ai aussi remarqué que si j'effectue "Print TSEC keys", j'ai le message "Unknow pkg1 version for reading TSEC firmware"

 

J'ai comme l'impression que PKG0 n'est pas en très bonne santé (je peux me tromper)

[Bibiz]

On dirait en tout cas qu'il il y a un problème avec ton firmware effectivement c'est bizarre...

Surtout que la restauration en 6.1 a l'air de s'être bien passée. 

Tu as bien toujours actuellement via hekate 7 efuses de grillés ? 

Modifié par Bibiz, 07 septembre 2019 - 22:50.

[SuperFilDuch]

Oui, toujours 7 efuses grillés.

 

Je suis assez certain que la switch démarre (power on) en mode normal, le système 6.1 essaye de démarrer mais, n'y arrivant pas, la switch se met automatiquement en mode RCM. Le démarrage automatique en mode RCM n'est donc qu'une conséquence d'un dysfonctionnement du démarrage du système 6.1

[Bibiz]

Clairement oui, donc je pense que tu es bon pour essayer le tuto de shadow256 qui pourrait te permettre de régler tout ça. 

[shadow256]

Mais il est très bien ce tuto, bon clairement c'est bien repompé sur le mien (il y a des phrases qui sont trop communes avec les miennes et surtout on reconnaît clairement ma façon d'écrire et de m'exprimer dans certaines phrases) mais c'est hyper bien fait, clairement le tuto est mieux que le mien (disons très précis, là où moi j'apprends la méthode de manière plus large l'autre choisi une démarche très précise se qui convient plus à certains utilisateurs; en plus il y a même les copies d'écran pour aider) donc en cas de souci, même si tu suit l'autre tuto tu peux poster sur mon sujet et je t'aiderai.

En tous cas clairement passes-en par là, je pense qu'il y a effectivement quelque chose de corrompu dans ton dump de nand ou, plus gênant mais çà on le verra après, dans ta nand.

Je me permet d'ajouter que mon script contient pas mal de fonctions qui peuvent aider à l'exécution de ce tuto si on l'utilise bien.

Modifié par shadow256, 08 septembre 2019 - 02:28.

[SuperFilDuch]

Je n'en suis pas certain mais le fait de ne pas pouvoir effectuer "Print TSEC keys" sous hekate_ctcaer est blocant pour la suite ?

 

En tout cas un grand merci pour vos conseils et vos compétences qui me permettront, peut-être un jour, de remettre ma switch en état

 

Cdt.

[shadow256]

Il te faut tes Bis keys pour déchiffrer la nand avec HacDiskMount ainsi que quelques clés communes pour créer le package avec ChoiDuJour, sur ce point il me semble que mon tuto est plus précis mais les clés communes tu les trouveras facilement et les Bis Keys seront dumpables via le payload Biskeydump.

[SuperFilDuch]

J'ai tenté de vérifier l'intégrité du fichier NAND sauvegardé et j'ai lu que l'utilitaire HaxDiskMount pouvait amener la réponse. J'ai donc ouvert le fichier et constaté rien d'anormal (j'ai monté les différentes parties (PRODINFO, ..., USER) et les ai également dumpé). Est-il juste d'en déduire que le contenu du fichier est cohérent et complet ? J'avais déjà reçu un message de succès lors de la sauvegarde par hekate.

 

Il me reste encore à valider Boot0 et Boot1

 

Cdt

[SuperFilDuch]

 Point de situation :

 

  - je n'ai pas encore entrepris la reconstruction des données contenues dans la mémoire.

  - si je peux comprendre qu'un incident est survenu avec ChoiDuJourNX, je ne m'explique pas pourquoi la restauration de mes sauvegardes (j'en ai effectué deux depuis l'acquisition de la switch il y a environ une année) n'ont pas provoqué l’effet escompté.

  - j'ai joué avec la switch en version 6.1 durant une année sans problème

  - aussi bien les sauvegardes que les restaurations se passent sans erreurs.

  - j'ai remarqué que suite à la restauration de Boot0/Boot1, kekate m'annonce comme quoi l'Autorcm est "enabled". Je le modifie systématiquement à "disabled", mais cela ne résout pas le problème. Il est fort possible que l'affichage de hekate soit faux
    https://github.com/C...kate/issues/263

 

Question : quelle(s) pourrai(en)t être la/les cause(s) du problème si l'on enlève le doute en ce qui concerne la validité des sauvegardes ?

 

Cdt et bonne journée à tous

[shadow256]

Donc tu utilisais l'auto-RCM avant de faire ton dump et en ce cas il faudrait savoir comment il avait été activé pour le désactiver via la même méthode. Sinon, comme je te l'ai dit, tu peux aussi utiliser NXNandManager pour vérifier l'auto-RCM sur ton fichier BOOT0 et il pourra même le désactiver pour le fichier, permettant de le restaurer ensuite sur la console sans l'auto-RCM.

Enfin bon selon moi tu perds ton temps à chercher, refais ta console avec ChoiDuJour, se sera plus simple et tu pourras repartir sur quelque chose de propre.

[SuperFilDuch]

Non, ce n'est pas exact, je n'ai jamais activé l'auto-RCM et, comme je l'ai indiqué, il semblerait que c'est une fausse information retournée par hekate.

 

Plus simple de repartir sur quelque chose de propre ? Je devrais avoir à disposition deux sauvegardes valides (reste encore à le vérifier complètement) et je pense qu'il est plus facile de les utiliser et cela devrait fonctionner. Si l'on part de l'hypothèse que les sauvegardes sont clean, alors cela voudrait dire que le problème est ailleurs et qu'une reconstruction totale (ou presque) ne garanti pas que c'est la solution.

 

En tout cas merci pour tes informations et je vais encore attendre avant de tout reconstruire (enfin essayer de le faire car je n'ai que peu de compétences en ce qui concerne ce sujet)

 

Cdt.

[SuperFilDuch]

Il se pourrait que j'y voie un peu plus clair...

 

NXNandManager arrive bien à ouvrir les rawnand.bin mais pas les Bootx.bin (Input file/drive is not a valid NX storage type). Il semblerait donc que Boot0.bin et Boot1.bin soient corrompues mais pourquoi ??? Les sauvegardes ont pourtant été effectuée par  hekate correctement. Vraiment étrange à min que NXNandManager ne soit pas capable d'ouvrir les Bootx.sys de la version 6.1 !

[shadow256]

Si si, normalement il n'y a aucun souci, NXNandManager peut ouvrir tous type de fichiers de la nand et les BOOT0 ont massivement été testés, d'autant plus jusqu'à la 6.1.0.

[SuperFilDuch]

Merci pour ton retour.

 

Je pars donc de l'hypothèse que Boot0.sys et Boot1.sys sont corrompus (raison ???) et c'est ce qui empêche le boot normal de la switch. Quand j'appuie sur "Power on", la console démarre en mode "non RCM", mais n'y arrivant pas (Bootx.sys en mauvais état), elle passe en mode RCM automatiquement.

 

Est-ce que je vois juste ?

 

Deuxième inconnu : pourquoi ChoiDuJourNX n'a pas effectué le travail correctement ??? (je verrai ce point plus tard)

 

La restauration des sauvegardes (y compris les Boot0 & 1) a provoqué le dysfonctionnement total.

 

Connais-tu une version "light" permettant de recréer les fichiers défectueux sans passer par toutes les étapes de ton tuto ?

 

Cdt.

[shadow256]

Non, il te faudra recréer le package via ChoiDuJour mais coup de chance pour toi, tu peux créer le package pour la 6.1.0 et tu n'auras plus qu'à restaurer BOOT0 et BOOT1 se qui est très simple. Bizarre le nom de tes fichiers ceci dit, normalement c'est BOOT0.bin et BOOT1.bin, (même pas certain pour l'extension en ".bin" même) à moins que sur les nouvelles versions de Hekate ceci ait changé mais il ne m'a pas semblé lire un tel changement dans les changelogs du payload.

Pour le souci que tu as eu via ChoiDuJourNX là par contre je ne sais pas, parfois ça déconne semblerait-il, perso j'ai jamais eu le moindre souci mais pour certains utilisateurs ça a parfois eu un résultat non attendu.

Modifié par shadow256, 09 septembre 2019 - 22:48.

[SuperFilDuch]

J'ai déjà commencé en ce qui concerne la partie ChoiDuJour et j'ai même tentè de restaurer des Bootx trouvé sur le net mais j'ai maintenant des fichiers Bootx valides (au sens de la structure) mais pas compatibles avec les informations de la NAND. Au démarrage, j'ai un écran bleu (c'est normal). Tu dis que c'est très simple de restaurer Boot0 et Boot1 (le contenu de la NAND est "par chance" valide) mais si tu pouvais me dire comment faire sachant que je n'arrive pas à générer les clefs BIS ?

 

Cdt.

[shadow256]

Première chose, tu restaures la Rawnand 6.1.0 que tu as, ensuite tu restaures BOOT0 et BOOT1 créé pour le firmware 6.1.0 par ChoiDuJour, si ta rawnand est bonne alors pas besoin des Bis Keys. Et je te déconseille fortement de prendre des fichiers de nand trouvés sur internet, c'est vraiment trop dangereux à mon sens de faire çà.

Par contre si çà ça ne fonctionne pas et que tu ne peux pas générer tes Bis Keys là j'aime autant te dire que ça va être vachement plus chiant à gérer, pour ne pas dire impossible. Comme je le dis souvent, avoir les clés uniques à la console est indispensable, en cas de problèmes ça peut vraiment sauver la console et ces dumps ne sont pas à prendre à la légère. T'as testé quelle méthode(s) pour le dump des Bis Keys et avec quel(s) résultat(s)?

[FilDuch]

Merci pour tes informations.

 

 

Merci pour ton avertissement mais je n'ai pas récupéré un rawnand sur le net mais "simplement" Boot0 et Boot1 pour la version 6.1 afin de voir le changement (l’écran passe du noir du mode RCM et bleu lié au crash de l'OS). J'ai également contrôlé la validité des Boot0/1 par NxNandManager).

 

Tu dis d'utiliser ChoiDuJour (pas ChoiDuJourNX) et je ne sais pas trop quoi spécifier au niveau du paramètre --keyset ? J'ai bien dumpé les keys de ma switch (keys.prod je crois) mais je ne pense pas qu'il s'agit de ça.

[shadow256]

Utilise mon script qui permet de te créer un package avec ChoiDuJour facilement (et si tu va avoir besoin de ton prod.keys) et mon script va épuré le fichier de clés que tu va lui fournir pour en sortir juste les clés dont il a besoin, ça t'évitera de t'embêter avec les "warn" de ChoiDuJour lorsqu'il rencontre des clés qu'il ne connaît pas et qui l'empêche de fonctionner (c'est expliqué dans mon tuto sur ChoiDuJour d'ailleurs).

Je me doute bien que tu n'as pas récupérer la rawnand sur internet mais même pour les autres fichiers je ne l'aurais pas fait perso. Après ton résultat m'inquiète franchement car si les fichiers étaient bon deux solutions, soit la rawnand est aussi corrompu ou soit tu te plante de firmware sauvegardé sur celle-ci, par exemple ça pourrait être 6.0.1.

Tu n'as pas tes Bis Keys dans ton "prod.keys"? Tu l'as dumper comment? Et s'il te plaît, réponds aussi à ma question sur se qu'il se passe quand tu veux dumper tes Bis Keys via Lockpick-RCM ou/et via Biskeydump parce qu'encore une fois selon moi tu perdras moins de temps à repartir de zéro, bon sans tes Bis Keys c'est impossible mais ton souci avec ton dump me semble insoluble au vu des résultats que tu as obtenu jusque là. A un moment il ne faut plus trop chercher à comprendre, il faut résoudre le problème.