Sponsored Links

Sponsored Links

Page 1 of 3 123 LastLast
Results 1 to 10 of 29



  1. #1
    Senior Member ModderFokker's Avatar
    Join Date
    Mar 2008
    Posts
    281
    Sponsored Links

    How the PS3 Hypervisor was Hacked and Dumped by GeoHot

    Sponsored Links
    A few days ago GeoHot Hacked the PS3 and dumped the PlayStation 3 hypervisor lv0 and lv1, and has now updated his blog with a technical writeup [Register or Login to view links] on how it was done written by Nate Lawson at rdist.root.org.

    To quote from the article: "The PS3, like the Xbox360, depends on a hypervisor for security enforcement. Unlike the 360, the PS3 allows users to run ordinary Linux if they wish, but it still runs under management by the hypervisor. The hypervisor does not allow the Linux kernel to access various devices, such as the GPU. If a way was found to compromise the hypervisor, direct access to the hardware is possible, and other less privileged code could be monitored and controlled by the attacker.

    Hacking the hypervisor is [Register or Login to view links] required to run pirated games. Each game has an encryption key stored in an area of the disc called [Register or Login to view links]. The drive firmware reads this key and supplies it to the hypervisor to use to decrypt the game during loading. The hypervisor would need to be subverted to reveal this key for each game. Another approach would be to compromise the Blu-ray drive firmware or skip extracting the keys and just slave the decryption code in order to decrypt each game. After this, any software protection measures in the game would need to be disabled. It is unknown what self-protection measures might be lurking beneath the encryption of a given game. Some authors might trust in the encryption alone, others might implement something like [Register or Login to view links].

    The hypervisor code runs on both the main CPU (PPE) and one of its seven Cell coprocessors (SPE). The SPE thread seems to be launched in isolation mode, where access to its private code and data memory is blocked, even from the hypervisor. The root hardware keys used to decrypt the bootloader and then hypervisor are present only in the hardware, possibly through the use of [Register or Login to view links]s. This could also mean that each Cell processor has some unique keys, and decryption does not depend on a single global root key (unlike [Register or Login to view links] that claim there is a single, global root key).

    George's hack compromises the hypervisor after booting Linux via the "OtherOS" feature. He has used the exploit to add arbitrary read/write RAM access functions and dump the hypervisor. Access to lv1 is a necessary first step in order to mount other attacks against the drive firmware or games.

    His approach is clever and is known as a "[Register or Login to view links]". This kind of hardware attack involves sending a carefully-timed voltage pulse in order to cause the hardware to misbehave in some useful way. It has [Register or Login to view links] by smart card hackers to unlock cards. Typically, hackers would time the pulse to target a loop termination condition, causing a loop to continue forever and dump contents of the secret ROM to an accessible bus. The clock line is often glitched but some data lines are also a useful target. The pulse timing does not always have to be precise since hardware is designed to tolerate some out-of-spec conditions and the attack can usually be repeated many times until it succeeds.

    George connected an FPGA to a single line on his PS3's memory bus. He programmed the chip with very simple logic: send a 40 ns pulse via the output pin when triggered by a pushbutton. This can be done with a few lines of Verilog. While the length of the pulse is relatively short (but still about 100 memory clock cycles of the PS3), the triggering is extremely imprecise. However, he used software to setup the RAM to give a higher likelihood of success than it would first appear.

    His goal was to compromise the hashed page table (HTAB) in order to get read/write access to the main segment, which maps all memory including the hypervisor. The exploit is a Linux kernel module that calls various system calls in the hypervisor dealing with memory management. It allocates, deallocates, and then tries to use the deallocated memory as the HTAB for a virtual segment. If the glitch successfully desynchronizes the hypervisor from the actual state of the RAM, it will allow the attacker to overwrite the active HTAB and thus control access to any memory region. Let's break this down some more.

    The first step is to allocate a buffer. The exploit then requests that the hypervisor create lots of duplicate HTAB mappings pointing to this buffer. Any one of these mappings can be used to read or write to the buffer, which is fine since the kernel owns it. In Unix terms, think of these as multiple file handles to a single temporary file. Any file handle can be closed, but as long as one open file handle remains, the file's data can still be accessed.

    The next step is to deallocate the buffer without first releasing all the mappings to it. This is ok since the hypervisor will go through and destroy each mapping before it returns. Immediately after calling lv1_release_memory(), the exploit prints a message for the user to press the glitching trigger button. Because there are so many HTAB mappings to this buffer, the user has a decent chance of triggering the glitch while the hypervisor is deallocating a mapping. The glitch probably prevents one or more of the hypervisor's write cycles from hitting memory. These writes were intended to deallocate each mapping, but if they fail, the mapping remains intact.

    At this point, the hypervisor has an HTAB with one or more read/write mappings pointing to a buffer it has deallocated. Thus, the kernel no longer owns that buffer and supposedly cannot write to it. However, the kernel still has one or more valid mappings pointing to the buffer and can actually modify its contents. But this is not yet useful since it's just empty memory.

    The exploit then creates a virtual segment and checks to see if the associated HTAB is located in a region spanning the freed buffer's address. If not, it keeps creating virtual segments until one does. Now, the user has the ability to write directly to this HTAB instead of the hypervisor having exclusive control of it. The exploit writes some HTAB entries that will give it full access to the main segment, which maps all of memory. Once the hypervisor switches to this virtual segment, the attacker now controls all of memory and thus the hypervisor itself. The exploit installs two syscalls that give direct read/write access to any memory address, then returns back to the kernel.

    It is quite possible someone will package this attack into a modchip since the glitch, while somewhat narrow, does not need to be very precisely timed. With a microcontroller and a little analog circuitry for the pulse, this could be quite reliable. However, it is more likely that a software bug will be found after reverse-engineering the dumped hypervisor and that is what will be deployed for use by the masses.

    Sony appears to have done a great job with the security of the PS3. It all hangs together well, with no obvious weak points. However, the low level access given to guest OS kernels means that any bug in the hypervisor is likely to be accessible to attacker code due to the broad API it offers. One simple fix would be to read back the state of each mapping after changing it. If the write failed for some reason, the hypervisor would see this and halt.

    It will be interesting to see how Sony responds with future updates to prevent this kind of attack.

    [Edit: corrected the description of virtual segment allocation based on a comment by geohot.]"

    How the PS3 Hypervisor was Hacked and Dumped by GeoHot

    More PlayStation 3 News...

  2. #2
    Contributor hellospaceboy's Avatar
    Join Date
    Jan 2009
    Posts
    130
    Sponsored Links

    How the PS3 Hypervisor was Hacked and Dumped by GeoHot

    Sponsored Links
    Geohotz's comments about the Root Lab's explanation of the hack:
    Oh, it can’t specify the new segment HTAB address. I just spam until I get the right one

    The SPEs can be used as oracles, although perhaps not from OtherOS. On a TEST, you can dump lv2 and games. Combine that with this, and thats everything. It’s just a matter of software to get lv2 to load using this.

    It does give you full access to the GPU. This really is a full hack of the PS3, despite how long it takes some people to believe it. The isolated SPEs can be viewed as black box crypto engines. Whether we can ever run them without a system is somewhat irrelevant. For example, the iPhone and PSP both have crypto engines that require the hardware, but are both widely hailed as hacked.

  3. #3
    Senior Member mushy409's Avatar
    Join Date
    Oct 2008
    Posts
    329
    Sponsored Links
    Sponsored Links
    In regards to ModderFokker's post, it's basically like an "inside man" job. Glitching the Hypervisor so it doesn't wipe the RAM leaving a small window to plant a few small landmines for the Hypervisor to step on.

    As I said, sounds similar to the Xbox 360, the CPU is glitched (reset) while the rest of the system (CPU, RAM, etc) is still active. When the CPU has reset, it loads code from a different address in flash (eg. XeLL...)

    Please correct me if I'm wrong but this is my basic understanding.

  4. #4
    Contributor jammyone's Avatar
    Join Date
    Dec 2009
    Posts
    36
    Thanks mushy409 - that sounds like a nice basic summary of what GeoHot has done. It's the first explanation I've understood anyway

  5. #5
    Forum Moderator PS3 News's Avatar
    Join Date
    Apr 2005
    Posts
    28,063

    Thumbs Up

    I moved this into a thread of its own for discussion, and also mirrored it in the Site News... +Rep to ModderFokker as well.

  6. #6
    Contributor pro2oman's Avatar
    Join Date
    Jan 2010
    Posts
    18
    Geo's comment sparks yet another hope, are dev's looking in the "test/debug" flag or are they still focused on the reversing/analyzing of dumps... no rush..

  7. #7
    Forum Moderator PS3 News's Avatar
    Join Date
    Apr 2005
    Posts
    28,063
    Quote Originally Posted by pro2oman View Post
    Geo's comment sparks yet another hope, are dev's looking in the "test/debug" flag or are they still focused on the reversing/analyzing of dumps... no rush..
    Most of them are still waiting for someone to (publically) release/leak either GeoHot's HV dump (which was "spoonfed" to select Devs ) or one of their own to examine. They just don't have the time nor materials to bother dumping it themselves at the moment, and honestly, there is little need for it (besides comparing them) when dumps already exist.

    There was word earlier today on IRC that at least one other person (possibly from PS2Dev, although I can't confirm that as I see no mention of it there due to the warez factor) made an internal dump of it using GeoHot's method but I have yet to see it.

    To my knowledge, the only ones currently working on reversing the GeoHot dump are Mathieulh's crew and possibly GeoHot himself. CJPC had a quick peek at a segment from it the other day and did confirm the flags are in it as Mathieulh tweeted on but that's about it.

  8. #8
    Contributor proZero's Avatar
    Join Date
    Jan 2010
    Posts
    4
    As far as I understood it, the first thing we will get is probably a not-circumcised Linux with full access to the RSX.

    Question is if the Cell security concept will ever allow us to dump any root key for backups, but that's not really what I want A Linux that can use the full power of the PS3 would be enough, hopefully some smart guys are writing a 3D Driver for the RSX...

  9. #9
    Contributor modzila's Avatar
    Join Date
    Dec 2009
    Posts
    33

    Thumbs Up

    This explanation is a lot more accessible to the masses and possibly help peeps understand how much work and ingenuity these Devs have to come up with. I hope this will build some respect and stop these requests for loaders.

    Respect to GH and all Devs who put aside their own greed in order to achieve something jointly (and the OP for sharing this info).

    It makes me wonder though, why sony released the slim, I mean cutting costs, sure, but removing OtherOS, which was a sunken cost... Did they too started to realise allowing peeps to install Linux was too generous?

  10. #10
    Contributor lilstevie's Avatar
    Join Date
    Dec 2009
    Posts
    17
    Quote Originally Posted by mushy409 View Post
    In regards to ModderFokker's post, it's basically like an "inside man" job. Glitching the Hypervisor so it doesn't wipe the RAM leaving a small window to plant a few small landmines for the Hypervisor to step on.

    As I said, sounds similar to the Xbox 360, the CPU is glitched (reset) while the rest of the system (CPU, RAM, etc) is still active. When the CPU has reset, it loads code from a different address in flash (eg. XeLL...)

    Please correct me if I'm wrong but this is my basic understanding.
    The xbox 360 exploit is actually an exploit in hypervisor itself, Xell catches and resets the CPU threads.

    [Register or Login to view links] is a good writeup on the xbox 360 hypervisor exploit

 

Sponsored Links

Page 1 of 3 123 LastLast
Advertising - Affiliates - Contact Us - PS3 Downloads - Privacy Statement - Site Rules - Top - © 2014 PlayStation 3 News