Changes

.pak files are encrypted using {{wp|Blowfish (cipher)|Blowfish}} in {{wp|Block cipher mode of operation#Cipher Block_Chaining .28CBC.29|CBC mode}} with a 16-byte key. When an encrypted block begins, decryption is initialized by reading an 8-byte, plaintext IV ({{wp|initialization vector}}) from the file. From then on, Blowfish decryption commences.

.pak files are encrypted using {{wp|Blowfish (cipher)|Blowfish}} in {{wp|Block cipher mode of operation#Cipher Block_Chaining .28CBC.29|CBC mode}} with a 16-byte key. When an encrypted block begins, decryption is initialized by reading an 8-byte, plaintext IV ({{wp|initialization vector}}) from the file. From then on, Blowfish decryption commences.

Each .pak file has its own encryption key. The keys for the different packs are found in [[packlist.dat]].

Each .pak file has its own encryption key. For older games, keys for the different packs are found in [[packlist.dat]]. Since ManiaPlanet, these keys are sent from the master server as "sub-keys" (stored in profile chunks for offline purpose) and calculated into final keys during runtime. ManiaPlanet.pak and Resource.pak are the only two that have these sub-keys stored directly in a function. ManiaPlanet .pak files also have an additional "file key" (only one) used to decrypt the files inside that is calculated differently by hashing the sub-key:

 

There is one gotcha where Nadeo deviates from regular CBC: on the first read and after every 256 bytes read, the current IV is xor'd with a value we'll call ivXor (this happens before the IV is applied to the Blowfish-decrypted block). ivXor is initialized to zero and is also reset to zero every time it is applied, so most times it doesn't have an effect. Crucially though it does get assigned a non-zero value while reading the .pak header, of which the effect usually kicks in somewhere in the middle of the file list. So if you don't take this into account, half your file table will be messed up (which is likely what Nadeo was intending with this trick). The same goes for [[GBX|.gbx files]] embedded in packs.

There is one gotcha where Nadeo deviates from regular CBC: on the first read and after every 256 bytes read, the current IV is xor'd with a value we'll call ivXor (this happens before the IV is applied to the Blowfish-decrypted block). ivXor is initialized to zero and is also reset to zero every time it is applied, so most times it doesn't have an effect. Crucially though it does get assigned a non-zero value while reading the .pak header, of which the effect usually kicks in somewhere in the middle of the file list. So if you don't take this into account, half your file table will be messed up (which is likely what Nadeo was intending with this trick). The same goes for [[GBX|.gbx files]] embedded in packs.