Doesn't seem to use latest Key updates

[SteveMyers75]

I'm starting to see a lot of "failed to read NSP [reason: missing Key_area_key[key_area_key_application_010]]" in the log, even though the prod.keys file is current for Switch Firmware 17.0.1.

I don't think it's the prod.keys file because I can decrypt post v17.0.0 update files using the same keys using other programs, (like Swiss Army Knife and NUT)

This is happening on all Updates that require 17.0.0 (like SMBW Update v65536)
Possibly it's just a .go file that needs to be modified to read the new keys, but I haven't been able to figure out which one.

[pedro-dro]

Open your prod.keys and rename "key_area_key_application_10" to "key_area_key_application_010". Do the same with all the keys finished in "_10"

[SteveMyers75]

Thanks @pedro-dro, that indeed does fix the problem!

A tweak is needed to the way it parses the keyRevision byte in the decryptAesCtr function call inside nca.go so we don't have to use a "modified" Prod.keys just for SLM.

[pedro-dro]

Thank you for the information. I have a modified version that I've compiled for me with some fixes, I'll fix this one too. I can upload later if you are interested.

[SteveMyers75]

Very much interested in seeing your version.

To fix the keyRevision 10 issue, I changed \switchfs\nca.go keyRevision making it a String so it doesn't need to padd a zero anymore.

Line 102 Change keyRevsion to a String

keyRevision := ncaHeader.getKeyRevision()
 -to-	
keyRevision := string(ncaHeader.getKeyRevision())

Line 111 Remove the Zero Padding

keyName := fmt.Sprintf("key_area_key_application_0%x", keyRevision)
-to-             	
keyName := fmt.Sprintf("key_area_key_application_%x", keyRevision)

.
.
So now the function reads like this:

func decryptAesCtr(ncaHeader *ncaHeader, fsHeader *fsHeader, offset uint32, size uint32, encoded []byte) ([]byte, error) {
	keyRevision := string(ncaHeader.getKeyRevision())
	cryptoType := ncaHeader.cryptoType
	if cryptoType != 0 {
		return []byte{}, errors.New("unsupported crypto type")
	}

	keys, _ := settings.SwitchKeys()

	keyName := fmt.Sprintf("key_area_key_application_%x", keyRevision)
	KeyString := keys.GetKey(keyName)
	if KeyString == "" {
		return nil, errors.New(fmt.Sprintf("missing Key_area_key[%v]", keyName))
	}
	key, _ := hex.DecodeString(KeyString)

	decKey := _crypto.DecryptAes128Ecb(ncaHeader.encryptedKeys[0x20:0x30], key)

	counter := make([]byte, 0x10)
	binary.BigEndian.PutUint64(counter, uint64(fsHeader.generation))
	binary.BigEndian.PutUint64(counter[8:], uint64(offset/0x10))

	c, _ := aes.NewCipher(decKey)

	decContent := make([]byte, size)

	s := cipher.NewCTR(c, counter)
	s.XORKeyStream(decContent, encoded[0:size])

	return decContent, nil
}

I'm not a GO coder, but I believe this will take care of any future keyRevisions 10 or higher.

[jonasmare]

So this problem has to do with SLM and not the way Lockpick_RCM is extracting the keys ?

[SteveMyers75]

So this problem has to do with SLM and not the way Lockpick_RCM is extracting the keys ?

I would say it's not Lockpick, since every other program I've tried works fine with the 17.0 Prod.keys file it creates.

I don't think @giwty considered the Switch Keys Revision would ever be greater than 0xF.

It's a simple fix, either do as @pedro-dro suggested and edit the Prod.keys file used just for SLM, or change the nca.go file so it doesn't need to padd a zero to the key revision and re-compile SLM.

[NikoMuffin]

Special thank you to @SteveMyers75 for posting this (and saving me the time to do it!) and @pedro-dro for a solution that works.

Please do not let this project die. It's one of a kind and there's no other solution like it for management of Switch games.

[pedro-dro]

As I promised, I've uploaded my customized version of slm. I've created a fork

Fork link: https://github.com/pedro-dro/switch-library-manager

Thanks to all that helped me

[deekboy]

@pedro-dro - If you could add the full code to the download, or create a fork so we can continue to improve this app.

[trembon]

@deekboy @pedro-dro i too wanted some of these fixes but wanted to the source code available online, i created a fork with some of the fixes and with github actions autobuild configured
but if another fork pops up, i can take mine down so it doesn't confuses people

[2600box]

@trembon Thanks for your efforts here! I made an issue on your fork about running it without GUI. trembon#7

Could you take a look and see if it can be fixed? Thanks!

[pedro-dro]

@trembon This is the first time I modify a github project. I've had to google what a fork was, lol. I thought the only way to upload code was creating a new project. I'll try to create a fork and upload changes. May we could share our improvements / fixes.

[trembon]

@pedro-dro no worries and sure, try make a PR against my fork if you want so there can be a shared code base going forward, or if you are new to this i can try to merge the changes from you

[r3nfolly]

Hi guys, how I can get this new version? Any update on when it will be incorporated into the main release?

[trembon]

@r3nfolly it seems that giwty isnt active anymore here on GitHub so this repo is dead as there is no other owner to take over

i created a fork and have continued some development with fixing bugs and improvements that i wanted to use, there is a download under the release tab if you want to use it: https://github.com/trembon/switch-library-manager