ph3 .dat reverse engineering notes

gistfile1.txt

(mirrored from http://pastebin.com/raw/nt7bbcs0)

0x0 - 0xA: "ArchiveFile"; simple enough.
0xB - 0xE: The number of files, little endian.
0xF: Always 0x1 for some reason.
0x10 - 0x13: The size of the next section, in bytes.
0x14 on: Filename section. Zlib compressed format per RFC 1950.
> Repeated for each file:
> 0x0 - 0x3: The number of bytes that follow
> 0x4 - 0x7: The number of characters in the directory name (dlen).
> 0x8 - 0x8 + 2 * dlen - 1: The directory name, encoded in UTF-16LE.
> 0x8 + 2 * dlen - 0xB + 2 * dlen: The number of characters in the filename (len).
> 0xC + 2 * dlen - 0xC + 2 * dlen + 2 * len - 1: The filename, encoded in UTF-16LE.
> Last 16 bytes: a footer consisting of:
>> 0x0 - 0x3: From observation, seems to be 1 for .txt and 0 for .png and .ogg. Perhaps 1 means compressed and 0 means uncompressed.
>> 0x4 - 0x7: The file size, uncompressed.
>> 0x8 - 0xB: The file size, compressed. If this file is not compressed, then this is zero.
>> 0xC - 0xF: The byte offset in the .dat file.
After that section: There is a run of zeroes for unknown motives. The number of zero bytes seems to correlate with the file size.
After the run of zeroes: There is a file data section. Compressed files use RFC1950, and uncompressed files just spurt out the binary data onto the .dat.

(additional notes)

The run of zeroes seems to be used by Danmakufu to copy over uncompressed data. Defeats the purpose of compression, though.