After some additional testing here is the scan version 0.4.4.
2007-04-30 0.4.4 Han Sooloo, GranpaHomer
> Printing of the scan position is now fixed.
> lseek command was replaced with lseek64 because for some strange reason PS3
is not capable of handling the lseek command properly when seek position=0.
> Default value for -s was changed to 2 so the scan program will now always
prompt to proceed with scanning after the size of hard drive is displayed.
Did you guys ever got somewhere with this approach?
I have a eSATA RAID enclosure and by playing with the size of the main container I can fool the PS3 to believe the hard drive is that size... that would be useful to study the difference in different HD sizes... small sizes makes it easier so lets say 4GB, then 5GB, then 6GB, etc...
Hello all. I've been working with the PS3 HDD for a little while now. Poking and prodding bytes to see their reactions and generally trying to enumerate locations of files/HDD sections.
I thought I would jot down the methods and process I'm using to analyse things. Partly for my reference, partly to share, partly to open up dialogue. These scripts/commands are mostly in Linux, Bash scripting format so you will need a cygwin or linux OS to use them(go for Ubuntu with wubildr for ease).
You will need an external sata hard disk dock to mess with your PS3 HDD.
The first part of the will be to back every byte up. If you have an 80 gig hard disk then you will need 80 gigs space to store this monster dump.
In my case external HDD is at '/dev/sdb', save location is at '/home/sdb' and the number of bytes to transfer(the ob option) at a time will be 8192. So the command would be:
dd if=/dev/sdb of=/home/sdb ob=8192
Go away for a while and let the backup complete. Mine took around 3 hours.
Once you have a backup complete I suggest you open it up with a hex editor and have a look at it. Awesome right!! Well yes, but it's all encrypted. The bytes I'm playing with at the moment are the first 16kb at the begining of the hard disk.
This area seems to be broken into 1 kb sections in the following format:
You will see that the same 16 byte key is repeated at every 1 kb for the first 8 kb. The PS3 system uses UFS2 (Unix File System 2) partition format under AES encryption. In my case I have one partition of 80gb under PS3 which leads me to assume that Signature Block 1 is the bootblock.
Signature blocks 2 can be altered without any obvious effect on the system so I must assume that these would have been other partitions(i.e otheros) boot blocks. The DataBlock doesn't share the same 16 byte starting signature as the previous 8 kb and has no discernable pattern.
Have a look yourself and see what you come up with.
I will post some differential analysis scripts later.
Edit: Thought I would post the differential analysis script.
Right, now that you have a full backup of your PS3 HDD(see previous post on how to) it's time to try and enumerate some locations.
The idea goes like this:
You backup your PS3 HDD
You return the HDD to the PS3
You delete a file
You remove the HDD again
You compare your original backup to the current HDD state and generate a differential file
You analyse the differential for for byte changes
The below code will compare the ps3 HDD to your backup.
echo "please make sure the play station hard disk is plugged in"
echo "starting diff process"
cmp -b -l /dev/sdb /host/sdb | sed -e 's/^[ \t]*//' | cut -d' ' -f 1 >> $outfile.txt
echo "Finished Diff Process Good Luck Dave"
It assumes that your ps3 hdd is located at /dev/sdb and the backup is located as a file at /host/sdb. The script will create a date stamped file with all the bytes that have changed. This is generally quite a bit faster than the backup process. The 'cmp' command does all the heavy comparison work, the rest is there for usability.
O.K, what you then end up with is a txt file with all the bytes that have changed.