PAK (File Format)/RetroStudios: Difference between revisions
mNo edit summary |
m (Document compressed block containing decompressed data) |
||
| Line 86: | Line 86: | ||
| 0x08 || UInt64 || '''Resource ID'''. | | 0x08 || UInt64 || '''Resource ID'''. | ||
|- | |- | ||
| 0x10 || UInt32 || '''File data size''' in bytes. Files are always padded with 0x40 | | 0x10 || UInt32 || '''File data size''' in bytes. Files are always padded with 0x40, which is reflected in the file data size. | ||
|- | |- | ||
| 0x14 || UInt32 || '''File data offset''', relative to the start of the [[#DATA|DATA]] section. | | 0x14 || UInt32 || '''File data offset''', relative to the start of the [[#DATA|DATA]] section. | ||
| Line 102: | Line 102: | ||
| 0x00 || Char[4] || '''Data magic'''. Always ''CMPD'' in ASCII. | | 0x00 || Char[4] || '''Data magic'''. Always ''CMPD'' in ASCII. | ||
|- | |- | ||
| 0x04 || UInt32 || '''Block count''' ('''N'''). Specifies the number of compressed blocks the data has been divided into | | 0x04 || UInt32 || '''Block count''' ('''N'''). Specifies the number of compressed blocks the data has been divided into. | ||
|} | |} | ||
| Line 114: | Line 114: | ||
| 0x01 || UInt24 || '''Compressed size''' in bytes. | | 0x01 || UInt24 || '''Compressed size''' in bytes. | ||
|- | |- | ||
| 0x04 || UInt32 || '''Decompressed size''' in bytes. | | 0x04 || UInt32 || '''Decompressed size''' in bytes. If the compressed size is identical to the decompressed size, it means the block data is not compressed and the data should be copied directly rather than decompressing. | ||
|} | |} | ||
Latest revision as of 20:22, 11 July 2025
PAK is an archive file format used in games such as Donkey Kong Country Returns created by RetroStudios.
File Format
Header
The file starts with the following header:
| Offset | Type | Description |
|---|---|---|
| 0x00 | UInt32 | Unknown. Always 2, possibly a version number. |
| 0x04 | UInt32 | Header size. Always 0x40. |
| 0x08 | Byte[0x10] | MD5 hash of the file data following the header. |
| 0x18 | Byte[0x18] | Padding. |
Table Of Content
After the header, a table of content structure specify what sections are stored in the file. It has the following structure:
| Offset | Type | Description |
|---|---|---|
| 0x00 | UInt32 | Section count (N). In practice this will always be 3 with order STRG, RSHD, DATA. |
N entries of the following structure follows.
| Offset | Type | Description |
|---|---|---|
| 0x00 | Char[4] | Section magic. |
| 0x04 | UInt32 | Section size in bytes. |
At 0x80 the section data for each section starts. They are laid out in the same order as they are specified above.
STRG
The STRG section specifies files which are named, in other words identified by a string. It starts with the following structure:
| Offset | Type | Description |
|---|---|---|
| 0x00 | UInt32 | Number of named resources (N). |
Immediately afterwards N named resources follows.
Named Resource
Each resource has the following structure:
| Offset | Type | Description |
|---|---|---|
| 0x00 | Char[N + 1] | Resource name stored as a null-terminated string of length N. |
| N + 1 | Char[4] | Resource magic. File magic of the resource specifying file type. |
| N + 5 | UInt64 | Resource ID. There is always an entry in the RSHD section with the same Resource ID. |
RSHD
The RSHD section specifies all files, where the files are identified by a 64-bit integer. All files in STRG are also stores in the RSHD section. It starts with the following structure:
| Offset | Type | Description |
|---|---|---|
| 0x00 | UInt32 | Number of resources (N). |
Immediately afterwards N resources follows.
Resource
Each resource has the following structure:
| Offset | Type | Description |
|---|---|---|
| 0x00 | UInt32 | Compression flag. Either 0 (uncompressed) or 1 (compressed). See here for more details. |
| 0x04 | Char[4] | Resource magic. File magic of the resource specifying file type. |
| 0x08 | UInt64 | Resource ID. |
| 0x10 | UInt32 | File data size in bytes. Files are always padded with 0x40, which is reflected in the file data size. |
| 0x14 | UInt32 | File data offset, relative to the start of the DATA section. |
DATA
All file data is stored in the DATA section and references by each resource. File data is always padded to nearest 0x40 with 0xFF.
Compressed Data
File data may be compressed. In Donkey Kong Country Returns, files may be compressed using ZLib. Compressed data starts with the following header:
| Offset | Type | Description |
|---|---|---|
| 0x00 | Char[4] | Data magic. Always CMPD in ASCII. |
| 0x04 | UInt32 | Block count (N). Specifies the number of compressed blocks the data has been divided into. |
Following the header N block entries follows:
| Offset | Type | Description |
|---|---|---|
| 0x00 | Byte | Flag. |
| 0x01 | UInt24 | Compressed size in bytes. |
| 0x04 | UInt32 | Decompressed size in bytes. If the compressed size is identical to the decompressed size, it means the block data is not compressed and the data should be copied directly rather than decompressing. |
Afterwards the compressed file data is stored. Like with decompressed data, the compressed data is padded with 0xFF to nearest 0x40.
Tools
The following tools can handle PAK files:
- crPakTool by jellees