Print

[johneboy81]

Can anyone point me in the right direction on how i would go about extracting the contents of a GOB file? It's for Crash Nitro Kart, and the files are:
ASSETS.GFC
ASSETS.GOB


I know the GOB file is an archive, and the GFC file specifies where in the archive the specific files are, but i haven't the slightest idea how i would begin to extra files to view

Any help is greatly appreciated

[grimdoomer]

The files are in big endian. I have gotten as far as extracting files from doom 3. Heres what you need to know:

CODE

public struct File
{
    int Offset, Size, Flags;
    string Name;
    long Unknown; //Probally hash
}

GFC
0 - Magic - Int32
4 - GOBFileSize - Int32
8 - IndexCount - Int32
12 - FileCount - Int32

After you read the Header Values, loop for IndexCount, reading the Offset, Size, and Flags of a Filestruct. There are two tables after the Index, some random table, and some table that has to do with the Files or Names some how. The olnly way to get to the Name Table is to manully put in its offset. I might be able to figure out how to calculate the size of the 2 unknown tables later. But once you get to the Name Table, loop for FileCount, you read the name which is 256 letters, and the Hash which I don't know what or how it hashes, which is 8 bytes.

GOB
The GOB file is a just a collection of files, some being compressed, some not, padded to 2048 bytes. Each File has a StartBlock (STBL) and EndBlock(ENBL), if the next byte is 122, the the file is compressed with zlib. If not, then its completly uncompressed.

Thats all you really need to know. I don't know if you can modify the files without knowing the hash but it still gives you a point to start at.

[johneboy81]

well, it's quite apparent you know quite a bit more then i do in regards to any of this.. (and that's an understatement)

i've checked the GOB file, and found that there are many data "gobs" surrounded by STBL (53 54 42 4C) and ENBL (45 4E 42 4C) with varying 00's between them.

I (novicely) thought that the content between these offset would be the file.. but there doesn't appear to be any way (that i know of) to determine what filetype it is..

At this point, i'm not concerned with modifying the contents.. just extracting..

Here is the contents of the first "GOB"...

CODE

STBLzxœ­.KoÂ0.„ï•ú.VÉ5ª.”¾¤..¸.R.h0}œ..Kc)qPìôñïq.† 8Ö'{ö[Ïhºž.BjüÂÒÜ^D†ð†¥.…ôöçúªß9.Bþ.²Ê.,¡XƒÐ˜«#럠#\ó*ÓÀ—Z|ãŽ=¢®çýãÃq.ñÄÄw}.….9Ϛl PƒN¹.•.U¶‚.a“ñ%®LPÐ. Üí9Žâ&#/ÍÛq ØhSB.lx¥.r”Õ.stta.N'1#.{.–.ÕúÞìù..BYü˜”ðZq©…þ«wÚm™Ôu³><ØÑpñ>.§d1Œ.£-¤g.î.¡d:‰Î˜ºõže>ÎƵ˭.³ˆ].ú.ˆÆ,ž\´¸³È0þœ1.4ê½Uc:Z.Ȍ6òƒ•.Áœ¶ôǃ..³˜.ûÑ®‰Ž..h@™Q·7±¨SENBL

or....

CODE

53 54 42 4C 7A 78 9C AD 90 4B 6F C2 30 10 84 EF 95 FA 1F 56 C9 35 AA 08 94 BE A4 1E 0C B8 12 52 12 68 30 7D 9C 90 03 4B 63 29 71 50 EC F4 F1 EF 71 08 86 20 38 D6 27 7B F6 5B CF 68 BA 9E 0B 42 6A FC C2 D2 DC 5E 44 86 F0 86 A5 12 85 F4 F6 E7 FA AA DF 39 81 42 FE 0B B2 CA 13 2C A1 58 83 D0 98 AB 23 EB 9F A0 23 5C F3 2A D3 C0 97 5A 7C E3 8E 3D A2 AE E7 FD E3 C3 71 81 F1 C4 C4 77 7D 08 85 14 39 CF 9A 6C A0 50 83 4E B9 06 95 16 55 B6 82 04 61 93 F1 25 AE 4C 50 D0 05 A0 DC ED 39 8E E2 26 23 2F CD DB 71 A0 D8 68 53 42 8D 6C 78 A5 10 72 94 D5 8D 73 74 74 61 1C 4E 27 31 23 11 7B 02 96 0A D5 FA DE EC F9 1D 9D 42 59 FC 98 94 F0 5A 71 A9 85 FE AB 77 DA 6D 99 D4 75 B3 3E 3C C3 98 D1 70 F1 3E 0F A7 64 31 8C 09 A3 2D A4 67 90 EE 01 A1 64 3A 89 CE 98 BA F5 9E 65 3E CE C6 B5 CB AD 1D B3 88 5D 04 FA 16 88 C6 2C 9E 5C B4 B8 B3 C8 30 FE 9C 31 12 34 EA BD 55 63 3A 5A 0C C8 8C 36 F2 83 95 07 C1 9C B6 F4 C7 83 0F 9D B3 98 04 FB D1 AE 89 8E 9D 8D 68 40 99 51 B7 37 B1 A8 53 45 4E 42 4C

is there anyway you know of to determine this filetype? or would MUST i use to the GFC file to know?

[johneboy81]

well, thanks to the info by grimdoomer, i think i've got this...


here's what i'm doing...

open ASSETS.GOB in hexeditor..

copy contents BETWEEN STBL to ENBL
i see that all have z after STBL, which is 7A (122)
i now know that 122/7A = zLib compression...


i take the contents of the above, and run it through a zlib decompression loop in a vb app i through together..
since i dont know the output file size, i loop from 1 to whatever until no error is returned...

so far its worked on 2 of the CSV files, and another "LightFactory" file..

i should be able to now right an app that will loop through the GOB file, extract all between STBL/ENBL, and then run the zLib decompression loop!!


thank you SO much!

[johneboy81]

update

so i've written an app that will read through the GOB file, and extract the contents between STBL/ENBL and append the extension of zlib to those compressed, and .dat to those not.

I've had no issues with the csv files, but have found that it appears most of these code chunks are 65k pieces.
i found 1 file that had PNG headers, but would only display the top 25% of the image.. appended the code from the next 5 code chunks to this file (all but the last being 65k uncompressed) , and the whole image showed up.

still haven't figured out how to extract WAV files that I know are in there.. i think the next step will be to write a batch script that will uncompress all extracted .zlib files, and then search through the contents for WAVE or RIFF which i believe indicate a wav file.

[grimdoomer]

I've written an app a long time ago to extract all the files properly. But since I could not figure out what those 2 tables where, I never tried to inject any files, and it's stopping my from making a PC to Xbox Map converter. One should br CRCs, meh I'll take another look this week.

[johneboy81]

well, i got all my files out.. now i'm trying to figure out how to modify them, and put them back in.

so far, changing on the CSV files (changing a value of 0 to 1) causes the game to stop working..

you think there is some CRC checks on the files?

the MD5SUM for the original assets.gob file
592cca47c0713446642b79a925ba515e

the MD5SUM of the new, updated assets.gob file
592cca47c0713446642b79a925ba515e

BUT...
the old zlib compressed CSV file:
7c347d99efe6d2b1f671a05795433827
the new zlib compressed CSV file:
75aaa12eecdf4583888e167592340487

I'm not sure why the hash would match on the entire file, but not the file i'm injecting..

also, i searched through the assets.cfg file to see if 7C 34 7d existed (in hopes the checksum was there for me to "fix"), but it was not.

[grimdoomer]

QUOTE(johneboy81 @ Apr 10 2009, 02:27 PM)

well, i got all my files out.. now i'm trying to figure out how to modify them, and put them back in.

so far, changing on the CSV files (changing a value of 0 to 1) causes the game to stop working..

you think there is some CRC checks on the files?

the MD5SUM for the original assets.gob file
592cca47c0713446642b79a925ba515e

the MD5SUM of the new, updated assets.gob file
592cca47c0713446642b79a925ba515e

BUT...
the old zlib compressed CSV file:
7c347d99efe6d2b1f671a05795433827
the new zlib compressed CSV file:
75aaa12eecdf4583888e167592340487

I'm not sure why the hash would match on the entire file, but not the file i'm injecting..

also, i searched through the assets.cfg file to see if 7C 34 7d existed (in hopes the checksum was there for me to "fix"), but it was not.

You did't modify the gob file, you modified the gfc files. Also yes there is a checksum somewhere, probally CRC not sure.