several db2 files can't be read from last PTR version

[Jeromnimo]

Hi Ladislav,

trying to update WMV to support 8.1, I am currently facing this issue : when I try to read Item.db2, creature.db2 or itemsparse.db2, I get a 6002 error (ENCRYPTED_FILE) when calling CascReadFile, even for reading the first 4 bits, to get the "magic" number. According to recent WDC3 changes, some sections of the files are probably encrypted, and we don't know the key yet according to wowdev.wiki

However, I am wondering if we are supposed to be stuck because file is partially encrypted with this key, or if we should be able to read other sections if the key is not the same.

I don't know how to easily dump key used overall for the file, let me know how to do it if you need more info.

Note : using CASCView produces the same result, we can't preview these 3 files in it.

[ladislav-zezula]

If the key is not known, then I can't do anything about it. We need to wait until the key becomes public.

[Jeromnimo]

The point is about checking is the full file is encrypted, on only a subset of sections. It seems you are reading files « page by page » in casclib. Today, even reading the first 4 bytes to get « magic » is impossible... not sure if encryption is done at file level or section level. Is there a way to check it?

[ladislav-zezula]

Should be OK to read first 4 bytes only, unless the first block is encrypted. I'll download the whole WoW installation and check :-)

[ladislav-zezula]

I checked on WoW PTR 8.1 (WoWT.exe =8.1.0.28085), tried to open these files:

• DBFilesClient\Item.db2
• DBFilesClient\Creature.db2
• DBFilesClient\ItemSparse.db2

Item.db2 and ItemSparse.db2 are partially encrypted, but I was able to read the first 4 bytes just fine.

• DBFilesClient\Item.db2: The first frame is 0x31C bytes long
• DBFilesClient\ItemSparse.db2: The first frame is 0x798 bytes long

To read the header, please, make sure that you only read the first frame. Do not read to buffer which is like 0x1000 bytes long.

[Jeromnimo]

Thanks for the try Ladislav. On my side, I was used to read all data at the same time (copying file content to get a memory buffer). I will need to change this strategy, in addition to wait for new key to be available...

[ladislav-zezula]

Originally, I used to do the same with StormLib (and MPQs). But here in Casc world, the blocks of the file are selected based on best compression and with variable length.

[WainPetopia]

Thanks, Ladislav! I wonder if this means they're going to encrypt a lot more of their data from now on and if this will require more frequent updates of tact keys in CASCLib. :/ if so, would it be possible to add a way for the lib to read extra tact keys from an external text file or database? That way users could use new encrypted data without always having to wait for the next client update to include the keys.

[ladislav-zezula]

if so, would it be possible to add a way for the lib to read extra tact keys from an external text file or database?

I'll do.

Off topic: Do you know what does 'tact' stand for?

[WainPetopia]

if so, would it be possible to add a way for the lib to read extra tact keys from an external text file or database?

I'll do.

Off topic: Do you know what does 'tact' stand for?

I had to look it up :) Trusted Application Content Transfer

https://wowdev.wiki/TACT

[Jeromnimo]

if so, would it be possible to add a way for the lib to read extra tact keys from an external text file or database?

I'll do.

Off topic: Do you know what does 'tact' stand for?

I think the best is to "simply" add an "addKey" funciton exposed at lib level. Then if an application want to use a file, db, whatever to manage some additional keys, it simply have to call this function for a set of keys

[ladislav-zezula]

bool WINAPI CascAddEncryptionKey(HANDLE hStorage, ULONGLONG KeyName, LPBYTE Key);

Commit bc515c56e05530b234058fe769f8c295015f675c.

[Jeromnimo]

Thanks @ladislav-zezula ! That was fast :)

[WainPetopia]

Fantastic! Thank you :)