Decrypting the PS3/HDD Pairing Ideas

[iUnknown]

Come on... How could Partition Magic read an ENCRYPTED drive ? Do you have any idea what you're talking about ?

I think he meant that Partition Magic was reading the Linux partition of the drive (he installed 'another OS' on the PS3), that's most likely what it picked up.

...
This should give us the answer to the HDD serial number.

But with my experience in encryption, I believe sony wouldn't have tied it down to the hdd itself.

In fact - They must be using the motherboard SN as well as (maybe the BBE chip) to marry the HDD to the board...

Right, but it must have a variable component to it as well (since the HDD/Mobo serial would be constant).

For example, I can take the same PS3 and format two HDDs, but if I try and put the first one back in, it doesn't pair up, meaning the PS3 either stores a single key to use time and time again (which is why it doesn't recognize the first HDD) or it incorporates a variable 'piece' of the key into each 'pairing' operation. At any rate, it needs to store this 'variable' info internally in order to recognize its matching HDD.

Going back to the idea of having the PS3 perform the same writing operation on multiple HDDs (or fake partitions), the pieces containing the HDD/mobo/etc serial should produce a familiar pattern each time, allowing the variable component to be isolated.

My thinking could be too much of a pie-in-the-sky idea though...

*Sorry, couldn't edit the post (I guess I was too late)

...the pieces containing the HDD/mobo/etc serial should produce a familiar pattern each time, allowing the variable component to be isolated.

What I meant to say was not necessarily 'each time' but if it repeated a pattern more than once (say on the 20th time), then you could theoretically isolate the variable component by analyzing the difference between the two (the difference being the variable piece)

[RexVF5]

And this is part of where I was heading with my previous post.

The PS3 seems to come up with multiple unique keys per HDD. Having said that, as Rex mentioned, the OS is never really aware of them (when accessing the HDD). As I don't think anyone knows how the PS3 generates the keys (otherwise I assume we wouldn't be talking about this) I'm wondering if there is a limit to the unique keys it generates.

Part of why I was curious about monitoring the output of the SATA port on the PS3 to sniff out some patterns and see if the HDD layout would be duplicated after X number of times (insinuating the same key has been used more than once, assuming we're writing the same information to the HDD each time). I would guess this would give us a lead but as CJPC mentioned, probably take forever.

The layout of the HDD is known - it is commonly used *nix filesystem (can't remember which now - search some posts) - it is just each sector is encrypted.

Sniffing the HDD won't help you. How should I describe it? Here's a simple example: let's assume first sector of that filesystem in unencrypted form is all ones (1). Let's assume that the encryption key is just one number - different for each console. And finally let's assume the encryption is just adding the encryption key to the raw data. In case of the first encrypted sector you'd end up with a sector filled with (encryption_key + 1). Now imagine you insert a drive from another console. How does your console verifies it can use the disk? Well it just reads the first sector, the HDD driver subtracts your console's encryption key from each byte it reads (i.e. attempts to decrypts the data). If it ends up with all ones it can accept the disk. In case the result is different the disk is unreadable - the console won't recognize the filesystem at all and will ask you to format it.

This way the encryption key is never written to the disk directly - it is just used to encrypt the data. The example is over-simplified: if you knew at least one byte of decrypted data you could deduce the encryption key. In reality the encryption operation is not for each byte - it is a block cipher (AES presumably) that is hard to break even when you know pairs of encrypted and decrypted data...

So forget about the idea that the key needs to be written onto HDD. It just doesn't - if you know some property of the decrypted data (like how the first sector of the filesystem looks like or for example the checksum) there is no need to store the encryption key with it - you just try to decrypt the data offered and check that property. In case someone elese encrypted the data the property check will fail...

[wakababy]

Yeah, and im fairly certain most modern consoles implore that type of protection scheme on HDDs.

[skrapps]

hey guys, im not too knowledgeable when it comes to encrypting and decrypting. but is it possible to somehow connect 2 sata drives via a "y" connector, and seeing if the ps3 will only send decryption data to one of the drives connected, or 2 different keys, one for each drive. if so maybe it will dump the key onto the formatted drive that doesnt have the firmware on it? something along those lines. sorry if it doesnt work that way, just tryin to help out a little.

[ionbladez]

Right, but it must have a variable component to it as well (since the HDD/Mobo serial would be constant).

For example, I can take the same PS3 and format two HDDs, but if I try and put the first one back in, it doesn't pair up, meaning the PS3 either stores a single key to use time and time again (which is why it doesn't recognize the first HDD) or it incorporates a variable 'piece' of the key into each 'pairing' operation. At any rate, it needs to store this 'variable' info internally in order to recognize its matching HDD.

Going back to the idea of having the PS3 perform the same writing operation on multiple HDDs (or fake partitions), the pieces containing the HDD/mobo/etc serial should produce a familiar pattern each time, allowing the variable component to be isolated.

Exactly what I meant, each motherboard and the components have an individual serial number, they are never the same on different units.

Of which, this would be your variable. All PC motherboards, of the same make/model have their own SN. They wouldn't put the same number on 2 boards, then anyone could install a copied version of XP to the computer.

Even with all the same specs - a pc always has a difference SN. this includes STOCK and OPTIONS.. Because of that - no system is exactly the same.

Also, the BBE also generates these keys before anything touches the NAND.
They aren't random, or they could be, but of what we have so far here is that they are using the board SN AND/OR BBE SN.

[crax0r]

Hello,

I'm not sure if this has been tested but can someone with more experience comment my idea?

1. take out hdd, plug to pc, create full image
(make sure hdd its not filled with crap, just clean formatted hdd with 1 or 2 games you want to edit)
2. trim down the saved image, cutting down all crypted-zero-sectors from the end of it
3. now you have optimized image of crypted hdd
4. create a file filled with zeros of exact size as your hdd image and put it to some 16gb mem stick or so
5. plug hdd and mem stick back to console
6. copy empty file to ps3 hdd in music menu
7. take out hdd and plug to pc
8. locate where the zero file has been crypted to
9. replace all sectors of crypted zero file with previously optimized full hdd image
10. plug hdd back to console and copy the file from music menu back to the usb stick
11. plug usb stick to pc, viola, fully decrypted image of the hdd
12. play around, change things (edit some sfo file for example)
13. after you're done with changes, you can treat modified image as zero file previously and repeat steps to get it crypted
14. after having the datas crypted again, you can write them directly starting from sector 0 again to the ps3 hdd, and boot modified partition(s)

~comments?~

[DSpider]

1. take out hdd, plug to pc, create full image
(make sure hdd its not filled with crap, just clean formatted hdd with 1 or 2 games you want to edit)

You mean a raw image, right ? Because apparently PCs don't recognize the HDD and asks you to format it as soon as you plug it in. Clean formatted, yes... 1 or 2 games, no. The PS3's firmware is on the HDD. Let's start with that first.

2. trim down the saved image, cutting down all crypted-zero-sectors from the end of it
3. now you have optimized image of crypted hdd

HDD encryption doesn't work that way. From my experience with TrueCrypt (an open source program), by encrypting an entire drive you ALSO encrypt the free space. So let's say you have a 40 GB HDD with only 300 MB on it. The disk image will take up 40 GB. I'm not sure if it's the same for the PS3. This should be checked.

9. replace all sectors of crypted zero file with previously optimized full hdd image
10. plug hdd back to console and copy the file from music menu back to the usb stick

I'm not sure what you meant by that.

[the wire]

If you want to remove the hdd decryption layer simply use NDT's HDD Studio tool, although you'll need your ps3 to use it.

[crax0r]

HDD encryption doesn't work that way. From my experience with TrueCrypt (an open source program), by encrypting an entire drive you ALSO encrypt the free space. So let's say you have a 40 GB HDD with only 300 MB on it. The disk image will take up 40 GB. I'm not sure if it's the same for the PS3. This should be checked.

I know how PS3 hdd encryption works (AES-CBC-128bit/512bytes), that's why I called those sectors "crypted-zero-sectors"
I'm getting a small SSD SATAII hdd and I'll try this trick & post my findings here!

By the way, has anyone tried delaying write command to the hdd, in a way PS3 drive thinks the hdd has been put into a "sleep mode", and while that happens, make a power-switch instant shutdown and try cold-boot attack on the ram memory, to find AES key and the CBC modifier (used in hdd encryption) ?

[ionbladez]

The cold-boot attack attempts have been thwarted in the first place.

BBE completely stops access to the NAND and ram during boot.
It's pretty much the first thing the system does before it even loads the XMB.