Additionally, the following was changed:
- added a screenshot button for after the keys finish dumping. Press VOL UP if you wish to save a screenshot, especially when submitting an issue to me
- reboot to Hekate option added to main menu if present on SD
- fixed Mariko dumping both sets of prod/dev keys, this was accidental and the other keyset is erroneous. Erista consoles can still dump both
- no longer require successful EMMC mount to derive keys since it's all done via embedded keygen
- retry keygen on failure for rare edge cases
- fix name of
bis_key_sourcein key file
- set regular RAM clocks while idle, only OC during run
- more verbose errors if encountered when dumping partial keys on Mariko
- embed version in payload so other payloads can check
This release bundles the Atmosphere keygen payload to allow for full keygen conducted by Lockpick_RCM with no Sept, no reboots, and faster runtime.
As a result, all Erista consoles will dump the latest key set regardless of NAND contents.
Also, due to the way keygen works, all Erista consoles will produce both
prod.keys which may be useful to some users for research and archival purposes.
Mariko keyslots are now validated thoroughly before saving partial keys for brute force purposes. Partial keys are also produced for AES class keys in slots 0-11. These aren't used for anything by the console or any tools, but are included for completeness' sake. See readme for details.
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