Well...I tried to get help elsewhere and got yelled at...so I have no other choice but to ask here. Can someone figure out how to unpack the two types of archives here.

File 1
File 2

If this can't be done HERE I'm completely out of luck. It looks relatively simple in hex but like I've said before I know nothing of decompression and scripting. Can someone please help out?

Also if posting game files is for some reason against the rules here, then I'm sorry. Just delete this post and I'll know not to from now on. Though that notion is a bit of a paradox based on the nature of our entire operation...but what the copyright Fascists say, goes, I suppose.

The BUNDLE file – no idea. There's some xml in the end of the file and a file listing for DDS files (among others) in the beginning.
I couldn't find any DDS headers though, so they're either compressed or encrypted or something i dunno

The ARC file contains a file listing in the beginning, and later in the file I spotted ZIP headers and some uncompressed model data (I think it was model data, there was a big array of coordinates) and PNGs I think.

I'll edit this post later sorry

What game is this for exactly?

(07-27-2014, 01:45 PM)Deathbringer Wrote: What game is this for exactly?

The South Park game, Stick of Truth(?)


EDIT EDIT:

Well uh, the first bytes in the ARC are 40 5C 06 00 40 5C 06 00 in hex, then in ascii algae.dds.
Take the first four bytes, 40 5C 06 00, read it backwards and get 00 06 5C 40. Guess what's in offset 0x65C40?
Well, data. The file listing ends in 0x65C3F, one byte before the messed up mix of mysteries start. And after that it's just like, well:
73 2A 5C 0D E3 3E 00 00 00 00 00 00 00 00 AB CD FF FF FF FF 46 AF 00 81 8C 42 06 91 00 1F E0.
Doesn't look like anything, and though all of my intuition says that this should be the algae.dds file, it's most certainly not. It doesn't have a DDS header and the data looks, well, encrypted or some shit. I dunno I'm sorry

Actually, it's for South Park: Tenorman's Revenge. Sorry I forgot to mention that. It's entirely 2-D which means I believe the only thing needed is to correctly extract the aforementioned DDS files to obtain the graphics. I appreciate the responses, by the way.

These files are weird! Both of them seem to be in a similar format, since something similar to what Sam described is happening in characters.bundle. Before each file there are two long integers (4 bytes each) which one would intuitively assume are their offsets and sizes. However for the first file, both values are the same, simply the offset at which the filenames end. The second has the first value as 0 and the second at some other offset. The third has a first value equal to the second value for the second file (hope I'm not making this confusing). From there the values don't seem to have any pattern.

The weird thing is that this is happening in both of the files. If it were only one, I could conclude that it's just some coincidence, but these patterns must have some weird meaning if it's in both.

The only thing I'm currently sure of is that the file names are null-terminated strings (they end with a null byte). I'll try look into this more and see if I can find anything.

By the way, if you have any more files to show that might help. Comparing files allows me to find similarities and differences, which helps with finding out what means what.

EDIT: Hasn't been long but I've made some progress.

The first two longs are the length of the file list (in bytes, not files) and the offset of the data starting from the begin of the file list. I'm not sure which is which, since in these two files they're identical (because the data starts directly after the file list).

After this is the file list. Each file has 3 bits of info: name, offset, and size. The name is, as I said, a null-terminated string. The offset is the offset relative to the data offset specified earlier. This is why one of the files has 0, that just means it's at the beginning of the data. The size is simple, that's just how long the file is, in bytes.

I verified this by manually extracting an XML file, and it turned out great. The issue now is decrypting the DDS files (since these seem to be the ones we want to get our hands on). As Sam said they don't seem to have headers, so in that case I can think of two possibilities, either that A) they are encrypted or compressed somehow, or B) the data their is simply the image data without the header. I think that A is much more likely than B though.

I'll write a QuickBMS script soon that will extract the files as they are. That will make it easier to look at the DDS files since they'll be separated. It'll also give directory structure and let us see what other files are in there (some, like XML, might be uncompressed).

Wow, that's a lot of development in such little time! I'm kind of amazed! Thank you so much for taking a look at these. I appreciate it greatly.

Great job Puggsoy! Can you upload a few of manually-extracted mystery-DDSes? I wanna look too

You can extract them yourself with this:


That's the QuickBMS script to extract all the files. Works with both files, characters.bundle is real small and takes 2 seconds, the other is bigger and might take a minute or two. As far as I can tell the only files that don't need to be decrypted/decompressed are XML files.

See if you can make heads or tails of the DDS files. The KRKB files might also be something useful, although I expect it's animation data or the like. I'll take a look myself later tonight or tomorrow.

Well I'm a macfag so I can't use quickbms BUT i'll try the with WINE.

edit: yeah doesn't work :c

Ah OK then. In that case I've attached 2 zips containing a couple from characters.bundle. If you want specific ones feel free to ask.

Thanks
also
wow
I've got nothing. The files begin the same and end (almost) the same, but everything that's in between... sfdg i have no idea

They must be compressed, that's all I can come up with.

Mm yeah, looks like it. 7zip almost extracted what appeared to be a LZMA:16 compressed file from cartman_atlas_0.dds, but it doesn't quite manage it and ends up with a 0 bytes file. No other files do this though so I'm not sure if it's a hint or a false alarm.

I'm quite useless with compression but it feels like a waste to come this far and give up, so I'll keep trying things.

Criminy this just gets weirder...the 'gpchr' files have more references and such when everything is extracted. I couldn't figure out the DDS files though...

The developer of the game is Other Ocean Interactive. Maybe digging into their previous titles might give some insight on their formats and methods of using resources?