All HDD models used in retail PS3's are 2.5" size and 9.5 milimeters height max, with 1 platter (and 1 or 2 heads), the platter has a rotational speed of 5.400 rpm and 512 bytes per sector

The maximum capacity supported by PS3 is 1TB (TeraBytes) note: this seems untrue as there are several people posting pictures of their external to internal drive mod with a size of 2TB, but so far no one has been able to confirm that, only to debunk it as fake. See/use the talk page for discussions/testreports

Is connected internally to South Bridge wich contains ENCDEC device to manage AES-CBC-128/AES-CBC-192/XTS-AES-128 encryption/decryption, and a SATA-150 controller with a maximum transfer speed of 1.5 Gb/s.

GameOS partition

Is an UFS2 256-bit file system with a sectorsize of 512 bytes (4096 bits).

Because is perconsole encrypted, it is not possible to read out the data on it with another console (it will just ask to reformat it, to set it to its own perconsole encryption, hence emptying the drive)

To read/write data out in Linux, BSD, Windows, Mac OS X its needed to use the specific perconsole "ATA tweak" and "ATA data" keys. See Harddrive encryption and HDD_Encryption

In some newer PS3 models (like CECH-40xxA 12GB) the internal harddrive has been replaced by a Flash

XTS-AES-128 means that there are 2 keys of size 128bit actually, the one for tweak encryption and the other for data encryption.
Both keys are different on each PS3 console and can be easily dumped e.g. with modified sb_iso_spu_module.self.
These 2 keys are sent to ENCDEC device which performs HDD encryption/decryption. HDD keys are NOT stored in EID4..
On PHAT consoles the only data key is used with zeroed IV.

Currently i'm able to decrypt my PS3 HDD on PC and i can also talk to the ENCDEC device without isolated SPU modules.

To be able to talk to the ENCDEC device, you have to extract 2 AES-CBC keys and one magic e.g. from sb_iso_spu_module.self .
First, the 2 AES-CBC are used to establish a secure session between the host and the ENCDEC device. The host and the ENCDEC
device exchange 2 random numbers and derive a session key from these random numbers. The session key is then used to encrypt the actual command sent to the ENCDEC device from the host. A command can e.g. set ATA keys.

Dumping ATA keys (128bit tweak and 128bit data key) is easy, i did it on PS3 Linux with my spuisofs driver and a modified
version of sb_iso_spu_module.self. ATA keys are passed as parameters to this module and i just copied them with MFC DMA to PPU memory
and stopped the execution of the SPU.

Savegames in PS3 format and trophies are linked to the console/user by using his PARAM.SFO... if you look in this table Requirements for HDD contents in his respective columns, the critical param_keys that needs to be taken in consideation when importing/exporting to another account or console are: ACCOUNTID, ACCOUNT_ID, PARAMS, and SAVEDATA_LIST_PARAM
There are several scenarios for importing exporting in the same or other console, between accounts, between registered and not registered PSN accounts, etc... One scenario that deserves a mention because the simplicity is when you replace the HDD, your account is not registered in PSN, and your PS3 uses a NOR flash

PS3 accounts not registered in PSN uses an account id filled with zeroes (thats normal, and is taken as a real number by the system), and trophies are only linked to ACCOUNTID !!!. If your source and target accounts are not registered in PSN you can simply paste the old trophy folders in the new account (dev_hdd0/home/<any_user_id_here>) in your new HDD and "rebuild database", thats all. You can use the same "trick" to transfer trophies between accounts in the same or other console if none of them are registered in PSN (yes, all the PS3 CFW users of the world not registered in PSN can share his trophies just by copypasting files)

For gamesaves the ACCOUNT_ID is also used, but like explained above (because in this example the source and target accounts are not registered in PSN) this is not a problem, the problem here are the contents of PARAMS and SAVEDATA_LIST_PARAM

Actually, are not a problem in all cases because chances are high that all values matches, but usually what changes is the "User ID" assigned to the account the first time it was created (you know... this 00000001 folder that was assiged to the first user you created inside dev_hdd0/home/<user_id_here>/), This number is a counter that always increases (even when you erase users it will not decrease) is stored inside xregistry.sys, and inside the gamesaves in the PARAMS

Probably you need to change this number to match the new account, so after replacing the HDD and creating a new account is a good moment to keep this account number 00000001 and modify all the saves to match the 00000001 inside his PARAM. The other known values inside PARAM doesnt need to be changed (because we are importing/exporting in the same console, so "PS3 console ID" is the same)... only is needed to change this when moving the save to another console

All this tasks are simple edits in the PARAM.SFO file... you could even make it with a hexeditor if you are used to .SFO format, to simplify it you can use some .SFO editor (one that allows to change this values) or one gamesave editor

Trophies and PS3 saves are protected by .PFD files so in case you modifyed one of the .SFO then you need to "update" the list of protected files inside the .PFD (because PARAM.SFO is always in the list). When you update the .PFD the new PARAM.SFO is added to the list and this makes the whole gamesave folder/files "valid" and ready to be copyed in PS3. Is also needed to use the option "rebuild database" at the end of the process

The PFD "update" is one of the commands inside "flatz pfd tools", it returns some info about the protected files inside the table with an "OK" at the end of each line when everything is fine.

Notes

Part of the contents of PARAMS and SAVEDATA_LIST_PARAM are still unknown, (is awesome how some people that uses/codes savegame cheat apps are still ignoring this... and im not talking about flatz, his purpose was to break the .pfd security to unlocking/transfering protected user files between legit offline accounts and no cheating purposes) --Sandungas (talk) 02:40, 28 January 2014 (EST)

Is PS3's with NOR xregistry.sys is stored in "Virtual flash" (a partition in HDD)

In the case of NOR when replacing/formatting the HDD you are deleting the file, so is generated at next boot (and filled with the user info the first time you create a new user, that will be assigned the "account id" 00000001). This is not bad, actually is a good way to "cleanup" the xregistry.sys because the PS3 will generate a "fresh one" from scratch (usually xregistry.sys contains lot of areas marked as "not used" from old users that was erased, other old data, the annoying user counter that always increases, and even errors)

Is PS3's with NAND xregistry.sys is stored in "NAND flash"

In the case of NAND when replacing/formatting the HDD you keep the file with the old users info, the user counter increasing, etc... i dont know a good/efective/simple way to regenerate it --Sandungas (talk) 02:15, 28 January 2014 (EST)

For compatibility, if you have a SATA-300 (sometimes called SATA-II or SATA2) or SATA-600 (sometimes called SATA-III or SATA3) harddrive, you should sometimes set the harddrive via jumper to enforce the slower SATA-150 speed, instead of default 3 Gb/s of SATA-300 / 6Gb/s of SATA-600.

Step-by-step guide

Download the FULL version of FW you currently have on the old harddrive and put it on a USB Mass Storage Device formatted with FAT32 in \PS3\UPDATE\PS3UPDAT.PUP

If you wish to transfer your installed games, savedata, DLC/PSN, /Photo, /Music, /Video, bookmarks etc. you can use Backup / Restore BEFORE you exchange the harddrive. You’ll need a FAT32 formatted External Drive for that (with enough free space). The backups will be stored in \PS3\EXPORT\BACKUP\ in a subfolder with the backupdate/time as name and in there several DAT files (archive.dat, archive_00.dat, archive2.dat and archive2_[4GBSPLITNR].dat etc.) This same drive can be used to store the FW mentioned earlier)

Disconnect the LAN/UTP cable and remove all discs from the BD-drive, to disable the possibility that another firmware gets downloaded/installed

Power Off the PS3 (disconnect the power cable) and open the HD tray (left/bottom) to exchange the original 2.5″ drive for the newer/larger/faster one (remark: use max. 9.5mm height drives).

Remark: The screws which are used to mount the internal hardisk in the PS3 HD-tray are made of soft aluminium. Use a good fitting screwdriver, or you’re bound to abuse the “X” bithole and must resort to flat pliers to get the screws out.

After everything is in place, insert the USB Mass Storage Device you prepared earlier and power ON the PS3. The new HD is detected and the PS3 wants to format it. Select YES and wait until format is finished. After that you can select Update to select the FW on the USB Mass Storage Device (in case it didn’t already do that automaticly after format).

After succesfull format and installation of the System Software / Firmware, reboot and check in XMB System Information to see which FW is currently used and how much is usable for the XMB.

Note: Copy-protected saved data cannot be restored. Also, saved data that has been restored may not be usable in some games. Trophies are not backed up by the XMB Backup Option!

Exchanging the internal drive to a 7200RPM model doesn’t do much for your loading times (shaves off a second or 2), hybrid SSHD are a bit more future proof while still lowcost, but upgrading to SSD/Flash Drives is almost insane considering the prices you pay per GB. Any modern larger drive is always faster than the older default smaller drive.
Some people are arguing that SSD/Flash Drives produce "much less heat" but consider this: a very good/efficient one uses 5V 0.35A 1.75 Watt while a harddrive uses 5V 0.85A 4.25 Watt. A difference of 2.5W less on a total of 225Watt is not something you would see prominently back on your electric bill or thermometer.

There is even report of SDD's sometimes having a negative impact on performance, compared to the original PS3 harddrive. Example: Corsair CSSD F240GBGT BK - which seem to have 4KB sectors (cause?)

Because of the low price/ high storage capacity I personally always go for SATAII/300 7200rpm drives (if internal, maximum height is 9.5mm, 12 or 12.5mm doesn’t fit) and if modified to external via eSATA you can even use cheaper/faster 3.5″ drives (but you’ll need them to have their own powersupply because the internal PS3 powersupply can’t power that safely).

The PS3 also supports external harddrives connected to the USB port (identified as USB Mass Storage device) using only FAT12/16/32 file systems format. File systems like UFS/UFS2, EXT3/EXT4, which are natively used on internal harddrive cannot be used on external on a non-modified system. You can format it to any size up to 8TB *, which is the theoretical drive size limit of FAT32. There have been verified success of 2TB external harddrives working with the PS3. The whole drive needs to be formatted into a single 2TB FAT32 partition using special software tools like fat32format.exe that can handle large drives. Note that FAT32 supports a maximum file size of 4GB.

*FAT32 restrictions:

max amount of files: 268,173,300

max filesize: 4,294,967,295 Bytes

max cluster size: 32K practical, 64K with high incompatibility (PS3 and Xbox360 will accept it, but most applications will not).

performance consideration: with a 8TB volumesize, the file allocation table itself will be 1GB, not really practical (it is 256MB at a 2TB volumesize, which is still a lot larger than ps3 memory thus negatively impacting on performance).