How 7-Zip Inspects Compound File Binary Formats

This article explains how 7-Zip treats legacy Microsoft Office files, such as DOC, XLS, and PPT, as browsable archives. By understanding the underlying Compound File Binary Format (CFBF), 7-Zip bypasses the application layer and interacts directly with the file's internal filesystem-like architecture. Readers will learn how the utility identifies the format via file signatures, traverses sector allocation tables, parses directory streams, and exposes raw internal data streams to the user.

Understanding the Compound File Binary Format (CFBF)

Legacy Microsoft Office documents created prior to the XML-based formats (such as DOCX) are built on the Compound File Binary Format, also known as OLE Structured Storage or "DocFile." CFBF functions essentially as a miniature filesystem inside a single physical file. Instead of containing plain raw text, a .doc file contains its own storage hierarchy, including sectors, allocation tables, directories, and data streams. 7-Zip treats this format the same way it treats ISO or TAR files: by reading the container structures rather than interpreting the higher-level document formatting.

Magic Byte Identification

7-Zip does not rely on file extensions to determine how to open an archive. When inspecting a file, it reads the header bytes at the start of the file. A valid CFBF file begins with a specific 8-byte signature:

D0 CF 11 E0 A1 B1 1A E1

When 7-Zip detects this signature, it directs the file to its internal CFBF/Compound handler rather than attempting to decompress it with general algorithms like Deflate or LZMA.

Reading the Header and Sector Allocation

Once 7-Zip recognizes the CFBF signature, it parses the 512-byte header to determine the layout of the file:

  1. Sector Size: The header defines the sector size, typically 512 bytes (or 4096 bytes in newer revisions).
  2. FAT and DIFAT Chunks: Much like the FAT filesystem on a storage drive, CFBF uses a Sector Allocation Table (SAT/FAT) to chain sectors together into contiguous streams. 7-Zip reads the Double-Indirect File Allocation Table (DIFAT) entries located in the header to map where the full allocation tables reside.
  3. Mini-FAT: To avoid wasting disk space on tiny streams, CFBF implements a Mini-FAT system for streams smaller than a specific cutoff (typically 4096 bytes). 7-Zip locates and maps this secondary allocation table to resolve smaller embedded blocks.

Parsing the Directory Tree

To present the user with a browsable list of files and folders, 7-Zip reads the Directory Stream specified in the header. The Directory Stream contains an array of 128-byte directory entries structured as a red-black balanced tree.

Each directory entry defines:

  • Entry Name: Encoded in UTF-16.
  • Entry Type: Identifies whether the node is a "Storage" (equivalent to a folder), a "Stream" (equivalent to a file), or the "Root Storage."
  • Starting Sector: Points to the first sector in the FAT or Mini-FAT where the entry's content is stored.
  • Size: The total byte length of the stream.

7-Zip walks this red-black tree, interpreting "Storage" nodes as folders and "Stream" nodes as individual files within its interface.

Exposing Streams to the User

After mapping the directory hierarchy and its associated sectors, 7-Zip exposes these components inside its file manager GUI or command-line interface. For a typical .doc file, users can see and extract discrete streams such as:

  • WordDocument: The main binary stream containing document text and formatting structures.
  • 1Table or 0Table: Supporting tables for formatting, styles, and document metadata.
  • SummaryInformation and DocumentSummaryInformation: Standard OLE metadata including author names, creation dates, and edit times.
  • Embedded objects: Any images, embedded OLE objects, or VBA macro streams (such as Macros/VBA).

By navigating the allocation tables and directory streams directly, 7-Zip inspects and extracts these individual components without executing macros or requiring Microsoft Word.