Busy day at the PS3 scene this weekend. PSX-Scene member known as “user” has release a tool that allows hypervisor debugging from GameOS. (more…)

Your Ad Here

That is it guys!! almost full control of the Ps3 now! Hacker Extraordinaire Graf_Chokolo announced minutes ago that he successfully exploited the hypervisor through gameOS here is what he had to say on the matter:

—Quote—
I have just exploited and dumped HV 3.15 from GameOS

I used memory glitching like Geohot to get dangling HTAB entry but 2nd and 3rd stages are quite different. I used my knowledge about HV internals and created a simpler exploit for stage2 and stage3.

I didn’t use second VAS like Geohot. I used lv1_undocumented_function_114 and lv1_undocumented_function_115 to exploit HV after i got a dangling HTAB entry

I will make everything public very soon and i plan to dump HV 3.41 in the next days

Happy new year guys
—End Quote—
we are still yet to know if any hardware is required i have already asked him this, but i think it is not!

Source PSX SCENE

Your Ad Here

Haxnetwork member xenno aka malow82 on Youtube, posted the PS3 segment of GeoHot’s speech at the Nuit Du Hack Conference, on IRC a few nights ago, i have been busy so never got round to posting, anyhow, here are the video’s.

Remember JaicraB, the guy who managed to dump the PS3 hypervisor and tell us how he did it? Well looks like he is back to work again and released his KeyFindPuP application and more information on his current progress.

To quote below (translated):

Good! For business reasons I have not had occasion to pursue my hobby. Although we have less time to devote some time still.

We stayed with the method of Dump LV2, but will not be entirely useful without appropriate software, which is why I open the door in case anyone wants to help do not hesitate.

Contact hadesteam@hotmail.com. HadesTeam? A small nonprofit group, we just like to learn. This group consists mainly of the following persons: JaicraB, DemonHades, Calimba, DanteHades and Druid. That said, do not hesitate to help.

Mainly we want to Lv2? As you know the PUP has a number of checks with Hmac_Sha1. If we make a clean dump of the process of installation of the Key PUP Hmac_sha1 achieve in this struggle to unpack a PUP to carry out changes and re-create the Hash.

How?

We need a otheros.bld as simple as cash. A BLD with built the exploit and a stand to dump the memory. If someone offers volunteer program, contact. Once we have the dump is necessary to search for the Key. I have designed a program which facilitates the task: jaic_Hmac_sha1_file.zip Provide us find the Key.

Extra Information

The installation of the PUP has three phases:
1. Checking the hash described in PUPHeader.bin
2. UPDATE to unpack the hard disk cache area Fat32.
3. Verification and update of hardware modules.

Process

Having a second hard drive formatted with the PS3 and have the BLD (see above). Enter the first drive and enter the recovery with the PUP in a USB.

The first process to run the PUP from the recovery checks described in the file hashes PUPHeader.bin. If everything is correct UPDATE unpacks the hard disk. At that time makes a reset and return to continue the installation.

At that time you restart and have lost the KEY, as it would be replaced by other data. Solution? Motherboard Keep constantly fed and cause instant shutdown.

“The next day the board will explain how to keep the system fed without being noticed. (Is curious to see the fan on the hard drive and other peripherals and the red light on.) Also explain how to cause instant off with a small bug on the BIOS controlled.”

With these two methods can turn off the PS3 at any time hold the RAM and make a Dump.

Objectives

Getting the key to restructuring a Hmac_Sha1 and PUP. The advantage of being able to change modules update. If you want to help hadesteam@hotmail.com.

Today, not having the special BLD we are investigating the BD player with good results. Greetings!

[Download KeyFindPuP for PS3 Dumps ]
[VIA]

JaicraB has released his method on how he dumped the PS3 Hypervisor LV2. The method does require soldering and is not for the inexperienced.

[VIA]

jaicrab has posted his dumps on his blog for the PS3 hypervisor and bootloader he managed to do via Xorhack toolkit. You can download dumps below.

Quote from his blog (translated):

Good. I’ve managed to make the Hyper Dump and BL. In the end I pulse generator echo PC using the search and the parallel port.

Outline LPT1:

Software: (I AM NOT RESPONSIBLE for damage to the pileup, is a very simple, just polished. Q is unlikely to burn something, but also take into account q LPT1 port is very delicate. Good luck!)

Advisable to do so under MSDOS. Download the boot disk Windows 98, copy the executable and run it. No conecteis LPT1 port until q do not enter the program. The source was made with Turbo C + +.

The important thing is to share and not keep anything more if it is for the common good. Do not make bad use of my Mac and my PS3′s own data

Dumps Download:
Hypervisor (Dump 1):

http://megaupload.com/?d=SJ0NX5SQ

Hypervisor (Dump 2):

http://www.megaupload.com/?d=ZO4K6OYT

BootLoader:

http://www.megaupload.com/?d=X9KX2WSA

Zip Pass: jaicrab.jaicrab

[VIA]

Demonhades has posted today progress/findings of the PS3 hypervisor and boostrap (lvl0/level1).

To quote:

For those who bear on our community and this study shall know the hypervisor and bootstrap, but for new and newcomers who want to know about the safety features on ps3, and is protected as it manages the hypervisor (hardware manager) believe that interesting reading this list.

Then I leave it here hypervisor dump that I have gone and published it to all make a good background paper on the hypervisor and the bootstrap

Here you will be added all the features you get in a list, if you see that are already discussed here, and exposed them to not only need to copy them from your valleys and fast

You can view the full (rough English translation) examination at the discuss in forums link, or the more organized version at the VIA link (in Spanish).

[VIA]

xorloser has released his PS3 HV Dump setup script for IDA which “setups function tables including the hypercall (syscall) table, mmcall table, OPD, TOC, GOT. It will find common functions such as puts and printf and very importantly it will fixup all rtoc references which are used to access global variables and strings”. You can download the file below.

I haven’t gotten around to doing an update in a while due to work (and a little relaxation) taking all my time. Rather than wait till I have finished all of the stuff I wanted to before posting again I decided to post some tidbits to tide you over until the rest is ready. Before I do so I’d like to make the following clear as no matter how many times I say it, people believe what they want to believe instead:

THIS PS3 EXPLOIT WILL NOT ENABLE PLAYING OF COPIED OR BACKED UP GAMES. THE EXPLOIT IS FOR RESEARCH PURPOSES ONLY.

It seems someone took some initiative and made some software themselves to dump the hypervisor once they have the correct hardware and software. So for anyone who has used that and dumped their own hypervisor I present this PS3 HV Dump setup script for IDA.This script will setup function tables including the hypercall (syscall) table, mmcall table, OPD, TOC, GOT. It will find common functions such as puts and printf and very importantly it will fixup all rtoc references which are used to access global variables and strings.

To use the script you should extract it somewhere and then from within IDA select “File->IDC File…”, then navigate to where you extracted the file and select it. Please note that this script could overwrite your previous work, so please run backup your idb/i64 file before running it. I recommend running it on a freshly created database by loading your hypervisor dump into IDA as “ppc” at ROM address 0 and then running this script as detailed above before doing anything else.

The other tidbit I wanted to share was the updates to the PPC Altivec plugin source code which I had forgotten to include in the recent releases, but which a few people have since asked for. Here is the PPC Altivec plugin v1.6 for IDA v5.6 with sourcecode. If anyone makes any fixes or adds support for new functions please pass these updates back to me so I can share them on this site.

[Download HV Dump script for IDA]
[VIA]

Now this is a nasty rumor to be awoken to, just as the scene finally broke down the hypervisor security, we now hear rumors that Sony is planning to block OtherOS support via next PS3 firmware update.

Owen Stampflee Linux Product Manager for Fixstars Corporation made the following post in the yellowdog-boards:

Everyone,

I’ve caught a rumor from a reputable source that the next firmware update for old PS3s will remove the OtherOS feature…

I’m not sure if it’s true or not but it’s in the best interest of the YDL community to spread the word.

Cheers,
Owen

This indeed is an unexpected move on Sony’s part if indeed this rumor is real, but of course we all know the solution and that is to not update .

[VIA]

PS3 Hacker CJPC has managed to dump the PS3 hypervisor and LV1 and Bootloader LV0 via PS3 RAM. He has provided a brief explanation of what he did and a download file to the exploit can be found in the VIA link:

We are happy to report that the PS3 Hypervisor LV1 and Bootloader LV0 are dumped from the PlayStation 3′s RAM after getting our SX28 Hardware a few days ago, utilizing code for glitching and mashing buttons for hours – the exploit eventually will get triggered!

We tried a few different ways to dump out the real memory – the biggest “problem” was the fact that you can’t just simply use File I/O code in a kernel module. Furthermore, you can’t call the lv1_peek function from user mode either.

Luckily, resident DEV kakarotoks was up to the challenge. After some trial and error (and too many PS3 crashes!) he made a kernel module which maps the “real” PS3 memory to a device in /proc. The /proc area lets the kernel and userland interact some.

Basically, the device /proc/ps3_hv_mem is created when the kernel module is inserted. Once it is inserted, you can use dd to read the device. By doing this, the device gets passed arguments, which is passed along to lv1_peek – which in turns reads out the real memory.

Be advised, don’t go beyond the PS3′s upper memory limit. At around 260MB, the PS3 tends to crash – it does not like trying to read beyond RAM limits! So, for usage:

First, run the exploit, and get it triggered and working – that’s the hard part!

Next, download the attached file, inside are three files, a Makefile, the ps3_hv_mem.c and a pre-compiled version. Stick these in a folder, and run make. It will then compile a kernel module for you (ps3_hv_mem.ko, or use the pre-compiled one). Then simply type: sudo insmod ps3_hv_mem.ko

Enter your password and check /proc for a ps3_hv_mem entry, or your dmesg. If it is there – let the dumping begin!

You can dump out the PS3 Hypervisor and Bootloader (and the rest of the real memory) via dd. You can use the command:

dd if=/proc/ps3_hv_mem of=PS3_Memory_Dump.bin bs=1024 count=10K

That command will dump out 10485760 bytes, or about 10MB – which nicely includes the goodies like LV0 and LV1. Finally, you can also increase the count, which will increase the amount dumped (multiply by blocksize).

[VIA]

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]