How the PS3 Hypervisor was hacked. - PS3Hax Network

Pirate · 01-28-2010

With the great news of the hypervisor being hacked by Geohot, many people are now wondering, what next, how does this work, and what can I look for in the future? Nate Lawson has posted up an excellent explanation detailing Geohots hack and what exactly is going on. For those interested in a less technical explanation you can view one here.

To quote:

George Hotz, previously known as an iPhone hacker, announced that he hacked the Playstation 3 and then provided exploit details. Various articles have been written about this but none of them appear to have analyzed the actual code. Because of the various conflicting reports, here is some more analysis to help understand the exploit.

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.

[VIA]

s3r4ph · 01-28-2010

I thought that the PS3 does not depend on the hypervisor for security, it's security is mostly hardware based.
http://www.ibm.com/developerworks/po...-cellsecurity/

Alycan · 01-28-2010

Ever wondered why the PS3 uses 7 of it's 8 cores whilst playing games?

Core 8 is HyperVisor. So the security is software AND hardware based.

Disane · 01-28-2010

Ever wondered why the PS3 uses 7 of it's 8 cores whilst playing games?

Core 8 is HyperVisor. So the security is software AND hardware based.

aha !!! I'm slowly putting this together

So the HV is already running in a an isolated SPE. And we can alter its functionality using GeoHot's exploit by manipulating the memory segment where the HV is. This just sounds too awsome to be true. Or its just me being an idiot know nothing about how the PS3 works

MIDASA · 01-28-2010

so when we use the data he posted we can direktly do what ever we wanna do in Linux, without the HV complaining
Or does the Exploit has to be implemented in every Programm, which could be complanable for the HV?

xKillerdogx · 01-28-2010

So what are we able to do now?
One Opportunity is to swap some functions in the Libraries e.g. to avoid security checking, but they are also securitry checked so someone skilled has to write a function with exactly the same hash, like write a function and fill it with comments to have a hash collusion. But maybe this will not work cause of other security checks.

Another Opportunity is to dump the driver of the videocard and load it inside the otheros system, that we now can use with complete kernel access and all SPEs (not the isolated one). If this is possible we were able to do much more inside Linux.

PS: I dunno if I did mistakes in my solutions cause I´m not that expert, but u can help some developers with your Ideas in this Forum, so let´s make a good brainstorming here and not 90% nonsence

And the PS3 is still not hacked like the way we want it to, we just got access to the Hardware like never before, but just in the OtherOS....

SuperDre · 01-28-2010

But at the moment the hack still needs expensive hardware to get access to the HV, or am I wrong? Or would it already work on any PS3 which can run OtherOS without the need for extra HW.. because only then we can actually try to see if a 3d driver can be made based on the Nvidia open source driver, since the RSX is based on the 7900 as far as I know..

DNAM · 01-28-2010

yeah it needs the hw to shock the system
i think from now on its research to see how the function works and add/replace functions for a better understanding of the functions
lv1_peek will really come in handy

Sublimewulf · 01-28-2010

Originally Posted by Alycan

Ever wondered why the PS3 uses 7 of it's 8 cores whilst playing games?

Core 8 is HyperVisor. So the security is software AND hardware based.

PS3 uses 7 cores (AKA SPUs). 6 for Developers and games and 1 for the hypervisor. The 8th is turned off to increase chip yield and reduce production costs.

David562 · 01-28-2010

Hmm... 8th core could be used for low-powered background Folding :D

Originally Posted by s3r4ph

I thought that the PS3 does not depend on the hypervisor for security, it's security is mostly hardware based.
http://www.ibm.com/developerworks/po...-cellsecurity/

Hypervisor is software code running on hardware... Basically, It's coded into the hardware(kinda.... ).

01-28-2010	#1
Pirate Join Date: Feb 2007 Posts: 6,938 Likes: 370 Liked 7,999 Times in 1,238 Posts Mentioned: 569 Post(s) Tagged: 0 Thread(s)	How the PS3 Hypervisor was hacked. With the great news of the hypervisor being hacked by Geohot, many people are now wondering, what next, how does this work, and what can I look for in the future? Nate Lawson has posted up an excellent explanation detailing Geohots hack and what exactly is going on. For those interested in a less technical explanation you can view one here. To quote: George Hotz, previously known as an iPhone hacker, announced that he hacked the Playstation 3 and then provided exploit details. Various articles have been written about this but none of them appear to have analyzed the actual code. Because of the various conflicting reports, here is some more analysis to help understand the exploit. 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. [VIA]

01-28-2010	#6
xKillerdogx Apprentice Join Date: Feb 2008 Posts: 19 Likes: 2 Liked 0 Times in 0 Posts Mentioned: 0 Post(s) Tagged: 0 Thread(s)	What now? So what are we able to do now? One Opportunity is to swap some functions in the Libraries e.g. to avoid security checking, but they are also securitry checked so someone skilled has to write a function with exactly the same hash, like write a function and fill it with comments to have a hash collusion. But maybe this will not work cause of other security checks. Another Opportunity is to dump the driver of the videocard and load it inside the otheros system, that we now can use with complete kernel access and all SPEs (not the isolated one). If this is possible we were able to do much more inside Linux. PS: I dunno if I did mistakes in my solutions cause I´m not that expert, but u can help some developers with your Ideas in this Forum, so let´s make a good brainstorming here and not 90% nonsence And the PS3 is still not hacked like the way we want it to, we just got access to the Hardware like never before, but just in the OtherOS.... __________________ [SIGPIC][/SIGPIC]I wear my sunglasses at night

		PS3Hax Network - Playstation 3 Hacks and Mods > News > PS3Hax News
How the PS3 Hypervisor was hacked.

01-28-2010	#2
s3r4ph Apprentice Join Date: Oct 2009 Posts: 19 Likes: 1 Liked 0 Times in 0 Posts Mentioned: 0 Post(s) Tagged: 0 Thread(s)	I thought that the PS3 does not depend on the hypervisor for security, it's security is mostly hardware based. http://www.ibm.com/developerworks/po...-cellsecurity/

01-28-2010	#3
Alycan Member Join Date: Nov 2008 Posts: 175 Likes: 14 Liked 20 Times in 16 Posts Mentioned: 0 Post(s) Tagged: 0 Thread(s)	Ever wondered why the PS3 uses 7 of it's 8 cores whilst playing games? Core 8 is HyperVisor. So the security is software AND hardware based.

01-28-2010	#5
MIDASA Member Join Date: Dec 2008 Posts: 72 Likes: 34 Liked 6 Times in 6 Posts Mentioned: 0 Post(s) Tagged: 0 Thread(s)	so when we use the data he posted we can direktly do what ever we wanna do in Linux, without the HV complaining Or does the Exploit has to be implemented in every Programm, which could be complanable for the HV?

01-28-2010	#7
SuperDre Member Join Date: Mar 2008 Location: helmond.nl Posts: 508 Likes: 98 Liked 126 Times in 84 Posts Mentioned: 21 Post(s) Tagged: 0 Thread(s)	But at the moment the hack still needs expensive hardware to get access to the HV, or am I wrong? Or would it already work on any PS3 which can run OtherOS without the need for extra HW.. because only then we can actually try to see if a 3d driver can be made based on the Nvidia open source driver, since the RSX is based on the 7900 as far as I know..

01-28-2010	#8
DNAM Apprentice Join Date: Mar 2008 Posts: 22 Likes: 2 Liked 0 Times in 0 Posts Mentioned: 0 Post(s) Tagged: 0 Thread(s)	yeah it needs the hw to shock the system i think from now on its research to see how the function works and add/replace functions for a better understanding of the functions lv1_peek will really come in handy

User Name		Remember Me?
Password