XeNTaX Forum Index
Forum MultiEx Commander Tools Tools Home
It is currently Wed Aug 23, 2017 8:32 pm

All times are UTC + 1 hour

Forum rules

Please click here to view the forum rules

Post new topic Reply to topic  [ 2 posts ] 
Author Message
 Post subject: Davidson & Associates .res files
PostPosted: Mon Aug 07, 2017 12:53 am 

Joined: Thu Feb 16, 2017 3:51 pm
Posts: 8
Has thanked: 0 time
Have thanks: 0 time

I'm at it again: I'm looking at files from old educational computer games I played as a kid. Files that end in .res can be found with several games by Davidson & Associates, but here I will be looking at one file from Math Blaster Episode 2: Secret of the Lost City, Version 1.2 C, as well as a file from Davidson's Learning Center Series: 3rd Grade (also known as Learning Voyage: Sand Trapped!). There's a reason I'm looking at two .res files, which I will get to. Feel free to follow along at home. A ZIP file containing both files can be downloaded from my Dropbox here: https://www.dropbox.com/s/p872xcdsf38gx ... s.zip?dl=0

So, here's the structure for the Math Blaster Episode 2 file (E2CD.RES):

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

There are a few oddities with this. For one thing, as mentioned, both tails are exactly the same; why they bothered putting it in there twice is beyond me. Second, the offsets are not in order, so in this case, the first file (at offset 0x44) is actually listed much later on down the list. Third, and most unfortunately for me, there are no file names. An accompanying file, E2CD.BAP, seems to contain file directory names, but not the names of the files themselves. I'll take a look at a later release also, to see if its .res file might be structured differently.

Now for the Learning Voyage file (LVG3.RES):

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

Whew! Now, that is what I call a complex archive! Hence why I probably won't write a MultiEx script for these types of files; there's too much jumping back and forth from offset to offset. Why did they do that, rather than just put everything in the header, or in the tail?

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.


You can make the ads go away by registering

 Post subject: Re: Davidson & Associates .res files
PostPosted: Tue Aug 08, 2017 9:59 pm 

Joined: Sat Apr 16, 2016 3:15 am
Posts: 24
Has thanked: 3 times
Have thanks: 9 times
It's a shame version two of the *.res files don't hold any filenames :/. (If there's another file it's supposed to match up to, just post it here and I'll add in support for those in version 2). For version 3, you were right about the "unknown" value being the file's date and time (given the game seems to be released around '98 and that is when the files were created). I wrote a QuickBMS implementation for both of the versions you've supplied as samples. If you happen to find anymore versions, post them here and I'll take a look (even much better if you would like to identify the structure beforehand :P). Anyways, here's the QuickBMS script for RES version's 2 + 3:

# Davidson & Associates *.RES
# Writen By Anex For QuickBMS

get VER long

if VER == 0x2
   get PADDING longlong
   get TB1OFF long
   get TB1SIZE long
   get TB2OFF long
   get TB2SIZE long
   goto TB1OFF
   get PADDING longlong
   xmath FCOUNT "(TB1SIZE - 0x8) / 0x8"
   callfunction VER2EXTRACT
   goto TB2OFF
   get PADDING longlong
   xmath FCOUNT "(TB1SIZE - 0x8) / 0x8"
   callfunction VER2EXTRACT
elif VER == 0x3
   callfunction SKIP
   get FTBA long
   get FTBASZ long
   callfunction SKIP
   get FTBB long
   get FTBSZ long
   goto FTBB
   get FNAMETB long
   get FNAMETBSZ long
   goto FTBA
   get PADDING longlong
   savepos OFFTABLE
   xmath FCOUNT "(FTBASZ - 0x8) / 0x8"
   for i = 0 < FCOUNT
      get OFFSET long
      get SIZE long
      savepos OFFTABLE
      goto FNAMETB
      get FNUM long
      get NULLSZ long //Sizes also stored here, but not accurate
      get FILEDATE long
      get FILEID long
      get FNSZ long
      getdstring NAME FNSZ
      savepos FNAMETB
      goto OFFTABLE
   next i

startfunction VER2EXTRACT
   for i = 0 < FCOUNT
      get OFFSET long
      get SIZE long
      log "" OFFSET SIZE
   next i

startfunction SKIP
      get ADVANCE byte
   while ADVANCE == 0x0
   savepos CUR_OFF
   math CUR_OFF - 0x1
   goto CUR_OFF

I'm interested in these formats too (hopefully there's more RES versions :P).

Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 2 posts ] 

All times are UTC + 1 hour

Who is online

Users browsing this forum: aspadm, Yahoo [Bot] and 6 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group