XorHack v2.0: The Updated PS3 Exploit Toolkit

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 :)

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 0x10000000 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 0x1000000 -d 8 -b > hvdump.bin

Reading the status register for spu0

ps3peek 0x20000044024 -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…

920 thoughts on “XorHack v2.0: The Updated PS3 Exploit Toolkit

  1. and each cell bootrom is otp, and cell has a unique key per each piece…. the cell key which is written at manufacturing time and is also otp.. 😛

  2. @Marcux
    X3max didn’t release anything, except promises. So you can safely assume they claimed it just to have their names in headlines.

  3. Zaxis,

    Thats just Ozmods’ sales pitch. I could drive the whole 15km and see for myself but I don’t need to – Its doesn’t make business sense to do a downgrade that way when they have a USB dongle that does it in a flash.

  4. @graf_chokolo

    hey, i cant get the bootstrap working properly… maybe you can give me some hints :)
    I compiled it with ps3toolchain, then tried with psgroopic and psfreedom (obviously padding it correctly).
    I cant really tell if the ps3 crash or if the bootstrap get executed correctly, but the only things for sure is that sendfile doesn’t receive any ACKs :(
    I’m using a cross cable to my laptop directly and my ps3 is a fat CECHL04.
    Can it be a problem from gcc-ppu ?

    Any help is appreciated, btw GREAT WORK! :)

  5. I was playing around with PUP files, I was curious and replaced some 3.41 files with the 3.50 files.

    CORE_OS_PACKAGE.pkg (3.41 to 3.50 PUP)
    dev_flash_003.tar.aa (3.41 to 3.50 PUP)

    I recompiled it, and used the service jig to install it to the ps3. I turn it on and I get the YLOD. Could it be a coincidence of the timing, or is it because the ps3 is rejecting the firmware I’ve made. I can’t do anything with it, is there any chance of fixing it or should I toss it out as junk?

  6. Pingback: graf_chokolo found OtherOS support in Fw 3.41 - PSX PS2 PS3 Scene Modchip & Jailbreak Community

  7. @graf_chokolo
    I compiled it with ppu gcc from the ibm cell sdk and it worked!

    Only one thing is strange:
    I noticed that sendfile did not recognize the packets that the ps3 sends as ACKs so it keep sending the first one!
    I made a dumb patch to avoid the ACKs check and to send all the packets from first to last with a delay of 2 second.

    with this method i tested dump_lv2 and it seems to work fine :)

  8. @jestero

    The problem with sendfile could be pcap filter. Look at source code and try to remove vlan filter. Some users reported this problem to me. Maybe it will help you. I tested my code only with IBM’s ppu cross compiler. I didn’t test it with other ppu compilers. I never had problems with IBM’s ppu compiler so no reason to use other compilers :-)

  9. Holy crap, guys :-) Did you know that LV2 kernel from service JIG is very different from retail version, it contains e.g. LPM (Logical Performance Monitor) and other stuff which LV2 3.41 doesn’t contain :-) I want to install it on my FAT ps3 and dump HV kernel :-) Maybe then i will found out how to use those isolated SPU modules contained in service JIG PUP :-)

  10. Guys, you know how $ONY calls HVCALL99 ? :-)

    They call it: lv1_authenticate_program_segment :-)

  11. @DOWNGRADEFTW

    I dont think it cames from the modified PUP i think you have a real Hardware prob.

    now about your idea with replace some files of the pup its good but i think there is a better way mabe by injekt the groove payload direct to the core_os pkg so we dont will need the JB more only we nee PSgrade to load the modified PUP than to the flash.

    i just looking for information about the pup, i think there must b any rev file on it that says with part of the pup will install and else. i wee see on the diference sys mabe the 80 GB with Soft emu for PS2 there must be some different to the others system i pup a PS2 Disc in a 80 GB PS3 with soft emu the XMB telme it is a PS2 disc on a PS without BC you get the massage incompatible Disc so ther must be sometink else. if i make the same in Service mode this PS without BC say its a Ps2 Disc and i can start it but after a time its jump back to XMB ant say this game is not compatible and i have to look on the PS3 info page if this game realy work or not.

    so where to hell is this option in the pup.

  12. I released several days ago my SELF decrypter. With that you will be able to decrypt all SELFs upto 3.41 firmware. The payload is in file decrypt_self_direct.c. It uses metldr and appldr directly to decrypt SELFs.
    Furthermore, you will need a revoke list for programs which can be extracted from PUP files. Have fun guys :-)

  13. @graf_chokolo
    \You definetely need very good ASM knowledge in PPC of course And knowledge about operating systems design like Linux, BSD or other Unix would help a lot IBM and $ONY provided us with a lot of free useful documentation about Cell CPU and other stuff. And look at my HV reversing page.\
    i am also trying to get involved in the scene and want to make sure i know and have everything i need before getting started so is there anything else i need to know. btw i am also working a guide to the PS3 for noobs anything you think i should include

  14. @graf_chokolo

    yep, i already fixed that!
    I just removed the vlan filter and now it receive ACKs…
    Then i noticed that:

    pkt_hdr = (struct pkt_hdr *) (vlan_eth_hdr + 1);
    pkt_hdr->offset = ntohl(pkt_hdr->offset);

    I don’t know why but in my case the right \offset\ is in pkt_hdr->magic :)

  15. I know this isn’t the proper place but I couldn’t really find your PS3 NID Attack tool on xorloser.com. I need to find the NID for sys_fs_access (int sys_fs_access(char const *, int) ) and was thinking your tool would be perfect for the job. I’ve downloaded it from some foriegn website and was wondering if you could give mean idea on how to run it. Any help would be greatly appreciated. Thanks for all the hard work!

  16. Never mind, I figured it out. Thanks for writing such a great program by the way. I would of never of gotten the NID address or whatever it’s called for cellFsAccess if it wasn’t for you.

Leave a Reply

Your email address will not be published. Required fields are marked *