157 réponses à ce sujet

[FilDuch]

Rebonjour,

 

J'ai définitivement perdu mes keyblobs sous forme encryptée dans Boot0 (0x180000, 0x180200, ...). Bien que les keyblobs, sous une forme en claire, soient les mêmes pour toutes les consoles, l’algorithme d'encryption basé sur le SBK qui permet d'encoder les keyblobs (qui deviennent par cette opération unique pour chaque console) dans Boot0 est encore très mystérieux et je n'ai trouvé personne qui semble connaître exactement, et d'une version à l'autre, comment faire.

 

J'ai néanmoins réussi a me retrouver dans l'état d'une console qui démarre en mode "normal" (non bricolé !) Actuellement en 6.2, je devrais pouvoir faire évoluer les versions mais je resterai dans le mode "normal".

 

Est-ce que quelqu'un pourrait me répondre sur les points suivants :

 

  - puis-je faire évoluer maintenant la console d'une manière officielle (via internet) sans me faire banir (j'ai tout reconstruit depuis zéro et je ne pense pas qu'il y a de trace de mon bricolage ) ?

  - a quoi servent exactement les keyblobs ? Ma console fonctionne correctement en mode "officiel" et semble bien se passer des keyblobs.

  - le fait de ne pas avoir de keyblobs valides est la raison du pourquoi je ne peux plus "bricoler" ?

 

Bien à vous tous

[shadow256]

Bon déjà une bonne chose que ta console refonctionne au moins un minimum. Se serait intéressant de savoir comment tu as réussi à faire repartir ta console, ça pourrait en aider certains.

Après normalement tu dois pouvoir lancer de nouveau un CFW je pense, tu peux toujours tester en créant une emunand. Les Keyblobs ne sont plus utilisées pour booter en firmware 6.2.0 et supérieur, il me semble que c'est le Tsec qui prend le relais à partir de ce firmware.

[FilDuch]

La question que je me pose est la suivante :

 

  - A quoi peuvent bien servir les keyblobs à partir de la version 6.2.0 d'Horizon ?

 

Comme shadow256 l'a écrit et qui est confirmé par l'état de ma switch : les keyblobs ne sont pas nécessaire pour démarrer l'OS officiel Horizon (en tout cas pour la version 6.2.0). Je pense, mais n'en suis vraiment pas certain, que les keyblobs sont indispensables par contre pour démarrer les CFW.

 

Est-ce que quelqu'un a des précisions en ce qui concerne la relation entre les keyblobs et les CFW ?

 

@shadow256 : je n'arrive pas à créer une arborescence "choidujour" par ton tuto pour la version 6.2.0. Lorsque je rentre 6.2.0, le tuto me redemande la version (et ainsi de suite si je spécifie toujours 6.2.0)

[shadow256]

C'est normal, ChoiDuJour ne peut créer de package au-delà du 6.1.0.

[eliboa]

@FilDuch tu peux nous expliquer comment tu as réussi à booter en 6.2 ? 

Dans le principe, les keyblobs sont juste des emplacements sur la mémoire morte, des blobs (binary large objects) qui contiennent des clés crypto. Après leur utilisation est multiple est variée.

 

Par contre je ne savais pas qu'ils n'étaient plus utilisés à partir de la 6.2 mais je me souviens que toute la crypto du bootloader a changé avec cette version donc ça ne m'étonne pas effectivement.

FilDuch, maintenant que tu bootes en 6.2 j'imagine que tu as fait un full dump, tu peux essayer de downgrader en version < 6.2 et voir si tes keyblobs sont régénérés éventuellement.

[FilDuch]

Avant de faire un retour sur "comment j'ai fait pour pouvoir à nouveau démarrer en 6.2", je désire encore consolider les étapes qui m'on permis d'y arriver.

 

La question urgente que je me pose c'est de savoir si et comment je peux démarrer un CFW (atmosphere, reinx, ...) sans les keyblobs. Je n'y arrive simplement pas et c'est peut-être normal.

 

Après avoir effectué et vérifier cette fois une sauvegarde complète (rawnand & Boot0/1), je tenterai un downgrade en version inférieur (ex 6.1). J'ai de fort doutes en ce qui concerne la régénération des keyblobs.

[shadow256]

@FilDuch : Se serait pourtant intéressant de savoir comment tu as procéder pour qu'au moins la console redémarre en 6.2.0, ça nous permettrait tout simplement de faire des tests dans les mêmes conditions ou d'établir des théories.

[FilDuch]

J'ai pas mal surfé sur les différents forums qui ont pour thème "faire du bien à notre switch" et j'ai effectivement réussi à redémarrer Horizon en version 6.2.0 sur ma switch. Je ne prétend pas avoir tout compris, mais en partant de mes maigres connaissances et tenter de comprendre le super tuto de shadow256 (merci à lui de m'avoir supporté :-) ), j'ai pu comprendre ce qui se discutait sur les autres forums sous une forme très différente de ce que l'on peu trouver sur notre forum (faut s'accrocher !).

 

En fait il y a brick et brick ! Le cas de figure que j'ai rencontré n'a pas de solution "toute faite" et donc même si l'on trouve plein de tutos (il y en a vraiment beaucoup), aucun ne couvrait le problème que j'avais (enfin que j'ai encore un peu). Le cas de mon brick était produit par Boot0 et Boot1 qui ne contenaient aucunes données valides. Ce qu'il faut d'abord comprendre c'est qu'en aucun cas les tutos ne s'occupe de l'entièreté de Boot0 & Boot1. Seule une partie est régénérée.

 

Après quelque temps et avec l'aide de shadow256 et eliboa, nous nous sommes aperçu de la non intégrité de Boot0 & Boot1 par l'absence des keyblobs dans Boot0. Ces keyblobs sont des clefs identiques à toutes les switchs mais cryptées en utilisant la SBK (Secure Boot Key) qui est unique pour chaque switch. Ces clefs sont utilisées pour divers applications (je ne sais pas exactement lesquelles) et sans elles, l'application de fonctionne pas. Dans mon cas, l'application était liée au démarrage de Horizon.

 

Ce que j'ai appris au fil de mes recherches c'est que les keyblobs ne sont plus utilisées pour le démarrage d'Horizon à partir de la version 6.2.0. La (partielle) solution à mon problème consistait donc à  "trouver" un tuto qui intégrait Boot0 et Boot1 et qui était préparé pour une version 6.2.0 ou ultérieur. Choidujour ne pouvant être utilisé dans mon cas (gère les versions < 6.2.0), j'ai trouvé ce que je cherchais dans le forum GBATEMP. L'URL du sujet y attenant est : https://gbatemp.net/...urposes.533830/ Assez long à lire, on pourra trouver trace de l'endroit des fichiers à télécharger et s’apercevoir que le sujet n'est pas encore clos (recherche de la régénération des keyblobs)

 

Je me retrouve actuellement avec une switch "normale" en version 6.2.0 tout à fait capable de lancer des jeux officiels. Apparemment les keyblobs ont besoin d'être présentes afin de pouvoir démarrer des CFW.

 

Maintenant je suis occupé d'une part à la recherche de la régénération des keyblobs et, d'autre part à comprendre, à quoi servent exactement les keyblobs.

[FilDuch]

Pour régénérer les keyblobs, j'ai téléchargé l'utilitaire linkle (https://github.com/M...linkle/releases) et taper la commande "run linkle keygen -k prod.keys". Le résultat affiché donne en autre les keyblobs "encrypted_keyblob_01/02/03/04/05" que j'ai introduit dans Boot0 par memloader + nxnandmanager + edit par HxD (full dump + restore). Le tout donne maintenant un Boot0 consistant au niveau des keyblobs et lockpick_rcm & biskeydump sont contents (et moi aussi !)

 

Je vais continuer et essayer de démarrer un CFW.

 

Je suis sur le bon chemin :-)

[FilDuch]

Voilà c'est terminé, ma switch refonctionne comme avant que je la casse. Comme c'était un des buts recherché, j'espère que d'autres vont pouvoir bénéficier de mon expérience et pourquoi pas faire revivre leur switch comme la mienne ?

 

Quelques inconnus subsistent :

 

  - pourquoi les sauvegardes n'ont pas fonctionné. Elles m'avaient pourtant été annoncées comme succès ?

  - pourquoi choidujour m'a blessé ma switch (je l'ai définitivement cassée par restore des dumps Boot0/1 non valides) ?

 

Un point que j'avais omis d'appliquer : vérifie toujours tes sauvegardes indépendamment de leurs résultats (surtout quand tu vas effectuer quelque-chose de potentiellement destructeur).

 

Comme je l'ai écrit à quelqu'un de notre forum que j'ai appris à apprécier indépendamment de nos prises de positions dès fois divergentes :

 

Comme je te l'ai annoncé dès le début, je suis quelqu'un qui cherche à comprendre ce qu'il fait et pourquoi il le fait. C'est "mon" moyen de progresser et un jour peut-être pouvoir en faire profiter d'autres.

 

Je trouve cet écriture plutôt juste et je continuerai à l'appliquer.

 

Bien à vous tous

[shadow256]

Bravo et merci pour les explications détaillées et surtout d'avoir insisté à ce point pour trouver comment réparer ta console, il est certain que cela servira à d'autres utilisateurs. De mon côté je vais m'atteler à tester ta solution et je l'ajouterai probablement à mon tuto de débrickage d'une Switch dans une partie un peu à part, ce genre d'info est très précieuse et très rare, tout comme de voir un utilisateur aussi obstiné et encore bien joué à toi car ça a été payant au final.

PS: Je suis aussi du genre à aimer comprendre les choses autant que possible, d'ailleurs je n'aurais pas écrit mes scripts si ça n'était pas le cas, écrire des scripts nécessite justement de bien comprendre comment fonctionne chaque chose pour enchainer les différentes actions au mieux.

[eliboa]

Bien joué FilDuch, content d'apprendre que ta console a pu être reparée.

[shadow256]

@FilDuch : Alors j'ai bien compris jusqu'à l'étape Linkle, par contre ensuite je ne comprend pas se que tu as édité avec HXD pour réintégrer les clés, quand je fais des recherches des différentes "encrypted_keyblob" dans un de mes fichiers "BOOT0" valide je ne les trouvent pas donc si tu pouvais nous en dire plus sur la procédure exacte avec HXD ça pourrait être utile (ofset à partir duquel tu as introduit les clés, etc...).

[mounavri]

FilDuch d"abord bravo pour avoir réussi à refaire renaitre ta Switch d'une mort certaine, tu es un miraculé, non tu es le patient 0, et je crois que tu es obligé de nous faire un bon tuto, ça sera peut être ton premier tuto mais peut-être pas le dernier  

[FilDuch]

Petit retour d'informations...

 

J'ai réinstallé tous mes jeux (environ une dizaine) et aucun problème n'est a signaler. J'ai utilisé choidujournx pour la faire évoluer en 8.1.0 et cette fois aucun soucis à signaler aussi bien en ce qui concerne la mise à jour (j'ai effectué et vérifié une sauvegarde de tout avant la migration) que des jeux. Je vais maintenant (c'était le but initial) ajouter des jeux très récents.

 

@shadow256 : j'ai utilisé la commande run linkle keygen -k prod.keys et réintroduit le résultat (affiché sur la fenêtre du cmd) des clefs keyblobs cryptées en l'injectant dans Boot0 (adresse 0x00180000 pour keyblob 0, 0x00180200 pour keyblob 1 et ainsi de suite pour les autres). Pour les voir apparaître dans le résultat de linkle, il faut que la forme en claire soit présente dans le fichier prod.keys (keyblob_00, keyblob_01, ...). Les entrées générées pour boot0 sont encrypted_keyblob_00, encrypted_keyblob_01 et ainsi de suite. Les valeurs en claire des keyblobs sont communes pour toutes les switchs (donc facile à les introduire pour linkle). Encore un grand merci pour toute l'aide que tu m'as apportée

[shadow256]

@FilDuch : Oui donc tes explications semblent bien être se que j'avais cru comprendre, cependant moi quand je regarde dans un de mes BOOT0 original à l'ofset 0x180000 mes key_blob ne sont pas présentes (quelqu'en soit la forme, chiffrées ou non), j'ai d'autre données à la place et qui vont en plus jusqu'à l'ofset 0x184020 (je précise que mon prod.keys est aussi correct et contient toutes les clés nécessaires). Bon pour l'instant j'ai juste fait des tests en flashant un BOOT0 avec une remise à zéro à partir de l'ofset 0x180000 puis en lui insérant mes encrypted_key_blob en respectant le saut d'ofsets nécessaire et j'ai juste eu le droit à un bel écran noir (firmware 4.0.1); par contre j'ai pas testé en restaurant en premier lieu un BOOT0 du firmware 6.2.0 comme tu l'as fait puis en insérant les key_blob, faudrait que je me fasse une emunand pour faire cela car pas trop envie de griller mes Efuses pendant les manipulations, je tiendrai informer des résultats de mes différents tests et j'écrirai le tuto dès que j'aurai trouvé les manipulations exactes à faire car pour l'instant il y a encore des zones d'ombre à éclaircir. Et de rien, ton problème est passionnant à étudier et il est l'un des chainons manquant à la résolution d'un brick particulier de la Switch, va juste falloir que je me replonge dans les explications du BOOT0 sur switchbrew, maintenant que j'ai les clés nécessaires il ne doit pas me manquer grand chose pour trouver comment restaurer la partie manquante à partir de l'ofset 0x180000 de ce fichier; to be continued.

[FilDuch]

D'après https://switchbrew.o...lash_Filesystem, on peut trouver jusqu'à 32 keyblobs (ça dépend des versions) à partir de l'adresse 0x00180000 avec une longueur de 0x200 réservé par keyblob (seulement une partie des 0x200 est effectivement utilisé). les adresses à partir de 0x0018000 pour une longueur de 32 x 0x200 sont donc réservées exclusivement pour les keyblobs. Rien d'autre ne doit s'y trouver et cela ne semble pas dépendre de la version de l'OS. Néanmoins, comme toi, j'ai trouvé du code "étrange" dans ces adresses (voir dans mes réponses) et je me demande d'ou ce code provenait ? J'avais pourtant pensé avoir suivi ton tuto "à la lettre" ?

 

Une fois que ton tuto inclura la notion du brick que j'ai rencontré, je pense que passablement de monde y sera très intéressé 

 

Cdt.

[FilDuch]

Je viens d'ajouter les jeux récents et je n'ai rencontré aucun problème particulier. Il m'a juste fallu comprendre qu'il était nécessaire de régénérer les clefs (via lockpick_rcm) après migration d'horizon et utiliser le fichier prod.keys nouvellement créé comme source pour 4nxci ou nscb pour convertir les .xci en .nsp. Au fil des versions, des nouvelles clefs sont ajoutées mais celles déjà existantes restent les mêmes.

 

Pour moi la boucle est bouclée et j'ai atteint mon but. Je vais rester à l'écoute de ce qui se passe sur le forum et en apprendre un peu plus sur cette console qui n'est pas la première que j'ai "bricolé" 

 

Bien à vous tous et merci encore pour toute l'aide apportée.