PS3 [Tutorial] HDD mounting and decryption on Linux

Hi,

UFS2 support in kernel is experimental, so by default is read only. To be able to write into UserData partition, You need to compile ufs.ko with write flag, unload old module, load new, mount partition as ro then remount as rw (Mounter doing remount by default if it is not Read Only version).

"KO Manager" script allows to compile it but at the end it doesn't work anyway (for unknown to me reasons). It still mounting read only.

Better (much stable) is exposing this mapper to Net BSD in QEmu vm.
Does anyone know what to do in this case? Or better yet, who has arcade images and how to install them?
Click to expand...
If I understood You correctly, You have GEX PS3 and some disk image? Why You want then modify this image instead write it to target disk?

If that's the case, then unmount everything and use below template:
Code: 
sudo dd if=${HOME}/disk_image.raw of=/dev/sdx bs=64M status=progress
 
Last edited:
Thanks, the disk I have is corrupt and I have no image of it, that's why I have to correct the game files. I don't know how to use ufs.ko but I will look for and read a tutorial that teaches how to use it. Thanks, I'll be here again if I can't fix this HD. :D
 
It's been almost 6 months since I restored my PS3 drive using Linux and FreeBSD. Everything has - seemingly - been working fine on the PS3 side.

However I wanted to edit a file on the internal drive today, so I went to mount it under FreeBSD for the first time since doing the recovery.

Interestingly, it wouldn't mount:

Code: 
Superblock check-hash failed: recorded check-hash 0x52ace23d != computed check-hash 0x43f9fa48
mount: /dev/vtbd1: Integrity check failed

I'm running fsck on it at the moment, it's been going over 30 minutes... even in it's original broken state it never took this long to run fsck. It's fixing errors like:

Code: 
INODE CHECK-HASH FAILED I=7765598  OWNER=2675071421 MODE=63146
SIZE=3794089125778566400
FIX? yes

BAD FILE SIZE
UNEXPECTED SOFT UPDATE INCONSISTENCY
 I=7765598  OWNER=2675071421 MODE=63146
SIZE=3794089125778566400
CLEAR? yes

It seems like it must be touching the inode for every file...

I shall report back if it (and my data) survives. :tranquillity:

Edit:
Just to add, the sizes that the INODE is reporting make no sense. They are bytes, as far as I know, which would make this one file ~3794 PB.

They were not like this when I originally restored the data, so something the PS3 has done over the last 6 months seems to have changed the inode file size on pretty much every file in the file system. I don't recall it crashing in that time, so it hasn't done a file system repair. The only thing of interest that has happened is a firmware update release. As above, the PS3 hasn't shown any problems at all, I've only come across it now because I wanted to edit a file in the file system.
 
Last edited:
@andshrew Oh, but that means is not safe to use even NetBSD 6.0 for writing and tweaking operations.

Maybe PS3 performing silent fsck during update? Plus using custom hashing algo and that's why not matching? But then, the same problem will occur during reading yet untouched by anything else than PS3 itself that partition. @haxxxen

Thank You very much for report and Your time.
 
It ended up taking some 30+ hours for fsck to finish. Unfortunately I didn't realise until it had been running for quite a while that by it outputting to the console it was slowing the process down considerably, and once I redirected output to a file it was accessing the file system at a much faster rate.

So, it was identifying and fixing inode errors such as:
Code: 
INODE CHECK-HASH FAILED I=83979193  OWNER=1153435563 MODE=114122
SIZE=3840234177375163744 
FIX? yes
BAD FILE SIZE
UNEXPECTED SOFT UPDATE INCONSISTENCY
 I=83979193  OWNER=1153435563 MODE=114122
SIZE=3840234177375163744 
CLEAR? yes

What I soon noticed is it was going sequentially through inode numbers, and the actual data within them is junk. The sizes, the owner, the mode - none of them make any sense.

So it would appear as if the PS3 is doing something (eg. perhaps trying to create a file) which is going wrong, and resulting in an inode being created with junk data. This has resulted in hundreds of thousands, if not millions of these bad records being created in the file system.

The actual real data seems to be fine. Once fsck had resolved all the errors and I could mount it under FreeBSD again, I was able to run a diff on the drive comparing it with my backup from 6 months ago. There is no significant data loss, with the only changes coming from games I've installed or uninstalled; or save files being changed etc. That's good news at least! I was able to then return the drive to the PS3, and that didn't seem to care at all that this huge repair had just been undertaken. It booted up first time, it didn't even want to do its own check.

A few additional comparisons I could do between now and when I completed the restore. I looked at SSD wear levels, which is at 577GB written. My restore was ~500GB alone so whatever is happening, it doesn't appear to be causing excessive writes on the drive.
The fsck output tells you how many fragments the file system consists of. This has almost doubled from when I did the restore, originally at 9635 and now at 16659. So it is having an effect on the file system beyond creating inodes.

So the question is what's going wrong. A few possible things...
  1. Mounting the file system under a modern FreeBSD (and using fsck on etc.) has done something to the UFS2 file system that the PS3 may not be compatible with. As a reminder, the file system was created by the PS3. All I did was mount in using FreeBSD so that I could restore my files to it.

  2. It's a consequence of using an SSD with the PS3.

  3. It's a consequence of using a large drive (1TB).

  4. A combination of all of the above.
It would be interesting to know if the file system would have eventually ground to a halt, had I just left it in the PS3. The most likely issue I can think of of is that it would eventually run out of inodes, especially if the PS3s disk utilities don't recognise this as a problem. The 1TB drive has ~122 million inodes based on how the PS3 formatted it. I am using ~380,000 (real data, not the junk inodes), so if it's generated millions of bad inodes in a 6 month period (where I haven't used it extensively, maybe 15 hours) it perhaps not unreasonable that it would use them all without intervention.

Anyway I thought I would share this as I found it interesting. I'll try and connect it up again in a couple of months and see if the same thing is continuing to happen.
 
I'm giddy with excitement right now so this may be a bit nonsensical, but I thought this might be nice to share. Apologies if someone already suggested it and I was just blind.

I tried various ways of restoring a drive I accidentally nuked by letting Windows initialize it, but ran into repeated issues with certain files not copying (the LittleBigPlanet games store save data inside the game's install folders, but the files are owned by "Nobody" and Linux Mint refused to copy them), or data corruption issues when following a more involved guide that uses Qemu to emulate FreeBSD to copy the files to a new drive.

After about a month of messing around and trying varying options, I decided to take a shot at just botching the old drive back together, and it actually worked. The procedure I followed was:

Code: 
Mount the initialized drive using "PS3 HDD Mounter (Missing PS3PT).sh
Make a copy of dev_hdd0 using "sudo dd if=/dev/loop41 of=dev_hdd0backup.img status=progress"
Make a copy of dev_flash2 using "sudo dd if=/dev/loop40 of=dev_flash2backup.img status=progres"
Unmount the drive using  "PS3 HDD Umounter (Missing PS3PT).sh"

Format the same HDD using the PS3, shut down the PS3 when it reboots to the PS3 setup window.

Mount the newly formatted drive using "PS3 HDD Mounter.sh"
Copy dev_hdd0 back using "sudo dd if=dev_hdd0backup.img of=/dev/mapper/ps3hdd2 status=progress"
Copy dev_flash2 back using "sudo dd if=dev_flash2backup.img of=/dev/mapper/ps3vflash3 status=progress"
Unmount the drive using "PS3 HDD Umounter.sh"

When I started the PS3 again, it was ready to go. When I tried updating a game, I ran into an error 0x800233E8, which refers to either an internet service problem or data corruption during an update. I do not know whether wifi flaked out during that, or there was data corruption, but after doing a filesystem repair from the recovery menu, I was able to update the game just fine and it launched without an issue afterwards.

I did just run into an error in LittleBigPlanet 3 where it gives me a popup saying I don't own DLC that I definitely do, so I'll have to check what that's about. This poor HDD has seen some stuff in my attempts to get things working again :P


Sorry for the ramble, I hope it might help someone in the future. Thanks to Berion and the many other folks that mess around with this stuff for providing fools like me with the tools needed to undo our mistakes. <3
 
@Parrotte Hello.

With root permissions You shouldn't have any problem to copy any data. What You did is like dropping atomic bomb to get rid of ant nest. :D

However, doing that, You shouldn't have any issues on PS3 side in the first place. I believe, that UFS2 was already broken due to various of factors.

You are welcome.

PS: For future, just make copy of first 36 sectors to avoid that in case of similar wipe out happen again. ;) This covering up GPT which Windows can write over PS3PT. Tasker script, option no.4.
 
Last edited:
Berion said:
@Parrotte Hello.

With root permissions You shouldn't have any problem to copy any data. What You did is like dropping atomic bomb to get rid of ant nest. :D

However, doing that, You shouldn't have any issues on PS3 side in the first place. I believe, that UFS2 was already broken due to various of factors.

You are welcome.
Click to expand...
I tried copying the data in question with Dolphin, both normal and opening the folders as root, and with the 'cp' command in terminal. Even with sudo, it outright refused to copy these files. And I couldn't get UFS writing working with gmipf's scripts either. This was my first ever experience with Linux though, so I might've missed something important.

gh44biR.jpg

Don't ask me why the LBP save files are called "littlefart" and "bigfart". I guess one of the devs thought it was funny.

Berion said:

PS: For future, just make copy of first 36 sectors to avoid that in case of similar wipe out happen again. ;) This covering up GPT which Windows can write over PS3PT. Tasker script, option no.4.
Click to expand...

I checked the drive in HxD and a lot of sectors were gone only to be interrupted by a message saying "Drive is not a bootable media" or something like that, I think I did more than just initialize it. I bunged it up nearly half a year ago, I don't quite remember what I did. I tried to do the sector replacement trick back then, but no dice, data remained corrupt.

I assure you, the first thing I did when I found out the data was all back earlier today is take the drive out, connect it to Windows [I]without initializing it this time[/I], and make a raw disk image. Aint making this mistake again...

[S][/S]
Whether or not I took the easy or the incredibly much more overcomplicated route, I'm just happy I got it working again! :D
Now that I have successfully got those files back on there, I can now procede to get them off again in the right way.

Funny thing is, I originally connected the drive to the PC to make a safety backup because I was worried that installing CFW might damage the files on it. I ended up needing to CFW just to save my files.

Once again, thank you for creating and/or collecting the scripts! They're a data-saver! :love heart:
 
I have exactly that GameID and no problems with backup. Im confused.

Yeah, I spot that too, when I preparing tutorial for "Mega Patch".

It is standard output in MBR blob. Should be in first 512 bytes. So I dunno what You could do more with that disk if have more than one. ^^

Well, it is fine what You did if wanted working environment, not just only getting data out. Very similar way but for ppl without ERK:
https://www.psx-place.com/threads/tutorial-fixing-windows-disk-initalization.27599/

You're welcome.
In future updates I will focus on UFS2 rw module (my script not working as intended, produced module is still ro for unknown to me reason) and Backuper script. Besides that, toolkit is quite finished. At least until we get ERK on eMMC models.

PS: It is not Dolphin but Nemo. On screenshot. ;)
 
Hmm. While I wouldn't hesitate to go through the quick guide, I chose the decryption helper package just to try this out.

Read-only works fine, but I can't mount as RW for some reason; the "PS3 HDD Mounter" script mounts as read-only.

Also, while it didn't really change anything, the `crc32` binary used in the script wasn't present on my system, installing `perl-archive-zip` fixes that.

PS3: CECHLxx (NOR)
Host: Artix Linux 6.9.7-zen1-1-zen
 
Last edited:
@lightwo Toolkit was tested only on Mint. Other distributions could not have necessary tools. I trying sticking to binutils as much as possible, the same with bash (well, except "-e" which eg. on Ubuntu for WSL2 doesn't work).

To mount user data partition with rw, You need load ufs.ko with unlocked flags for RW. Otherwise, remount will return errors.
 
Hello Berion i've been following your thread from 2019
i have ps3 fat and this have 80gb hdd i bought that on 2011 and i had my old my family videos and pictures on it.
I saved hdd untill now, i bought ps4 in 2019 and i was forgot if my videos still in ps3 i forgot psn account password and alot of firmware update requiered.
actually i dont remember what caused my ps3 to this happened after update or maybe i wiped ps3 and all data was gone,
but i didnt even overwrite anything. i was thinking this hdd to clone and then jailbreak ps3 with new hdd to try find rootkey and decrypt in ps3 emulator as you said other thread.
And finally 2 week ago i bought 500gb hdd for try your method because when i searching that in 2018 there was no one tried with video or with tutorial,
I'm lucky your thread still alive.
I have hdd docker offline clone and i cloned ps3 80gb hdd to 500gb hdd and its sector by sector i guess
and i will download linux mint can i use rufus to install linux mint to usb flash thumb drive because i will remove all my sata hdds on my pc and then
i'll plug cloned 500 gb hdd on sata then try your method but i confused im afraid if i do something wrong.
Can you help me what am i doing wrong? Now what i need to do?
 
@t3llO Hello.
Data isn't gone just like that in assumption, physically disk is fine. Even if PS3 rejecting it, it is still high chance to access to and retrieve data (as long as UFS2 on user partition isn't broken enough, but then, still you could carve data from decrypted mapper by signature scan, plus UFS2 trying to keep data unfragmented which helps us a lot).

The only you need is EID Root Key (ERK) and of course disk or its sector by sector and uncompressed image. It is fine if you will write that image to another disk but not really necessary. You can just copy image file to any existing filesystem and on Linux side just attach it to loop. Modern Linuxes, mounting external storages under "/media", so lets say, you can do that:
Code: 
sudo losetup -f "/media/somelabelorguidofthatstorage/ps3hdd.raw"
And it will start be displaying on devices list as i.e "/dev/loop2" (that's then the device by which you feeding scripts).

Better do not tamper with source media like e.g real HDD from which you need to retrieve data. Also, if you made image, keep it in safe place as yet another copy (so in summary: two copies, one for work, one for just in case, and original disk in case unpredictable disaster like hw or user failure). That way, You will safe yourself from loss.

On PS3 side, use different disk of course for everything leading to ERK reading.

About ERK, it is possible to read that key only on CFW. While currently all firmwares and all models can be hacked in one way or another, not on all models CFW can be put. Only on all so called Fat models, and in case of so called Slims on all CECH-21xx and early 25xx. Not late 25xx and not on all 3xxx/4xxx.

You can write Linux Mint image with Rufus on e.g USB and boot from it PC. That's fine (use persistent option with around 1GiB, that makes live session mounting that small image as home, so you will not loose what you setup on it, or what you written (normally live sessions running fully from RAM and after turning off data changed is lost)).

Bunch of links you should read:

If you will upload disk image somewhere (in parts by maximum 20GiB; i.e you can make uncompressed archive or just make split disk image) with checksums (CRC32, MD5, whatever) for data integrity control after downloading; and with ERK (but send in different information channel than image to avoid data stealing by another ppl); then I could retrieve those files for You. Yet of course in such case I will charge You for my time. Choose your poison. ^^
 
Last edited:
Hi @Berion , a few years ago my PS3 suddenly froze in XMB, once I restarted the console it got stuck while trying to rebuild system files.
I have followed your guide to get my data from the dead HDD to a new HDD and save my ps3 data, I got the ERK and managed to mount the original HDD on Linux.

I have opened nemo with root privilages (with red ribbon), I can see all my files but some of them cannot be copied i.e. game files, the owner of those files is listed as "nobody". Similar to @Parrotte 's problem.
I am connecting the original PS3 HDD trough SATA, it has never been initialized, I have only created a raw copy of it.

Do you know what causes this issue and how to fix it?
Thank You, for your work on this amazing guide.
 
@HIND-D Hello.

It is possible that filesystem is damaged in a way which results that behavior of ufs module. You can try as last resort, copying userdata partition (on PS3 mounting as "dev_hdd0/") from mapper on which is decrypted - to get decrypted dump of that partition - to feed dedicated recovery software supporting UFS2 which maybe would deal with it with success (none of them will decrypt encrypted, so that's why you need to make image decrypted). Or in much more difficult scenario, use NetBSD 6.0 (it must be that specific version).

In other words, do:
  1. Run "PS3 HDD Mounter.sh" script (read only option).
  2. Mount PC partition with enough free space to store nearly whole PS3 HDD image. If that be partition used by Windows, before run Linux, turn off hibernation and reboot Windows to take effect; it is because so called Fast Boot not leaving filesystems in clean state and Linux will damage it if you will ignore his warning.
  3. Run "PS3 HDD Dumper.sh", choose that destination (should be in "/media/<label or GUID>/") and then option no.5 to dump GameOS. Default read chunk is set to 64MiB so you can get at the end of process error telling you it is not enough data to read last one - that is normal and not invalidating full dumping.
  4. On Windows: https://www.psx-place.com/threads/files-recovery-from-gameos-partition.27603/

Thanks. You are welcome.
 
Last edited:
@Berion Hello again.

I got the dump and ran it through UFS Explorer, and it worked!
I got all my data back and put it in a new hdd, now my PS3 works again. I mounted the new hdd on Linux aswell, to see if I can access the game files now, and I can.
So it was due to damage done to the hdd and the filesystem, as you've said.

Once again thank you and everyone who worked on this problem.
 
You must log in or register to reply here.

Similar threads

Back
Top