the .toc
is a table of contents files that always starts with the header 1rrs.
It also contains directory and file paths at offsets that will relate to the data file.
Where should I start trying to use the .toc
to extract from the .data
file?
Reverse Engineering Stack Exchange is a question and answer site for researchers and developers who explore the principles of a system through analysis of its structure, function, and operation. It only takes a minute to sign up.
Sign up to join this communitythe .toc
is a table of contents files that always starts with the header 1rrs.
It also contains directory and file paths at offsets that will relate to the data file.
Where should I start trying to use the .toc
to extract from the .data
file?
Full Disclosure is always appreciated. This seems to be a ("the"?) data file for FASA Studio's "Shadowrun". Anyway, the data file contains enough recognizable items to get a good start (PNGs, Unicode text). Data seems to be aligned on 16 bytes, padded with what seems to be random trash.
PNG images are a good start; you can extract them 'manually' (I used 0xED) and see if they are well-formed. The few I tried were, and the all-but-one last data block should be a PNG image, according to the toc file. I located it at 0x82A72D0
, with a length of 0x2E231
bytes.
Then I checked the data around the last PNG file name in core.toc
for these bytes. Bingo - not a huge challenge.
The initial part of the toc file is unknown but may be a fast look-up table. I didn't cross-reference this any further with what follows. After that, the following data can be found per each file:
4 bytes length (little endian)
4 bytes offset
8 bytes unknown (perhaps checksum, perhaps file data/time, who knows?)
3 bytes name length -- possibly only the first 2 though, 3 bytes is rare #
x bytes name
Right after the block of file names more stuff appears, I couldn't think of a use for it. You could extract all file names, count them, and see if this is relevant. It seems it isn't as the file name block contains everything you were looking for.
# Ah-- for the first file, this name length
is 0x0E 0x00 0x01
. Seems the third byte indicates something else, then. I found 2 so far with a 0x01
, both are 'pathless' files.