So, here's the structure for the Math Blaster Episode 2 file (E2CD.RES):
Code: Select all
uint32 {4} - .res version? (2)
uint64 {8} - null padding (all 0)
uint32 {4} - tail 1 offset
uint32 {4} - tail 1 length
uint32 {4} - tail 2 offset
uint32 {4} - tail 2 length
byte {44} - null padding (all 0)
// all data, until tail 1 offset
// begin tail 1
uint64 {8} - null padding (all 0)
// for each file
uint32 {4} - file offset
uint32 {4} - file size
// tail 2 begins at tail 2 offset; exactly the same as tail 1
Now for the Learning Voyage file (LVG3.RES):
Code: Select all
uint32 {4} - .res version? (3)
byte {16} - null padding (all 0)
uint32 {4} - file info A offset
uint32 {4} - file info A length
byte {32} - null padding (all 0)
uint32 {4} - tail offset
uint32 {4} - tail length
// all data, until file info A offset
uint64 {8} - null padding (all 0)
// for each file
uint32 {4} - file offset
uint32 {4} - file size
// continues until file info B offset (defined in tail)
// for each file
uint32 {4} - file number
uint32 {4} - file size (+2 for RCB files)
uint32 {4} - unknown (see below for guess)
uint32 {4} - file type ID (0x2 for WAV files, 0x4 for BMP files, 0x7 for RCB files, 0xA for BAP files)
uint32 {4} - length of file name
char {length} - file name, complete with drive letter or "./"
// continues until tail offset
uint32 {4} - file info B offset
uint32 {4} - file info B length
// for each file
uint32 {4} - starting offset of detailed file info
uint32 {4} - length of detailed file info
But despite the complexities compared to what I call the "version 2" .res files, these "version 3" .res files actually have some major advantages, such as actually having the file names, as well as having the file offsets and sizes be in the actual order of the files. But then, why is it that the sizes are still reported twice, except for RCB files they're listed incorrectly the one time, and correctly the other? And what the heck is an RCB file, anyway? What is it there for? Also, what's with those file names? Why do they start with a drive letter or a "./"? (Yes, I do know that ./ means the root, but... of what, in this case?)
Now, onto the one "unknown" element in the detailed info/"Info B" section (I'm sorry, I really don't know what else to call it). It's clearly not an offset or a length. However, with Hex Workshop, I can actually highlight it and it gives me a value that seems to make sense: the "time_t" value seems to match up with when the files were actually created. I've highlighted those strange values at random points in each file, as well as for other files, and it seems to consistently match up. So, my theory is that these values are actually the dates when the individual files were created. Now that's great and all, but is there a way to make it so that, when I eventually make some way to extract it, I can have that be the date modified/created?
I'm sorry that this is such a long post, but I really wanted to let everyone know what I've figured out so far, and what I have yet to figure out. I'm just thankful that there's no compression or encoding that I have to deal with this time.
-Johnny
). Anyways, here's the QuickBMS script for RES version's 2 + 3:
. I don't think QuickBMS support Date and Time options sorry :/. If you find the version 4 file, post it here!