[Support] Tutorial Switch Keys auslesen

Moin. Ich habe gestern bei meiner Switch mit 5.1.0 über die Variante 2 die Keys gesichert.
Vorher habe ich über Atmosphere /Hekate 4.6 ein Backup gemacht. Da mein Sohn heute Abend das smash bekommt und er den Fighterpass kaufen möchte, ist jetzt die Frage, ob durch das benutzen von Lockpick Spuren vorhanden sein könnten?
Wäre es sinnvoll, das Backup wieder einzuspielen, oder einfach so lassen?

Spiele noch mit den Gedanken, eine SX Lizenz zu kaufen und einen emunand einzurichten oder zu abzuwarten, bis Atmosphere einen emunand bietet.

Hast du die CFW über einen emuNand laufen? Wenn nicht, ist es sehr gefährlich danach online zu gehen!

Edit:
Habe übersehen, dass du kein SX OS nutzt (und somit auch keinen emuNand haben kannst). In diesem Fall wäre es ratsam einen Nand Restore zu machen, um wieder einen sauberen Nand zu bekommen (vorausgesetzt, du hast ein sauberes Nand Backup).

jo, das Backup ist ein sauberes Backup, welches ich als allererstes erstellt habe. Danach erst habe ich die Keys ausgelesen.
Dann werde ich mal das Backup einspielen.
Edit:
Hekate speichert das Backup im Ordner Sd://Backup/xxxxxx/ ab, für den restore muss aber das backup unter sd://backup/xxxxxx/restore liegen?
Zumindest hat er das so angezeigt, das er die rawnand.bin dort nicht gefunden hat. Kopiere jetzt die einzelnen Dateien (wegen fat32) dorthin... bringt auch nix, es muss zwingend als ganze Datei vorliegen. Lege jetzt ne extra sd Karte mit exfat an, um das Backup einzuspielen.

Müssen eigentlich installierte Spiele (NSP) beim Firmware Upgrade neu installiert werden?

Bsp.:
Keys mit 6.2 im emuNAND ausgelesen, von XCI in NSP konvertiert und installiert. Irgendwann ein Update auf die kommende FW 6.3 (sofern möglich und freigegeben) durch ChoiDujourNX geupdatet -> Spiele laufen oder müssen diese neu installiert werden?

Wenn dem so wäre, macht es für die SX-User doch Sinn die über Album zu mounten und als XCI zu speichern

Nein, es kann nur sein, dass dann ein Update des Spiels erforderlich wird.

Edit
Die Keys können derzeit nur aus dem sysNand ausgelesen werden. Wenn z.Bsp. dein emuNand auf 6.2.0 ist, und dein sysNand auf 4.1.0, werden nur die Keys aus dem 4.1.0 sysNand ausgelesen und nicht die 6er Keys aus dem emuNand. Ich habe über diese Problematik bereits mit dem Dev von Lockpick geschrieben und auch bei TX diesbezüglich vorgesprochen. Denn nur wenn es eine Möglichkeit geben würde, den tsec_root_key aus dem emuNand zu dumpen, wäre ein Auslesen der Keys vom emuNand möglich!

Ist das normal, das die keys der FW 6.0.1 exakt die gleichen sind wie bei der 6.2?

Hast du zufällig einen sysNand 6.0.1 und einen emuNand 6.2.0? Dann sind deine ausgelesenen Keys nicht die aus dem emuNand, sondern die aus deinem sysNand.

Ich habe keinen emuNAND.
Ich wollte die keys die ich für den NSC Builder brauche mal auf den neuesten Stand bringen.
Dort waren noch die von 6.0.1 eingetragen. Hab meine Switch auf 6.2 gebracht und bin nach dieser Anleitung zum auslesen der Keys vorgangen.
Beim Vergleich fiel mir auf: kein Unterschied

Dann hast du die erste Anleitung genommen? Du solltest besser die zweite Methode verwenden, die mit dem Tool Lockpick.

nein die zweite

Zitat von muxi

Dann sind deine ausgelesenen Keys nicht die aus dem emuNand, sondern die aus deinem sysNand

Der EmuNAND besitzt dieselben Keys, wie der SysNAND!
Sie werden aus dem package1ldr ausgelesen, welches sich im Boot0 befindet und diesen gibt es nur einmal pro Konsole. xD

Alao braucht man nicht nach einem Firmware Update im emuNAND die Keys erneut auszulesen, da die bereits ausgelesen nicht mehr werden?

Ich habe deshalb gefragt, ob er einen emuNand mit einer höheren FW hat, weil der tsec_root_key, der u.a. für die Erstellung der Keys mit Lockpick verantwortlich ist, derzeit nur aus dem sysNand ausgelesen werden kann und nicht aus dem emuNand! Daher können keine Keys eines 6.2.0 emuNands ausgelesen werden, wenn der sysNand noch auf beispielsweise 4.0.1 ist. Es werden dann immer die Keys der alten Version des sysNands ausgelesen! Das bedeutet also, dass jemand mit dieser Konstellation auch nicht an den 6er Masterkey dran kommt!

Ich weiß nicht, ob für das Konvertieren von XCI nach NSP, wenn ein Titel die FW 6.2.0 voraussetzt, nicht auch die Keys erneut ausgelesen werden müssen, wenn die alten Keys nur maximal die 05er Keys enthalten. Dieses Problem haben User, die auf einer niedrigen FW im sysNand sind. Daher kann der emuNand zwar auf 6.2.0 sein, aber es wird nicht möglich sein, ohne den sysNand ebenfalls auf 6.2.0 zu updaten, an diese 6er Keys zu kommen. Es müsste einen tsec_root_key Dumper für den emuNand geben, damit das möglich werden kann. Der Dev von Lockpick sagte mir, dass er sein Tool anpassen würde, wenn so ein Tool von TX veröffentlicht werden würde. Immerhin ist der emuNand meines Wissens ja eine TX Entwicklung.

Ich glaube, hier wird was verwechselt. Natürlich funktionieren noch die Public Master-Keys von älteren FWs.
Die FW 6.2.0 änderte nur grundlegende Schlüsselgenerierung die durch die TSEC-Firmware initialisiert wird und somit verwendet sie keine Keyblobs mehr, alles Gerätespezifisch..

@SwitchGamerX2019 Habe ich dich jetzt richtig verstanden, dass es ausreicht, seine Keys einmalig auszulesen, und man kann zukünftige Titel Veröffentlichungen mit höheren Masterkeys auch weiterhin mit den alten ausgelesenen Keys konvertieren?

Nur so lange die Games keine neue Master-key Revision besitzten:

Das sind Public keys die funktionieren zurzeit mit allen Spielen:

master_key_00                         = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
master_key_01                         = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
master_key_02                         = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
master_key_03                         = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
master_key_04                         = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
master_key_05                         = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


titlekek_source                       = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
key_area_key_application_source       = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
key_area_key_ocean_source             = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
key_area_key_system_source            = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
aes_kek_generation_source             = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
aes_key_generation_source             = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
header_kek_source                     = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
header_key_source                     = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

master_key_00: 1.0.0-2.3.0
    master_key_01: 3.0.0
    master_key_02: 3.0.1-3.0.2
    master_key_03: 4.0.0-4.1.0
    master_key_04: 5.0.0-5.1.0
    master_key_05: 6.0.0-6.1.0
    master_key_06: 6.2.0-current

Man unterscheidet 3 Keysets:

prod.keys - Enthält public Schlüssel, die von allen Switches verwendet werden.
console.keys - Enthält konsoleigene Schlüssel.
title.keys - Enthält spielspezifische Schlüssel.

Also müsste man die Firmware im sysNAND updaten, wenn ein Spiel das Update / Masterkey mit mindestens 6.x voraussetzt, auch wenn im emuNAND eine höhere emuliert wird. Es sei denn TX bringt ein Update heraus, was aus dem emuNAND liest, korrekt?

@Weltverbesserer Genau diese Problematik habe ich bei TX schon angesprochen und auch mit shchmue, dem Entwickler von Lockpick. Das wäre noch eine nützliche Weiterentwicklung des SX Loaders um den tsec_root_key aus dem emuNand dumpen zu können. Dann wäre das Problem gelöst!

@SwitchGamerX2019 Das mit den 5er Keys mag vielleicht noch für Basis-Spiele zutreffen, für Updates jedoch nicht. Dort wird bei den aktuellsten Versionen der Masterkey 6 z.T. schon vorausgesetzt.

@Weltverbesserer Nein.

@muxi Ist eigentlich nicht notwendig, da alle public keys, welche die fw 6.2.0 geändert hat, bekannt sind, einschließlich der Masterkey 6. Ich kann dir den master-key 6 per PN zusenden.

Danke, nicht nötig, den habe ich bereits. Ich habe nur schon weiter gedacht, wenn einmal der Masterkey 7 kommen sollte. Dann wäre es praktisch, den aus seinem aktuellen emuNand extrahieren zu können, ohne dafür den sysNand aktualisieren zu müssen. Vielleicht kommt bis dahin ja noch eine Lösung!