37w ago - Following up on his previous release, today Sony PlayStation 3 hacker Naehrwert has updated SCETool to version 0.2.9 which now includes an NP application types fix and more as detailed in the changes below.
Plaintext sections will now take less space in metadata header keys array.
Added option to specifiy a template SELF to take configuration values from.
Added option to override the keyset used for en-/decryption.
Fixed NP application types.
[Firmware Version] will now be written to control info only.
[Application Version] will now be written to application info only.
Finally, from ben.ss7: Here is a scetool v0.2.9 which has zlib1.dll and the data folder embedded within the exe, which means it doesn't require you to have zlib1.dll and the data folder for keys.
The original scetool source code hasn't been touched and it shouldn't have any issues. The keys which have been embedded in to this exe are:
If any user wants me to embed all the keys up to 4.31 PM me. Enjoy
Stay tuned for more PS3 Hacks and PS3 CFW news, follow us on Twitter and be sure to drop by the PS3 Hacks and PS3 Custom Firmware Forums for the latest PlayStation 3 scene updates and homebrew releases!
Here are a few quick updates from naehrwert (twitter.com/naehrwert) for those following:
haha just figured the eid3 algo, nice!
KaKaRoToKS and I added basic NPDRM support to scetool
SELF generation works now for SPU and PPU, except for compressing the data and NPDRM
added SPU SELF generation to scetool
Also from his site: nwert.wordpress.com/2011/12/24/individual-infos/
One of the PS3′s console specific cryptography works as follows:
At factory time there is a console specific key generated, probably from a private constant value and a console specific seed. Maybe that’s the key used for encrypting bootldr and metldr. Fact is, that metldr stores another console specific keyset (key/iv) to LS offset 0×00000. That keyset is probably calculated from the first one. At factory time the isolated root keyset (how I call it) is used to encrypt the console’s “Individual Infos”, like eEID.
But not the whole eEID is encrypted the same way, special seeds are used to calculate key/iv pairs for the different sections. And not even that is true for every eEID section, because for e.g. EID0 another step is needed to generate the final section key(set). Each of the isolated modules using such an “Individual Info” has a special section that isoldr uses to generate the derived key(set)s.
But the generation works in a way, that the section data is encrypted with aes-cbc using the isolated root keyset, so it is not possible to calculate the isolated root keyset back from the derived key(set)s, because aes shouldn’t allow a known plaintext attack. So far I can decrypt some of EID0′s sections, EID1, EID2 and EID4. EID5 encryption should be similar to EID0′s but I lack the generation keys for that one.