HDD Keys generating scripts

3141card said:
Don't forget that vflash region is encrypted twice.
1. 16-bit swap,
2. decrypt vflash region with ata key, (first layer)
3. decrypt vflash region again with vflash key, (second layer)

you was faster, @sandungas :)
Click to expand...
I use to edit my posts a lot, but the previous post i wrote i think sumarizes very well the info about encryption from the table in wiki, and that info was written by you, i just copyed it to the table in wiki, but because maybe i had mistakes or because this is a mess, i always have the feeling that the table in wiki is not much accurate
Some days ago i was asking here if there was some mistake in the table, and im guess im going to know now after berion reviews how works that encryptions :)
 
Success, at least with Slim. I feel stupid now... I forgot about second layer encryption... Thanks!

So to clarify, this is proper:
Code: 
cryptsetup create -c aes-xts-plain64 -d /home/mint/ps3/vflash_key_SLIM.bin -s 256 -p 8 ps3vflash /dev/dm-1

However... something is not right with this table:
http://www.psdevwiki.com/ps3/Talk:Harddrive#HDD_partitions

In my case it looks like this:
Code: 
dev_flash1 raw?  15462400
dev_flash2 FAT16  209453056
dev_flash3 FAT16  16777216
dev_flash4 FAT12  524288
dev_flash5 raw?  4194304
dev_flash6 raw?  262144

This console haven't ever see OOS/OOS+ but still I have i.e vflash6 and something definitely is there as none of them are empty.

ps3hdd_slim_all_works.png

PS: lol

ps3hdd_vflsh_deadface.png

- - -

About FAT HDD I don't know what to do. I have tried aes-cbc-essiv:sha256 with -s 256; aes-cbc-plain, aes-cbc-plain64, aes-cbc-null, with -s 192; in all combinations and still I get garbage or "device-mapper: reload ioctl on failed: No such file or directory".

I'm using https://gitlab.com/cryptsetup/cryptsetup/wikis/DMCrypt as reffering. I don't see anything like i.e aes-cbc-192 or aes-cbc-essiv:192.

Also I don't understand how to zeroed IV. Idon't see any switch related to it besides -o replacing -p.
 
Last edited:
Berion said:
This console haven't ever see OOS/OOS+ but still I have i.e vflash6 and something definitely is there as none of them are empty.
Click to expand...

ps3hdd_slim_all_works-png.13737

The confusing thing is there is a mistmatch of partition numbers with the devices names used in PS3 firmware, the ps3vflash1 in your image is a "secret" area (and mostly unknown) located in first position inside VFLASH, but you cant access it from normal firmware functions (as far i know)
The next partition is actually dev_flash (or we can talk about it with the unnofficial name dev_flash1)... so 1 is located in position 2
And the next one is dev_flash2... so 2 is located at position 3

And so on... you are carrying a displacement of 1 position when assigning numbers to them



Edit:
And something similar is hapening with primary hdd partitions
The ps3hdd2 in your image is dev_hdd0 (GameOS, variable size)
The ps3hdd3 in your image is dev_hdd1 (GameOS cache, always 2GB)
The ps3hdd4 doesnt appears in your image is dev_hdd2 (Linux, official installation)
 
Last edited:
@sandungas It must me be correct order (at least on my model) because every partition with fs can be mounted and contents properly read. So partition tables, and fs tables must be correct. Once again I have looked into table and well, it is fit I think (judged by size and fs). Just only order is not the same but mapper names fiting.

vflash1 ("dev_flash0")
vflash2 (dev_flash)
vflash3 (dev_flash2)
vflash4 (dev_flash3)
vflash5 ("dev_flash4")
vflash6 ("dev_flash5")
vflash7 ("dev_flash6") missing
Code: 
mount -t ufs -o ufstype=ufs2,ro /dev/dm-2 /home/mint/ps3/dev_hdd0
mount -t vfat /dev/dm-3 /home/mint/ps3/dev_hdd1
mount -t vfat /dev/dm-6 /home/mint/ps3/dev_flash1
mount -t vfat /dev/dm-7 /home/mint/ps3/dev_flash2
mount -t vfat /dev/dm-8 /home/mint/ps3/dev_flash3
I would love to compare with FAT HDD but I cannot figure out what am I doing wrong (it also should be vflash as CECHL is NOR model type).

Maybe dev_hdd4 only appear when something is installed on HDD for OOS? The same with dev_flash6?

It is a shame that still there are secrets even on such matter like mass storage. I'm very curious what Sony exactly did with eMMC and if they again changed algos or somehow obfuscate keys. I hope one day we will be able to run homebrew with the same privileges like on CFW.
 
Last edited:
Berion said:
@sandungas It must me be correct order (at least on my model) because every partition with fs can be mounted and contents properly read. So partition tables, and fs tables must be correct. Once again I have looked into table and well, it is fit I think (judged by size and fs). Just only order is not the same but mapper names fiting.
Click to expand...
I made a mistake in my previous post, but yes, is like what you posted and your driver is displaying them fine, is just the names are confusing
And btw, if i remember right... the device names "dev_flash5" and "dev_flash6" doesnt exists in official firmware, the way is accessed to them is by other means but not using that names, and the name "dev_flash4" (used by petitboot) im not really sure if exists either
So in plain words is something like this:

ps3vflash1 (unknown)
ps3vflash2 (dev_flash)
ps3vflash3 (dev_flash2)
ps3vflash4 (dev_flash3)
ps3vflash5 (dev_flash4 ?)
ps3vflash6 (no_gameos0)
ps3vflash7 (no_gameos1)

Berion said:
Maybe dev_hdd4 only appear when something is installed on HDD for OOS? The same with dev_flash6?
Click to expand...
Yes, dev_hdd2 only exists if you made a official otherOS installation (not the unnofficial otherOS++ installation that is different) in a old firmware when it was officially supported

If i remember right, there is an unnofficial way to do a linux installation in dev_hdd2, but this only available for FATS with NAND and using a special petitboot ? (im not sure)

Berion said:
It is a shame that still there are secrets even on such matter like mass storage. I'm very curious what Sony exactly did with eMMC and if they again changed algos or somehow obfuscate keys. I hope one day we will be able to run homebrew with the same privileges like on CFW.
Click to expand...
I think with eMMC is going to be the same but "the other way around", lol... i mean...
In PS3 models with NOR flash we have a "virtual flash" inside hdd. So in PS3 models with eMMC most probably we have a "virtual hdd" inside flash
And technically a eMMC chip have a NAND flash inside, so i think is going to be pretty similar to PS3 FAT models
Actually, i remember at the first days of the ps3exploit with the webkit exploit nobody knew how to access the "flash" area of eMMC and after a few days the solution was to use the same access path than old PS3 FATS... this means the LV2 of the PS3 firmware (or other external layer of the onion) doesnt really knows the flash type, only acceses the "flash" by his name but the real work of mapping devices is made at a deeper level (by the hypervisor probably)

And yes, is a shame we are missing a lot of details of the hdd map, i always was interested in that "secret" first partition inside VFLASH, because is big (15mb), and it have the same exact size than the "ps3nflashb" area of the real NOR chip. So it looks like a "mirror" of the real flash chip, hmmmm
My guess is used in some intermediate step of firmware installations (as a temporal backup), or to prevent corruption problems... or dunno... but is interesting for sure... sony is not going to reverse 15mb for no reason ;)
Is important, and maybe there is some surprise inside it, and maybe could unlock some handy "hack" ;)

Another thing i was interested to map are the "gaps" in between partitions, are useless areas and very small, but the point is are "out" of the gameOS access and we can use them to store info in them (as example... the EID/HDD/VFLASH/ATA keys needed to decrypt other areas ;))
Also, because completionism... i would like to know how that gaps are used to "align" the partitions that comes inmediatly after every "gap"
This details are needed to be known it at some point we want to rebuild partitions in PC
 
Last edited:
@sandungas My bet is a NOR backup used by service dongles as rescue media (dual fw hack would be niiiiiiiice ^^). It would be also nice to know if it even changed (like i.e after reflash real NOR) but I don't have time for that.

Gaps are also interesting. Worth a check if they contain per console stuff or are the same for others (I didn't check if they are empty padding or something else).

Yeah, PC tool could gave us great freedom.
 
Berion said:
@sandungas My bet is a NOR backup used by service dongles as rescue media (dual fw hack would be niiiiiiiice ^^). It would be also nice to know if it even changed (like i.e after reflash real NOR) but I don't have time for that.

Gaps are also interesting. Worth a check if they contain per console stuff or are the same for others (I didn't check if they are empty padding or something else).

Yeah, PC tool could gave us great freedom.
Click to expand...
The idea of storing keys in the gaps should only work if that gaps are not encrypted btw
Imagine, you write the keys in one of that gaps and after that your driver could search for them (in a predefined location we could use as the unnofficial place to store them)
And after you prepare it is just "plug and play" in PC, no need to enter the keys by command line because are already inside the hdd in "plain readable" format ;)

I guess the best place to store this keys is at the first sectors (before sector 9), inmediatly after the official main hdd partition table
 
Last edited:
Fantastic idea to be honest.

Encryption is made per block, not per partition or some long chunk so could be possible to abuse this if it is real only a padding. But to keep backward compatibility with NAND models cannot be done that way. I don't know the details about partition table structure but if there is indeed some space not used and equal or larger than 32B that would be the best place.

And doing format on PS3 will probably wipe this out. :D

PS: fun fact: If You give PS3 MBR with NTFS, she will leave some data unencrypted. If disk is empty, she encrypt all space*. But why then PS3 HDD Reader read it without problems?

*I preparing my FAT to be selling and I have everything wipeout + twice wrote OFW 3.55. Now I see everything is encrypted but before I have some data from NTFS table (some Windows junk with Polish names, probably meta header from EFS hidden partition). Strange, but for proof of my words, few years ago I gave @zecoxao 10MB dump from it and he said it is not PS3 HDD dump, and then he said my PS3 is f*ed (those times we don't know that FAT uses different algorithms). But this HDD works ok with my PS3 and I'm not stupid to mislead device point to make dump from something else by accident. ;)
 
Last edited:
Berion said:
Fantastic idea to be honest.

Encryption is made per block, not per partition or some long chunk so could be possible to abuse this if it is real only a padding. But to keep backward compatibility with NAND models cannot be done that way. I don't know the details about partition table structure but if there is indeed some space not used and equal or larger than 32B that would be the best place.
Click to expand...
The official hdd partition table only needs 1 sector (the first on the hdd), but are reserved 8 sectors
What i dont know is how many of that 8 are considered the real partition table, the first one for sure belongs to the partition table, but the next 7 maybe are not
Or maybe the first 4 are reserved for the partition table, and the next 4 is just a "gap" to align the next partition
If i remember correctly all this sectors are filled with zeroes, so is not posible to know by looking at the data in the hdd

Berion said:
And doing format on PS3 will probably wipe this out. :D
Click to expand...
I guess by formatting the hdd in PS3 all data is going to be overwriten, but maybe not, incase the "old" partition table matches with the "new" partition table (because is the same hdd, and that info already existed in it) then there is no needed to rebuild partitions (it should be enought with rebuilding filesystems)

Berion said:
PS: fun fact: If You give PS3 MBR with NTFS, she will leave some data unencrypted. If disk is empty, she encrypt all space*. But why then PS3 HDD Reader read it without problems?

*I preparing my FAT to be selling and I have everything wipeout + twice wrote OFW 3.55. Now I see everything is encrypted but before I have some data from NTFS table (some Windows junk with Polish names, probably meta header from EFS hidden partition). Strange, but for proof of my words, few years ago I gave @zecoxao 10MB dump from it and he said it is not PS3 HDD dump, and then he said my PS3 is f*ed. ;). But this HDD works ok with my PS3.
Click to expand...
Yep, that experiments are needed to be made, storing some "control data" in the gaps and formatting the hdd in PS3 to see how many of the "control data" inside the "gaps" survives the format
 
Last edited:
@sandungas
The reason for the slack space are, regions have to start at a certain alignment, don't remember, to long ago, maybe 16 or 32 sectors.
The idea of store the eid root key in such a place is old, best is a CFW do this automatic. The reader can be changed, to look first on this place.
 
The minimal gap size seems to be 8 sectors (8 * 0x200 bytes each sector = 4096 bytes in decimal)
I dont remember to calculate to how many sectors are aligned the partitions, but is a multiple of 8 sectors for sure (and i guess this is why there are 8 sectors together with the main hdd partition table on the first sector of the hdd)
It looks a bit like... if a "page" is composed by 8 sectors, and the PS3 firmware is accessing the hdd data "by pages"

And it could be nice if a tool like the EID_rkey_dumper released by flatz (or rebug toolbox) could write the keys in one of the gaps of hdd. This would automatize the process, is more "noob friendly" :)

The linux driver could identify and decrypt PS3 hdds automatically following this procedure:
-new device detected
-read x bytes from x sector (in raw)... and if control info is found (as example, the bytes 0x1337133713371337 at the start of the sector)... then mount whole hdd with the crypt driver (by using the keys stored in that same sector)
 
Last edited:
I cannot figure this up. I have read tons of documentation and nothing works.

So... As I understand, HDD key is 32B and contain 24B of Data and 16B of IV. If key is 32B long, we using 256bits, 24B means 192 and 16 means 128.

So... If FATs uses AES-CBC-192 with zeroed IV, this means we need to use "-s 192". If we using 192, we cannot use "aes-cbc-essiv:256" so it only left "aes-cbc-plain64". But this doesn't work.

If FAT for VFLASH uses only 16B of vflash_key.bin this means we need use "-s 128". Like above, essiv mode cannot be used in such case. If VFLASH is encrypted once, then we don't need to decrypt "normal" partitions first, right? And the same rule like for slims, must be skiped by 8 bytes (so we need to use "-p 8"). But this also doesn't work.

I see only few reasons:
case 1. key generation is not the same for FAT and SLIMS.
case 2. there is needed another switch for cryptosetup (--hash ?)
case 3. it is not AES CBC 192

None of those cases are the ones I could check due to lack of knowledge.

BTW: There is mistake in dev wiki. Slims VFLASH is encrypted twice but first by ATA key, and then ENDEC key, not otherwise. If wiki info would be correct, I wouldn't decrypt vflash partitions (any partitions). Or maybe this is true for any other PS3 models than CECH-2504.

So... I gave up. I don't know what to do now. :(

Below are examples which should work for FAT:
Code: 
cryptsetup create -c aes-cbc-plain64 -d /home/mint/ps3/hdd_key_FAT.bin -s 192 ps3hdd /dev/nbd0
cryptsetup create -c aes-cbc-plain64 -d /home/mint/ps3/vflash_key_FAT.bin -s 128 -p 8 ps3vflash /dev/nbd0

Below are examples which WORKS for SLIMS, just for comparsion:
Code: 
cryptsetup create -c aes-xts-plain64 -d /home/mint/ps3/hdd_key_SLIM.bin -s 256 ps3hdd /dev/nbd0
cryptsetup create -c aes-xts-plain64 -d /home/mint/ps3/vflash_key_SLIM.bin -s 256 -p 8 ps3vflash /dev/dm-1

Below is key generation script from "eid_root_key.bin".
Code: 
#!/bin/bash
erk_data=$(xxd -p -u -c 32 -l 32 "eid_root_key.bin")
erk_iv=$(xxd -p -u -c 16 -s -16 "eid_root_key.bin")
echo "0: D92D65DB057D49E1A66F2274B8BAC508" | xxd -r > 1.tmp
echo "0: 83844ED756CA79516362EA8ADAC60326" | xxd -r > 2.tmp
echo "0: C3B3B5AACC74CD6A48EFABF44DCDF16E" | xxd -r > 3.tmp
echo "0: 379F55F5777D09FBEEDE07058E94BE08" | xxd -r > 4.tmp
echo "0: E2D05D4071945B01C36D5151E88CB833" | xxd -r > 5.tmp
echo "0: 4AAA298081D8C44F185DC660ED575686" | xxd -r > 6.tmp
echo "0: 02083292C305D538BC50E699710C0A3E" | xxd -r > 7.tmp
echo "0: 55F51CBAA535A38030B67F79C905BDA3" | xxd -r > 8.tmp
cat 1.tmp 2.tmp > ata_data_seed.bin
cat 3.tmp 4.tmp > ata_tweak_seed.bin
cat 5.tmp 6.tmp > encdec_data_seed.bin
cat 7.tmp 8.tmp > encdec_tweak_seed.bin
rm *.tmp
openssl aes-256-cbc -e -in "ata_data_seed.bin" -out "ata_data_key.bin" -K $erk_data -iv $erk_iv -nopad -nosalt
openssl aes-256-cbc -e -in "ata_tweak_seed.bin" -out "ata_tweak_key.bin" -K $erk_data -iv $erk_iv -nopad -nosalt
openssl aes-256-cbc -e -in "encdec_data_seed.bin" -out "encdec_data_key.bin" -K $erk_data -iv $erk_iv -nopad -nosalt
openssl aes-256-cbc -e -in "encdec_tweak_seed.bin" -out "encdec_tweak_key.bin" -K $erk_data -iv $erk_iv -nopad -nosalt
adk=$(xxd -p -u -c 32 -l 16 ata_data_key.bin)
atk=$(xxd -p -u -c 32 -l 16 ata_tweak_key.bin)
edk=$(xxd -p -u -c 32 -l 16 encdec_data_key.bin)
etk=$(xxd -p -u -c 32 -l 16 encdec_tweak_key.bin)
echo "$adk" "$atk" | xxd -r -p > hdd_key.bin
echo "$edk" "$etk" | xxd -r -p > vflash_key.bin
 
@sandungas This doesn't work for me either. I have replaced last 8 and in second test last 16 bytes by zeroes in HDD Key and test on aes-cbc-plain64 with 192 and 128 regardless but still I getting junk data not decrypted data. I also check aes-cbc-essiv:256 with 256 also on both cases but still junk data.

Information on wiki about encrypting only once VFLASH must be incorrect if it is aes-xts-plain64 with 256.

I attached my 512KB dumps of HDD + keys. Could You guys look at them and try to decrypt?
 

Attachments

Last edited:
I posted the link where 3141card made a list with encryptions.... because the info about decryption in the table in wiki is based on that, i just copyed to the wiki table what 3141card said in that post
So either... both are right (what 3141card posted and the table in wiki), or both are wrong
I tend to think both are right though

I cant verify it though (this is one of the reasons why the table is still in the "talk" page instead of the "frontpage"), im not used to encryption
 
Last edited:
I don't think @3141card mistake or something, I just point that this doesn't work for me. For some reason. Maybe then cryptsetup doesn't do something right, I dunno.

I'll try use my ERK and his minion HDD with latest version of HDD Reader, but I remember that in the past I read dev_hdd0 and works, and dev_flash2 doesn't.
 
I was looking at this page (for other reasons), and noticed there are 2 device names a bit weird related with flash
http://www.psdevwiki.com/ps3/Devices

RFLASH and EFLASH

Im wondering if one of them is the unknown area located inmediatly before VFLASH
In other words, the ps3vflash1 with size 14.8M in your screenshot
ps3hdd_slim_all_works-png.13737
 
I found some Linux distro on VM with script using cryptosetup aes-cbc-null with 192, which have sense. ^^ But still, it doesn't works for me... This must means that i.e HDD Keys generating methods for Fat and Slims are different. So where I made mistake? Could someone help me solve this puzzle, i.e reading how ENCDEC Emulator doing this on the fly? ;)
 
Berion said:
I found some Linux distro on VM with script using cryptosetup aes-cbc-null with 192, which have sense. ^^ But still, it doesn't works for me... This must means that i.e HDD Keys generating methods for Fat and Slims are different. So where I made mistake? Could someone help me solve this puzzle, i.e reading how ENCDEC Emulator doing this on the fly? ;)
Click to expand...
If you mean Fat PS3 with nor then encdec doing this (while decrypt):

Code: 
//Set key for AES-CBC
                    aes_setkey_dec(&aes_ctxt, edec_k1, 128);
                    //Decrypt CBC sector.
                    memset(zero_iv, 0, 0x10);
                    aes_crypt_cbc(&aes_ctxt, AES_DECRYPT, SECTOR_SIZE, zero_iv, (buffer + (SECTOR_SIZE * i)), buffer + (SECTOR_SIZE * i));
                    //XOR initial block in sector with sector index value.
                    buffer[(SECTOR_SIZE * i)+0x8] ^= ((u64)((position / SECTOR_SIZE)+start_sector + i) >> 56 & 0xFF);
                    buffer[(SECTOR_SIZE * i)+0x9] ^= ((u64)((position / SECTOR_SIZE)+start_sector + i) >> 48 & 0xFF);
                    buffer[(SECTOR_SIZE * i)+0xA] ^= ((u64)((position / SECTOR_SIZE)+start_sector + i) >> 40 & 0xFF);
                    buffer[(SECTOR_SIZE * i)+0xB] ^= ((u64)((position / SECTOR_SIZE)+start_sector + i) >> 32 & 0xFF);
                    buffer[(SECTOR_SIZE * i)+0xC] ^= ((u64)((position / SECTOR_SIZE)+start_sector + i) >> 24 & 0xFF);
                    buffer[(SECTOR_SIZE * i)+0xD] ^= ((u64)((position / SECTOR_SIZE)+start_sector + i) >> 16 & 0xFF);
                    buffer[(SECTOR_SIZE * i)+0xE] ^= ((u64)((position / SECTOR_SIZE)+start_sector + i) >> 8 & 0xFF);
                    buffer[(SECTOR_SIZE * i)+0xF] ^= ((u64)((position / SECTOR_SIZE)+start_sector + i) & 0xFF);

While for Slim, only:

Code: 
//Init AES-XTS context.
                    aes_xts_init(&xts_ctxt, AES_DECRYPT, edec_k1, edec_k2, 128);
                    //Decrypt XTS sector.
                    aes_xts_crypt(&xts_ctxt, (u64)((position / SECTOR_SIZE) + i + start_sector), SECTOR_SIZE, (buffer + (SECTOR_SIZE * i)), buffer + (SECTOR_SIZE * i));

Looking at code for phat it is AES-CBC 128 for VFLASH. Or I messed something :/

This code looks like Phat with vflash use AES-CBC 128 with encdec key1 (and xoring) (vflash) + AES-CBC 192 with ata key 1 (ata)
Zero iv in both o_0
 
@kozarovv Well, I have in mind what this application doing with EID Root Key input file, not how to decrypting blocks etc. on encrypted device. ^^ I have asked @zecoxao himself but he must changed email or ignoring me.
 
You must log in or register to reply here.

Similar threads

Back
Top