Skip to content
View in the app

A better way to browse. Learn more.

ResHax

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.
Help us keep the site running.

GolfStar GSR Archive - compression XOR encryption

Featured Replies

  • Author
  • Localization

wattostudios, posted Wed Sep 06, 2017 12:08 pm (26315)


Hi guys,

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:
// 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:
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
Guest
This topic is now closed to further replies.

Account

Navigation

Search

Search

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.