Kula World Archive

[evlgsr]

Hey All,

I have been racking my brains out trying to figure out how this archive (if it is indeed an archive) file is structured, it doesn't conform to any standard i read about apart from the file names being listed in plain text i can see the structure follows goes like this

header -> file names -> file header -> file data

if someone can write a script but most importantly show me how you got to that point that would be great, i am not trying to get the files out of that archive just trying to learn how to read a raw archive file.

[aluigi]

http://aluigi.org/bms/kula_world.bms

[evlgsr]

Awesome, thank you

quick question how did you come up with that and what kind of archive was it.

[aluigi]

The archive is splitted in the following parts:

• number of files
• offset + compressed size of each file
• offset of each filename
• filenames

That's why it was necessary to use the array feature of quickbms for reading each part and then extracting the files one by one.
There is no decompressed size specified so I had to use zlib_noerror which is just like comtype zlib with the difference that doesn't need a valid decompressed size field.

[evlgsr]

great work as usual

now i just need to figure out what type of files its extracted.

[evlgsr]

me again i have picked this little project to learn some more

since the last post i can see that the pack files are nothing more than containers for zlib files inside of them one per level (still trying to figure out what format the uncompressed file is)

my attention has now turned to the TGI file that is there with every stage\theme which is attached. i can see there are 4 instances that look like zlib headers as well however cannot find a way to extract them, i also tried to see if i could find a table or see if this file is an archive or raw data but could not figure out.

have also attached the exe file

sorry had to rename the files to .txt to attach them

[evlgsr]

some playing around today using the debugger i found out that the .PAK files once uncompressed show the information about the level for example what items are laid out and where they are which makes me think the 3d models for the level are actually in the TGI file.

[evlgsr]

A bit more debugging and i have come up with the following explanation about the file formats used in this game

.TGI file holds the textures for that level including the skybox image
.PAK file holds level layout data example where item pickups are located and what they are including obstacles
.GGI this file definitely has 3d geometry data as i can manipulate the main character which is a ball by changing values of this file in the emulator, as there are many worlds that exist in the game this file holds the not only the 3d geometry for each ball but also its textures, UV layout etc. only problem is i cant figure out what format this file is in as it does not have any clues that i can see. PSXPREV which is a ps1 model,texture etc ripper was unable to find anything in this file and also the values i changed in the debugger did not make sense. starting from offset 0x10A0 is the geometry data for the ball in the first world, right above that is the what appears to be either the texture or the UV layout.

also when i ran signsearch on the file it tells me the following

offset num description [bits.endian.size]
--------------------------------------------
0003c8ee 1038 padding used in hashing algorithms (0x80 0 ... 0) [..64]

- 1 signatures found in the file in 1 seconds
- done

i have uploaded the GGI file if anyone else wants to have a go at figuring it out.

[evlgsr]

Getting closer and closer

i now know that geometry data vertex index is for the 1st level ball is 0000107C - 0000130C in the GGI file as if i edit the values in the debugger the ball becomes mangled, however i cannot for the life of me figure out how to get it into readable format.

i have also found that there is a table in the GGI file that starts at offset 0000004C and is E10 bytes in Length, all the offsets in the table point to what appears to be different files, there are 51 entries in the table, i still have not been able to locate the size table as well as the name tables yet. There are other files beyond the last entry of the table so there must be another table somewhere else.

here is what i believe to be geometry data for the ball in the first level from the GGI file

Code: Select all

260000001B001B0064005C005C00000000002600E5FF1B00DAFF00005C005C005C000000E5
FFE5FF0000DAFF1B00E5FF5C005C005C1111111100E5FF4711111111001B00470047004700000032
0032001B001111111147004700470047000000E5FF4100CEFF3200BFFF1B004700470047000000B9
FF0000BFFFE5FFCEFFCEFF4700470047000000E5FFBFFF0000B9FF1B00BFFF4700470047000000320
0CEFF5500DDFF5C0000004700260026000000550023004100410023005500260026002600000000
005C00DDFF5500BFFF41002600260026000000ABFF2300A4FF0000ABFFDDFF2600260026000000B
FFFBFFFDDFFABFF0000A4FF26002600260000002300ABFF4100BFFF5C00DAFF26002600000000006
40000005C00260047004700000000000000000026005C0000006400DAFF5C000000000000000000
B9FF4700A4FF26009CFF00000000000000000000A4FFDAFFB9FFB9FFDAFFA4FF0000000000000000
00009CFF2600A4FF4700B9FF00000000000000005500DDFF5C00000055002300DAFFDAFFDAFF000
0410041002300550000005C00DAFFDAFFDAFF0000DDFF5500BFFF4100ABFF2300DAFFDAFFDAFF00
00A4FF0000ABFFDDFFBFFFBFFFDAFFDAFFDAFF0000DDFFABFF0000A4FF2300ABFFDAFFDAFFDAFF0
0004100BFFF4100E5FF47000000DAFFB9FFB9FF000041001B00320032001B004100B9FFB9FFB9FF0
00000004700E5FF4100CEFF3200B9FFB9FFB9FF0000BFFF1B00B9FF0000BFFFE5FFB9FFB9FFB9FF00
00CEFFCEFFE5FFBFFF0000B9FFB9FFB9FFB9FF00001B00BFFF3200CEFF26000000B9FFB9FFA4FF00
001B001B0000002600E5FF1B00A4FFA4FFA4FF0000DAFF0000E5FFE5FF0000DAFFA4FFA4FFA4FF000
01B00E5FF000000001A004E00A4FF9CFFC6FF0000

[evlgsr]

Sorry to be spamming this post but hopefully someone can answer this question.

What does it mean when in the hex editor data visualiser for the file i believe has model data in it you see what appears to be hex lines that make up images which look like textures as per attached image. Does this mean that the texture files are uncompressed raw data or can they still be compressed?

[evlgsr]

The archive is splitted in the following parts:

• number of files
• offset + compressed size of each file
• offset of each filename
• filenames

That's why it was necessary to use the array feature of quickbms for reading each part and then extracting the files one by one.
There is no decompressed size specified so I had to use zlib_noerror which is just like comtype zlib with the difference that doesn't need a valid decompressed size field.

Hi

can you please take a look at the .GGI file i attached as that is where all geometry sit, it doesnt look like compression to me but i could be wrong and wanted to check in with you.

Thank you in advance