Help with archive format in the God of War 2 (PS2)

[Mirakichi]

God of War 2 Structure of GODOFWAR.TOC File
Hi guys, I am writing a small tool in C to allow dump and repack the files inside the
PART1.PAK and PART2.PAK archive from the God of War 2 (PS2). My tool is able to dump
properly the files inside the PART1.PAK, but the PART2.PAK I don't know how to get
the proper offset to reach the file inside the PART2.PAK.
Below is some infos about the GODOFWAR.TOC and too the link with the sample of PART1.PAK
and PART2.PAK. If someone can help me, I'll be grateful.
Link with the samples: https://drive.google.com/file/d/1KpD52N ... sp=sharing

Some infos about the GODOFWAR.TOC format:
The GODOFWAR.TOC file has the infos as offsets, filesize, id_archive and filenames
of all files inside the PART1.PAK and PART2.PAK archive.
These infos about the GODOFWAR.TOC file I've understood thanks the bms script made by
aluigi.
There is only two PAK archives named PART1.PAK and PART2.PAK inside the original game iso.
The PART2.PAK is stored in the second layer of iso. The second layer I can extract it
using the Apache software.
The structure of GODOFWAR.TOC is the following:

STRUCTURE WITH THE FILENAME, FILESIZE, ID_PART AND ID_OFFSET (0x24 bytes)
0x00 - FILES COUNT long
0x04 - Filename string (the string length is always 0x18 bytes filled with 0x00)
0x1C - Filesize long
0x20 - id_archive long - if the bytes in this field are 0x00, 0x01, 0x02, 0x03,
0x04, the file is stored in PART1.PAK. If the bytes are greater than 0x04, the file is
stored in the PART2.PAK.
0x24 - offset_id long (offset_id * 4 + 32872) - The value in this field points to the
GODOFWAR.TOC offset where are 4 bytes long that multiplied by 0x800 generate the offset
to the file in the PART1.PAK or in the PART2.PAK archive. To the files stored in the
PART2.PAK, not is possible to get the proper offset using 0x800. This is the only
info that I need to know to finish my C code to dump and rebuild the PART1.PAK and
PART2.PAK archive.

[aluigi]

"Sorry, the file you have requested does not exist."
Did you find a solution?

[Mirakichi]

Yes, I managed to make the tool to dump properly the files from PART1.PAK and PART2.PAK archives from the God of War 2. The special number to find the offsets in the PART2.PAK it was in your script the whole time and only then did I see that number in the script, the number is 10000000. I took what I understood from your script to make my tool.
Now I am trying to do a tool to dump the files from an archive of the Mortal Kombat Shaolin Monks (PS2) using the infos of an bms script made by you. I've understood how to find the offsets,
but I can't understood how to get the properly filesize, it seems this archive stores the filesize in the TOC in an encrypted way.
The line in the script that apparently decrypt the filesize is below:
line 1 xmath SIZE "(SIZE & ((1<<20)-1)) * 4"
line 2 PRINT "Filesize is %SIZE|h%"
The filesize of one the files in the archive is 0xF5015008. This value is in the TOC as a Little Endian value.
In the script, the SIZE variable in the line 1 has the value 0xF5015008 that is the filesize.

In the line 2 the PRINT command show properly the filesize that is 0x00007D4 or 2004 bytes.
I know the ((1<<20)-1)) * 4 instruction generate it the 4194300 number, but I don't know the operation made with the & symbol.
I use the PRINT command to show the values in the variables and to help me better understand what the bms script is doing.
Can you tell me what operation is done in line 1.
I want to do the same operation in C to finish my tool.
This link has the bms script with the commands above https://drive.google.com/file/d/1RhxANZ ... sp=sharing
Thnaks in advance!

[aluigi]

I updated that script just few days ago for supporting version 2 of the WAD files (just in case):
http://aluigi.org/bms/mksm_ewdf.bms

Basically those instructions done on the collected OFFSET and SIZE are used for reading the correct bits.
OFFSET is a 22 bits field which must then multiplied by 2048.
SIZE is 20 bits multiplied by 4

Code: Select all

######################..####################............
|                     | |                   |
|                     | |                   ???
|                     | SIZE * 4
|                     ???
OFFSET * 2048

[Mirakichi]

If the SIZE is 20 bits, so if I have 0xF5015008, I must read as 0x85001F5 and to consider only 0x85001 and then multiply by 4?
I do this but I can't to get 0x7D4 or 2004 bytes

[aluigi]

Do you mean there is a bug in a script or in your tool?

0x7d4 / 4 = 0x1f5 so it looks correct: (0x85001F5 & ((1<<20)-1)) * 4 = 0x7d4

[Mirakichi]

The script works properly, I just can't understood as 0xF5015008 can be converted to 0x7D4

[aluigi]

little endian

[Mirakichi]

Ah, I think that I've understood! The 2 first bytes 0xF501 is the filesize when multiplied by 4. And what the meaning of the last 2 bytes 0x5008?

[aluigi]

I didn't investigate the meaning of the remaining bits.

[Mirakichi]

Hey aluigi, I've managed to do the tool, but I don't know if the extraction is proper, the GAMEDATA.WAD is 388MB, but my tool dump about 700MB. Can you take a look in my C code and check if I understood properly the GAMEDATA format?
If yes, here is the link with my C code https://drive.google.com/file/d/1FAeFfx ... sp=sharing

[aluigi]

HextoDec is wrong because you have set all the shift to 8 while they should be: 24, 16, 8.
Since it's just little endian like the supposed platform you are using, you can just use: number = *(int *)data;
(usually 32bit are also read as "long" but in my experience I prefer "int" because long is 64bit on 64bit compilers).

There is no need to use fseek when you work with sequential data read via fread, you need it only when you go to read the magic field of each file and then back.

data_field seems wrong because 20 bits take at least 3 bytes and not 2 as you set there.

The part from "y = Header_Check(header);" seems a bit chaotic.

Remember that the "EWDF" files are compressed with deflate.

[Mirakichi]

Thanks, I'll try to improve the code here

[BL4CK0UT]

Thanks, I'll try to improve the code here

so? where is this "tool"??

[Ekey]

so? where is this "tool"??

https://zenhax.com/viewtopic.php?p=59425#p59425

[BL4CK0UT]

so? where is this "tool"??

https://zenhax.com/viewtopic.php?p=59425#p59425

Thanks! does this works on God of War 2 .PAK?