Ravenloft: Strahd's Possession

[Aka Guymelef]

Hello,

I'd like to extract the assets of the RPG game Ravenloft: Strahd's Possession (DOS, 1994, DreamForge Intertainment). I'm mainly interested in the texts since I'd like to do a translation.

The game's data is divided in 9 files RES0~RES8 (no extension), I've attached the first three.

Thanks in advance for you help.

[aluigi]

It's a weird format mainly because it's a sequence of offsets that point to some "data" that starts with "EH", they don't seem compressed but probably they are images (my guess).
There are also some very few non-EH files like at the end of RES1.
In RES1 the first offset is 1 and not an offset (?), don't know why.

This script for quickbms can dump the data:
http://aluigi.org/bms/ravenloft_res.bms

[Aka Guymelef]

Hello,

Thanks again for helping with that riddle.

I noticed that I was always one file short (which happened to be the first) so I made a change in the script to work that out :

Code: Select all

# Ravenloft: Strahd's Possession

get FILES long
for i = 0 < FILES
    get OFFSET long
    putarray 0 i OFFSET
next i
savepos MIN_OFF
get OFFSET asize
putarray 0 i OFFSET
sortarray 0
for i = 0 < FILES
    getarray OFFSET 0 i
    math i + 1
    getarray SIZE   0 i
    math SIZE - OFFSET
    if OFFSET >= MIN_OFF
        log "" OFFSET SIZE
    endif
next

Regarding RES1, I checked my backup and the first offset had not the correct value indeed (I must have slipped-up). The last two files still don't have the "EH" marker that all the other share.

RES3 has the most offsets with very small sizes, maybe it's the texts I'm searching (or maybe it's all the low-res images) but nothing is in plain text.

RES5 is the most interesting because it is containing the music of the game which are stored in the XMI format. As I understand, the first XMI chunk always starts at offset 0x09 which would mean that each file has an 9 bytes headers before its actual content (which is an odd number) starting with the magic number 0x4548 (EH).

I'm not sure how to proceed to retrieve the actual content for all the RES files ?

[aluigi]

Good catch the >= MIN_OFF

[Aka Guymelef]

Not only that, I needed to move the savepos before the "get OFFSET asize" apparently.

[aluigi]

Uhmmm no, savepos is ok in both the ways since the last file operation was in the "for" cycle (get OFFSET asize isn't a file operation)

[Aka Guymelef]

Hello,

Uhmmm no, savepos is ok in both the ways since the last file operation was in the "for" cycle (get OFFSET asize isn't a file operation)

You're probably right. I discovered that the tool I was using to visualize the binary content of the files had some cache issue. So it's very probable that after changing the condition the first file was correctly extracted but the tool display the previous content leading me to believe I needed something else to work.

Anyways, I continued trying to decipher the format of the files contained in the archive. Knowing that RES5 stored its XMI files uncompressed, I deducted that the nine first bytes were some sort of header related to the archive (or the program) and after that was the file proper :

Offset | Value | Comment
0x00 | 0x45 | 'E'
0x01 | 0x48 | 'H'
0x02 | 0x03 | consistent
0x03 | 0x00 | consistent
0x04 | 0x00 | consistent
0x05 | 0xXX | file size
0x06 | 0xXX | file size
0x07 | 0x00 | consistent (file size ?)
0x08 | 0x00 | consistent (file size ?)

The bytes at 0x05-0x06 would give me a UInt16LE whose value is the file size minus 9. The file size might be actually a UInt32LE with the inclusion of bytes 0x07-0x08 but I've not yet seen a file size bigger than 65535.

I tested my assertion with RES6 which actually contains the voice files in format VOC (Creative Voice File) and it worked except for the byte at 0x02 whose value is consistently 0x04 (some sort of file type for the program maybe ?).

However that assertion does not work at all with the archive RES0. Byte 3-4 would either be 0x02 0x08 or 0x01 0x08 and the values at the "size" emplacement would not match at all.

RES1 did also not follow the pattern, its byte 3-4 being mostly 0x01 0x08. However in this file I discovered that the offset table pointed multiple file to the same offset and some of the file only had a 4-bytes length whose value was 0x60 0x00 0x00 0x00 which departed from the "EH" marker.

RES2 did also not follow the pattern, its byte 3-4 being 0x01 0x08.

RES3 did also not follow the pattern, its byte 3-4 being 0x07 0x00.

RES4 did also not follow the pattern, its byte 3-4 being 0x06 0x00.

RES7 did also not follow the pattern, its byte 3-4 being 0x01 0x08.

RES8 did also not follow the pattern, its byte 3-4 being 0x01 0x08.