Originally Posted by KaktoR (Post 491573)

I think the unpacked files have to be in a folder which is exactly named as the corresponding pak file.

Originally Posted by Joe Forster/STA (Post 491563)

According to this utility: UnrealPak, Chernobylite's files are not encrypted, only compressed (with ZLib). I could list and extract the contents of any of the PAK's. If I understand correctly, you have to specify the AES key in the "Crypto.json" file of this utility to be able to decrypt files; if the PAK "index" is also encrypted, you won't even be able to list the files inside without the proper key. So I think AES finder was right: there's no key in this game.

This also means that you won't be able to significantly compress the game as it is further because it's already compressed, unless you extract everything from all the PAK's. [...] I tried it: Chernobylite works fine it this unpacked form - I could load the last savegame in the base and start a mission - and the (unpacked) files don't seem to be encrypted. (You can't compress encrypted files much anyway.) I extracted the PAK's in this order: 0, 1, 3, 3optional, ..., 9, 10, ..., 15. About 124 thousand files, 40.6 gigabytes. The "ChernobylGame" and "Engine" directories extracted from the PAK's go to the root directory of the game, all other directories go under "ChernobylGame\Content".

Can you confirm that you cannot list of extract files from "Samurai Jack - Battle Through Time" with the same utility? Without explicitly specifying the AES key, that is.

Originally Posted by Joe Forster/STA (Post 491563)

According to this utility: UnrealPak, Chernobylite's files are not encrypted, only compressed (with ZLib). I could list and extract the contents of any of the PAK's. If I understand correctly, you have to specify the AES key in the "Crypto.json" file of this utility to be able to decrypt files; if the PAK "index" is also encrypted, you won't even be able to list the files inside without the proper key. So I think AES finder was right: there's no key in this game.

This also means that you won't be able to significantly compress the game as it is further because it's already compressed, unless you extract everything from all the PAK's. [...] I tried it: Chernobylite works fine it this unpacked form - I could load the last savegame in the base and start a mission - and the (unpacked) files don't seem to be encrypted. (You can't compress encrypted files much anyway.) I extracted the PAK's in this order: 0, 1, 3, 3optional, ..., 9, 10, ..., 15. About 124 thousand files, 40.6 gigabytes. The "ChernobylGame" and "Engine" directories extracted from the PAK's go to the root directory of the game, all other directories go under "ChernobylGame\Content".

Can you confirm that you cannot list of extract files from "Samurai Jack - Battle Through Time" with the same utility? Without explicitly specifying the AES key, that is.

Originally Posted by L33THAK0R (Post 491579)

did you have any difficulties extracting PAK 0?

Originally Posted by Joe Forster/STA (Post 491585)

No difficulties here (GOG v33909) but I think I know what's wrong with UnrealPak: it handles file offsets and sizes as signed 32-bit (maximum of 2 GB) values.

When you extract files from PAK 0 (2967 MB), you get a line for each file like this:
And often offsets are negative numbers.

When extracting from PAK 1 (9128 MB), offsets obviously start from 0, go upwards to 2 GB, then switch to -2 GB and continue going upwards. This would suggest that files extracted from most of PAK 1 - above 4 GB - may be damaged - because they have been extracted from the wrong part of the PAK - but that's not the case: they don't seem to be damaged and you couldn't decompress damaged ZLib streams anyway without noticing. So, probably, only the display of file offsets is wrong but I can't tell as there's no source code: you can download the "source code" from GitHub but that's just another copy of the binaries. (?!)

PAK 0 is the only one whose size is between 2 GB (maximum of 32-bit signed integer) and 4 GB (32-bit unsigned integer); this may be why you're experiencing this error with it and only it. Look at the error message and you'll see that the file size is negative.

QuickBMS's error message looks similar: it's trying to allocate a negative number of bytes.