Results 1 to 8 of 8

Thread: Phrack Magazine: Hacking the Cell Broadband Engine Architecture

  1. #1
    Join Date
    Apr 2005

    Phrack Magazine: Hacking the Cell Broadband Engine Architecture

    To quote from SKFU's recent find:

    "A few days ago the new Phrack Issue had its street date including an article about Hacking the Cell Broadband Engine Architecture.

    The author BSDaemon who works for RISE Security 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!

    More PlayStation 3 News...

  2. #2
    Shrink Guest


    Sounds like Christmas!
    Anything in the works already?

  3. #3
    Join Date
    Apr 2005
    I know CJPC agreed it was an interesting read... not sure about anything in the works as a result of it yet though.

  4. #4
    walidahmadi Guest
    This looks interesting.. but whether anything rises from this or not is another question ?

  5. #5
    shummyr Guest
    this could lead to some good stuff!

  6. #6
    Dibblah Guest
    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.

  7. #7
    red8316 Guest
    Very interesting read, thank you. I'm not very technical but I love to try and learn more. Cheers.

  8. #8
    Join Date
    Apr 2005

    Thumbs Up

    I noticed xorloser commented on this article at his blog today:

    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.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts