PS3 [Tutorial] HDD mounting and decryption on Linux

I made infographic with logic structure scheme. It is less detailed than one on dev wiki but better showing most important info for end user I think.

PS3 HDD logic structure scheme.png

  • Above scheme is for NOR models.
  • NAND models just don't have VFLASH so imagine them without violet and purple stuff. ;)
  • Internal flash of eMMC models are completely unknown.
  • Models with NOR memory but on which cannot be retrieved ERK, are also unknown but high probably they are the same as other NORs.
  • Dark places are space not written to partition table, some can be unused, for some usage is unknown.
 
Last edited:
Hi Berion, thanks for your tools and guides here.

I have an OFW PS3 which decided to corrupt its storage recently after downloading a large game from PSN. The PS3 was set to shutdown automatically after finishing which it did, on next boot it says it needs to format the storage. None of the safe mode options worked. I don't think the drive is physically faulty, I think it's just the PS3 deciding it cannot fix the file system. I have taken a dd clone of the drive though to rule that out.

I'd like to try to recover the drive (or at least the important data), and then return to OFW.

I have installed CFW on the PS3 and have extracted my eid_root_key. I have been able to read the drive under Linux with the "PS3_HDD_Reader" and have extracted my save data etc with help from your user data backup guide.

So now that I have my data recovered, I'd like to experiment to see if the file system can be made to work again. Do you know if there are any temporary files or such that I could try deleting from the drive that might allow the OFW to try and repair it?

Additionally, while I have my PS3 on CFW, is there anything else worth dumping like eid_root_key which may be useful in future?

Thanks
 
@Berion bswap16-ecb isn't compiling anymore on the latest Fedora kernel, I think something has changed in the kernel source. Did you noticed that too?

Code: 
gmipf@wks01:~/ps3hdd/bswap16-ecb/source$ make clean
make -C /lib/modules/6.5.9-200.fc38.x86_64/build M=/home/gmipf/ps3hdd/bswap16-ecb/source clean
make[1]: Entering directory '/usr/src/kernels/6.5.9-200.fc38.x86_64'
  CLEAN   /home/gmipf/ps3hdd/bswap16-ecb/source/Module.symvers
make[1]: Leaving directory '/usr/src/kernels/6.5.9-200.fc38.x86_64'
gmipf@wks01:~/ps3hdd/bswap16-ecb/source$ make
make -C /lib/modules/6.5.9-200.fc38.x86_64/build M=/home/gmipf/ps3hdd/bswap16-ecb/source modules
make[1]: Entering directory '/usr/src/kernels/6.5.9-200.fc38.x86_64'
  CC [M]  /home/gmipf/ps3hdd/bswap16-ecb/source/bswap16.o
/home/gmipf/ps3hdd/bswap16-ecb/source/bswap16.c: In function 'bswap16_init':
/home/gmipf/ps3hdd/bswap16-ecb/source/bswap16.c:41:16: error: implicit declaration of function 'crypto_register_alg'; did you mean 'crypto_has_alg'? [-Werror=implicit-function-declaration]
   41 |         return crypto_register_alg(&bswap16_alg);
      |                ^~~~~~~~~~~~~~~~~~~
      |                crypto_has_alg
/home/gmipf/ps3hdd/bswap16-ecb/source/bswap16.c: In function 'bswap16_exit':
/home/gmipf/ps3hdd/bswap16-ecb/source/bswap16.c:46:9: error: implicit declaration of function 'crypto_unregister_alg' [-Werror=implicit-function-declaration]
   46 |         crypto_unregister_alg(&bswap16_alg);
      |         ^~~~~~~~~~~~~~~~~~~~~
/home/gmipf/ps3hdd/bswap16-ecb/source/bswap16.c: At top level:
/home/gmipf/ps3hdd/bswap16-ecb/source/bswap16.c:55:21: error: expected declaration specifiers or '...' before string constant
   55 | MODULE_ALIAS_CRYPTO("bswap16");
      |                     ^~~~~~~~~
cc1: some warnings being treated as errors
make[3]: *** [scripts/Makefile.build:243: /home/gmipf/ps3hdd/bswap16-ecb/source/bswap16.o] Error 1
make[2]: *** [/usr/src/kernels/6.5.9-200.fc38.x86_64/Makefile:2046: /home/gmipf/ps3hdd/bswap16-ecb/source] Error 2
make[1]: *** [Makefile:246: __sub-make] Error 2
make[1]: Leaving directory '/usr/src/kernels/6.5.9-200.fc38.x86_64'
make: *** [Makefile:7: all] Error 2
 
OK fixed already, they changed the place of the functions "crypto_register_alg" and "crypto_unregister_alg" in kernel 6.4 and later. You need to add this line at the top in "bswap16.c":

Code: 
#include <crypto/algapi.h>
 
@andshrew I bet that fault is UFS2 filesystem corruption for which there are no tools on Linux side to even check his condition. Instead using PS3 HDD Reader, could You try PS3 HDD Decryption Helper? Can reveal more if You trying mount each of partitions with fs.

Also, wise would be checking S.M.A.R.T of this HDD because what You describe, looks like bad sectors.

Dump also IDPS and make NOR/NAND Flash memory dump. You never know when You need it. ;] First allows You to resign any saves for your console and user, also decrypting all system backup archives. Second can be handy if Your flash become corrupted and You get perm brick.

- - -
@gmipf Fast as lighting. ^^ Thank You, I will update toolkit soon, due to adding OtherOS support which I finally figure out.
 
Last edited:
I'm trying to use the decryption helper at the moment, I'm using Ubuntu via WSL2. I'm using option 7 in KO Manager but getting errors.

For bswap16-ecb it complains the sed command is incorrect: sed: -e expression #1, char 25: unknown option to `s'.

I've tried manually setting KSRC_DIR=
${HOME}/ps3/apps/source/kernel, and eventually got it to build but it won't load the module:

Code: 
sudo modinfo apps/bswap16-ecb.ko
filename:       /home/andrew/ps3/apps/bswap16-ecb.ko
alias:          crypto-bswap16
alias:          bswap16
author:         Decaf Code <[email protected]>
description:    Byte swap pseudo-cipher
license:        GPL
srcversion:     04B949023613CEB4D2E3EE2
depends:
retpoline:      Y
name:           bswap16
vermagic:       5.15.133.1-microsoft-standard-WSL2+ SMP mod_unload modversions

Code: 
sudo insmod apps/bswap16-ecb.ko
insmod: ERROR: could not insert module apps/bswap16-ecb.ko: Invalid module format

With ufs I see this output
Code: 
KCSAN: dynamic data race detector (KCSAN) [N/y/?] (NEW)
#
# configuration written to .config
#
WARNING: Symbol version dump "Module.symvers" is missing.
         Modules may not have dependencies or modversions.
         You may get many unresolved symbol warnings.
  MODPOST fs/ufs/Module.symvers
/bin/sh: 1: scripts/mod/modpost: not found
make[1]: *** [scripts/Makefile.modpost:133: fs/ufs/Module.symvers] Error 127
make: *** [Makefile:1826: modules] Error 2
ERROR. Compilation failed!

Perhaps I am missing something obvious?
 
@andshrew Nah, not obvious and not trivial. Default Microsoft Linux kernels cannot be used (or I'm missing something). Kernel modules cannot be load on it, even if You resolve compiling issues. I considering remove/hide it from KO Manager because there is no easy way to go through the process.

Please, download Linux Mint disc image, burn it on USB via Rufus and boot computer from it. You don't need to install anything, everything will work from RAM once read from USB. That is Your best bet.
 
Thanks Berion. I've tried it on Ubuntu now (just as I had one readily available), and I've got the tool working now. I'll try Mint if I have any further issues, but for now the tool has been able to mount the drive and I can browse it.

I noticed that I'm missing /dev_flash2/etc/xRegistry.sys - which in reading about it seems like it would be a bit of a problem.

I've been able to create an image dev_flash2 and run testdisk against it, and it seems like it will let me undelete xRegistry.sys (and backup, restore folders which were also missing).

So given that partition is writable, I could try putting that file back onto the real drive and see if the PS3 will attempt a repair then?

Also thanks for the advice on what other things to dump while I have CFW.
 
Ubuntu is fine too. Just have unhandy interface. ;d

That's strange. Things rather not disappearing just like that. ;] This file is mandatory to working environment. Settings and user credentials are stored there.

Yes, this could works, and dev_flash2 using FAT16 if Im not mistaken (or FAT12). It is fully writable and supported in Linux. Your plan have sense but before You doing that, make sector by sector copy of this partition, eg. that:
Code: 
sudo dd if=/dev/mapper/ps3vflash3 of=${HOME}/ps3/storage/devflash2.img status=progress
In case something will goes wrong, You can restore it in the same way but in opposite direction ("if" means input, "of" means output).
Remember that Your home is in RAM, so copy it to USB or Windows partition (but not the system one mounted as C in Windows if You have turned on fast boot). ;]

You're welcome.

You can check also dev_hdd1 (task in Tasker script), it is intensively used and have FAT32.
 
Last edited:
I tried putting the recovered xRegistry.sys back in place, used the option to clean up dev_hdd1, and then returned the PS3 back to OFW but unfortunately it still says the system storage is corrupted.

I tried cloning the original drive once more using ddrescue this time, and it completed with zero errors.

So I guess it is as you suspected - something has gone wrong with the UFS2 filesystem. Not bad enough to make it unreadable with these tools, but enough to make the PS3 unable to fix it. I did notice when browsing the game folder in dev_hdd0 that some of the files there have file sizes listed but cannot open (for example some of the picture PNG files).

Anyway, I was at least able to recover my save files and - given that I can now decrypt any drive in my PS3 - it should be easy to back them up again in future :smile new:

Thanks for taking the time to reply. Now for the painful process of trying to use the PS Store download list to reinstall my games... :tranquillity:
 
I've been thinking some more on this, and reading through the discussion on write access to the UFS filesystem on the past couple of pages. I started to think why get it working on Linux when FreeBSD supports it natively; why not just decrypt the drive on a Linux system, and then pass the device through to a FreeBSD VM.

The first issue is that the PS3s PowerPC is big-endian, and so a x86 FreeBSD VM cannot read the big-endian formatted dev_hdd0. But with qemu we can configure the VM to emulate a PowerPC system, so now we can pass the device through to a big-endian system which should be able to natively read the drive.

And sure enough it works!

I decrypt the device in Linux, I then directly pass the device (/dev/mapper/ps3hdd2 - I have a Slim) through to the qemu PowerPC FreeBSD VM, and then mount the device within FreeBSD. Write access to dev_hdd0 natively works.

Code: 
root@:~ # file -s /dev/vtbd0
/dev/vtbd0: Unix Fast File system [v2] (big-endian) last mounted on /cell_mw_cfs, last written at Fri Nov  3 16:32:49 2023, clean flag 0, readonly flag 0, number of blocks 311386280, number of data blocks 301585654, number of cylinder groups 3311, block size 16384, fragment size 2048, average file size 16384, average number of files in dir 64, pending blocks to free 0, pending inodes to free 0, system-wide uuid 0, minimum percentage of free blocks 8, TIME optimization

Note the last written date time is Fri Nov 3 16:32:49 2023 - so the PS3 has made no attempt to fixing the drive when I've booted it since then.

Given the suspected corruption that my drive has, I was able to run fsck on it...
Code: 
root@:~ # fsck -y /dev/vtbd0
** /dev/vtbd0
** Last Mounted on /cell_mw_cfs
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
UPDATE FILESYSTEM TO TRACK DIRECTORY DEPTH? yes
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
FREE BLK COUNT(S) WRONG IN SUPERBLK
SALVAGE? yes
SUMMARY INFORMATION BAD
SALVAGE? yes
BLK(S) MISSING IN BIT MAPS
SALVAGE? yes
394087 files, 259173843 used, 42411811 free (69523 frags, 5292786 blocks, 0.0% fragmentation)
***** FILE SYSTEM MARKED CLEAN *****
***** FILE SYSTEM WAS MODIFIED *****

It worked!! The PS3 booted up perfectly, and didn't complain of any disk corruption.

Give me some time and I'll write up the commands I used to boot qemu and pass the device through, and the pre-built FreeBSD image I used.

For reference this is my configuration:

Code: 
Windows 11 host
PS3 drive connected to USB SATA
│
└── Linux Mint VM (VMware Workstation)
     │
      Entire PS3 drive is passed through to VM
      /dev/mapper/ps3hdd is created
     │
     └── FreeBSD VM (qemu-system-ppc64)
          |
           /dev/mapper/ps3hdd2 is passed through to VM
           Read/Write access is natively available

I notice that reserving %8 of free space seems to be a feature of the file system, so presumably there is a native way of changing this now that write access is possible.
 
The first issue is that the PS3s PowerPC is big-endian, and so a x86 FreeBSD VM cannot read the big-endian formatted dev_hdd0
Click to expand...
bswap16-ecb converting on the fly endiannes. So mapper "ps3hdd-bs" is BE, while "ps3hdd" is LE. So also "ps3hdd2" is also LE, ready to be exposed eg. via NBD.

So I'm confused now. But very surprised and waiting for some mini guide. ^^

However, fs detected is FFS, not UFS2. Im' even more confused now. ;]
 
Berion said:
bswap16-ecb converting on the fly endiannes. So mapper "ps3hdd-bs" is BE, while "ps3hdd" is LE. So also "ps3hdd2" is also LE, ready to be exposed eg. via NBD.

So I'm confused now. But very surprised and waiting for some mini guide. ^^

However, fs detected is FFS, not UFS2. Im' even more confused now. ;]
Click to expand...

Think as a man-in-the-middle, translator kind of thing.

First you mount the PS3 drive, decrypt it with in order to be able to mount it, then run a VM with FreeBSD and link the decrypted HDD to it. Now, the VM will send the commands to update the data on the PS3 HDD, the VM will recieve them and process them as usual via the Linux kernel command interface.

It's pretty hardcore to load a whole VM + OS in order to handle big endian, but very effective.
 
But I understand the idea, I tried doing the same but with mapper exposed as nbd0 or as real device in emu. And I failed.

ps3hdd2 mapper is in Little Endian. Otherwise, decryption wouldn't work because PS3 doing such translation for everything except OtherOS on VFLASH and on dedicated partition.

ps3hdd_le_vs_be.png


In last post I have in mind: sdx vs ps3hdd-bs/ps3hdd mappers, not ps3hdd-bs vs ps3hdd. Sorry.

So I thinking that he unnecessary converting it again and just FreeBSD automatically detecting endianness type by doing some challenges on fs parser side.
 
Last edited:
@andshrew Interesting. I actually did what you did once, decrypt on Linux host and mount on the ppc qemu emulator. I had no luck with FreeBSD though. But on NetBSD in vm mounting worked fine.
 
NetBSD using FFS too. And I've tried mount as UFS2 in GhostBSD (it is FreeBSD) as maniac. ;] That's is possible that PS3 in reality using FFS and we all those years living in wrong, due to positive mounting as UFS2 on Linux (but no corruption using ufs.ko so far on PS3 and PS4)? :| Massively writing test should at least be made to confirm that it is safe. R-Studio returned fs recognition as UFS2. IsoBuster too.
 
I typed out a long post then the forum decided it was spam... :angel:

So I've shared the steps in a gist on GitHub: https://gist.github.com/andshrew/1d0b5e35308a6fd9770831e47950be0a

It's reasonably straight forward so hopefully works for you. I did initially try with an amd64 FreeBSD VM, which is when I ran into the endianness issue and from reading it seems like UFS within FreeBSD can only read drives which match the systems endianness - which is why I then tried ppc64.

I'm curious now if it will be possible to extend the size of this partition. Looking at your diagram it seems like I would only need to relocate dev_hdd1 to potentially do this. It seems like you can definitely tweak the 8% reservation, although the man page for tunefs perhaps suggests it isn't such a good idea.

Also with my drive which I repaired I noticed that the PS3 is no longer activated. I guess this is to be expected given I've since installed CFW to get my eid_root_key and now reverted back to OFW. I've not tried connecting back online yet to reactivate it, but I was able to play a demo which doesn't require a license. I tried to be as careful as possible when installing CFW (I did it entirely offline, with the PS3s Internet access blocked at the router), and have since reinstalled OFW twice. So I'm hopeful I haven't left any trace, as my intention was just to repair my drive so I can go back to using my PS3 as it originally was (on OFW).
 
Last edited:
I think whether you mount as ufs or ffs, the driver will auto set to ffs anyways in Linux and also on NetBSD. I'm still not sure about that but I think FFS has all different implementation between the BSD flavours.
 
Ok, so I uploading it here if You don't have anything against it (low post members have some restrictions due to spambots).
https://gist.github.com/andshrew/1d0b5e35308a6fd9770831e47950be0a#file-ps3_hdd_decryption_notes-md
Copy in attachment, change *.txt to *.md (forum not accepting md extension).

- - -
PS3PT have easy and known structure but You need do it manually. However, not from ps3hdd<number> mappers if You did not first modify partition table because mapper will have set size which kpartx found. Also You cannot exceed 2TiB because LBA field there have only 4 bytes.

Quite coincidentally I'm sitting on toolkit update for OtherOS and I'm figure out where those values are stored. :)

- - -
CFW have patches related to "dev_hdd0/home/<user number>/exdata/act.dat". OFW deleting this file if something goes wrong with validation, checking on each boot. Licenses (*.rif, *.edat, *.mln should be fine).


PS: And thank You for Your time!
 

Attachments

Last edited:
You must log in or register to reply here.

Similar threads

Back
Top