157 replies to this topic

[shadow256]

@FilDuch : Tu as essayé de flasher BOOT0 et BOOT1 via Etcher avec le package que je t'ai fourni via message privé? Ce package est fonctionnel, c'est certain, je l'ai testé moi-même pour ma console.

[FilDuch]

Oui et je viens de réessayer, même résultat.

 

Je pense que tu en es certain mais je pose la question quand même : les Boot0&1 sont universels pour une version donnée de la switch (ex. 5.1) ?

[shadow256]

Disons qu'au vu de se que fait ChoiDuJour je suppose que oui, cependant là @eliboa pourrait répondre mieux que moi je pense car il maîtrise bien mieux la structure de la nand de la Switch que moi.

[eliboa]

Oui et je viens de réessayer, même résultat.

 

Je pense que tu en es certain mais je pose la question quand même : les Boot0&1 sont universels pour une version donnée de la switch (ex. 5.1) ?

Nope de ce que je sais non, les keyblobs de BOOT0 contiennent des clés uniques pour chaque console. Cf => https://switchbrew.o...esystem#Keyblob et la déchiffrement du package1 se fait après initialisation du TSEC et utilise la device key => https://switchbrew.o...#Key_generation

Ce message a été modifié par eliboa - 28 septembre 2019 - 10:20.

[FilDuch]

D'après ce que j'ai trouvé sur la toile, seul Boot1 est compatible sur toutes les consoles tournant la même version de l'OS. Boot0 contient des informations spécifiques pour chaque console, donc le Boot0 que tu m'as envoyé ne semble pas utilisable sur ma console.

[shadow256]

Nope de ce que je sais non, les keyblobs de BOOT0 contiennent des clés uniques pour chaque console. Cf => https://switchbrew.o...esystem#Keyblob et la déchiffrement du package1 se fait après initialisation du TSEC et utilise la device key => https://switchbrew.o...#Key_generation

OK mais là il y a un truc qui me perturbe du coup, quand on flash BOOT0 avec Etcher on supprime l'ensemble des données de la partition avec un package commun, ChoiDuJour ne nécessite aucune clé unique à la console pour créer ses packages.

[eliboa]

OK mais là il y a un truc qui me perturbe du coup, quand on flash BOOT0 avec Etcher on supprime l'ensemble des données de la partition avec un package commun, ChoiDuJour ne nécessite aucune clé unique à la console pour créer ses packages.

Effectivement c'est vraiment étrange. Soit les keyblobs sont alimentés au boot ou peut-être que la bootrom charge boot1 (safemode bootloader) a la place de boot0 et que la console passe du coup sur un espece de mode recovery mais ce ne sont que des suppositions...

[FilDuch]

Pour moi, le scénario qui tient encore la route reste le même :

 

  - ChoiDuJourNX a perturbé quelque-chose au niveau de la séquence de boot (passage du mode RCM à l'OS

  - 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)

 

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). Par contre un fichier prod.keys est bien produit. Est-il possible que toutes les clefs recherchées par Lockick n'existent pas sous la version 5.1 ?

 

Y aurait'il une explication pourquoi le script ne rend compte d'aucune erreur lorsque je lui donne le prod.keys sauvegardé initialement (avant migration) et que ce même prod.keys fait planter ChoiDuJour lorsque je le lui indique manuellement ? Que fait le script de ce fichier avant de le lui passer à ChoiDuJour ?

 

@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.

[shadow256]

Comme déjà expliquer avant il n'y a que BOOT0, BOOT1 et la RAWNAND de modifiable, si le problème n'est pas matériel alors il vient obligatoirement d'un de ces éléments et comme @eliboa l'a expliqué ça vient probablement de BOOT0 qui merde quelque part. Le problème ne peut pas venir du passage entre le mode RCM et Horizon (l'OS de la Switch) car il y a un payload qui se lance entre temps donc le mode RCM n'est plus actif, il n'est de toutes façons pas possible de passer du mode RCM à Horizon puisqu'il y aura toujours un payload en intermédiaire pour démarrer dans le cas du passage par le RCM.

Pour la création du package de ChoiDuJour via mon script il y a une analyse du fichier de clés fourni qui est faite et qui extrait les clés nécessaires si elles existent, ensuite on règle les options puis la création du package se fait en utilisant le fichier de clés créé car ChoiDuJour est tatillon pour les clés qu'il peut utilisé, s'il n'en connait pas une il stop, raison pour laquelle j'ai utilisé un tel traitement du fichier de clés.

[FilDuch]

Ok, je vais admettre que le soucis vient de Boot0/1 & RAWNAND. Il est quand même étonnant que, suite au restore complet de ma switch avec des sauvegardes effectuées avec succès, je ne puisse pas retrouver un état stable (Boot0/1 et RAWNAND ont été pourtant été réécrit à leur origine).

 

Pour essayer de mieux comprendre : premièrement je mets la switch en mode RCM, en deuxième je lui injecte le bootloader hekate. Depuis ce dernier, tu m'indiques qu'il démarre un payload avant Horizon. De quel payload s'agit'il ?

 

FS510-exfat_nocmac_nogc.kip1  est d'après ce que j'ai lu une partie personnalisable d'un CFW. Sais-tu de quel CFW fait'il partie (hekate ?) et ce qu'il fait plus ou moins exactement ?

 

En ce qui concerne la création du package manuel ,et ce n'est à rien y comprendre, j'ai repris mon fichier que j'avais créé avec uniquement les clés nécessaire pour choidujour et ça fonctionne. La seule chose que je me souvienne d'avoir fait en dernier, c'est que j'ai renommé le fichier en .keys au lieu de .txt. Je ne vois vraiment pas le rapport et maintenant je n'arrive plus à reproduire le problème (même avec l'extension .txt)

[shadow256]

Comme tu le dis toi-même tu boot en RCM puis tu lance Hekate, le voilà ton payload, Hekate. A partir de ce moment là tu n'es plus en RCM.

Pour le fichier ".kip1" c'est un fichier permettant d'appliquer une modification (ici le patch nocmac) au lancement d'Horizon et en fait il n'y a pas de CFW au vrai sens du terme sur la Switch, on fait en réalité un abus de langage car en fait se que l'on appel CFW est le même genre de remplacement de modules de Horizon mais juste à plus grande échelle. Et Hekate n'est pas un CFW, c'est plutôt un bootloader comme pourrait l'être le Grub pour le PC.

Alors par contre pourquoi ça ne refonctionne pas même après réécriture du firmware là je n'en sais rien. Faudrait que tu upload ton dump de BOOT0 (celui qui provient de ton dump sensé être bon, le dump que tu as fait en tout premier lieu et qui n'a pas fonctionné après restauration) et que tu m'envoie le lien en MP pour que je regardes de plus près cet élément pour commencer, je pense que tu peux aussi envoyé le lien à @eliboa qui t'aidera peut-être s'il en a le temps. Peut-être même que nous envoyer le dump complet (fais-en un zip pour qu'il prenne bien moins de place) avec ton prod.keys le plus complet serait encore mieux, je sais que normalement on ne demande pas de fournir ces clés mais là si on veut pouvoir t'aider il faudrait qu'on puisse vraiment pouvoir voir en détail là où ça ne va peut-être pas et pour cela on aura besoin des clés.

Enfin pour ton problème de clés avec ChoiDuJour je ne comprends pas se que tu faisais mais bon, si le package se cré via mon script alors cela signifie que les clés requises se trouvent dans le fichier, il n'y a pas plus à chercher et de toutes façons je t'ai déjà envoyé un package créé et fonctionnel donc inutile de tenter de le refaire, le problème n'est pas là.

[eliboa]

Alors par contre pourquoi ça ne refonctionne pas même après réécriture du firmware là je n'en sais rien. Faudrait que tu upload ton dump de BOOT0 (celui qui provient de ton dump sensé être bon, le dump que tu as fait en tout premier lieu et qui n'a pas fonctionné après restauration) et que tu m'envoie le lien en MP pour que je regardes de plus près cet élément pour commencer, je pense que tu peux aussi envoyé le lien à @eliboa qui t'aidera peut-être s'il en a le temps. Peut-être même que nous envoyer le dump complet (fais-en un zip pour qu'il prenne bien moins de place) avec ton prod.keys le plus complet serait encore mieux, je sais que normalement on ne demande pas de fournir ces clés mais là si on veut pouvoir t'aider il faudrait qu'on puisse vraiment pouvoir voir en détail là où ça ne va peut-être pas et pour cela on aura besoin des clés.

+1

 

@FilDuch, Pour moi y'a pas photo, le problème vient des keyblob de BOOT0.

Si tu regardes le code de Lockpick, voilà ce que fait le programme :

 for (u32 i = 0; i <= KB_FIRMWARE_VERSION_600; i++) {
    minerva_periodic_training();
    se_aes_crypt_block_ecb(8, 0, keyblob_key[i], keyblob_key_source[i]); // temp = unwrap(kbks, tsec)
    se_aes_crypt_block_ecb(9, 0, keyblob_key[i], keyblob_key[i]); // kbk = unwrap(temp, sbk)
    se_aes_key_set(7, keyblob_key[i], 0x10);
    se_aes_crypt_block_ecb(7, 0, keyblob_mac_key[i], keyblob_mac_key_source); // kbm = unwrap(kbms, kbk)
    if (i == 0) {
        se_aes_crypt_block_ecb(7, 0, device_key, per_console_key_source); // devkey = unwrap(pcks, kbk0)
        se_aes_crypt_block_ecb(7, 0, new_device_key, per_console_key_source_4x);
    }

    // verify keyblob is not corrupt
    emummc_storage_read(&storage, 0x180000 / NX_EMMC_BLOCKSIZE + i, 1, keyblob_block);
    se_aes_key_set(3, keyblob_mac_key[i], 0x10);
    se_aes_cmac(3, keyblob_mac, 0x10, keyblob_block + 0x10, 0xa0);
    if (memcmp(keyblob_block, keyblob_mac, 0x10)) {
        EPRINTFARGS("Keyblob %x corrupt.", i);
        gfx_hexdump(i, keyblob_block, 0x10);
        gfx_hexdump(i, keyblob_mac, 0x10);
        continue;
    }
 }

6 keyblob (KB_FIRMWARE_VERSION_600 + 1) sont lus sur l'eMMC dans le bloc de keyblobs à l'offset 0x180000, soit dans BOOT0 (0x000000 -> 0x400000) et sont comparés (memcmp) au MAC calculé à partir de la keyblob_mac_key

Si la comparaison échoue, le keyblob est considéré comme corrompu.

Je crois que le MAC est généré par la SBK ou TSEC key je ne sais plus, en tout cas surement par une clé stockée ou dérivée dans la bootrom. 

Ce message a été modifié par eliboa - 30 septembre 2019 - 15:15.

[FilDuch]

MP envoyé.

 

Je me demande comment lockpick peut fonctionner lorsque la switch est "totalement" briquée et que Boot0 n'est pas initialisé (Boot0 est créée valide par ChoixDuJour et il est mis en mémoire bien après) ?

[eliboa]

MP envoyé.

 

Je me demande comment lockpick peut fonctionner lorsque la switch est "totalement" briquée et que Boot0 n'est pas initialisé (Boot0 est créée valide par ChoixDuJour et il est mis en mémoire bien après) ?

Ton fichier BOOT0 est complétement vide. Pas étonnant que tu n'arrives pas à dumper tes clés ^^

Vérifies celui que tu nous as envoyé, si c'est celui de ta console, tu n'iras pas loin. Dans ce cas, il faut reprendre le tuto de shadow pour utiliser choidujour et regénérer les bons fichiers.

Ou alors envoies-nous directement le BOOT0 généré par choidujour.

Ce message a été modifié par eliboa - 30 septembre 2019 - 23:40.

[shadow256]

@eliboa : Je pense que c'est le fichier "BOOT0" de son dump de la version originale de son firmware 6.X.X (on ne sait pas vraiment lequel), ça ne doit pas être le dump de se qui est actuellement sur sa nand.

[FilDuch]

Le fichier Boot0 est celui qui correspondait à l'original (version 5.x).

 

Je vous ai envoyé maintenant celui que j'ai généré ce jour par ChoiDuJour (5.1). Rien n'a changé et lockpick (effectué après la reconfiguration) est toujours en erreur.

[eliboa]

Le fichier Boot0 est celui qui correspondait à l'original (version 5.x).

 

Je vous ai envoyé maintenant celui que j'ai généré ce jour par ChoiDuJour (5.1). Rien n'a changé et lockpick (effectué après la reconfiguration) est toujours en erreur.

Bon j'avais jamais fait gaffe mais le BOOT0 généré par ChoiDuJour ne contient que les 0x180000 premiers bytes de la partition. C'est à dire qu'il ne contient que la BCT et le pagckage1. Il manque les keyblobs à l'offset 0x180000.

Donc si tes keyblobs sont corrompus, ce qui semble le cas, le BOOT0 généré depuis ChoiDuJour n'y changera rien.

Deux choses :

- Peux-tu dumper le BOOT0 de ta console via NxNandManager (ouvrir BOOT0 via memloader) stp et m'envoyer ton BOOT0 au complet (il doit faire 4096 Ko) stp? Si ça fonctionne pas, réessaye d'abord de restaurer le BOOT0 généré par CDJ.

- Peux-tu essayé d'injecter le payload briccmii sur ta console et activer/désactiver le brick. Ce payload peut réparer les keyblobs de Customer Data dans BOOT0. Et nous remonter les erreurs si il y en a.

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

[FilDuch]

C'est fait, aucun changement pour lockpick après avoir passé par l'étape briccmii.

[eliboa]

C'est fait, aucun changement pour lockpick après avoir passé par l'étape briccmii.

Bon les keyblobs du BOOT0 qui est dans ta console sont complètement vides.

Et le BOOT0 générés par ChoiDuJour ne contient pas les keyblobs. Voilà d'où vient ton problème.

As-tu un backup de BOOT0 qui a été fait quand ta console fonctionnait ? Si oui, envoies le moi, je vais essayé de reconstruire un nouveau BOOT0 complet.

[shadow256]

Bon les keyblobs du BOOT0 qui est dans ta console sont complètement vides.
Et le BOOT0 générés par ChoiDuJour ne contient pas les keyblobs. Voilà d'où vient ton problème.
As-tu un backup de BOOT0 qui a été fait quand ta console fonctionnait ? Si oui, envoies le moi, je vais essayé de reconstruire un nouveau BOOT0 complet.

Alors oui, le BOOT0 de ChoiDuJour ne fait que un peu plus d'un MB. Cependant ici ta remarque m'amène à une question, serait-il possible donc de reconstruire un BOOT0 si l'utilisateur a ses clés uniques (device_key, tsec_key, bis_key_XX, etc...) mais sans avoir le dump de celui-ci, genre dans son cas car je pense qu'il n'a pas un dump correct de BOOT0 justement se qui a induit ce souci dès le départ (si oui ça pourrait faire une belle fonction à NXNandManager çà)?

Ce message a été modifié par shadow256 - 01 octobre 2019 - 14:25.