Quake Champions

[coredevel]

Has anyone look at the beta for Quake Champions? Data is stored in a unknown .pak format. Actually, I think there's two types of .pak files. One .pak format stores unrelated chromium data, which looks uncompressed.

The other .pak format stores the game data, but the format is unrecognized. It looks like there's some kind of entry list at the end of the file. All files end with the same 64-bit ID (1P.D.KS1). One of the .pak files is almost 16 GB, so they could store 64-bit offsets, but they look odd to me. From there, I can't make much of anything.

[wattostudios]

I too would be interested in this - it's a bit beyond me though, seems to have encryption throughout the archive footer and files directory.

You can go here to get a free Beta key for the game... https://quake.bethesda.net/en/signup
This directs you how to download the game - it has a number of PAK files in the client\preload\paks directory - most are 25-200MB in size, and 1 at nearly 16GB in size.

This is the general archive structure...

Code: Select all

// FILE DATA
  // for each file
      X - File Data
    
// DIRECTORY
  // for each file
    X - Unknown (Encrypted)
    1 - null
    2 - Unknown (4)
    4 - Unknown (4)
  
// ARCHIVE FOOTER
  2 - Header (PK)
  2 - Version? ((bytes)5,6)
  4 - null
  4 - Unknown
  4 - Directory Length
  8 - Directory Offset
  X - Unknown
  40 - Encrypted Footer Info

I suspect somewhere in the 40-byte Encrypted Footer it will contain a pointer to the "PK" field in the ARCHIVE FOOTER, after which you can find the offset and length of the DIRECTORY.

The entries in the DIRECTORY are of varying length, but are similar sized (ie. all in the range of say 80-120 bytes in length), so I suspect the encrypted part probably stores filenames and directory paths, and hopefully some length and offset information for each file.

The file data doesn't appear to be encrypted, and I don't think it's compressed either. Certainly, when downloading the data from the website at the top, it only downloaded about 10-11GB for the install, but it takes up about 17GB on my PC, so I'm pretty certain the PAK files are not compressed on my PC (but were obviously compressed when downloading from the website)

Would anyone with encryption expertise care to take a look at this?

Thanks, much appreciated.

[wattostudios]

I have uploaded 3 of the archives here - if anyone can take a look at the encryption, it'd be greatly appreciated.

https://drive.google.com/open?id=0B7gEf ... TM4dmNXdVE

Somewhere in the 40-bytes at the end of the archive, it should contain a pointer to the "PK" field (which seems to be a few thousand bytes before the end of the archive). Once we can get that, we can grab the Directory Offset field.

Then, at the Directory Offset, we can clearly see a repeating pattern of file entries, of varying length, so they almost certainly contain a filename in them, as well as probably Length and Offset details.

Thanks for your help guys

[aluigi]

I launched offzip -a -z -15 and it worked very well because all or almost all the files are compressed and they don't use chunks.
There are only 0x1e bytes between each compressed files and they are just zeroes, so no info there.

I tried to search the compressed sizes, uncompressed sizes and offsets in the archive but found no references so it means that the TOC is encrypted, in fact the last part of the archive is divided in 3 parts: a long sequence of "random" bytes (encrypted TOC), some 64bit numbers and the 40bytes RSA signature.

[wattostudios]

Thanks for trying Aluigi, at least thats better than nothing

Let me know if you think it'd be useful to look at any of the EXEs for a way to crack the encryption, or if you need anything else from me.

[aluigi]

Here we go
http://aluigi.org/bms/quake_champions.bms

The encryption algorithm is a 64bit random number generator taken from "Numerical Recipes 3rd edition" and using the first 64bit seed of the last 40 bytes and an ivec of 32 bytes still take from the last 40 bytes.

[wattostudios]

Wow, awesome work, I won't even begin to fathom how you worked that one out, what a nice complicated bit of work Think you'll find lots of people happy to have access to these files.

[coredevel]

Amazing work. Thanks for the help!

[OXOTHuK]

Hi 2 all.
Now this script does not work?

[aluigi]

@OXOTHuK
What error you get from quickbms?
Nobody else has reported any problem.

[madsnark]

@OXOTHuK
What error you get from quickbms?
Nobody else has reported any problem.

[aluigi]

Upload the archive.

[madsnark]

Upload the archive.

https://drive.google.com/open?id=1zcBMS ... h4k8xv2jdS

[aluigi]

I analyzed the file you provided and noticed that now the "PK\x05\x06" entry has been replaced with a "PK\x06\x06" entry having the following custom format:

Code: Select all

get ZERO byte
get central_entries longlong
get central_size longlong
get central_offset longlong
get DUMMY_offset longlong

Unfortunately there is something small changed in the encryption algorithm because the first byte every 8 is partially invalid.
In my opinion it's something related to NextUInt64().

[Rev3n4nt]

Is there anything new about encrypting renewed PAK format? If it's NextUInt64(), is there a way meybe to bruteforce invalid first byte every 8 ? I'm not a coder really, but I hope there will be solution soon for this, so communities like "Garry's mod", "XNALara", and "Quake1 models mods" can get some models from QC for them asap

[buk0wski]

Hey luigi, good to see that you're still doing great work after all this years.
However, bump?! What happened here, did they change the init vectors? Do you think there is any practical way to solve this issue?

And besides, how did you even find the correct NextUInt64() function in the first place?

[buk0wski]

This is what I get from changing "PK\x05\x06" to "PK\x06\x06" in lines 69 and 71 of the .bms file.
central_offset is wrong I suppose? (line 81, goto)

EDIT:


It's somewhat evolving. I updated the header format and added prints to keep track of everything. The dummy doesn't look legit tho

I'll continue tomorrow, it's already quite late. However this isn't hopeless I think

[aluigi]

Do you think there is any practical way to solve this issue?

Sure, buy the game, find NextUInt64 with the help of the constant numbers used in the algorithm, spot the differences and give me the result

[buk0wski]

I did it with literally every constant (as hex ofc), but without any success. Seems like the switched the entire RNG process, while leaving the decrypt function itself technically the same.
But in fact the exe doesn't even disassemble properly (with IDA Free v7). All that I realized is that my capabilities and knowledge are not yet sufficient for this kind of nuisance.

[aluigi]

Try searching the constants in hex for NextUInt64:
2862933555777941757ULL = 0x27bb2ee687b0b0fd
7046029254386353087ULL = 0x61c8864680b583bf
4294957665U = 0xffffda61
21 and 35

The only other constant available is the one of NrRandom:
4101842887655102017ULL = 0x38ecac5fb3251641

Locating these functions should be really very easy. If you need to make some practice this is the perfect occasion.

It's perfectly possible that the exe is encrypted, being on Steam you probably need to use steamless to decrypt it first:
https://github.com/atom0s/Steamless/releases

Worst case scenario dump the memory and do it the raw way