Sponsored Links

PS4 News on Facebook! PS4 News on Twitter! PS4 News on YouTube! PS4 News RSS Feed!
Sponsored Links
Sponsored Links
Home PS4 News - Latest PlayStation 4 and PS3 News

How the PS3 Hypervisor was Hacked and Dumped by GeoHot

Sponsored Links
269w ago - 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.]"

How the PS3 Hypervisor was Hacked and Dumped by GeoHot

Stay tuned for more PS3 Hacks and PS3 CFW news, follow us on Twitter, Facebook and drop by the PS3 Hacks and PS3 Custom Firmware Forums for the latest PlayStation 3 scene and PlayStation 4 scene updates and fresh homebrew PS3 Downloads. Enjoy!

Comments 28

• Please Register at PS4News.com or Login to make comments on Site News articles.
#18 - Ps3Rips - 269w ago
Ps3Rips's Avatar
You can either use a FPGA like GeoH did, or you can use a Mono-Stable circuit which seems like the easier of the two options it should be able to do the same thing.

#17 - TUHTA - 269w ago
TUHTA's Avatar
well... i understood... well i need to write program... and i need harware... which hardware do i need?

#16 - zangetsu1 - 269w ago
zangetsu1's Avatar
1ns = 1x10^-9 it's the same as 1 divided by 1000000000

in other words 1ns = 1 nano seconds..

#15 - Warrorar - 269w ago
Warrorar's Avatar
with 40ns he means the time you have to push the signal to 1.

easiest way is to write a assembler program and connect the pc with the board.

#14 - TUHTA - 269w ago
TUHTA's Avatar
well i can do it at myself but i just still can't understand, where its dumping? and what is that 40ns? how can i get 40ns? what i must to use? Do i need to solve something?

#13 - Rac3rX - 269w ago
Rac3rX's Avatar
I'm interested in seeing where this goes, homebrew on regular PS3's would be sweet.

Not to mention getting Linux the ability to use the PS3 hardware accelerators finally..

#12 - PS4 News - 269w ago
PS4 News's Avatar
Quote Originally Posted by internetfloozy View Post
So when can an average user expect to be able to get their hands on one of these dumps to look at?

That's the question most are asking at the moment... my guess is either when someone from the community with the equipment dumps it themselves and shares it publically, when CJPC has time and dumps it (assuming nobody else does, otherwise he won't bother), or when the existing dumps are leaked to more people pretty much.

#11 - internetfloozy - 269w ago
internetfloozy's Avatar
So when can an average user expect to be able to get their hands on one of these dumps to look at?

The more eyes experimenting with RE the better.

#10 - semitope - 269w ago
semitope's Avatar
Quote Originally Posted by PS3 News View Post
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.

It'd have been cool if they had the time and equipment though. Maybe they can poke around beyond what geohot did. I doubt they could attempt getting keys without some hardware.

#9 - lilstevie - 269w ago
lilstevie's Avatar
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.

http://www.securityfocus.com/archive/1/461489 is a good writeup on the xbox 360 hypervisor exploit


Advertising - Affiliates - Contact Us - PS4 Downloads - PS4 Forums - Privacy Statement - Site Rules - Top - © 2015 PlayStation 4 News