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

 

[petspeed]

Sad news indeed, you will be missed. Thank you @Slluxx for all your contributions to the Switch scene during the years and good luck with your future projects

 

[urherenow]

How should I go about using Lockpick on a chipped Switch? It boots right to Hekate so I assume I cannot send a payload the way I was accustomed to (using NS-USB Loader).

Edit: I think I figured it out, there is an option to dump from sysnand or emunand, does it matter?

It does matter, if you don't update both sys and emummc. That should really be self-evident. There are those that think it's a good idea to keep sys on a low firmware, and only update emummc. In that case, using it on sys, is not going to get you the latest keys.

 

[impeeza]

It does matter, if you don't update both sys and emummc. That should really be self-evident. There are those that think it's a good idea to keep sys on a low firmware, and only update emummc. In that case, using it on sys, is not going to get you the latest keys.

My SysNAND is untouched from the box, The very first time I turn on the console, I injected Hekate and make a backup then converted the backup to an EmuNAND RAW partition (later converted to file based), since then I NEVER started the SysNAND, My EmuNAND got updated from 4.01 to every FW release since then, And has been using 90DNS and Atmosphère's DNSMiTM (when become available) ALL THE TIMES.

 

[shchmue]

the difference between what gets dumped from sysnand and emunand is just titlekeys if you have different games installed. this would always generate the latest system keys no matter what version is actually installed

Post automatically merged: Feb 17, 2024

Back from deployment! And it only took me 10 minutes or so to figure out the question to my last post (but couldn't access this site again until now). 1) That particular bit is only for Erista, and I only brought my OLED with me, and 2) that key does not, in fact, exist in the secmon_boot_key_data.s file that we were told to use for this purpose. It exists in fusee_key_derivation.cpp. So without further ado, here's a cheat sheet I made up of what the keys are called in the various files. I got this thing nailed down now (until the actual crypto changes... then I know where to look to figure things out, but it won't be quick. It'll be quick if it's just new keys and nothing else).

this comment explains why atmosphere only keeps one of the master kek sources https://github.com/Atmosphere-NX/At...rogram/source/boot/secmon_boot_key_data.s#L84

it will always have only the newest one. if you need older ones check the commit history for this file

 

[Hassal]

the difference between what gets dumped from sysnand and emunand is just titlekeys if you have different games installed. this would always generate the latest system keys no matter what version is actually installed

Post automatically merged: Feb 17, 2024

this comment explains why atmosphere only keeps one of the master kek sources https://github.com/Atmosphere-NX/At...rogram/source/boot/secmon_boot_key_data.s#L84

it will always have only the newest one. if you need older ones check the commit history for this file

Is there a reason why lockpick cannot dump console keys if exFAT drivers are installed onto the system? This has always bugged me.

 

[BigOnYa]

Is there a reason why lockpick cannot dump console keys if exFAT drivers are installed onto the system? This has always bugged me.

You should not be using exFAT anyways, always use FAT32 on the Switch.

 

[Hassal]

You should not be using exFAT anyways, always use FAT32 on the Switch.

Sometimes I receive consoles like so its an extra step for me if I want to dump their keys.
The issue happens when exFAT drivers are installed, the console no longer pairs with the eMMC giving you a false reading.

I reported this a long time ago and nobody seem to give the reason why this is happening.

 

[RedColoredStars]

Don't need it myself, but where would one go now to get it since both slluxx and mudkip pages are gone?

 

[Blythe93]

Don't need it myself, but where would one go now to get it since both slluxx and mudkip pages are gone?

If you're looking for the latest release of Lockpick_RCM, you can find it in this post.

 

[Worldblender]

I've just discovered that the source repository has went down, and there's apparently no other place of getting it to my knowledge so far, so I uploaded the mudkip repository from 5/2023 (supporting 17.0.x firmware) here. I may consider uploading this to my GitLab profile later for backup purposes. Let me know if this upload becomes an issue.

 

[AlamosIT]

I've just discovered that the source repository has went down, and there's apparently no other place of getting it to my knowledge so far, so I uploaded the mudkip repository from 5/2023 (supporting 17.0.x firmware) here. I may consider uploading this to my GitLab profile later for backup purposes. Let me know if this upload becomes an issue.

I found this fork still online.

 

[Worldblender]

I found this fork still online.

Since it's on GitHub, it may be vulnerable to a DMCA takedown since they can affect forks from the original repository unless it was a separate reupload. I specifically mentioned GitLab as it isn't as well known as GitHub is, although it's hosted service is still in the United States. I also already have an account over there.

 

[Slluxx]

https://git.gdm.rocks/Mirror/Lockpick_RCM

 

[AlamosIT]

There's also a webarchive backup of the previous download link from NH Switch Guide

https://web.archive.org/web/2023112...CM/releases/download/v1.9.11/Lockpick_RCM.bin

 

[Nameless_Mofo]

https://git.gdm.rocks/Mirror/Lockpick_RCM

Thank you @Slluxx for posting this backup mirror. Even though I have a copy of the bin, I was very upset that mudkip's repo went offline. It's good that the code is still available for now at least.

Unless I absolutely have to, however, I don't ever plan to update f/w beyond 17.0.1.

 

[Slluxx]

Thank you @Slluxx for posting this backup mirror. Even though I have a copy of the bin, I was very upset that mudkip's repo went offline. It's good that the code is still available for now at least.

Unless I absolutely have to, however, I don't ever plan to update f/w beyond 17.0.1.

Team Neptune will take care of that, dont worry. Aside from us, there are multiple people that can and will update Lockpick and post here so there is no need to worry.

 

[Tyvar1]

https://github.com/Decscots/Lockpick_RCM/releases/tag/v1.9.12

Support firmware 18.0.0

 

[impeeza]

Keys generated!!!! Thanks a lot.

 

[NotUsingAnAltAccount]

Hahaha, thank you a lot for the update!

 

[oresterosso]

is it hosted on github?
Has the developer taken the DMCA issue into account?
Why not learn the lesson and keep going to GitHub?