From XentaxWiki
Revision as of 22:51, 17 December 2017 by Multimedia Mike (talk | contribs) (describe the trailing XML)

Jump to: navigation, search
  • Format Type : Archive
  • Endian Order : Little Endian (for PC variant) or Big Endian (XBOX or PS3 variants); the platform type is specified in the header

SDS is an archive format used in the game Mafia II developed by 2K Czech. The page describes the SDS files as seen on the Windows version of the game. Other platform ports might use the same variant.

This description of the format was reverse engineered from a set of SDS manipulation tools written in C# by Rick Gibbed.

Format Description

The overall structure of an SDS file is:

signature preamble
archive header
resource type table
block table (actual data)
XML descriptions

Preamble and Header

An SDS file begins with the following 8-byte preamble:

bytes 0-3    file signature string: 'SDS\0'
bytes 4-7    0x00000013 (either a version number of a length value specified in 32-bit words)

The header has the following 60-byte structure:

bytes 0-3    platform string/endian-ness indicator
bytes 4-7    0x5FFB74F3
bytes 8-11   resource type table offset
bytes 12-15  block table offset
bytes 16-19  XML offset
bytes 20-23  slot RAM required
bytes 24-27  slot VRAM required
bytes 28-31  other RAM required
bytes 32-35  other VRAM required
bytes 36-39  unknown
bytes 40-55  array of 16 bytes; purpose unknown
bytes 56-59  file count

There are 3 known values for the platform string, and the endian-ness of multi-byte numbers keys off of this value:

  • 'PC\0\0' for the PC version of Mafia II; multi-byte numbers are little-endian
  • 'XBOX' or 'PS3\0': multi-byte numbers are big-endian

Resource Type Table

Following the header is the resource type table offset (the absolute offset of this table is also referenced by the "resource type table offset" field in the file header). The table begins with the count of resources in the table.

Following the count, there is an entry for each resource in the archive. Each entry has the following format:

bytes 0-3   ID
bytes 4-7   length of name field in bytes
bytes 8..n  resource name
bytes 8-11  parent

Presumably, these help to link resources together.


A texture resource contains a DDS texture file. While DDS already describes a lossy, constant bit-rate image compression algorithm, SDS files typically compress this data further.

The header of a texture resource payload has the following format:

bytes 0-3  signature: 'UEzl'
bytes 4-7  unknown
byte 8     unknown, but should be 4

Following this is a sequence of blocks which have the following header:

bytes 0-3  size
byte 4     compression flag

If the compression flag is set, then this block is compressed. The header for a compressed block has the following header:

bytes 0-3    uncompressed size
bytes 4-7    unknown
bytes 8-11   unknown
bytes 12-15  unknown
bytes 16-19  compressed size
bytes 20-23  unknown
bytes 24-27  unknown
bytes 28-31  unknown

Following the header is a data compressed using standard zlib.

To decompress the data, iterate over blocks until encountering a block with a size of 0.

Trailing XML

The end of an SDS file contains XML data. The absolute offset of the start of this data is indicated by the "XML offset" field of the header. The XML contains a textual description of some of resource's parameters. For example:

               <SlotRamRequired __type='Int'>0</SlotRamRequired>
               <SlotVramRequired __type='Int'>2097152</SlotVramRequired>
               <OtherRamRequired __type='Int'>0</OtherRamRequired>
               <OtherVramRequired __type='Int'>0</OtherVramRequired>