Dit is een zeer belangrijke exploit, het is zelfs een stapje dicht bij METLDR!

Darkhacker heeft deze exploit uitgebracht, maar hij is zeker niet de enige vinder hiervan. Deze exploit zou ons opnieuw een stapje dichter brengen naar de METLDR exploitatie, al was deze al eens eerder uitgevoerd. Echter was dit steeds nog met stenge beveiliging, dus je had bijlange geen volledige controle over je PlayStation 3 systeem. Deze exploit loopt voor een stuk gelijk met de hardware exploit van geohot, alshoewel deze exploit ons volledige toegang tot alles biedt. Dit wil dus zeggen dat er hiernaast niets hoeft te draaien, met volledige toegang tot het lv2 geheugen!

Dit is natuurlijk allemaal zeer mooi, maar het wordt aangeraden om dit enkel te gebruiken als je toch al een redelijke basis hebt in het programmeren voor de PlayStation 3. Darkhacker houdt er ook rekening mee dat hij net zoals geohot voor de rechter gedaagt zou kunnen worden hiervoor, maar die strijd ziet hij volledig zitten. Met deze exploit kun je bijvoorbeeld bij het opstarten al volledige toegang hebben tot alle geheugens van je PlayStation 3, wat niet niets is. Ik heb hieronder de download van het .pdf bestandje gezet, als er gevraagd wordt om de download te verwijderen, zal ik dit onmiddellijk doen.

Mening van Mathieulh

muhahahahaha this is just the cell reset line trick, you can use this to dump lv2 from 1.10 to 3.15 but that's it.

Oh! and it's been known for ages by about....err... everyone...

The fact is you can't glitch the cell to even access the isolated LS because it's PHYSICALLY disconnected from the bus.

As in the cell was especially designed for the purpose of preventing access to the isolated LS by anything but the isolated process. You can read details about this here: The Cell Broadband Engine processor security architecture

Anyway I'll stop talking of ps3 stuff for now, I am still pissed.

That so called "cpu exploit" allows no more than dumping lv2 from 1.10 to 3.15. That's it. It's just pointless.

The trick only worked because the otheros setting was written upon selection rather than upon shutdown.

Then you could coldboot to a small piece of code installed in the linux partition which would dump the lv2 ram space for you.

No, the isolated LS gets physically disconnected from the bus when isolation kicks in. That's the way it's designed

Only the isolated process itself can access the isolated Local Store.

Isolation itself is designed in a very secure way, I have never seen IBM engineers messing around when it comes to security.

The line itself is cut, so to speak.

As in the bus can have no physical interaction whatsoever with the isolated Local Store.

In fact, should you have access to the nexus/jtag port on the cell, you still couldn't access the isolated Local Store.

This means that to effectively dump the isolated LS content, you need to exploit the isolated process itself.

Yes there is obviously a logic gate being involved in the process.

Sadly most details from IBM about isolation are under NDA, so we don't know what's going on for sure "underneath"

The only way to access the isolated LS again by software is to destroy the SPU and Create it again but this would delete the data.

of course I do not mean to physically destroy the spu xD.

Mainly what happens is that so long as a SPU runs isolated, only the software on that SPU can access the isolated LS, nothing else

Then how about the code that actually kickstarts the isolation ?

Then what does decrypt the bootloader and metldr ? There has to be some rom doing the decryption and holding key

Of course the spu isolation itself would be done by hardware, but only "trusted" software can run isolated

Those are the public docs you know ?

A lot of the cell docs are NDAed, You cannot expect the spu to just jump at encrypted instructions can you ?