Question about how to obtain decryption key for UE4 title.

[L33THAK0R]

Originally Posted by Joe Forster/STA

I can confirm this, with AES finder 0.9f. The .pak files do seem to be encrypted, though. Yes, probably AES finder doesn't support this game (yet).

Thank you for confirming Joe, thankfully there are many more UE4 games for me to try my hand at compressing! Fingers crossed a future version supports this title!

[Joe Forster/STA]

Originally Posted by L33THAK0R

there are many more UE4 games for me to try my hand at compressing!

Do you have one for which AES finder can find the key? (I think it will find keys in 32-bit executables only.)

[L33THAK0R]

Originally Posted by Joe Forster/STA

Do you have one for which AES finder can find the key? (I think it will find keys in 32-bit executables only.)

"Samurai Jack - Battle Through Time" which has the file name "SJGAME-Win64-Shipping.exe", (which I'm thinking is a 64-bit executable) generates the key "0x8E0A631576F6CBE340BF039C7C5BB8632E6FDC1082E019B 646B44B2846C96855". Currently attempting to compress some other games right now but I'll be sure to give it a shot in the coming days. Tried getting a key from the game "Satisfactory", but I'm having issues unpacking it with steamless, might ask over on the cs forums for help with that though, as I don't think its relevant here.

[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.

[Masquerade]

UnrealPAK is OK, however if you are extracting ue4 paks I recommend using quickbms.

If any key is needed, it prompts you at the start of the extraction process.

There's a script on Luigi's site, but there's also updated scripts which have better chance of working on cs forum (not entirely sure I'm allowed to link it for obvious reason). This thread contains long list of keys also.

@Joe you'll need to specify the key in order to decrypt/extract the pak - regardless if the full pak is encrypted or only Table of Contents.

All ue4 games run fine when their pak files are unpacked.

[Joe Forster/STA]

Originally Posted by Masquerade

updated scripts which have better chance of working on cs forum (not entirely sure I'm allowed to link it for obvious reason). This thread contains long list of keys also.

Yes, I think we made maximum use of this topic on this forum.

[L33THAK0R]

Originally Posted by Masquerade

UnrealPAK is OK, however if you are extracting ue4 paks I recommend using quickbms.

If any key is needed, it prompts you at the start of the extraction process.

There's a script on Luigi's site, but there's also updated scripts which have better chance of working on cs forum (not entirely sure I'm allowed to link it for obvious reason). This thread contains long list of keys also.

@Joe you'll need to specify the key in order to decrypt/extract the pak - regardless if the full pak is encrypted or only Table of Contents.

All ue4 games run fine when their pak files are unpacked.

I had no idea all ue4 games run fine with the .pak files unpacked! Definitely keen to experiment with this!

[Masquerade]

When I say "all" there may be one or two exceptions, none that I can think of...

Before I figured out how to use XTool, I used to unpack the games

[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.

Attempted to Extract the .pak (only 1 exists) for Samurai Jack, can confirm a key is required. When inputting a key (using BMS script) extraction is successful. Thank you so much for your help man!

[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!