157 replies to this topic

[eliboa]

@shadow, je pense que ça doit être possible mais là ça dépasse mes compétences actuelles en crypto. Je ne saurai pas dire comment sont calculées les clés présentes dans les keyblobs, je sais pas contre qu'elles sont indispensables pour déchiffrer le package1 et donc indispensable pour booter.

Si FilDuch n'a aucun backup complet de BOOT0, ça risque d'être compliqué mais je vais essayé de me renseigner sur le sujet.

Ce message a été modifié par eliboa - 01 octobre 2019 - 15:42.

[shadow256]

@shadow, je pense que ça doit être possible mais là ça dépasse mes compétences actuelles en crypto. Je ne saurai pas dire comment sont calculées les clés présentes dans les keyblobs, je sais pas contre qu'elles sont indispensables pour déchiffrer le package1 et donc indispensable pour booter.
Si FilDuch n'a aucun backup complet de BOOT0, ça risque d'être compliqué mais je vais essayé de me renseigner sur le sujet.

Ouai, j'ai regardé rapidement et ça n'a pas l'air simple en effet. Mais du coup un autre truc qui me pose question, normalement en utilisant Etcher pour flasher la partition BOOT0 ça devrait supprimer l'ensemble des données de la partition avant écriture non? J'ai toujours pensé que l'utilisation de ce genre d'outil supprimait toute les données de la partition avant d'écrire, je me serais trompé?

[eliboa]

Ouai, j'ai regardé rapidement et ça n'a pas l'air simple en effet. Mais du coup un autre truc qui me pose question, normalement en utilisant Etcher pour flasher la partition BOOT0 ça devrait supprimer l'ensemble des données de la partition avant écriture non? J'ai toujours pensé que l'utilisation de ce genre d'outil supprimait toute les données de la partition avant d'écrire, je me serais trompé?

Je ne sais pas comment fonctionne etcher mais je pense que ça ouvre un pointeur sur le premier cluster/bloc de la partition du disque puis que ça écrit la totalité de l'image (raw copy). Donc si l'image est plus petite que la partition, les clusters suivants ne sont pas touchés. A moins que le programme décide explicitement de supprimer physiquement (zero bytes) le reste, il n'y a pas de raison que ça efface les clusters suivants. Très peu de programmes font en réalité de la suppression physique de données (quasi tout le temps logique). NxNandManager fonctionne comme ça, mais ca vaut le coup que je teste tout de même pour ces BOOT0 de 0x180000 bytes.

Ce message a été modifié par eliboa - 01 octobre 2019 - 17:01.

[shadow256]

Je ne sais pas comment fonctionne etcher mais je pense que ça ouvre un pointeur sur le premier cluster/bloc de la partition du disque puis que ça écrit la totalité de l'image (raw copy). Donc si l'image est plus petite que la partition, les clusters suivants ne sont pas touchés. A moins que le programme décide explicitement de supprimer physiquement (zero bytes) le reste, il n'y a pas de raison que ça efface les clusters suivants. Très peu de programmes font en réalité de la suppression physique de données (quasi tout le temps logique). NxNandManager fonctionne comme ça, mais ca vaut le coup que je teste tout de même pour ces BOOT0 de 0x180000 bytes.

Logique en effet et raison très probable expliquant pourquoi il est dit de ne jamais formater les partitions lors du montage des partitions sur le PC, ça se tien.

[FilDuch]

J'ai les sauvegardes suivantes :

 

  - 1ère : Boot0, Boot1 et rawnand.bin (le Boot0 semble être vide)

  - 2ème : Boot0, Boot1, rawnand.bin, 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 et USER

 

Je vous envoie tout ce qui pourrait aider (je pense surtout Boot0 et Boot1 de la sauvegarde en espérant qu'ils ne soient pas vides)

[eliboa]

J'ai les sauvegardes suivantes :

 

  - 1ère : Boot0, Boot1 et rawnand.bin (le Boot0 semble être vide)

  - 2ème : Boot0, Boot1, rawnand.bin, 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 et USER

 

Je vous envoie tout ce qui pourrait aider (je pense surtout Boot0 et Boot1 de la sauvegarde en espérant qu'ils ne soient pas vides)

Seul un BOOT0 de 4Mo peut servir.

[eliboa]

Bien reçu tes fichiers, mais effectivement ils sont tous les deux vides.

Est-ce que quand tu restaures un boot0 fait par choidujour et qu'ensuite tu le dumpes via memloader, il est toujours vide ? Je veux éliminer un problème de dump/restore de l'emmc.

[FilDuch]

Je bug sur le dump via memloader ? Je l'ai dumpé par nxnandmanager. Est-ce que cela te convient ?

 

J'ai remarqué que les keyblobs (keyblob_key_00 à 05 sont écrit dans le fichier prod.keys. Ca peut aider ?

[FilDuch]

Je vais revenir sur la notion de Boot0 vide :

 

Qu'entends-tu pas vide et j'ai compris que cela te semble anormal et que cela pourrait expliquer pourquoi "lockpick" ne fonctionne pas (il ne trouve pas les bonnes clefs "keyblob" ou elles n'ont pas été initialisées). Que remarques-tu de différents sur les autres (Boot0 normaux) qui ont été dumpé sur des consoles fonctionnelles ?

 

Je me pose cette question car je trouve toujours "étrange" que les deux sauvegardes effectuées par hekate produisent des fichiers Boot0 "vides" et que c'est pas normal. Ok, j'ai peut-être fait deux mauvaises manipulations, mais pourquoi alors le tuto produit semble-t'il également des fichiers Boot0 vides ?

 

Ne serait-t'il pas possible d'envisager que, lors du démarrage de la switch, une partie de la séquence de démarrage s'occupe d'écrire les keyblobs au bon endroit de manière persistante (ou pas) dans Boot0 ?

 

Je n'ai que très peu de connaissance en la matière et j'essaye un peu de suivre les chemins qui me semblent les plus logiques.

[FilDuch]

La création du fichier Boot0 par choidujour me semble aussi vide (par le volume des données qu'il contient) mais ce point reste encore à vérifier.

Ce message a été modifié par FilDuch - 02 octobre 2019 - 09:17.

[shadow256]

Alors t'aurais pas un antivirus qui foutrait le bordel, en plus comme je t'ai dit le package que je t'avais envoyé contient un BOOT0 (et d'ailleurs tous le package) valide.

[eliboa]

A FilDuch, quand je dis que le BOOT0 est vide, je veux dire qu'il ne contient que des zéros. Ca ne change rien au poids du fichier car un byte contenant des zéros fait toujours un byte.
Tu peux ouvrir le fichier avec un éditeur hexadécimal (HxD par ex) et tu verras que tous les bytes sont a zéro.
Je regarde les fichiers que tu m'as envoyés ce soir.

[eliboa]

Le fichier que tu m'as envoyé est bien ok sur les 0x180000 premiers bytes mais est donc vide ensuite. Pas de problème de backup/restore donc. Les keyblobs sont manquants. Là pour savoir comment les réparer je sais pas te dire pour le moment

Ce message a été modifié par eliboa - 02 octobre 2019 - 22:19.

[FilDuch]

Merci pour l'information,

 

Entre temps j'ai regardé le contenu binaire des Boot0 : que des zéros ! J'avais pourtant fait des dumps avec hekate (une version assez ancienne sous 5.?)

 

Apparement les keyblobs sont fixées dans Boot0 de manière permanente je suppose. Est-il possible de savoir qui les écrits et à quel moment ? En tout cas pas ChoiDuJour ni Etcher via MemLoader.

 

J'avais écrit que je voyais dans Prod.Keys les clefs  keyblob_key_00 à 05 Est-ce que ce sont ces clefs qui doivent être présentes dans Boot0 ? Si c'est le cas, connait-on les adresses ou il faudrait les mettre ? Avec tout ces "si", on pourrait utiliser un éditeur d'HEX pour les y mettre manuellement ?

[FilDuch]

@shadow256 :

 

Je doute qu'un antivirus puisse modifier le contenu d'un fichier. Les zéro me semble pas provenir de ça.

 

Le Boot0 que tu m'as envoyé est certes valide mais je ne pense pas qu'il contienne les clefs keyblobs de ma console.

[shadow256]

@shadow256 :
 
Je doute qu'un antivirus puisse modifier le contenu d'un fichier. Les zéro me semble pas provenir de ça.
 
Le Boot0 que tu m'as envoyé est certes valide mais je ne pense pas qu'il contienne les clefs keyblobs de ma console.

Il y a des antivirus qui font des trucs bizarres parfois mais bon comme l'a dit @eliboa au moment de l'écriture ça semble se faire correctement, il manque donc ta partie personnelle de BOOT0 mais on peut donc éliminer le problème d'antivirus. Pour info c'est pas juste des clés à mettre dans le fichier, c'est un peu beaucoup plus compliquer que çà.

Non il ne contient évidemment pas les clés, le BOOT0 que j'ai fourni est celui de ChoiDuJour donc c'est la première partie de BOOT0, celle qui est donc générique pour toutes les consoles.

[FilDuch]

Je peux parfaitement m'identifier à celui qui a eu le même problème que moi (restore de Boot0 en provenance de choidujour cause la corruption de la console) : https://gbatemp.net/...ion-5-1.517515/

La solution a passé par l'envoi d'un Boot0 non complet ainsi que SBK/TSEC à un "maestro" de la switch (rajkosto). Il a ensuite généré un Boot0 valide qui a fonctionné. Evidemment je ne sais pas comment il a réussi à produire un Boot0 valide pour une console spécifique ???

 

Point de situation :

 

  - Boot0 installé selon le tuto ne contient au moins pas les keyblobs empêchant un démarrage normal de la switch (messages : initializing... Identified package1 <'20180220163747'>, keyblobversion 4 , loaded package1 and keyblob, ... puis bloqué)

  - Les tutos que j'ai trouvé et essayé sur le net ne permettent pas d'apporter une solution au problème que je rencontre (je me demande même si ils sont réellement applicables en cas de la perte totale de Boot0 ?)

  - Je ne suis pas le seul à rencontrer ce problème

 

"Reste" maintenant à trouver la procédure qui permet de créer un Boot0 spécifique à une console. ChoiDuJour "ne fait" que de créer un squelette qui peut servir de base pour le rendre compatible avec une console spécifique( pour autant que l'on sache comment faire ?)

 

Merci à tous pour le temps que vous investissez pour essayer de faire revivre ma switch (d'autres en mauvais états comme la mienne pourraient aussi en bénéficier)

[eliboa]

@Filduch, bon j'ai regardé un peu comment se passait la crypto des keyblobs.

Déjà, bonne nouvelle, une fois déchiffré, le contenu des keyblobs n'est pas unique à une console. Il est donc possible de déchiffrer les keyblobs d'une console saine, de le chiffrer avec les clés de la console brické puis de les réinjecter dans BOOT0 de cette console. Donc en théorie, pour ta console ce n'est pas foutu car tu as bien un dump de toutes tes clés de côté.

Ensuite, sur la crypto, les keyblobs sont effectivement déchiffrés avec des clés uniques à la console dérivées de la sbk (bootrom) et TSEC key.

Sachant que ce qui peut être déchiffré, peut-être rechiffré en utilisant les mêmes clés, il "suffit" de modifier le code (par ex de lockpick) qui déchiffre les keyblobs pour qu'il chiffre au contraire des keyblobs déchiffrés d'une autre console.

Pour le moment je suis en plein dev sur NxNandManager mais quand j'aurai terminé je pourrai regardé comment faire un tel programme, sans garanties car la crypto n'est pas mon fort.

Sinon tu pourrais demander de l'aide sur le discord ReSwitched, schmue, SciresM ou d'autres sauront sûrement t'aidé mieux que moi

 

PS :

Dumping the SBK and TSEC key of any single system should be enough to derive all key material on the system, prior to 6.2.0.

Donc dès lors que tu as ces deux clés, rien n'est foutu ^^

Ce message a été modifié par eliboa - 03 octobre 2019 - 17:49.

[FilDuch]

@eliboa : merci pour ton retours. J'avais lu ce que tu as écrit concernant " Dumping the SBK and TSEC key of any single system should be enough to derive all key material on the system, prior to 6.2.0" exprimé sous différentes formes sur différents forums. J'ai bien compris que ma console pourra "revivre" un jour (c'est juste ne question de temps) et je vais continuer mes investigations.

 

Est-il juste de comprendre que les clefs "keyblob", contenues dans le fichier prod.keys, sous une forme décryptée (en clair), sont communes à toutes les consoles ? Le problème principal est de savoir comment les chiffrer avant de les écrire aux bons emplacements dans Boot0 ? Ultérieurement elles seront décryptées pour être utilisées sous cette forme.

 

Je me pose la question de comment j'en suis arrivé là et pourquoi n'y a-t'il pas plus de personnes qui sont dans mon cas et qui utilisent avec succès le tuto de shadow256. La réponse pourrait-être (cela demande à être validé) que seulement une partie de Boot0 est écrite sur la console. La partie concernant les keyblobs n'est pas affectée. Dans mon cas, j'ai au moins une fois essayé de restorer Boot0 avec hekate. Comme le Boot0 sauvegardé ne contenait (pour une raison ???) que des zéros, l’entièreté de Boot0 à été sur-écrit par des zéros. Ais-je vu juste ou pas ?

[shadow256]

@FilDuch : Oui, voilà pourquoi ton BOOT0 est maintenant corrompu, tu as restauré au préalable un BOOT0 ne contenant rien donc on aura beau s'acharner avec le tuto de ChoiDuJour ça ne suffit pas, il faut trouver un moyen de restaurer les données manquantes et spécifiques à ta console sur ta nand.