PS4 News on Facebook! PS4 News on Twitter! PS4 News on YouTube! PS4 News RSS Feed!

Closed Thread
Page 4 of 4 FirstFirst ... 34

  1. #31
    Join Date
    Apr 2005
    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.
    Attached Files Attached Files

  2. #32
    Join Date
    Nov 2006
    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...

  3. #33

    PS3 HDD Analysis

    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.

    [Register or Login to view code]

    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:

    [Register or Login to view code]

    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:

    Signature Block 1 (1 kb)
    Signature Block 2 (1 kb)
    Signature Block 2 (1 kb)
    Signature Block 2 (1 kb)
    Signature Block 2 (1 kb)
    Signature Block 2 (1 kb)
    Signature Block 2 (1 kb)
    Signature Block 2 (1 kb)
    Data Block (8 kb)

    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.

    [Register or Login to view code]

    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.

    Next post, parsing this info for readability.

Closed Thread
Page 4 of 4 FirstFirst ... 34


Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts