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. the hmac key for PUPs doesnt magically allow custom firmware. this is because all of the files that make up the PUP are signed anyway, so you cannot make custom versions of any of those files because you cannot sign them.

    as for x3max supposedly working on v3.50, i call fake.

  2. Pingback: x3MAX - What is the latest? 72 hours up in 3 hours time! - Page 16 - PSX PS2 PS3 Scene Modchip & Jailbreak Community

  3. xorloser is right guys regarding 3.50 JB :-) Either it’s fake or they have stolen some stuff from $ONY :-) Or no, not again. It’s no fun to “reverse” things by stealing them from $ONY :-) Too easy if you ask me and where is the fun ???

  4. It may not allow custom firmware, but if 3.55 really does simply revoke the LV2Diag.self it would be possible to swap out the RL_FOR_PROGRAM.pkg for an older one, therefore allowing the revoked LV2Diag to load :)

    (that might all be pointless though…)

  5. Pingback: X3Max 3.50 Hack Fake? - PSX PS2 PS3 Scene Modchip & Jailbreak Community

  6. @anos If you read my twitter you would know that someone used a reply from a totally unrelated question, pasted next to that pointless question and posted it on LS (probably to boost the crappy x3 sales)

    I believe it’s probably some video x3max did with a debug on 3.50 to boost their dongle sales. Unless it’s proven otherwise I do not think it is real.

    @DOWNGRADEFTW They just replaced the dev_flash3 tarball, they didn’t even bother to rehash the PUP. There is no key to find from comparing PUP files…


    That should be a more complete diagram of the boot chain, some parts like the update manager and such are missing from it though.

  7. Pingback: X3Max 3.50 Hack Fake? « MaxConsole

  8. Pingback: X3Max 3.50 Hack Fake? - PS3ISO

  9. but xorloser, we don’t even need to change any file in 3.50 to be signed again, just mounting it using one of the usb firmware loaders out there would do the job to be in 3.50 over a jailbroken 3.41… am i too wrong?

  10. “How exactly did sony block the jailbreak in 3.50? does anybody know?”

    they fixed the buffer overflow.

    “We are able to get into service mode on 3.55, but cannot downgrade due to a change on lvl2diag.self (From what I’ve heard)”

    They have revoked the version of lv2diag that is public, they’ll probably push out a new one to the service centres.

  11. “but xorloser, we don’t even need to change any file in 3.50 to be signed again, just mounting it using one of the usb firmware loaders out there would do the job to be in 3.50 over a jailbroken 3.41… am i too wrong?”

    the usb firmware loaders don’t do what the name suggests.
    all they do is allow you to mess around with xmb etc.
    you can’t load lv1 from usb for example.

  12. @xorloser: i was imaging that hmac was only for pup signing (and not for files), but it’s always a first step, and it allow us to create an hybrid firmware (with already signed files) with a correct header hash, and we don’t need service mode to skip hash check, we can just install it from XMB (for example, we can’t upgrade in service mode a 3.50 with an hybrid 3.55 with some different (already signed) files, in service mode we will get “10 beep error” or “red screen: contact sony blablablabla”, there are some reports that confirmes that we can’t upgrade correctly in service mode). It can be a temporary fix for 3.55 downgrade, and the beginning of a CFW :)

  13. @Mathieulh

    thanks for the diagram. if I understand the thread correctly, we are currently able to decrypt lv2_kernel.self. which lower levels we can decrypt (if any)? what prevents us from decrypting all the rest?

  14. Guys and about the BD playback problem? Any news? Some fix?
    This is off topic, but some people need this stuff.

    @graf_chokolo: congrats for your excellent work.

  15. @smf:

    just forget about current [usb] firmware loaders; I have said this before:

    be it via a payload or via a lv2 routine uploaded via libkammy or so, we can do something like what asbestos does > load all lv2 and other files etc from usb ( or folder in hdd )  + redirect further lv1_storage_read or at least file io; doing the loading in a controlled fashion; something like “3.41 lv1 and from there a controlled/patched 3.50 lv2”.

    This, again, is like another asbestos, but using the necesary “glue” to make 3.50 lv2 components work propperly over a 3.41 lv1 ( hooks, hooks and more hooks ).

    The big requirement is, as always, a decrypted new firmware; which we do have for 3.50 but then there is another problem:

    or we hook lv1 operations to decrypt+load modules and have every module of our 3.50 fw decrypted+reconstructed ( following our own standars )
    – or –
    we have some better way of just chainloading all/some XYZLDRs in lv2 and making any changes -in them and hooks in places in lv2 where lv1 hvsc for module loading are made- ( with new fw crypto keys and all that ) so that they can decrypt+load any original/unencrypted 3.50 modules from lv2, simulating module loading as a virgin/not-jailbroken system does.

    in any case, the thing is obtaining keys from those XYZLDRs… thats the needed part, the other things I wrote are difficult and probably a veeery big task, but having those intermediate keys…

  16. @abrek I have a hunch that you are from Sony. @KaKaRoTo offering a ‘BOUNTY’ ! Is he after @graf_chokolo’s true identity? Am I being paranoid?

  17. @KaKaRoTo

    Thanks :-) I got your message. But i think we should divide the bounty. When i get the money you and all others who made it possible will get a share from it because not only me was involved, you reversed the key, zAxis and Hansi and all others. It was community work. I will contact you as soon as i have it :-)

  18. KaKaRoTo, by ignoring you graf states that he is a real one who does not need any bounty. he won’t take money, he does it only cause of fun

  19. @abrek The problem is the keys are embedded in different loaders which happen to be isolated, this makes them somewhat harder to exploit and dump unlike the usual ps3 ppu code. The loaders have their own protocols, from time to time, sony releases updates with loaders sporting updated protocols and new keys, you can’t “talk” to the loaders without knowing their protocols, and you can’t know their protocols without having a peek at the ppu binaries that “talk” to them, so it’s really a vicious circle in here. Unless someone magically shows up with metldr’s key we’ll keep playing cat and mouse when it comes to ps3 binary decryption, that’s even if someone would exploit specific loaders revisions to get their keys (as long as we can’t decrypt those loaders, sony can perform security audits on these and update them with new keys and without the vulnerabilities you may have found in the past.

    Of course although the isolation is a strength it’s also one of the reason the ps3 security fails, sony relies on the isolation for most if not all of the playstation 3 security, but isolation really provide obfuscation which in the end is no true security, as soon as the ppu code becomes “available” then that kind of security goes down totally because nothing prevents third parties from looking for exploits which are likely to be in whatever revision of the ppu code they have yet to dump.

    True security becomes achieved when there are no exploitable bugs to be found even as though the actual code is available to reverse engineers. On that particular note, the xbox360 security architecture seems rather more effective than the playstation 3’s counterpart.

    As to what we can decrypt, you can use the loaders (as soon as you know their protocols) to decrypt ppu binaries, so far we can decrypt (up to some firmware revision) anything decrypted by appldr or lv2ldr, this means kernels or application selfs. You wont ever be able to use lv1ldr because of the ATA init issue though but that’s another story.

  20. Hello i have a question,
    I bought a ps3 without drive but now if i wanna downgrade from 3.50
    its keep blinking green and in the log stands update package elapsed time = 211922 msec
    Updating or Verifying failure 0x8002f057
    UpMng.UpdatePackage() failure
    manufacturing updating FAILURE(0x8002f057)
    Total Elapsed time = 213052 msec

    can any body help me with it

  21. why cant i downgrade without bluray drive my ps3 keeps blinking and in the log stand a error thans

  22. @ all
    jig master key

    0×32, 0×78, 0×57, 0x2D, 0×90, 0X90, 0xD5, 0xAC, 0xAE, 0xF9,
    0×03, 0xCA, 0x1A, 0xB6, 0x5E, 0xF1, 0xB7, 0×69, 0x4C, 0xDE,

    is working on 2.10, i had try this in hope to find a solution of my broken BD-Playback. Maybe it can help or not? i will see :-)

  23. Sorry was a mistake. didn’t save the key.h :-(. But JIG is not function in 1.50 (with right key, not the key i posted).

  24. I was bored so I decided to made this graf_chokolo’s “Lord Prayer” version:

    English Version:
    Our Graf who art in Xorl’s,
    hallowed by thy payload
    Thy selfs come
    Thy custom firmware be done
    on 3.41 as it is on 3.15
    Give us this day our daily hack,
    and forgive us our updates,
    as we forgive those who blocked PSN
    and lead us not into 3.55,
    but deliver us from Sony.

    Spanish Version (Original):
    Graf nuestro que estás en Xorloser’s
    Santificado sea tu payload
    Venga a nosotros tus selfs
    Hagase tu custom firmware
    Tanto en 3.41 como en 3.15
    Danos hoy nuestro hack de cada día
    perdona nuestras updates
    como nosotros tambien perdonamos las de Sony
    No nos dejes caer en 3.55 y líbranos de Sony.

    I hope you like it Graf :)

  25. @graf_chokolo
    Ok cool, I was wondering if you decided to ignore me (because you don’t want the money) or if you just missed the messages.
    If you want to share it, I don’t mind. That was my original plan, share it among you, zaxis and hansi, but since zaxis said if he gets it, he’ll give it all to you, I decided to do the same.

  26. Hm, guys, i took a closer look at PS2 Soft EMU yesterday and it uses lots of LPM (Logical Performance Monitor) HV calls :-) What for i wonder ? For debugging ? :-)

  27. Holy shit :-) PS2 soft emu kernel doesn’t use only HV calls, but it uses also syscalls in kernel itself :-)

  28. @Mathieu @Graf
    I don’t quite get a thing:
    1.PS3 updates are not incremental (we can jump from 2.x or 3.15 to 3.50 or 3.55 directly) that means in the 3.15 we have all the tools to decrypt the 3.50 package (pup). The files inside are also encrypted, i know.
    2. There is no CPU that can run encrypted instructions, the executables must be decrypted at runtime.
    3. Not every part of the PS3 can be updated (the 32K bootrom eprom in the cell, I’m not asking Math how he knows it :) )
    4. So between 3.41 and 3.50, 3.55 $ony changed something in the decryption chain:
    except the bootrom which is otp.
    The new decryption key is in that pup, or the cell won’t be able to decrypt at runtime. There is a new key because otherwise we could decrypt selfs on 3.15.

    Can’t we just analyse the decrypted PUP to see the new decryption key, and then everything is plain asm?

    How? the “first stage” is encrypted the same way as 3.15 or the boot rom which is not updatable won’t be able to run it.
    once the “first stage” is decrypted we see how it loads the “second stage” (the new key?), port that algorithm to a 3.15 runnable self and use it to manually decrypt the “second stage” and so on.

    Unfortunately I’m not that good at asm to be able to do this myself…

  29. @executivul

    1. while updating the ps3 simply overwrites the loaders with the new ones prior reboot, there is no mystery to it, of course update packages and updaters themselves have to keep using the same keys because otherwise it would be impossible to update from let’s say 1.00 to the latest version.

    2. The cell has been designed with security in mind, it sports an embedded bootrom code which will used a dedicaced crypto engine with the per console hardware root key to decrypt the bootloader (and metldr) once the isolation kicks in. The bootloader will then start the rest of the bootchain. Of course that bootrom isn’t encrypted but it likely runs isolated as well, and dumping it doesn’t seem an option short of decapping the cell processor.

    3. The bootrom is OTP, it can only be written once at factory and contains fancy stuffs such as vendor code, keys and so on. The bootrom itself uses the cell fuseset (that can also only be written to once) which contains a unique per console 128bits key to decrypt “trusted” isolated binaries (the only ones the cell cpu really considers as “trusted”) Not even the loaders in self format decrypted and loaded by metldr are actually considered trusted when it comes to the cell architecture. I assume (but that is purely assumptions at this point) that “trusted” isolated process have access to more resources (such as perhaps the cell crypto engine) than regular isolated loaders. The OTP bootrom isn’t the only part that cannot be updated, because metldr and the bootloader are encrypted with a supposedly undumpable per cpu hardware root key, considering it’s pretty much impossible to access that key through software means alone (it would be a security liability if it happened to be possible in the first place), it is impossible for updaters to re-encrypt either metldr or the bootloader for your console, this means they cannot be updated even if lv2 has access to the metldr area on the nand and can read/write it. This is very important because the day the bootloader and metldr keys get revealed, sony cannot possibly change them and prevent us from decrypting newer loaders of lv0 (depending on which key gets leaked)

    4. The bootchain itself didn’t change, the same binaries get executed in the same order, of course those binaries have changes just like in pretty much every single firmware updates. The bootchain diagram pretty much remained the same from pre 1.00 firmwares to 3.55, Sony have no reasons to change it at this point.

    PUPs aren’t encrypted, they are just a hashed container that holds encrypted update packages and tarballs. The update packages can be decrypted but they contain encrypted binaries themselves which you cannot decrypt because you do not hold the key to do so (or you can’t use the newer loaders)

    The problem is newer binaries are encrypted in new keys contained in updated loaders using a new protocol (which you do not have) Those loaders sure can be decrypted and loaded by metldr but since they are isolated, you can’t access/dump them without exploiting those isolated processes themselves. Even if you owned the cpu you still couldn’t access the isolated LS because the spu happens to be physically isolated. Since you can’t use the new loaders and you can’t get the keys to the binaries you want to decrypt, you are kind of stuck short of finding new exploits.

  30. @pschycoboy
    I had the exact same problem I think, at least the same error :)

    1. What I’ve done is cut off the power of the PS3 put in the USB key with the file 2 Lvl2diag.self then turn PS3 on normally

    2. When PS3 is turn off again, cut off the power again. Then Jailbreak with special PSGrade. When youre PSGrade is function properly youre ps3 will be factory mode. And will turn off after the process.

    3. Put in USB stick with file 1 Lvl2diag.self and the MODIFIED 3.41PUP file

    4. Put on normal way just press the on/off button. Then the PS3 should be downgrading would take 5 minutes or so!! Keep waiting!

    5. When PS3 is turned off again just load without any USB stuff

    6. You should be having a screen with factory mode still on and PS3 on 3.41

    7. Turn off normally and put USB with only File 2 Lvl2diag.self

    8. Turn PS3 on normally again and it should be ok

    At least for me it was 😉

  31. @ PSCHYCOBOY – This isn’t really the place (but I hate seeing someone stuck).

    You need ANY logic / controller board (from a suitable Blu Ray drive) to complete the circuit as far as I know.

    I tried mine without the logic board and got the same error. After plugging in the correct logic board, the green light blinks faster, then turns solid red (standby mode) shortly after. That is what it’s meant to do!

    It’s rumoured that you can pair a new logic / controller board to your PS3 using service mode, but I haven’t tried just yet (haven’t got time). If it’s not paired, PS3 will boot, but will black screen on loading games/homebrew.

    If you have ANY possible way of getting your original BR drive back, try! I had to dig through someone’s bin for one and then solder the ribbon cable to it!

    Until someone figures out how to pair motherboards to different logic boards, you have a problem (games and homebrew won’t load) but you should be able to finish the downgrade with any board attached, you don’t even need a drive, but just a logic board, then data and power cables are essential.

    Order one from Ebay, but make sure it’s the correct one for your model!

    @ GRAF, your last few posts have me on a semi.. 😛

  32. I’ve seen lots of people talking about “modified” PUP file, but what is the MD5 hash of this file? I thought I had the modified PUP, but it turned out to be the original 3.41…

  33. @graf_chokolo

    so sony did you a big favor and opened the ps3 through ps2 emu for you?
    sounds that you descovered something not far away from an exploit 😉 ?

  34. Ive tested different firmwares on my ps3 to see what can be installed and what cant. Ive used the downgrade method to install retail 3.41, 3.15, 1.10, and debug 3.41, 1.80, and 3.40 they all work with out any problems. the debug options sort of work but the install packages doesnt install jailbreak packages only debug pkgs (probably needs to use signed code). i can safely say we can install any firmware without worry through this method wether its debug or retail. the only thing weird is when you’re on the debug firmware you cant use the system update on the xbm to update to another debug firmware. (it will copy the files to the hard drive and boot to a frozen update page (only could be solved with a hard drive format)

    I hope this information will be somewhat helpful to anyone.

    80 gb ps3 (backwards compatable)
    currently (debug firmware 3.41)

  35. Thank you mathieulh for that post, that was an awesome summary that really helps me understand how things work better now :)

  36. Guys, i’m able now to decrypt all SELF upto 3.41 firmware using appldr directly without HVCALL 99 :-) Just decrypted vsh.sekf from 3.15 firmware with this method. I will make everything public very soon :-) And then you will see the low level interface to appldr. It’s partially hidden by lv1_undocumented_function_99 :-)

  37. @Graf
    I promised you that I will give you the bounty if I get it, so you can keep my share :-)
    Also, you are decrypting lv2kernel.self through assembly, doesn’t that mean you can bypass all security constraints? and do you have access to real memory addresses in assembly or do you still have to go through paging?

    if I understand correctly, pup files are hmac singed (should be real easy to re-compute), but each file in it is digitally signed (should be impossible to recompute)?
    that means we could reconstruct pup files from existing parts and it will be accepted without any hacks (except getting the hmac key)?

    it seems the root key is dump-able through hardware, with infectus. a few days ago, ozmodchips were offering a service were they extract your ps3 key from the nand dump and use it to re-encrypt a nand of an older firmware for your ps3. this key might not be the one used by bootrom, but there is a good change that it is used by the bootrom to complete the bootchain. remember there is an egg-and-chicken problem when it comes to decrypting,some key must be stored in plain text, which decrypts some other keys and stuff. or if some hardware is used only to decrypt the bootrom then we should be able to read its output through hardware too.

  38. Did X3max really get the master key? if so, how did they manage to retrieve it out of the CPU? I thought it was Hard Coded?

  39. @krunchy
    I have 2 x 3.41 pups:
    Sony released PUP MD5: 00c835be718fc3d5f793e130a2b74217

    Modified PUP MD5: 6f1ef9144c43c9a6f00f7ee7464a6689

    Hope that helps.

  40. @zAxis
    yeah some keys need to be in plaintext, and you know that is applied to every security scheme…. and ps3 is not different, it follows the same suit. ah and the plain text key is in the bootrom inside the cell die, and to extract it we need very good decapping service for decapping a cell and red the bootrom… AFAIK. this is what it seems. anyway if mistaken forgive me as i m not holding that much of knowledge as you ppl do… 😛

  41. @bogmass
    Thanks for clarification. I have 4 different versions of 3.41 which I determined are:

    00C835BE718FC3D5F793E130A2B74217 – (original 3.41)
    E07D2B84C9E9691C261B73E5F1AADA20 – (2nd 3.41 – the good one for JB)
    561B924D2B388FB920F3F7AB12C679CA – (kiosk 3.41)
    6F1EF9144C43C9A6F00F7EE7464A6689 – (modified 3.41)

    The only other one I’m aware of is the debug 3.41 which is 2ED02E302DBBBCBB35CAC6A661EEA561.

    It’s like Pokemon over here…

Leave a Reply

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