"A few days ago the new Phrack Issue had its street date including an [Register or Login to view links] about Hacking the Cell Broadband Engine Architecture.
The author BSDaemon who works for [Register or Login to view links] used a PlayStation 3 system for his tests and got very interesting information for you; definitely worth reading!"
The article covers topics including: Debugging Cell, Debugging the SPE, Finding/Exploiting Software Vulnerabilities on Cell SPE, Memory Overflows, SPE memory layout, Avoiding Null Bytes and more on the PS3.
Those interested can check it out linked above in full!
It is an interesting read - It's a beginners guide to writing code on the Cell. However, it contains no real surprises and definitely no exploits as such.
It's also concentrating on SPE vulnerabilities. Exploiting this is difficult, since the hypervisor (running on a SPE) protects main memory used by both the SPE and PPE. The hypervisor is essentially self-contained after boot - If it has been properly designed (and the lack of a hack after this amount of time suggests nothing else) it has only well defined external interfaces that can't be exploited by any obvious method.
So, to get an exploit in OtherOS or GameOS, you need to cause the hypervisor SPE to run your own code. There are also symptoms which would tend to indicate that there is a "watchdog" to ensure that the hypervisor is still active - If I was implementing this, it would be an external device to the processor that accepts some sort of signed message at 5 second or so intervals which resets the CPU in case of a missed heartbeat.
I noticed xorloser commented on this article at his blog today: [Register or Login to view links]
It is a nice introduction and overview of the cell for anyone who is new to it.
Unfortunately the “hacking/exploit” section takes up about 1 paragraph among the pages and pages of general info. If you were to read the official docs that this was based upon then the hacking/exploit information is pretty self evident. Basically it comes down to no memory protection, so you can write to “code” sections and execute “data” sections which is the requirements for buffer overflow style exploits that have existed for a long time. The wrap around memory addressing is a bonus that makes this even easier.
What they don’t mention is the secure isolated SPU mode that anything of consequence runs in on the SPUs. In this mode the only access to the internals of the SPU is through an interface that is defined inside the isolated SPU module. Also these modules are encrypted and signed so that you cannot see how they work or alter how they work, making exploiting them very tricky.