Some compressed data from GameCube game

[Maxwell]

I've stumbled upon archive from racing game (Street Racing Syndicate that runs on Eutechnyx engine) for GameCube.
Basically the entire archive contents are compressed as a single chunk of data.
I wasn't able to detect algo, but it looks like some form of LZ.
Maybe someone seen something similar or same?

Thanks.

Fields:
0x78 Compressed size
0x7C Uncompressed size
0x80 Data start

 

To admins: If you have problems with samples, please let me know what is ok.

archive.zip

Edited October 31, 2023 by Maxwell

[wssdude]

Specifying what game it is would be more helpful to others than just "some gamecube game".

Gamecube version is a good information, consoles tend to have a bit different formats, but without the game name which could provide some more information about engine etc. is not that helpful for anyone interested to help you.

[Maxwell]

I've edited my initial post.

I don't expect it's an engine, but rather platform thing, compression algo used from GC SDK perhaps?

All other platforms (PS2 and Win) are using regular zlib.

[wssdude]

Sure, it may be archived by some platform-specific format as mentioned (hence it is good you mentioned it comes from Gamecube), but data internally may not differ much from PC version for example. More of what I meant 😛

Older Hitman games have quite similar formats for example between consoles, am pretty sure RenderWare games also have similar formats. Main distinction tends to be compression algorithm used in most cases, but internal data structures after decompression tend to be the same.

Could still be this is really just some game-specific format and compression not using platform compression. 

[wssdude]

See? Found something interesting right away I suppose 😜

I have a PC version on Steam, tried to download it... Apparently, PC version has one giant archive.ar (it has over a gigabyte and probably contains all the data so obviously won't upload it I suppose... could share some chunk of it if someone wants it).

Beginning of headers looks similar at least, although it has different extension.


Yours seems to have similar starting bytes somewhat.


Could help someone I suppose figure out the start of the data at least.

[wssdude]

Found this QuickBMS script for Hot Wheels: Beat That!, is from same developer and has same magic bytes at the beginning.

It is for Wii version, maybe it is somewhat usable (had not tested it honestly)

hot_wheels_arcn.zip

[wssdude]

Ok, I just tested the script (had a bit of trouble running QuickBMS, had not used it for a bit..)

It doesn't work... 

How sure are you 0x78 is compressed size btw? Because I dont think that is the case, or the file has some odd footer at least then...

0x33F2 (which is in sample u32 from offset 0x78 + 0x10 which seems a bit suspicious) is a plain text. Would not expect that from something that should be in compressed block 🤔

It sounds more like an offset to footer tbh...

[Maxwell]

I am sending header structure

struct Header {
    u32 id;
    u32 numEntries;
    u16 numTextures;
    u16 numModels;
    u16 numAttachments;
    u16 numAttachedModels;
    u16 numSkeletons;
    u16 numCameras;
    u16 unk1;
    u16 numRigNodes;
    u16 numMaterials;
    u16 numMeshes;
    u16 unk2;
    u16 numReferencedTextures;
    u16 unk22[4];
    u16 numIndexBuffers;
    u16 numVertexBuffers;
    u16 unk20[2];
    u16 numSkinnedMeshes;
    u16 numDeformedMeshes;
    u16 numAnimations;
    u16 unk3;
    u16 numAnimatedNodes;
    u16 unk4;
    u16 numUnkNodes;
    padding[58];
    u32 compressedSize;
    u32 uncompressedSize;
};

 

Hopefully this will clear things up.

 

1 hour ago, wssdude said:

Apparently, PC version has one giant archive.ar (it has over a gigabyte and probably contains all the data so obviously won't upload it I suppose... could share some chunk of it if someone wants it).

Oh, yeah, I forgot about that, I was looking at it like a year ago. All platforms are using those big ar archives. Those acts like regular generic game archive. I had fully researched those.

Arc acts like a package, holding various data structures. And after looking on my old research, it looks like only GC version is using compression, so there is a possibility the compression is not GC related. I guess I assumed it's platform compression, due to being the only one using it.

[wssdude]

Is the file using mix of big endian and little endian? Interesting format lol...

Tried to match your header somewhat, but it looks like (if all what you found is correct) that they encode one thing with big endian (like the number of things) and then use little endian later for sizes?

Also, if I understood correctly, comparing header and information in the sample, there should be like 42 entries of something and 6 textures?

At least judging by the strings I can see in the footer (and I tried to find some others in the middle unsuccessfully), I have a feeling something doesn't add up for whatever reason 😕

[DKDave]

The compressed data does indeed start at offset 0x80.  It uses lzo1x compression, and you get a decompressed file of 25991 (0x6587) bytes.  Taking into account the compressed size, there are also an extra 0x1e bytes at the end of the file for some reason.

I'm not sure if other files have multiple compressed blocks, but this just has 1.

 

Edited October 31, 2023 by DKDave

[Maxwell]

9 hours ago, DKDave said:

It uses lzo1x compression

Thank you, this is exactly what I was looking for

 

9 hours ago, DKDave said:

there are also an extra 0x1e bytes at the end of the file for some reason.

Yes, those can have variable length, data seem same across arcs. Possibly dictionary for lzo?

 

10 hours ago, wssdude said:

Is the file using mix of big endian and little endian?

It uses big endian as a whole, but for some reason only those two u32 (and possibly footer) are in little. My guess is that they use little endian decompressor abi.