PS3 [Tutorial] HDD mounting and decryption on Linux

[Berion]

@gmipf Security by obscurity? ^^

PS3 using SATA-I and even unnecessary encrypted (because everything else is secured anyway and fs access would not help in any hacks (because images, videos, p3t can be imported from USB, and there is www access via web browser - so putting anything on HDD outside PS3 is pointless in the first place)), so they don't much care about efficiency. Probably they thinking that ~50MiB/s in write is fine.

 

[GuilloteTesla]

@gmipf Security by obscurity? ^^

PS3 using SATA-I and even unnecessary encrypted (because everything else is secured anyway and fs access would not help in any hacks (because images, videos, p3t can be imported from USB, and there is www access via web browser - so putting anything on HDD outside PS3 is pointless in the first place)), so they don't much care about efficiency. Probably they thinking that ~50MiB/s in write is fine.

I still think that Sony engineers decided to make the most secure system ever, and took that very seriously by encrypting every layer, every component, every piece of data from the system.

Performance?, who wants performance with a CELL when you have super security?. :P

 

[Berion]

@GuilloteTesla Actually they would succeed if not ECDSA human error.

- - -
Could You all good people attach for me dumps of Yours partition table?

sudo dd if=/dev/mapper/ps3hdd of=${HOME}/ps3pt.img bs=512 count=2 status=progress

Eventually just a text file contents pasted ("random garbage" after last "*" symbol is not needed):

sudo hexdump -C /dev/mapper/ps3hdd | head -32 >> ${HOME}/ps3pt.txt

Also mention from what PS3 models dump came.

Example: (CECHL04, no OtherOS installed so only three partitions)

00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000010  00 00 00 00 0f ac e0 ff  00 00 00 00 de ad fa ce  |................|
00000020  00 00 00 00 00 00 00 03  00 00 00 00 00 00 00 02  |................|
00000030  00 00 00 00 00 00 00 08  00 00 00 00 00 08 00 00  |................|
00000040  10 70 00 00 01 00 00 01  00 00 00 00 00 00 00 0b  |.p..............|
00000050  10 70 00 00 02 00 00 01  00 00 00 00 00 00 00 03  |.p..............|
00000060  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000000c0  00 00 00 00 00 08 00 10  00 00 00 00 00 2c df f0  |.............,..|
000000d0  10 70 00 00 01 00 00 01  00 00 00 00 00 00 00 03  |.p..............|
000000e0  10 70 00 00 02 00 00 01  00 00 00 00 00 00 00 03  |.p..............|
000000f0  10 20 00 00 03 00 00 01  00 00 00 00 00 00 00 03  |. ..............|
00000100  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000150  00 00 00 00 00 34 e0 08  00 00 00 00 00 3f ff f8  |.....4.......?..|
00000160  10 70 00 00 01 00 00 01  00 00 00 00 00 00 00 03  |.p..............|
00000170  10 70 00 00 02 00 00 01  00 00 00 00 00 00 00 03  |.p..............|
00000180  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*

I'm trying figure out those flags. Maybe we could make formatter, of course FreeBSD would still be needed to do mkfs.ufs or whatever they using, ;p but this could still simplify the process.

Between my 4GiB HDD dump (above) and 80GB dump (diagram from here), I see that numbers changed on 04 column in hex editor, but I don't see any sense in that. So this is mostly important values for me. I have looked at kpartx source but it not using it for anything.

 

[bleepbleep]

here's the partition table using petitboot on CECH-2501A and saving to usb drive:

mount -w /dev/sda1 /tmp/petitboot/mnt/sda1
cd /tmp/petitboot/mnt/sda1
dd if=/dev/ps3da of=ps3pt.bin bs=512 count=2

includes txt text file, rtf text file, and binary file.
looks similar to yours.
edit: ps3da is the hard drive

 

[Berion]

I have added in first post newer versions of the tutorial (in attachments in first post). This one expands few topics, focusing more on Windows users, I removed ERK dumping guide (because it is now a separate guide) and cover whole procedure by PS3 HDD Decryption Helper toolkit instead typing everything by hand.

However, I didn't removed old tutorials so they will be always available, but never updated.

 

[Berion]

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.

Could You try it please? For now size doesn't matter, we need to know if this BSD is able to resize it. ^^

Preparations:
0a. Use small HDD and make its sector by sector image
0b. Write this image into larger drive.
0c. Run console to be sure that she recognizing HDD. If not, allow her to format this drive and write again this image so now for sure console will not ask for formatting (sometimes HDD can be swapped, sometimes cannot, we don't know why).
So result should be recognized HDD by PS3 with boundaries from old HDD (that was reason to write image of it to new drive).

It does not work with NAND models (different addresses and mappers). Only NORs.

The reason why doing step 2 is to unmount partitions but left mappers.
The reason why doing step 4 is to remove everything to read again in step 5 with new size mapping, so also update mappers.
And again, unmount everything but leaving mappers in step 6 for BSD magic.
So it is not my mistake, that's magic is for a reasons. ^^"

If this will work, it pushes us to next test kind of larger disk than 1TiB.
If 1TiB test will succeed, then we tricked the Sony to have zeta bytes drives.

And of course, since it is EXPERIMENTAL script, can lead to all data loss. So please, do not try on HDDs with valuable data.

 

[gmipf]

@Berion I'm a little late, not sure if you still need the attachments. I also had an idea why the ps3 filesystem is marked as BE. Maybe that filesystem is in-fact created and handled as BE but just the files are processed as LE on the fly in the ps3 OS? If that is the case, then I think the proper way to do fsck would be to use an PowerPC virtual machine running FreeBSD I think.

EDIT: But that would also mean to use a powerPC machine running Linux first for decryption, since we can't decrypt in FreeBSD -.-

 

[Berion]

@gmipf Yes, still still. The more the better to understand flags. Thank You.

 

[andshrew]

@Berion I'll try your new expander script within the next few days and report back.

 

[andshrew]

@Berion First attempt, I have a newly formatted 60GB drive that I have cloned to a 250GB drive. It boots in the PS3 OK and it reports 47GB/232GB free.

lsblk after running the mounter script:

VMware Virtual S               232.9G /dev/sdc
                               232.9G └─/dev/mapper/ps3hdd-bs
                               232.9G   └─/dev/mapper/ps3hdd
                                 256M     ├─/dev/mapper/ps3hdd1
                                 256M     │ └─/dev/mapper/ps3vflash
                                14.7M     │   ├─/dev/mapper/ps3vflash1
                               199.8M     │   ├─/dev/mapper/ps3vflash2
                                  16M     │   ├─/dev/mapper/ps3vflash3
                                 512K     │   ├─/dev/mapper/ps3vflash4
                                   4M     │   ├─/dev/mapper/ps3vflash5
                                 256K     │   └─/dev/mapper/ps3vflash6
                                53.6G     ├─/dev/mapper/ps3hdd2
                                   2G     └─/dev/mapper/ps3hdd3

During running the extender script:

/dev/sdc
[sudo] password for andrew:         
1+0 records in
1+0 records out
8 bytes copied, 0.000115286 s, 69.4 kB/s
1+0 records in
1+0 records out
8 bytes copied, 0.000146351 s, 54.7 kB/s
1+0 records in
1+0 records out
8 bytes copied, 8.0757e-05 s, 99.1 kB/s
1+0 records in
1+0 records out
8 bytes copied, 8.0927e-05 s, 98.9 kB/s
mkfs.fat 4.2 (2021-01-31)
All done. Press any key to exit.

But now during running the mounter mounter script it hangs - however lsblk output does suggest that /dev/mapper/ps3hdd2 has been expanded:

VMware Virtual S               232.9G /dev/sdc
                               232.9G └─/dev/mapper/ps3hdd-bs
                               232.9G   └─/dev/mapper/ps3hdd
                                 256M     ├─/dev/mapper/ps3hdd1
                               230.6G     └─/dev/mapper/ps3hdd2

I will repeat the test now and clone onto another HDD, to see if it hangs at the same point with that one. These are are old drives I have and there is a chance that the drive is bad...

 

[andshrew]

@Berion yes I think the 250GB drive was bad... I applied the 60GB image to a 320GB drive and it now re-mounts after running the expander script:

Also make sure to set the block size when writing the image... I didn't do that the first time and it wrote the image at 8MB/s. Setting bs to 64k and it wrote at 70MB/s.

sudo dd if=ps3_60gb.img of=/dev/sdc bs=64k status=progress

lsblk prior to running the extender:

VMware Virtual S               298.1G /dev/sdc
                               298.1G └─/dev/mapper/ps3hdd-bs
                               298.1G   └─/dev/mapper/ps3hdd
                                 256M     ├─/dev/mapper/ps3hdd1
                                 256M     │ └─/dev/mapper/ps3vflash
                                14.7M     │   ├─/dev/mapper/ps3vflash1
                               199.8M     │   ├─/dev/mapper/ps3vflash2
                                  16M     │   ├─/dev/mapper/ps3vflash3
                                 512K     │   ├─/dev/mapper/ps3vflash4
                                   4M     │   ├─/dev/mapper/ps3vflash5
                                 256K     │   └─/dev/mapper/ps3vflash6
                                53.6G     ├─/dev/mapper/ps3hdd2
                                   2G     └─/dev/mapper/ps3hdd3

lsblk after running the extender:

VMware Virtual S              298.1G            /dev/sdc
                              298.1G            └─/dev/mapper/ps3hdd-bs
                              298.1G              └─/dev/mapper/ps3hdd
                                256M                ├─/dev/mapper/ps3hdd1
                                256M                │ └─/dev/mapper/ps3vflash
                               14.7M                │   ├─/dev/mapper/ps3vflash1
                              199.8M                │   ├─/dev/mapper/ps3vflash2
                                 16M                │   ├─/dev/mapper/ps3vflash3
                                512K                │   ├─/dev/mapper/ps3vflash4
                                  4M                │   ├─/dev/mapper/ps3vflash5
                                256K                │   └─/dev/mapper/ps3vflash6
                              295.8G                ├─/dev/mapper/ps3hdd2
                                  2G                └─/dev/mapper/ps3hdd3

So then passing /dev/mapper/ps3hdd2 into the FreeBSD VM, and it's not overly happy.

It can see the partition ok:

root@:~ # geom disk list
Geom name: vtbd1
Providers:
1. Name: vtbd1
   Mediasize: 317657006080 (296G)
   Sectorsize: 512
   Mode: r0w0e0
   descr: (null)
   ident: (null)
   rotationrate: unknown
   fwsectors: 63
   fwheads: 16

This command should list information about the partition, which it doesn't:
(output like /dev/vtbd1: Unix Fast File system [v2] (big-endian) last mounted .....)

root@:~ # file -s /dev/vtbd1
/dev/vtbd1: data

fsck seems unable to do anything:

root@:~ # fsck_ufs /dev/vtbd1
Attempted recovery for standard superblock: failed
Attempted extraction of recovery data from standard superblock: failed
Attempt to find boot zone recovery data.
Finding an alternate superblock failed.
Check for only non-critical errors in standard superblock
Failed, superblock has critical errors
SEARCH FOR ALTERNATE SUPER-BLOCK FAILED. YOU MUST USE THE
-b OPTION TO FSCK TO SPECIFY THE LOCATION OF AN ALTERNATE
SUPER-BLOCK TO SUPPLY NEEDED INFORMATION; SEE fsck_ffs(8).

 

[andshrew]

@Berion Making some progress... just looking through what the expander script is doing, it looks like it sets a fixed start location for the the USERDATA partition. Since we're just expanding the partition the start location for this shouldn't change? Also the location it was using wasn't where mine started.

If I manually run the commands omitting setting the start location for USERDATA:

sudo dd if=/tmp/ps3pt_p3_start.bin  of=/dev/mapper/ps3hdd seek=42 bs=8 count=1 status=progress
sudo dd if=/tmp/ps3pt_p3_length.bin of=/dev/mapper/ps3hdd seek=43 bs=8 count=1 status=progress
sudo dd if=/tmp/ps3pt_p2_length.bin of=/dev/mapper/ps3hdd seek=25 bs=8 count=1 status=progress

Now when I pass it into FreeBSD I can see the partition, and it can mount it:

root@:~ # file -s /dev/vtbd1
/dev/vtbd1: Unix Fast File system [v2] (big-endian) last mounted on /cell_mw_cfs, last written at Sun Jan  1 00:11:14 2012, clean flag 1, readonly flag 0, number of blocks 14061452, number of data blocks 13618311, number of cylinder groups 191, block size 16384, 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
root@:~ # geom disk list
Geom name: vtbd1
Providers:
1. Name: vtbd1
   Mediasize: 317657006080 (296G)
   Sectorsize: 512
   Mode: r0w0e0
   descr: (null)
   ident: (null)
   rotationrate: unknown
   fwsectors: 63
   fwheads: 16

Running growfs seems to work...

root@:~ # growfs /dev/vtbd1
It's strongly recommended to make a backup before growing the file system.
OK to grow filesystem on /dev/vtbd1 from 54GB to 296GB? [yes/no] yes
super-block backups (for fsck_ffs -b #) at:
 112919360, 113510560, 114101760, 114692960, 115284160 .......
root@:~ # file -s /dev/vtbd1
/dev/vtbd1: Unix Fast File system [v2] (big-endian) last mounted on , last written at Tue Nov 28 15:45:06 2023, clean flag 1, readonly flag 0, number of blocks 77552980, number of data blocks 75116955, number of cylinder groups 1050, block size 16384, 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

I ran an fsck:

root@:~ # fsck_ufs -y /dev/vtbd1
** /dev/vtbd1
** Last Mounted on
** 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
66 files, 128564 used, 74988391 free (31 frags, 18747090 blocks, 0.0% fragmentation)
***** FILE SYSTEM IS CLEAN *****
***** FILE SYSTEM WAS MODIFIED *****

With the cache partition, the script re-creates that before unmounting and remounting the mapper. I manually ran this after remounting, I think that would make more sense (otherwise wouldn't it format the wrong location?).

Also when recreating it it's not exactly like the original partition.... the original one:

andrew@mint:~/ps3$ sudo file -s /dev/dm-4
/dev/dm-4: , code offset 0+3, OEM-ID "        ", sectors/cluster 64, Media descriptor 0xf8, sectors/track 0, sectors 4194272 (volumes > 32 MB), FAT (32 bit), sectors/FAT 512, reserved 0x1, serial number 0, unlabeled

The new one:

andrew@mint:~/ps3$ sudo file -s /dev/dm-4
/dev/dm-4: DOS/MBR boot sector, code offset 0x58+2, OEM-ID "mkfs.fat", sectors/cluster 8, Media descriptor 0xf8, sectors/track 63, heads 128, sectors 4194288 (volumes > 32 MB), FAT (32 bit), sectors/FAT 4088, serial number 0xc21530bf, label: "NO_NAME    "

Now putting it back into the PS3..... it boots.

But... it thinks it has 0KB free space, and even gets a notification about System Storage having less than 500MB free.

I remounted it back in FreeBSD and it's definitely not full:

root@:/cell_mw_cfs # df
Filesystem   1K-blocks    Used     Avail Capacity  Mounted on
/dev/vtbd1   300467820  503040 275927356     0%    /cell_mw_cfs

I tried some Safe Mode options, Restore File System and Rebuild Database but no luck. It still thinks there is 0KB free.

Any ideas?

 

[Berion]

@andshrew Oh wow, thanks for complex tests! ^^

(...) just looking through what the expander script is doing, it looks like it sets a fixed start location for the the USERDATA partition. Since we're just expanding the partition the start location for this shouldn't change? Also the location it was using wasn't where mine started.

Indeed, it will not change. I assumed that it is the same always which was wrong. Compared my PS3PT from NOR model with other tables donated by @gmipf and @bleepbleep and it seems different. So I will leave it intact anyway (just comment line by # symbol with dd which writing "ps3pt_p2_start.bin").

With the cache partition, the script re-creates that before unmounting and remounting the mapper. I manually ran this after remounting, I think that would make more sense (otherwise wouldn't it format the wrong location?).

It is fine because not partitions are mounted, and we works on "parent mapper". That's second reason why all mappers etc. must be removed after those changes to update situation.

Also when recreating it it's not exactly like the original partition.... the original one:

In case of FAT32, we can use compressed image of clean one because is always the same but I wanted more clean solution. I don't think it is a problem but who knows. Could You make image from valid Cache partition mapper via dd and restore it on this HDD? I doubt it glitched because of that but worth a shot. But still, probably it is grow fs which didn't se some flag in UFS I believe.

About label: I mislead it with VFLASHes. Cache don't have any indeed.

 

[andshrew]

@Berion No problem.

Regarding partition tables, is this the output you need for comparison? This is from the 60GB drive with no modifications.

andrew@mint:~/ps3$ sudo dd if=/dev/mapper/ps3hdd bs=8 count=125 status=none | hexdump -C
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000010  00 00 00 00 0f ac e0 ff  00 00 00 00 de ad fa ce  |................|
00000020  00 00 00 00 00 00 00 03  00 00 00 00 00 00 00 02  |................|
00000030  00 00 00 00 00 00 00 08  00 00 00 00 00 08 00 00  |................|
00000040  10 70 00 00 01 00 00 01  00 00 00 00 00 00 00 0b  |.p..............|
00000050  10 70 00 00 02 00 00 01  00 00 00 00 00 00 00 03  |.p..............|
00000060  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000000c0  00 00 00 00 00 08 00 20  00 00 00 00 06 b4 7c 60  |....... ......|`|
000000d0  10 70 00 00 01 00 00 01  00 00 00 00 00 00 00 03  |.p..............|
000000e0  10 70 00 00 02 00 00 01  00 00 00 00 00 00 00 03  |.p..............|
000000f0  10 20 00 00 03 00 00 01  00 00 00 00 00 00 00 03  |. ..............|
00000100  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000150  00 00 00 00 06 bc 7c 80  00 00 00 00 00 3f ff f8  |......|......?..|
00000160  10 70 00 00 01 00 00 01  00 00 00 00 00 00 00 03  |.p..............|
00000170  10 70 00 00 02 00 00 01  00 00 00 00 00 00 00 03  |.p..............|
00000180  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000003e0  00 00 00 00 00 00 00 00                           |........|
000003e8

I've tried cloning the original Cache partition - just in case - but that didn't make any difference, still 0KB free.

I'm now imaged the drive again, but this time I've only made the changes to the partition table. So I haven't run growfs or recreated the Cache partition.

In this state it will boot in the PS3 and it still lists the original free space (expected).

Interestingly the PS3 doesn't complain about the Cache partition being missing - is this normal? Given that we've moved the starting sector for the partition in the partition table, but not actually physically relocated it, I was expecting that it should no longer be able to mount this partition. Am I misunderstanding something there?

Anyway, I tried growfs again and the same as before. The PS3 reported 0KB free.

I tried the process once more but this time limited growfs to 100GB - and this worked. The PS3 now reports 96 GB / 298GB free.

So I tried going 10GB under the 296GB available.... and this worked too! 276 GB / 298 GB free.

root@:~ # growfs -s 286GB /dev/vtbd1
It's strongly recommended to make a backup before growing the file system.
OK to grow filesystem on /dev/vtbd1 from 100GB to 286GB? [yes/no] yes
super-block backups (for fsck_ffs -b #) at:
 209876160, 210467360, 211058560, 211649760,

So there is something that it doesn't like about letting growfs automatically extend the partition to the maximum size. But resizing to something at least 10GB below the maximum absolutely works (I'll do some further testing to see just how close it goes to the limit).

Edit: I went up to 295GB out of 296GB and it still works in the PS3, now seeing 285 GB / 298 GB free.

I don't really have any spare larger drives than this to test further... I assume the interest now would be could you use a drive larger than 1.5TB by doing this?

 

[Berion]

Regarding partition tables, is this the output you need for comparison? This is from the 60GB drive with no modifications.

Yes, thank You. Yours UserData started on LBA 080020h (524320d) while I set it to 080010h (524304d). That's why FreeBSD didn't found superblock and was unable to mount it.

Interestingly the PS3 doesn't complain about the Cache partition being missing - is this normal?

I never remove it so I dunno. I guess so? But for sure system updates and games will not work because those using cache partition.

Anyway, I tried growfs again and the same as before. The PS3 reported 0KB free.
I tried the process once more but this time limited growfs to 100GB - and this worked. The PS3 now reports 96 GB / 298GB free.
So I tried going 10GB under the 296GB available.... and this worked too! 276 GB / 298 GB free.

Maybe not size is barrier here but guessing partition size itself by growfs? Or maybe there is some demanding for padding which is violated in full size? I dunno. We are on uncharted land, the pioneers who putting flag on conquered ground.

Maybe we could use manually setting size, but smaller for few MiB from end of partition (just for test purposes).

I don't really have any spare larger drives than this to test further... I assume the interest now would be could you use a drive larger than 1.5TB by doing this?

You are super helpful. Thank You! Yes, it seems there is some limits we don't know yet but tests can be moved to larger drives which we... both don't have it. ^^"

- - -
Having all this data, I can make more smart Expander script. Thanks again.

 

[Berion]

PS3 HDD Expander v0.4:

[+] Added NAND support (but I have nothing to test it, so it is written blindly based on DECHSA00A's PS3PT).
[f] Fixed FAT32 type creation but still is not exactly the same as original (not possible to make it without messing with dd and streams). I think that better be writing clean image of it.
[c] Turned off UserData partition start values writing, now they are created but original are left intact.
[c] Made cooler looking script main menu, added credits and changed some text.

So, nothing really important for You @andshrew to worth a change. ^^" But if someone have NAND and want to join the fun with big HDD, then he have ready to deploy solution.

 

[andshrew]

Maybe not size is barrier here but guessing partition size itself by growfs? Or maybe there is some demanding for padding which is violated in full size? I dunno. We are on uncharted land, the pioneers who putting flag on conquered ground.

Maybe we could use manually setting size, but smaller for few MiB from end of partition (just for test purposes).

A did a quick test and expanded the filesystem to 10MiB from the end of the partition, and this resulted in 0KB free on the PS3. So the limit is somewhere between 1GB and 10MiB from the end of the partition.

root@:~ # growfs -s 317646520320b /dev/vtbd1
It's strongly recommended to make a backup before growing the file system.
OK to grow filesystem on /dev/vtbd1 from 295GB to 296GB? [yes/no] yes
super-block backups (for fsck_ffs -b #) at:
 618986560, 619577760, 620168960

Unfortunately you don't seem to be able to shrink the file system again so to test further means reimaging the drive each time... although perhaps you can just apply the first xGB from the /dev/mapper/ps3hdd2 image to save doing the entire drive.

Edit: yes, you can copy just the first 1GB of the image to reset the file system back to its original size... although it wasn't happy. Nothing that fsck couldn't fix though...

 

[Berion]

@andshrew That's strange. :/ Maybe that is somehow related to UFS preservation space set on one of flags? But default size is 8% of max size of partition so it is too small to fit into this assumption. Besides that, that space must be in fs table because changing from 8 to 1, changing free space available, otherwise it would needs reformatting partition to gain that space which not happens.

BTW: I found issue in preview scripts related to UserData calculations because I used hardcoded value for VFLASH on NORs and in case of NAND, to small size as it could be. Will be fixed in next version. Sorry. ^^

 

[andshrew]

@Berion I'm getting a headache from doing bytes to GiB and GB conversions.

I wonder if the PS3 OS might need the partition size to be an exact number in GiB.

I tried -1000MiB from the end of the partition and this didn't work on the PS3 with the 0KB free showing. This is 316608430080 bytes, or 294.86GiB. This partition is smaller than when I previously successfully set it to exactly 295GiB (using growfs -s 295g rather than specifying the bytes).

So:

Size (Bytes)	Size (GiB)	Works in PS3
316608430080	294.86	No
316753838080	295	Yes

[THEAD] [/THEAD]

Although looking at the image of the 60GB drive, both the partition and file system there are 57595707392 bytes (53.64 GiB) and that works... perhaps it only becomes an issue over 100GB. I guess I could let the PS3 format the 320GB drive and then see what size the partition and filesystem is then.

Edit:- the 320GB drive formatted by the PS3 is also the full size of the partition (317656989696 bytes, 295.84 GiB)

Here is the partition table from that: the length of USERDATA and start of CACHE are different to our manually edited one.

andrew@mint:~/ps3$ sudo dd if=/dev/mapper/ps3hdd bs=8 count=125 status=none | hexdump -C
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000010  00 00 00 00 0f ac e0 ff  00 00 00 00 de ad fa ce  |................|
00000020  00 00 00 00 00 00 00 03  00 00 00 00 00 00 00 02  |................|
00000030  00 00 00 00 00 00 00 08  00 00 00 00 00 08 00 00  |................|
00000040  10 70 00 00 01 00 00 01  00 00 00 00 00 00 00 0b  |.p..............|
00000050  10 70 00 00 02 00 00 01  00 00 00 00 00 00 00 03  |.p..............|
00000060  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000000c0  00 00 00 00 00 08 00 20  00 00 00 00 24 fa ea 80  |....... ....$...|
000000d0  10 70 00 00 01 00 00 01  00 00 00 00 00 00 00 03  |.p..............|
000000e0  10 70 00 00 02 00 00 01  00 00 00 00 00 00 00 03  |.p..............|
000000f0  10 20 00 00 03 00 00 01  00 00 00 00 00 00 00 03  |. ..............|
00000100  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000150  00 00 00 00 25 02 ea a0  00 00 00 00 00 3f ff f8  |....%........?..|
00000160  10 70 00 00 01 00 00 01  00 00 00 00 00 00 00 03  |.p..............|
00000170  10 70 00 00 02 00 00 01  00 00 00 00 00 00 00 03  |.p..............|
00000180  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000003e0  00 00 00 00 00 00 00 00                           |........|
000003e8

I still think it's got to be something quirky with the PS3 OS and sizes that it expects the partition to be, rather than an issue with UFS itself.

What I'll perhaps try next is setting the partition table to match this one, and then see if growfs to the maximum size works.

Edit 2:-
For info, the difference between p2 length and p3 start on both my 60GB and 320GB drives when formatted on the PS3 is 524320, whereas the expander script is setting the difference to be 524312.

 

[Berion]

@andshrew That's sound strange even more. :/ But why do You calculating GB/GiB in the first place? I believe all tools which using M, G, T etc. counts by 1024, not 1000. Even if displaying eg. GB, because in IT, we always using SI description of 1024 counting. And because it was misleading, new units has been introduced but still not many projects using it. Counts by 1000 however using damn media producers but this can be bypassed by checking block size and multiplying it by 512 which results in bytes. This is far less cancerous than 1000 stuff "converting" to 1024.

Positions will be different because script don't using any padding (empty spaces between partitions and tables). I don't know why Sony using it and why they have different size on different consoles and/or HDD. Maybe that is the key here? But I completely have no idea how to deal with that because I don't know from what depends size and their existence in the first place. In addition, we still have flags which we don't know what means in PS3PT. I leaving them intact but maybe they are somehow related to that problem?

Overwriting "dirty disk" by first few GiB of "small but valid is sufficient". Why so much? Because UFS table can be such large. If You overwrite only partial of it, it will produce mixed and broken stuff beyond repair. Of course Cache partition be broken too, but that's not an issue since it is created from scratch anyway.

- - -

PS3 HDD Expander v0.5:

[f] Fixed critical bug with UserData start and length LBA. Now it is read from partition table instead using constant value (which turns to be different on different models for unknown reasons). Now should works always on all models.

[+] Added running FreeBSD option. This checking "${HOME}/ps3/storage/vm/freebsd.qcow2" existence and downloading it if not found and run vm already set up. User must have installed qemu-system-ppc and zstd.