PS4 officially Jail Broken!

It seems interesting that Sony would keep certain console-specific keys in a physically accessible device, whose contents can be readily dumped and overwritten.
While true, the keys are not compromised because they are not decrypted and accessible - they're somewhere in that encrypted NAND dump. But this does indicate that Sony aren't using unique hardware serial numbers (which does surprise me), or at least their current encryption system is not making use of it.
 
I´m portuguese, and read the original messagem on the brasilian website. Any doubt due to translations, feel free to ask!
Boa tarde raparigo. Como e que esta voce? :)

Would this allow people to play offline without the need to ever go online? I remember back in the day that LOTS of people had two Xbox 360 consoles at home, one to play legitimately and the other was a pirated console to play games offline.
 
While true, the keys are not compromised because they are not decrypted and accessible - they're somewhere in that encrypted NAND dump. But this does indicate that Sony aren't using unique hardware serial numbers (which does surprise me), or at least their current encryption system is not making use of it.

That's still an avenue for at least limited system and platform compromise, as has been demonstrated.
It's true that the keys are not decrypted as of yet, but due to the physical accessibility and lack of authentication, you can still use the keys without knowing what they are.
It still isn't possible to run unsigned code, but it's not a good thing that you can run someone else's signed code.
It seems like an odd oversight to have made, where the externally accessible data is that interchangeable.

Sleight of hand like this could be a threat long-term, if interactions between versions of signed code modules never intended to interact can be exploited.
 
Boa tarde raparigo. Como e que esta voce? :)

Damm... if ever an automatic translator sucked, it was now :)

Rapariga means Girl... so Raparigo would mean Boy... But there is no such word in the Portuguese Dictionary.
It was a good try nonetheless ;)

The hack allows for online and offline play. The console is a clone, and the software is original. Games can be removed and even updated!
You can even install more if they are original! But for more pirated ones a new cloning is needed!

That means, with the use of a CD key on the games, Sony could detect multiple access. But this would require an internet connection!
 
It's true that the keys are not decrypted as of yet, but due to the physical accessibility and lack of authentication, you can still use the keys without knowing what they are.
Yes, it's an all or nothing solution which is why it's limited to full system cloning.

It seems like an odd oversight to have made, where the externally accessible data is that interchangeable.
Where you suggest storing data that isn't externally available?
 
Yes, it's an all or nothing solution which is why it's limited to full system cloning.
The console itself can support two different accounts, so there is software running in two different signed contexts. I'm not confident that this is something the security architecture had in mind, so there may be room for a dedicated hacking team to generate an exploit if they find a way to force a console in this state to mix and match validation information, code, or system buffers from both contexts.

Where you suggest storing data that isn't externally available?
The possibilities in the future include integrating it on-die or stacking it so that it becomes physically impractical to get away with it in a game shop's back room. There are likely secure stores for the actual signing keys.
With or without that, externally available data doesn't have to be interchangeable between consoles. The hard disk partitions do not allow it, and save the false assumption that the NAND wasn't (ed: was) for some reason inaccessible, why should something like a specific console's firmware package allow it?
Sony has enough experience with the kind of damage a soldering iron and exposed pads or traces can do to their security, and what happens when keys can apply anywhere.

edit: Clarification on contradictory wording
 
Last edited:
The console itself can support two different accounts, so there is software running in two different signed contexts. I'm not confident that this is something the security architecture had in mind, so there may be room for a dedicated hacking team to generate an exploit if they find a way to force a console in this state to mix and match validation information, code, or system buffers from both contexts.
I know the PS4 can support more than two accounts, we have three on ours and friends do, on occasion, login with PSN credentials.
I think it's likely there are only two fundamentally different types of accounts though - primary and secondary/other - which seems designed to accommodate families where one account with a credit card is used to buy most of the software that is shared and I imagine the public key credentials of the owner of the primary account are written to NAND so that any other user with access to it, can run applications owned by that user.

The possibilities in the future include integrating it on-die or stacking it so that it becomes physically impractical to get away with it in a game shop's back room. There are likely secure stores for the actual signing keys.

In the future, yes. But the PS4 is in it's third calendar year (2013, 2014, 2015) from launch and the fundamentals of this were probably designed five years ago (scary, huh!). Their options back then were limited. I would be interested to know of the APU has a USN. If so, Sony can shut this down by hardening the system.

With or without that, externally available data doesn't have to be interchangeable between consoles. The hard disk partitions do not allow it, and save the false assumption that the NAND wasn't for some reason inaccessible, why should something like a specific console's firmware package allow it?

You have to remember that the vast majority of one PS4 is very much like another. It's only the differentiators that set one apart from another and the differentiators appear to be the HDD, RAM (at any particular time) and the contents of NAND. Clone the contents from one to another and the system can't tell. So fundamentally at a hardware level, there needs to be a differentiator like a USN. Maybe there is and they're not using it. Yet.
 
Damm... if ever an automatic translator sucked, it was now :)

Rapariga means Girl... so Raparigo would mean Boy... But there is no such word in the Portuguese Dictionary.
It was a good try nonetheless ;)

The hack allows for online and offline play. The console is a clone, and the software is original. Games can be removed and even updated!
You can even install more if they are original! But for more pirated ones a new cloning is needed!

That means, with the use of a CD key on the games, Sony could detect multiple access. But this would require an internet connection!
:mrgreen: No translator, no, raparigo exists in galician and it is a rapaz (masculine), rapaza (girl, feminine), rapariga (girl). But thanks for clearing that up.

If that's the case I expect the hardware sales to skyrocket in the upcoming months. Any legitimate player could allow for their console to be cloned, Sony couldn't do much to know who is the actual legitimate player and owner of the games and who isn't. while others would get the console just to play offline.

The console itself can support two different accounts, so there is software running in two different signed contexts. I'm not confident that this is something the security architecture had in mind, so there may be room for a dedicated hacking team to generate an exploit if they find a way to force a console in this state to mix and match validation information, code, or system buffers from both contexts.


The possibilities in the future include integrating it on-die or stacking it so that it becomes physically impractical to get away with it in a game shop's back room. There are likely secure stores for the actual signing keys.
With or without that, externally available data doesn't have to be interchangeable between consoles. The hard disk partitions do not allow it, and save the false assumption that the NAND wasn't (ed: was) for some reason inaccessible, why should something like a specific console's firmware package allow it?
Sony has enough experience with the kind of damage a soldering iron and exposed pads or traces can do to their security, and what happens when keys can apply anywhere.

edit: Clarification on contradictory wording
How about changing the NAND in future PS4 designs? Would be it feasible to prevent this hack?
 
I think it's likely there are only two fundamentally different types of accounts though - primary and secondary/other - which seems designed to accommodate families where one account with a credit card is used to buy most of the software that is shared and I imagine the public key credentials of the owner of the primary account are written to NAND so that any other user with access to it, can run applications owned by that user.
That is how the cloned PS4s can continue to add software and updates after the initial cloning. The flaw is that the data that validates the firmware and user credentials is usable outside of the console that created the data.

In the future, yes. But the PS4 is in it's third calendar year (2013, 2014, 2015) from launch and the fundamentals of this were probably designed five years ago (scary, huh!). Their options back then were limited. I would be interested to know of the APU has a USN. If so, Sony can shut this down by hardening the system.
The thing is that AMD has been big on TPM and security measures like TrustZone for some time, and so the option may have been present. Sony was rumored to have declined that solution, and the auxiliary processor may be where some of the initial validation is being handled.
The PS3's security was breached in 2010. The lead-up to that included a rapid increase in the iteration rate due to a successful bus-glitching exploit (ready physical access) and then a failure to properly randomize a value that lead to a compromise to apply to any console.

You have to remember that the vast majority of one PS4 is very much like another. It's only the differentiators that set one apart from another and the differentiators appear to be the HDD, RAM (at any particular time) and the contents of NAND. Clone the contents from one to another and the system can't tell. So fundamentally at a hardware level, there needs to be a differentiator like a USN. Maybe there is and they're not using it. Yet.
That's my argument, that I do not see why there would have been any question as to using unique keys per console from the outset, because there is so little available to authenticate otherwise. The platform's defenses are significantly more shallow if a compromise in one device is universally applicable with no additional effort. It doesn't even necessarily have to be unique, just have enough possibilities that a collision is rare and time-intensive to discover on a large scale.
 
That is how the cloned PS4s can continue to add software and updates after the initial cloning. The flaw is that the data that validates the firmware and user credentials is usable outside of the console that created the data.

I image the the firmware is signed with a public key where the other half is heavily encrypted in NAND.

The thing is that AMD has been big on TPM and security measures like TrustZone for some time, and so the option may have been present. Sony was rumored to have declined that solution, and the auxiliary processor may be where some of the initial validation is being handled.

TPM has a cost attached. I only work with TPM devices and you'd be shocked at the hidden costs of some implementations. I do not believe the rumours about Sony and TrustZone but then I have more to go on that rumours which I cannot share. But plenty of TrustZone solutions are not reliant on USN. It depends on what vulnerabilities you're protecting yourself from.

That's my argument, that I do not see why there would have been any question as to using unique keys per console from the outset, because there is so little available to authenticate otherwise.

Cost, definitely cost.
 
How about changing the NAND in future PS4 designs? Would be it feasible to prevent this hack?
In other cases, firmware chips have had fuses blown before leaving the factory to prevent dumps of the contents or prevent reflashing.
There are also various forms of non-volatile storage chips that themselves are designed to encrypt or protect their contents, although if that were an option here it wouldn't help if the exact same key were used.
I don't know if Sony felt there is a need for such bulk activity in the wild, if for manufacturing, updates, or RMAs.

That aside, it probably should not be up to the physically separate non-volatile storage to do this. It is permanently vulnerable to analysis and snooping over its bus. Having some kind of encryption there would be a nice initial barrier, but it should be something internal to a processor or SOC, and even unique to individual consoles if you're really paranoid.
The storage then wouldn't need to know the details of what it was storing, and something like a unique key and maybe even a hash function that swaps around how the addresses are stored would make it harder to divine what was being loaded out of the storage and it would fail outright if cloned to a different machine.

This is something I am curious about with regards to the suspend modes of both consoles, since there is now a way for a rapid restart that might have important data in DRAM packaged for a quick boot. That's volatile storage, but DRAM can be manipulated to retain data (freezing it) and can be dumped.
In-memory encryption is also a thing that has at least been proposed as a future solution.

Come to think of it, which module is the NAND? I was going by descriptions of the hack, but is there actually a NAND chip as opposed to a different non-volatile? The teardowns weren't clear on this.
 
Google's auto detect and translate worked for me. Detected Galician.

Galician is a mix between Portuguese and Spanish. A lot similar to portuguese but with some spanish terms. It´s neither portuguese, nor real spanish.

I keep a Portuguese Technology Webpage, and do all my translations myself. And boy, do I see some terrible translations in other websites. Sometimes things cannot be translated to the letter and if they are the real meaning of the phrase may be lost.

Rapariga is a Girl... but not any girl. A Young girl, an adolescent! If you call Rapariga to a mature woman she won´t like it. It implies she as not matured at all!

And be even more carefull in brasilian. Rapariga is whore or a mistress.

In Portuguese/Brasilian (And brasilians speak Portuguese, but use some terms of their own) the masculine of rapariga is Rapaz.

Sorry for the off-topic. Lets talk again about Sony's rapariga ;)

Don´t you believe a firmware solution can be found that prevents writing on the Nand without some sort of validation, blocking brute force access? BMW did something like that recently to prevent reading of their cars ECU's NAND and the cloning of keys using the OBD port!
 
Google's auto detect and translate worked for me. Detected Galician.
Fas ben Shifty Geezer. :LOL: Google got it with the raparigo thing, but words like voce don't exist in galician, for instance.
In other cases, firmware chips have had fuses blown before leaving the factory to prevent dumps of the contents or prevent reflashing.
There are also various forms of non-volatile storage chips that themselves are designed to encrypt or protect their contents, although if that were an option here it wouldn't help if the exact same key were used.
I don't know if Sony felt there is a need for such bulk activity in the wild, if for manufacturing, updates, or RMAs.

That aside, it probably should not be up to the physically separate non-volatile storage to do this. It is permanently vulnerable to analysis and snooping over its bus. Having some kind of encryption there would be a nice initial barrier, but it should be something internal to a processor or SOC, and even unique to individual consoles if you're really paranoid.
The storage then wouldn't need to know the details of what it was storing, and something like a unique key and maybe even a hash function that swaps around how the addresses are stored would make it harder to divine what was being loaded out of the storage and it would fail outright if cloned to a different machine.

This is something I am curious about with regards to the suspend modes of both consoles, since there is now a way for a rapid restart that might have important data in DRAM packaged for a quick boot. That's volatile storage, but DRAM can be manipulated to retain data (freezing it) and can be dumped.
In-memory encryption is also a thing that has at least been proposed as a future solution.
Thanks for the detailed reply, awesome as always. As for what is stored for rapid start purposes, the game data remains intact, but why should they keep important data on memory rather than just the game's assets?

Come to think of it, which module is the NAND? I was going by descriptions of the hack, but is there actually a NAND chip as opposed to a different non-volatile? The teardowns weren't clear on this.
That's a very good question, and this teardown says that the PS4 doesn't use NAND memory:

this article

“At the console level, the Xbox One is $10 less expensive than the PS4. This is primarily due to a $23 memory premium on the PS4, but it is offset by an $11 cost premium on the Xbox One processor. The Xbox One also has 4GB eMMC NAND flash, making the non-volatile category $3 higher for Xbox One, while the housings/mechanicals of the Xbox One add another $4 premium over the PS4.”

and this other article

"Another Xbox One chip located on the mainboard and marked as X861949-005 T6WD5XBG-0003 has its own eMMC NAND memory buffer, but its purpose is unclear."
 
Last edited:
Galician is a mix between Portuguese and Spanish. A lot similar to portuguese but with some spanish terms. It´s neither portuguese, nor real spanish.

I keep a Portuguese Technology Webpage, and do all my translations myself. And boy, do I see some terrible translations in other websites. Sometimes things cannot be translated to the letter and if they are the real meaning of the phrase may be lost.

Rapariga is a Girl... but not any girl. A Young girl, an adolescent! If you call Rapariga to a mature woman she won´t like it. It implies she as not matured at all!

And be even more carefull in brasilian. Rapariga is whore or a mistress.

In Portuguese/Brasilian (And brasilians speak Portuguese, but use some terms of their own) the masculine of rapariga is Rapaz.

Sorry for the off-topic. Lets talk again about Sony's rapariga ;)

Don´t you believe a firmware solution can be found that prevents writing on the Nand without some sort of validation, blocking brute force access? BMW did something like that recently to prevent reading of their cars ECU's NAND and the cloning of keys using the OBD port!
I speak galician like 99% of the time. You described the language very well, it also has a few celtic words, especially noticeable in place names. Rapariga where I live is a not so common word, but used to call someone -even a relatively mature woman (say until their late 30s)- girl/woman in an affectionate way. But the "correct" term and the original one always refers to a young girl. So yeah, it depends on the place and the context.

As for the PS4's NAND, it sounds to me like the 3MB of eSRAM on the XO CPU or some WiiU components that are there but nobody knows exactly what their function is.
 
Last edited:
Thanks for the detailed reply, awesome as always. As for what is stored for rapid start purposes, the game data remains intact, but why should they keep important data on memory rather than just the game's assets?
That is a fair point, so I can only express curiosity if there is a possible exploit there, either due to something left there by design or just something accidentally left available.

The benchmarked launch times from suspend for the PS4 appear to be measurably shorter than the launch times recorded prior to that option being available, although that does not rule out improvements to the boot process in general. The Xbox One has an actual NAND chip that might hold something, whereas the PS4 does not--although using the NAND for the Xbox One goes back to the question of whether it is uniquely encrypted.

I'm curious if there's something left in DRAM that might be used to skip over startup or enumeration steps for devices, or links between OS services and the game partition.
Given that Sony didn't feel like the firmware needed to be fully locked down, there might be cause to wonder if there was some kind of assumption built in from early development that volatile memory could not be intercepted by a sufficiently motivated party.

There are some interesting directions being proposed for hashing and encrypting data in DRAM, although nothing mentioned of that sort for the consoles.
 
ICome to think of it, which module is the NAND? I was going by descriptions of the hack, but is there actually a NAND chip as opposed to a different non-volatile? The teardowns weren't clear on this.
It's flash rather than NAND. The PS4 has three distinct banks of RAM: 8Gb GDDR5 (using Samsung K4G41325FC-HC03 chips), 2Gb DDR3 (a Samsung K4B2G1646E-BCK0 chip), 256mb Flash (a Macronix MX25L25635FMI chip).
 
That is a fair point, so I can only express curiosity if there is a possible exploit there, either due to something left there by design or just something accidentally left available.

The benchmarked launch times from suspend for the PS4 appear to be measurably shorter than the launch times recorded prior to that option being available, although that does not rule out improvements to the boot process in general. The Xbox One has an actual NAND chip that might hold something, whereas the PS4 does not--although using the NAND for the Xbox One goes back to the question of whether it is uniquely encrypted.

I'm curious if there's something left in DRAM that might be used to skip over startup or enumeration steps for devices, or links between OS services and the game partition.
Given that Sony didn't feel like the firmware needed to be fully locked down, there might be cause to wonder if there was some kind of assumption built in from early development that volatile memory could not be intercepted by a sufficiently motivated party.

There are some interesting directions being proposed for hashing and encrypting data in DRAM, although nothing mentioned of that sort for the consoles.
Launch times were the same if you used the Instant-on (the equivalent of sleep mode in a computer OS) feature. That's to say, time remained the same to get to the console's dashboard -instant-on, fast launch, like 5 seconds, power saving mode, 1 minute launch-.

What I noticed is that after suspending a game and returning to the dashboard, the sound of said game stuttered for a few seconds, and sounded like one of those machines of the 70s-80s (prrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr.r..-rr-r-r-r-r-r-r-r-r-r-rr-r-r-r-r-r-r-r-, like the bleep of a Pc internal speaker if your keyboard is not the NKRO type). This was more noticeable in Diablo 3.

Regarding the NAND, :smile2: X360 apparently used a set of irreversible fuses (whatever that means..., what does it mean, btw?) per console.

What puzzles me is; why using a 8GB NAND? Couldn't the encrypted keys get away with a 128Kb-256Kb NAND? We are talking about a few numbers, no need for 8GB to store that.
 
What I noticed is that after suspending a game and returning to the dashboard, the sound of said game stuttered for a few seconds, and sounded like one of those machines of the 70s-80s (prrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr.r..-rr-r-r-r-r-r-r-r-r-r-rr-r-r-r-r-r-r-r-, like the bleep of a Pc internal speaker if your keyboard is not the NKRO type). This was more noticeable in Diablo 3.
Audio is latency-sensitive, so maybe that has to do with the process of suspending interfering with the processing of what remained in the audio buffers. Diablo 3 seems to have a pretty rigid frame tick model going by the way damage and weapon/monster effects kick off, so perhaps other elements of the engine won't to respond to the suspend event without spitting out a few final frames worth of data.

What puzzles me is; why using a 8GB NAND? Couldn't the encrypted keys get away with a 128Kb-256Kb NAND? We are talking about a few numbers, no need for 8GB to store that.
I saw some speculation it was used by the OS and applications, but another explanation that sounds plausible is that it contains a backup system image. I don't recall an official statement on that, however.
 
Back
Top