How the PS3 Hypervisor was Hacked and Dumped by GeoHot
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 here 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 not the only step required to run pirated games. Each game has an encryption key stored in an area of the disc called ROM Mark. 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 SecuROM.
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 eFUSEs. This could also mean that each Cell processor has some unique keys, and decryption does not depend on a single global root key (unlike some articles 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 "glitching attack". 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 long been used 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.]"
More PlayStation 3 News...
How the PS3 Hypervisor was Hacked and Dumped by GeoHot
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.
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.
Thanks mushy409 - that sounds like a nice basic summary of what GeoHot has done. It's the first explanation I've understood anyway
I moved this into a thread of its own for discussion, and also mirrored it in the Site News... +Rep to ModderFokker as well.
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..
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.
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...
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?
http://www.securityfocus.com/archive/1/461489 is a good writeup on the xbox 360 hypervisor exploit