Dolphin Posted July 20 Share Posted July 20 (edited) 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 by Dolphin Link to comment Share on other sites More sharing options...
DKDave Posted July 20 Share Posted July 20 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. 1 Link to comment Share on other sites More sharing options...
Durik256 Posted July 21 Share Posted July 21 (edited) 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 by Durik256 1 Link to comment Share on other sites More sharing options...
Dolphin Posted July 21 Author Share Posted July 21 Thanks to both of you, I'll look at the files tomorrow. It's a pity that the compression doesn't work( Link to comment Share on other sites More sharing options...
Dolphin Posted July 24 Author Share Posted July 24 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 Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now