PCSX2 is a PS2 emulator, it features memory card support and produces .ps2 files which are a raw image of the memory card, here’s what I had to say about them last time:
- The file is a raw image of a PS2 memory card.
- I believe it’s a similar system to FAT12/16, it’s got a similar FAT usage from my quick scan.
- Every 512 bytes is a 16 byte footer, I assume it’s some sort of checksum
Spurred on by an email I recieved earlier I decided to do some more digging, here’s some prelimerary findings:
(all addresses include the 16 byte footers)
- .PS2 file always has Sony PS2 Memory Card Format 1.2.0.0 as it’s header.
- The FAT table starts at 0×2520 , uses word(tbc?) for each entry
- Clusters start at: 0xA920
- Clusters are 0×200 in size.
- First cluster is file entry for . (2E in hex), an entry for .. also exists
- A file/directory entry occupies an entire 0×200 byte cluster and is broken down as such:
The first int is the file/folder attribute
second int is the file size.
I belive the datetime is next.
I belive the fat entry (word or int?) to be located 0×10 bytes in.
The filename is 0×40 bytes in and 0 terminated. - The first cluster I found containing the file data was always located at 0xB9A0 in the files I looked at.
- As with other FAT implementations 0xFFFF appears to be used to indicate end of chain (EOC) in the FAT table
Using the above information it should be possible to construct a basic tool to extract files from the .ps2 file.
I’ve been thinking about the 16 byte footer and believe it may be the attributes of the preceeding sector rather than a checksum. a sector contain all 00′s and a sector containing all FF’s both have the same footer…
Please note all information above is based on a 10 minute poke around the file in a hex editor, corrections and updates are welcome!
#1 by alkarl on November 18, 2006 - 9:26 pm
Quote
facts:
the *.ps2 files are 8650752 bytes long.
with 16384 frames.
each frame is 528 bytes long.
a frame is composed successively of:
512 bytes of data.
12 bytes of checksum.
4 constant NULL bytes.
the checksum’s bytes are divided in four 3bytes long cheksum’s units.
the result of the checksum of each 128bytes of data is stored in it’s corresponding checksum’s unit.
the default value of the checksum’s units is 77 7F 7F.
the checksum’s process ignore the bytes with a 00 value.
uncertainties:
as for the FF & 7f their sequence must perfect through all the 128 bytes to not alter the checksum’s unit default value.
the footers have too much dissimilarity to be holding attributes i rather stick with the checksum theory.
the checksum could be a 24bits type & big endian :s
#2 by Matt on March 29, 2007 - 9:00 am
Quote
I was able to figure out the CRC had 3 bytes each for each successive 128-bytes of data, with the first byte being the most likely to change. Because of how consistent they are (And the fact that they’re the same when all values are 0×00, when all values are 0xFF, and when all (word) values are 0x7FFF, it’s obviously just an xor of…something.
Looking at the PCSX2 source shows the value isn’t generated by PCSX2 directly (That is, PS2 code generates it, rather than the memcard itself).
Further googling revealed source to generate the checksum: http://www.geocities.com/SiliconValley/Station/8269/sma02/sma02.html
Not exactly the most obvious algorithm.
#3 by gothi on March 30, 2007 - 8:23 am
Quote
Thank you both for your updates, they’re most welcome
Matt, thanks for the link to the checksum routine, I’ll be looking into that as soon as I get some spare time.