I have a *.GSR archive from the game GolfStar that I'm trying to analyse, but the combination of XOR encryption and compression is tripping me up.
The basic archive structure is this...
Code: Select all
// ARCHIVE HEADER
36 - Header ("GolfStar Resource File, Version 1.1" + null)
4 - Unknown
4 - Directory Offset
4 - Directory Length?
// FILE DATA
// for each file
X - File Data (encrypted and compressed)
// DETAILS DIRECTORY
// XOR with (byte)69 {
// for each file (260 bytes per entry)
248 - Filename (null terminated, filled with nulls)
4 - File Offset
4 - Compressed File Length
4 - Decompressed File Length
}The DETAILS DIRECTORY is simple to read - just XOR it with (byte)69.
Now, in the archive I'm analyzing, the files are all compressed, and have the extension *.dds, so it should be obvious if we find the correct compression. Running it through the ZenHax compression detector didn't give anything. However, I noticed that the files all look to be encrypted as well. The data for each file looks like this...
Code: Select all
1 - XOR Value (XOR this value with (byte)12, and this gives the XOR value to use for the rest of the file)
X - File Data (XOR with the XORValue above, then decompress with Unknown compression type)So basically if you read the first byte of the file and XOR it with (byte)12, it gives you a value. You use this new value to XOR all the other bytes in the file, and now you can see the normal header you expect from a DDS image. However, the file data is still compressed somehow.
I'm struggling here because...
1. I don't know if the 1-byte file header is actually an XOR value key, or if it's part of the real file data
2. I don't know if the file is encrypted first, or compressed first
3. I don't know if the compression algorithm is a known or common one.
Here is a download link for the *.GSR archive, as well as some of the exported files... https://drive.google.com/open?id=0B7gEf ... XJEeGlaXzQ
In the archive, there are 3 DDS files called "before_xor" which are the raw data exported from the archive. There are also the same 3 DDS files called "after_xor" which is where I have performed the XOR with (byte)12 as described above, so you can see the DDS header in there, but the file is still compressed somehow.
If anyone could take a look at it, it'd be greatly appreciated - it's an intriguing archive format.
Thanks