PS4 [Tutorial] HDD mounting and decryption on Linux

Berion

Developer
I have put into it many hours to make it as much noob friendly as possible (included Linux new comers which doesn't understand well this environment).
  • "Montowanie pamięci wewnętrznej na Linuksie" - official Polish version
  • "Mounting internal memory on Linux" - official English version
  • PS4 HDD Decryption Helper - Toolkit which contains various of scripts
In case of some problems etc, don't be shy and ask. ;)

ps3hddddh_nemo_1-png.41908

ps3hddddh_nemo_2-png.41909

ps3hddddh_nemo_3-png.41910
 

Attachments

Thanks for creating this @Berion.

As with the PS3 drive, you can pass the decrypted UFS2 partitions through to a BSD VM for potentially easier write access than with Linux alone. It's even easier than with the PS3, with the PS4 CPU being little-endian it means you can just grab an AMD64 image of FreeBSD.

Passing the /user partition through to a QEMU VM:
Code:
sudo qemu-system-x86_64 -smp 2 -m 2g \
        -drive file="$HOME/Downloads/FreeBSD-13.2-RELEASE-amd64.qcow2",format=qcow2,if=virtio \
        -drive file=/dev/mapper/ps4hdd_27,format=raw,if=virtio \
        -nographic

For interest, the file system summary:
Code:
root@freebsd:~ # dumpfs -s /dev/vtbd1 | more
magic   19540119 (UFS2)
last mounted time       Wed Feb 21 19:31:30 2024
last modified time      Wed Feb 21 20:06:49 2024
superblock location     65536   id      [ 61be7cd9 00000001 ]
ncg     1226    size    232225792       blocks  228577187
bsize   32768   shift   15      mask    0xffff8000
fsize   4096    shift   12      mask    0xfffff000
frag    8       shift   3       fsbtodb 3
minfree 8%      optim   time    symlinklen 120
maxbsize 32768  maxbpg  4096    maxcontig 4     contigsumsize 4
nbfree  26838460        ndir    284     nifree  58062417        nffree  354
bpg     23680   fpg     189440  ipg     47360   unrefs  0
nindir  4096    inopb   128     maxfilesize     2252349704110079
sbsize  4096    cgsize  32768   csaddr  3000    cssize  20480
sblkno  24      cblkno  32      iblkno  40      dblkno  3000
cgrotor 0       fmod    0       ronly   0       clean   1
metaspace 0     avgfpdir 64     avgfilesize 16384
flags   soft-updates 
fsmnt   /user
volname         swuid   0       providersize    0

This is taken from a 512e HDD, note how fsbtodb is 3. So this suggests to me that PS4 OS does not have the same "fault" that the PS3 OS has where it configures this value incorrectly on 512e drives.

Code:
root@freebsd:/ # file -s /dev/vtbd1
/dev/vtbd1: Unix Fast File system [v2] (little-endian) last mounted on /user, last written at Wed Feb 21 23:37:54 2024, 
clean flag 1, readonly flag 0, number of blocks 232225792, number of data blocks 228577187, 
number of cylinder groups 1226, 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

Lastly, the command that FreeBSD suggests would create this file system:
Code:
root@freebsd:/ # dumpfs -m /dev/vtbd1
# newfs command for /dev/vtbd1 (/dev/vtbd1)
newfs -O 2 -U -a 4 -b 32768 -d 32768 -e 4096 -f 4096 -g 16384 -h 64 -i 16384 -k 0 -m 8 -o time -s 1857806336 /dev/vtbd1

Nothing more to add for now, I was mostly curious if they had fixed the 512e issue and it seems they did. :encouragement:
 
You're welcome.

So You have also hacked PS4. That's great news. :}

Hard to say it is issue in the first place. For outside environments, tests proves it is but for PS3 itself, rather not. ^^"
 
Hello! I have a question regarding the HDD keys. I have a ps4 pro, baikal, running FW9.00. As far as I understand, the scripts that parse sflash0 does not work here, as I'm unable to mount the drive using a key created that way. I've read that psxitarch should dump the keys, so I decided to try this, as I already had the distro installed. The key isn't there, but I'm not 100% sure if I installed v3 in a stock version, I might have used different kernel and\or intramfs, as I was installing using guides from ps4linux.

The module that should dump the key, where is it located? Should I create a new installation from scratch, or perhaps just change the kernel? Or should the only thing for me to do is to get the keys from the ps4 kernel dump, like the wiki suggest? If so, can you please shed some light on this - should I copy those 0x2000000 bytes from the offset defined in kern_off_eap_hdd_key and then reverse the bytes order OR reverse the whole dump and then copy its part. Any help would be greatly appreciated.
 
@ebol Hello. Indeed, Baikal's SFLASH0 extraction does not work because we don't know how to decrypt it outside PS4. If kernel dump made on PS4 is decrypted, then key can be extracted (but still, I'm not very certain about that).

I don't have hacked PS4 so I don't know either how it is resolved on Linux side. If it is part of system lower than userland or not. But I believe it is some module which dumping it because Linux not needs internal HDD access to anything to work.

Reversing on key only.

Just to clarify, you don't have "/etc/cryptsetup/eap_hdd_key.bin"?
 
Do you have a guide for backing up a HDD for people with no BD drive?
You have to clone the drive, iirc. As you probably know, HDD failure on a nobd PS4=brick unless you have an hdd backup. I was on the pkg-zone discord server for a while, and I think all azif told me there's no way to remarry a bd drive on the PS4 currently. I don't even think Sony does it if you were to send it in. You pretty much always get a refurbished unit.
 
Do you have a guide for backing up a HDD for people with no BD drive?
What specifically you asking? Could you elaborate more? Because above have not much sense to me. ^^" I don't see connection between HDD and ODD (BD >> Blu-Ray Drive?).

If Charles correctly understood you, then yes, you need make sector by sector copy and store it safely. By any tools (dd, IsoBuster, DMDE, HDD Raw Copy Tool etc.). That means also that you will not be able to restore it on smaller drive, and restoring on larger will not brings you unused space back. Plus, disk is assigned so you cannot restore image on different HDD, put it back to that console and boot console with it (I'm not super sure about that thou but I believe that works the same as on some PS3's).
 
Last edited:
yeah, your hdd doesn't have to be backed up for nobd, but it's recommended, because if the hdd fails, there's no way to reinstall the firmware. I believe that's the reason, so it's basically bricked.
 
I asked here on the forum about a ps4 with no BD drive and found a guide by lighting mods that it is recommended to clone the HDD sector by sector
But if I make a new HDD with the backup sectors it will not work?
 
I asked here on the forum about a ps4 with no BD drive and found a guide by lighting mods that it is recommended to clone the HDD sector by sector
But if I make a new HDD with the backup sectors it will not work?
afaik, it should work. lightning mods is the creator of the software for no-bd, I believe, so you should always follow his recommendations for software to use/steps and such things. I'm not too familiar with the mod, because I've never had a ps4 with no-bd. I just know that it's recommended to have a backup of your hdd in case your hdd fails at some point, because it will eventually.
 
Just to clarify, you don't have "/etc/cryptsetup/eap_hdd_key.bin"?
@Berion, sorry for late answer, went offline dureing the weekend. And no, it was the first thing I tried after reading upon this, there's even a shortcut for PS4 drive mount in the menu, but there was no key on that path.

I don't have hacked PS4 so I don't know either how it is resolved on Linux side.
I'm on a FW that supports the exploit, so I could, theoretically create a kernel dump, if the payloads are still valid. Have not tried it yet. I'll post on how it went, might as well try.
 
@ebol Would be great if you compare it with raw dump from HDD (/dev/sdx5 (for partitions order 1...31) or /dev/sdx3 (for partitions order 1-15)). That way you will know if or is already decrypted or just dumped like outside PS4.

On PC:
Code:
sudo dd if=/dev/sdx5 of=${HOME}/ps4hdd_kernel.img status=progress
 
@Berion I was reading your work on this again recently, and regarding the samu_hdd_key.bin. Do you have details of how you would actually get this from a 6.72 firmware PS4?
 
@andshrew I don't know the details. I have two PS4s, one on fw 8.03 due to dead ODD (maybe I can use on it PSFree, but no downgrade anyway) and one on newest fw. Also I never have access to dump with that key, so I based blindly on Flatz statement. Plus there is no such thing as "SAMU HDD Key" but temporary I name it that way (SAMU holds many keys for various purposes, but I dunno which is for what exactly).
 
@andshrew I don't know the details. I have two PS4s, one on fw 8.03 due to dead ODD (maybe I can use on it PSFree, but no downgrade anyway) and one on newest fw. Also I never have access to dump with that key, so I based blindly on Flatz statement. Plus there is no such thing as "SAMU HDD Key" but temporary I name it that way (SAMU holds many keys for various purposes, but I dunno which is for what exactly).

Ah, fair enough. The reason I ask is I had a low 6.x firmware PS4 which I hastly upgraded to 9.00 before realising these keys could only be obtained from 6.72. I understand there is a hardware mod I could attempt which would allow me to flip which firmware OS slot the system is booting from so that I could in theory go back, but it's quite involved and so I'm trying to figure out how you actually trigger the SAMU exploit to then determine whether it's actually worth doing the firmware reversion mod.
 
Back
Top