Today PlayStation 3 developer modrobert has dumped the PS3 4K unit memory and initiated a project that aims to implement PlayStation 3 4K Custom Firmware (CFW) on PS3 Super Slim (4K) models with details below.
To quote: "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)...
[Register or Login to view code]
- 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).
[Register or Login to view code]
- 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
From Abkarino comes a link to 2 unencrypted PS3 bootloaders that may help in research as follows:
Download: dump_1.zip / dump_1.zip (Mirror) / dump_2.zip / dump_2.zip (Mirror)
From modrobert also comes another update, as follows: Yes, you are definitely on the right track there with 'rtl-sdr'. I guess my waterfall plot gave it away.
I had some other pm replies guessing Acoustic Cryptanalysis (cs.tau.ac.il/~tromer/acoustic/) which wasn't bad either, someone also mentioned "ground plane attack" which basically measures voltage diffs. They are all good guesses, and I've used bits and pieces from all those techniques.
My idea was to hook up a rtl-sdr (sdr.osmocom.org/trac/wiki/rtl-sdr) device to the PS3 4k between chassis and real ground (yes, I actually have a two meter copper rod buried in my lawn) using the antenna leads. First I had to make sure the PS3 4k chassis wasn't grounded in the outlet, and that no video out or USB connector was hooked up to ground indirectly via other hardware. If you want to try this, make sure that the rtl-sdr antenna leads are the only lead between the PS3 mobo/chassis and real ground. Before connecting the rtl-sdr antenna leads I measured the voltage on the PS3 chassis which peaked at around 1.8V which was safe enough, didn't want to blow it up on the first try.
This method will effectively turn your console into an "active antenna" leaking all kind of interesting data on the rtl-sdr frequency spectrum (between 24 - 1766 MHz). After hooking it up, I started using gqrx (gqrx.dk) on my laptop to look for signal peaks while the PS3 4k was turned on, after finding a peak I just powered off the PS3 completely and turned it back on, using the waterfall plot you've seen in my first post I can see if there is something interesting happening during boot and verify that the signal is indeed coming from the PS3.
In a similar way I learned to distinguish between the PS3 BD drive, GPU and CPU which pops up at different frequencies. Then I dumped the data (I/Q recording) that looked interesting and made a note of the frequency. You also get reflected signals of some chipsets, so after searching some more a better "version" of the same signals from booting the PS3 might appear at a different frequency.
It's hard to describe the incredible feeling when you tune into a good signal and start watching the waterfall plot revealing opcodes, register bits and what might be stack contents. The Acoustic Cryptoanalysis paper (PDF) has a lot of good info how to interpret the output from various window functions (en.wikipedia.org/wiki/Window_function) in the plot.
What I'm coding right now is a gnuradio-companion (gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules) block which will filter and test the dumped data for decryption keys against encrypted PS3 data. This turned out to be a lot harder than I expected, the human brain is better at finding interesting signals and decipher bits in a visual history plot than a computer based program, but with the amazing GNU Radio software (gnuradio.org) you get a lot of signal processing for free in the form of existing blocks/modules. Computers are indeed dumb, but fast, as Feynman pointed out.
That would probably be a good approach if I was receiving emissions from a distance (air gap), but in this case the rtl-sdr device antenna leads are directly hooked up between PS3 chassis and ground (with PS3 otherwise isolated from ground), so a faraday cage would be bypassed by the circuit. However, it might help with reflections (signals showing up on several frequencies).
What I try to do when identifying signals is to use moments when some chipsets are inactive while others aren't (eg. early boot), or better, remove parts from the circuit completely when possible. I also use chipsets extensively to identify.
For example, when I find a signal peak, I mount a BD disc and watch the signal when the drive spins up, if it changes a lot and starts to show stuff in sync with servo movements, controller, coils charged up etc., then I know that it is the drive. The pattern is also useful to remember, if it shows up in signals on other frequencies as interference.
The frequency range of these rtl-sdr devices is huge, 24 MHz - 1766 MHz, so interference hasn't been a major issue so far. After searching for a while I can find a relatively clean signal of some part I have identified during boot cycle or otherwise.
I realized last night is that I should write homebrew code on my other PS3 with CFW that just executes one PPC assembler instruction (opcode) thousands of times in sequence (not in a tight loop though, because that involve branches). While doing that I have to dump the signal to map out the opcodes, and make a signature system for each opcode so it can be identified by my grc block program (and visual waterfall screenshot so I can remember the signal in my head as well).
Then using opcodes on one specific register at the time to map out those with bit contents, and the stack, and so on. Imagine the possibilities when having a "waterfall view" where it's raining opcodes (disassembly) and register contents rather than signal dots. Sure, it will be random opcodes from execution at best, with gaps (incomplete disassembly), but all we need is a single register (or stack) content at some point early on in the boot regarding the keys.
From iCEQB: Very interesting approach ! Can you show us how the ouput looks like when you are looking for strings or something ? Something familiar that the average joe would recognise
Also, is it possible to focus on the cell ? Only receive what the CPU is doing ? I ask in case the unique console key ever gets exposed in isolated SPU mode?
I don't know if the cell has a hw crypto engine or not, but if so I can't image we ever get the key out of there, because it's hard burned into the CPU and probably never leaves its location (?)
On the other hand I don't know what exactly you can sniff with this method.
From modrobert: Yes, the CELL (PPC CPU) appears to be an isolated signal cluster, you can see it from a "zoomed out perspective" in my previous black & white waterfall image, it's on both sides of the bright white vertical line there, with what appears to be registers or cache of some sorts (stack?) flanking each side where single bits seem to change over time (vertical axis).
To understand it better you really need to see a video of the signal in action (also with audio for added effect), or try it yourself. I can upload a video later to youtube if I figure out some smart way of doing it.
All keys have to be processed by some CPU/GPU/MCU somewhere during boot (from power on moment) or it can't be used for decryption. These are not memory dumps, and not bus dumps either, but rather detailed boot logs with signal fragments of a targeted chipset operating with a clock oscillator, depending on oscillator speed and other factors the signals appear at different frequencies, which is great for us, since we get CPU, GPU, memory controller, BD drive, etc., appearing on different frequencies.
To get an idea what you are looking at when doing this you need to check the signal screenshots/images in the Acoustic Cryptoanalysis paper (PDF).
They have some examples there identifying the keys in PGP decryption from a computer by just using audio dumps from a standard microphone at a distance, which looks really hard to do because their data is filled with noise and looks really fussy compared to the signals I dumped via rtl-sdr from the PS3 which are clear and detailed in comparison.
From defyboy: I know of a few people who have very specific expertise in this field who have tried even far more complicated side channel attacks however it would seem IBM put quite a bit of effort into masking exactly this.
Please see the following patent for an idea of how this works: google.com/patents/US8046573?dq=cell+broadband+engine+secure&hl=en&sa =X&ei=dfQCVM_hGpXh8AXm54D4Ag&ved=0CCMQ6AEwATgK
From modrobert: Thanks for the help so far, here and on IRC, not sure how to proceed though.
I keep receiving hints about an upcoming lawsuit by some people privately, at the same time getting help from PS3 hackers in many different ways. Unfortunately this also includes being fed like a "fall guy" with existing PS3 information no one else dare to release it seems.
When starting this project I assumed that there was a lot of RE work needed to reach the goal of installing CFW on PS3 Super Slim (4k), but after getting extensive feedback the past week, it seems like this information is already known, but deliberately not used/finalized, either out of fear or other reasons.
The rtl-sdr side channel method I'm trying to develop here is far from complete, haven't even started to test the decryption with collected data yet, still developing the grc stream block by identifying signatures of opcodes, registers, stack, etc. However, I'm starting to feel this is time wasted, at least on PS3. Let me know what you think.
From Fox_Hound Derpa 992: When loaded into memory the isolation begins where the virtual adress of the isoldr is stored, kakoii is exactly right except if it indeed it there are only single keys in existence that remain, the given frequencys the spes give off are using masked substitution tables according to how one would obtain a private key through brute force or through modroberts given side channel xtraction method.
Here's a link for anyone interested: http://www.google.com/patents/US7778419
Reversing a public key to find a private key through xor bruteforce method is a good way to implement key masking to calcuate obtained private keys while the boot order stupidly makes it self vulnerable to decrypt random mask values via power consumption dpa attack ftw.
So if the boot order runs a round a trust diagram to load various loaders and pass security checks among the core files to check for any intrusion or modifications you only rotate masked key values of the first rounded key used to compute the xor value to calculate the private key.
So since Sony uses two cryptographic operation in verifying lv0 and using 0.2 to console check the core os for modifcations internally.. our round keys are general public keys of a 16 bit value while our loaders use a random combination of of masked key values key values wich we can calculate according to the ldrs obtained from 360xx onward. since the spkg hasn't changed
Below is a PS3 Revoke Keys Small Dump by Fox_Hound Derpa 992. as follows:
From B7U3C50SS: Okay so someone wants to know about the processor they use? the chip patent was it? well i can help you narrow it down for good measure.
PS3.. still uses FreeBSD, open Solaris CSW, Oracle, Java, SUSE, fedora, UNIX, Linux, and the Sparc processor. (not sure on the patent though) On every FW update this is all they do - change the Linux type and base off those factors (make it UNIX).
that stuff is all licensed by GNU ^
It seems this way to me at least. Least I think Deank has to have figured this out as well considering he used all these exact types of linux distros to create MulitMAN.
Also deank never really used the psl1ght sdk from what i'm hearing. It has been said many times before that the key they put out was the Bootldr key not lv0 And I'm pretty sure its only the pub-priv key not the private key.
From boxcutter: Just a thought, if every console has it's own key based on fuse-bits. if we could find out how they function, maybe blow the lot. Set the key-seed to "FF / 00" or whatever!!!
Have you done a patent search for the ps3 chips?
From BadBoy17: There is no lv0ldr ... lv 0 private key is lv0ldr a key leaked by the muskateers , lv0 is decrypted by bootldr.
Finally, from modrobert (via eurasia.nu/modules.php?name=Forums&file=viewtopic&topic=7352& forum=87#34580):
Thanks, but think I will take a break from this project for a while now.
The PS3 doesn't like my probing, changed cabling, shielded, shortest possible, resistor configuration, different caps in serial and parallel (and both), it shuts down with three beeps no matter what I try.
Here is a photo of my first motherboard XDR DRAM soldering, with some hot glue blobs to keep the wires in place.
TIP: You can easily remove hot glue with rubber alcohol (aka Isopropyl or Isopropanol) on a cotton bud, just work your way from the edges and let it soak for while, falls right off like magic.
After reading the Elpida XDR DRAM datasheet a bit more (attached previously in this topic) it seems like the PS3 runs the serial port clock at 200MHz, because they mention 5ns clock cycle for SCK (which is roughly 200MHz), and that seems to be correct with observations during my tests. When dumping the pin signals at 350MHz using the FPGA (ChipScope core) I can see that the smallest pulse train periods are around two clock cycles.
I have managed to get data on the SCK, RST and CMD pins using CMOS12 levels on the input. The SDO and SDI pins are dead traffic wise, and I suspect it is because my circuit is disturbing the PS3 when initializing the XDR DRAM somehow, or the signal levels are wrong (have tried input configured as CMOS12, CMOS15, CMOS18, CMOS25 with and without pullups/pulldowns), this is no surprise since Rambus have their own RSL standard, so anything besides that is a compromise.
I bought two voltage-level breakout boards; TXB0104 (aka level shifters), but they are too slow for this purpose, with a factor of 10 (50ns @ 1.2V which is roughly 20MHz), this is high speed serial traffic. When Rambus refer to "low speed serial" it is because they compare with the XDR DRAM itself which is 3.2GHz, so yes, 200MHz is not much then. You can potentially write at a lower speed than reading on the XDR DRAM serial pins, but the problem is that the PS3 doesn't like when you block that bus, and shuts down, so whatever we need to do, it has to be very fast.
As an interesting sidetrack I managed to find the Syscon UART pins for my DIA-002 PS3 motherboard after searching around a bit, soldered some wires to the points and hooked up my custom 3.3V MAX3232 serial board using the Amiga 1200 and NComm terminal prog (57600 BAUD 8N1), wanted to see if there was any message when the XDR DRAM failed (with three beeps) to make it easier to debug my problem, but there was no error message.
I tried some of the syscon commands found over at ps3devwiki.com (psdevwiki.com/ps3/Syscon_Hardware#Samples) after writing a small Python prog (attached) to generate valid commands with required checksum.
[Register or Login to view code]
Some syscon commands worked, most of the listed commands fail, apparently it differs a lot depending on firmware or console version.
Here is a photo of the Syscon UART solder job on my DIA-002 mobo.
Until I come up with some fantastic idea how to interface with Rambus XDR DRAM properly this project is on hold. Also, I could use a high-end oscilloscope to debug this properly, but those are way too expensive for my budget.
In the meantime I will play around a bit more with the Syscon UART, fascinating little SoC which is alive even when the PS3 is in standby mode.
More PlayStation 3 News...