Divinity: Original Sin EE .pak

[Panzerdroid]

Hello,

It seems that with new version dev changed deflate in game packs to LZO.

Could anyone help with a proper BMS script?

Thanks in advance!

3 small sample files:
http://www43.zippyshare.com/v/TfVlMyeE/file.html

[aluigi]

I don't know what compression algorithm is used for the information table at the end of the archives.
And no, lzo is not used for the files (for example icons.pak from offset 0 to 83268)

[Ekey]

Well header now always at the end in every pak.

Code: Select all

struct PAKHeader
{
   uint32_t   dwVersion; // 13 > Previous version is 10
   uint32_t   dwTableOffset;
   uint32_t   dwTableSize;
   uint32_t   dwFlag; // 1
   uint8_t    iMD5[16]; // Seems md5 hash
   uint32_t   dwUnknown; // Always 40
   uint32_t   dwID; //LSPK
};

Code: Select all

goto dwTableOffset;
get dwTotalFiles long;

[aluigi]

Is there any difference between the Enhanched Edition and the standard one?
I have noticed that the archives of the previous versions were different with the header at the beginning and without this strange compression.

[Panzerdroid]

Is there any difference between the Enhanched Edition and the standard one?
I have noticed that the archives of the previous versions were different with the header at the beginning and without this strange compression.

Yes, they redone a lot of things, changelist is huge. So I think changing of pak format was necessary for them (now the game ported to consoles as well).

[Ekey]

In previous version table was not compressed, but file data's was compressed by LZ4 and ZLIB. Seems table compressed even as LZ4.

[aluigi]

I have read that there is an official editor from Larian for the previous version so maybe it will happen the same for this new one too.

[Panzerdroid]

Yeah, maybe some day - I didn't found anything about near plans

[Ekey]

It's LZ4, no doubt. PseudoCode (http://i.imgur.com/CBjCg2C.png)

[Panzerdroid]

I slightly missed with compression type
How do you people even understand all those machine codes!

[aluigi]

lz4 for the files but lz4 doesn't work with the information table.

[Ekey]

Tomorrow i will test it fully.

[Ekey]

I did a test decompressor (LZ4 r128) and it works like charm

test1.dat - table from Engine.pak
test2.dat - table from Main.pak

*.dec files already decompressed data.

Decompressed size = entry count * 280

[Ekey]

Code: Select all

struct PAKEntry
{
   uint8_t    iFileName[256];
   uint32_t   dwOffset;
   uint32_t   dwZSize;
   uint32_t   dwSize;
   uint32_t   dwPakNum;
   uint32_t   dwUnknown; // Always 66
   uint32_t   dwCRC32; // For compressed data
};

[aluigi]

It's a fault of lz4 that returns errors if there are bytes after the stream, just like happens with Witcher3 in reimport mode.
In short I had the 0x0d000000 long still attached to my input data and it caused the error.
I have to check if I can bypass this issue in quickbms to improve the compression scanning or if there is no solution.

[aluigi]

Ok, I don't think there is solution for lz4... it's just a raw stream.

The script is almost ready but EngineShaders.pak gives some problems.
*edit* there is an additional 32bit zsize at the beginning, the files are too small to guess if it's a tentative of chunks or just a different and useless way.

Additionally does someone know if some of the paks of the previous versions were compressed too?

[Panzerdroid]

Test decoder works, thank you! But I guess it doesn't support decompression of the whole pack yet, right?

[aluigi]

This is the script but we need to find how it should work with EngineShaders.pak because lz4 fails with the second file:

*edit*
http://aluigi.org/bms/lspk.bms

[Ekey]

Here example pak's from previous version (all types)

[Ekey]

Also seems some pak files could be separated. For Example Textures.pak have normal header at the end but Textures_1.pak and Textures_2.pak it does not have. here samples.