when you use the CHECK function on DEX it decrypts the eboot and saves a log file to usb...is there anyway we could use this to our advantage.
Yes we can (provided that this does indeed work out well) - from there (theoretically speaking), we can use the necessary signing tools to resign the EBOOTs for lower firmware versions.
Yes we can (provided that this does indeed work out well) - from there (theoretically speaking), we can use the necessary signing tools to resign the EBOOTs for lower firmware versions.
Has anyone else tried this?
it only saves the log file to usb not the actual decrypted eboot...but when using the check function you now know the ps3 has decrypted the eboot and is somewhere in memory if we could somehow hijack the process..and get our hands on them...im just thinking out load here ..so i might be talking cobblers...but it sounds feasable...i think...lol
I wonder where the 'check' code is on 3.55 DEX firmware? - how about modifying the code to save the decrypted output to usb? (Not even sure what the output is atm) - Ive ran a few checks and have noticed that different eboots decompress differently using check option, so its gotta be doing something!, If not then we could at least understand the check process and how it works?
Way over my head though! - i dont even know where the check code would be!
*Update;
The 'check option' on DEX/TEST machines has something to do with 'checker_plugin.sprx' which is located at /dev_flash/vsh/module - ive copied the file over and tried to decrypt using SELF/SPRX decrypter by DeLiGhT, but it fails, crashes the PS3 - However the source is available for the SELF/SPRX decrypter, if a dev can please take a look at the source and see why it wont decrypt, (need to add some type of printf's for debugging the app and see what causes the lockup?)
saying that Im trying to decrypt using a 3.55 converted DEX - **Update, Tried on CEX 3.55 and the *.SPRX does the same as DEX!.
Reply With Quote
Originally Posted by harryoke
