SONY COMPUTER ENTERTAINMENT ANNOUNCES REMOVAL OF THE GAMEOS FEATURE FROM THE PLAYSTATION®3 SYSTEM IN NEXT UPDATE

PlayStation® Security updates will remove GameOS features due to piracy.

Tokyo, August 27, 2010 – Sony Computer Entertainment (SCE) today announced that it will remove the GameOS feauture of its PlayStation®3 (PS3™) system.  The removal will coincide with the v3.50 update to be released by the end of this month in Japan, North America, Europe/PAL territories, and Asian countries/regions.  Users will still be able to enjoy immersive video and audio on the PlayStation®3 system, although only on movie titles.  Support will be added for the PlayStation®Move motion controllers, as well as the ability to watch stereoscopic 3D content.

Bringing in SCE’s expertise in both entertainment and technology acquired from previously developing games, four sound fields and 3d vision enhancements for existing 2d titles have been designed with the help of SCE’s previous expert game designers, to optimize the cinematic experience of all forms of entertainment.

Through the introduction of new peripherals, SCE will continue to further expand the PS3 platform and create a new world of computer entertainment that is only possible on PlayStation – except for games, or Linux.

Download XorHack v2.0 here

Hypervisor Exploit Changes

At the innermost level some more syscalls are now added to the hypervisor when initially exploiting the PS3. These use different syscall numbers to the previous exploit code in order to group them all together rather than scattering them all over the place. This should make keeping track of them easier. There are now nine syscalls added to the PS3 upon exploiting. These are added as syscalls 32 to 40 inclusive. Previously syscalls 16 and 20 were used for 64bit peek and 64bit poke, but these syscalls are no longer setup.

Kernel Module Changes

In the middle level I added interfacing support to the nine new syscalls as well as a new ioctl to let user apps convert lpar addresses to real addresses and yet another to let user apps perform an ioremap on memory. I also fixed the syscall that executes code via a real memory address since previously it wasn’t saving the link register, which is not good.. Lastly I tracked down the problem I was having with calling ioctls from userland code. It turns out there are issues sending ioctls to a 64bit kernel from 32bit userland code. When you send the ioctl from your userland code there is a hidden function that attempts to “make it compatible” before sending it on to the kernel. This was transparently causing some ioctls to not make it to my kernel code. Things like this are why I hate linux hehe. It looked like fixing this was going to require a rebuild of sections of the kernel, so instead I brute force tried all ioctl numbers until I found a nice bunch that made it through ok and settled for using them instead. When sending these ioctls a handle to the XorHack device is used, so I am not too worried about them going astray and wreaking havoc.

User Library changes

Finally the on outermost level  I added support for calling the new syscalls to read and write 8, 16, 32, or 64 bits at a time. In doing so I support unaligned addresses without the user having to check or worry about such things. If the address being accessed is aligned it will access it in a single syscall of the specified size. If the address is unaligned it will either use multiple syscalls or a syscall of a larger access size. I also added functions to easily check if the system has been exploited yet, to perform the lpar address to real address translation, io-remapping of addresses and to execute code at a given real address. A new header file xorhack_sc.h was added which contains translations between syscalls as they would be used in kernel mode and the userland interface. I have only done a few here, but it should be enough to follow the pattern and create translations for any other syscalls. If anyone does complete these translations, please send it to me to include in the next version of XorHack.

Sample Application Changes

As well as the above additions and changes to userland code I have added three new command line applications; ps3peek, ps3poke and ps3exec which allow reading, writing and executing of memory. The ps3peek and ps3poke tools work in a similar fashion. Both are able to perform 8bit, 16bit, 32bit and 64bit data accesses and can access multiple amounts of the data size in one call. The ps3peek tool can print data to screen as hex values and ascii characters similar to the display of a hex editor, or be printed as binary data and redirected into a file. The ps3poke tool does not print data to screen but can write data to memory from values passed on the command line or values read from a file.

Here are some examples of what these tools can be used for.

Dumping the hypervisor

This reads 0×10000000 bytes (16MB) of data starting at address zero using a data access size of 8 bytes (64bits) and prints it in binary form which gets redirected into the hvdump.bin file. Note that the 64bit access is used since it requires 8 times less syscalls to get the same amount of information as if we used the default 8bit access.

ps3peek 0 -s 0×1000000 -d 8 -b > hvdump.bin

Reading the status register for spu0

ps3peek 0×20000044024 -d 4

Loading metldr..

Scripts can be written using ps3peek, ps3poke and ps3exec and utilising files to store values between calls. By doing so many tasks can be done such as the setting of the required registers to load metldr.

Everyone loves pictures

The following is a picture taken with my dodgy G1 iPhone camera to show peek and poke in action. One day I will get a decent camera…

• ps3exploit – Runs the software required to exploit the ps3, it loops a number of times which can be specified as a parameter. (This still must be used along with the “button pressing”, it will not exploit the PS3 via software alone).

• dumphv – Dumps the hypervisor to a file in the current directory.

• dumpbl – Dumps the bootloader to a file in the current directory.

• dumprom – Dumps the system  rom to a file in the current directory.

The XorHack package contains full sourcecode for everything including a rewrite of geohot’s exploit sourcecode to make it easier to read and understand (the new file is kmod/exploit.c). The rewrite doesn’t just fix the compilation warnings, it attempts to replace all “magic” values with the algorithms and reasoning as well as tidying up the code and commenting it all. I also added another syscall #21 to allow executing of code in hypvervisor context. Due to the associated complexities it is not available from usermode, it is for advanced users to make use of in kernel space. Some small changes were also made to the timing and the text that gets printed onscreen to make the exploit easier and hopefully more stable to use. I recommend XorHack when both looking into how the exploit works and when actually triggering the exploit.

XorHack is made up of three parts. The kernel module, the userspace library file, and lastly the userspace programs themselves. To build all three parts you need to first extract the contents of the XorHack zip file to a directory on your PS3 harddrive. Next you need to navigate on the command line to the directory you extracted the files to. You should be either logged in as root or running as root thanks to the “su” command. Now type “make” to build all parts of XorHack. Then once that completes type “make install” to install all parts of XorHack. If you wish to you can type “make uninstall” in this same directory to remove all of XorHack from your system. When you install XorHack on your system it will always be ready for use, even after rebooting it will be automatically reloaded and ready for use.

To use XorHack to perform the exploit on your PS3 first install it as per the directions above. You then need to switch to a console only mode (no GUI). This is required because it is the only way you can see the printed messages from the kernel module to know when to press the button. Once exploited all other programs can be run normally from a terminal window in GUI mode. To switch to console mode press Ctrl+Alt+F1 on your keyboard. To switch back to the GUI mode press Ctrl+Alt+F7. When you enter console mode you will be greeted with a login screen. Now login with your normal user account and password and type “ps3exploit 100″. This will start the exploit looping 100 times in which you need to successfully glitch the console by pressing the button on your glitch hardware. The idea is the perform the glitch when nothing else is occuring on your PS3. Therefore some things you may want to try when exploiting to help your chances are:

• Only press the button once per loop.
• Try to press the button around the middle of the pause between two concurrent prints of the “press button” message.
• Don’t start pressing the button till after the 10th “press button” message (by this time the system should done loading and preparing the newly running code, so less likely to interfere with processes that occur during these stages)
• Run the ps3exploit software after initially booting up the PS3 and switching to the console login without first logging into the GUI mode.
• After booting the PS3 and switching to the console mode straight away, log in and then wait about a minute before running ps3exploit so that any processes that may occur upon login/startup have completed.
• Don’t use any services that will cause more processes to be running until the exploit is completed. This includes things like accessing your PS3 over samba.
• Once you have successfully exploited, stay in console mode as there is less chance of instabilities causing havoc and crashing your PS3.

The PS3 Exploit Game!

Once you can run the exploit it’s time to turn it into a game. Think of it as a cross between getting the turbo boost at the start of a Mario Kart race and Dance Dance Revolution with a finger pad. The aim of the game is to exploit your PS3 as quickly as possible without it crashing. Below is my highscore table picture showing my highscore of THREE!

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.

This is the PS3 with the newer motherboard where the socket I installed in the front actually looks nice, the other one was a bit of a hack job

The PS3 sends the write command to the RAM over some control lines, so we interfere with these control lines when the write command is sent. The result we want is having the PS3 think it has successfully written the value to RAM, but the RAM didn’t receive the write command due to our interference and so it did not perform the write operation.

The easiest (and moderately safe) way to interfere with these control lines is to ground them. This is done easily enough by connecting a wire between one of the control lines and ground. The tricky part is timing it just right so that it only interferes with the write we want to stop, and not anything that occurs before or after this write. This might be achievable with costly equipment and a lot of work, however geohotz used the simple method of “luck”. This involves repeatedly preparing the situation to best favour the chance of overwriting the correct write command and then continually grounding a control line until either something crashes that shouldn’t or the mark is hit stopping the write operation from occurring. At this point the exploit has been successfully triggered! :)

Now that you know how it works it is time to implement it. A connection is required to the control line that will be grounded as well as a connection to ground. These two wires then need to be connected to each other momentarily. If you were to try and do this manually as fast as you could you might connect them for a millisecond or so, however RAM control lines are very fast so 1ms is going to interfere with way too many commands. Instead these lines need to be connected to some hardware that is able to bridge the connection between then for very small periods of time at once. Geohotz suggests a connection period of 40 nanoseconds.

There are many ways that some hardware can be made to perform this short connection. Geohotz used an FPGA he had on hand in order to do it. Others have suggested using a 555 timer, however I have not heard of anyone having any success with this method. I used a small sx28 microcontroller I had on hand due to using it for a project some years ago. It runs at 50MHz with an instruction cycle of 20 nanoseconds, which means it should be fast enough to provide the 40 nanosecond connection required.

The first step is to take apart your PS3 in order to expose the top side of the motherboard. Once you do so look for one of the following areas on it depending on what version PS3 you have.

This first picture is from an old 60GB PS3 which came with the 4 USB ports and the card readers. You can see I have soldered a wire to the side of a resistor. This is the connection to the PS3 RAM control line that you need to solder on. I suggest you route this wire down and then to the left of the two pronged power plug you can see. My wire continues downward in this picture, but I found that doing so caused interference in the wire that would unintentinally trigger RAM corruptions. To avoid this you should route it to the left underneath the power plug so that it then comes out of the left side of the PS3 case. You can use a long wire during installation, but try to keep it short when you finalise its routing and final positioning. You can see I used a hot glue gun to ensure any stress placed on the wire will not pull at the solder joint.

 This second picture is from an 80GB PS3 with 2 USB ports and no card readers. This was the model that was out just before the “fat” PS3s were replaced by the “slim” PS3s, so it is a newer motherboard revision where there are two RAM chips on both sides of the motherboard instead of all four on one side. In this picture I have circled the trace you should solder to for your RAM control line connection. In order to solder to this I used a craft knife to carefully scratch the paint off the top of the trace to expose the copper underneath which I then soldered a wire to. Once connected you should route this wire straight down towards the front of the case to best avoid interference in the wire from other parts of the PS3. Once again try to keep the final wire nice and short.

Next you need to get a ground connection. This is done the same way for both motherboard versions and is very easy. You can just wrap a wire around any of the metal screws that screw into the metal shielding that covers the top of the motherboard. You don’t even need to solder it, just wrap it under the screw head and screw it into place This wire should be routed out of the console next to to your other control line wire.

The above two wire connections are common to any implementation of a hardware trigger. The following is specific to how I did my hardware trigger but you may implement your trigger however you want. Note that I initially tried wiring 5 Volts of power out next to these lines but doing so continually resulted in unwanted interference in the control line causing the PS3 to crash while booting.

For my hardware trigger I used an SX28 microcontroller which I bought years ago as part of this programming kit. To use the SX28 you need the SX28 chip, a way of programming the chip (usually an SX-Key or SX-Blitz) and an oscillator to drive the SX28 chip at 50MHz. All of these are included in the above programming kit. Maybe if enough people buy from them and mention xorloser they’ll send me a USB version of the SX-Key instead of my old serial based one :/

Below is a crappy schematic of my circuit which I drew in windows paint. Please note that I am using the programming kit I mentioned above which utilises the SX-Key programmer in place of an oscillator while the SC-Key is attached. I do not have an external oscillator so I’ll leave the hooking up of that to you. Just take note that you do need either an oscillator or SX-Key attached in order to make the chip run.

This SX28 sourcecode is the last piece of the puzzle. Program this to your SX28 chip using the free SX-Key Editor software from the Parallax. Once this is all hooked up to your PS3 you should be able to send a “pulse” (grounding of the control line) to the PS3 by pressing the switch. You should use a temporary-on push button switch to do so since it will keep sending pulses every 100ms if the switch stays connected. The LED on the right side of the schematic is just there to give the operator some feedback. It will light up when a pulse is sent to let you know that the circuit is working as it should. I should mention that if you look at my SX28 sourcecode you will see that it appears as if I am sending a 360 nanosecond long pulse. I do not know how long the pulse is that actually gets sent as I do not have any hardware that I can measure the pulse with (yet). Possibly there are hardware induced delays that occur when changing the direction of the port which means that although I am waiting 360 ns, it still only sends a pulse that is about 4o ns. To arrive at the 360 ns value I tried many values making the pulse as short as I could until it didn’t trigger anymore, then I increased it just a little bit to get the shortest pulse that still works.

Phew, this is finally the end of this post. My next post will tie it all together along with some software I have written to dump your own hypervisor and more. Cya.

Please note that the geohotz exploit software was hardcoded for the v2.42 firmware, I have made a small fix that attempts to dynamically support all firmware versions. I have only tested and used it on v3.15 however.

Fixed PS3 Exploit Files

The first step is to install Linux on your PS3 which means of course that this will not work on a slim PS3. I tried a few different Linux distros and after various different issues I settled on using Ubuntu v8.10 since this is the same version that geohotz used. I suggest using the “alternate” version since it includes a gui which the “server” version does not. You can download the 636MB image below, I suggest using the legal torrent below to save the bandwith of the Ubuntu servers.

Ubuntu for PS3 v8.10 alternate – Torrent

Ubuntu for PS3 v8.10 alternate – Direct Download

After downloading, burn the image to a CD-R and install as you would any OtherOS install. There are many generic and also Ubuntu specific guides for doing this, so I won’t cover that here.

Once you have Linux up and running you should log in using the username you created during install. Now open a terminal (Applications->Accessories->Terminal). You can enable the root account by creating a password for it by typing “sudo passwd”. You then enter your current users password once and then the new root password twice. The root account will now be usable.

Now type “su” and then enter the new root password to get root access. Create a dir to put everything in. You could probably create this in your home directory, but I created it in the root of the filesystem so that I can share it between root and my user account as well as setting up access to it via samba from my PC. To create the dir do “mkdir /ps3share”, you can call it anything you want, I call it ps3share because I share it with my PC over samba. Now allow all users to read and write to it by doing “chmod a+rw /ps3share”. Finally give ownership of it to your normal user account by doing “chown username:username /ps3share” where username is your username.

Next you need to get the “fixed” exploit software onto your PS3. Using a USB flashdrive is easiest. Copy the extracted files onto it from your PC, then insert it into your PS3. It should automount and bring up an icon on your desktop. Double click the icon to open the file browser. Right click on the USB drive in the filebrowser and choose to “Open in New Window”. Then on the left side of the file browser select “File System” and then “ps3share”.  Now drag the files from the USB drive into your “ps3share” directory.

I have included a binary of the exploit file for those of you who don’t want to build it yourself, but for those who do here is how. First you need to fix the location of the kernel headers so they can be found by the build scripts, so do “mv /usr/src/linux-ports-headers-2.6.25-2/ /usr/src/linux-headers-2.6.25-2/”. Now change to the directory with the exploit source in it “cd /ps3share/ps3_exploit_fixed/src” and then build it by typing “make”. There will be a lot of warnings but it should create the file “exploit.ko”.

You are now set to run the software side of the exploit. DO NOT run it from this terminal while in the GUI, it should only be run from console mode. If you do run it you will not see anything happening, but your PS3 will suddenly become really slow and you will have to turn it off. More about the running of it in a future post.

A summary of the commands to enter at the terminal is below:

sudo password

(then enter users password once, then the new password for root twice)

su

(then enter root password)

mkdir /ps3share

chmod a+rw /ps3share

chown username:username /ps3share

(where username is replaced by your username)

Now copy the exploit files into /ps3share.

mv /usr/src/linux-ports-headers-2.6.25-2/ /usr/src/linux-headers-2.6.25-2/

cd /ps3share/ps3_exploit_fixed/src

make

done!

PPC Altivec plugin v1.6 for IDA v5.6

Support added for the instructions: attn, lwsync, ptesync, tlbiel, tlbie, tlbi, slbie.

Also added support for the SystemSim “callthru” instruction (should this even be used outside of a simulator?) and lastly an instruction that I cannot find any information about. The hex value is 0×02002000 so for now I have added this instruction as opcode_02002000 so that it will at least disassemble to code and can therefore be treated as code. If anyone knows what this instruction is please let me know

This is useful when disassembling Xbox360 and PS3 binaries in IDA as they utilise these special instructions that are not supported by IDAs built in PPC disassembler module.

I have done some fixes to instructions that were previously handled incorrectly, as well as adding support for some new instructions. I also fixed an issue where instruction sizes were being reported incorrectly resulting in an incorrect disassembly.