== Blood .RFF ==

Game resources (such as sounds, maps, scripts and voxel models) are contained within RFF files. File structure for version 2.0, 3.0, and 3.1 is identical: it starts with a small 16-byte header, and then a directory of (48 * dirLength) bytes located at dirOffset, and finally multiple chunks of information. However, while data and the file directory in version 2.0 are clear, version 3.0 introduces an encryption system to prevent extraction of resources. The algorithm employed is identical in version 3.0 and 3.1, but the key used to encrypt the file directory is different. The encryption algorithm is "chr[i] ^= (unsigned char)((encryptionKey + i) \ 2)" (or "chr[i] = chr[i] XOR (((encryptionKey + i) \ 2) AND &hFF)"). In version 3.0 and 3.1, the file directory MUST be deciphered as one long chunk of data. To decipher the directory in version 3.0, use encryptionKey = rffDirOffset. In version 3.1, encryptionKey = (rffDirOffset * 2). If, for any specific file, the encryption flag is set (0x10), the first 256 bytes of information must be decyphered with encryptionKey = 0x00 (this flag only exists in version 3.0 and 3.1)

header_t (16 bytes)
  CHAR[4]   Signature     ("RFF" + 0x1A)
  UINT16    Version       MUST be 0x0200 (2.0), 0x0300 (3.0) or 0x0301 (3.1)
  UINT16    Filler        Usage unknown, likely a filler
  UINT32    dirOffset     Offset of directory
  UINT32    dirLength     How many entries in the directory

dir_t (48 bytes)
  CHAR[16]  filler        ??
  UINT32    chunkOffset   Offset of the first byte of information from this chunk
  UINT32    chunkLength   Length of this chunk, in bytes
  UINT64    fileTime      Date and time
  UINT8     fileFlag      Special storage flags
  CHAR[3]   fileExt       File extension
  CHAR[8]   fileName      File name
  UINT32    fileIndex     Entry number

fileFlag:
  0x01  - Do not allow BARF.EXE to extract
  0x02  - ?
  0x04  - ?
  0x08  - ?
  0x10  - Is encrypted
  0x20  - ?
  0x40  - ?
  0x80  - ?