07-27-2014, 09:19 AM (This post was last modified: 07-30-2014, 10:41 PM by Carpaccio.)
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.
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.
Doofenshmirtz: This is a little bit awkward but have you seen my escape jet keys? (Perry nods) What, you have? Well that's great! So where are they? (Perry looks away) You won't tell me? Is this because you don't speak or are you just being a jerk? ~Phineas and Ferb, "One Good Scare Ought to Do It!" (2008)
07-27-2014, 02:15 PM (This post was last modified: 07-27-2014, 02:56 PM by Raccoon Sam.)
(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.
07-27-2014, 09:46 PM (This post was last modified: 07-27-2014, 11:02 PM by puggsoy.)
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).
You may have a fresh start any moment you choose, for this thing that we call "failure" is not the falling down, but the staying down. -Mary Pickford
# South Park: Tenorman's Revenge archive format
# This simply extracts the raw files, it doesn't decompress or decypt anything (yet)
# Only tested with characters.bundle and data_uncompressed.arc
#
# Written by puggsoy
# script for QuickBMS http://quickbms.aluigi.org
get BASE_OFF long
get FILESEND long
math BASE_OFF += 8
math FILESEND += 8
savepos POS
do
getct NAME string 0x00
strlen NAMESZ NAME
math POS + NAMESZ
math POS + 1
goto POS
get OFFSET long
get SIZE long
math OFFSET += BASE_OFF
log NAME OFFSET SIZE
savepos POS
while POS < FILESEND
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.
You may have a fresh start any moment you choose, for this thing that we call "failure" is not the falling down, but the staying down. -Mary Pickford
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.
You may have a fresh start any moment you choose, for this thing that we call "failure" is not the falling down, but the staying down. -Mary Pickford
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?
