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. What about the flags at 00002100?

    00002108 : “allow bypass of HV for unrestricted memory r/w access”
    00002120 : “disable decryption SPU”
    00002164 : “set console type : 00000001 = retail & 00000004 = test”
    0000217c : “allow play of unlicensed game”
    000021f4 : “magically makes you an elite hacker”

  2. Found some kind of kernel memory allocator: 002B8AE8
    Used in alot of places to allocate memory, hehe :-)

  3. Found functions strcpy and strchr.
    strncpy: 0028FFFC
    strnchr: 0029DDD4

    They are used in file system module.

  4. Great work, Unfortunately i havent got your message. Meet me on ps3dev tonight and I’ll give you my email address where you can find me.

  5. Is there a software only exploit on the way? I would love to try this stuff out but I don’t want to mess with my hardware. How hard would this be to do after knowledge of the HV and NAND is more studied?

  6. Figured out what hypervisor saves in HSPRG0, hehe :-)
    It is a key structure and is accessed in every hv call.
    I know now where it is in the dump, hehe :-)

  7. I am able now to decrypt and decompress CORE_OS_PACKAGE.pkg from PS3 PUP-Files. The decrypted and decompressed package is a copy of FLASH region where all the important SELFs and isolated SPUs stored, e.g. lv1.self or isoldr.

    So, now i could downgrade PS3 by writing this decrypted image to FLASH manually, without Update Manager from HV. In fact, Update Manager just do this :-) But the problem is, that the SHA-1 hash values for these files are stored not in flash but in SC EEPROM and i don’t have access to it yet :-)

    Here is a snippet from CORE_OS_PACKAGE.pkg 3.15:

    Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F

    00000000 00 00 00 01 00 00 00 17 00 00 00 00 00 6F FF E0 ………….oÿà
    00000010 00 00 00 00 00 00 04 60 00 00 00 00 00 04 00 00 …….`……..
    00000020 63 72 65 73 65 72 76 65 64 5F 30 00 00 00 00 00 creserved_0…..
    00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …………….
    00000040 00 00 00 00 00 04 04 60 00 00 00 00 00 00 00 08 …….`……..
    00000050 73 64 6B 5F 76 65 72 73 69 6F 6E 00 00 00 00 00 sdk_version…..
    00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …………….
    00000070 00 00 00 00 00 04 04 80 00 00 00 00 00 01 E5 CC …….€……åÌ
    00000080 6C 76 31 6C 64 72 00 00 00 00 00 00 00 00 00 00 lv1ldr……….
    00000090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …………….
    000000A0 00 00 00 00 00 05 EA 80 00 00 00 00 00 01 6D A0 ……ꀅ…m
    000000B0 6C 76 32 6C 64 72 00 00 00 00 00 00 00 00 00 00 lv2ldr……….
    000000C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …………….
    000000D0 00 00 00 00 00 07 58 80 00 00 00 00 00 01 2E 44 ……X€…….D
    000000E0 69 73 6F 6C 64 72 00 00 00 00 00 00 00 00 00 00 isoldr……….
    000000F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …………….
    00000100 00 00 00 00 00 08 87 00 00 00 00 00 00 01 DA E4 ……‡…….Úä
    00000110 61 70 70 6C 64 72 00 00 00 00 00 00 00 00 00 00 appldr……….
    00000120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …………….
    00000130 00 00 00 00 00 0A 61 E4 00 00 00 00 00 00 FA CC ……aä……úÌ
    00000140 73 70 75 5F 70 6B 67 5F 72 76 6B 5F 76 65 72 69 spu_pkg_rvk_veri
    00000150 66 69 65 72 2E 73 65 6C 66 00 00 00 00 00 00 00 fier.self…….
    00000160 00 00 00 00 00 0B 5C B0 00 00 00 00 00 00 5C 94 ……\°……\”
    00000170 73 70 75 5F 74 6F 6B 65 6E 5F 70 72 6F 63 65 73 spu_token_proces
    00000180 73 6F 72 2E 73 65 6C 66 00 00 00 00 00 00 00 00 sor.self……..
    00000190 00 00 00 00 00 0B B9 44 00 00 00 00 00 00 65 D0 ……¹D……eÐ
    000001A0 73 70 75 5F 75 74 6F 6B 65 6E 5F 70 72 6F 63 65 spu_utoken_proce
    000001B0 73 73 6F 72 2E 73 65 6C 66 00 00 00 00 00 00 00 ssor.self…….
    000001C0 00 00 00 00 00 0C 1F 14 00 00 00 00 00 01 53 2C …………..S,
    000001D0 73 63 5F 69 73 6F 2E 73 65 6C 66 00 00 00 00 00 sc_iso.self…..
    000001E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …………….
    000001F0 00 00 00 00 00 0D 72 40 00 00 00 00 00 00 44 98 ……r@……D˜
    00000200 61 69 6D 5F 73 70 75 5F 6D 6F 64 75 6C 65 2E 73 aim_spu_module.s
    00000210 65 6C 66 00 00 00 00 00 00 00 00 00 00 00 00 00 elf………….
    00000220 00 00 00 00 00 0D B6 D8 00 00 00 00 00 00 D7 F0 ……¶Ø……×ð
    00000230 73 70 70 5F 76 65 72 69 66 69 65 72 2E 73 65 6C spp_verifier.sel
    00000240 66 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f……………
    00000250 00 00 00 00 00 0E 8E C8 00 00 00 00 00 00 80 8C ……ŽÈ……€Œ
    00000260 6D 63 5F 69 73 6F 5F 73 70 75 5F 6D 6F 64 75 6C mc_iso_spu_modul
    00000270 65 2E 73 65 6C 66 00 00 00 00 00 00 00 00 00 00 e.self……….
    00000280 00 00 00 00 00 0F 0F 54 00 00 00 00 00 00 88 B8 …….T……ˆ¸
    00000290 6D 65 5F 69 73 6F 5F 73 70 75 5F 6D 6F 64 75 6C me_iso_spu_modul
    000002A0 65 2E 73 65 6C 66 00 00 00 00 00 00 00 00 00 00 e.self……….
    000002B0 00 00 00 00 00 0F 98 0C 00 00 00 00 00 00 C0 78 ……˜…….Àx
    000002C0 73 76 5F 69 73 6F 5F 73 70 75 5F 6D 6F 64 75 6C sv_iso_spu_modul
    000002D0 65 2E 73 65 6C 66 00 00 00 00 00 00 00 00 00 00 e.self……….
    000002E0 00 00 00 00 00 10 58 84 00 00 00 00 00 00 5D B0 ……X„……]°
    000002F0 73 62 5F 69 73 6F 5F 73 70 75 5F 6D 6F 64 75 6C sb_iso_spu_modul
    00000300 65 2E 73 65 6C 66 00 00 00 00 00 00 00 00 00 00 e.self……….
    00000310 00 00 00 00 00 10 B6 34 00 00 00 00 00 00 22 A0 ……¶4……”
    00000320 64 65 66 61 75 6C 74 2E 73 70 70 00 00 00 00 00 default.spp…..
    00000330 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …………….
    00000340 00 00 00 00 00 10 D9 00 00 00 00 00 00 12 B1 70 ……Ù…….±p
    00000350 6C 76 31 2E 73 65 6C 66 00 00 00 00 00 00 00 00 lv1.self……..
    00000360 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …………….
    00000370 00 00 00 00 00 23 8A 80 00 00 00 00 00 03 E8 28 …..#Š€……è(
    00000380 6C 76 30 00 00 00 00 00 00 00 00 00 00 00 00 00 lv0………….
    00000390 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …………….
    000003A0 00 00 00 00 00 27 72 A8 00 00 00 00 00 16 EE B8 …..’r¨……î¸
    000003B0 6C 76 32 5F 6B 65 72 6E 65 6C 2E 73 65 6C 66 00 lv2_kernel.self.
    000003C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …………….
    000003D0 00 00 00 00 00 3E 61 60 00 00 00 00 00 07 0F 94 …..>a`…….”
    000003E0 65 75 72 75 73 5F 66 77 2E 62 69 6E 00 00 00 00 eurus_fw.bin….
    000003F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …………….
    00000400 00 00 00 00 00 45 70 F4 00 00 00 00 00 07 FC 48 …..Epô……üH
    00000410 65 6D 65 72 5F 69 6E 69 74 2E 73 65 6C 66 00 00 emer_init.self..
    00000420 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …………….
    00000430 00 00 00 00 00 4D 6D 3C 00 00 00 00 00 06 16 00 …..Mm<……..
    00000440 68 64 64 5F 63 6F 70 79 2E 73 65 6C 66 00 00 00 hdd_copy.self…
    00000450 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …………….

    00263264 33 31 35 2E 30 30 30 0A 00 00 00 00 00 00 00 00 315.000………
    00263280 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …………….

  8. I have already decrypted Core OS Packages from 3.15, 3.41 and 3.50 PUP-Files. Also decrypted Revoke List for Packages and Programs which can be also found in PUP-Files. And also SYSCON firmware was decrypted by me.

    Sony uses zlib to compress Core OS Packages. But not all packages are compressed, e.g. SYSCON firmwares are not compressed, just crypted.
    Packages are first compressed and then decrypted. So first they have to be decrypted and then decompressed with zlib on Linux e.g.

  9. I have also decrypted profile file DEFAULT.SPP. There are stored e.g. System manager configuration and other things like ACLs.

  10. Today decrypted Core OS Package 2.80, BlueRay Drive Firmware, Bluetooth Firmware and System Controller Firmware.

    Bluetooth/WLAN is a Marvell chip.

  11. Some interesting strings from Bluetooth Firmware 3.41:

    Marvell Firmware SDK Version 2.3.0

    Eurus_Primary_Phy Marvell_AP

    DoSharedKeySeq1

    mlmeAuthDoSharedKeySeq3

  12. There is a new isolated SPU module in Firmware 3.50 which is not contained in older firmwares.

    manu_info_spu_module.self

  13. > There is a new isolated SPU module in Firmware 3.50 which is not contained in older firmwares.
    > manu_info_spu_module.self

    Thats interesting, I wonder what it could be.

    The name isn’t very helpful, it naturally expands to “manual information” which implies that its manually activated, and it gives information.

    Might be something that allows the psn to confirm that its running on unexploited firmware.

  14. Just decrypted 1.80 debug firmware.
    Contents of DEFAULT.SPP file are a little bit different.

  15. Xor, graf. Thank you both very much for all your efforts on PS3 exploits, including a not-for-profit 3.50 downgrader.

    There is a huge community eagerly anticipating your work.

    Thanks very much from all of us. And please keep up the excellent work!

  16. In DEFAULT.SPP are stored different configuratons which are e.g. read by system manager during boot, e.g. LPAR parameters for LINUX, GameOS, PS2 Emulation. This file is managed by SPL (Secure Profile Loader).

  17. You realy should start a blog, that’s some crazy stuff to just be posting on someone else’s blog. Document your findings.

    Too bad even with a CFW .pkg we still can’t write to dev_flash.

    If only we could repack the firmware, we’d be golden.

  18. You can decrypt all fws, you are a master, sir. Why don’t you share how did you do it for others to study?

  19. @graf_chokolo:
    Can you post the index.dat in the vsh/etc/ for fw3.50? So far, I don’t think it has been retrieved by anyone

    Thanks,
    Nebster

  20. With the exception of the three bytes at the end, those look identical to each other and are the same data as the old lv dumps Hotz showed in January.

    Please show us some other file that has some changes.

    We really want to believe this is real, but with all of the fakes in this game it’s “Trust, but Verify”

  21. Nice joob!!Keep good work!

    So actually how do u pack it back to pup?

    And look…and we install Debug Update to PS3 after some monipulations with pup?

  22. Please, show us something we have never seen before, more like this(pulled from a decoded ELF used while a 3.15 PS3 was booting.)

    http://pastie.org/1298788

    (Hmmm whats up with the CELL_FS_UFS on line 121…looks like it only uses FAT,EFAT or UFS…)

    JMK

  23. GooD Luck !!!! my friend i hope That you are the first person that can touch the memory flash to BlackPiggy

    Are With You!!!!!

  24. Why do you think he cares about any of you, or whether you think he’s fake or not? He never invited you here or asked for your opinions. He never advertised himself either, so what makes you think he cares about anything any of you have to say?

    Piss off, and leave him alone. Go beg somewhere else…

  25. Yeh, guys please don’t turn this into a “JB 3.50 FW” wishlist, there is some amazing information posted here that very few eyes would have seen, and Graf seems like he could be a huge benefit for us all in helping the scene progress!

    Doesn’t matter how long it takes, progress is progress!

    Keep up your outstanding work Graf, if you need donations or anything just say so, plenty people are so eager for what you’re doing nobody would have a problem helping. Seems like you’ve nearly found a solution to millions of peoples problem right now..

    Please keep working and let us know what you find next Graf, can’t believe what you’ve posted already! Groundbreaking stuff!

  26. just in case ppl don’t realise, all useful files are still encrypted and signed once unpacked/decrypted from inside these pkg files. this means that unpacking them does not magically make them usable or alterable.

    in other words this will not lead to a CFW or jailbreak.

  27. I somehow doubt the security on twitter for devs. So, when u got a solid ip shifter and so on come and share with us please!

  28. xorloser is right, the single files are not alterable. But the complete decrypted CORE_OS_PACKAGE.pkg can be used for downgrades. If i had access to HV i would already have downgraded :-) But i do not have it yet :-)

  29. Graf you realy should open your own blog! keep up the good work.
    @xor what’s your last post about???
    I think most of us understand that (disregarding the fw beggers that posted retarded sh*t). but this *could be/is* a step in the right direction for cfw among other things

  30. Wouldnt it be possible to mix most 3.50 ( or put any new firmware here ) binaries ( yes, yet encrypted+signed, but decrypted from the main PUP update file ) with the 3.41 binaries that have the psjb exploit ? Also, maybe its too much to think about real flashed firmware, but what about using a usb firmware loader already out ?

  31. there are other version specific files as well as version strings stored on the ps3. i am not so sure that just copying across the “core os” contents will work for you. sure it will install the old “exploitable” lv2_kernel.self. but possibly something else will be missing that will cause your ps3 to no longer boot.

    why not do what that new usb downgrader device does and just pretend to be a jig and do a full downgrade. there isn’t much to it, something similar can be done without too much trouble. or just wait till 1-2 days after it is released and another million clones appear. sure you actually need a key this time, but that isn’t so hard to get…

  32. yes, dependencies between modules and such could be a problem, but who knows…

    The thing is downgrading is definitelly useful for people with >3.41, but as a second stage usage, something towards psp-like devhook or more ambitious CFW would be desirable; Having the possibility to stay “updated” _and_ jailbroken…

    The “good” part ( but I dont have that much of the needed knowledge, just spitting out ideas O:) ) is that if the vulnerable lv2_kernel.self is used ( if doing it by actually flashing the new pup decrypted files; I would preffer going the “decrypted firmware in usb” path ), the payload in any jailbreak dongle could “assist” or ease the changes/fixes/patches needed by any further module to work propperly…

    Also, although I might be very very mistaken here, suppose we did that kind of mixed file firmware and booted the ps3 with a “dumpelf” payload… provided that the dumping would be done by the new firmware ( maybe the flaw in this idea is indeed here, maybe the code resposible that is deployed to an isolated spu for self decryption os so is in lv2_kernel.self but doesnt make sense since lv2_kernel.self itself has to be decrypted first… but may be there are different levels/categories of encrypted selfs… ), maybe we could decrypt the remainning selfs and develop the needed changes to glue everything back “to normal”

    Arf, sorry, mind goes fast ( too fast… ;( )

  33. sure downgrading is nice. but upgrading with an exploit is nicer. first step could be a hybrid firmware…after that a cfw…only reason why we don’t have this yet is because of (scene) people making money of jb devices 😉 I think a 3.50 copy over with a 3.41 lv2 to the NAND will probably work. It’s the signing that keeps us from that. I wish I could help with that but my skills do go so deep. So I’ll just be following you tech guys

  34. I completely reversed the Update Manager that runs in Process 6 in HV.
    And it decrypts CORE_OS_PACKAGE.pkg, calculates hash values of lv0 and lv1.self, sends these hash values to SC Manager (runs also in a HV Process), that stores it either in EEPROM or somewhere else. After that the decrypted CORE_OS_PACKAGE.pkg is stored on the flash. So, by decrypting of CORE_OS_PACKAGE.pkg i just did a part of what UM does.
    And i have write access to FLASH but NO access to SC Manager.

    During booting, System Manager (runs in HV Process 9) tells Update Manager to do integrity check. Among other things, Update Manager reads lv0 and lv1.self hash values from SC Manager, calculates hash values of these files from FLASH and compares them. If they do not match, then it reboots or power off.

    So that is why i said in my earlier post, that before i will do downgrading, i need SC Manager access.

    GameOS has a VUART communication link to HV Processes which provide different services to GameOS. Updater from GameOS e.g. communicates with Update Manager from HV through this link. And SC Manager can also be accessed through VUART link (Dispatcher Manager)
    but unfortunately it has ACLs and denies all accesses to SC Manager from GameOS :-(. If i had access to SC Manager, i could do so many cool things :-) E.g. decrypt USB Dongle Master Key that is stored decrypted in HV Process 6 (the same process where Update Manager runs).

    USB Dongle Master Key is decrypted by SC Manager :-)
    I guess Jailbreak people have decrypted USB Dongle Master Key. If you have this key, then you can bring your PS3 intp product mode. In this mode e.g. integrity checks done by Update Manager are skipped :-)
    BTW, USB Dongle Authenticator runs also in HV Process 6 and GameOS has free access to it, but you need the master key :-)

    BTW, System Controller (SC or SYSCON) is accessed in HV through VUARTs from LPAR1. And the VUARTS send data to ioif, address somewhere 0x2400009000, don’t know exactly, have to look up it HV.
    So if someone manages to map this address into LPAR’s memory, the he got access to SC.

    I have now a very rock solid knowledge of HV and it’s Processes but unfortunately no HV access yet :-)

    So, here is some piece of my knowledge i gathered by reversing HV :-)

    I’am able to run isolated SPUs from GameOS but i didn’t use any GameOS functions. I used ONLY HV calls. I’m more intersed in HV r eversing :-)

    I will soo make public how to decrypt CORE_OS_PACKAGE.pkg.

  35. Hi chokolo, i think some devs at psx-scene will help you on your project if u will public ur Files u found out Till now.
    May Be together with Other devs u can get Some more Shot to work =)

Leave a Reply

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