Secret Files: Tunguska (Demo) SPR

From XentaxWiki
Jump to: navigation, search

Back to index | Edit this page


Format Specifications

char {4}     - ID (SPCD)

uint32 {4}   - Unknown
uint32 {4}   - Unknown
uint32 {4}   - Decryption key seed
uint32 {4}   - Unknown
uint32 {4}   - Unknown
int32 {4}    - Number of strings
int32 {4}    - String table offset
int32 {4}    - String table size
int32 {4}    - Number of files
int32 {4}    - File table offset
int32 {4}    - File table size
uint32 {4}   - Unknown
int32 {4}    - Number of directories
int32 {4}    - Directory table offset
int32 {4}    - Directory table size
byte {x}     - File data
// string table data (encrypted)

// for each string
uint16 {2}   - String length
// for each string
char {x}     - String data

// directory table data (encrypted)

// for each directory
int32 {4}    - Directory name (index into string table)
int32 {4}    - Parent directory (index into directory table, 0x1effffff for root)

// file table data (encrypted)

// for each file
int32 {4}    - Parent directory (index into directory table, 0x1effffff for root)
int32 {4}    - Name prefix (index into string table)
int32 {4}    - Name suffix (index into string table)
uint32 {4}   - CRC32 of uncompressed data (might not be set, zero in that case)
// file date (as Windows _SYSTEMTIME type)
uint16 {2}   - Year
uint16 {2}   - Month
uint16 {2}   - Day of week
uint16 {2}   - Day
uint16 {2}   - Hour
uint16 {2}   - Minute
uint16 {2}   - Second
uint16 {2}   - Millisecond
int32 {4}    - Size of uncompressed data
int32 {4}    - Compression header offset (0xffffffff if file is not compressed)
int32 {4}    - Compression header size (zero if file is not compressed)
int32 {4}    - File data offset
int32 {4}    - File data size

Notes and Comments

Table decryption

Each of the three structure tables has been xor-encrypted. The decryption depends on the seed value given in the header as well as a partly fixed key domain value. The decryption key will change for each byte in the buffer (depending on the previously seen bytes), as shown in this pseudo code:

KeyDomain := 0xbebe2 * Seed;
Key := ((Seed shl 8) or ((not Seed) and 0xff));

for i := 0 to Length(Data) - 1 do

Key := (Key * Key) mod KeyDomain;
Buffer[i] := Buffer[i] xor (Key and 0xff);
Key := Key + Buffer[i] + 1;


Data decompression

In cases of compressed file data, the compression header offset and size values will be set to appropriate values. Note that the data offset value will then point to the compressed data block. The compression header itself might look different for various compression techniques, but only one is known to be used in the game's archives.


The compression header of the SLZX method is constructed by a four-char identifier (SLZX) followed by a int32 value storing the uncompressed data size. The compressed data block is prepended by an int32, also containing the uncompressed size. (Please note that this results in three distinct places where the uncompressed size can be found: The file table entry, the SLZX compression header and the beginning of the compressed data block.)

The compression technique itself is a variant of the common LZSS in the following sense:

  • The interpretation of the bit flags is reversed (0 indicates a literal copy, while 1 indicates a buffer reference).
  • An offset/length pair is given by a little-endian uint16 value. The uppermost five bits store the length, while the lower 11 bits contain the offset value. After each such offset/length pair there follows exactly one additional literal character.
  • The history buffer (2048 bytes in size) is not circular, but slides along the output. All offsets are absolute buffer references. (Please note that the buffer "window" only starts sliding forward as soon as 2048 bytes of data have been output.)

MultiEx BMS Script

None written yet.

Supported by Programs