Dungeon Siege 3 *.oaf file format
Posted: Fri Jun 17, 2011 3:44 pm
With the help of offzip/packzip and Raptor's extractor, I get know some format of *.oaf file, but still not know about everything. Do you guys have some idea about this?
Basically, the file has four parts: file header, zlib stream offset table, zlib stream, file name and tree structure table.
1). File header:
0x0: 3 bytes. Magic number of *.oaf file. 'OAF'
0x3: 9 bytes. Unknown. Maybe part of the magic number.
0xC: 4 bytes. File name table entry offset.
0x10: 4 bytes. Unknown.
0x14: 4 bytes. Entry number. zlib stream should contain the same number of blocks as file name table.
0x18: 4 bytes. Unknown. Looks like some checksum.
2). Zlib stream offset table:
Each entry is 0x14 bytes, so this part should be 0x14 * EntryNumber. Some zeros bytes for alignment may be found after this part.
For each entry:
0x0: 4 bytes. Zlib block start offset.
0x4: 4 bytes. Unknown. Maybe related to the compression algorithm.
0x8: 4 bytes. Raw data size. The unpacked data size in bytes.
0xC: 4 bytes. Packed data size. If this field is zero, it means the raw data is not compressed.
0x10: 4 bytes. Unknown. Looks like some kind of hash related to raw data checksum.
3). Zlib stream.
Note that this part should align at 0x10 bytes, which means the start address of this part & 0xF = 0.
According to the offset table found in the 2nd part, we can dump each block of compressed data.
4). File name and tree structure
Relative directory and filename. Each entry is ended with 0x0 (string end).
Do you guys know the unknown part which I listed?
Basically, the file has four parts: file header, zlib stream offset table, zlib stream, file name and tree structure table.
1). File header:
0x0: 3 bytes. Magic number of *.oaf file. 'OAF'
0x3: 9 bytes. Unknown. Maybe part of the magic number.
0xC: 4 bytes. File name table entry offset.
0x10: 4 bytes. Unknown.
0x14: 4 bytes. Entry number. zlib stream should contain the same number of blocks as file name table.
0x18: 4 bytes. Unknown. Looks like some checksum.
2). Zlib stream offset table:
Each entry is 0x14 bytes, so this part should be 0x14 * EntryNumber. Some zeros bytes for alignment may be found after this part.
For each entry:
0x0: 4 bytes. Zlib block start offset.
0x4: 4 bytes. Unknown. Maybe related to the compression algorithm.
0x8: 4 bytes. Raw data size. The unpacked data size in bytes.
0xC: 4 bytes. Packed data size. If this field is zero, it means the raw data is not compressed.
0x10: 4 bytes. Unknown. Looks like some kind of hash related to raw data checksum.
3). Zlib stream.
Note that this part should align at 0x10 bytes, which means the start address of this part & 0xF = 0.
According to the offset table found in the 2nd part, we can dump each block of compressed data.
4). File name and tree structure
Relative directory and filename. Each entry is ended with 0x0 (string end).
Do you guys know the unknown part which I listed?