PS3 wait why can't we jailbreak 3000+ systems?

[bguerville]

By the way - I thought with CFW we have access to all 8 SPUs, am I missing something?

Yes and no.

Iirc you can change the number of available spus stored in syscon eeprom, set it from 6 to 7 (the isolated SPU is not included in that count), that change cannot be deployed by a CFW pup file, but on CFW you can run custom code to write to syscon and apply this mod.
Or you could do it from OtherOS Linux.

That unlocks the 8th SPU, you may eventually use it under OtherOS Linux at the condition that it's not defective (remember that they disabled one SPU for a good reason) however on GameOS the kernel won't handle it iirc, it may require some patches I dunno, in any case it would only benefit apps that would use it and currently no apps or games were coded to take advantage of an additional SPU.

 

[atreyu187]

The fact that Sony didn't (and supposedly couldn't) patch metldr on already-sold console using firmware updates means that even with full knowledge of the internals it's not that easy.

By the way - I thought with CFW we have access to all 8 SPUs, am I missing something?

You can enable a patch for all 8 SPE's but retail games can not take advantage of this. Linux can but it is hindered and has been. But even if you unlock the last one there is no assurance it will even work.

https://www.psdevwiki.com/ps3/Unlocking_the_8th_SPE

 

[NiQ]

Yes and no.

Iirc you can change the number of available spus stored in syscon eeprom, set it from 6 to 7 (the isolated SPU is not included in that count), that change cannot be deployed by a CFW pup file, but on CFW you can run custom code to write to syscon and apply this mod.
Or you could do it from OtherOS Linux.

That unlocks the 8th SPU, you may eventually use it under OtherOS Linux at the condition that it's not defective (remember that they disabled one SPU for a good reason) however on GameOS the kernel won't handle it iirc, it may require some patches I dunno, in any case it would only benefit apps that would use it and currently no apps or games were coded to take advantage of an additional SPU.

So no way of accessing the isolated SPU? Even from lv1?

 

[bguerville]

So no way of accessing the isolated SPU? Even from lv1?

In theory? No, that's why we call it isolation mode.

In practice? Yes, with a SPU exploit.
The ERK dumper source can show you a way to hack the SPU, there are others, including MikeM64 hardware based one.

SPUs are optimised for speed, there are no checks, no stack/heap guard, therefore whenever a SPU elf in isolation processes external data that is customized by us, if ever it omits to check that data properly before using it, it can be possible to get an out of bounds write that overwrites the stack enabling you to take control of SPU execution and from there communicate data to the PPU via the mailbox system or whatever.

Roughly and oversimplifying, you could describe this type of SPU hacking with this other example, at some point, someone noticed lv2ldr processed the revocation data stored in the flash memory, to parse the rk list data, lv2ldr needed first to copy it to its dedicated Local Store (dedicated memory range where the isolated SPU heap/stack data is located), to do that, it trusted implicitly the value stored in the flash memory to describe the size of the revocation list data.
It was only a matter of writing to the revocation region of flash memory (doable from userland) to modify the rk list data size with a higher value then add custom SPU code appropriately (far enough) after the revocation list data, then run lv2ldr, it would then copy the revocation list to LS, and more data, until the copying crossed the heap/stack limit, overwrote the stack with the custom SPU code and voilà the SPU executed the custom SPU code. That's the general idea of it anyway.

 

[NiQ]

In theory? No, that's why we call it isolation mode.

In practice? Yes, with a SPU exploit.
The ERK dumper source can show you a way to hack the SPU, there are others, including MikeM64 hardware based one.

SPUs are optimised for speed, there are no checks, no stack/heap guard, therefore whenever a SPU elf in isolation processes external data that is customized by us, if ever it omits to check that data properly before using it, it can be possible to get an out of bounds write that overwrites the stack enabling you to take control of SPU execution and from there communicate data to the PPU via the mailbox system or whatever.

Roughly and oversimplifying, you could describe this type of SPU hacking with this other example, at some point, someone noticed lv2ldr processed the revocation data stored in the flash memory, to parse the rk list data, lv2ldr needed first to copy it to its dedicated Local Store (dedicated memory range where the isolated SPU heap/stack data is located), to do that, it trusted implicitly the value stored in the flash memory to describe the size of the revocation list data.
It was only a matter of writing to the revocation region of flash memory (doable from userland) to modify the rk list data size with a higher value then add custom SPU code appropriately (far enough) after the revocation list data, then run lv2ldr, it would then copy the revocation list to LS, and more data, until the copying crossed the heap/stack limit, overwrote the stack with the custom SPU code and voilà the SPU executed the custom SPU code.

So it's basically a classic buffer overflow.

I assume someone already dumped the RAM of that SPU, nothing interesting there?

 

[bguerville]

So it's basically a classic buffer overflow.

I assume someone already dumped the RAM of that SPU, nothing interesting there?

By RAM, you mean the Local Store? Yes it's been dumped before, you find whatever the currently executing elf has put there.
You can get hold of some keys, in the case of metldr, you can find ERK for instance, that's what the ERK dumper does, in that regard everyone who dumped ERK has dumped isolated SPU ram lol, iirc with lv2ldr, you can get other keys, etc..

 

[NiQ]

By RAM, you mean the Local Store? Yes it's been dumped before, you find whatever the currently executing elf has put there.
You can get hold of some keys, in the case of metldr, you can find ERK for instance, that's what the ERK dumper does, in that regard everyone who dumped ERK has dumped isolated SPU ram lol, iirc with lv2ldr, you can get other keys, etc..

But I assume nothing that would let us mess with metldr

 

[Berion]

What do You mean by messing? On HEN we don't have access to that area.

 

[NiQ]

What do You mean by messing? On HEN we don't have access to that area.

What I meant was, suppose the Cell key was somehow obtained, then you could write your own patched version of metldr2 using an E3 or whatever to run CFW on any console.

 

[Berion]

TBH we don't even know if Cell Key exist. High probably it is, but we don't know, so no one ever also dump it. If exist, probably never leaving Cell.

 

[NiQ]

TBH we don't even know if Cell Key exist. High probably it is, but we don't know, so no one ever also dump it. If exist, probably never leaving Cell.

Wait, suppose it doesn't exist - what prevents us from using a hardware flasher to flash a modifier metldr2 with a custom ECDSA key?

 

[Berion]

Meta loader is encrypted by *something* and *somehow*. We don't know by what, how and from where. The best candidate for this hypothesis is CPU key.

 

[RoboKing's Cosmos]

If I'm correct could the super slim PS3 metldr2 be obtained using the PS4 methods by the fail0verflow?