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]
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/
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.
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?
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 Im not that expert, but u can help some developers with your Ideas in this Forum, so lets 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....
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..
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
Hmm... 8th core could be used for low-powered background Folding :D
Broken? why broken...
could we turn it on? XD
Oh ok, : ) thats better, is it me or has geo's hack brought more confusion and anger than it has joy? Because what we have here is, 90% who have no clue, a hacked OtherOS, not a fully hacked ps3, also we have people complaining about how oh we dont want ISO loaders, when actual fact i'm sure most do, what i mean is a way to play our backups, which we bought LEGALLY XD..Its good we have read write access to linux now (full) but if we cant use the exploit, its as good as having nowt at all... dont flame meeeeeeeeeeeeeee.... XD eep!
From the link I posted earlier,
Ok so what I got out of this article is that all we gotta do is wait for someone to "reverse engineer" the hypervisor to where a software exploit can be found? Until then I'm assuming some company will probably come up with some kinda tool to work through the glitching process for us and then software to make whatever changes. I'm thinking kinda like the Wii where there was a modchip first and then later on the soft-mod came...
With full access to the PS3 hardware on the Linux side, if nothing ever comes up on the PS3 side I'm sure someone will design some kinda emulator?
What does have access to the 7th SPU?
if the HV doesnt call it nor does the operating sys
what sends info to it?
The problem is that it's not really the kinda full access on the linux side that people need for backup exploits. You'll never get full access to the system from Linux because of it's design, it's got hardware features that limit what the software can do.
Because alot of the PS3's security is hardware based, not only software based, you'll find it very hard to get a software exploit. Amongst other things, there's a random number generator(apparently it's like a datestamp to prevent replay attacks) that is used to encrypt information, as well as the root key. Because the root key is in the spv, you won't get it by any software means. You'll have to find some other way to get in through hardware.
And looking at the information inside the spu's as it's being run(to get the root key when it's decrypting the code) is extremely hard. The other devices place the data onto the ls of the designated spu, the spu lock the ls and completely isolates itself from the system(by design it blocks it's connection to the buses) to work on the data. Once it's done processing the data, It will clear the ls and if it needs to, response data and place it back onto the ls then accept connections again. The root key is never exposed, and no software is gonna expose it. It's mostly done by hardware.
That's why it will be hard to get your homebrew to run on the PS3, we need to somehow encypt it with that number generated by the random number generator and the root key before it's verified and processed inside the spv.
The only way to get backups playing again will be from a hardware mod, and it won't be easy
i think that's bs and swap magic would like a word with you about playing ps2 backups without a hardware mod.
we got a otheros hardware exploit now, with enough time the people working hard on this may have a gameos software exploit for us.
i'm not trying to bash you and you are right about alot of things, i just believe with enough time, the sky turns from black to blue.
so that being said, has/can anyone analysed an animated theme for a possible exploit? they have rsx access right? do they have some of the same code as the regular themes or are they completely different?
It might be a stupid idea, but if there is full access to the system from OtherOS, would it be possible to design homebrew stuff as an "OtherOS" (so the PS3 would "think" you're just booting Linux)?
@teejoo: you have "full" access to the hardware but there is no driver for the videocard so 3D would be a problem
I have another Opportunity that might be something interesting. Dump the NVRAM, change the Harddrive so the Hardware key will be calculated new in the NVRAM, then dump it again and localize the Key. Would that be possible or did i miss something??
I have a question.
Did anyone use this exploit yet ?
I know that it is real, but I also would like to know if somebody works on something using this exploit.
I hope you understand what I want. (and sorry for my english Im german)
every ps3 has 2 keys personal and master key(the 1 every1 wants)
the ps3 encrypts the harddrive with a personal key
there is a way to find your personal key by (i think) dumping an image of ur hard drive then using the backup option of the ps3
the ps3 then decrypts your HD backup