The command header is uint8_t for the command, then uint32_t for the tick.

The first link parses the signon data, the second link skips the data (it does a relative seek for signon length bytes).

Dunno about the rest, protobuf wasn't used when I last looked at the demo format.

What's that supposed to be?

Names, offsets, sdfdata indices and all that are in the TOC file's zlib compressed chunk. That 0x140 bytes block is probably some signature or something like that.

There's no encryption/obfuscation going on in the TOC file.

The format of the encryption and signature data in the header comment changed (the 2kb or whatever less is that data). Also be aware that XXTEA isn't actually used.

7zip opens the decrypted files just fine for me.

Check the Evolve pak thread.

The key changed from the closed beta. Didn't hardcore/provide any keys to avoid potential problems.

http://sktest.aruarose.com/PakDecrypt_Evolve.7z

Fill RSAKeyData.bin with the key from the release version (should be 140 bytes).

The only thing I've seen encrypted in Frostbite games was the .toc files.

It's LZ4.

It's almost identical to Crysis 3.

Oh wait, it's like that because the script doesn't handle the compression.
Might post something that does tomorrow.

Try opening the file in a hex editor and check if the first few bytes are 06 05 04 03.

Looks like the first 8 bytes of that .big file are missing.

It's the same method Crysis 3 uses with a different key. The Star Citizen key is: unsigned char g_RSAKeyData[140] = { 0x30, 0x81, 0x89, 0x02, 0x81, 0x81, 0x00, 0xF4, 0x6F, 0x92, 0x32, 0x80, 0xAC, 0x43, 0x08, 0x86, 0x8C, 0x30, 0x99, 0x76, 0x4B, 0x7F, 0xE4, 0xFB, 0x4F, 0x54, 0xFD, 0x26, 0xFB, 0xFF, 0x...