Thank to all of you. I hope someone is able to code a program using this info.
First of all, I want to congratulate Euss of ps3devwiki on finding the klicensee decrypt key and provide a proof of concept of the AppLoder part of the algorithm. Check
http://ps3devwiki.com/index.php?titl...and_Decryption
Now you have the tools to decrypt all free executable content.
Euss they key is not duplicated... there are two cases that lead to the same (similar to the keys, two cases so two repeated tables).
Some of you asked what this algorithm is for. It has several use from backing up PSN games so they can be used with/without license (some countries allow backups, but NEVER sharing copyrighted material....) or use game updates on lower firmwares (some updates are NPDRM so they could not be decrypted and downgraded). I don't know if DUPLEX used this method or if they replaced the data with debug versions as some implied...
Also, it can be use is to modify geohot's make_self_npdrm to use non static keys for encoding. I don't know if that would be enough to make a self runnable on 3.56+ firmware. However it is a step on the right direction (I think extra modifications are required). If someone knows which parts of the self is whitelisted it would be an interesting addition to the thread. Sony was publishing 3.55 after 3.56 went online so I really interested to see which part of the SELF was whitelisted.
Others asked for the keys. I can not provide them nor functional code to avoid being sued... Graf and geohot were sued for providing the keys and/or functional code.
However, I can provide a tip on getting the RIF key.... once decrypted bytes 0x40 to 0x4F should be xx xx xx xx xx xx xx xx xx xx xx xx 00 00 00 aa where x is random and aa is a number between 0x00 and 0x7F. It is located on the VSH.elf (remember that PPC64 has 8 byte aligment). That is a plaintext attack + dictionary(vsh). You don't need the curves as you can not sign rif nor act.dat (You can only check that file is valid). And the vsh keys can be easily find... graf chokolo called IDPS as device_id_ptr.... and the CONST is very near on code execution...
To yolbulduran: That is a piracy related question. In addition you have published confidential info, which anyone who does RCE should avoid (I do not have the SDK). The answer is NO. Why?. See this code:
ret = sceNpDrmVerifyUpgradeLicense("FAKE_CONTENT_TO_DETECT_CFW");
if(ret == 0){
banConsole();
print("CFW detected. Game will exit");
exit(-1);
}
ret = sceNpDrmVerifyUpgradeLicense("REAL_CONTENT");
if (ret == 0) {
int fd = openEncryptedContent("REAL_CONTENT.edat",......,keyForFile,sizeof(KeyForFile));
if (fd > 0) {
//Do things
}
}
First part is an example of how a developers can easily catch that modification and stop execution making it dangerous (could get a ban!!!). You modification says that the console has access to a fake content, which only CFW will have. When patching code the modification should be done only to the case you want to fix. That modification should go on the executable not on npd libraries. That way we do not patch the first verify but we will patch the second...
The second part is the real reason why it wont work... you REQUIRE the rif for opening the edat. The rif holds the klicensee for both SELF and EDAT. In fact I assume that the klicensee follows the same transformation upto the apploader. That key that you see on the command it is only used to check the HMAC on the NPD element (see geohot make_self_npdrm omac calculations)
For executable the problem is similar as when trying to run another PPU executable the program will finish and ask the vsh to run the other process which will undergo the full decryption algorithm... again you need the rif.
But.... what will happen if we decrypt the paid edat/SELF using the rif and then resign and encrypt as a free content before executing the code??? (Assuming we can sign edat)
WE CAN SIGN EXECUTABLES UPTO 3.55 THANKS TO FAIL0VERFLOW'S EPIC FAIL..... I think people do not really understands what that means...