The Zone File System is a method used by Star Trek: Armada to store game assets in archive-like files, namely the objtxt.zfs and assets.zfs. Especially the latter contains most of the ODF files as well as the tech tree files. The contents are not stored in their plain format, so the whole storage method may be considered kind of a method of obfuscation of actual game assets. The format is, however not very complicated to decipher/unpack.

A ZFS has a header as well as directory-like sections and actual file content sections.

The header has a length of 28 byte, consisting of the following information:

Each directory entry basically consists of a file name and some meta data of where the file content is stored in the ZFS container and its length. It has the following structure:

This gives every directory entry the full length of max. file name length + 20 bytes (max. entry length).

Each file name is stored as ASCII encoded string, ended with a zero-byte (unless using the maximum number of bytes, then the zero byte might be omitted).

If a file name consists only of zero bytes it means the block is not used. As there are no blocks following an unused block, the occurrence of an only-zero-bytes-file name marks the end of the directory block. This should fit the number of files set in the ZFS header.

The meta data of where to find the actual file contents and under what file name they are addressed is found in directory blocks. There must be at least one directory block. (Otherwise no payload files are contained, which makes no sense.) But there can be more than one block. Each block contains the information on where the next directory block is to be found as well as the actual directory entries (see above). Each directory block handles a number of files, the maximum number being set in the header by max. files per directory. A directory looks like this:

This implies that without having read the entire directory block-by-block, there is no explicit information of how many directory blocks are in a ZFS file or how many are following after a specific one. Only once reached the last block is it clear, that no other blocks follow.

If the Next Directory Block Offset is zero it implies that no more directory blocks follow, marking the block the last one of the directory.

The file content itself is not stored in plain in the ZFS files, while the file names and metadata of directories are. The »encryption« of the file contents is actually very simple: Each file is stored in chunks of 4 bytes, each being xor-ed with the Cypher Key taken from the header. So in essence the »password« is provided along with the encrypted file contents. This is why this method of storage cannot seriously be considered proper encryption. Neither is the algorithm strong, nor is an already provided password any serious blockage from reading the file. It's at best a method of obfuscating things.

The stock game file objtxt.zfs contains mostly mission objective texts as well as one testobjectives.t file:

(click to expand)

This file contains almost all the ODF files as well as tech tree files:

This is the list of ODF files provided in the assest.zfs file:

(click to expand)

The following ODF files are replaced by stock patch files in the addon folder:

• borg.odf,
• chainp.odf,
• fed.odf,
• kling.odf and
• rom.odf.

This means, these particular files will (effectively) not be taken from the ZFS file but from the file placed by the 1.2 patch in folder addon. The unpatched files in the ZFS are still present, but the addon folder mechanism overriding them makes it possible to deliver only a few patched files, instead of re-distributing ~800 kB of ODF data and tech tree files.

This is the list of tech tree files provided in the assest.zfs file:

(click to expand)