Index file start with a header of 0x80 bytes.  It has a few interesting things:

  0x00  uint32_le  last offset in file
  0x08  uint32_le  end of data
  0x0C  uint32_le  chunk size
  0x48  uint32_le  start of data

The file is split into chunks, with the header being in the beginning of the
first chunk.  Each data block has a header of 0x12 bytes.  Rest is index
records, 0x0C bytes each:

  0x00  uint32_le  byte offset in data file
  0x04  uint32_be  resource type
  0x08  uint32_be  resource ID

The order of index records does not seem to make much sense, but it may be some
sort of tree structure.

Each record in the data file has a header of 0x0A bytes:

  0x00  char[2]    0xFA 0xFA (magic value?)
  0x02  uint32_le  offset to next record
  0x06  uint32_le  data size of this record

Data size may be smaller than offset-0x0A, possibly because the resource has
been replaced with a smaller one.

Apparently cTree stores records as mostly opaque blobs, so the record contents
are totally application-defined.

Item data begins with:

  0x00  uint32_le  resource type
  0x04  uint32_le  resource ID
  0x08  uint32_le  data size (record size - 0x0C)
  ...
  0x24  uint32_le  first property key
  0x28  uint32_le  first property value
  ...              more properties

Sometimes the data file record does not match index record.  This may have
something to do with interpolating items?  Also there are sometimes multiple
index records that point to the same data record.

All counts appear to be divisible by 1009.  (count = value/1009-1)