{"id":14,"date":"2013-06-12T22:59:34","date_gmt":"2013-06-12T22:59:34","guid":{"rendered":"https:\/\/blogs.scummvm.org\/richiesams\/?p=14"},"modified":"2022-05-22T19:52:07","modified_gmt":"2022-05-22T19:52:07","slug":"zfs-file-format","status":"publish","type":"post","link":"https:\/\/blogs.scummvm.org\/richiesams\/2013\/06\/12\/zfs-file-format\/","title":{"rendered":"ZFS File format"},"content":{"rendered":"

Over the years I’ve reverse engineered quite a few file formats, but I’ve never really sat down and picked apart why a format was designed the way it was. With that said, I wanted to show the ZFS archive file format and highlight\u00a0some of the peculiarities I saw and perhaps you guys can answer some of my questions.<\/p>\n

\nFor some context, Z-engine was created around 1995 and was used on Macintosh, MS-DOS, and Windows 95.<\/p>\n<\/div>\n
Format<\/b><\/div>\n
The main file header is defined as:<\/div>\n
struct ZfsHeader {\r\n    uint32 magic;\r\n    uint32 unknown1;\r\n    uint32 maxNameLength;\r\n    uint32 filesPerBlock;\r\n    uint32 fileCount;\r\n    byte xorKey[4];\r\n    uint32 fileSectionOffset;\r\n};\r\n<\/pre>\n
\n
    \n
  • magic\u00a0and\u00a0unknown1\u00a0are self explanatory<\/li>\n
  • maxNameLength\u00a0refers to the length of the block that stores a file’s name. Any extra spaces are null.<\/li>\n
  • The archive is split into ‘pages’ or ‘blocks’. Each ‘page’ contains, at max,\u00a0filesPerBlock\u00a0files<\/li>\n
  • fileCount\u00a0is total number of files the archive contains<\/li>\n
  • xorKey\u00a0is the\u00a0XOR cipher used for encryption of the files<\/li>\n
  • fileSectionOffset\u00a0is the offset of the main data section, aka fileLength – mainHeaderLength<\/li>\n<\/ul>\n
    <\/div>\n<\/div>\n
    The file entry header is defined as:<\/div>\n
    struct ZfsEntryHeader {\r\n    char name[16];\r\n    uint32 offset;\r\n    uint32 id;\r\n    uint32 size;\r\n    uint32 time;\r\n    uint32 unknown;\r\n};\r\n<\/pre>\n
    \n
      \n
    • name\u00a0is the file name right-padded with null characters<\/li>\n
    • offset\u00a0is the offset to the actual file data<\/li>\n
    • id\u00a0is a the numeric id of the file. The id’s increment from 0 to\u00a0fileCount<\/li>\n
    • size\u00a0is the length of the file<\/li>\n
    • unknown\u00a0is self explanatory<\/li>\n<\/ul>\n
      <\/div>\n
      Therefore, the entire file structure is as follows:<\/div>\n<\/div>\n
      [Main Header]\r\n \r\n[uint32 offsetToPage2]\r\n[Page 1 File Entry Headers]\r\n[Page 1 File Data]\r\n \r\n[uint32 offsetToPage3]\r\n[Page 2 File Entry Headers]\r\n[Page 2 File Data]\r\n \r\netc.\r\n<\/pre>\n
      <\/div>\n
      <\/div>\n
      Questions and Observations<\/b>
      \n
      \n<\/b>maxNameLength
      \nWhy have a fixed size name block vs. null terminated or [size][string]? Was that just the popular thing to do back then so the entire header to could be cast directly to a struct?<\/p>\n
      filesPerBlock
      \nWhat is the benefit to pagination? The only explanation I can see atm is that it was some artifact of their asset compiler max memory. Maybe I’m missing something since I’ve never programmed for that type of hardware.<\/p>\n
      fileSectionOffset
      \nI’ve seen things like this a lot in my reverse engineering; they give the offset to a section that’s literally just after the header. Even if they were doing straight casting instead of incremental reading, a simple sizeof(mainHeader) would give them the offset to the next section. Again, if I’m missing something, please let me know.<\/p>\n
      Well that’s it for now,
      \n-RichieSams<\/p><\/div>\n","protected":false},"excerpt":{"rendered":"
      Over the years I’ve reverse engineered quite a few file formats, but I’ve never really sat down and picked apart why a format was designed the way it was. With that said, I wanted to show the ZFS archive file format and highlight\u00a0some of the peculiarities I saw and perhaps you guys can answer some […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-14","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/blogs.scummvm.org\/richiesams\/wp-json\/wp\/v2\/posts\/14","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blogs.scummvm.org\/richiesams\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.scummvm.org\/richiesams\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.scummvm.org\/richiesams\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.scummvm.org\/richiesams\/wp-json\/wp\/v2\/comments?post=14"}],"version-history":[{"count":1,"href":"https:\/\/blogs.scummvm.org\/richiesams\/wp-json\/wp\/v2\/posts\/14\/revisions"}],"predecessor-version":[{"id":15,"href":"https:\/\/blogs.scummvm.org\/richiesams\/wp-json\/wp\/v2\/posts\/14\/revisions\/15"}],"wp:attachment":[{"href":"https:\/\/blogs.scummvm.org\/richiesams\/wp-json\/wp\/v2\/media?parent=14"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.scummvm.org\/richiesams\/wp-json\/wp\/v2\/categories?post=14"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.scummvm.org\/richiesams\/wp-json\/wp\/v2\/tags?post=14"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}