Thread: HDD encryption
I just wanted to share some insights of the HDD encryption, I gained in the last days:
It seams the encryption is sector(512 bytes)-wise, meaning that each sector is encrypted by the same way. There are no further dependencies of the encryption key to things like the sector number (but of course the key depends on the specific PS3).
In each sector the data is encrypted in 16-byte chunks. There are 32 of these chunks in each sector and every chunk is encrypted differently. Whether the algorithm change or the key, I don't know yet.
The chunk encryption is not a simple XOR with a key, it actually depends on the data in the chunk. I think it is also not a simple substitution chiffre, since for 16 bytes, the substitution table would be far far too big to store anyway. I'm currently investigating whether it may be a linear function of the input data.
That's what I know so far, comments, any ideas?
Have a look at http://en.wikipedia.org/wiki/Cipher_...ning_.28CBC.29 to see how those 16byte blocks get combined. It is a standard way in cryptography. The cipher may be anything - AES maybe.
There is a test to verify it really is CBC mode and block length is really 16 bytes:
- Encrypt 2 blocks of clear text - P1 and P2, you will get 2 blocks of encrypted text C1 and C2.
- Encrypt 3 blocks - P1, P2 and P3 so that P3 XOR C2 is the same as P2 XOR C1. Input to cipher in third block thus should be the same as to second block. If it is so, C3 should be the same as C2.
If it is so, it is CBC and we know that block length is indeed 16 bytes.
Great work guys, keep us all informed actual PHYSICAL Proof of the HDD and how its encrypted for all to see, not just myths... Keep it up, fingers crossed!
P.S: I think it will have AES in there somewhere, and it could be related to PKG AES if they are stupid, and so we can unlock two secrets quickly...
Hey RexVF5 you are right, it is chained. Great comment.
Perhaps I should write a report of my hdd analysis so far:
When you dump your HDD, you easily identify two kind of sectors: sectors written by the PS3 and sectors never touched by the PS3. The first ones contain zeros (or whatever was on the disk before it was mounted to the console), the latter garbage, i.e.totally random data, so that are the encrypted sectors. In the following I will only talk about the sectors written by the PS3.
You can actually find some sectors with same content. Doing a histogram for each byte index in the sector individually over the whole disk, you notice for each byte index a high frequency for a single value. This is the encrypted value of all bytes in the sector zero. By this way you can get the encrypted version of an sector with all bytes zero. I will refer to this encrypted sector as the "zero-sector".
Now you can actually find some sectors on the disk, where the first bytes of equals the corresponding ones of the "zero-sector" while the rest of the sector is again random. You also can notice that this only happens with multiples of 16bytes. I will call a quantity of 16bytes a chunk in the following. This is why I said the sectors are encrypted chunk-wise.
After RexVF5 comment, I tried the following: I write a file (using the PS3) on the disk, which contained:
#1: a sector with first chunk all zeros, rest of sector full with 0xff
#2: a sector with first two chunks all zeros, rest of sector 0xff
As described above, on the encrypted sector #1 the first chunk equals the corresponding bytes to the "zero-sector", while the rest is garbage. In the encrypted sector #2 the first two chunks equals the "zero-sector" as expected. When you compare the third chunk on both encrypted sectors they contain different random data (even if the clear text in both sectors is all bytes 0xff).
This is a clear evidence that actually the difference in the second chunk changes the encryption of the third chunk. And that's cipher-block-chaining.
Yep, pretty much CBC. I agree with you. what you can try to do is to set all chunks to 0x00 except the very last byte of the sector. Then try to figure out what makes the difference and that last byte encrypted. For example:
512 bytes sector = 511 (0x00) + 1 (0x01). And then, on that last byte go from 0x01 from 0xFF and compare the differences.
interesting progress, good work thus far
This is quite interesting! Thanks for sharing what you found!
It would be nice to check and make sure that CBC is used (not PCBC, CFB, OFB or CTR as explained in http://en.wikipedia.org/wiki/Cipher_block_chaining ...)
What RexVF5 suggested seems like the best way to test this :
Encrypt 2 blocks of clear text - P1 and P2, you will get 2 blocks of encrypted text C1 and C2.
Encrypt 3 blocks - P1, P2 and P3 so that P3 XOR C2 is the same as P2 XOR C1. Input to cipher in third block thus should be the same as to second block. If it is so, C3 should be the same as C2.
Did anyone try to do a cold boot attack on it to see if we could get the encryption keys out of the RAM ?
See here for more info : http://en.wikipedia.org/wiki/Cold_boot_attack
It could be done maybe by a simple off/on on the back switch + power on.. putting the ps3 in a fridge before would probably help! Someone with liquid nitrogen and willing to put it on the RAM and unplug the RAM from the machine would have better success rates I suppose but anyways... booting into a minimal otherOS and quickly dumping the RAM might give us some info on the encryption keys... (does the hypervisor allow us to access the raw RAM by the way? I guess it does...)
Anyways, The method to decrypt/encrypt the disc is great, kudos to the people who discovered it (and no worries, I don't think sony can prevent this without forcing a full re-encrypting of the whole HDD which they can't afford to do).
I'm interested in knowing a few things, if someone is willing to try it out :
- Those 0x000000 bytes at the start of a sector that are encrypted in the same way everytime, does it change from one ps3 to another? Does it change if you change the HDD and reformat it? In other words, is the key unique to every PS3, or is it dependent on the HDD?
- By properly feeding data to the PS3 to encrypt (the dummy file), we can easily recore the initialization vector (IV) for the CBC.. can we also check if the IV is unique to the PS3 or is it always the same? Does it change if we change the HDD on the same PS3 ?
- By zero wiping an HDD then formatting it (fully) for the PS3, how much space is taken by the OS (how many non zero bytes are stored) ? Do they ALL seem to be encrypted or is there a small header that isn't encrypted (might contain the keys or IV if the key seems to change after every format) ?
- If we zero wipe the HDD then format it, then decrypt the whole OS stored on it, then 'dd' (write to the disc) the decrypted partition, how does it get detected? is it ext3, reiserfs, etc.. ? can a Linux system recognize the file system and mount it ?
we can obviously *encrypt* data back into the HDD too... pretty simple, put a huge dummy file, find its offset, copy the encrypted OS on it, decrypt it with the PS3, copy it to your PC, modify it, write it back as the 'dummy' file using the PS3, plug the HDD back to the PC and at the file's offset, you'll get the new encrypted OS, just replace the previous OS offsets with the dummy file's content... boot the PS3 and you got a modified OS on your PS3 (assuming it boots)
The process is hard and takes time, but if we use small HDDs (the minimum size for a sata 2.5" is probably 10 or 20 GB.. if you can find one..) and use external HDD connectors, it could be help speed up the process... I'll try to test all this, but I don't have a spare 2.5" drive
Keep up the good work!
Well, just a note - you can use a 3.5" SATA hdd with your PS3, just grab the proper SATA cable, or rig something up - a simple way for an external drive!
Edit: Aha, thanks to Mr. PS3NEWS, the link is here: http://www.ps4news.com/forums/ps3-hd...ble-39655.html (for the cable)
05-27-2009 #9Banned User
- Join Date
- Jan 2007
Good point CJPC and thanks for the link! Now where to find a very small sized SATA drive...
@idone: ok cool, thanks for the information! Now I wonder if the IV or the key or both are the ones being unique...
By the way, I thought about the cold boot attack and I don't think it would be successful... the key is probably stored in the hypervisor's SPU cache or something... afaik, it's the only solution against cold boot attacks, and Sony probably though about it...
I'd still like to know which file system is being used..
@CJPC, by the way, the debug consoles aren't encrypted, right? don't you guys have access to the whole OS's files?
Do you guys have any knowledge on how the OS's FS works? Like, what the directory structure is.. where do .pkg files get stored.. where are they extracted? Where to put a custom self for it to appear in the 'Games' section and be launchable... and all that ?