1. Add subfolder traversal in edat/sdat folder.
2. Fix 2G+ file handling issue (probably).
3. Fix syntax issue while handling certian edat files.
4. Re-adjust the mainmenu.
1. Add SDAT file supporting.
1. Fix Java OutOfMemory for encrypting big files.
2. Add JVM Memory config in toolcore.cfg.
1. Decrypt and encrypt edat files on pc.
2. Fast rebuild mode.
3. Batch mode.
4. Dev Klic should be input manually at now.
It seems Windows 8 cannot pass the java check.. maybe fix it in next version.
Finally, from oakhead69: Hi jjkkyu, If you have based your code on my C# code which in turn is based on the port by KDSBest. There is a significant bug in the reverseByteWithSizeFIX code.
It will fail the hash check on some data blocks, hench KDSBest removed the test. More importantly when generating the hash for the data blocks during encryption, the hash will be incorrect. Hench the resulting SDAT/EDAT will be bad. I have attached some updated code below.
public static byte reverseByteWithSizeFIX(byte b)
if (b.Length < 0x10 && (b[b.Length - 1] & 0x80) != 0)
b2 = new byte[0x10];
for (i = 0; i < b.Length; i++)
b2[b2.Length - 1 - i] = b[i];
for (i = b.Length; i < 0x10; i++)
b2[0x10 -1 - i] = 0xff;
b2 = new byte[b.Length];
for (i = 0; i < b2.Length; i++)
b2[b2.Length - 1 - i] = b[i];
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.