Fantastic Four (PS3) unk archive

[Dolphin]

Hello everyone, I'm trying to unpack the files of the game Fantastic Four (PS3), but it has strange archives A,B,C,D... K. I think this is one archive divided into parts of 524 MB. The first file A seems to have tables, but I'm not sure, I tried to read it and got something strange.

Spoiler

import os
import struct

path = r'A'
with open(path, 'rb') as f:
	f.seek(16)
	num = struct.unpack('>I', f.read(4))[0]
	f.seek(156)
	for x in range(num):
		u = struct.unpack('>3I', f.read(12))
		print('u:', u)
	print('end:', f.tell())
os.system('pause')

out:

(353811, 13150, 19)
(1418124, 1945945, 318)
(3449626, 1522033, 1260)
(4707287, 1223433, 1484)
(5345551, 516675, 367)

...

(4292664833, 1535909, 144)
(4292822971, 2687031, 215)
(4293865469, 1963382, 1313)
(4294827671, 1930247, 1428)

please help me decipher this or find out what kind of compression/encryption it is. I will be grateful for any information. also a link to Google Drive (all files and Hex screenshots of the beginning of each file). FILE LINK

 

Edited July 20, 2024 by Dolphin

[DKDave]

1 hour ago, Dolphin said:

Hello everyone, I'm trying to unpack the files of the game Fantastic Four (PS3), but it has strange archives A,B,C,D... K. I think this is one archive divided into parts of 524 MB. The first file A seems to have tables, but I'm not sure, I tried to read it and got something strange.

  Reveal hidden contents

import os
import struct

path = r'A'
with open(path, 'rb') as f:
	f.seek(16)
	num = struct.unpack('>I', f.read(4))[0]
	f.seek(156)
	for x in range(num):
		u = struct.unpack('>3I', f.read(12))
		print('u:', u)
	print('end:', f.tell())
os.system('pause')

out:

(353811, 13150, 19)
(1418124, 1945945, 318)
(3449626, 1522033, 1260)
(4707287, 1223433, 1484)
(5345551, 516675, 367)

...

(4292664833, 1535909, 144)
(4292822971, 2687031, 215)
(4293865469, 1963382, 1313)
(4294827671, 1930247, 1428)

please help me decipher this or find out what kind of compression/encryption it is. I will be grateful for any information. also a link to Google Drive (all files and Hex screenshots of the beginning of each file). FILE LINK

 

Yes, the file table in "A" covers all of the archive parts.  As you've already seen in the file, the table consists of 3 values - the first one could be a filename hash, the 2nd value is the offset, and the 3rd value is the size.  Offset and size are multiplied by 0x800 to get the actual offset and total size.  You'll need to do some calculation to get the correct archive (something like offset // 0x20000000 should give you the archive, and offset % 0x20000000 should give the offset within that archive).

I'm not sure of the compression, but it looks to be some sort of LZSS variation, and each file seems to consist of multiple parts.

 

[Durik256]

On 7/20/2024 at 8:47 PM, Dolphin said:

archives A,B,C,D... K

 

I wrote an unpacker (using DKDave's tips) for your files, and made a parser of the resulting files (out of 2700+ files, about 130 have a different structure)

 

here is an random example output for the file 0x1a3a5ac5.dat: (this file is in the archive with scripts)

Spoiler

magic: 4282118036
u0ofs: 168
u1ofs: 2968782
zero: 0
numUnkBuf: 2
u0: 13
numFiles: 3
u1: 69

UnkBuf::
    unk: (3137710529, 3137710529, 16, 528, 7, 168, 147, 0)
        bufInf: (239613891, 528, 147, 7, 8)
    unk: (1091909333, 1091909333, 128, 3058856, 8, 315, 2968467, 0)
        bufInf: (239613891, 3058856, 2968467, 8, 14)

::
unk: (13, 29, 45)

UnkFiles::
    unk: (2771081590, 1547079785, 2, 352, 2796288)
    unk: (3149827392, 1547079785, 2, 176, 1398144)
    unk: (4088350104, 1547079785, 2, 0, 0)

End::
sizeEndBlock: 816 num: 3 unk1: 5
unk: (13, 61, 109)

unk_inf::
    unk: (157, 309, 2, 311, 317, 16, 176, 176, 311, 317, 128, 262568, 262568)
    unk: (311, 473, 2, 475, 481, 16, 176, 176, 475, 481, 128, 1398096, 1398096)
    unk: (475, 639, 2, 641, 647, 16, 176, 176, 641, 647, 128, 1398096, 1398096)

path:: 2968966
     art/environments/redghost/ibl/rg_ibl_set1_diffuse.tga_256x256_CC_cubemap_ARGB TXTR DRAM DRAM VRAM VRAM [77]
     art/environments/redghost/textures/rg_350_sidewall_b_albedo.tga_1024x1024_WW__ARGB TXTR DRAM DRAM VRAM VRAM [82]
     art/environments/redghost/textures/rg_350_cylinders_a_albedo.tga_1024x1024_WW__ARGB TXTR DRAM DRAM VRAM VRAM [83]

 

---

On 7/20/2024 at 9:57 PM, DKDave said:

but it looks to be some sort of LZSS variation

judging by the lines and sizes inside the file, these are clearly textures, I don’t know compression algorithms, I tried using comtype_scan QBMS. and then looked at the output files, nothing looked like a texture, also “LZSS”

 

EDIT: I uploaded the wrong file (changed)

files.zip

Edited July 24, 2024 by Durik256

[Dolphin]

Thanks to both of you, I'll look at the files tomorrow. It's a pity that the compression doesn't work(

[Dolphin]

I tried to do something about it for several days, still a problem with this compression.

I unpacked and loaded all the files to disk https://drive.google.com/drive/folders/14bKG7HQH_2-rW9vVUui3ylbz42Z9Wjbx?usp=sharing

[Dolphin]

still trying to figure it out. I ran the qbms scanner several times, but I don't see any result. Can someone with a fresh look understand what kind of compression this is? thanks in advance🥲