Dreamfall PAK

• Return to the list of games

Choose archive extension:

PAK

• Format Type : Archive
  
• Endian Order : Little Endian
  

Note: This documentation is still very preliminary and should be considered as work in progress.

Format Specifications

// PAK header
char {12}  - Identifier ("tlj_pack0001")
uint32 {4} - Number of Type 1 entries
uint32 {4} - Number of Type 3 entries
uint32 {4} - Number of Type 2 entries

Following the header, there are three distinct arrays of entries (Type 1, Type 2 and Type 3, in this order; note the reversal of the matching array lengths in the PAK header structure). The naming of the entry types is preliminary as their actual purpose is not yet fully understood.

Type 1

// Type 1 entry
uint32 {4} - Absolute file offset
uint32 {4} - File size
uint32 {4} - Index into Type 1 entry array (probably)
uint32 {4} - Unknown
uint32 {4} - Index into Type 2 entry array (probably)

Type 1 entries determine "real" file items. If the file size specified is non-zero, a file can be copied out of the resource archive by simply seeking to the file offset and copying as many bytes as the file size value indicates.

However, the file size value might also be zero. In this case, the offset value usually points to the beginning of the very first file item (i. e. directly after the header and entry array structures). The purpose of these entries is not yet known. The remaining three fields (or at least the indexes into the array structures) seem to be especially important in the latter case, possibly indicating a file system-like chaining.

Type 2

// Type 2 entry
uint8 {1} - Unknown

Despite the trivial structure, the purpose of these bytes is unknown. Their values usually seem to be relatively low, though.

Type 3

// Type 3 entry
uint32 {4} - Index into Type 2 entry array (probably)

The actual purpose of these entries is also still unknown.

Futher notes

• The whole file might be organized in "sectors" of 2048 (?) bytes in size; the alignment of the file offsets indicates this.
• File names for the extraction process are nowhere near to be seen. They are possibly hidden inside the compiled Shark3D binaries within the single archives. It might eventually be necessary to reverse-engineer this format as well to fully understand the PAK structure.
• One file, resource.pak, does not follow the format described here, but is structured in a completely different (and yet unknown) way. Its purpose is still unclear as well.

MultiEx BMS Script

Not written yet

Compatible Programs

Unknown