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

 

[urherenow]

Anyone know when Lockpick would become available again? Obviously the link has now been moved or deleted. Since were not aloud to ask for wares, not sure if PMs are aloud or not....

you're trolling, right? There's a binary on this very page. There's probably 1 or 2 on the previous page (that were buggy because of the memory issue).

 

[impeeza]

Well guys, the most recent version of the binaries and code are on the download section:

1.9.15 binary:
https://gbatemp.net/download/lockpick_rcm-1-9-15-fw-20-zoria.39129/

1.9.15 source:
https://gbatemp.net/download/lockpick_rcm-1-9-15-fw-20-zoria-source.39130/

Again, Thanks a lot to @Zoria @Muxi @shadow256 and @urherenow for all your help.

 

[urherenow]

I could not find any of these code lines in your source code and yet it works. "SZ_16K" is set in the corresponding line.

You're not keeping up very well. The binary above used:

char *text_buffer = (char *)calloc(1, text_buffer_size + 65);

I just found an easier and cleaner (in my opinion) way to deal with it after the fact. After duckbill007's post gave me a clue (or rather, the whole answer).

 

[Muxi]

Well guys, the most recent version of the binaries and code are on the download section:

The correct version number would actually be 1.9.14, because the previous Lockpick_RCM version for FW 19.x.x was 1.9.13! You are one version too far with version 1.9.15.

I have compiled the source code you posted in the download section again with the correct version number. The binary can be found in the attachment.

You're not keeping up very well. The binary above used:

char *text_buffer = (char *)calloc(1, text_buffer_size + 65);

It was about these two possibilities in the “keys.c” file::

 u32 text_buffer_size = MAX(_titlekey_count * sizeof(titlekey_text_buffer_t) + 1, SZ_16K * 2);

and

 u32 text_buffer_size = MAX(_titlekey_count * sizeof(titlekey_text_buffer_t) + 1, SZ_32K);

none of which is contained in @Zoria's source code (keys.c - line 576) to which I was referring in my post, but this one:

u32 text_buffer_size = MAX(_titlekey_count * sizeof(titlekey_text_buffer_t) + 1, SZ_16K);

You, on the other hand, are talking about the line 577 below! But that's not what I was talking about!

 

[Zoria]

I gave a way to do it but I didn't remodify the source code or the binary as I don't have it at home.
I'll let you manage the rest for reparting with the SZ_32K patch

 

[Muxi]

@Zoria No offense intended. I just wanted to clarify that, because despite the entry at the end “SZ_16K);” your binary worked under my switch revisions (Erista v1 & Mariko).

 

[impeeza]

The correct version number would actually be 1.9.14, because the previous Lockpick_RCM version for FW 19.x.x was 1.9.13! You are one version too far with version 1.9.15.

The version 1.9.14 is on the Github, I didn't uploaded to GBATemp because some testing was needed.

 

[Muxi]

The version 1.9.14 is on the Github

As far as I know, all repositories of Lockpick_RCM have been disabled due to the DMCA takedown. I only found this one, which seems to have been overlooked:
https://github.com/saneki/Lockpick_RCM/releases

 

[Tyvar1]

As far as I know, all repositories of Lockpick_RCM have been disabled due to the DMCA takedown. I only found this one, which seems to have been overlooked:
https://github.com/saneki/Lockpick_RCM/releases

https://github.com/impeeza/Lockpick_RCMDecScots

 

[ColdDarkKiller]

read the post above yours

What you mean the part where it says there will be an update soon? If so yes I did read that.

 

[StevensND]

What you mean the part where it says there will be an update soon? If so yes I did read that.

https://gbatemp.net/threads/lockpick_rcm-payload-official-thread.532916/post-10648353

 

[ColdDarkKiller]

you're trolling, right? There's a binary on this very page. There's probably 1 or 2 on the previous page (that were buggy because of the memory issue).

Na mate, I'm not trolling, im not as good with stuff as you more experienced lads on here, just basic stuff only for me I'm afraid. Help anyone & give advice as n when i can. I'm not here to troll I'm here for advice, to learn & to help the forum as best as I can. Been a member here for ever but just started a new account & recently got a switch so back here again. Thanks for the help everyone

 

[impeeza]

Guys if you downloaded the V1.9.15 from downloads section, PLEASE DOWNLOAD IT AGAIN, a silent update was pushed, by an error on Actions of GitHub the latest commit (the one which changed the displayed version) was ignored.

 

[urherenow]

It was about these two possibilities in the “keys.c” file::

 u32 text_buffer_size = MAX(_titlekey_count * sizeof(titlekey_text_buffer_t) + 1, SZ_16K * 2);

and

 u32 text_buffer_size = MAX(_titlekey_count * sizeof(titlekey_text_buffer_t) + 1, SZ_32K);

none of which is contained in @Zoria's source code (keys.c - line 576) to which I was referring in my post, but this one:

u32 text_buffer_size = MAX(_titlekey_count * sizeof(titlekey_text_buffer_t) + 1, SZ_16K);

You, on the other hand, are talking about the line 577 below! But that's not what I was talking about!

I think somehow you still don't get it. Those were not in in Zoria's source, because that's not what Zoria changed. I made the SZ_32K change privately, and added it to the discussion. Zoria simply responded to that.

 

[Muxi]

I think somehow you still don't get it. Those were not in in Zoria's source, because that's not what Zoria changed. I made the SZ_32K change privately, and added it to the discussion. Zoria simply responded to that.

I don't want to go into it any further, as the matter has already been settled.

 

[impeeza]

I think somehow you still don't get it. Those were not in in Zoria's source, because that's not what Zoria changed. I made the SZ_32K change privately, and added it to the discussion. Zoria simply responded to that.

mate, I really do not have a deep knowledge on c coding. More by curiosity please correct me if I am Wrong:


On this thread «two» solutions has been proposed:

Modifying the definition of text_buffer_size , as far I understand that variable is defined as a u32 variable with the value of the result of evaluate the maximum of two values «_titlekey_count * sizeof(titlekey_text_buffer_t) + 1» or the global variable SZ_16K (on original code. so if «_titlekey_count * sizeof(titlekey_text_buffer_t) + 1» is bigger than 0x4000 (16384) that value is used or at least 16384 is used. one solution was change the constant SZ_16K by SZ_16K*2 or SZ_32K so the minimum value of text_buffer_size now is 0x8000 (32768)

        u32 text_buffer_size = MAX(_titlekey_count * sizeof(titlekey_text_buffer_t) + 1, SZ_16K * 2);
        u32 text_buffer_size = MAX(_titlekey_count * sizeof(titlekey_text_buffer_t) + 1, SZ_32K);

or the other change was on a later line which use the value of text_buffer_size to create a pointer to a new variable called text_buffer and adding 65 to it.

char *text_buffer = (char *)calloc(1, text_buffer_size + 65);

in both cases the new pointer to the variable text_buffer now is bigger and do not overflow while writing the keys.

At the end we choose the first case. but please let me know if I got the correct meaning of the two proposal.

Thanks a lot.

 

[urherenow]

I've done nothing but basic programming myself. There is no difference between SZ_16K * 2, and SZ_32K, as far as math goes, so don't worry about it too much. It's more like personal preference and what looks "clean" to you.

Text buffer is/was not a new variable. It's used everywhere in that file, and is initially created in keys.h, as a variable required in the definition of a few SAVE_KEY things... In the line in question, the text_buffer is actually being given a value, or a new value if it was already used before.

Where my ignorance lies, is that I have no idea why +65 was used. 65 seems arbitrary to me, and just an oddball number. There may be a perfectly good reason for it, I just don't know.

 

[impeeza]

He he we are on the same, I know only the basic, by example, what a variable, pointer or function, but well, I am not able to write C code by my self.

I've done nothing but basic programming myself. There is no difference between SZ_16K * 2, and SZ_32K, as far as math goes, so don't worry about it too much. It's more like personal preference and what looks "clean" to you.

Ok, as far I did remember from programming class (30 years ago) the only difference may be performance.

Where my ignorance lies, is that I have no idea why +65 was used. 65 seems arbitrary to me, and just an oddball number. There may be a perfectly good reason for it, I just don't know.

Yep, a odd number, but works because on my case only 1 key generate the overflow, and most of the keys lines uses 63 characters.

thanks a lot for your answers.

 

[urherenow]

He he we are on the same, I know only the basic, by example, what a variable, pointer or function, but well, I am not able to write C code by my self.


Ok, as far I did remember from programming class (30 years ago) the only difference may be performance.


Yep, a odd number, but works because on my case only 1 key generate the overflow, and most of the keys lines uses 63 characters.

thanks a lot for your answers.

Lot more going on than just how many characters are in a key. for these purposes, I think 63 characters would take 63 bytes of space. In UTF-8, where some characters can take up to 4 bytes, that would be a maximum of 252 bytes. That's a long road to filling up even just 1KB (more than 4 times as much, in the UTF example)...

 

[hippy dave]

Ok, as far I did remember from programming class (30 years ago) the only difference may be performance.

It's multiplying a constant by another constant, I would imagine any competent compiler would calculate it at compile time and turn it into a single constant in the resulting code so there shouldn't be a difference.