Added an agnostic methodology for handling future firmware versions which use the same master key generation and key derivation method.
Updated to support version 12.0.2, which again introduces no new keys but has a new pkg1 version
Updated bdk/drivers to reach parity with hekate v5.5.6
Implemented payload compression to allow for easier growth in the future
Re-enabled the battery status bar
Big release! If you can load payloads on your Mariko or patched Erista console, you can now dump keys with Lockpick_RCM!
Thanks loads to CTCaer, SciresM, Shadów, balika011, and averne for information, advice, and help testing!
The following section is only for research purposes - all keys needed for normal use are dumped by the program with no further action required
To get your SBK or the Mariko specific keys (the kek which is used for master key derivation or the bek which is used to encrypt package1 and the BCT), you will need to use the
/switch/partialaes.keys file along with a brute forcing tool such as https://files.sshnuke.net/PartialAesKeyCrack.zip. I will test out a userland homebrew for this purpose soon. The contents of this file are the keyslot number followed by the result of that keyslot encrypting 16 null bytes. With the tool linked above, enter them in sequence for a given keyslot you want the contents of, for example:
PartialAesKeyCrack.exe <num1> <num2> <num3> <num4> with the
--numthreads=N where N is the number of threads you can dedicate to the brute force.
The keyslots are as follows, with names recognized by
mariko_kek (not unique - this is used for master key derivation)
mariko_bek (not unique - this is used for package1 decryption)
secure_boot_key (console unique - this isn't needed for further key derivation than what Lockpick_RCM does but might be nice to have for your records)
15 - Secure storage key (console unique - this is not used on retail or dev consoles and there's nothing useful to do with it)
So if you want to brute force the
mariko_kek, open your
partialaes.keys and observe the numbers beneath keyslot 12. Here's an example with fake numbers:
12 11111111111111111111111111111111 22222222222222222222222222222222 33333333333333333333333333333333 44444444444444444444444444444444
Then take those numbers and open a command prompt window at the location of the exe linked above and type:
PartialAesKeyCrack.exe 11111111111111111111111111111111 22222222222222222222222222222222 33333333333333333333333333333333 44444444444444444444444444444444 and if you're on a powerful enough multicore system, add
--numthreads=[whatever number of threads], ideally not your system's maximum if it's, for example, an older laptop with a low-end dual core CPU. On my Ryzen 3900x with 24 threads this generates a lot of heat but finishes in about 45 seconds.
Improved the general aes-xts crypto function to match the diskio algorithm (only 2 total aes-ecb calls instead of one per block) and perform the xor operations in 32-bit chunks. Also updated for gcc 10 and merged latest Hekate commits.
Sysmmc runs get a slight speed improvement, emummc gets a large speed improvement, especially file-based.
Also now supports parsing sept from sept-secondary if FSS0 entry is present in
Version 10.0.0, in addition to having new key offsets, expands the
80000000000000E1 common ticket save. This revealed a bug in remap init code, now fixed. Also fixed a bug caused by missing ES saves.
Fixed BIS key off-by-one index issue for new consoles
New consoles also introduced new handling for keys in PRODINFO, so fixed titlekey regression
Lockpick_RCM now supports firmware 9.1.0. Like in update 9.0.0, the root keys didn't change and so consoles on any version from 8.1.0-9.1.0 will dump all current keys.
Minerva should be updated on SD to use its performance benefits. If the old library is present, Minerva will not activate.
Also corrected bug where SD seed verification vector was being read from sysnand even when dumping keys from emunand.