CASC storage

CASC (Content Addressable Storage Container) is a storage system introduced in 2014 to replace the outdated MPQ format as the primary data storage for recent Blizzard games.

Unlike MPQ archives, the CASC system contains multiple subdirectories and uses many files to contain its data.

This document is a brief explanation of the CASC system, and only contains the information required to write the files downloaded from the Blizzard CDNs. The main difficulty in extracting files from this storage lies in parsing the root file (and some supplementary files) that are required to convert file names to content hashes. The root file format is different in every Blizzard game; for better understanding you might want to look at CascLib source code.

CASC directories

The root folder for the CASC system has different names depending on the game, i.e. for Diablo III the folder is called Data, whereas for Heroes of the Storm it is called HeroesData. Alongside the root directory you can find the .build.info file (or .build.db for older storages), which tells the game which version needs to be loaded - it has a format similar to the global configuration tables, except it only has two lines. Here is an example file from Heroes of the Storm:

Branch!STRING:0|Active!DEC:1|Build Key!HEX:16|CDN Key!HEX:16|Install Key!HEX:16|IM Size!DEC:4|CDN Path!STRING:0|CDN Hosts!STRING:0|Tags!STRING:0|Armadillo!STRING:0|Last Activated!STRING:0|Version!STRING:0|Keyring!HEX:16|KeyService!STRING:0
eu|1|3f072df7d1fa6d5fd7f9ebcf48518c68|9e6a78255e2e1daefb6245a60893d920|ef50f9376f363af7c551f80150a5af68|17076|/tpr/Hero-Live-a|blzddist1-a.akamaihd.net blzddist2-a.akamaihd.net|Windows code EU? enUS speech?:Windows code EU? enUS text?||2016-03-02T17:10:50Z|16.3.41150||

The most important field is the Build Key, which contains the hash key for the build-config file, which is stored in the config folder of the CASC system, and is used to locate the root and encoding files in the storage.

Config folder

The config folder is located directly inside the root CASC folder, and is used to store patch, build and CDN configuration files, in the same format as they are obtained from the Blizzard CDN. Inside the config folder, they are located in two subfolders, indicated by the first two and the second two characters of the hash name.

Data folder

The data folder contains all the actual files stored in the CASC system. See the Data section for further explanation.

Indices folder

The indices folder contains all the .index files for CDN data (and patch?) archives, likely used to quickly locate the files required to patch the game.

Patch folder

The patch folder is only used while the game is being updated, and is empty at other times.

Data

The data folder contains three types of files:

• data.XXX files contain the compressed files themselves, along with small headers
• XXXXXXXXXX.idx files are used to locate the individual files inside the data.XXX files
• shmem file contains the full path to the data directory, latest versions of the index files, and lists unused space in the data files. This file is recreated every time the client is started.

Data files

Data files are always named data.XXX, with XXX being sequential decimal numbers (starting with 000). The file consists of a sequence of short headers immediately followed by BLTE encoded files. There might be extra space before and between individual files, so one has to consult the index files to find the exact file locations.

• Header (30 bytes)

Offset	Type	Name	Description
0x00	char[16]	Hash	Reversed CDN hash
0x10	uint32 [LE]	Size	Size of this header plus the compressed file data
0x14	char[10]	Unknown	Setting this to zeroes seems to work fine, although it normally contains some data

Index files

These files are currently named XXYYYYYYYY.idx, with XX being the index of the file, and YYYYYYYY being the file version. The game keeps recreating these files, increasing the version number. It is okay to start the version at any number you want, but the XX portion has to be a two digit hex number starting with 00.

The file is structured as follows:

• Block header
• Index header
• Zero padding (8 bytes)
• Block header
• List of index entries
• Zero padding, up to a 4096 byte (0x1000) boundary
• Some additional data (at least 0x7200 bytes)
• Zero padding, up to a 4096 byte (0x1000) boundary

The number of entries in each index file varies from game to game. In Diablo III, the index file sizes are always 0xA0000. The additional data seems to contain some information linking the different versions of the same index file, and can be safely filled with zeroes. The two block headers describe the index header and the list of index entries, correspondingly.

• Block header (8 bytes)

Offset	Type	Name	Description
0x00	uint32 [LE]	BlockSize	Number of data bytes following the block header
0x04	uint32 [LE]	BlockHash	Jenkins checksum of the block data

• Index header (16 bytes)

Offset	Type	Name	Description
0x00	uint16 [LE]	Version	Always 07 00
0x02	uint8	KeyIndex	Index of the index file (same first two characters of file name)
0x03	uint8	ExtraBytes	Always 0
0x04	uint8	SizeBytes	Number of bytes for file size (always 4)
0x05	uint8	OffsetBytes	Number of bytes for archive index + file offset (always 5)
0x06	uint8	KeyBytes	Number of bytes for file CDN hash (always 9)
0x07	uint8	OffsetBits	Number of bits for file offset - rest are used for archive index (always 30)
0x08	uint64 [BE]	MaxOffset	Maximum offset (always 00 00 00 00 40 00 00 00, aka 1GB)

• Index entry (18 bytes)

Offset	Type	Name	Description
0x00	char[9]	Hash	First 9 bytes of the file CDN hash
0x09	uint40 [BE]	IndexAndOffset	A 40-bit integer in big endian notation; high 10 bits contain the data file index, low 30 bits contain the offset (of the file header) within the data file
0x0E	uint32 [LE]	Size	Size of the data header (30 bytes) plus compressed file data

Shared memory file

This file does not need to be created when downloading the game data. The file format can be found on wowdev Wiki.