Skip to main content

Module compression

apfs_core

Module compression 

Source
Expand description

Transparent decmpfs decompression (REUSE — not reinvented).

APFS reuses HFS+’s com.apple.decmpfs scheme verbatim: a 16-byte header (MAGIC 0x636d_7066 “cmpf”, a compression-type byte, uncompressed size), CHUNK_SIZE 65536, payload either embedded in the xattr (odd types) or in the com.apple.ResourceFork stream (even types). The fleet already solved and validated this against real macOS in hfsplus-forensic; this module is the thin APFS-side glue over the same codec stack:

  • type→algorithm/storage map: forensicnomicon::decmpfs::classify — used here, never re-defined.
  • zlib/DEFLATE (types 3/4): flate2.
  • LZVN (types 7/8): our length-tolerant lzvn crate (lzvn-core) — real decmpfs LZVN blocks carry trailing bytes after the end-of-stream opcode that lzfse_rust’s strict path rejects (validated 25/25 on macOS Tahoe by hfsplus-forensic; the bug that motivated the length-tolerant decoder).
  • LZFSE (types 11/12): lzfse_rust.

All pure-Rust, preserving unsafe_code = "forbid". The only APFS-specific part is locating the decmpfs payload (xattr vs resource-fork stream). Any decode failure is a named refusal (crate::ApfsError::Decmpfs) — never fabricated plaintext (fail-loud: fabricating file content is the worst bug in a forensic tool).

Functions§

decompress_decmpfs
Decode a decmpfs payload given its 16-byte header and the file’s resource fork (required only for even/resource-fork compression types; None for inline).
read_compressed
Read a transparently-compressed file’s content: decode the decmpfs payload (inline in the header xattr, or in the com.apple.ResourceFork stream) rather than the raw extent bytes.