“Mounting the PS3 internal memory on Linux”

Introduction
In this tutorial you will learn how to mount a PlayStation 3 Hard Drive on a Linux computer. The distribution
on which the text is based is 64 bit Linux Mint with Cinnamon desktop environment – it does not require
installation. What is required is a console with any so-called Custom Firmware uploaded (only to obtain
special key).

At this point, I'd like to warn e-fascists and all sorts of warriors for the purity of the firmware: hacking the
console is an obvious violation of the license, but not yet software piracy… Digital piracy is the domain of
those seeking thrills on copies of games that were not purchased by them – which of course I advise against.
This guide is directed to computer forensics and gamer enthusiasts who care about ultimately original firmware
or just those who want to access data on the PS3 hard drive after its tragic, untimely death (BGA/IHS
problems, bad blocks on NAND/NOR Flash etc.). Software purists and those sensitive to IT obscurity are asked
to leave (though they will probably regret it ;)).

As you may know, the PS3's internal memory is encrypted with keys unique to each individual model
(except for all GECR models). It has a custom partition table and – depending on the model and setup – up to
nine partitions. The purpose or content of all are unknow, so I will focus only on the basic ones ie, "dev_hdd0"
where there is user data, part of the system, configuration files, swap file and the "dev_flash2" where there is,
among other things, a file with the settings of the console and its users (present only on models with NOR
memory).

Above, for the curious, a listing of the hard drive logic in the PlayStation 3. Source: psdevwiki.com.
Magic keys and environment preparation
From the introduction, you learned that there are unique keys, that is, that each PS3 console (in fact, its
motherboard) uses to encrypt, for example, the hard drive (this is why the HDD of one console can not be read
on another without the mandatory formatting, and thus encrypt it with the keys for that console).

One of these keys is EID Root Key (hereafter I will use the abbreviation ERK), from which, using the attached
script, you will generate a pair: ATA Key and VFLASH Key.

There are various methods to obtain the ERK, the one I described applies only to CFW Rebug!

1. First, on the PS3 install and run the program Rebug Toolbox. Of course, you need to have CFW installed on
your console (official firmware, etHANol and HFW + Homebrew Enabler do not allow it) with support for the
required syscalls (I recommend the latest Rebug REX or Lite).

2. Go to the "Utilities" category and select "Dump eid root key". The console will double-beep and reset, and
the key will land in "dev_hdd0/game/RBGTLBOX2/USRDIR/".

3. Using a file manager (such as multiMAN), copy the "eid_root_key" file from there to the flash drive. You
can also use an FTP client if you have a connection configured and an FTP server running in the background.
Additionally, rename the file to "eid_root_key.bin".

4. Go back to your computer and create the "ps3" folder, and inside it, the folders "dev_hdd0", "dev_hdd1",
"dev_hdd2", "dev_flash1", "dev_flash2" and "dev_flash3", which are the future partition mount points that have
the same names as the PS3 environment.
5. Download and unzip the PS3HDD Keygen script, change it's attributes to executable and drop it into the
"ps3" folder along with the ERK.

6. Download the bswap16 kernel module ("bswap16_aio.7z|bswap16-ecb/bswap16-ecb*.ko") or compile it

yourself from source, as those particular one will only fit the default kernels in various of Linux Mint
distributions – just open up a terminal, go to its "source" directory and type "make"). Remember also to give it
the executable attribute.

7. Run the key generator (i.e. double-click on it and select "Open in terminal") then select the console model
where the key came from and the hard drive.
8. After everything is done, in the ps3 folder you should see the files "ata_key.bin", "vflash_key.bin" plus the
other keys and seeds that were involved in the process (you can throw them away, they won't be needed
anymore).
On-the-fly decryption and partitions mounting
The most stressful part is yet to come – just a dozen or so lines to type and the gates to the drive will open.

• If you are going to attach a mirror image of your PS3 hard drive, you will need to pin it as a device. To
do this, type "losetup loop1 /home/mint/ps3/disk.img". Of course, this is just an example – you must
enter the location and file name as you have it.

• If you are going to connect a real media device (preferably directly to the SATA controller, without any
USB enclosure), you should first use "lsblk". This will give you the device name ("/dev/sda",
"/dev/sdb", "/dev/sdc" etc.). In the tutorial I use "/dev/sdx", but of course this is just an example, so be
careful.

1. Switch to root rights by typing "sudo su" and confirming it with your user password. All further actions
require elevated privileges, so instead of typing sudo every time, it's more convenient to switch permanently.

2. type "insmod '/home/mint/ps3/bswap16.ko'", this will load the necessary kernel module which will be used
to create a mapper where the bit order will be changed on the fly from Big Endian to Little Endian.

3. Then type "cryptsetup create -c bswap16-ecb -d /dev/zero ps3hdd-bs /dev/sdx". If this is a disk image then
replace sdx with loopx (for example, instead of sda (which means real HDD on first SATA port) choose loop1
(if loop1 is currently free)).

4. You are now faced with a crucial choice. Depending on the type of your console, you need to choose an
appropriate algorithm and key length.

• For Fat models (both NAND Flash and NOR Flash), enter:
"cryptsetup create -c aes-cbc-null -d /home/mint/ps3/ata_key.bin -s 192 ps3hdd /dev/mapper/ps3hdd-bs"

• For Slim models, enter:

"cryptsetup create -c aes-xts-plain64 -d /home/mint/ps3/ata_key.bin -s 256 ps3hdd /dev/mapper/ps3hdd-bs"

5. In the next step, type "kpartx -a /dev/mapper/ps3hdd".

6. Now check the mapping points with "ls -la /dev/mapper/". You should see "ps3hdd", "ps3hdd1", "ps3hdd2"
and "ps3hdd3" redirected to "/dev/dm-*".

On consoles with NOR memory, "ps3hdd1" is VFLASH (virtual flash). Since CECHHxx models, Sony
abandoned the 256 MiB NAND memory on which all on-board software (firmware + OS) had previously
resided in favor of 16 MiB of NOR. The rest was moved to a hard disk partition, which is conventionally called
VFLASH. On consoles with NAND memory, on the other hand, this mapper corresponds to "dev_hdd1", a
2GiB partition for cache. On all models, the invariant "ps3hdd2" corresponds to "dev_hdd0" (which is the users
partition or so called GameOS partition). Since on "NORs" "ps3hdd1" occupies VFLASH then "ps3hdd3" acts
as "dev_hdd1". And if you have e.g. Linux installed on your hard disk (in the official way, i.e. using Other OS)
then there will also be "ps3hdd4" corresponding to "dev_hdd2" (on consoles with NAND memory it will get the
"ps3hdd3" allocation).

Depending on whether the drive comes from a NOR or NAND console, and whether Other OS is installed (up
to and including fw 3.15, Other OS+ is a scene hack for all newer fw and in theory only allows installation of
the system on USB), the list of mappers will vary. The guide is largely based on a console with NOR without
OOS and only for this tandem you can unreflectively rewrite tutorial scripts. You can tell what's what by the
size (VFLASH is always 256MiB, cache always 2GiB, user partition the largest, and the Linux partition as
much as the system itself allocated during installation).
7. If you are going to access data on a virtual flash, then you need to create an additional mapping. Since
VFLASH is encrypted twice, you can only do this after decrypting and mapping the “regular partitions” (which
you have already done above). Obviously, ignore steps 7 and 8 if your PS3 has NAND memory!

"cryptsetup create -c aes-xts-plain64 -d /home/mint/ps3/vflash_key.bin -s 256 -p 8 ps3vflash /dev/mapper/ps3hdd1".

8. Now type "kpartx -a /dev/mapper/ps3vflash" to map all virtual flash memory partitions.

9. If all went well, you are now ready to mount the filesystems (you created the folders in the ps3 directory
before to use them now).

If you have previously loaded the ufs2 kernel module for writing (which this tutorial doesn't cover yet) then
replace "ro" with "rw".

"mount -t ufs -o ufstype=ufs2,ro /dev/mapper/ps3hdd2 /home/mint/ps3/dev_hdd0"

The following partitions have FAT12, FAT16 and FAT32 filesystems, so they will appear in the file manager for
you to click on and automatically mount. Don't do this, however, as you may have trouble unmounting them
later (I don't know why). It is safer to do this by typing in the terminal:

"mount -t vfat /dev/mapper/ps3hdd3 /home/mint/ps3/dev_hdd1"

"mount -t vfat /dev/mapper/ps3vflash2 /home/mint/ps3/dev_flash1"
"mount -t vfat /dev/mapper/ps3vflash3 /home/mint/ps3/dev_flash2"
"mount -t vfat /dev/mapper/ps3vflash4 /home/mint/ps3/dev_flash3"

Be careful with the order of the VFLASH mappers! It may be different than mine. dev_flash1 will always be
~200MiB, dev_flash2 16MiB, and dev_flash3 512KiB.

In my case, the PS3 hard drive is ~4GiB image (which is BTW the minimum capacity the console accepts).
10. Congratulations! From now on, you have gained access to all encrypted partitions on your PS3 hard drive.
Remember, however, not to take ownership of them or change permissions at all. Always manage your data
as root (the contents will be invisible to normal users). After mounting the filesystems, you will be able to
explore the resources with the file manager (or in a terminal if that is more convenient for you).

On the left the contents of "dev_flash2/etc/", on the right "dev_hdd0/home/<user number>/".

A handful of interesting facts:

For example, the previously empty "dev_hdd0" folder, will start showing the contents of the console users
partition. That's where to look for it. If you've gone through this whole tutorial, but you're a "Windows clicker"
and you're afraid to even look at Linux ;) this may be confusing for you. Well, Unix systems don't mount
partitions in alphabetical order, they mount them where the user wants them, in whatever directory the user
wants them – and we both want e.g. the users partition on the PS3 disk (or its image) to be mounted in e.g.
"/home/<user>/ps3/dev_hdd0/".

Once you have access to the data on the HDD, it is a good idea to make a copy of your important data when
doing so.

"dev_hdd1" is a partition used mainly for games, but also for system updates (the PS3 unpacks the
"PS3UPDAT.PUP" package there). In special cases, it may happen that the console will not be able to complete
the update (it will stop verifying the unpacked data), or start it again, let alone boot up normally. In that case, all
you have to do is connect the hard drive to your computer, go through the tedious process I've described above
and delete the entire contents (which you can read about in a separate tutorial). Otherwise the only possibility
would be pointless formatting of the disk and losing all the data… which is what the service providers do in
such case or the unfortunate ones without EID Root Key.

The other VFLASH mappers do not have a file system and are most likely accessed through the console by
address. I don't know what specifically they contain or what they are for (other than those used by OOS). There
are empty spaces between some of them, which are perhaps just alignment, or perhaps have some other role.
Interestingly, there is one partition-mirror of NOR bones (could it be service?).
11. Once you've finished wading through the forbidden zone of your PlayStation 3's hard drive, it's imperative
that you dismantle everything one by one (unmounting order doesn’t matter). You shouldn't just turn off the
computer or unplug the drive (and you absolutely can't do this if you've mounted any writable partitions!).

"umount -l /home/mint/ps3/dev_hdd0"
"umount -l /home/mint/ps3/dev_hdd1"
"umount -l /home/mint/ps3/dev_flash1"
"umount -l /home/mint/ps3/dev_flash2"
"umount -l /home/mint/ps3/dev_flash3"

"kpartx -d /dev/mapper/ps3vflash && cryptsetup remove ps3vflash"

"kpartx -d /dev/mapper/ps3hdd && cryptsetup remove ps3hdd"
"cryptsetup remove ps3hdd-bs"

Unplug loopx of course only when the PS3 disk image is there.

If you have done everything correctly then the console will never learn about the transplant while she are
asleep. If not, you will face a forced disk formatting and loss of all data when you return. Good luck! :)
Frequently Asked Questions
That is, the hurdles life can throw at your feet.

P: „I have the original firmware, how do I read the ERK?”

O: You can't read it. The official software does not allow you to run unofficial programs.

P: „I have original firmware with HAN or HEN, how do I read the ERK?”
O: You can't read it. etHANol (HAN for short) does not allow you to run unofficial programs and HEN
(Homebrew Enabler for short) does not allow you to access all the console resources at this time.

P: „I have a dump of the NAND/NOR with the firmware, how do I read the ERK?”
O: You can't read it. The ERK is part of the Meta Loader (metldr), which is encrypted with a key (probably)
located in the CPU, so you would have to extract it from there first somehow. No one has succeeded in this feat
yet.

P: „I have a Drive Key or decrypted metldr dump. Can I extract the ERK from that?”
O: You can. The Drive Key, the key used to marry a drive or when emulating a drive, contains an ERK and you
can extract it with this script. In the case of a decrypted metldr (e.g, obtained in the debug retail console
conversion process using the metldrpwn exploit), the ERK is its first 48 bytes.

Of course if you have no way of reading the ERK then you have no way of reading the DK or decrypting the
metldr. The above information is useful for those who have used ODDE or CEX2DEX in the past, are now on
OFW, but still have those files hanging around in a backup somewhere.

P: „I connected the HDD to Windows and it asked to initialize the disk, I agreed…”
O: By “initialize the disk”, Windows means overwrite the partition table. This can still be fixed, but it is
material for a separate tutorial, as it requires creating a sector-by-sector image, formatting the disk in the
console, reading the array, replacing the one in the image with it, uploading the crafted image and next time
reading the messages carefully. ;)

P: „Can I use someone else's ERK, ATA or VFLASH key?”

O: You can't, they are unique to each console unit. The exception is the GECR (Arcade) models, but these are
not sold at retail (as the name suggests, they are used as arcade machines).

P: „I changed to a different drive, can I read both using the same key?”
O: Yes, because the keys the console uses to encrypt it have not changed…

P: „I changed the console and put the old disk in it, can I read it ERK from the old console?”
O: You cannot because it is encrypted with the keys from the new console…

P: „Can I change the ERK, ATA or VFLASH key in the console?”

O: You can't.

P: „Why does cryptsetup display: "device-mapper: reload ioctl on failed: No such file or directory"?”
O: Because you made a syntax error.

P: „Can the same thing be achieved on FreeBSD?”

O: I am not yet familiar with BSD family systems, perhaps you can use geom/geli tools. Undoubtedly an
advantage is the default and stable support for UFS2, which is the native file system for FreeBSD (on which,
incidentally, CellOS, the PlayStation 3 operating system, is based).

P: „When I insert a disk into the console, this one wants to format it! Why?”
O: Because the file system or table has been corrupted. There could be any number of reasons for this, such as
that you did not unmount the partition mounted with rw privileges.
P: „I did everything as per the tutorial, but I don't have ps3hdd1, 2 and 3, why?”
O: Because the disk was not decrypted. Probably an incorrect key. If the ERK and the hard drive are from the
same console, it is possible that the encryption or key generation is done in a different way than for the models
we know. Type "hexdump -C /dev/mapper/ps3hdd | head -8", if it displays chaff and not mostly zeros, it means
the decryption is incorrect.

P: „Is absolutely the entire HDD encrypted?”

O: No. There are small “islands” with just zeros, indicating that the PS3 does not use those sectors. I don't
know why this is the case, but it can be used creatively (for example like that). :)

P: „What is the difference between "bswap16-nbd.elf" and "bswap16-ecb.ko"?”

O: The first one is a special version of nbd-server for converting BE to LE, the second one is a kernel module
that does the same thing, but without the nbd-server and nbd-client, which had to be in a specific version (the
newer ones stopped working). The guide you read is based on bswap16-ecb because it can be used on a live
distribution and it compiles easily. The previous solution is deprecated.

P: „Does it have to be this complicated?”

O: If you want to access absolutely everywhere on this disk it has to be. Not counting bswap16, you are using
the usual tools found in any Linux distribution. The guide is for people who are also interested in writing to
these partitions and/or detailed analysis, and/or fixing stuff. If you just want to read contents then use HDD
Reader for Windows or Linux (of course both also require ERK but not require to calculate ATA and VFLASH
keys).

P: „Can I get ERK on CFW and then upload the official fw and pirate games that way?”
O: If you mount dev_hdd0 as rw then you can upload even pirate games, but they won't work because digital
content requires correct executable file signatures, correctly generated and signed licenses, and discs (mounting
images or directories requires programs or plugins signed with long blacklisted keys or keys for debug
consoles). In conclusion, that's not what PC disk access is for! If you're interested in console piracy, there are
much simpler ways than lashing out with “penguin” in a terminal…

P: „For what, then?”

O: If you read the ERK and IDPS keys in advance on CFW, then even on OFW (the original software) you'll
have full control over all your data (including rewriting saves and trophies for any user, making copies, or
transferring data to another PS3 in the event of the sudden death of your current console). Without these keys,
you are doomed to the mercy and disfavor of the company and even the failure of your toy.
Special thanks

 To graf_chokolo/Glevand for invaluable contributions to PS3 reverse engineering and Linux support
(it's thanks to him that multipath-tools/kpartx supports PS3 partition tables).

 To 3141card for the HDD Reader and a number of comments on the algorithms used.

 To sguerrini97 for correcting my old script and rewriting dm-bswap16 from the original kernel module
(incompatible with current kernels) to a program that communicates with the nbd-client (on which I
based an earlier version of this tutorial).

 To Decaf Code for bswap16-ecb kernel module, compatible with the current kernels.

 To einsteinx2 for the tutorial describing how to unlock 8% free hard disk space, and thus for the
inspiration to write this text.

 To Yugonibblit for capturing the tables from CECHG01 in order to validate the algorithms used to
generate the ATA Key for consoles with NAND.

 To mlody95pl for pointing out the bug in the tutorial and compiling the UFS module.

Berion
2018-10-28 / 2022-04-16

The document has been automatically translated from Polish to English using DeepL.

You may distribute this guide on any site, only as an unmodified PDF.
All rights reserved, modification and/or copying content without permission prohibited.