Toggle sidebar

Front-page Hacking RELEASE  Updated

Lockpick_RCM payload - Official Thread


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
 

Attachments

  • AB1248EA-8BB9-448B-83F5-FF68C2579FB1.jpeg
    AB1248EA-8BB9-448B-83F5-FF68C2579FB1.jpeg
    11.2 KB · Views: 0
Last edited by shchmue,
  • Like
Reactions: FanNintendo, Deleted member 753700, DefenderOfHyrule and 77 others
Click to expand...
impeeza said:
No they are not, you can see on the source of Atmosphère the SEEDs The keys are the resultant of run the seeds on the firmware so you can extract them. the link to the Atmosphère's code is on previous Posts. By the Way this new file is bit by bit the same generated for the source code published by zoria on the last page.
Click to expand...
Well, as far I know... Atmosphere has the keys encrypted with previous keys in its source... So maybe that's what duckbill007 is refering to.
 
josete2k said:
Atmosphere has the keys encrypted with previous keys in its source... So maybe that's what duckbill007 is refering to
Click to expand...
I run this on console with FW 17.0.0. It definetly can not contains any bytes related to master_key_12, but lockpick creates file with master_key_12 in it.

So, either plain master_key_12 is embedded in lockpick, or some data + math function that calc master_key_12 embedded in lockpick.

Both (plain and data+func) seems the same to me.

Previous version of lockpick on the same console produces only master_key_11. So, new version embed master_key_12 either in plain form or in form of data+function.
 
  • Like
Reactions: Blythe93 and BigOnYa
As I understand (and this is wild speculation on my part based on what I've read around here, so take with a brick of salt), those "seed" values are known when a new firmware major version is out, and are the same for everyone, worldwide. The values can be used to derive a valid master key, but some requirement to do so (data and/or math functions, not sure which) is unique to each console and lives somewhere in its hardware (APU maybe?)
So, if you knew the seed values for firmware 20+, you could use them on a given console to generate the corresponding master_key_13 for it. No matter the version of the firmware running on the console, or even if the eMMC is corrupted, as long as it can boot and run a RCM payload.
 
Nephiel said:
but some requirement to do so (data and/or math functions, not sure which) is unique to each console and lives somewhere in its hardware (APU maybe?)
Click to expand...
No. In that case generated values will be unique, but they are all the same. So, lockpick do embed "seed" from firmware + math func.
 
  • Like
Reactions: Blythe93 and Nephiel
impeeza said:
I only have the next comment, on the file"\Lockpick_RCM\source\hos\hos.h the lines

C++: 
#define KB_FIRMWARE_VERSION_1900 18
#define KB_FIRMWARE_VERSION_MAX  KB_FIRMWARE_VERSION_1800 //!TODO: Update on mkey changes.
#define KB_FIRMWARE_VERSION_MAX  KB_FIRMWARE_VERSION_1900 //!TODO: Update on mkey changes.

define two times the same variable, should be only the last one, leaving that duplicate redefinition you get the warnings:
View attachment 463579should be only the last one left on the code?
Post automatically merged:

And @Zoria Thanks a lot for update the github with that files which we can not name here :D
Post automatically merged:


Uploaded a copy to Downloads section:

https://gbatemp.net/download/lockpick_rcm-1-9-13-fw-19-zoria-source.38837/
Click to expand...
I don't understand. where is the .bin file?
EDIT: got it now. Just saw link above. Can it be used on 18.1 also? Or only for 19.0?
 
Last edited by laz305,
  • Haha
Reactions: impeeza
laz305 said:
And do we need to run lockpick after every firmware update or once is enough?
Click to expand...
You really never need to use it except for if a software needs it. But yes, each new firmware that created a new key, needs a new lockpick version to dump the latest key. Else no really. Some firmware updates don't have a new key.


EDIT: Btw, always have one dump of your keys. Since it got unique keys in it.
 
Last edited by linuxares,
  • Like
Reactions: Blythe93 and laz305
duckbill007 said:
No. In that case generated values will be unique, but they are all the same. So, lockpick do embed "seed" from firmware + math func.
Click to expand...
As i understand Atmosphere provides the seeds and Lockpick uses Nintendos keygen algorithm to derive the keys independent of installed firmware. I don't know what the legality is in this case but Nintendo is trying hard to take Lockpick down. Would not surprise me if this site gets takedown notices sooner than later.
 
  • Like
Reactions: Blythe93
ghjfdtg said:
As i understand Atmosphere provides the seeds and Lockpick uses Nintendos keygen algorithm to derive the keys independent of installed firmware
Click to expand...
No. In that case lockpick does not need to be updated for each fw version. It has seed embedded into lockpick and not derive it from firmware as it should.
 
  • Like
Reactions: laz305 and Blythe93
duckbill007 said:
No. In that case lockpick does not need to be updated for each fw version. It has seed embedded into lockpick and not derive it from firmware as it should.
Click to expand...
I meant provide as in the seeds are copied from Atmosphere code. Each time Nintendo updates the keys Lockpick needs to be updated adding the missing seed. If you know how SciresM extracted the seeds then go ahead and modify Lockpick so it can do that automatically. Until then we are stuck with updating Lockpick manually.
 
I have an error after launch lockpick, during the creation of file.

Common... Error: Save header is invalid.
Failed to process es save

Can you help me?
Note: OFW is clean no games or others installed systemwipe was performed
 

Attachments

  • IMG-20241026-WA0002.jpg
    IMG-20241026-WA0002.jpg
    94.9 KB · Views: 101
Last edited by spix,
  • Like
Reactions: Tyvar1, Blythe93 and BigOnYa

Site & Scene News

Go to forum More news

Popular threads in this forum

Dusk for switch (TLoZ Twilight Princess port)

Homebrew  New Homebrew "Foil Server"?

Homebrew  Full List of N64 Recompilation Switch ports

Hacking  WiFi chip failing and can't boot. is it possible to enable Airplane Mode by editing system save files directly?

Homebrew Tutorial Translation Project  CS2SX — Write Nintendo Switch Homebrew in C#

Homebrew  Sonic Unleashed Recompiled (Homebrew Port)

Is it fixable

Hacking Emulation  Switch Prod Keys downloading from sites okay?