PS3 [Tutorial] HDD mounting and decryption on Linux

@andshrew Thank you for the detailed steps. What I just don't get is how the big-endian ppc variant of FreeBSD is able to work with your mounted drive, despite being fed as little-endian to the vm, since you also applied bswap16 to it before decrypting. The logical step should be to skip bswap16 and instead decrypt directly with byte-swapped decryption keys.
 
gmipf said:
@andshrew Thank you for the detailed steps. What I just don't get is how the big-endian ppc variant of FreeBSD is able to work with your mounted drive, despite being fed as little-endian to the vm, since you also applied bswap16 to it before decrypting. The logical step should be to skip bswap16 and instead decrypt directly with byte-swapped decryption keys.
Click to expand...

If that is what bswap16 is doing, then perhaps the qemu virtio storage controller on the VM is transparently swapping it back?
 
andshrew said:
If that is what bswap16 is doing
Click to expand...
;)
ps3hdd_le_vs_be-png.41745
 
gmipf said:
@andshrew To me it seems that FreeBSD BE also supports LE FFS partitions. The conversion is probably done by the FFS driver of FreeBSD.
Click to expand...

It's possible. Out of interest, I will try creating a UFS LE partition in my amd64 FreeBSD VM, and then see if the ppc64 BE FreeBSD VM can mount it.
 
@gmipf
From my amd64 FreeBSD VM I created a new UFS partition on a GPT disk:
Code: 
root@freebsd:~ # gpart create -s gpt vtbd1
vtbd1 created
root@freebsd:~ # gpart add -t freebsd-ufs -l ufs-amd64 -b 1M -s 1G vtbd1
vtbd1p1 added
root@freebsd:~ # newfs -U /dev/gpt/ufs-amd64
/dev/gpt/ufs-amd64: 1024.0MB (2097152 sectors) block size 32768, fragment size 4096
        using 4 cylinder groups of 256.03MB, 8193 blks, 32896 inodes.
        with soft updates
super-block backups (for fsck_ffs -b #) at:
 192, 524544, 1048896, 1573248
root@freebsd:~ # file -s /dev/gpt/ufs-amd64
/dev/gpt/ufs-amd64: Unix Fast File system [v2] (little-endian) last mounted on , last written at Thu Nov  9 23:09:02 2023, clean flag 1, readonly flag 0, number of blocks 262144, number of data blocks 253831, number of cylinder groups 4, block size 32768, fragment size 4096, 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

Then from the ppc64 FreeBSD VM I tried to mount it, but it was unable to because of the endian mismatch
Code: 
root@:~ # mount /dev/gpt/ufs-amd64 dev_hdd0/
UFS superblock failed due to endian mismatch between machine and filesystem
mount: /dev/gpt/ufs-amd64: Illegal byte sequence
 
@andshrew I get the same message but in reverse, forwarding
/dev/mapper/ps3hdd2 to an amd64 FreeBSD VM. This should work since both ends are LE but the partition is marked as BIG-ENDIAN, regardless of what conversion is done before. Therefore I'm not sure if in your case FreeBSD is even handling that partition correctly.

EDIT: Also tried already decrypting using byteswapped decryption key. Not working. Of course not, since the decryption is processed in LE on the host side.
 
Last edited:
@andshrew I see in Your guide that You typing all stuff manually due to lack option to not mounting partitions, just decrypting alone. So I added to Umounter to unmout all. ;p I know it is annoying but less than typing everything by hand. This can be combined with Read Only scripts (mappers are writable, ro only for fs which You unmounting anyway).

Also I saw that loading modules menu can be misleading and annoying, so I commented sections from interactive mode. Eventually, if You want only bswap16-ecb, use hidden option "1-bs".

I fixed (maybe, I hope :D) WSL2 part of script. Could You check if it compiling now? Please, before that, redownload stuff from option no.3.

Later we can thinking about PowerShell script (I hate PowerShell ;d) and FreeBSD script for adding some automatics.
 
@Berion That's great, thanks for adding those options.

Regarding WSL2, I'm still getting the modpost and sed error messages. I've saved the entire output here for you: https://pastebin.com/JffQ811V
I'm using the stock Ubuntu 22.04 download.

I've finished with my own drive now I think, everything is recovered and I've since migrated the data using the FreeBSD VM so that I get the full size of my new drive. I ended up doing a file copy of dev_hdd0, then letting the PS3 reformat the drive, and then copying the files back - rather than trying to manually resize it. I saved my notes of the process here for anyone who is interested, it was pretty painless in the end :pride:: https://gist.github.com/andshrew/1d0b5e35308a6fd9770831e47950be0a#file-ps3_hdd_migration_notes-md
 
@andshrew Do you still have an image of your drive in broken filesystem state or do you know how to break the filesystem irreparabel? I would like to experiment something.
 
gmipf said:
@andshrew Do you still have an image of your drive in broken filesystem state or do you know how to break the filesystem irreparabel? I would like to experiment something.
Click to expand...

I still have the original drive in its broken state, I only ran fsck on the clone I made. You can see the output from fsck and what it found wrong in my earlier post.

I don't know how to manually break the file system; it broke when the PS3 completed a background game download/install (using the option to automatically turn the system off after it finishes).
 
@gmipf Copy PKG to disk, start installing it, then turn off console by cutting off power. On next boot, if this doesn't help and PS3 perform fsck with success, repeat. If this not help, increase UFS preservation to higher than normal, and perform again this ritual. Shouldn't survive. Eventually, which is more safe, just overwrite randomly, decrypted superblock by some random values.

@andshrew You gave me super idea to making cloning drives. :) Are You volunteer to test or rather want now calm environment? :D
And thanks for the report.
 
Actually I know a method to break the filesystem reliably but the process is tedious. I had a problem on my OFW slim CECH2500 where I couldn't install more than 600gb of PSN pkg game data. Already tried filled a 1000GB SSD, 750GB HDD etc. If I fill more than 550 or 600GB of it and after that manually run filesystem test on that ps3 it will break definitely. Have experimented days long, installing from psn, breaking, reformatting with different drives, breaking etc.. At this moment the only reliable way to use my OFW ps3 is to use an 480GB SSD.

I actually also need to investigate that problem further with different models to determine whether that unreliability is existent on other models too.
 
Last edited:
Here is quick look at first PS3PT. I colored stuff to be better recognized. As You can see, first field is start address of partition, second field is length, also in sectors. I don't know what those flags doing but better not touch them for now.

Values are in LBA, which means 1 LBA = 512 bytes. Which can be easily find recalculating them. And easily modified via dd (maybe even xxd could serve values in pipe) and its skip=<how many bytes> bs=<used value unit> count=<how many times do it>.

From example below for UserData (UFS2) partition:
Code: 
080018 * 200 = 10003000 = start address in hex
524312 * 512 = 268447744 = start address in dec
7c8f898 * 200 = f91f13000 = sector length in hex
130611352 * 512 = 66873012224 = sector length in dec
10003000 + f91f13000 = fa1f16000 end address in hex
268447744 + 66873012224 = 67141459968 end address in dec
67141459968 / 512 = 131135664 end address in LBA in dec
Best candidate for enlarging test is environment without OtherOS and edit of CACHE because it is FAT32 and no extra efforts are needed. Mini guide for such test:
  1. Clone smaller HDD to larger via sector by sector copy.
  2. Decrypt HDD (of course I have in mind mappers, not literal decryption of whole HDD).
  3. Edit Cache partition length only.
  4. Remove mappers and all stuff and decrypt disk again (to update mappers range).
  5. Fix FAT32 from tasker script.
  6. Remove mappers and all stuff.
  7. Check if PS3 will boot fine and see enlarged dev_hdd1 (eg. in multiMAN file manager).
If this will work, then this opening us for dealing with 1GiB limit for UserData partition, which in theory can be enlarged to 2TiB (if only four bytes filed is in use, but if 8 (4 zeroes from beginning) then OMG ;d).

And interesting if this bug lies only in emetinit or ufs libs at all. Linux+FreeBSD could free us from partition not only enlarging but also severally speed up cloning, the real cloning not just copying files from A to B.

Who volunteer for that? :D

ps3pt_dump.png
 
Last edited:
@Berion Could you find out where the identifier is in the ufs filesystem which determines if the fs is BE or LE? My idea is to swap that header/identifier by manipulating the drive directly before mounting on a LE FreeBSD VM and swapping the old identifier back after umount. I will not trust accessing the drive in a BE FreeBSD system before knowing what the driver is actually doing.
 
You reading in my mind. :D

edit: That could be not easy if possible.
https://flylib.com/books/en/2.48.1/ufs2_superblock.html
Maybe in flags it is defined?

But I found this, and while it is talking about x86 and Sparc, we are on the same boat on x86 and ppc64:
https://ufs-discuss.opensolaris.narkive.com/Nlpb4GEV/big-and-little-endian
Unlike ext2fs, pcfs, udfs, etc., a byte-order independent ufs will have to
support BOTH byte orders. In other words, ufs may be either big endian or
little endian, which means we may have to byte swap on either architecture.
The other file systems have a defined byte order, and swapping is only required
on the opposite byte order architectures.

- ufs file systems differ between intel and sparc in more than just byte
order. For instance, the fs_state and fs_npsect fields in the superblock
are swapped in little endian machines for increased compatibility with the
SVR4 ufs implementation. If byte swapping is enabled, then these two
fields need to be swapped as well.

- Perhaps the most difficult problem to solve is that even if you do have a
file system that understands both formats, you still can not yank a disk
off a sparc machine and plug it into the intel system and have it work.
The sd driver has intimate knowledge of the disk label and partition
information, which is totally incompatible between Solaris intel and
Solaris sparc.

- Byte swapping a file system is a very invasive procedure. My first attempt
at this problem was to intercept the points where metadata was read in or
written out, and perform the byte swap operation then. However the buffer
cache complicates this as you then need to keep track of whether the buffer
has been swapped or not already, and in some cases, which parts of the
buffer may have been swapped.
Click to expand...

BUT. CellOS writing data in LE, then encrypt it and converting to BE, and then writing physically. Otherwise, what we doing on Linux currently, wouldn't work at all (because first operation in such case must be decryption, not byte swapping, but we doing opposite and it is fine!). I'm a little confused with this, especially while freebsd le doesn't accepting ps3hdd2 which is le (You are thinking that because BE kind of marking to tells the driver how to handle stuff, and that's logical).
 
Last edited:
Berion said:
BUT. CellOS writing data in LE, then encrypt it and converting to BE, and then writing physically. Otherwise, what we doing on Linux currently, wouldn't work at all (because first operation in such case must be decryption, not byte swapping, but doing opposite and it is fine!). I'm a little confused with this.
Click to expand...

Interesting, didn't knew CELLOS is writing data in LE. But the filesystem seems to be clearly set as BE, since FreeBSD is showing it as such. Why Sony did it that way? Seems unnecessarily complicated and a performance bottleneck too.
 
gmipf said:
Could you share the image with me? After removing all personal info of course.
Click to expand...

It's over 500GB, so probably not really practical to share.

Berion said:
@andshrew You gave me super idea to making cloning drives. :) Are You volunteer to test or rather want now calm environment? :D
And thanks for the report.
Click to expand...

Haha, I think I'm going to let my PS3 have a rest now having survived this ordeal. :triumphant:

But I do have another PS3 in storage (it's a fat, but I think it is a NOR model). So once I get access to that again I can do some further testing.
 
You must log in or register to reply here.

Similar threads

Back
Top