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: SnowStormAkikaze, FanNintendo, Deleted member 753700 and 78 others
Click to expand...
bth said:
I've decided to see if I cannot add a new key derivation path similar to my other projects into lockpick_rcm;

what this does differently compared to what lockpick_rcm did before, is it reads and decrypts the nca headers, identifies system update and the fat32 filesystem nca;
then checks the key revision used in the system update (as FS always master key 0), and compares it against what lockpick already knows about.

if it's lower or equal, lockpick does nothing new.

if it's higher, it attempts to decrypt the FS .nca, finding /nx/package1, decrypts it (hovi kek tsec keygen has also been added because of this), searches for magic to find where master_kek_source is stored;

then processes the new keys for that keygen revision using the master kek source found.


the intent of this change is for lockpick rcm to be able to get the newest keys without lockpick rcm requiring an update to do so, however updating lets the keys generated into prod.keys have example:

_15
_16
_17

instead of lacking updates and a hypothetical list (essentially a gap):

_15
_17

https://github.com/borntohonk/Lockpick_RCMaster/releases/download/test/Lockpick_RCM_current.bin
https://github.com/borntohonk/Lockpick_RCMaster/releases/download/test/Lockpick_RCM_subtracted.bin (latest generation commented out)


I have these two binaries, which needs testing on an actual system, because i'm bit unsure if the codepath is triggered as it currently is, or if i need to add a +1

https://github.com/borntohonk/Lockpick_RCMaster/commit/35f2dd852f3266aa40b0dde77eb8b9e82887f884
Click to expand...
Wow mate, great work.

I just propposed a PR with some minor format changes and the addition of 1TB+ sd cards support.
 
impeeza said:
Wow mate, great work.

I just propposed a PR with some minor format changes and the addition of 1TB+ sd cards support.
Click to expand...
i have zero intention of maintaining lockpick, the intention behind the commit/work done so far is to produce a version which no longer needs to be manually updated.

i will be sending a PR upstream to thzoria master and a duplicate PR to lockpick PRO after someone has tested and verified if it emits it or not:
https://github.com/borntohonk/Lockpick_RCMaster/releases/download/test/Lockpick_RCM_current.bin
https://github.com/borntohonk/Lockpick_RCMaster/releases/download/test/Lockpick_RCM_subtracted.bin (latest generation commented out)


basically, if it prints:
"Key generation up to date."
or
"New keys derived for master_key_%02x"


if both versions say "New keys derived for master_key_%02x" then i have to add a +1.

and if the prod.keys output has master_key_15 (especially for "Lockpick_RCM_subtracted.bin" as that one has the hardcoded key sources commented out)

(obviously test console needs a firmware version of 22.0.0 or higher, as i only commented out the latest key generation)

C: 
    new_gen_keys_t new_keys = {0};
    int new_gen_mkr = 0;
    int key_gen_result = extract_new_gen_keys(keys, &new_keys, &new_gen_mkr);
    if (key_gen_result > 0) {
        gfx_printf("%kNew keys derived for master_key_%02x\n", colors[(color_idx++) % 6], new_gen_mkr);
        if (new_gen_mkr > CURRENT_KEY_GENERATION + 1)
            EPRINTFARGS("Warning: master_kek_source missing for revisions %02x-%02x.", CURRENT_KEY_GENERATION + 1, new_gen_mkr - 1);
    } else if (key_gen_result == 0) {
        gfx_printf("%kKey generation up to date.\n", colors[(color_idx++) % 6]);
    }
 
Last edited by bth,
  • Like
Reactions: Blythe93, Tyvar1 and impeeza
duckbill007 said:
Am I right that HOS contains only last (current) master kek source? In that case how does it derives older keys?
Click to expand...
if i get a confirmation that this works, i will be refactoring lockpick's key derivation process

but the tl:dr is lockpick (currently, wont after refactor) gets the tsec root key from the keyslot after running the atmosphere tsec keygen payload, and uses that root key (tsec_root_key_02) with key for all keys above 0A (with the master_kek_sources)

it only needs to decrypt one key that way (tsec_root_key + master_kek_source)

it then uses that derived master_kek with master_key_source to get master_key_0a,

then decrypts these, that lockpick calls vectors, which is just the previous master key encrypted by the current master key, then it recursively decrypts down to _00


basically, this change of mine is to make new keys appear even if no update was made to lockpick, and the gap as i explained if not maintained


https://github.com/borntohonk/Lockpick_RCMaster/blob/main/source/keys/key_sources.inl#L60-L80

here's the logic in my crypto example
https://github.com/borntohonk/Switch-Ghidra-Guides/blob/master/scripts/crypto.py#L319-L352

and the full populated master key list
https://github.com/borntohonk/Switch-Ghidra-Guides/blob/master/scripts/crypto.py#L206-L211


tl:dr lockpick uses the embedded master_kek_sources, nothing from HOS currently.
 
Last edited by bth,
  • Love
Reactions: impeeza
forgotten-865 said:
Which option should I use for EmuMMC, Dump from SysNAND or Dump from EmuNAND ?

Another thing, is there any difference between versions of locjpick? I'm using this

https://github.com/THZoria/Lockpick_RCMaster
Click to expand...
For the side of the production keys booth should be the same, the difference should be on the installed games keys, each *NAND has a different set of keys.
 
  • Like
Reactions: forgotten-865
Thanks to a tester the refactor of lockpick_rcm has reached a state of being able to (on its own) produce new key revisions, even if there has not been an update to lockpick_rcm

https://github.com/borntohonk/Lockpick_RCMaster/commit/86374d2ae7d3eee7ef61adb19d5c2bce2f3ea847

it's still work in progress, as i want to rewrite the key derivation a tiny bit (of the rest of lockpick_rcm's key derivation process); but the most important bit has been completed;

testing with only _14 key sources / 21.0.0 defined, yielded (appended at end of prod.keys) _15 revision keys, where no key source or definition for 22.0.0 was provided.

after i'm done with the refactor/rewrite lockpick_rcm technically wont be in need of an update to the payload to dump the latest keys if new ones appear



(this involves opening the system partition, finding two specific ncas, using first ones header to find out key revision; then the second nca's romfs, to then find package1, to then decrypt package1, to then find the master_kek_source inside the decrypted package1, to then generate the key revision the master_kek_source is tied to)
 
  • Like
  • Love
Reactions: Noxskc, Tyvar1, impeeza and 2 others
bth said:
Thanks to a tester the refactor of lockpick_rcm has reached a state of being able to (on its own) produce new key revisions, even if there has not been an update to lockpick_rcm

https://github.com/borntohonk/Lockpick_RCMaster/commit/86374d2ae7d3eee7ef61adb19d5c2bce2f3ea847

it's still work in progress, as i want to rewrite the key derivation a tiny bit (of the rest of lockpick_rcm's key derivation process); but the most important bit has been completed;

testing with only _14 key sources / 21.0.0 defined, yielded (appended at end of prod.keys) _15 revision keys, where no key source or definition for 22.0.0 was provided.

after i'm done with the refactor/rewrite lockpick_rcm technically wont be in need of an update to the payload to dump the latest keys if new ones appear



(this involves opening the system partition, finding two specific ncas, using first ones header to find out key revision; then the second nca's romfs, to then find package1, to then decrypt package1, to then find the master_kek_source inside the decrypted package1, to then generate the key revision the master_kek_source is tied to)
Click to expand...

Thats a great achievement, congrats.
Will it support only sys partition or emunand too?
And thanks for the work put into it.
 
  • Like
Reactions: Blythe93
bth said:
Thanks to a tester the refactor of lockpick_rcm has reached a state of being able to (on its own) produce new key revisions, even if there has not been an update to lockpick_rcm

https://github.com/borntohonk/Lockpick_RCMaster/commit/86374d2ae7d3eee7ef61adb19d5c2bce2f3ea847

it's still work in progress, as i want to rewrite the key derivation a tiny bit (of the rest of lockpick_rcm's key derivation process); but the most important bit has been completed;

testing with only _14 key sources / 21.0.0 defined, yielded (appended at end of prod.keys) _15 revision keys, where no key source or definition for 22.0.0 was provided.

after i'm done with the refactor/rewrite lockpick_rcm technically wont be in need of an update to the payload to dump the latest keys if new ones appear



(this involves opening the system partition, finding two specific ncas, using first ones header to find out key revision; then the second nca's romfs, to then find package1, to then decrypt package1, to then find the master_kek_source inside the decrypted package1, to then generate the key revision the master_kek_source is tied to)
Click to expand...
Wow mate, that is a lot of work. Thanks seems no enough
 
  • Like
Reactions: SonGoku78
if anyone has a modchipped mariko / oled;
or regular erista console and want to just confirm this produces prod.keys with keys consistent with what the old lockpick dumped pre-refactor, that would be great (it will produce more keys than before)

if it works as expected, i will submit a PR upstream and consider this finished

changelog:
refactors master key derivation process by utilizing falcon hw secret 0x26
consolidates mariko master key derivation path

new:
adds the ability for lockpick_rcm to pull new key sources from package1, without knowing the existence of the key revision or key source; making it not require an update to produce the latest key revisions.

( this involves opening the system partition, finding two specific ncas, using first ones header to find out key revision; then the second nca's romfs, to then find package1, to then decrypt package1, to then find the master_kek_source inside the decrypted package1, to then generate the key revision the master_kek_source is tied to )



tl:dr the atmosphere tsec_keygen binary lockpick/atmosphere/hekate uses, hardcodes root key 02 (dev/prod) into keyslot, and generates tsec_key as well

this change ignores the tsec root key slot, as we generate them using hw secret 0x26 and secure boot auth signatures now.

only erista uses the tsec_keygen code path, for the tsec_key only now, as that one uses hardware secret 0x3F which is console unique
 
Last edited by bth,
  • Like
Reactions: SonGoku78 and impeeza
@bth
I would love to help with testing, but i am not sure if its helpfull.
I have a launch model switch, that should be erista right?
Sorry, i am just too long out of switch modding.
And i am still on fw21 (emunand).
I am not sure, if i had dumped keys after updating emu to 21.
So if my setup is good for testing, please pm me with instructions.
Can do probably later today, or tomorrow latest.
 
  • Like
Reactions: impeeza
bth said:
if anyone has a modchipped mariko / oled;
or regular erista console and want to just confirm this produces prod.keys with keys consistent with what the old lockpick dumped pre-refactor, that would be great (it will produce more keys than before)

if it works as expected, i will submit a PR upstream and consider this finished

https://github.com/borntohonk/Lockpick_RCMaster/releases/download/pre-release/Lockpick_RCM.bin


( https://github.com/borntohonk/Lockpick_RCMaster/commit/841bfc6642d6b6c9880130dd74edbde40b232c6e )

changelog:
refactors master key derivation process by utilizing falcon hw secret 0x26
consolidates mariko master key derivation path

new:
adds the ability for lockpick_rcm to pull new key sources from package1, without knowing the existence of the key revision or key source; making it not require an update to produce the latest key revisions.

( this involves opening the system partition, finding two specific ncas, using first ones header to find out key revision; then the second nca's romfs, to then find package1, to then decrypt package1, to then find the master_kek_source inside the decrypted package1, to then generate the key revision the master_kek_source is tied to )



tl:dr the atmosphere tsec_keygen binary lockpick/atmosphere/hekate uses, hardcodes root key 02 (dev/prod) into keyslot, and generates tsec_key as well

this change ignores the tsec root key slot, as we generate them using hw secret 0x26 and secure boot auth signatures now.

only erista uses the tsec_keygen code path, for the tsec_key only now, as that one uses hardware secret 0x3F which is console unique
Click to expand...
I am attaching a redacted version of the Files generated by the most recent release of Picklock_RCM and your binary, on my Unpatched Erista V1 Console some extra keys are generated. but also some «NOFAT» and «unable to mount system partition» errors are generated using the new binary. I am also attaching the Screenshots for debug purpose.
Post automatically merged:

SonGoku78 said:
@bth
I would love to help with testing, but i am not sure if its helpfull.
I have a launch model switch, that should be erista right?
Sorry, i am just too long out of switch modding.
And i am still on fw21 (emunand).
I am not sure, if i had dumped keys after updating emu to 21.
So if my setup is good for testing, please pm me with instructions.
Can do probably later today, or tomorrow latest.
Click to expand...
You are right the launching model is Erista.

The firmware version do not matter because the keys are derivated even before load the bootloader.
 

Attachments

  • Like
Reactions: bth and SonGoku78
impeeza said:
I am attaching a redacted version of the Files generated by the most recent release of Picklock_RCM and your binary, on my Unpatched Erista V1 Console some extra keys are generated. but also some «NOFAT» and «unable to mount system partition» errors are generated using the new binary. I am also attaching the Screenshots for debug purpose.
Post automatically merged:


You are right the launching model is Erista.

The firmware version do not matter because the keys are derivated even before load the bootloader.
Click to expand...
looks good enough;

new version outputs tsec_root_kek_%% package1_kek_%% and so on,

the part that matters is whenever new key generation is found either, also the debug message for not found doesn't matter that much

"NOFAT" error exists before my refactor;
unable to mount system partition error i am aware of, but it still works despite that.

also "Unable to mount system partition.", is part of old code
error for new code is "DEBUG: Unable to mount system partition."

Im noticing that biskey is all zero, in both old and new, i'll see if i cant fix that (not caused by me, apparently)

edit: biskey shouldn't be problem, most likely @impeeza edited the files.

bis_key_00 = 1f412a32694e742810909cf9ec1d091a44f86f5bb2c8b2ef21a60f0fddcc3c81
bis_key_01 = 8cc14f2755755d361dbcb16b4d49a8e5e5bf4d1d70170cf6eb77b79a3c8ac45c
bis_key_02 = 4a6b471a40d0608bca61ef3cc677afc87f03414cbd362092fae62baac7f13afb
bis_key_03 = 4a6b471a40d0608bca61ef3cc677afc87f03414cbd362092fae62baac7f13afb


the device_key (used by erista) and device_key_4x (used by mariko) are what generates biskeys, and both are present in your files.



edit:

both NOFAT and "Unable to mount system partition" should be fixed:
https://github.com/borntohonk/Lockpick_RCMaster/commit/a34c14d3262b179254b728471a8ac25e32475dad

https://github.com/borntohonk/Lockpick_RCMaster/releases/download/release/Lockpick_RCM.bin
 
Last edited by bth,

Site & Scene News

Go to forum More news

Popular threads in this forum

Homebrew Homebrew game  Chrono Trigger - Switch port

Emulation Homebrew PS1/2 Emulator  ARMSX2-NX Initial Release

Emulation Emulator  NetherSX2 - Switch Port

Dekopon - (Mostly) Fullspeed 3DS Emulation on Nintendo Switch

Hacking Homebrew Tutorial  New Switch Modpack, NX-ModPack

Homebrew Homebrew game  Castlevania Symphony of the Night - Switch port

Homebrew Homebrew game  Angry Birds Classic - Switch Port

Homebrew Homebrew game  GTA: Liberty City Stories - Switch port