PS3 4K Model Dumped by ModRobert For CFW

**CroCop** · 08-29-2014

PlayStation 3 developer ModRobert has started a project that will allow for implementation of CFW on the 4k models by figuring out a way around of having to sign for them, and hopefully, obtaining the keys. He has so far succeeded in dumping the units memory with the goal of adding CFW to the SuperSlim.

Sony intentionally shipped out their 3k and 4k models with a firmer higher than 3.55 OFW, that makes it necessary for the installation of CFW. The workable methods for a hack so far, has been the ODDE way and that hasn't been a very convenient method. Owners of the ODDE's have been forced to burn bluray discs and use the swap-disc method with the device, which puts them back in the stone-age methods of the PS2 hacks. Sony has been quick to patch those methods with updates that render them useless. Needless to say, there has been a big need and want for a hardware free, permanent solution hack for the newer model PS3's.

A quote from ModRobert -

"After releasing 3k3y firmware v2.11 beta (with OFW 4.55 support) and losing interest in the ODE "cat & mouse" game with Sony (OFW 4.60 and 4.65), I have spent the past few weeks researching and dumping raw data in an ongoing project to extract lv0.2 keys via bootldr.

My dumps include data from most of the PS3 4k chipsets, this was *NOT* collected by sniffing a bus (or several) in a conventional way, so even if targeted key is embedded in silicon, as long as it is processed/executed internally by any kind of microcode I might be able to catch it.

At this point I don't want to reveal how the data was obtained exactly, it is a method of my own design based on several known side channel attacks. The intention is to release the method eventually.

What is required to install CFW on PS3 Super Slim (4k)?

Added lv0.2 to the crypto chain diagram which is how it works on PS3 Super Slim (4k).

NEW consoles only: metadata lv0.2 (signed with nonrandomfail key) is used to check lv0 integrity.

As I figured it (please correct me if I'm wrong) we need the keys for lv0.2 which are held by bootldr. Some claim that bootldr is "Per Console Encrypted at factory", but I have my doubts about that, either way, as long as we can get that key on one specific console it is enough for our purpose. More on that later.

What it boils down to is this (using CORE_OS data from OFW 4.65 in this test case)...

scetool -v -d lv0.2 foo2.out
scetool 0.2.9 <public build> (C) 2011-2013 by naehrwert
NP local license handling (C) 2012 by flatz

Loaded keysets.
Loaded loader curves.
Loaded vsh curves.
Using keyset [lv0ldr 0x0000 00.00]
Error: Could not decrypt header.

We need this to succeed in order to reach the final goal of installing CFW on PS3 Super Slim (4k).

This is how it looks for lv0 (where we have the keys already).

scetool -v -d lv0 foo.out
scetool 0.2.9 <public build> (C) 2011-2013 by naehrwert
NP local license handling (C) 2012 by flatz

Loaded keysets.
Loaded loader curves.
Loaded vsh curves.
Using keyset [lv0ldr 0x0000 00.00]
Header decrypted.
Data decrypted.
ELF written to foo.out.

Now that's a lot better...

My dumps include data from most of the PS3 4k chipsets, this was *NOT* collected by sniffing a bus (or several) in a conventional way, so even if targeted key is embedded in silicon, as long as it is processed/executed internally by any kind of microcode I might be able to catch it. At this point I don't want to reveal how the data was obtained exactly, it is a method of my own design based on several known side channel attacks. The intention is to release the method eventually.

I can clearly see the first steps during PS3 4k boot in the dumps, the syscon init of the CELL, things are a lot slower in the initial boot process, MHz rather than GHz. (ps3devwiki.com/ps3/Boot_Order)

What I'm trying to code right now is a clever python script that will parse the raw data and test potential keys by decrypting lv0.2 in a loop.

To be honest, chances are probably slim (phun intended) this will succeed even with the collected data and a clever method to test keys, but the final goal makes this project exciting no matter what the odds are!"

PlayStation 3 developer iCEQB chimed in the following as well on the ongoing project: bootldr is encrypted per console with a unique key which CELL holds.

IF lv0.2 is indeed decrypted by bootldr, than bootldr does signature checks as well, which carries on for the rest of the bootchain.

This means, IF you manage to get the lv0.2 keys, you might be able to decrypt it, but not sign it, because the ECDSA fail is long gone.

So no matter where you try to exploit the system during boot, past the bootldr stage, you won't get far because of the signatures you can't produce for patched files.

The only way I see it going down is to get the unique console key to encrypt a patched bootldr, which keeps booting into an unsigned bootchain.
I don't know whether if bootldr is signed or IF CELL is capable to check signatures, but afaik and iirc, bootloader is "just" encrypted with the keys inside the on DIE bootrom of the CELL.

I heard rumors every now and then of a 360 like glitcher, which exploits the console during boot to execute an unsigned loader.

Or the other way around is to exploit the system during runtime ... something like HEN for PSP.

Dunno, you have the decrypted bootldr on hand

"Sony Computer Entertainment Inc" shows up pretty often their system related files ... but afaik this would only appear inside an isolated SPE, because bootldr and metldr never leave the CELL if I'm not mistaken.

You need a way to expose the boot ROM keys ... if that can be reproduced on other consoles w/o any decapping (or whatever you are doing ) then we might have something to look forward to for the broad audience

Regards

[WIP]PS3 4K Model Dumped by ModRobert For CFW