PS3 SCETool, Friday Isolated SPU POC and EIDTool WIP Updates
This weekend Sony PlayStation 3 hacker naehrwert has released a PS3 SCETool based on the fail0verflow tools, an Isolated SPU binary POC dubbed Friday and some EIDTool work in progress updates for PlayStation 3 developers interested in remarrying Blu-ray drives, motherboard keys, QA tokens, etc via [Register or Login to view links].
Friday (C) 2011 by naehrwert - This is a POC for a isolated spu binary. Generate a self encrypted+signed with the metldr keys out of friday.elf. Then use friday.h to write a PPU application that loads the self by utilizing metldr and DMAs your console's EID2 to the shared SPU LS. It will generate the P and S block from it, that is used to pair the BD drive to the specific console. Yon can then DMA the blocks out from the LS and send them to the drive to remarry it to the console.
Communication with the SPU is done over in_mbox and out_mbox. MSG_OUT_* is send from the SPU code to out_mbox. MSG_IN_* should be written from the PPU to in_mbox. When MSG_OUT_READY arrives the PPU should DMA the EID2 to EID2_START and send MSG_IN_READY. When MSG_OUT_GEN_DONE arrives the PPU should DMA the blocks out from BLOCKS_START and send MSG_IN_DIE.
I wonder what else is stored in the area and how long the data in it persists, so my next idea is to code an isolated elf, that allows me to specify the value written to channel 64 and then dumps the data from channel 73.
Here are a few quick updates from naehrwert (twitter.com/naehrwert) for those following:
haha just figured the eid3 algo, nice!
KaKaRoToKS and I added basic NPDRM support to scetool
SELF generation works now for SPU and PPU, except for compressing the data and NPDRM
added SPU SELF generation to scetool
Also from his site: nwert.wordpress.com/2011/12/24/individual-infos/
One of the PS3′s console specific cryptography works as follows:
At factory time there is a console specific key generated, probably from a private constant value and a console specific seed. Maybe that’s the key used for encrypting bootldr and metldr. Fact is, that metldr stores another console specific keyset (key/iv) to LS offset 0×00000. That keyset is probably calculated from the first one. At factory time the isolated root keyset (how I call it) is used to encrypt the console’s “Individual Infos”, like eEID.
But not the whole eEID is encrypted the same way, special seeds are used to calculate key/iv pairs for the different sections. And not even that is true for every eEID section, because for e.g. EID0 another step is needed to generate the final section key(set). Each of the isolated modules using such an “Individual Info” has a special section that isoldr uses to generate the derived key(set)s.
But the generation works in a way, that the section data is encrypted with aes-cbc using the isolated root keyset, so it is not possible to calculate the isolated root keyset back from the derived key(set)s, because aes shouldn’t allow a known plaintext attack. So far I can decrypt some of EID0′s sections, EID1, EID2 and EID4. EID5 encryption should be similar to EID0′s but I lack the generation keys for that one.