XorHack: The PS3 Exploit Toolkit is Now Available!
Today xorloser has shared his XorHack: The PS3 Exploit Toolkit which allows you to call lv1 syscalls (level 1 system calls) from a normal (userspace) program and run the software required when triggering the PS3 exploit from a normal userspace program.
To quote: I finally found the time to complete the PS3 exploit toolkit software I mentioned to in my previous posts. I call it XorHack.
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!
More PlayStation 3 News...
Seems my post was too late :-(
Skywalker of Hitmen
im trying to get the (or better my [from the flashdump]) metldr to load by the SPU. Do this by setting up everything for the SPU, including channels 3,4 and 0x18 (whereby, what is channel 0x18 used for ? 3 and 4 are known what theyre used for, but what did the isolated load request expects in channel x18 ?). So the SPU goes into isolated mode in loadstate but immediately do a "load failed" (SPU isolated but stopped, RetCode 1) ... i either tried the original image location of metldr (within exploited SC space) and to load it on myself in kernel mapped space as file, setting image load address for isolated load request + 0x18 to whatever (0, -1 or tried size of image) ... every try only results in "load failed" state of the SPU. Tried both version with the 256KB image at the end of the flash too, same result (load failed with RC 1) ...
Any idea whats wrong on this ? Any help would be nice, thxSkywalker of Hitmen
Yeah, already read that code, but its just his playfield, thus wrong about the load up of the image ... afaik it needs to be loaded via the channels / registers the load state is waiting for, but it seems im wrong on their setup.Skywalker of Hitmen
Still no success on loading metldr (see some posts below), still getting "load failed" with RC=1 ... if you have any idea what could be wrong, help would be nice, thx.geohot
You are correct about the channels. That code snippet I posted doesn't work.
Also, for some reason I couldn't do it without the exploit.Skywalker of Hitmen
Oh, ok, so you still need the exploit running while trying to isolate load ? Are you pointing to the image inside the mem-mapped flash then, or are you trying to load it on yourself ? And do i have to issue a DMA transfer via MFC Proxy regs, or "just" need to set up the two corresponding, doc'd image address channels plus channel 0x18 (which i still dont know whats it supposed to do during load phase, maybe size of the image) ?
Anyway, thx for the infos so fargeohot
I was first trying to create an SPU the normal way and poking the registers in the lv2/problem mapped stuff, but I couldn't get that working. So instead I used the exploit(lv1/lv2/problem) and didn't tell the hv I was using an SPU.
Cool, idk where you found docs on the channels(you mean signal registers right?). To load metldr, the only ones I use are the two address ones. Though perhaps you are loading metldr correctly and just aren't using it right.Skywalker of Hitmen
Oh, thats interesting, thanks for this info on not using lv1 HV for allocating the SPU, need to try that later. As my SPU stalls with W bit set on status register if i dont write to those *3* channels (address ones and this strange 0x18 one, all read blocking seen from SPU side), so maybe the creation using lv1 HV causes the registers to behave strangely. i took the channel infos from "CBEA_v1.02_11Oct2007_pub.pdf" (sorry, dont have the link here atm, somewhere on the usual ibm-documentation page), chapter 9.
I dont think that the metldr is loaded correctly, since i never reached a running state with it. SPU isolate load|running (281) -> SPU isolate load|stopped (282) with return code 1 ... how to handle the metldr once it is running is something i dont have any clue about for now, and i guess this is hard to understand (since its Thony prop stuff, against ibm cell standard based isolation stuff to handle for now). But surely i will try to go further with all of this, like i did with all Thony consoles so far Of course, if help is offered/needed i'll listen thankfully ...disane
Some stuff can be found in the following IBM articles:
Cell Broadband Engine processor DMA engines, Part 1: The little engines that move data:
Cell Broadband Engine processor DMA engines, Part 2: From an SPE point of view:
More on SPU channels on chapter 9 of this documentation by IBM :
I'm guessing your trying to set up the isolation mode the wrong way. I'll dig up a few Cpp source codes on how to do that with both isolation modes. Here's some reading while your waiting:
https://www-01.ibm.com/chips/techlib...Guide_v3.0.pdfSkywalker of Hitmen
geohot, is MFC_SR1 TL (bit 57) set or unset, thus HV controls TLB or the HW ?
That's OK RexVF5... if you wouldn't have said anything I wouldn't have replied, so no biggie HEHE.
That's a very well documented source code, seriously, you can easily go through the whole program without losing yourself in some weird and "magic" lines. This is a very good job indeed, thank you for sharing XORLOSER, I mean, you are giving us the possibility to execute code from user space ... that's just so cool.
A hell of a contribution
Does this still need the Hardware exploit to work or is it just possible by software ? I'm no dev so perhaps this question is stupid : "userspace" means PS3 linux or not ?
Some more information from the blog:
The flashdump metldr location is fetched through asecure_loader from ROM... You could try aversing loading failure (SPU) through allocating alternative to 0x40000 in physical memory.
Load fail with RC1 will still occur as you get null Retcode 1 when the SPU is stopped.