HDD Keys generating scripts

I have now tested the write mode of the UFS module in Linux with a BE UFS2 partition. I have created the BE UFS2 drive in a FreeBSD ppc64 qemu emulator. The write speed is very bad, I'm only getting 450kB/s max. I am using Ubuntu 16.04 with Kernel 4.15.0-59.
 
@gmipf Have You compiled ufs.ko as external module alone with write permission or whole kernel with ufs.ko with rw? Or maybe in 4.15 write is turned on by default?

On the horizon there is special fork of fuse-ufs, so even if ufs drivers are bad (didn't tested myself), then maybe this one would solve our problems. Currently testing. ^^
 
@Berion I have compiled ufs.ko as an external module without the whole kernel. Tested it again with a HDD instead of a USB flash drive. Write speed was 10MB/s this time.
But there is something wrong with the integrity of written files. I have written a file from the FreeBSD ppc64 guest to the HDD with:
Code: 
dd if=/dev/urandom of=/mnt/dummy.dat bs=1M count=100
And calculated the md5 checksum of dummy.dat.

Then I mounted it on the Ubuntu 16.04 host and calculated md5 again from same file and the file was different. I also have tried it in reverse order, copied a 500MB ISO file to the BE UFS2 HDD, calculated checksum, mounted it on the FreeBSD ppc64 guest and calculated again, the file was different again. Interestingly if I create a simple one liner with vi the file is in both directions the same but corrupted with bigger files.
 
I never testing writing in UFS on Linux. But be patient, easy solution soon will comes to light. Also on Linux but not via *.ko.

As You already know, this kernel module (at least in Your case) breaking data. And even 10MiBps is suspicious (should be around max write for target media minus difference from max write via connecting interface).
 
DEPRECATED
Use this script instead: https://www.psx-place.com/threads/ps3-hdd-decryption-helper.38281/page-5#post-362960


Is there anything new regarding rw access to PS3 HDDs?

Here are my notes I have found on my PC for the UFS2 rw kernel module, for those who want to try itself:

Install dependencies for building:
Code: 
sudo dnf install @"Development Tools" rpmdevtools dnf-utils ncurses-devel kernel-devel
rpmdev-setuptree


Install kernel source:
Code: 
dnf download --source kernel
sudo dnf builddep kernel-<version>.src.rpm
rpm -Uvh kernel-<version>.src.rpm


Build kernel module:
Code: 
cd ~/rpmbuild/SPECS
rpmbuild -bp --target=$(uname -m) kernel.spec

cd ~/rpmbuild/BUILD/kernel-<version>/linux-<version>

cp -v /lib/modules/`uname -r`/build/Makefile .
cp -v /lib/modules/`uname -r`/build/Module.symvers .
cp -v /boot/config-$(uname -r) .config
cp -v /lib/modules/`uname -r`/build/System.map .

make menuconfig

Select: File systems -> Miscellaneous filesystems -> UFS file system write support (DANGEROUS)
Save, overwrite .config and exit.

Code: 
make prepare
make archprepare
make modules_prepare     # For Fedora 35 and other Distro with newer kernel.
make modules M=scripts
make modules M=fs/ufs


Install kernel module (Fedora 30):
Code: 
sudo mv /lib/modules/`uname -r`/extra/fs/ufs/ufs.ko.xz{,.old}

sudo make INSTALL_MOD_DIR=extra/fs/ufs modules_install M=fs/ufs

Install kernel module (Fedora 35):
Code: 
sudo mv /lib/modules/`uname -r`/kernel/fs/ufs/ufs.ko.xz{,.old}

sudo make INSTALL_MOD_DIR=kernel/fs/ufs modules_install M=fs/ufs
If your ufs module path differs check with "modinfo ufs".

Mount with following command:
Code: 
sudo mount -t ufs -o ufstype=ufs2,rw /dev/sdb1 /mnt

And this if necessary:
Code: 
sudo mount -o remount,rw /mnt

Install kernel source:

First you need to add source-URIs to the sources.list. Just run:
Code: 
sudo software-properties-qt
(On KDE) and activate "Source code" on the first tab.

Code: 
mkdir kernel
cd kernel

apt source linux-source-<version>
sudo apt build-dep linux-source-<version>
sudo apt install linux-headers-generic libncurses-dev


Change directory to kernel source and show running kernel version:
Code: 
cd linux-*

cp -v /lib/modules/`uname -r`/build/Makefile .

uname -r


Set your Linux version in the Makefile
Example for my version 4.15.0-59-generic:
Code: 
VERSION = 4
PATCHLEVEL = 15
SUBLEVEL = 0
EXTRAVERSION = -59-generic


Build kernel module:
Code: 
cp -v /lib/modules/`uname -r`/build/Module.symvers .
cp -v /boot/config-`uname -r` .config
sudo cp -v /boot/System.map-`uname -r` System.map

make menuconfig

select: File systems -> Miscellaneous filesystems -> UFS file system write support (DANGEROUS)
Save, overwrite .config and exit.

Code: 
make prepare
make archprepare
make modules M=scripts
make modules M=fs/ufs


Install kernel module:
Code: 
sudo mv /lib/modules/`uname -r`/kernel/fs/ufs/ufs.ko{,.old}

sudo make INSTALL_MOD_DIR=kernel/fs/ufs modules_install M=fs/ufs


Mount with following command:
Code: 
sudo mount -t ufs -o ufstype=ufs2,rw /dev/sdb1 /mnt

And this if necessary:
Code: 
sudo mount -o remount,rw /mnt
 
Last edited:
@Berion I have found an interesting thread of you over there: http://daemonforums.org/showthread.php?p=67438

My idea is the following scenario:

Install FreeBSD ppc64be as OtherOS on a PS3 and connect any other PS3 HDD with an SATA-USB adapter to it for rw access. Accessing the external HDD would be realized over FTP or SAMBA server running on the FreeBSD machine. I think this is the most realistic way to be at least functional. Could you try this scenario out?
 
@gmipf You cannot just install FreeBSD on OtherOS without drivers to work with. Target CPU architecture is only one of the obstacles. Other are lack of decryption tools for this OS (it cannot be done by geom or geli alone as I know); and no, PS3 firmware will not expose external HDD as decrypted device. However, it would be nice alternative but someone first must create live FreeBSD which at least works in CLI (in assumption that internal HDD is decrypting by PS3 firmware independently whatever if it is GameOS or OtherOS - I don't know that).

For now the most complicated but worth trying method, yet still not tested by me, is expose decrypted mappers (without fs mounting of course) to nbd-server and connect to them by real FreeBSD (like vanilla one or i.e GhostOS) via nbd-client and from there mount them. This should works great but also demand complicated environment (two PC with two OSes or Linux with FreeBSD inside VM). It is really ugly potential solution but at least possible without writing anything what currently doesn't exist.

But to be honest, I don't really interesting in it right now. I'm not sure if I even back to it in this year (I'll try finished some old projects which haunting me like i.e AIO PS2 v1.7). Sorry to disappoint You. ^^
 
Last edited:
In the last few days I have tried a combination of Host and VM, like you mentioned. My Host is running Kubuntu 19.10. VM software is KVM/Qemu. First I have created the virtual device with bswap16 kernel module until the command kpartx but haven't mounted the drive at the host. Then I created a FreeBSD VM and passthroughed the device /dev/mapper/ps3hdd1 as a Storage device to the VM. But mounting wasn't possible in FreeBSD.

Then I have tried the same procedure with a NetBSD VM and curiously it was able to mount the partition in rw mode as an ffs2 filesystem. I have written big iso files and verified them and everything was OK. But after connecting to the PS3 it couldn't boot with the message of a filesystem defect. It tries to repair the filesystem but fails.
 
Last edited:
And now I have successfully write accessed the PS3 ufs partition on a Linux host without any failures. I have copied a 32GiB file from PC to the PS3 drive and the PS3 could boot after that without any failures. Then I have transferred the same file to the PC over FTP back, MD5 hashed both files and it was the same. The transfer speed was just 11MiB/s, but better then nothing.

I have just build the ufs rw kernel module on Kubuntu 19.10 and mounted it using bswap16 kernel module. I also have updated the instructions for building the ufs kernel module for Kubuntu 19.10 on my previous post.

Now I need to test copying many little files at once.
 
Last edited:
In BSD world I'm newbie, so I don't know much of those family OS but I read on wiki that FFS2 is the same as UFS2, just differently named. So this news ripped me from the hope a little. :D
  1. Could You elaborate more about the connection?
  2. Did You used nbd or other method?
  3. Did You unmount this partition after write in NetBSD?
  4. How did You mount it (what command, especially the switches did You used)?
Those questions can be obvious but for sanity check, it is worth to clarify that. ^^"

PS: Thanks for the instructions, I'll check this. Sounds promising as my steps was different and probably incomplete.
 
Last edited:
As far as I understand all the different BSD flavors are based on 4.4bsd which is very old. All the BSD flavors aren't distributions of the same kernel, instead all have their own historically developed kernel. Therefore they also developed and extended the UFS filesystem all in their own way. All UFS2 variants, including FreeBSD UFS2, NetBSD FFS2(another ufs2 variant) or OpenBSD UFS2 are incompatible as far as I understand.
And I have read somewhere (wikipedia?) that only parts of FreeBSD (for network?) used for CellOS, the other parts came from NetBSD. That was the reason I have tried NetBSD as second choice.

I will recreate the scenario with NetBSD again and document it for you soon.
 
Last edited:
Here is what I have done:
  • I have installed NetBSD x86_64 in a KVM/qemu VM using virt-manager on Kubuntu 19.10.
  • I have connected and prepared the PS3 HDD (from NAND ps3) using bswap16-ecb kernel module. (Not with network based userspace nbd driver.)
  • After the command "kpartx -a /dev/mapper/ps3hdd" I have added a new hardware (Storage) to the VM in virt-manager using the path "/dev/mapper/ps3hdd1"
  • Then booted NetBSD and mounted using the command: "/sbin/mount -v /dev/wd1 /mnt"
  • Following message is shown after mounting: "/dev/wd1 on /mnt type ffs (local, fsid: 0x13/0x78b, reads: sync 1 async 0, writes: sync 2 async 0)"
  • If I mount using following: "/sbin/mount -v -t ufs /dev/wd1 /mnt" it still posts the same message and mount it as default FS ffs.
  • I have used following commands to remove the drive: "/sbin/umount /mnt"; shutdown VM; "kpartx -d /dev/mapper/ps3hdd"; "cryptsetup remove ps3hdd" and "cryptsetup remove ps3hdd-bs"
  • This time I have only tried the rw mount on NetBSD without copying any files to the ps3hdd. PS3 still shows corrupted filesystem on boot. It repair till 100%, reboots and do it again forever in a bootloop. You need to reformat it in Recovery Mode.
 
Last edited:
Sounds even more reasonable approach than my idea. :) Thanks for the guide.

Oh, and today I have tried get to source of build-in generic kernel from Mint 19.3 (because I really want provide ready and perm solution to end user in live environment) and just like before, there is nothing in repository... I cannot understand why. So it looks like I must forbidden it for ufs.ko task for other distro.
 
I have successfully unpacked packages to the ps3 hdd directly on my pc without any issues. The only little issue are permissions. I need to figure out how to set them correctly on PC without Multiman.
 
@gmipf Mint 19.3, 64bit with Cinnamon. Default kernel is 5.0.0.32-generic for which I want create this ufs2-rw ko (this specific one because will allow user to load module from i.e the same pendrive on live session without messing with compilation and Linux installation and downloading other kernel version - a lot of headache could be saved for end user).

Of course I enable sources. ;) In Cinnamon it is i.e on GUI in Software Manager.

By chmod or chown. But I don't remember what they must be, however it is easy to check.
 
Wouldn't it be a better idea to create a tutorial for a live distribution with more recent Linux kernel? My Kernel is 5.3.0.

EDIT: Or a ready to go virtual machine package?

EDIT2: Have attached RW ufs.ko module for Kernel 5.3.0-24-generic. Build it on Ubuntu 19.10 Cinnamon Remix. It's compatible with the live environment iso "cinnamonremix-19.10-all.20191204.iso".
 

Attachments

Last edited:
Thanks for the effort. I'll check that.

Reason's behind to use any popular distribution in live is to not bother with compilation etc. and have working binary out of the box. I just favourite Mint only because it is my distro of choice. I'm not a fan of disk images because they are huge, no one will share them endlessly, and popular Linux distribution user can always find (and the reason why in default kernel because repositories for them can disappear one day (or at least address can change)).
 
You must log in or register to reply here.

Similar threads

Back
Top