PS3 Glitch Hack
This is an event log for the PS3 Glitch Hack, sorted oldest comes first.
Hello hypervisor, I'm geohot
Friday, January 22, 2010
geohot @ http://geohotps3.blogspot.com/2010/01/hello-hypervisor-im-geohot.html
I have read/write access to the entire system memory, and HV level access to the processor. In other words, I have hacked the PS3. The rest is just software. And reversing. I have a lot of reversing ahead of me, as I now have dumps of LV0 and LV1. I've also dumped the NAND without removing it or a modchip.
3 years, 2 months, 11 days...thats a pretty secure system
Took 5 weeks, 3 in Boston, 2 here, very simple hardware cleverly applied, and some not so simple software.
Shout out to George Kharrat from iPhoneMod Brasil for giving me this PS3 a year and a half ago to hack. Sorry it took me so long :)
As far as the exploit goes, I'm not revealing it yet. The theory isn't really patchable, but they can make implementations much harder. Also, for obvious reasons I can't post dumps. I'm hoping to find the decryption keys and post them, but they may be embedded in hardware. Hopefully keys are setup like the iPhone's KBAG.
A lot more to come...follow @geohot on twitter
fine, one tweet... i just hacked the PS3... http://geohotps3.blogspot.com/
Saturday, January 23, 2010
I know some function names...
And now if calls have restrictions I don't like, I zap them.
Monday, January 25, 2010
What it is and what it isn't
First off, this is not a release blog like "On The iPhone". If you are expecting some tool to be released from this blog like blackra1n, stop reading now. If you have a slim and are complaining this hack won't work for you, stop reading now. WE DO NOT CONDONE PIRACY, NOR WILL WE EVER. If you are looking for piracy, stop reading now. If you want to see the direction in which I will take this blog, read the early entries in the iPhone one. Information on this blog is for research purposes only.
That aside, I'll tell you what I have so far. I have added two hypercalls, lv1_peek and lv1_poke. peek reads memory in real space(including all the MMIO), poke writes it. I can also add other arbitrary hypercalls as I see fit.
The hypervisor is complicated, it is written in C++ and is PPC, which I am not that familiar with yet. At first I was trying to add a hypercall to add arbitrary real memory to the LPAR, but it kept crashing(because I can't code), which is really annoying, because I have to wait while Linux reboots.
Some people pointed out that I have not accessed the isolated SPEs. This is true. Although as far as doing anything with the system, it doesn't matter. The PPE can't read the isolated data, but it can kick the isolated SPEs out. Decrypt the PPE binary you need using the intact SPE and save the decrypted version. Kick out the SPE, and patch the decrypted version all you want. And interesting note, by the time you get to OtherOS, all 7 working SPEs are stopped.
Despite this, I am working on the isolated SPEs now(which I can now load), because what I'd really like to do is post decryption keys here so you guys can join the fun.
Tuesday, January 26, 2010
A level playing field
Right now, I'm playing with the isolated SPEs, trying to get metldr to load from OtherOS. Interesting thing, I am not using the exploit. I always assumed the enable isolation mode register was hypervisor privileged. It's not, it's kernel privileged, which means using hypervisor calls you can all get to it. So, get to hacking. Here is the code I am playing with.
I'm not that opposed to releasing the exploit, but I think the majority of you are going to be disappointed, even if you do get it working. Unless you have pushed the HV to it's limits, this exploit really isn't going to do much for you...yet. So install OtherOS and start playing around. If people start coming up with convincing reasons why they need the exploit to go further, I'll release it. It's just a waste to release if people can't make use of it.
As far as the GPU goes, I have full access to the GPU memory space 0x2800... But without a driver, it's useless. 3D video card drivers are notoriously hard to write, look at the ATI and NVIDIA ones for linux. The best are still the closed source manufacturer ones. I'm not even sure I believe that the HV restricts video card access, just that the OtherOS driver is 2D. If someone skilled in video card driver development comes forward, and they can explain in detail what the HV is restricting, I'll send them the exploit.
And something has to be done about the comments. Theres a couple of good ones, mixed in with tons of trash. Please, if you don't have something technical and useful to say, don't say it. This is not the place for congratulations(go back to the hello hypervisor post), debates about piracy(go somewhere else, the internet is big), or trying to convince me to do X.
Tuesday, January 26, 2010
Here's your silver platter
In the interest of openness, I've decided to release the exploit. Hopefully, this will ignite the PS3 scene, and you will organize and figure out how to use this to do practical things, like the iPhone when jailbreaks were first released. I have a life to get back to and can't keep working on this all day and night.
Please document your findings on the psDevWiki. They have been a great resource so far, and with the power this exploit gives, opens tons of new stuff to document. I'd like to see the missing HV calls filled in, nice memory maps, the boot chain better documented, and progress on a 3D GPU driver. And of course, the search for a software exploit.
This (mirror) is the coveted PS3 exploit, gives full memory space access and therefore ring 0 access from OtherOS. Enjoy your hypervisor dumps. This is known to work with version 2.4.2 only, but I imagine it works on all current versions. Maybe later I'll write up how it works.
I've gotten confirmation the exploit works on 3.10. Also I've heard about compile issues on Fedora. I did this in Ubuntu. I think this qualifies as a nice tutorial at least for the software side. :)
This is a good article for what it means for the less technical. A good more technical writeup is here.
IRC snip from geohot somewhere explaining the hack
geohot: well actually it's pretty simple geohot: i allocate a piece of memory geohot: using map_htab and write_htab, you can figure out the real address of the memory geohot: which is a big win, and something the hv shouldn't allow geohot: i fill the htab with tons of entries pointing to that piece of memory geohot: and since i allocated it, i can map it read/write geohot: then, i deallocate the memory :) geohot: all those entries are set to invalid geohot: well while it's setting entries invalid, i glitch the memory control bus geohot: the cache writeback misses the memory geohot: and i have entries allowing r/w to a piece of memory the hypervisor thinks is deallocated geohot: then i create a virtual segment with the htab overlapping that piece of memory i have geohot: write an entry into the virtual segment htab allowing r/w to the main segment htab geohot: switch to virtual segment geohot: write to main segment htab a r/w mapping of itself geohot: switch back geohot: PWNED geohot: and would work if memory were encrypted or had ECC geohot: the way i actually glitch the memory bus is really funny geohot: i have a button on my FPGA board geohot: that pulses low for 40ns geohot: i set up the htab with the tons of entries geohot: and spam press the button geohot: right after i send the deallocate call
PS3 exploit released...good luck community http://geohotps3.blogspot.com/
Friday, February 5th, 2010
PS3 Exploit: Software
xorloser @ http://xorloser.com/?p=162
As I’m sure everybody heard, the memory access exploit for the PS3 hypervisor was released recently by geohotz. I was finally able to replicate his hack so I thought I’d take the time to help out others who may also have trouble due to being linux n00bs like me :) If I were to post everything at once it would be too much work and I’d never get around to it, so I’ll post bits at a time to ensure I actually do post it heh. Today’s post will talk about the software side of the exploit.
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.
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.
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
Monday, February 8th, 2010
PS3 Exploit: Hardware
xorloser @ http://xorloser.com/?p=175
This post will deal with the hardware required to trigger the PS3 hypervisor memory access exploit. The purpose of the hardware is to stop the PS3 from saving a change to a value that we don’t want changed. The PS3 saves this changed value by writing the value to RAM. Therefore in order to stop it from saving the changed value we need to stop this write from occurring.
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 (mirror) 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.
Monday, February 8th, 2010
PS3 Exploit Setup
xorloser @ http://xorloser.com/?p=214
Just a quick pic of it all working together cos everyone loves pictures!
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 ;)
Saturday, February 13, 2010
On the Isolated SPUs
Today I verified my theories about running the isolated SPUs as crypto engines. I believe that defeats the last technical argument against the PS3 being hacked.
In OtherOS, all 7 SPUs are idle. You can command an SPU(which I'll leave as an exercise to the reader) to load metldr, from that load the loader of your choice, and from that decrypt what you choose, everything from pkgs to selfs. Including those from future versions.
The PPU is higher on the control chain then the SPUs. Even if checks were to be added to, for example, verify the hypervisor before decrypting the kernel, with clever memory mappings you can hide your modified hypervisor.
Ah, but you still didn't get the Cell root key. And I/we never will. But it doesn't matter. For example, we don't have either the iPhone or PSP "root key". But I don't think anyone doubts the hackedness of those systems.
I wonder if any systems out there are actually secure?
Today I validated my theories about running the isolated SPUs on the PS3 as crypto engines. The PS3 is 100% hacked. So where my homebrew at?
Wednesday, February 24th, 2010
PS3 Exploit Tidbits
xorloser @ http://xorloser.com/?p=230
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 (mirror). 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 (mirror). 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.
Thursday, March 4th, 2010
XorHack: The PS3 Exploit Toolkit
xorloser @ http://xorloser.com/?p=254
I finally found the time to complete the PS3 exploit toolkit software I mentioned to in my previous posts. I call it XorHack (mirror). It allows you to call lv1 syscalls (level 1 system calls) from a normal (userspace) program. It also lets you run the software required when triggering the PS3 exploit from a normal userspace program. To give an example of how it can be used I have included the following example programs:
- 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!
Sunday, March 7th, 2010
PS3 Glitch Finder released
I have released PS3 Glitch Finder which is a VHDL design for Spartan-3 (eg. xc3s400) FPGAs with the purpose of easily creating a custom pulse which can be used to glitch various hardware, like the PS3 memory bus. The design should work with most of the Spartan-3 development boards out there (eg. Spartan-3 Starter Kit, Basys, Nexys, Discovery or similar). This small project has been a lot of fun and reminds me of the happy days of phreaking using blue box, the art of finding that working 'break' (tone combo) for an unsuspecting toll-free switch board in a country far away somewhere. Now we can enjoy finding the perfect glitch for PS3 instead. ;) More info regarding the project can be found in the wiki, and if you have suggestions or just want to comment try this forum topic. The VHDL source code is released under GPL v2.
Thursday, March 18, 2010
As some people in the comments called, it's an RCO file edit, just like RCO edits on the PSP(almost same format too). RCO files are resource files for VSH plugins, live in the dev_flash, and aren't signed. To edit them on your system, patch your hypervisor to allow encrypted access to the partition(flash on old systems, hd on new), and mod ps3pf_storage. dev_flash is just a FAT partition, mount it in Linux and change what you'd like.
Friday, March 19th, 2010
XorHack v2.0: The Updated PS3 Exploit Toolkit
xorloser @ http://xorloser.com/?p=297
After using the XorHack for a while I realised it was missing some things so I decided it was time for an update. New syscalls have been added to give finer control over data access, now providing 8, 16, 32 and 64 bit reads and writes. Also some new ioctls were added to provide additional useful functions for your userland code. Lastly new userland applications were added which now give the ability to read, write and execute memory from the command line :)
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
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…
Monday, March 29, 2010
A note to people interested in the exploit and retaining OtherOS support, DO NOT UPDATE. When 3.21 comes out, I will look into a safe way of updating to retain OtherOS support, perhaps something like Hellcat's Recovery Flasher. I never intended to touch CFW, but if that's how you want to play...
Two things, some people seem to think CFW will enable some sort of piracy. It won't. It'll just be a custom version of 3.21 that doesn't lose OtherOS support. Hacking isn't about getting what you didn't pay for, it's about making sure you do get what you did.
And this is about more than this feature right now. It's about whether these companies have the right to take away advertised features from a product you purchased. Imagine if an exploit were found in Safari on the iPhone, but instead of fixing it, Apple decides to pull web browsing altogether. Legally, they may be within their right to do so, but we have to show them it's the wrong move for the future of the product and the company.
don't update to 3.21 if you are interested in the exploit or otheros support
Wednesday, April 7, 2010
OtherOS Supported on "3.21OO"
Here is a video demoing my "custom firmware". It's not any sort of version string change; I would have added something showing off the new features of 3.21, but oh wait, there aren't any.
This can be installed without having to open up your PS3, just by restoring a custom generated PUP file, but only from 3.15 or previous. It's possible this CFW will also work on the slim to actually *enable* OtherOS; I'll know when my infectus gets here.
No release date yet, use the proxy hack to play online with 3.15
Note to the people who removed OtherOS, you are potentially turning 100000+ legit users into "hackers."
New PS3 blog post, OtherOS on 3.21 @ http://geohotps3.blogspot.com/ --Tweeted from my iPad