PS4 News on Facebook! PS4 News on Twitter! PS4 News on YouTube! PS4 News RSS Feed!

Home PS4 News - Latest PlayStation 4 and PS3 News

September 1, 2010 // 9:30 am - Earlier today we reported on the open-source PS JailBreak PS3 exploit from Mathieulh's PlayStation 3 hacking team dubbed PSGroove, and as promised the reverse-engineering details are now available linked above and posted below, as follows:

Analysis of the PSJailbreak Exploit


The PSJailbreak dongle is a modchip for the PlayStation 3 that allows users to backup and play games off the harddrive. Unlike the modchips of the Previous generation, or the modchips so far for the Xbox360 and Wii, this modchip simply plugs into the USB port on the front of the PS3, avoiding the need for complex soldering and voiding of your warranty.

As the time of writing this document, the final PSJailbreak has not been released, but a number of samples were given out and at least one fell into the hands of someone who owned a USB sniffer.

This analysis of the exploit is based on those USB sniffer logs, issues encountered during the development of the opensource PSGroove version of the exploit and a number of educated guesses. It will probably be updated as new information comes in.

The initial analysis by suggested that it was a Stack overflow attack. After further analist it turns out that this exploit is a Heap Overflow attack. The exploit carefully manipulates the heap by plugging and unplugging fake usb devices with large device descriptors until the device on port 4 which misreports its size to overwrite one of malloc's boundary tags.

The state of the PS3

The exploit takes place while the PS3 is looking for the Jig (triggered by pressing eject within 200ms of pressing power). It is suspected that the ps3 spends around 5 seconds doing nothing but initializing devices on the USB bus, so there is little extra code running to mess the exploit up.

Setting up the heap

The PSJailbreak dongle emulates a 6 port USB hub. By attaching and detaching fake devices to the ports of the hub the dongle has control over the mallocing and freeing of various blocks of memory that hold the device and configuration descriptors.

Port one

After the hub has been initialized, a device is plugged into port one with a pid/vid of 0xAAAA/0x5555, It has 4 configurations with each one is 0xf00 bytes long. This is just under the size of 4k page, so malloc will have probably have request a new page for each one, unless it already has enough free space, but at least one will be aligned at the start of a page.

The ps3 also changes the configuration the 2nd time it is read so the configuration in the ps3 memory is only 18 bytes long.

It just so happens that that this data contains the payload that the exploit will jump to after gaining control of the execution, but that is not important for the exploit.

Port two

After the PS3 has finished reading the port one device descriptors, the dongle switches back to the address of the hub and reports that a device has been plugged into port two.

This device has a pid/vid of 0xAAAA/0xBBBB, and it has 1 configuration descriptor which is 22 bytes long. Only the first 18 bytes are real usb data and the remaining 4 bytes are:

04 21 B4 2F

With a length of 04 and an invalid type byte, anything interpreting it as USB descriptor will probably skip over it and the last 2 bytes. It is suspected that this is just here to make this descriptor take up an exact amount of heap space.

Port Three

The port three device has a pid/vid of 0xAAAA/0x5555, the same as port one. Unlike the port one device it has 2 configuration descirptors, each 0xa4d bytes long The data that fills them is junk but it may or may not be relevant that if you treat the data as descriptors they will have valid lengths. These descriptors will probably be allocated to the start of a fresh 4kb page that follows the page with the last port one descriptor and port three descriptors.

Port Two Disconnect

After port three is connected, port two will be disconnected, this will cause the port two descriptors to be freed, which frees up some space between the Port One and Port Three descriptors.

The exploit

The heap is now prepared for our exploit.

Port Four Connection

A device is connected to port 4, with a pid/vid of 0xAAAA/0x5555 and 3 configurations.

Configuration A

This is a normal configuration, 18 bytes long

Configuration B

This configuration is the same as Configuration A, except it changes its total length from 18 bytes to to zero bytes after the PS3 has read it the first time and allocated space for it.

This is where things get vague, this is key to the exploit and will somehow cause the the extra data at the end of Configuration C to overwrite one of malloc's boundary tag, most likely the one belonging to Port Three.

But the exact reason for this buffer overrun is hard to guess without actually seeing the exploited code.

Configuration C

This starts the same as configuration A, but has 14 bytes of extra data at the end.

.. .. 3e 21 00 00 00 00
fa ce b0 03 aa bb cc dd
80 00 00 00 00 46 50 00
80 00 00 00 00 3d ee 70

The first 6 are just padding (but the 3e might be important if this ever gets interpreted as a USB descriptor.) Then there are 3 u64 values, each 8 bytes long.

The first two values are stored for use by the shell code later just before malloc's boundary tag.

The 3rd value overwrites the first value of the boundary tag, which is pointer to the next free section of memory. The replacement pointer will point to a function somewhere. This will cause a malloc to allocate memory in the wrong place, sometime in the future, allowing the exploit to overwrite an existing function.

Port Five

The dongle plugs the fake Jig into Port Five right after Port Four has done its job. It uses the same PID/VID that the original Sony Jig uses (0x054C/0x02EB) and probably the same configuration with the same end points.

It is suspected that because the Jig is a known device that the PS3 was waiting for, it's device and configuration descriptors will not be malloced into the heap.

The PS3 sends a 64 byte challenge to the fake Jig to authenticate it, and the dongle replies with 64 bytes of static data. The PS3 will malloc space for this response, and because the boundary tags have been modified by Port Four, malloc will return a pointer to 24 bytes before a function that has something to do with free and the 64 bytes of data will be written over top of the function.

At the point, no code has been patched yet, so the Jig's static response will fail to authenticate the jig.

Unplug Port Three

The dongle now sends a message that port 3 has been unplugged. This will cause the PS3 to free the Port Three's configuration data, the very same buffer which had its boundary tag overwritten by Port Four.

So our shellcode gets called, with R3 pointing to the boundary tag before Port Three's Configuration data.

The Shellcode

PPC Assembly:

ROM:00000018 ld %r4, -0x10(%r3)
ROM:0000001C ld %r3, -8(%r3)
ROM:00000020 loc_20: # CODE XREF: sub_18+14j
ROM:00000020 ld %r5, 0x18(%r3)
ROM:00000024 addi %r3, %r3, 0x1000
ROM:00000028 cmpw %r4, %r5
ROM:0000002C bne loc_20
ROM:00000030 addi %r6, %r3, -0xFE0
ROM:00000034 mtctr %r6
ROM:00000038 bctr

This takes a pointer to the corrupted boundary tags in r3.

r4 is loaded with the 0xFACEB003AABBCCDD tag, then r3 is loaded with 0x8000000000465000, both of these values are stored just before the boundary tag.

The shell code then scans every 4KB block (0x1000 bytes) starting at 0x8000000000465000, checking for 0xFACEB003AABBCCDD tag in the u64 at 0x18 in each page.

When it finds it, the shellcode will jump to offset 0x20 in the payload.

After the exploit


The exploit is now completed: Port Five, Port Four then Port One will be unplugged.

Hopefully the Payload will have copied itself out of the heap before Port One is unplugged.

Port Six

The device that gets plugged into Port Six has nothing to do with the exploit. It has a vid/pid of 0xAAAA/0xDEC0 (on the PPC, which is big endian, the pid is 0xC0DE).

The payload sends it a single byte (0xAA) control transfer so that the dongle will know that the exploit was successful so it can turn the green LED on to signal the user.

A function in the original PSJailbreak Payload will make sure that this device stays plugged in. If it is ever unplugged then it will call LV1_Panic and your PS3 will shutdown. PSGroove has removed this 'feature'.

The Payload

The actual payload is outside the scope of this document (There might be a 2nd document discussing the original PSJailbreak payload), but we will discuss the environment.

The payload will start in an unknown position, aligned to a 4KB boundary, it should either use position independent code, or copy itself to a known location. The payload has full control over the lv2 (aka gameos) kernel and anything below it. It doesn't have any control over lv1 (aka the hypervisor) without a 2nd exploit (the original Geohot exploit should still work.)

The Jig authentication code is most likely running in lv1 or an isolated SPU so it is not possible to patch it with this exploit.

The lv2 kernel is loaded at the time of the exploit, perfect for patching or you could replace it with something better like a linux kernel. A linux kernel running in this environment would have all the privilege of the regular gameos kernel.


What firmware versions will this work with?

The exploit should work on any firmware version, but the current payload only works on 3.41.

As i read it is not needed to have the dongle plugged in the whole time? My Question is what happens after rebooting the ps3? will homebrews still be installed and bootable?

They will be still installed, but unless you boot with the exploit you can't run them. This might change at a later date, think back to the original xbox softmods.

How hard would it be for Sony to patch this exploit in the next firmware release? If trivial, does that mean that basically this exploit will be useless in a few weeks unless we never update ever again?

Semi-trivial. but yes, in a few weeks don't upgrade your console.

Can this exploit and having full access to lvl 2 faciliate research of other vulnerabilities in the system, or does this not give us more than what dev consoles already have?

I think dev consoles only give access to lvl 2 applications. Besides only a few people have dev consoles, so just having it in reach of more people increases the odds of finding exploits.

Export to other devices like BlackBerry

I think this can be exported to other devices with USB port access, in example, Blackberry phones. Imagine a Blackberry application conected to de PS3 via usb cable runing a java app that do the magic work. Can you help me with tech specs about a similar port? i dont know the abstraction level of the USB BlackBerry Libs, cold be sufficient a serial read/write to the port? thanks!

PS JailBreak PS3 Exploit Reverse Engineering is Detailed!

Follow us on Twitter, Facebook and drop by the PS3 Hacks and PS3 CFW forums for the latest PlayStation 3 scene and PS4 Hacks & JailBreak updates with PlayStation 4 homebrew PS4 Downloads.

#20 - daveribz - September 1, 2010 // 9:23 pm
daveribz's Avatar
I don't get why a different ID is used than the original game ID since it's using the BD Emulator built in the PS3 OS to play the games. So basically, it's suppose to show the ID of the game you're playing since it's a total emulation of the disk, which doesn't even use some 'homebrew' code. I think they might have been some misunderstanding of the Title ID stuff: i'm sure the only time the fake ID is used is when you're in the Backup Manager. After, the game is mounted using official debug functions and launched like a real game.

#19 - kingpin007 - September 1, 2010 // 9:06 pm
kingpin007's Avatar
Ok so basically I wont have to pay $100 or so dollars to get my ps3 running homebrew and backing up my store bought ps3 originals?

Piracy kills game developers which is not a good thing but my purpose only would be for protecting my originals as my kids even though I tell them to be careful .. well crap happens & I want to protect my originals.

I guess the market will be flooded soon with ps3 usb mod sticks and the price will come down so I should hold off on purchasing the usb modkey?

#18 - jevolution - September 1, 2010 // 4:42 pm
jevolution's Avatar
Quote Originally Posted by tripellex View Post
Doesn't matter really, so long as you don't update. The genie is out of the bottle, and with full access to LV2 (and LV1 with Geo's exploit), there literally is no limit to what we can do with the system over time, including finding other exploits, or even possibly shutting out $ony altogether.

rofl... would be awesome to replace gameos with a full linux os able to launch games directly... epic $ony pwnage.

in the meantime... slipping in a bootloader before gameos allowing a linux fork would allow us to regain otheros and it'd be better than ever, with all gameos privileges... exciting stuff.

#17 - daveribz - September 1, 2010 // 4:21 pm
daveribz's Avatar
Wow.. Amazing stuff can be done with this exploit. If I understand correctly, we have FULL control over GameOS and could patch the bootcode to anything we want.

#16 - CodeKiller - September 1, 2010 // 2:15 pm
CodeKiller's Avatar
if anyone interested, i made a little commenting on the descriptors (original comments retagged to //** )

descriptor.h from the github:

[Register or Login to view code]

in this regards, it theoretically can be used with v-usb (software usb for atmega) as it only bind to 8 bytes-packets: slow-speed usb

bad text-align... sorry, forgot to preview.

#15 - tragedy - September 1, 2010 // 12:50 pm
tragedy's Avatar
Awesome article! As I've only looked at the ppc exploit code as originally posted, I was wondering what the patched function that compared against AAAAC0DE was for...

#14 - mossopinc - September 1, 2010 // 12:20 pm
mossopinc's Avatar
Quote Originally Posted by Jes03 View Post
Isn't this just telling $ony how its done so now they know exactly how to patch it?

Don't ya think sony could work it out themselfs? they know the PS3 and it's workings fully..

#13 - laggmaster - September 1, 2010 // 12:19 pm
laggmaster's Avatar
Great news... looks like i will be able to turn my old 60gb into a full linux pc (the otheros function was always crippled because of no rsx support)... as soon as my supplies arrive looks like i'm going to have to start reverse engineering the ps3s driveboard firmware to try and get myself my ps2Bc back

this has literally opened the PS3 world to homebrew something that has been alluding us for 4 years now is now open source not long after its release... now to watch the scene boom then degrade then boom again then probably die just like the psp scene has seemed to do...

#12 - Sshadow2305 - September 1, 2010 // 10:55 am
Sshadow2305's Avatar
So the australian reseller can not win vs Sony? Because psjailbreak team used the jig id ?

#11 - tripellex - September 1, 2010 // 10:54 am
tripellex's Avatar
Quote Originally Posted by teusjuh View Post
does that mean there is an big hope for custom firmware??

The possibility of CFW is going to be dependent on us actually decrypting existing firmware, modifying the decrypted content, repacking and getting the PS3 to accept the modified, unsigned CFW and install it. So as of now, not so much a big hope as a glimmer. Until we can get ahold of the PS3's encryption keychain that is, which this exploit, or another exploit that may come from using this exploit, may give us. Confused? I know I am