Unreal Engine 4 pak-file Unpacker / unreal_tournament_4.bms [UE4 global topic]

[aluigi]

The files inside the pak archives aren't encrypted.
Have you tried to just press RETURN when quickbms tells you to select the encryption key?

[ssringo]

When I tried using umodel with the game it said a bunch of files were encrypted (and couldn't load anything) so I figured I'd take it's word. Thank you for the info though. After extracting with your script I can view textures (no models though).

[GamingDamned]

I get this error:


QuickBMS generic files extractor and reimporter 0.8.0
by Luigi Auriemma
e-mail: me@aluigi.org
web: aluigi.org
(Mar 12 2017 - 15:03:46)

quickbms.aluigi.org Homepage
zenhax.com ZenHAX Forum
@zenhax Twitter & Scripts

- GUI mode activated, remember that the tool works also from command-line
where are available various options like folder scanning, filters and so on

- select the BMS script to use
- select the input archives/files to extract, type * or "" for whole folder and subfolders
- select the output folder where extracting the files
- open input file C:\Users\GamingDamned\Desktop\SummerCamp\SummerCamp.uproject
- open script C:\Users\GamingDamned\Desktop\New folder\unreal_tournament_4.bms
- set output folder C:\Users\GamingDamned\Desktop\SummerCamp

offset filesize filename
--------------------------------------

Error: incomplete input file 0: C:\Users\GamingDamned\Desktop\SummerCamp\SummerCamp.uproject
Can't read 4 bytes from offset 6f625822.
Anyway don't worry, it's possible that the BMS script has been written
to exit in this way if it's reached the end of the archive so check it
or contact its author or verify that all the files have been extracted.
Please check the following coverage information to know if it's ok.

coverage file 0 3% 44 1402 . offset 6f625822

Last script line before the error or that produced the error:
149 get NAMESZ signed_long

Press ENTER or close the window to quit

[tonaz]

The unpacker by Haoose seems to don't work with big pak files (like 15GB), while it worked for some 100MB pak files i unpacked.
Can anyone suggest me something?
Thanks!!

[aluigi]

@GamingDamned
uproject is not pak, the script works with pak archives

@tonaz
Does the script for quickbms work?

[GamingDamned]

@GamingDamned
uproject is not pak, the script works with pak archives

@tonaz
Does the script for quickbms work?

I know i want to repack the files back into a pak. So how do i repack my modified files?

[aluigi]

The reimport feature of quickbms should work correctly, please read section 3 of http://aluigi.org/papers/quickbms.txt for all the information and limitation.
And remember the main and most important rule of this feature: SELECT THE SAME FILES AND FOLDERS YOU SELECTED FOR THE EXTRACTION

[GamingDamned]

The reimport feature of quickbms should work correctly, please read section 3 of http://aluigi.org/papers/quickbms.txt for all the information and limitation.
And remember the main and most important rule of this feature: SELECT THE SAME FILES AND FOLDERS YOU SELECTED FOR THE EXTRACTION

I've tried it and still bit confused. I don't doubt the feature does work. But i need proper steps for this. I really wanna test my edits in game and then release it whenever to public.

[aluigi]

viewtopic.php?p=23032#p23032

[GamingDamned]

https://zenhax.com/viewtopic.php?p=23032#p23032

Thank you finally that example worked.

[GamingDamned]

I got 1 issue tho. How do i fix this error?



Game Runs fine but gets the error allows me to close window and play but causes some issues with the game not finding these files. I've manually went to their directory and found the files there but why is it giving this error if the files are there? If i can fix this then my mod is complete.

[aluigi]

I assume all your edited files were smaller/equal than the originals and you removed those that you didn't edit.

That error may be caused by a non-compressed file that was shorter than the original and the engine doesn't "like" it or it may be caused by a file compressed with the snappy algorithm because both zlib and gzip are more "easy" to be accepted (99% of times your compressed size is different than the original) but snappy is probably a problem.

Honestly I have no suggestions at the moment, probably you can try to rebuild the pak with some official/non-official tool or try with the classical exclusion technique: edit one file, reimport, run the game, edit the second file, reimport, run the game and so on till you get the crash.

[GamingDamned]

I assume all your edited files were smaller/equal than the originals and you removed those that you didn't edit.

That error may be caused by a non-compressed file that was shorter than the original and the engine doesn't "like" it or it may be caused by a file compressed with the snappy algorithm because both zlib and gzip are more "easy" to be accepted (99% of times your compressed size is different than the original) but snappy is probably a problem.

Honestly I have no suggestions at the moment, probably you can try to rebuild the pak with some official/non-official tool or try with the classical exclusion technique: edit one file, reimport, run the game, edit the second file, reimport, run the game and so on till you get the crash.

Thing is i've never edited these files tho.

[aluigi]

Very bad, it means you are trying to reimport the 100% of the files.
With compressed files you have to reduce at minimum the amount of reimported files just to avoid problems with most of the compression algorithms.
Edit one of the files you really need to reimport and retry (use ever the original backed-up archive)

[GamingDamned]

Very bad, it means you are trying to reimport the 100% of the files.
With compressed files you have to reduce at minimum the amount of reimported files just to avoid problems with most of the compression algorithms.
Edit one of the files you really need to reimport and retry (use ever the original backed-up archive)

Still same issue i removed all unedited files and still get same error in game. I really need a fix for this sadly.

[UncleFestor]

. I just realized that this isn't a thread for tekken 7. Sorry about that. Should I post this in another thread?

Is there anyone here that can create a script to extract the textures from the uasset files for this game ? I already figured out how they're structured, but i'm not at all versed in QuickBMS so, I have no clue how to create the necessary script.

Steps to take to locate Textures & mipmaps:

Binary Search for 8-Byte String: 01 00 00 00 48 00 00 00 - These seem to be 4-Byte Nametable entries
Read 4-Bytes - Texture Data Length - Endianness needs to be swapped - 00 00 08 00 = 80,000 - Data Length
Read 4-Bytes - Texture Data Length (Duplicate Entry)
Read 4-Bytes - Starting Offset - This is where you get the start of the texture, Endianness needs to be swapped to get offset.
Read 4-Byte NULL
Start of texture - Apply Texture Data Length
End of Texture
Read 4-Bytes - Texture Width - Swap Endian & convert Hex to Dec
Read 4-Bytes - Texture Length - Swap Endian & convert Hex to Dec
Repeat steps for subsequent Mipmaps, So, Binary Search for 8-Byte String: 01 00 00 00 48 00 00 00 Etc...

[aluigi]

Tekken 7 uses the UE4 engine so it's ok I guess although would be more appropriate to make a new topic in the Graphics section.

Regarding the script:

Code: Select all

for i = 0
    findloc OFFSET binary "\x01\x00\x00\x00\x48\x00\x00\x00"
    math OFFSET + 8
    goto OFFSET
    get SIZE long
    get SIZE long
    get OFFSET longlong
    math TMP = OFFSET
    math TMP + SIZE
    goto TMP
    get WIDTH long
    get LENGTH long
    string NAME p "%d_%dx%d.raw" i WIDTH LENGTH
    log NAME OFFSET SIZE
next i

*edit* script updated

[UncleFestor]

Thanks for the script pimpin'

[UncleFestor]

Tekken 7 uses the UE4 engine so it's ok I guess although would be more appropriate to make a new topic in the Graphics section.

Regarding the script:

Code: Select all

for i = 0
    findloc OFFSET binary "\x01\x00\x00\x00\x48\x00\x00\x00"
    goto OFFSET
    get SIZE long
    get SIZE long
    get OFFSET long # unused?
    get ZERO long
    savepos OFFSET
    math TMP = OFFSET
    math TMP + SIZE
    goto TMP
    get WIDTH long
    get LENGTH long
    string NAME p "%d_%d_%d.raw" i WIDTH LENGTH
    log NAME OFFSET SIZE
next i

There's a slight error with the script, and it's probably because I didn't explain properly. It ends with an error, and I can see that the starting offset is incorrect:



In that screen shot the starting offset is 0x439. But that's actually the offset where the package defines the starting offset of the 1st texture. So @ that offset you'll find a 4-Byte string: 41 04 00 00. The actual texture starts @ that location, Offset 0x441

Here's the file I'm extracting textures from, in case that would make things easier for you.

[aluigi]

My little mistake, script updated in my original post.