PS3 hacked by famous hacker

[joeorc]

Lurker said:
The reason it wasn't done earlier is because it's an expensive process. It's still too expensive for the majority of pirates to screw with it. They gotta have Blu-ray burners and stuff.

that's not what this Hack is talking about.

example:

the online blog stated from the claimed hack

"

Hello hypervisor, I'm geohot

I have read/write access to the entire system memory, and HV level access to the processor. In other words, I have hacked the PS3. The rest is just software. And reversing. I have a lot of reversing ahead of me, as I now have dumps of LV0 and LV1. I've also dumped the NAND without removing it or a modchip.

 

now if you read this:

 

I posted this info in the previous thread:

 

However, even with LV1, the beauty of the Cell's security is the Isolated SPU mode, which keeps code out of main memory, and it isolates itself totally - so it "in theory" can not be dumped, which is of course, where all the goodies are (keys, keys, keys)

also:

v0 (bootloader) just takes a tiny bit of code, pushes it to the cell to start the bringup and lv1 doesn't do any crypto, it just sends an encrypted image (the ldr's) to a isolated SPU which is what actually "works the magic."
Sure, that might be sufficient for saying "Hello World" in Linux but it wouldn't help with using the "PS3" part of the PlayStation 3 to do everything else.

 

these response's was short to the point of what the SPU security is on the PS3 i have the IBM white paper on the security of the PS3 if your interested it's quite robust in its security. the PS3's security is no joke.

 

The Secure Processing Vault
Goal: isolation of an application
To achieve a secure platform, a processing environment must exist where a single application can execute isolated from all other executing software threads in the system. The Cell BE processor's Vault can provide such an environment. Within the vault, the execution of the application and its data cannot be manipulated or observed -- the hardware design prevents other applications from doing so. For example, digital movie content can be decrypted in, and played from, the vault without the danger of the content being compromised.

its called a VAULT for a reason this is not only software but also dedicated hardware

The goal of isolating a process thread is not new; however, in contrast to the hardware-based method, existing approaches have used software to enforce the separation.  The operating system or the hypervisor (also known as the virtual machine monitor -- the layer of software with the most authority in a virtualized system) has the responsibility of separating processes.  For example, the operating system would ensure that the memory location of the high-value digital content is protected from reads and writes from non-authorized processes.  The problem with this approach is that if an adversary takes control of the operating system or the hypervisor, all bets are off.  The adversary can use the operating system to change the permissions for the memory area it is trying to break into, or simply use the operating system to read the memory location since the operating system can read any memory location in most systems.  In fact, this is why the operating system (or root) is usually the target for hackers and viruses.  An adversary will look for a weakness in the operating system design, such as a buffer overflow vulnerability (see Resources), exploit this hole to gain control of it, and then execute operations that only the operating system has privileges to do.  Within this kind of environment, sensitive data can be easily copied by the adversary-controlled operating system because the memory protection for that data no longer has any effect. The same argument would hold for a virtualized machine where a hypervisor controls the memory accesses of different processes.  If the hypervisor is compromised, whatever protection mechanisms it is intended to provide will not matter anymore.  

The fundamental problem with existing approaches is that they rely on software to provide the isolation, but at the same time software can be manipulated by an adversary.

 A better approach is for the hardware design to isolate the process in such a way that the software cannot override the isolation, and this is precisely what the Cell BE processor's Vault provides.

THIS RIGHT HERE IS VERY IMPORTANT READ IT!

The Vault is implemented as an SPE running in a special mode where it has effectively disengaged itself from the bus, and by extension, the rest of the system.  When in this mode, the SPE's LS, which contains the application's code and data, is locked up for the SPE's use only and cannot be read or written to by any other software.  Control mechanisms which are usually available for supervisory processes to administrate over the SPE are disabled.  In fact, once the SPE is isolated, the only external action possible is to cancel its task, whereby all information in the LS and SPE is erased before external access is re-enabled.  From the hardware perspective, when an SPE is in this isolation mode, the SPE processor's access to the LS remains the same, while on the other side of the LS (the bus side), external accesses are blocked. Thus, all LS read and write requests originating from units on the bus such as the PPE, other SPEs, and the I/O have no effect on the locked-up region of the LS.  However, an area of the isolated SPE's LS is left open to data transfers to and from other units on the bus for communication purposes.  The application running on the isolated SPE is responsible for ensuring that the data coming through the open communication area of its LS is safe.  Also, consistent with the idea that the cores execute independently, any number of SPEs can be in isolation mode at any given time.

 

Figure 3. The application inside an isolated SPE cannot be observed or modified

 

NOW READ THIS!

All of this is accomplished exclusively by hardware means; no software, in the form of setting protection bits in an address translation table for example, is involved in the process.  Because of this hardware isolation, even the operating system and the hypervisor cannot access the locked up LS or take control of the SPE core.  Therefore, a hacker who has gained root or hypervisor privileges is not a threat to an application executing on an isolated SPE. The supervisory privileges will not enable him to control the application, nor will it allow him to read or write the memory used by it.  The execution flow and the data of the isolated application are safe.

 

A hotel analogy clarifies this security model; the hotel manager (PPE) allocates a room (SPE) for a guest (application).  The guest can lock the room from the inside; the hotel manager, and other guests, cannot peek into the room.  However, the hotel manager can kick the guest out.

 

TO READ MORE

http://www.ibm.com/developerworks/power/library/pa-cellsecurity/