(adsbygoogle = window.adsbygoogle || []).push({}); the topic revolves around a possible PS3 4.0 exploit, and the theory around it. This is information that I would like to share with the scene, in hopes of change and overcoming the current barriers to jailbreaking the PS3 console. Feedback welcomed, as I has put a lot of thought and time into this theory.

There has been information available for quite some time. and I took it, thought about it, researched and experimented and I come out with my theory below to exploit 4.00 part of the way. This is not a random theory to, this is logical stuff and true facts. I'm providing this info for other devs to look at and lets see if this can work. I don't keep my work to my self, I like to share in give other people chances in discovering stuff. It always makes me happy when someone finds something out using my work, it just tells me I did a good job in describing and helping and they did a good job in listening and learning the material in order to trigger the exploit or whatever it might be.


The lv2ldr is used to verify and decrypt the lv2_kernal.self. In the lv2ldr Parameters Layout, the arguments start at 0x3E800 we need to know this so we can load with the different arguments we want to. the arguments end around where the program revoke list address starts, so around this 0x3F000. u8* means read one byte from the address. One of the lv2 arguments are lv2_in* that would mean the address in ram (Where it's located). The other is lv2_out* that's where to decrypt lv2 address in ram(Where decrypts lv2_kernal.self). that would also use u8 because you want to read it by one byte from that address. well with a program made to read the address like how readself works we can know the address where the lv2 lies in the ram and where it is decrypted. once we know the address the real decryption can start. So knowing the decrypted address we can take that offset make a progam like coreos_tool pull the and get the lv2 key all from knowing that decrypted lv2_kernal.self location. exploiting 4.00 with this method would work most likely because I doubt sony changed all the locations where the loaders do there thing, sure there encapsulated in the bootloader but they still pass over into the ram at one point before being fed over to the metldr which loads ldrs.
some where along these lines
Code:
void *buf; // <- that will get the address of the argument we chose to load
u? buf_size;// <- pretty clear it gets the size. but would you add u64?
} lv2_in;
struct {
u8 result[0x10];//read it by one byte from the address
} lv2_out;
}
that just a quick sample. not full.

So other devs I post this possible exploit I found here for you to experiment with and get some where with 4.00. You can follow me on twitter You must login or register to view this content.

nice job m8

its not my idea its this guys called RealPsDev i was just asking any1 on here if it wud work lol