Need help with binary file analysis

Question

So I'm currently trying to analyze a resource archive file of an old game.

What I got so far

• The file is supposed to represent a "virtual drive", the format is called VDRV. This means there are paths listed with offsets and sizes.
• Header structure is 64 bytes for the game identification (magic number + a whole lot of 0x00), then a uint32 for total file size, then a uint32 for the offset where the first block of data ends
• Data follows, the first block takes up more than 90% of archive size. This is where the resources have to be located. This seems to be ciphered/encrypted.
• What is left is what I call the "Resource Table" - a chain of either 64 or 120 bytes long blocks until the end of file. I believe this is where the paths are registered

So far, so good. However, this is where it get's tricky. The first twelve bytes of each of those blocks are readable, they are always three uint32.

1. Length of the block including this int (either 64 or 120)
2. Some offset, this seems to link the blocks in a LinkedList style (actually proved that using a small program I wrote).
3. Offset of the last 4 bytes of this block.

And this is where I'm currently stuck, since the rest seems to be encrypted/ciphered data. I dumped the data from the 64 and 120 long blocks seperately, without those twelve "header" bytes. Each block is seperated by line break.

• Long Blocks
• Small Blocks

Now there are obviously some repeated patterns here, so I'm thinking that it might be some XOR-ish cipher, though I haven't been able to figure out a key or even a structure.

What I expect to find in this data

• Two uint32, offset and size
• A string path
• Unused space filled with 0x00

Also, I know that these (partial) strings should be in there somewhere in some way or another (got those from the executable):

data
../../../data/g
g/img/inv_Lf._img
g/img/inv_Rt._img
g/img/inv_All._img
g/img/mcUse._img
g/img/mcTalk._img
g/img/mcTake._img
g/img/mcLook._img
g/img/mcArrow._img
g/img/fntOtherSpeakers._img
g/img/fntBig._img
g/img/fntWhite._img
g/img/fntYellow._img
g/img/fntGray._img

That is all I have been able to figure out up to now. Any help in figuring this out would be much appreciated!

Thank you for your time!

EDIT: Posted the binary in the comments

Answer 1

The binary seems to be composed of blocks of zlib compressed data.

$ binwalk -B vdrv.dat 

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
76            0x4C            Zlib compressed data, best compression
410855        0x644E7         Zlib compressed data, best compression
411415        0x64717         Zlib compressed data, best compression
411833        0x648B9         Zlib compressed data, best compression
739843        0xB4A03         Zlib compressed data, best compression
740261        0xB4BA5         Zlib compressed data, best compression
943653        0xE6625         Zlib compressed data, best compression
944071        0xE67C7         Zlib compressed data, best compression
1342964       0x147DF4        Zlib compressed data, best compression
1343382       0x147F96        Zlib compressed data, best compression
1715439       0x1A2CEF        Zlib compressed data, best compression
1715857       0x1A2E91        Zlib compressed data, best compression
<-snip->

binwalk treats the following bytes as zlib signatures:

#0    beshort        0x7801        Zlib header, no compression
0    beshort        0x789c        Zlib compressed data, default compression
0    beshort        0x78da        Zlib compressed data, best compression
0    beshort        0x785e        Zlib compressed data, compressed

Entropy plot:

When the compressed data at offset 4C is decompressed, the result is a binary blob with some image signatures and string data:

 $ binwalk 4C

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
89            0x59            JPEG image data, JFIF standard 1.02
119           0x77            TIFF image data, big-endian, offset of first image directory: 8
413           0x19D           JPEG image data, JFIF standard 1.02
6169          0x1819          Copyright string: "Copyright Flag"
6800          0x1A90          JPEG image data, JFIF standard 1.02

Adobe Photoshop 7.0
2004:10:25 15:02:26
Adobe_CM
4Photoshop 3.0
Resolution
FX Global Lighting Angle
FX Global Altitude
Print Flags
Copyright Flag
Japanese Print Flags
Color Halftone Settings
Color Transfer Settings
URL overrides
ICC Untagged Flag
Layer ID Generator Base
New Windows Thumbnail
Version compatibility info
JPEG Quality
@3$%&C49
#L#|AJ74N
M>5..=l5
/;t>q~{z
6.r%G60L
<-snip->

The presence of readable ASCII strings seems to confirm that the data is compressed and was successfully decompressed. With that being said, binwalk detects roughly 1900 zlib compressed data blocks, with some false positives detected throughout the file. In addition, not all of the compressed blocks may be detected; when I used wxHexEditor to search for byte 0x78DA, more than 3000 matches were found. Either that or binwalk augments its signature scan with additional information or heuristics that I am not aware of to reduce false positives.

The search results differ from the output of the signature scan.