To quote: This tool is used to bruteforce devklic for edat files on pc. It supports bruteforcing from binary or text files. It only take minutes to bruteforce in an elf file, no more waiting for hours or days.
This tool is based on BuC's EDAT Devklic Validator, all credit to BuC.
Update to v1.1
Fix a bug while bruteforce in text file.
If you meet some issue, please feedback. Thx.
Update to v1.2
Add 2 Modes:
Short Mode: Run only 4 rounds for binary source file. This mode doesn't try all the contents from source file. But it is enough in most cases.
Line Mode: Run only 1 round for text source file. This mode reads first 32 bytes in each line as devklic. It runs extremely fast for formatted text source file.
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.