Question about how to obtain decryption key for UE4 title.

[Masquerade]

Originally Posted by KaktoR

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

No, move the pak file to a separate folder outside of the game, unpack it, then move the unpacked files to the root of the game folder. The pak file contains stuff outside of the Content / Content\Paks folder.

[dixen]

Originally Posted by Joe Forster/STA

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.

This feature -create does not work in this version

[Masquerade]

I am also having issues trying to make paks with the UnrealPak, I tried with Partisans.

[L33THAK0R]

Originally Posted by Joe Forster/STA

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.

Hi Joe sorry to ask but did you have any difficulties extracting PAK 0? I'm using the GOG release and always seem to hit a byte allocation error, with QuickBMS, and a series of errors when using UnrealPakTool, however I'm able to unpack all the other PAK files with no issues.

[Joe Forster/STA]

Originally Posted by L33THAK0R

did you have any difficulties extracting PAK 0?

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:

LogPakFile: Display: Extracted "Engine/Content/EditorBlueprintResources/StandardMacros.uasset" to ".../Engine/Content/EditorBlueprintResources/StandardMacros.uasset" Offset 0.

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.

[L33THAK0R]

Originally Posted by Joe Forster/STA

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:

LogPakFile: Display: Extracted "Engine/Content/EditorBlueprintResources/StandardMacros.uasset" to ".../Engine/Content/EditorBlueprintResources/StandardMacros.uasset" Offset 0.

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.

Huh I think I actually understood that, I'll try re-downloading the tools to see if the original source is the issue (outdated or an unstable version as I don't quite remember what version either were, and I didn't document this), it's still a puzzle to me why I was unsuccessful and you were, but I suppose sometimes shit breaks for reasons we cannot fathom, thank you for the explanation!

[L33THAK0R]

UPDATE: Issue with Chernobylite pak0 has been resolved, thanks to a revision on the UE4.26 QuickBMS script, courtesy of spiritovod on the ZenHax forums. The attached file is the revised script for anyone looking.