[carldenning]

when a new ofw comes out and we need a new cfw there will be one . like there is 4.30 cfw , there is no need for a 4.31 cfw at this time

[shadow931251]

Originally Posted by snkysnake02 @shadow931251 cant share that info its secret!!! ;-)

lol i see what you done there lol ok well sony cant patch anything if were alreaddy on the fw i seen a metldr expolite got leaked and hears a quote

STEP I)

In a self file, at address 0x0C a value is used to calculate where the metadata is going to be decrypted, the "offset" is at self header + 0x0C
its the "meta header offset" in the SCE structure, it takes the SCE offset + that value, so what you have to do is to have a calculation that is equal to 0x3E01F0 which happens to be where metldr copies over the shared metadata from the mailbox (which is sent over by the ppu), the trick is to have metldr to decrypt the metadata located at.
So basically you have to
1) set the offset += 0x2000
dump shared lsa
and keep increasing 0x2000
until somewhere in the shared lsa changes 0x40 byte
2) when it changes 0x40 bytes, you can add/subtract the proper amount to make it decrypt the proper locations
3) then dump shared lsa and we have decrypted header
knowing that metldr uses SCE header 0xECF0, you could calculate it knowing the address 0x3E01F0 - 0xECF0 = the value you would patch at SCE header + 0x0C

ROM:0000F6C0 D2 68 87 E6 metadata_erk: .int 0xD26887E6 ; DATA XREF: ROM:0000F178o
for example in CECHA , the address you want to decrypt it to is 0x3E1F0
so it should be 0x3E1F0 - 0xF6C0

Once you get the decrypted header, you have the key to decrypt the rest of the metadata. Here you go, you have your decrypted signature.

So far so good, now what's next ?

STEP II)

Contrary to popular beliefs, you do not need to know the public key to calculate the private key, you just need two decrypted signature, you now know how to dump these, so let's assume you just did, now all you have to do is to bruteforce the curve type by constantly reloading a self to metldr, the curve type being only 1 byte, that would be 64 possibilities.

CONGRATULATION, you just signed a loader !

Now what ?

Well Your first reflex would be to sign a loader and use it to dump whatever is in your Isolated Local Store, the first thing you will notice is that you have a bit of metldr's code as a leftover, after a few seconds of disassembly you will figure it's actually some piece of code that clears metldr's code and registers and jumps to some address which is matches your signed loader's entrypoint.

This seems like a more than likely candidate to exploit, as in your goal would be to overwrite that piece of code with your own, that way you would have the whole metldr code right before the point where everything gets cleared out.

Let's try to do just that, from your previous dump, you obviously know that the clear code is located from 0x400 to 0x630, (0x410 being where metldr jumps when it clears) your first attempt would naturally be to have a loader section to load at 0x400, well not so surprisingly, it fails, because you are not without a brain (at least you aren't supposed to be if you're reading and understanding this), you will assume that it is likely that metldr checks if you aren't loading your loader/self section below a certain address, which considering you know the loaders' entrypoint is most likely to be 0x12C00, this assumption is in fact correct as metldr will make sure you cannot load any loader at 0x12BFF and below, seems like a huge let down...

Well, maybe not, because yet again, you are not without a brain, you check out the hardware properties for the Local Store, and you find out that the memory wraps around (memory is a donut as someone once said at some ccc conference).

So what happens when you load your loader at let's say from 0x3F000 to 0x40000+some address? (like 0x40410 for example) ?

Well, it WORKS!
You could put the section at 0x3F000, if you made the length 0x1414 and the last instruction branches "up" to the dump code

ROM:000008AC 33 7F 6C 80 brsl lr, cleanup_and_jump_entry
ROM:000008B0 32 00 11 80 br loc_93C
ROM:00000410 cleanup_and_jump_entry: ; CODE XREF: main+4Cp
ROM:00000410 32 7F FF 80 br sub_40C
this is what the exploit that got leaked (yeah that's not really their work eh but you figured that much by now did you not? ) does.
It overwrites from 0x000 to 0x480 because I originally loaded the section o size 0x880 to 0x3FC00

So now you get code execution on metldr at the best time possible because your code executes right after metldr copies the root keys from 0x00 to 0x30, which means you get to dump these too. (Although they are hardcoded in metldr's code anyway)

Here you go, you have a metldr dump !

now what if we could use something like this to actually get an entire system dump all keys and everything

also just brain storming [and note im not a fan of wii] iv read wii has the letter bomb exploit and it uses wii message to load the exploit not a fw update is it possible to do such a thing on ps3 and if not threw msg how about ps3 theme if we was to creat a theme for ps3 with a few simple commads to dump the keys in the theme right before it gets applied there could be a possible exploit... i also saw a post were some 1 managed to get install pkg file on ofw is it possible to get the fw off the ps3?and install it on another i can post a link to the site i saw it on it looked legit and i have a few more idea but well star with these
************* [ - Post Merged - ] *************

Originally Posted by carldenning when a new ofw comes out and we need a new cfw there will be one . like there is 4.30 cfw , there is no need for a 4.31 cfw at this time

there is a 4.30 cfw that will not install over ofw so what good is that for non cfw ps3s?

[carldenning]

not the trick way again
************* [ - Post Merged - ] *************

Originally Posted by shadow931251 there is a 4.30 cfw that will not install over ofw so what good is that for non cfw ps3s?

buy one that can have cfw.

u can't calculate the private keys

i bet shadow931251 is that prick modderexcess

[tjhooker73]

Originally Posted by shadow931251 lol i see what you done there lol ok well sony cant patch anything if were alreaddy on the fw i seen a metldr expolite got leaked and hears a quote STEP I) In a self file, at address 0x0C a value is used to calculate where the metadata is going to be decrypted, the "offset" is at self header + 0x0C its the "meta header offset" in the SCE structure, it takes the SCE offset + that value, so what you have to do is to have a calculation that is equal to 0x3E01F0 which happens to be where metldr copies over the shared metadata from the mailbox (which is sent over by the ppu), the trick is to have metldr to decrypt the metadata located at. So basically you have to 1) set the offset += 0x2000 dump shared lsa and keep increasing 0x2000 until somewhere in the shared lsa changes 0x40 byte 2) when it changes 0x40 bytes, you can add/subtract the proper amount to make it decrypt the proper locations 3) then dump shared lsa and we have decrypted header knowing that metldr uses SCE header 0xECF0, you could calculate it knowing the address 0x3E01F0 - 0xECF0 = the value you would patch at SCE header + 0x0C ROM:0000F6C0 D2 68 87 E6 metadata_erk: .int 0xD26887E6 ; DATA XREF: ROM:0000F178o for example in CECHA , the address you want to decrypt it to is 0x3E1F0 so it should be 0x3E1F0 - 0xF6C0 Once you get the decrypted header, you have the key to decrypt the rest of the metadata. Here you go, you have your decrypted signature. So far so good, now what's next ? STEP II) Contrary to popular beliefs, you do not need to know the public key to calculate the private key, you just need two decrypted signature, you now know how to dump these, so let's assume you just did, now all you have to do is to bruteforce the curve type by constantly reloading a self to metldr, the curve type being only 1 byte, that would be 64 possibilities. CONGRATULATION, you just signed a loader ! Now what ? Well Your first reflex would be to sign a loader and use it to dump whatever is in your Isolated Local Store, the first thing you will notice is that you have a bit of metldr's code as a leftover, after a few seconds of disassembly you will figure it's actually some piece of code that clears metldr's code and registers and jumps to some address which is matches your signed loader's entrypoint. This seems like a more than likely candidate to exploit, as in your goal would be to overwrite that piece of code with your own, that way you would have the whole metldr code right before the point where everything gets cleared out. Let's try to do just that, from your previous dump, you obviously know that the clear code is located from 0x400 to 0x630, (0x410 being where metldr jumps when it clears) your first attempt would naturally be to have a loader section to load at 0x400, well not so surprisingly, it fails, because you are not without a brain (at least you aren't supposed to be if you're reading and understanding this), you will assume that it is likely that metldr checks if you aren't loading your loader/self section below a certain address, which considering you know the loaders' entrypoint is most likely to be 0x12C00, this assumption is in fact correct as metldr will make sure you cannot load any loader at 0x12BFF and below, seems like a huge let down... Well, maybe not, because yet again, you are not without a brain, you check out the hardware properties for the Local Store, and you find out that the memory wraps around (memory is a donut as someone once said at some ccc conference). So what happens when you load your loader at let's say from 0x3F000 to 0x40000+some address? (like 0x40410 for example) ? Well, it WORKS! You could put the section at 0x3F000, if you made the length 0x1414 and the last instruction branches "up" to the dump code ROM:000008AC 33 7F 6C 80 brsl lr, cleanup_and_jump_entry ROM:000008B0 32 00 11 80 br loc_93C ROM:00000410 cleanup_and_jump_entry: ; CODE XREF: main+4Cp ROM:00000410 32 7F FF 80 br sub_40C this is what the exploit that got leaked (yeah that's not really their work eh but you figured that much by now did you not? ) does. It overwrites from 0x000 to 0x480 because I originally loaded the section o size 0x880 to 0x3FC00 So now you get code execution on metldr at the best time possible because your code executes right after metldr copies the root keys from 0x00 to 0x30, which means you get to dump these too. (Although they are hardcoded in metldr's code anyway) Here you go, you have a metldr dump ! now what if we could use something like this to actually get an entire system dump all keys and everything also just brain storming [and note im not a fan of wii] iv read wii has the letter bomb exploit and it uses wii message to load the exploit not a fw update is it possible to do such a thing on ps3 and if not threw msg how about ps3 theme if we was to creat a theme for ps3 with a few simple commads to dump the keys in the theme right before it gets applied there could be a possible exploit... i also saw a post were some 1 managed to get install pkg file on ofw is it possible to get the fw off the ps3?and install it on another i can post a link to the site i saw it on it looked legit and i have a few more idea but well star with these ************* [ - Post Merged - ] ************* there is a 4.30 cfw that will not install over ofw so what good is that for non cfw ps3s?

Are you modderexcess?
Is that the old exploit from Failoverflow?
Or is that the Mathldr (lol) Exploit?

[carldenning]

Originally Posted by tjhooker73 Are you modderexcess? Is that the old exploit from Failoverflow? Or is that the Mathldr (lol) Exploit?

its Mathldr Exploit

[shadow931251]

Originally Posted by tjhooker73 Are you modderexcess? Is that the old exploit from Failoverflow? Or is that the Mathldr (lol) Exploit?

its mathldr i believe im not sure came across it some how but thats not the point

[carldenning]

what is the point?

[tjhooker73]

Originally Posted by shadow931251 its mathldr i believe im not sure came across it some how but thats not the point

The mathldr exploit does not work from what we know. cause by the time of the leak he was lying out his anus.

[shadow931251]

ok that part i didnt know but the point is has any 1 tryed dumping the keys threw a modded theme with a embedded code to dump and dycript the ps3 keys it sounds possible ?? or what about the extracting the firmware from the ps3 that had install pkg files on it it weas supposibly on ofw 4.30 ? possible or not? i believe all he could do was install sighned pkg files but its a step closer

[carldenning]

what keys do u want to dump?