Since everyone was wondering how the hell the last remaining keys were found so fast, i shall explain to the best of my abilities on how to find keys.
most keys are found inside the decrypted binaries. we also have to know correctly how the chain of trust works.
bootldr/lv0ldr -> lv0
metldr -> appldr, isoldr, lv1ldr, lv2ldr
appldr -> vsh / emer_init / hdd_copy / etc
isoldr -> spu_pkg_rvk_verifier, spp_verifier, (all that has iso and spu in it)
lv1ldr -> lv1
lv2ldr -> lv2_kernel
spu_pkg_rvk_verifier (rvkldr?) -> prog.rvk pkg.rvg RL_FOR_PROGRAM.img RL_FOR_PACKAGE.img
spp_verifier -> default.spp
with this in mind, considering there were only major differences inside the firmware when 3.60 was released, there are two of ways of finding the keys, the old one and the new one.
old way is by using the metldr key to decrypt everything else (3.56 and below)
new way is a lot more complicated, but there are two tools that can help us get there, recently released.
new way requires us the bootldr key to decrypt lv0 ( since all the loaders were hidden in there)
now for the pattern repetition.
the thing marked with black arrow is a pattern. i’m pretty sure this is repeated in every single version listed on the wiki when listing the keys.
this one is more recent, you can see the scramble keys and next to it two patterns.
usually when you’re looking for keys, you need to take a look at a firmware that already has keys listed, and search for those keys, then find the pattern and look in the firmware not found
common patterns in hex :
80 80 80 80
FF FF FF FF
01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F (this happens a lot when finding public and curve type)
of course, the best way to know if there’s a key or not is with IDA, by looking at its data references (DATA xref)
PS: As for the seeds, most of them are hidden inside the metadata section of the self.
As with everything, any correction is very well welcome