Share

SteamDB implements the download system for game tracking purposes, so we have some understanding of how it works under the hood.

While this post is pretty technical, we hope it removes some misinformation that we’ve seen around preloads and how they work.

How Steam downloads work

It all begins with a depot manifest which is identified by a unique 64-bit ID (which can be seen in the app info).

This manifest is the file list, which consists of the encrypted file name, file size, file hash, file flags (such as if it is a directory or executable), and chunks metadata.

The manifest contains the following information for each chunk: chunk id, adler32 checksum, offset in the file, compressed and uncompressed sizes.

Each file is split into roughly one megabyte chunks, and each chunk is compressed with LZMA and encrypted with an AES 256-bit key.

Each chunk is compressed with the same encryption key as the file names in the manifest. The encryption key is unique to the depot and is same for all Steam users. This allows CDNs to efficiently cache the content, and allows LAN caches to work.

Only Steam users that have access to the game and that specific depot can request the encryption key, but once one user is able to receive it, they could technically share it with other users.

How Steam preloads work

Everything that has been described above also applies to preloads, except for one minor detail — the encryption key is not accessible until the game releases.

Steam downloads all the chunks into *.csd files in the depotcache folder, and when the encryption key becomes available, it will decrypt it.

When downloading a released game, the decryption process happens while downloading, but when decrypting a preload, Steam has to read and write data to disk, so if your disk is slow but you have fast internet, it may actually take longer to decrypt a preload than re-downloading the game.

Why bruteforcing preloads is impractical

Here’s the depot key for CS:GO’s 731 depot formatted in hex: BCA9A9CDE94BB4DFF61849C6A87230EE45867A590FDD28826366E35E7D62C08E. It is 256 bits long, and to bruteforce it, you would need to exhaust 2256 possibilities.

And as Wikipedia kindly explains it: Fifty supercomputers that could check a billion billion (1018) AES keys per second would, in theory, require about 3×1051 years to exhaust the 256-bit key space (at which point, the earth and probably the universe itself are long gone).

If you have heard about quantum computers breaking encryption, you likely heard about the Shor’s algorithm, which applies to asymmetric encryption algorithms.

AES-256 is a symmetric encryption algorithm, and it is believed to be quantum resistant. This means quantum computers are not expected to be able to reduce the attack time enough to be effective.

You can read about more AES-256 quantum resistance over on qvault.io.

References

Steamworks documentation provides details on how the content system works here.

If you are interested in more technical details, you can take a look at DepotDownloader project code.