Editing Talk:HDD Encryption

= ATA keys with openssl =
<pre>
$ hexdump -C ata_data_key_seed 
00000000  d9 2d 65 db 05 7d 49 e1  a6 6f 22 74 b8 ba c5 08  |.-e..}I..o"t....|
00000010  83 84 4e d7 56 ca 79 51  63 62 ea 8a da c6 03 26  |..N.V.yQcb.....&|

$ hexdump -C ata_tweak_key_seed 
00000000  c3 b3 b5 aa cc 74 cd 6a  48 ef ab f4 4d cd f1 6e  |.....t.jH...M..n|
00000010  37 9f 55 f5 77 7d 09 fb  ee de 07 05 8e 94 be 08  |7.U.w}..........|

$ eid_root_key="...your eid root key as hex string..."
$ eid_root_iv="...your eid root iv as hex string..."

$ openssl aes-256-cbc -e -in ata_data_key_seed -out ata_data_key -K $eid_root_key -iv $eid_root_iv -nopad -nosalt
$ openssl aes-256-cbc -e -in ata_tweak_key_seed -out ata_tweak_key -K $eid_root_key -iv $eid_root_iv -nopad -nosalt

$ echo `xxd -p -u -c 32 -l16 ata_data_key` `xxd -p -u -c 32 -l16 ata_tweak_key` | xxd -r -p > hdd_key.bin
</pre>

= ENCDEC keys with openssl =
<pre>
$ hexdump -C encdec_data_key_seed 
00000000  e2 d0 5d 40 71 94 5b 01  c3 6d 51 51 e8 8c b8 33  |..]@q.[..mQQ...3|
00000010  4a aa 29 80 81 d8 c4 4f  18 5d c6 60 ed 57 56 86  |J.)....O.].`.WV.|

$ hexdump -C encdec_tweak_key_seed 
00000000  02 08 32 92 c3 05 d5 38  bc 50 e6 99 71 0c 0a 3e  |..2....8.P..q..>|
00000010  55 f5 1c ba a5 35 a3 80  30 b6 7f 79 c9 05 bd a3  |U....5..0..y....|

$ eid_root_key="...your eid root key as hex string..."
$ eid_root_iv="...your eid root iv as hex string..."

$ openssl aes-256-cbc -e -in encdec_data_key_seed -out encdec_data_key -K $eid_root_key -iv $eid_root_iv -nopad -nosalt
$ openssl aes-256-cbc -e -in encdec_tweak_key_seed -out encdec_tweak_key -K $eid_root_key -iv $eid_root_iv -nopad -nosalt

echo `xxd -p -u -c 32 -l16 encdec_data_key` `xxd -p -u -c 32 -l16 encdec_tweak_key` | xxd -r -p > vflash_key.bin
</pre>

= Getting keys the easier way =
First you need to get the sb_iso_spu_module.self individuals seed that can be found in the metadata header:

<pre>
D9 2D 65 DB 05 7D 49 E1 A6 6F 22 74 B8 BA C5 08
83 84 4E D7 56 CA 79 51 63 62 EA 8A DA C6 03 26
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
C3 B3 B5 AA CC 74 CD 6A 48 EF AB F4 4D CD F1 6E
37 9F 55 F5 77 7D 09 FB EE DE 07 05 8E 94 BE 08
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
</pre>also found in lv1ldr

Using your console specific eid_root_key/iv (e.g. from metldr dump) and libeeid you can then generate the keys directly by calling

<pre>
u8 indivs[0x100];
u8 chunk1[0x40] = {0xD9, 0x2D, /*...*/, 0x00};
u8 chunk2[0x40] = {0xC3, 0xB3, /*...*/, 0x00};
indiv_gen(chunk1, chunk2, NULL, NULL, indivs);
</pre>

Now you have your console specific ATA data key in indivs[0x00-0x20] and the ATA tweak key in indivs[0x40-0x60] :)

= About "ENCDEC IV and key" =
This key/iv pair set by metldr is your eid_root_key, it's not just used for one purpose. (-> https://nwert.wordpress.com/2012/07/11/eeid-cryptography/)

= HDD's end =

This was found at the end of an HDD backup, 41 sectors from the end, 33 sectors in size, followed by zero bytes (8 sectors)
It's very uncanny how this is formed after decryption. Maybe there's a new layer of encryption at the end of the disc?

https://dl.dropboxusercontent.com/u/35197530/hddend.bin

{| class="wikitable"
|+Sector 1 of unknown area (0x200 length)
! Chunk !! Offset !! Length !! Example !! Description !! Notes
|-
| rowspan="6" | 1 || 0x0 || 0x10 || A2A0D0EBE5B9334487C068B6B72699C7 ||  || '''partitions common key''' ?
|-
| 0x10 || 0x10 || DA7BD0E6BE941449B84EDE147F9705BA ||  || '''partition1 key''' ?
|-
| 0x20 || 0x8 || 2200000000000000 || '''partition1 start sector''' || in big endian: 22
|-
| 0x28 || 0x8 || E5513C0000000000 || '''partition1 end sector''' || in big endian: 3C51E5
|-
| 0x30 || 0x8 || 0000000000000000 || ''not used'' || 
|-
| 0x38 || 0x48 || p r i m a r y || '''partition type''' || ''identifyer'' ?
|-
| rowspan="6" | 2 || 0x80 || 0x10 || A2A0D0EBE5B9334487C068B6B72699C7 ||  || '''partitions common key''' ?
|-
| 0x90 || 0x10 || FB2718C324FC9947907A18267C30F0FE ||  || '''partition2 key''' ?
|-
| 0xA0 || 0x8 || 00583C0000000000 || '''partition2 start sector''' || in big endian: 3C5800
|-
| 0xA8 || 0x8 || FF37B60000000000 || '''partition2 end sector''' || in big endian: B637FF
|-
| 0xB0 || 0x8 || 0000000000000000 || ''not used'' || 
|-
| 0xB8 || 0x48 || p r i m a r y || '''partition type''' || ''identifyer'' ?
|-
| 3 || 0x100 || 0x80 ||  || ''not used'' || filled with zeroes
|-
| 4 || 0x180 || 0x80 ||  || ''not used'' || filled with zeroes
|}

*Notes
**divided in 4 chunks of 0x80 each
**values in the column "offsets" in the table are relative to the sector start
**partition start and end sectors are stored in little endian
**first 0x10 and second 0x10 bytes could be related to this [http://www.psdevwiki.com/ps3/Communication_Processor#De.2FEncrypt_Communication_Processor_updates (IV/HASH Note)}]