Description
Lockpick_RCM is a bare metal Nintendo Switch payload that derives encryption keys for use in Switch file handling software like hactool, hactoolnet/LibHac, ChoiDujour, etc. without booting Horizon OS.

Source: https://github.com/shchmue/Lockpick_RCM
Payload: https://github.com/shchmue/Lockpick_RCM/releases

Due to changes imposed by firmware 7.0.0, Lockpick homebrew can no longer derive the latest keys. In the boot-time environment however, there are fewer limitations. That means the new keys are finally easy to dump!

Usage

• Launch Lockpick_RCM.bin using your favorite payload injector or chainload from Hekate by placing it in /bootloader/payloads
• Upon completion, keys will be saved to /switch/prod.keys on SD
• If the console has Firmware 7.x, the /sept/ folder from Atmosphère or Kosmos release zip containing both sept-primary.bin and sept-secondary.enc must be present on SD or else only keyblob master key derivation is possible (ie. up to master_key_05 only)

Big thanks to CTCaer
For Hekate and all the advice while developing this!

Known Issues

• Chainloading from SX will hang immediately due to quirks in their hwinit code, please launch payload directly

 

[Muxi]

please test the attached files and let me to know how go for you.

good night mates.

Tested! 217 keys are read from the sysNand. As I see it, some keys are missing (there should actually be 242 keys). 8 out of 9 keys of generation 13 are read out. The screen appears again only briefly and the main menu is loaded again.

 

[Konzolista]

The Fw 19 was a piece of puzzle, but the Fw 20 will probably be bigger...

 

[impeeza]

View attachment 501838
Bug but yes
This kind of bug is exhausting
I should point out that we still have SD errors on my side, but the prod is recovered on the SD and it has all the keys, unlike my build.

@Zoria While Sleeping, I noted the version of the program do not freeze have multiple write to SD card routines. on the section of write keys, may be we are hitting to a buffer overflow or something .

I copied the write to SD card routine on several places to try to find which one key was the one resetting to main page.

Post automatically merged: May 2, 2025

Well After so many tests

This is what I learned:

On my V1 Unpatched Erista. If you took the code of LockPick 1.9.13 and add only the new keys and build the payload dumping the SysNAND will dump nothing and return to main menu. My EmuNAND works fine.

Editing the file source\keys\keys.c and commenting some lines between lines 580 and 645, the ones with the SAVE_KEY( on the start, the new code works fine on my SysNAND.

if you comment 1 the process works but freeze before writing to SD card. if you comment 3 the process works fine.

This is the point to my knowledge go, I have no enough skill on C to diagnose the real cause of the freeze/crash.

 

[hetop]

Here is the screenshot of the frozen tool. On the second attempt, the Lockpick_RCM screen popped up briefly and was reloaded without anything happening.

In the end, the keys were not saved on the SD card either.

Of all the screenshots that have been posted here, this is the one that's closest to what's happening for me. Only difference is that I get 241 prod keys for some reason and not 242 prod keys like you get, but it freezes all the same.

 

[urherenow]

I was trying to update my own copy yesterday. I can add all of the new key info that I always previously add, and it would work up to key 12 (If I didn't update hos.h properly to change the max version to 2000). But as soon as I fix that, it's back to the problem where things flash across the screen too fast to read, then jumps back to the main menu. Didn't think to try using it directly instead of through hekate though... Glad you guys are already looking at it.

The IPS Patch Creator... seems to spit out key 13, but skips over key 12, with the 20.0.0 update. Dunno why that is... I haven't dumped 20.0.1 yet to see if the results are the same. darthsternie seems to have messed up the page because the 20.0.1 uses the same link as 20.0.0.

 

[impeeza]

I was trying to update my own copy yesterday. I can add all of the new key info that I always previously add, and it would work up to key 12 (If I didn't update hos.h properly to change the max version to 2000). But as soon as I fix that, it's back to the problem where things flash across the screen too fast to read, then jumps back to the main menu. Didn't think to try using it directly instead of through hekate though... Glad you guys are already looking at it.

The IPS Patch Creator... seems to spit out key 13, but skips over key 12, with the 20.0.0 update. Dunno why that is... I haven't dumped 20.0.1 yet to see if the results are the same. darthsternie seems to have messed up the page because the 20.0.1 uses the same link as 20.0.0.

20.0.1 have exactly the same keys tomorrow will share a code which seemed work but it's a very bad code

 

[urherenow]

20.0.1 have exactly the same keys tomorrow will share a code which seemed work but it's a very bad code

I am aware, I just don't know the specifics of what Nintendo fixed that may have been soft-bricking systems. Perhaps a missing key could have caused it for the effected users. But no, I just dumped 20.0.1 myself, and ips patch creator still skips over key 12. But produces key 13. Really odd. Can't even pretend to look into it, because the latest source I have is from right before the keygen button was added.

 

[Zoria]

https://github.com/CTCaer/hekate/pull/1084/commits/0d80a0b8d967cb6100f7e5caeebf1f9a7a99e69e
This code may help to understand what is blocking LockPick.

 

[impeeza]

I am aware, I just don't know the specifics of what Nintendo fixed that may have been soft-bricking systems. Perhaps a missing key could have caused it for the effected users. But no, I just dumped 20.0.1 myself, and ips patch creator still skips over key 12. But produces key 13. Really odd. Can't even pretend to look into it, because the latest source I have is from right before the keygen button was added.

You can generate keys for teenage you don't have installed on the console. By example my stuff is 4.0.1 and emunand is 19.0.1 and I was able to dump 13 keys

 

[Muxi]

By example my stuff is 4.0.1 and emunand is 19.0.1 and I was able to dump 13 keys

This is absolutely strange, because there are no master keys 13 in fw 19.0.1. It must have something to do with the buggy Lockpick_RCM version.
Since Systemsoftware 20.0.0/20.0.1 is a major update, the code of Hekate in Lockpick_RCM will probably have to be adapted. I have now compiled the prod.keys for FW 20.0.0 myself and manually collected the missing entries from the net and added them. I will use this prod.keys file as a comparison for future tests. These are the prod.keys that I read from my 19.0.1 emuMMC with Lockpick_RCM version 1.9.13, with the missing 9 masterkeys 13 added accordingly. As already mentioned, there are 242 entries in this prod.keys file.

 

[urherenow]

https://github.com/CTCaer/hekate/pull/1084/commits/0d80a0b8d967cb6100f7e5caeebf1f9a7a99e69e
This code may help to understand what is blocking LockPick.

Nope. It actually changes less than lockpick. As far as key stuff, anyway. All other changes don't appear to have anything to do with lockpick, that I know of.

 

[impeeza]

This is absolutely strange, because there are no master keys 13 in fw 19.0.1. It must have something to do with the buggy Lockpick_RCM version.
Since Systemsoftware 20.0.0/20.0.1 is a major update, the code of Hekate in Lockpick_RCM will probably have to be adapted. I have now compiled the prod.keys for FW 20.0.0 myself and manually collected the missing entries from the net and added them. I will use this prod.keys file as a comparison for future tests. These are the prod.keys that I read from my 19.0.1 emuMMC with Lockpick_RCM version 1.9.13, with the missing 9 masterkeys 13 added accordingly. As already mentioned, there are 242 entries in this prod.keys file.

I has been always able to extract keys for all firmware from my SysNAND on 4.0.1 strange

Post automatically merged: May 3, 2025

https://github.com/CTCaer/hekate/pull/1084/commits/0d80a0b8d967cb6100f7e5caeebf1f9a7a99e69e
This code may help to understand what is blocking LockPick.

Sadly the only changes on that commit are basically the same we already put on LockPick code, which is add the seeds for the new keys.

but the current problem of freezing or crashing is related to the functions «SAVE_KEY_VAR» and «SAVE_KEY_FAMILY_VAR» I am thinking about a problem with a buffer or a missing pointer or something like that, I barely have notions about C programming to understand concepts but not to code from scratch.

 

[draftguy123]

My -workaround- was commenting out some keys in the source code
and manually copy them over from the previous dev.keys and prod.keys.

/source/keys/keys.c

627 //    SAVE_KEY(sd_card_custom_storage_key_source);
628 //    SAVE_KEY(sd_card_kek_source);
629 //    SAVE_KEY(sd_card_nca_key_source);
630 //    SAVE_KEY(sd_card_save_key_source);

 

[impeeza]

My -workaround- was commenting out some keys in the source code
and manually copy them over from the previous dev.keys and prod.keys.

/source/keys/keys.c

627 //    SAVE_KEY(sd_card_custom_storage_key_source);
628 //    SAVE_KEY(sd_card_kek_source);
629 //    SAVE_KEY(sd_card_nca_key_source);
630 //    SAVE_KEY(sd_card_save_key_source);

Thanks yes, Was my first workaround too. then I tried copying the code

    if (!sd_save_to_file(text_buffer, strlen(text_buffer), keyfile_path) && !f_stat(keyfile_path, &fno)) {
        gfx_printf("%kWrote %d bytes to %s\n", colors[(color_idx++) % 6], (u32)fno.fsize, keyfile_path);
    } else {
        EPRINTF("Unable to save keys to SD.");
    }

to several points between «SAVE_KEY» lines, now the code writes all the keys to the Prod.keys file but sometimes freeze

 

[Muxi]

I have to correct myself, there must be "243" entries! The ‘eticket_rsa_kek_personalised’ was still missing! I have attached the prod.keys file here, but without the key values.

Edit:
But what would interest me is which of the keys are console-specific?
I found these, but I don't know if they are complete.

secure_boot_key tsec_key device_key bis_key_00 bis_key_01 bis_key_02 bis_key_03 save_mac_key_00 save_mac_key_01 keyblob_key_## keyblob_mac_key_## encrypted_keyblob_## sd_seed save_mac_sd_card_key ssl_rsa_key eticket_rsa_keypair

 

[impeeza]

I have to correct myself, there must be "243" entries! The ‘eticket_rsa_kek_personalised’ was still missing! I have attached the prod.keys file here, but without the key values.

Edit:
But what would interest me is which of the keys are console-specific?
I found these, but I don't know if they are complete.

secure_boot_key tsec_key device_key bis_key_00 bis_key_01 bis_key_02 bis_key_03 save_mac_key_00 save_mac_key_01 keyblob_key_## keyblob_mac_key_## encrypted_keyblob_## sd_seed save_mac_sd_card_key ssl_rsa_key eticket_rsa_keypair

You are right as far I know that are the only keys unique for each console.

 

[Konzolista]

atmosphere-1.9.0-preprerelease-20_support-9dd8269f7+hbl-2.4.4+hbmenu-3.6.0+fusee
https://github.com/Atmosphere-NX/Atmosphere/issues/2502#issuecomment-2849410425

hekate_20.0.0_support_test
https://github.com/CTCaer/hekate/issues/1086#issue-3038243199

 

[Muxi]

atmosphere-1.9.0-preprerelease-20_support-9dd8269f7+hbl-2.4.4+hbmenu-3.6.0+fusee
https://github.com/Atmosphere-NX/Atmosphere/issues/2502#issuecomment-2849410425

hekate_20.0.0_support_test
https://github.com/CTCaer/hekate/issues/1086#issue-3038243199

This AMS PrePrePreRelease version 1.9.0 always crashes shortly after booting into the HOS under FW 20.0.1. The Fatal Crash Screen shows “010000000000001F” as the error source. prodinfo blanking is deactivated by the way.

 

[Blythe93]

This AMS PrePrePreRelease version 1.9.0 always crashes shortly after booting into the HOS under FW 20.0.1. The Fatal Crash Screen shows “010000000000001F” as the error source. prodinfo blanking is deactivated by the way.

View attachment 503074

Do you have the latest sys-patch as well?

 

[Muxi]

@Blythe93 That was the mistake! Many thanks for the tip!