{ "schema_version": 1, "generated": "2026-10-21 06:46:19", "commit": "640a2a9928f4e36a976b89901512a8dce824d093", "source": "https://github.com/kalink0/crush-forensics/blob/640a2a9928f4e36a976b89901512a8dce824d093/crush/data/build_formats_db.py", "license": "Apache-2.0", "notes": { "signatures": "hex: the signature bytes. offset: byte offset in the file, null when unknown (shown, never matched by Crush).", "extensions": "Known extensions are a hint, never proof. Evidence files are routinely renamed, carved or exported without an extension. Crush identifies formats by their content, not by their name.", "status": "Draft: compiled from a brief web search (search engine or AI-assisted) and not reviewed yet. Drafts are not part of formats.db, so Crush neither shows them nor uses their signatures.", "crush_support": "Crush support: “Supported” means Crush has a parser or container backend for the format (named in brackets). “Not yet supported” means it has none." }, "formats": [ { "slug": "7z", "url": "https://kalink0.github.io/crush-forensics/formats/7z/", "name": "7-Zip Archive", "short_name": "7Z", "category": "archive", "platforms": [ "Windows", "macOS", "Linux", "iOS", "Android", "QNX" ], "parser_class": "SevenZipVFS", "crush_support": "Supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "General-purpose archive format with high compression ratios (LZMA/LZMA2), increasingly seen as a container for forensic tool output and exfiltrated data due to strong optional AES-256 encryption of both file contents and, with header encryption enabled, the file listing itself — an encrypted-header 7z gives no visibility into archive contents (names, sizes, timestamps) without the password. A 32-byte signature header at offset 0 points to the archive header at the end of the file, which holds the file list; timestamps are stored as UTC FILETIME with 100 ns precision (modification time always, creation and access time optionally). Solid compression (default) groups multiple files into shared compression blocks, meaning a single corrupted block can affect the recoverability of several unrelated files at once — a drawback compared with ZIP's per-file compression. Seen in the wild bundling malware droppers (compression ratio + optional encryption both help evade signature-based and content-inspection scanning), as well as legitimate acquisition tool exports.", "signatures": [ { "offset": 0, "hex": "377ABCAF271C", "length": 6, "description": "7z signature ('7z' BC AF 27 1C), followed by the format version" } ], "extensions": [ ".7z" ], "links": [ { "label": "7z format overview and features (7-Zip)", "url": "https://www.7-zip.org/7z.html" }, { "label": ".7z format specification (py7zr documentation)", "url": "https://py7zr.readthedocs.io/en/latest/archive_format.html" }, { "label": "7z format overview (Wikipedia)", "url": "https://en.wikipedia.org/wiki/7z" } ] }, { "slug": "android-backup", "url": "https://kalink0.github.io/crush-forensics/formats/android-backup/", "name": "Android Backup Archive", "short_name": "Android backup", "category": "archive", "platforms": [ "Android" ], "parser_class": "AndroidBackupVFS", "crush_support": "Supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "Backup created via ADB backup functionality (deprecated; restricted since Android 12 / API 31). The archive is a TAR stream compressed with Deflate, optionally encrypted with AES-256. Contains app data, shared storage, and system settings depending on app configuration. Forensically relevant as a logical acquisition path — but significantly limited: apps setting allowBackup=false (e.g. banking, messaging) are excluded, and apps targeting Android 12+ are automatically excluded. Can reveal installed app data, preferences, and media for apps that permit backup.", "signatures": [ { "offset": 0, "hex": "414E44524F4944204241434B55500A", "length": 15, "description": "Android backup header" } ], "extensions": [ ".ab" ], "links": [ { "label": "AOSP source (BackupManagerService, Android 4.1 original implementation)", "url": "https://android.googlesource.com/platform/frameworks/base/+/refs/heads/jb-dev/services/java/com/android/server/BackupManagerService.java" }, { "label": "Android 12 behavior changes — adb backup restrictions", "url": "https://developer.android.com/about/versions/12/behavior-changes-12" }, { "label": "Android Backup Extractor (ABE)", "url": "https://github.com/nelenkov/android-backup-extractor" }, { "label": "Format internals (Nikolay Elenkov)", "url": "https://nelenkov.blogspot.com/2012/06/unpacking-android-backups.html" }, { "label": "ADB backup forensic acquisition (Andrea Fortuna)", "url": "https://andreafortuna.org/2017/12/29/forensic-logical-acquisition-of-android-devices-using-adb-backup/" } ] }, { "slug": "payload-bin", "url": "https://kalink0.github.io/crush-forensics/formats/payload-bin/", "name": "Android OTA Update Payload (payload.bin)", "short_name": "payload.bin", "category": "archive", "platforms": [ "Android" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-05", "forensic_relevance": "The update payload of Android A/B (seamless) updates, usually named payload.bin inside an OTA ZIP. A big-endian header with major version and manifest size (and, in version 2, the metadata signature size) is followed by a protobuf manifest that describes target partitions and install operations, and by the operation data. Full payloads contain complete partition images; delta payloads only differences to a specific source build. Payloads are used to obtain partition images and to identify the exact firmware build of a device.", "signatures": [ { "offset": 0, "hex": "43724155", "length": 4, "description": "Payload magic 'CrAU'" } ], "extensions": [], "links": [ { "label": "update_engine README — update payload file specification (AOSP)", "url": "https://android.googlesource.com/platform/system/update_engine/+/HEAD/README.md" } ] }, { "slug": "bom", "url": "https://kalink0.github.io/crush-forensics/formats/bom/", "name": "Apple Bill of Materials (BOM)", "short_name": "BOM", "category": "archive", "platforms": [ "macOS", "iOS" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-05", "forensic_relevance": "Apple's BOMStore container format used for installer Bill of Materials files and also as the underlying container for compiled asset catalogs such as Assets.car. macOS installer receipts in /var/db/receipts/*.bom contain file records with metadata such as path, mode, owner, group, size and checksum, making them useful for establishing which files a package installed and for comparing an installed file set with the expected package contents. Installer packages (.pkg, xar) also contain an internal 'Bom' file. Assets.car files use the BOMStore container together with CoreUI-specific structures for compiled asset catalogs; they should therefore be treated as a distinct higher-level format rather than as ordinary BOM receipt files. BOMStore data consists of named blocks, variables and B-tree structures.", "signatures": [ { "offset": 0, "hex": "424F4D53746F7265", "length": 8, "description": "BOMStore signature 'BOMStore'" } ], "extensions": [ ".bom", ".car" ], "links": [ { "label": "bomutils — BOM file reader/writer (source with format structures)", "url": "https://github.com/hogliux/bomutils" } ] }, { "slug": "aea", "url": "https://kalink0.github.io/crush-forensics/formats/aea/", "name": "Apple Encrypted Archive (AEA)", "short_name": "AEA", "category": "archive", "platforms": [ "macOS", "iOS" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-05", "forensic_relevance": "Apple's archive container providing signing and/or encryption, selected by a profile ID in the header (signed-only, symmetric, ECDHE-based and password/scrypt-based variants). The payload is typically compressed and can be an Apple Archive or other data such as disk images. Signed-only archives (profile 0) are not encrypted; this profile is used, for example, for shared Shortcuts (.shortcut) since iOS 15. Encrypted archives are used for Apple software distribution, including root filesystem images in IPSWs (.dmg.aea) since iOS 18 / macOS 15; the header's authentication data contains the parameters needed to obtain the decryption key. Without the key, encrypted archives still establish presence, profile and provenance metadata, but not their contents.", "signatures": [ { "offset": 0, "hex": "41454131", "length": 4, "description": "AEA format signature 'AEA1'" } ], "extensions": [ ".aea", ".shortcut" ], "links": [ { "label": "Apple Encrypted Archive (The Apple Wiki)", "url": "https://theapplewiki.com/wiki/Apple_Encrypted_Archive" }, { "label": "AEA guide (blacktop/ipsw documentation)", "url": "https://blacktop.github.io/ipsw/docs/guides/aea" } ] }, { "slug": "appledouble", "url": "https://kalink0.github.io/crush-forensics/formats/appledouble/", "name": "AppleDouble / AppleSingle", "short_name": "AppleDouble", "category": "archive", "platforms": [ "macOS" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-05", "forensic_relevance": "Containers for Macintosh file metadata and resource forks when the underlying filesystem or transport cannot preserve them natively. AppleDouble stores the metadata in a separate header file, commonly named '._', alongside the data file; AppleSingle stores the data fork and metadata in a single container. AppleDouble files can contain Finder information, a resource fork and extended attributes; macOS stores extended attributes in an Apple-specific 'ATTR' structure following the Finder Info entry. Modern macOS AppleDouble files can therefore preserve forensic metadata such as com.apple.quarantine, Finder tags and other extended attributes, including download or provenance information where present. They are commonly encountered on non-Mac filesystems and transports and inside ZIP archives, where Finder-created AppleDouble files may occur below __MACOSX/. The containers can preserve metadata that is otherwise absent from the corresponding data file and can therefore provide valuable evidence about file provenance, Finder state and historical file attributes.", "signatures": [ { "offset": 0, "hex": "00051607", "length": 4, "description": "AppleDouble magic 0x00051607" }, { "offset": 0, "hex": "00051600", "length": 4, "description": "AppleSingle magic 0x00051600" } ], "extensions": [], "links": [ { "label": "MIME Encapsulation of Macintosh Files — MacMIME (RFC 1740)", "url": "https://www.rfc-editor.org/rfc/rfc1740.html" }, { "label": "copyfile.c — AppleDouble '._' layout with ATTR extended attributes (Apple OSS)", "url": "https://github.com/apple-oss-distributions/copyfile/blob/main/copyfile.c" } ] }, { "slug": "gzip", "url": "https://kalink0.github.io/crush-forensics/formats/gzip/", "name": "Gzip Compressed Data", "short_name": "gzip", "category": "archive", "platforms": [ "Windows", "macOS", "Linux", "iOS", "Android", "QNX" ], "parser_class": "GzipVFS", "crush_support": "Supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "Single-file lossless compression format using DEFLATE (RFC 1951), defined in RFC 1952. Identified by magic bytes 0x1F 0x8B at offset 0. 10-byte header contains: compression method (CM=8 for DEFLATE), flags (FNAME, FCOMMENT, FEXTRA, FHCRC), mtime (4-byte Unix timestamp of original file — forensically significant, may reveal when the source file was last modified; 0 if unavailable, e.g. when a stream was compressed or the name/time were suppressed), OS byte (identifies the OS that created the file: 0=FAT, 3=Unix, 7=Mac, 11=NTFS), and optional original filename (FNAME flag). 8-byte footer: CRC-32 of uncompressed data and original file size (modulo 2^32). Forensically common as: Linux log rotation (.gz), compressed kernels and ramdisks in Android boot images (mainly older devices), iOS/macOS sysdiagnose archives (.tar.gz), network traffic content encoding, and database backups. Multiple gzip members can be concatenated in a single .gz file. OS byte and mtime can reveal the origin platform and source file age.", "signatures": [ { "offset": 0, "hex": "1F8B08", "length": 3, "description": "Gzip magic number (ID1=0x1F, ID2=0x8B) and compression method 8 (DEFLATE)" } ], "extensions": [ ".gz", ".tgz" ], "links": [ { "label": "GZIP file format specification (RFC 1952)", "url": "https://www.rfc-editor.org/rfc/rfc1952.html" }, { "label": "Gzip format overview (Wikipedia)", "url": "https://en.wikipedia.org/wiki/Gzip" }, { "label": "Gzip format (Library of Congress)", "url": "https://www.loc.gov/preservation/digital/formats/fdd/fdd000599.shtml" }, { "label": "Gzip (ForensicsWiki)", "url": "https://forensics.wiki/gzip/" } ] }, { "slug": "lz4", "url": "https://kalink0.github.io/crush-forensics/formats/lz4/", "name": "LZ4 Frame", "short_name": "LZ4", "category": "archive", "platforms": [ "Windows", "macOS", "Linux", "iOS", "Android", "QNX" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-05", "forensic_relevance": "The LZ4 frame format for .lz4 files and LZ4-compressed data in apps, kernels and databases. The frame descriptor records block size, checksums and optionally the content size. The older legacy frame format (fixed 8 MB blocks, no checksum) is still used by the Linux kernel for LZ4-compressed kernel images and initramfs. (Mozilla's jsonlz4 and Apple's LZ4 variants use other headers.)", "signatures": [ { "offset": 0, "hex": "04224D18", "length": 4, "description": "Frame magic 0x184D2204" }, { "offset": 0, "hex": "02214C18", "length": 4, "description": "Legacy frame magic 0x184C2102" } ], "extensions": [ ".lz4" ], "links": [ { "label": "LZ4 Frame Format Description (lz4 project)", "url": "https://github.com/lz4/lz4/blob/dev/doc/lz4_Frame_format.md" } ] }, { "slug": "lzfse", "url": "https://kalink0.github.io/crush-forensics/formats/lzfse/", "name": "LZFSE Compressed Data", "short_name": "LZFSE", "category": "archive", "platforms": [ "macOS", "iOS" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "Apple-proprietary lossless compression algorithm introduced with iOS 9 and macOS 10.11 (El Capitan). Used in OTA software updates, IPSW firmware payloads, Dyld Shared Cache (DSC), kernelcache, some system binaries, and app data. Files must be decompressed before content analysis. Identified by the 'bvx2' magic (0x62767832). Apple also uses a simpler variant called LZVN (used for inputs under 4096 bytes and unconditionally in Mach-O compressed segments). HFS+ and APFS transparent file compression also uses LZFSE/LZVN — the file's content is then stored compressed in a resource fork or extended attribute, not in the data stream. Also used in Apple Archive (.aar) format since macOS Big Sur.", "signatures": [ { "offset": 0, "hex": "62767832", "length": 4, "description": "LZFSE magic ('bvx2', compressed block with compressed tables)" }, { "offset": 0, "hex": "62767831", "length": 4, "description": "LZFSE magic ('bvx1', compressed block with uncompressed tables)" }, { "offset": 0, "hex": "6276786E", "length": 4, "description": "LZVN-compressed block ('bvxn')" }, { "offset": 0, "hex": "6276782D", "length": 4, "description": "Uncompressed block ('bvx-')" } ], "extensions": [], "links": [ { "label": "LZFSE reference implementation (Apple/GitHub)", "url": "https://github.com/lzfse/lzfse" }, { "label": "Apple developer docs — Compression framework", "url": "https://developer.apple.com/documentation/compression/algorithm/lzfse" }, { "label": "LZFSE overview (Wikipedia)", "url": "https://en.wikipedia.org/wiki/LZFSE" } ] }, { "slug": "cab", "url": "https://kalink0.github.io/crush-forensics/formats/cab/", "name": "Microsoft Cabinet (CAB)", "short_name": "CAB", "category": "archive", "platforms": [ "Windows" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-05", "forensic_relevance": "Microsoft's compressed archive format for installers, Windows updates and drivers. Holds file names, sizes, DOS date/time stamps and attributes for each file; the DOS timestamps have a 2-second resolution and no time zone and usually reflect the creator's local time. Data is stored uncompressed or compressed with MSZIP or LZX. Cabinets can be split across several files, each recording the names of the previous and next cabinet in the set, and can be signed with Authenticode, the signature being referenced from the reserved header area.", "signatures": [ { "offset": 0, "hex": "4D53434600000000", "length": 8, "description": "Signature 'MSCF' followed by the zeroed reserved1 field" } ], "extensions": [ ".cab" ], "links": [ { "label": "Microsoft Cabinet Format (Microsoft)", "url": "https://learn.microsoft.com/en-us/previous-versions/bb417343(v=msdn.10)" } ] }, { "slug": "jsonlz4", "url": "https://kalink0.github.io/crush-forensics/formats/jsonlz4/", "name": "Mozilla LZ4 (jsonlz4)", "short_name": "jsonlz4", "category": "archive", "platforms": [ "Windows", "macOS", "Linux" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-05", "forensic_relevance": "Firefox's LZ4-compressed JSON files: session store (sessionstore.jsonlz4, recovery.jsonlz4 — open tabs, history per tab, form data, cookies), bookmark backups, search engine configuration (search.json.mozlz4), add-on startup data (addonStartup.json.lz4) and other add-on data. A custom header 'mozLz40\\0' and the decompressed size (4 bytes, little-endian) precede a raw LZ4 block without frame.", "signatures": [ { "offset": 0, "hex": "6D6F7A4C7A343000", "length": 8, "description": "Header magic 'mozLz40'" } ], "extensions": [ ".jsonlz4", ".mozlz4", ".baklz4" ], "links": [ { "label": "dejsonlz4 — reference decoder (avih)", "url": "https://github.com/avih/dejsonlz4" } ] }, { "slug": "rar", "url": "https://kalink0.github.io/crush-forensics/formats/rar/", "name": "RAR Archive", "short_name": "RAR", "category": "archive", "platforms": [ "Windows", "macOS", "Linux", "iOS", "Android", "QNX" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-05", "forensic_relevance": "The RAR archive format (versions 1.5–4.x and 5.0): headers with file names, sizes, modification (and optionally creation and access) times and attributes; RAR 5.0 stores times as Unix time (optionally with nanoseconds) or Windows FILETIME. Supports solid compression, multi-volume sets and recovery records. RAR 5.0 uses AES-256 with PBKDF2, RAR 3.x–4.x AES-128, while RAR 2.x used a proprietary cipher; encryption can cover the data or the headers too. With encrypted headers even the file names are hidden. Self-extracting (SFX) archives carry the RAR signature not at offset 0 but after an executable module and are therefore initially identified as executables.", "signatures": [ { "offset": 0, "hex": "526172211A0700", "length": 7, "description": "RAR 1.5–4.x signature" }, { "offset": 0, "hex": "526172211A070100", "length": 8, "description": "RAR 5.0 signature" }, { "offset": null, "hex": "52457E5E", "length": 4, "description": "Signature of RAR versions before 1.5 (sparsely documented)" } ], "extensions": [ ".rar", ".r00" ], "links": [ { "label": "RAR 5.0 archive format (RARLAB)", "url": "https://www.rarlab.com/technote.htm" }, { "label": "ForensicsWiki — RAR", "url": "https://forensics.wiki/rar/" } ] }, { "slug": "tar", "url": "https://kalink0.github.io/crush-forensics/formats/tar/", "name": "TAR Archive", "short_name": "TAR", "category": "archive", "platforms": [ "Windows", "macOS", "Linux", "iOS", "Android", "QNX" ], "parser_class": "TarVFS", "crush_support": "Supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "Unix standard archive format packaging files and directory trees with full metadata preservation. TAR itself provides no compression — commonly combined with gzip (.tar.gz/.tgz), bzip2 (.tar.bz2), or xz (.tar.xz). Structure: each file entry has a 512-byte header containing filename, permissions, UID/GID (as octal ASCII), file size, and mtime (Unix epoch seconds as octal ASCII). Four major variants: V7 (no magic), USTAR/POSIX ('ustar\\0' at offset 257 — adds uname/gname and longer paths), GNU tar ('ustar \\0' with two spaces), and PAX/POSIX.1-2001 (USTAR + extended header records for sub-second timestamps, unlimited path lengths, and UTF-8 encoding). Forensically relevant as: Samsung firmware packages (.tar.md5), iOS/macOS app packages (.ipa are ZIP, but some backup formats use TAR), Linux backup archives, Docker image layers, and forensic tool outputs. TAR has no deletion mechanism — updated files are appended as new entries; superseded versions of the same file remain in the archive. mtime in headers may reveal original file timestamps from the source system.", "signatures": [ { "offset": 257, "hex": "7573746172", "length": 5, "description": "USTAR/GNU magic ('ustar') at offset 257 in first header block" } ], "extensions": [ ".tar", ".tgz", ".tar.gz", ".tar.bz2", ".tar.xz" ], "links": [ { "label": "TAR format specification (GNU tar manual)", "url": "https://www.gnu.org/software/tar/manual/html_node/Standard.html" }, { "label": "TAR archive format overview (Wikipedia)", "url": "https://en.wikipedia.org/wiki/Tar_(computing)" }, { "label": "The tar archive format, its extensions, and why GNU tar extracts in quadratic time (mort.coffee, 2022)", "url": "https://mort.coffee/home/tar/" } ] }, { "slug": "wim", "url": "https://kalink0.github.io/crush-forensics/formats/wim/", "name": "Windows Imaging Format (WIM / ESD)", "short_name": "WIM", "category": "archive", "platforms": [ "Windows" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-05", "forensic_relevance": "File-based image format for Windows installation media, deployment and backup images. A WIM can hold several images, each a complete directory tree with NTFS metadata such as timestamps, security descriptors and named data streams, plus XML metadata per image; identical content is stored only once. ESD files use the same format with solid LZMS compression. With WIMBoot (Windows 8.1 and later), files on a volume can be pointer files backed by a WIM.", "signatures": [ { "offset": 0, "hex": "4D5357494D000000", "length": 8, "description": "Header magic 'MSWIM'" } ], "extensions": [ ".wim", ".esd", ".swm" ], "links": [ { "label": "wimlib documentation", "url": "https://wimlib.net/man1/wimlib-imagex.html" }, { "label": "wimlib header.h (source with header layout)", "url": "https://github.com/ebiggers/wimlib/blob/master/include/wimlib/header.h" } ] }, { "slug": "xar", "url": "https://kalink0.github.io/crush-forensics/formats/xar/", "name": "XAR Archive", "short_name": "XAR", "category": "archive", "platforms": [ "macOS" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-05", "forensic_relevance": "The eXtensible ARchive format used by macOS flat installer packages (.pkg), XIP archives and some other Apple software distribution artifacts; older bundle-style .pkg packages are directories instead. An XAR archive consists of a big-endian binary header, a zlib-compressed XML table of contents (TOC) and a heap containing the archived file data. The TOC can contain paths, file types, ownership, permissions, timestamps, sizes and per-file archived and extracted checksums, providing useful metadata for forensic analysis and integrity comparisons. Signed XAR archives reference the signature data stored in the heap from the TOC, which also embeds the associated X.509 certificate chain. For installer packages, the TOC can therefore provide both metadata about package contents and information useful for validating the integrity and provenance of the package.", "signatures": [ { "offset": 0, "hex": "78617221", "length": 4, "description": "XAR signature 'xar!'" } ], "extensions": [ ".pkg", ".xar", ".xip" ], "links": [ { "label": "xar format (mackyle/xar wiki)", "url": "https://github.com/mackyle/xar/wiki/xarformat" }, { "label": "xar source (Apple Open Source)", "url": "https://github.com/apple-oss-distributions/xar" } ] }, { "slug": "xz", "url": "https://kalink0.github.io/crush-forensics/formats/xz/", "name": "XZ Compressed Data", "short_name": "XZ", "category": "archive", "platforms": [ "Windows", "macOS", "Linux", "iOS", "Android", "QNX" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-05", "forensic_relevance": "LZMA2-based compressed stream holding a single file, often a TAR archive (.tar.xz), Linux packages, kernel modules or firmware. Streams consist of blocks with integrity checks (CRC32, CRC64, SHA-256 or none) and an index, and end with the footer magic 'YZ'; multiple streams may be concatenated. No file name or timestamp is stored.", "signatures": [ { "offset": 0, "hex": "FD377A585A00", "length": 6, "description": "Stream header magic FD 37 7A 58 5A 00" } ], "extensions": [ ".xz", ".txz" ], "links": [ { "label": "The .xz File Format (Tukaani)", "url": "https://tukaani.org/xz/xz-file-format.txt" } ] }, { "slug": "zip", "url": "https://kalink0.github.io/crush-forensics/formats/zip/", "name": "ZIP Archive", "short_name": "ZIP", "category": "archive", "platforms": [ "Windows", "macOS", "Linux", "iOS", "Android", "QNX" ], "parser_class": "ZipVFS", "crush_support": "Supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "Ubiquitous archive format and basis for many higher-level formats: APK (Android apps), IPA (iOS apps), DOCX/XLSX/PPTX (Office Open XML), JAR (Java), and many others are ZIP archives with specific internal structures. Dual-directory structure: Local File Headers precede each entry's data, Central Directory at end-of-file is the authoritative index — discrepancies between them can indicate tampering, polyglot files, or malware. EOCD (End of Central Directory) comment field may contain hidden data, tracker IDs, or malware markers — scan the last 64KB for the EOCD magic. Timestamps use DOS date/time format: 2-second precision, local time, no timezone information — unreliable for precise forensic timeline unless extra fields add UTC times (0x5455 extended timestamp, 0x000A NTFS modification/access/creation times). APK-specific: APK Signing Block v2+ inserts between the last Local File Header and Central Directory — presence indicates modern Android signing. ZIP structure variation (creator OS, compressor version, extra fields) can fingerprint the tool or OS used to create the archive. Encryption: ZipCrypto (legacy, weak — known-plaintext attack possible) or WinZip AES (128/192/256-bit, strong). Standard ZIP limited to 4GB — ZIP64 extension required for larger archives.", "signatures": [ { "offset": 0, "hex": "504B0304", "length": 4, "description": "ZIP Local File Header signature ('PK\\x03\\x04')" }, { "offset": 0, "hex": "504B0506", "length": 4, "description": "Empty archive (End of Central Directory record only)" }, { "offset": 0, "hex": "504B0708504B0304", "length": 8, "description": "First segment of a split/spanned archive (span signature followed by Local File Header)" }, { "offset": null, "hex": "504B0506", "length": 4, "description": "End of Central Directory record, within the last 64 KB of the file" } ], "extensions": [ ".zip", ".apk", ".ipa", ".jar", ".docx", ".xlsx", ".pptx" ], "links": [ { "label": "ZIP format specification (PKWARE APPNOTE)", "url": "https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT" }, { "label": "ZIP format overview (Wikipedia)", "url": "https://en.wikipedia.org/wiki/ZIP_(file_format)" }, { "label": "File fingerprinting of the ZIP format for identifying and tracking provenance (FSI: Digital Investigation, 2021)", "url": "https://www.sciencedirect.com/science/article/abs/pii/S266628172100189X" }, { "label": "An Android Package is no Longer a ZIP — APK Signing Block (Fortinet, 2018)", "url": "https://www.fortinet.com/blog/threat-research/an-android-package-is-no-longer-a-zip" }, { "label": "ForensicsWiki — ZIP format", "url": "https://forensics.wiki/zip/" } ] }, { "slug": "zstd", "url": "https://kalink0.github.io/crush-forensics/formats/zstd/", "name": "Zstandard Compressed Data", "short_name": "zstd", "category": "archive", "platforms": [ "Windows", "macOS", "Linux", "iOS", "Android", "QNX" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-05", "forensic_relevance": "Zstandard frames as used for .zst files, Linux packages (e.g. Arch Linux .pkg.tar.zst), initramfs and kernel modules, and as HTTP content encoding stored in browser caches. A frame header may record the content size, a checksum flag and a dictionary ID; data compressed with a dictionary cannot be decompressed without that dictionary. Skippable frames (magic 0x184D2A50–0x184D2A5F) can carry arbitrary other data.", "signatures": [ { "offset": 0, "hex": "28B52FFD", "length": 4, "description": "Frame magic 0xFD2FB528" }, { "offset": null, "hex": "502A4D18", "length": 4, "description": "Skippable frame magic 0x184D2A50–0x184D2A5F (low nibble of first byte varies)" } ], "extensions": [ ".zst", ".tzst" ], "links": [ { "label": "Zstandard Compression and the 'application/zstd' Media Type (RFC 8878)", "url": "https://www.rfc-editor.org/rfc/rfc8878.html" } ] }, { "slug": "bzip2", "url": "https://kalink0.github.io/crush-forensics/formats/bzip2/", "name": "bzip2 Compressed Data", "short_name": "bzip2", "category": "archive", "platforms": [ "Windows", "macOS", "Linux", "iOS", "Android", "QNX" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-05", "forensic_relevance": "Block-sorting compressed stream holding a single file, often a TAR archive (.tar.bz2) or a log/disk image. No file name or timestamp is stored. Each block (up to 900 kB uncompressed) carries its own CRC and starts with a 48-bit block magic; since blocks are bit-aligned, recovering undamaged blocks from truncated or carved streams requires a bit-level search (e.g. bzip2recover). Multiple streams may be concatenated.", "signatures": [ { "offset": 0, "hex": "425A68", "length": 3, "description": "Signature 'BZh' followed by the block size digit" }, { "offset": 4, "hex": "314159265359", "length": 6, "description": "First block magic 0x314159265359 (BCD pi)" }, { "offset": 4, "hex": "177245385090", "length": 6, "description": "Stream footer magic 0x177245385090 (BCD sqrt(pi)) of an empty stream" } ], "extensions": [ ".bz2", ".tbz2", ".tbz" ], "links": [ { "label": "bzip2 (sourceware.org)", "url": "https://sourceware.org/bzip2/" }, { "label": "The bzip2 format (Joe Tsai, dsnet/compress)", "url": "https://github.com/dsnet/compress/blob/master/doc/bzip2-format.pdf" } ] }, { "slug": "ios-backup", "url": "https://kalink0.github.io/crush-forensics/formats/ios-backup/", "name": "iOS Backup (iTunes/Finder)", "short_name": "iOS Backup", "category": "archive", "platforms": [ "Windows", "macOS", "iOS" ], "parser_class": "ITunesBackupVFS", "crush_support": "Supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "Local iOS device backup created by iTunes (Windows/older macOS), Finder (macOS 10.15+) or the Apple Devices app (Windows). Stored at: Windows: %APPDATA%\\Apple Computer\\MobileSync\\Backup\\{UDID}\\ (Microsoft Store iTunes / Apple Devices: %USERPROFILE%\\Apple\\MobileSync\\Backup\\{UDID}\\) macOS: ~/Library/Application Support/MobileSync/Backup/{UDID}/ Structure (iOS 10+): 256 subdirectories (00-ff) containing files named by SHA-1 hash of domain+'-'+relativePath — no file extensions, no original filenames; older backups are flat and indexed by Manifest.mbdb. Four key metadata files: Info.plist (device info, installed apps, last backup date, iTunes version), Manifest.plist (backup keybag, encryption flag, WasPasscodeSet, app list), Status.plist (backup state, creation start date), Manifest.db (SQLite index mapping fileIDs to domain/relativePath/metadata). In encrypted backups (IsEncrypted=true) each file is encrypted with a per-file key wrapped by the backup keybag, and since iOS 10.2 Manifest.db itself is encrypted with the ManifestKey stored in Manifest.plist; unencrypted backups leave both the file contents and Manifest.db in the clear. The backup password is not tied to the device passcode. Keychain data (keychain-backup.plist) is present in both, but in unencrypted backups it stays protected with a device UID-derived key and cannot be decrypted off the device. Manifest.plist's WasPasscodeSet shows whether a passcode was set on the device.", "signatures": [], "extensions": [], "links": [ { "label": "Keybags for Data Protection — backup keybag (Apple Platform Security)", "url": "https://support.apple.com/guide/security/keybags-for-data-protection-sec6483d5760/web" }, { "label": "iTunes Backup format internals, unencrypted / Manifest.mbdb (The Apple Wiki)", "url": "https://theapplewiki.com/wiki/ITunes_Backup" }, { "label": "iPhone backup forensics 101 (Kinga Kieczkowska / OBTS v7)", "url": "https://kieczkowska.wordpress.com/2025/04/29/iphone-backup-forensics-101/" }, { "label": "iOS Data Protection on Backup (VulBusters, Medium)", "url": "https://medium.com/@vulbusters/ios-data-protection-on-backup-6f53d588c830" } ] }, { "slug": "ds-store", "url": "https://kalink0.github.io/crush-forensics/formats/ds-store/", "name": "macOS Finder .DS_Store", "short_name": ".DS_Store", "category": "configuration", "platforms": [ "macOS" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-05", "forensic_relevance": "Hidden Finder files storing per-directory metadata and view settings in a B-tree database. Records are keyed by file or directory name and can contain information such as icon position, Finder view style, display settings, Spotlight comments and, for directories, timestamps (modD/moDD). Records may persist after the corresponding file has been removed from the directory, making .DS_Store files potentially useful for recovering names and other historical evidence of directory contents. .DS_Store files can also be found outside the original macOS volume, for example on network shares, removable media and in extracted archive contents, because Finder may create them when browsing those locations.", "signatures": [ { "offset": 0, "hex": "0000000142756431", "length": 8, "description": "Initial alignment value 1 followed by buddy-allocator magic 'Bud1'" } ], "extensions": [], "links": [ { "label": "DS_Store format (Wim Lewis, Mac::Finder::DSStore)", "url": "https://metacpan.org/dist/Mac-Finder-DSStore/view/DSStoreFormat.pod" } ] }, { "slug": "keystore", "url": "https://kalink0.github.io/crush-forensics/formats/keystore/", "name": "Android Keystore", "short_name": "Keystore", "category": "database", "platforms": [ "Android" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "Android's credential and key storage system. Two distinct layers: (1) App-level keystore files — BKS (Bouncy Castle KeyStore) or PKCS#12/PFX files bundled in APKs for certificate pinning and SSL. BKS files contain certificates, private keys, and trust anchors; their passwords are frequently hardcoded in app code. (2) System Keystore — keys generated through Keymaster/KeyMint in the TEE or StrongBox are stored as wrapped key blobs under /data/misc/keystore/: up to Android 11 as one file per key in user_/ named after the owning UID and alias, since Android 12 (keystore2) in the SQLite database persistent.sqlite. The key material cannot be used off the device, but aliases, owning UIDs and certificates remain readable. App keystore files (.bks, .keystore, .p12, .pfx) are found bundled in APK assets/ or res/raw/ directories. App keystores can also be JKS/JCEKS; see Java KeyStore. BKS has no magic and begins with its version number; PKCS#12 is DER (ASN.1 SEQUENCE, 0x30). Hardcoded keystore passwords in decompiled DEX are a common finding in mobile app security assessments.", "signatures": [ { "offset": null, "hex": "30", "length": 1, "description": "PKCS#12/PFX — ASN.1 SEQUENCE tag (too generic to match on)" } ], "extensions": [ ".keystore", ".bks", ".p12", ".pfx" ], "links": [ { "label": "Android Keystore system (Android developer docs)", "url": "https://developer.android.com/privacy-and-security/keystore" }, { "label": "keystore2 database schema (AOSP system/security, database.rs)", "url": "https://android.googlesource.com/platform/system/security/+/refs/heads/main/keystore2/src/database.rs" }, { "label": "PKCS#12 format overview (Wikipedia)", "url": "https://en.wikipedia.org/wiki/PKCS_12" }, { "label": "Mind Your Keys? A Security Evaluation of Java Keystores (NDSS 2018)", "url": "https://www.ndss-symposium.org/wp-content/uploads/2018/02/ndss2018_02B-1_Focardi_paper.pdf" } ] }, { "slug": "binarycookies", "url": "https://kalink0.github.io/crush-forensics/formats/binarycookies/", "name": "Apple Binary Cookies", "short_name": "binarycookies", "category": "database", "platforms": [ "macOS", "iOS" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-05", "forensic_relevance": "Cookie store of Safari and WebKit-based apps (Cookies.binarycookies) on macOS and iOS, found in the user's and in app-specific Library/Cookies directories. A big-endian file header lists the page sizes; each page holds little-endian cookie records with domain, name, path, value, flags (secure, HTTP-only) and expiration and creation times as Cocoa timestamps (seconds since 2001-01-01 UTC). Cookies reveal visited services, logged-in accounts and their creation time, also for apps with embedded web views.", "signatures": [ { "offset": 0, "hex": "636F6F6B", "length": 4, "description": "Signature 'cook'" } ], "extensions": [ ".binarycookies" ], "links": [ { "label": "Safari cookies file format (libyal/dtformats)", "url": "https://github.com/libyal/dtformats/blob/main/documentation/Safari%20Cookies.asciidoc" } ] }, { "slug": "keychain", "url": "https://kalink0.github.io/crush-forensics/formats/keychain/", "name": "Apple Keychain", "short_name": "Keychain", "category": "database", "platforms": [ "macOS", "iOS" ], "parser_class": "SQLiteParser", "crush_support": "Supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "Apple's password management system storing credentials, private keys, certificates, Wi-Fi passwords, payment data, and secure notes. On iOS, implemented as a single SQLite database at /private/var/Keychains/keychain-2.db — the file itself is not encrypted, but each item is encrypted with two AES-256-GCM keys: a metadata key for its attributes (protected by the Secure Enclave, cached in the application processor) and a per-row key for the secret value (unwrapped only by the Secure Enclave), both bound to the item's protection class. Records contain: account name (acct), service (svce), server, access group (agrp — identifies the owning app), protection class, and the encrypted secret (data). On macOS: Login Keychain (~/Library/Keychains/login.keychain-db, .keychain before 10.12) and System Keychain (/Library/Keychains/System.keychain) use a separate big-endian database format beginning 'kych', not SQLite; Local Items/iCloud Keychain is a keychain-2.db (SQLite) with a user.kb keybag under ~/Library/Keychains//. If iCloud Keychain sync is enabled, keychain-2.db may contain credentials from all the user's Apple devices. Encrypted iTunes/Finder backups contain the keychain as keychain-backup.plist, decryptable offline with the backup password except for ThisDeviceOnly items. On devices with a Secure Enclave (iPhone 5s and later) the class keys can only be unwrapped on the device itself; older devices allow offline decryption with extracted class keys.", "signatures": [ { "offset": null, "hex": "53514C69746520666F726D6174203300", "length": 16, "description": "SQLite magic — keychain-2.db is a standard SQLite database" } ], "extensions": [ ".db", ".keychain", ".keychain-db" ], "links": [ { "label": "Apple keychain data protection (Apple Security Guide)", "url": "https://support.apple.com/guide/security/keychain-data-protection-secb0694df1a/web" }, { "label": "MacOS keychain database file format (libyal/dtformats)", "url": "https://github.com/libyal/dtformats/blob/main/documentation/MacOS%20keychain%20database%20file%20format.asciidoc" }, { "label": "Extracting and decrypting iOS Keychain (ElcomSoft / DFIR Review)", "url": "https://dfir.pubpub.org/pub/gqqxl93l" }, { "label": "Deep dive into Apple Keychain decryption (Passware)", "url": "https://blog.passware.com/a-deep-dive-into-apple-keychain-decryption/" } ] }, { "slug": "spotlight", "url": "https://kalink0.github.io/crush-forensics/formats/spotlight/", "name": "Apple Spotlight Store", "short_name": "Spotlight", "category": "database", "platforms": [ "macOS", "iOS" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-05", "forensic_relevance": "Apple Spotlight metadata indexes used by macOS and iOS. On macOS, stores are typically found below /.Spotlight-V100/Store-V2// and can contain store.db and .store.db files; on iOS, CoreSpotlight indexes are found below .../Library/Spotlight/CoreSpotlight/ (index.spotlightV2). Other Spotlight/CoreSpotlight indexes can exist in user and application-specific locations. The store contains metadata records associated with indexed file-system objects, including file names, paths or path-related information, content types, creation and modification dates, last-used dates, authors, download/source information, URLs and other metadata; depending on the item and index, textual content or searchable content metadata may also be present. Spotlight data is therefore valuable for reconstructing the existence and metadata of files that are no longer present on the live file system, although the presence of an index record does not by itself prove that the corresponding file still existed at the time of acquisition or establish how the file was accessed. Spotlight stores are proprietary databases and their exact contents vary with macOS/iOS versions and the type of index.", "signatures": [ { "offset": 0, "hex": "38747364", "length": 4, "description": "Signature '8tsd' at the beginning of a Spotlight store database" } ], "extensions": [], "links": [ { "label": "Apple Spotlight store file formats (libyal/dtformats)", "url": "https://github.com/libyal/dtformats/blob/main/documentation/Apple%20Spotlight%20store%20database%20file%20format.asciidoc" }, { "label": "spotlight_parser (Yogesh Khatri)", "url": "https://github.com/ydkhatri/spotlight_parser" } ] }, { "slug": "bdb", "url": "https://kalink0.github.io/crush-forensics/formats/bdb/", "name": "Berkeley DB Database", "short_name": "BDB", "category": "database", "platforms": [ "Windows", "macOS", "Linux" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-05", "forensic_relevance": "Embedded key-value database library format with Btree, Hash and Queue access methods. The first page is a metadata page whose magic number at offset 12 identifies the access method; its byte order shows the endianness of the creating system. Commonly encountered as legacy Bitcoin Core wallets (wallet.dat, Btree), which contain keys, addresses and transaction data; newer Bitcoin Core versions use SQLite-based wallets and only migrate legacy files. Also used by older Linux package databases and various Unix services. Freed pages can retain previous records.", "signatures": [ { "offset": 12, "hex": "62310500", "length": 4, "description": "Btree metadata magic 0x00053162 (little-endian)" }, { "offset": 12, "hex": "00053162", "length": 4, "description": "Btree metadata magic 0x00053162 (big-endian)" }, { "offset": 12, "hex": "61150600", "length": 4, "description": "Hash metadata magic 0x00061561 (little-endian)" }, { "offset": 12, "hex": "00061561", "length": 4, "description": "Hash metadata magic 0x00061561 (big-endian)" } ], "extensions": [], "links": [ { "label": "Berkeley DB magic definitions (file/libmagic)", "url": "https://github.com/file/file/blob/master/magic/Magdir/database" }, { "label": "migrate.cpp — Berkeley DB parser for legacy wallets (Bitcoin Core)", "url": "https://github.com/bitcoin/bitcoin/blob/master/src/wallet/migrate.cpp" } ] }, { "slug": "chrome-cache", "url": "https://kalink0.github.io/crush-forensics/formats/chrome-cache/", "name": "Chromium Disk Cache", "short_name": "Chrome cache", "category": "database", "platforms": [ "Windows", "macOS", "Linux", "Android" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-05", "forensic_relevance": "The HTTP cache of Chrome, Edge and other Chromium browsers and Electron apps. The blockfile backend (default on Windows) uses an index file and data_0..3 block files; the simple backend (default on all other platforms) stores one file per entry. Entries hold the URL, response headers with server dates and the cached content (pages, images, scripts), also for sites no longer in history. With cache partitioning, keys are prefixed with '_dk_' and the site that loaded the resource, revealing the context in which it was requested. Content is stored as transferred, so it may be gzip-, Brotli- or Zstandard-encoded.", "signatures": [ { "offset": 0, "hex": "C3CA03C1", "length": 4, "description": "Blockfile index magic 0xC103CAC3" }, { "offset": 0, "hex": "C3CA04C1", "length": 4, "description": "Blockfile data file magic 0xC104CAC3" }, { "offset": 0, "hex": "305C72A71B6DFBFC", "length": 8, "description": "Simple cache entry magic 0xFCFB6D1BA7725C30" }, { "offset": null, "hex": "D8410D97456FFAF4", "length": 8, "description": "Simple cache end-of-stream magic 0xF4FA6F45970D41D8 (EOF records within entry files)" } ], "extensions": [], "links": [ { "label": "Chrome Cache file format (libyal/dtformats)", "url": "https://github.com/libyal/dtformats/blob/main/documentation/Chrome%20Cache%20file%20format.asciidoc" }, { "label": "Disk Cache (Chromium design documents)", "url": "https://www.chromium.org/developers/design-documents/network-stack/disk-cache/" }, { "label": "Very Simple Backend (Chromium design documents)", "url": "https://www.chromium.org/developers/design-documents/network-stack/disk-cache/very-simple-backend/" } ] }, { "slug": "ese", "url": "https://kalink0.github.io/crush-forensics/formats/ese/", "name": "Extensible Storage Engine (ESE) Database", "short_name": "ESE", "category": "database", "platforms": [ "Windows" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "Microsoft's embedded database engine (JET Blue). Used by SRUM (SRUDB.dat — per-app network and energy usage), Windows Search up to Windows 10 (Windows.edb; Windows 11 uses SQLite instead), Internet Explorer/Edge legacy WebCache, Active Directory (ntds.dit) and Exchange. Pages are written through transaction logs (.log/.jrs), and a database copied from a live system may be in a 'dirty shutdown' state (recorded in the file header) with changes still only in the logs.", "signatures": [ { "offset": 4, "hex": "EFCDAB89", "length": 4, "description": "File header signature 0x89ABCDEF at offset 4" } ], "extensions": [ ".edb", ".dat", ".dit" ], "links": [ { "label": "Extensible Storage Engine (ESE) Database File (EDB) format (libyal/libesedb)", "url": "https://github.com/libyal/libesedb/blob/main/documentation/Extensible%20Storage%20Engine%20(ESE)%20Database%20File%20(EDB)%20format.asciidoc" }, { "label": "ForensicsWiki — ESE database file format", "url": "https://forensics.wiki/extensible_storage_engine_(ese)_database_file_(edb)_format/" }, { "label": "Windows Search Index: the forensic artifact you've been searching for — ESE vs. SQLite in Windows 11 (LevelBlue/Stroz Friedberg, 2023)", "url": "https://www.levelblue.com/blogs/spiderlabs-blog/windows-search-index-the-forensic-artifact-youve-been-searching-for/" } ] }, { "slug": "cache2", "url": "https://kalink0.github.io/crush-forensics/formats/cache2/", "name": "Firefox Cache (cache2)", "short_name": "cache2", "category": "database", "platforms": [ "Windows", "macOS", "Linux" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-05", "forensic_relevance": "The HTTP cache of Firefox and other Gecko-based browsers in the profile's cache2 folder: an index file and one file per entry below entries/, named by a hash of the key. Each entry file holds the cached content followed by metadata; the last 4 bytes point to the metadata, which contains a version, fetch count, last fetched, last modified and expiration times, the key (URL with context prefixes) and elements such as the response headers. Cached content can show visited pages and loaded resources independent of the browsing history. Entry format version 4 supports at-rest encryption of the metadata.", "signatures": [], "extensions": [], "links": [ { "label": "CacheFileMetadata.h (Firefox source)", "url": "https://github.com/mozilla-firefox/firefox/blob/main/netwerk/cache2/CacheFileMetadata.h" }, { "label": "Firefox cache file format (libyal/dtformats)", "url": "https://github.com/libyal/dtformats/blob/main/documentation/Firefox%20cache%20file%20format.asciidoc" } ] }, { "slug": "hive", "url": "https://kalink0.github.io/crush-forensics/formats/hive/", "name": "Hive Database (Dart / Flutter)", "short_name": "Hive", "category": "database", "platforms": [ "Windows", "macOS", "Linux", "iOS", "Android" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-06", "forensic_relevance": "Append-only key-value store of the Dart/Flutter Hive library (Hive 2.x and its Hive CE continuation). Each box is one .hive file, the box name in lower case, next to a .lock file; a .hivec file is the intermediate result of a compaction. Has no magic bytes: the file is a plain sequence of frames, each made of a little-endian uint32 frame length, the key (type 0: uint32, type 1: UTF-8 string of up to 255 bytes), the value (a type ID byte followed by the data, absent for a deletion) and a CRC32 over the frame. Every write or delete appends a new frame, so earlier values and deleted keys remain in the file until a compaction rewrites only the live frames (automatically once more than 60 obsolete frames make up over 15 % of the entries, or when the app requests it). With encryption only the value is encrypted (AES-256-CBC, random 16-byte IV in front, PKCS7 padding); keys stay in plain text and the CRC is seeded with a checksum of the key. Integers are stored as 64-bit floats. Custom objects carry an app-defined type ID (stored as ID + 32) and store their fields by numeric index, not by name. Hive CE adds value types such as sets, DateTime, BigInt and Duration plus 16-bit type IDs, but keeps the frame layout. Opening a box whose last frame is damaged truncates the file at the last valid frame by default. The Hive 4 development versions store boxes as Isar databases instead (see Isar Database). Depending on the app, boxes hold settings, cached content, session state such as account IDs or tokens, histories or the app's main records. Found in the app data directories of Flutter apps on Android, iOS and desktop systems.", "signatures": [], "extensions": [ ".hive", ".hivec" ], "links": [ { "label": "Hive 2.2.3 frame writer (source)", "url": "https://github.com/isar/hive/blob/v2.2.3/hive/lib/src/binary/binary_writer_impl.dart" }, { "label": "Hive 2.2.3 storage backend: lock file, recovery, compaction (source)", "url": "https://github.com/isar/hive/blob/v2.2.3/hive/lib/src/backend/vm/storage_backend_vm.dart" }, { "label": "Hive CE (Hive Community Edition)", "url": "https://github.com/IO-Design-Team/hive_ce" } ] }, { "slug": "isar", "url": "https://kalink0.github.io/crush-forensics/formats/isar/", "name": "Isar Database (Dart / Flutter)", "short_name": "Isar", "category": "database", "platforms": [ "Windows", "macOS", "Linux", "iOS", "Android" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-06", "forensic_relevance": "Embedded object database of the Dart/Flutter Isar library. Isar 3.x and its community fork store each instance in a single libmdbx file named .isar (default.isar for the default instance) with a .isar-lck lock file next to it. The file is a libmdbx database and carries the libmdbx meta page signature (see LMDB / libmdbx Database); only the name and its sub-databases tell it apart. Each collection is a named sub-database keyed by the 64-bit object ID, accompanied by sub-databases for indexes (_i__) and links (_l_ and _b_ prefixes). The _info sub-database holds the collection schemas as JSON, which gives the property names and types needed to decode the binary objects. Collections hold the app's structured records, for example libraries, histories, download lists or account data, depending on the app. Objects use a compact little-endian layout of a static part followed by dynamic data; DateTime values are stored as UTC microseconds since the Unix epoch. As in any libmdbx file, freed pages can retain deleted or earlier versions of objects until they are reused or the file is compacted (rewritten as .isar.compact and renamed, only when the app enables compaction on open). Isar 3 has no encryption. Isar 4 (development releases and forks) can use this native engine or SQLite; with SQLite the instance is a .sqlite file in WAL mode, optionally encrypted with SQLCipher. Found in the app data directories of Flutter apps on Android, iOS and desktop systems.", "signatures": [ { "offset": null, "hex": "03114CEFBD9D6559", "length": 8, "description": "libmdbx meta page signature at offset 20, shared with every libmdbx file (see LMDB / libmdbx Database); identifies the storage engine, not Isar" } ], "extensions": [ ".isar" ], "links": [ { "label": "Isar 3.1.0+1 instance: file name, sub-databases, compaction (source)", "url": "https://github.com/isar/isar/blob/3.1.0%2B1/packages/isar_core/src/instance.rs" }, { "label": "Isar 3.1.0+1 libmdbx environment flags (source)", "url": "https://github.com/isar/isar/blob/3.1.0%2B1/packages/isar_core/src/mdbx/env.rs" }, { "label": "Isar 4 SQLite engine: file name, WAL, encryption (source)", "url": "https://github.com/isar/isar/blob/main/packages/isar_core/src/sqlite/sqlite_open.rs" }, { "label": "Isar Community (maintained fork of Isar 3)", "url": "https://github.com/isar-community/isar-community" } ] }, { "slug": "jks", "url": "https://kalink0.github.io/crush-forensics/formats/jks/", "name": "Java KeyStore (JKS / JCEKS)", "short_name": "JKS", "category": "database", "platforms": [ "Windows", "macOS", "Linux" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-05", "forensic_relevance": "Key and certificate containers of the Java platform. Entries carry an alias and a creation date in cleartext; certificates are stored unencrypted, while private and secret keys are protected with an entry password (JKS uses a proprietary SHA-1/XOR scheme, JCEKS a stronger password-based encryption). The whole store ends with a keyed SHA-1 digest derived from the store password. Since Java 9 the default keystore type is PKCS#12, which has no fixed signature.", "signatures": [ { "offset": 0, "hex": "FEEDFEED", "length": 4, "description": "JKS magic 0xFEEDFEED" }, { "offset": 0, "hex": "CECECECE", "length": 4, "description": "JCEKS magic 0xCECECECE" } ], "extensions": [ ".jks", ".keystore", ".jceks", ".ks" ], "links": [ { "label": "JavaKeyStore.java (OpenJDK source)", "url": "https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/provider/JavaKeyStore.java" }, { "label": "JceKeyStore.java (OpenJDK source)", "url": "https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/com/sun/crypto/provider/JceKeyStore.java" } ] }, { "slug": "kdb", "url": "https://kalink0.github.io/crush-forensics/formats/kdb/", "name": "KeePass 1.x Database (KDB)", "short_name": "KDB", "category": "database", "platforms": [ "Windows", "macOS", "Linux", "iOS", "Android" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-05", "forensic_relevance": "The password database format of KeePass 1.x and KeePassX. The fixed-size header is readable without the key: encryption flags (AES or Twofish), format version, master seed, IV, the number of groups and entries, a content hash, the transform seed and the number of key transformation rounds, which determines the effort of password attacks. Groups and entries with titles, user names, passwords, URLs and notes are encrypted with a key derived from the master password and/or key file. Signature 1 is shared with the newer KDBX format; only signature 2 distinguishes them.", "signatures": [ { "offset": 0, "hex": "03D9A29A", "length": 4, "description": "Signature 1 0x9AA2D903 (shared with KDBX)" }, { "offset": 4, "hex": "65FB4BB5", "length": 4, "description": "Signature 2 0xB54BFB65 (KeePass 1.x)" } ], "extensions": [ ".kdb" ], "links": [ { "label": "KeePass1.h — format constants (KeePassXC)", "url": "https://github.com/keepassxreboot/keepassxc/blob/develop/src/format/KeePass1.h" }, { "label": "KeePass1Reader.cpp — header layout (KeePassXC)", "url": "https://github.com/keepassxreboot/keepassxc/blob/develop/src/format/KeePass1Reader.cpp" } ] }, { "slug": "kdbx", "url": "https://kalink0.github.io/crush-forensics/formats/kdbx/", "name": "KeePass Database (KDBX)", "short_name": "KDBX", "category": "database", "platforms": [ "Windows", "macOS", "Linux", "iOS", "Android" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-05", "forensic_relevance": "The password database of KeePass, KeePassXC and compatible apps. Outside the encrypted payload only the header is readable: format version (offset 8), cipher, compression, master seed and IV; from KDBX 4 on also the key derivation function and its parameters (e.g. AES-KDF or Argon2 with rounds/memory), protected by an HMAC-SHA-256. The KDF parameters determine the effort of password attacks. Entries with titles, user names, passwords, URLs, notes and history are encrypted with a key derived from the master password and/or key file. Signature 1 is shared with the older KeePass 1.x format (.kdb); only signature 2 distinguishes them.", "signatures": [ { "offset": 0, "hex": "03D9A29A", "length": 4, "description": "Signature 1 0x9AA2D903 (shared with KeePass 1.x)" }, { "offset": 4, "hex": "67FB4BB5", "length": 4, "description": "Signature 2 0xB54BFB67 (KeePass 2.x / KDBX)" } ], "extensions": [ ".kdbx" ], "links": [ { "label": "KDBX File Format Specification (KeePass)", "url": "https://keepass.info/help/kb/kdbx.html" }, { "label": "KDBX 4.1 (KeePass)", "url": "https://keepass.info/help/kb/kdbx_4.1.html" } ] }, { "slug": "lmdb", "url": "https://kalink0.github.io/crush-forensics/formats/lmdb/", "name": "LMDB / libmdbx Database", "short_name": "LMDB", "category": "database", "platforms": [ "Windows", "macOS", "Linux", "iOS", "Android" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-06", "forensic_relevance": "Memory-mapped key-value store built as a copy-on-write B+tree. LMDB and its derivative libmdbx share the design but are not file-compatible. An environment consists of a data file and a lock file: data.mdb and lock.mdb in a directory (LMDB), mdbx.dat and mdbx.lck (libmdbx), or in single-file mode any file name with a lock file carrying the suffix -lock (LMDB) or -lck (libmdbx). In single-file mode the data file often has no extension at all, so the meta page signature is the reliable indicator. The data file starts with two (LMDB) or three (libmdbx) meta pages holding the signature, the last committed transaction ID and the roots of the free-page tree and the main tree; named sub-databases are entries of the main tree. Pages released by a transaction are tracked in the free-page tree and reused later, so deleted and overwritten records can survive in pages no longer referenced, and the older meta pages point to earlier committed states. The lock file only holds the reader table and no records. Header fields use the byte order of the creating system (little-endian on common platforms). In LMDB 0.9 the signature offset depends on the page number size of the build: 16 on 64-bit, 12 on 32-bit. Used by OpenLDAP and many embedded applications, for example Monero node data (lmdb/data.mdb), Ethereum clients such as Erigon and Reth (libmdbx), and Flutter apps using Isar (see Isar Database).", "signatures": [ { "offset": 16, "hex": "DEC0EFBE01000000", "length": 8, "description": "LMDB 0.9 meta page: magic 0xBEEFC0DE and data version 1 (little-endian, 64-bit build)" }, { "offset": 12, "hex": "DEC0EFBE01000000", "length": 8, "description": "LMDB 0.9 meta page: magic 0xBEEFC0DE and data version 1 (little-endian, 32-bit build)" }, { "offset": 20, "hex": "03114CEFBD9D6559", "length": 8, "description": "libmdbx meta page: 56-bit magic 0x59659DBDEF4C11 with data version 3 (little-endian)" } ], "extensions": [ ".mdb", ".dat" ], "links": [ { "label": "LMDB 0.9 source: meta page, magic, file names (mdb.c)", "url": "https://github.com/LMDB/lmdb/blob/mdb.RE/0.9/libraries/liblmdb/mdb.c" }, { "label": "libmdbx 0.12.4 internals: magic, data version, page header (source)", "url": "https://github.com/isar/libmdbx/blob/v0.12.4/src/internals.h" }, { "label": "libmdbx (GitHub mirror)", "url": "https://github.com/erthink/libmdbx" } ] }, { "slug": "leveldb", "url": "https://kalink0.github.io/crush-forensics/formats/leveldb/", "name": "LevelDB Database", "short_name": "LevelDB", "category": "database", "platforms": [ "Windows", "macOS", "Linux", "iOS", "Android", "QNX" ], "parser_class": "LeveldbParser", "crush_support": "Supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "Key-value store used by Chrome/Chromium (IndexedDB, localStorage, sessionStorage), Electron-based desktop apps, and many Android and iOS apps for caches and app state. LevelDB is not a single file but a directory containing: CURRENT and MANIFEST-###### (metadata), .ldb/.sst files (sorted string tables with key-value data, Snappy-compressed blocks), and ######.log files (write-ahead log with recent mutations). All files must be parsed together for a complete view. Deleted or overwritten records survive in .log files with sequence numbers and a deleted/live state flag — deleted data is often recoverable. Values are frequently serialized in the V8/Blink format (Chromium IndexedDB) or as JSON. Chromium's IndexedDB, Local Storage and Session Storage are separate LevelDB stores holding web app state and cached API responses — common sources of social media and messaging artifacts.", "signatures": [ { "offset": null, "hex": "57FB808B247547DB", "length": 8, "description": "Table file (.ldb/.sst) footer magic 0xdb4775248b80fb57 (little-endian) in the last 8 bytes" } ], "extensions": [ ".ldb", ".sst", ".log" ], "links": [ { "label": "LevelDB format specification (Google)", "url": "https://github.com/google/leveldb/blob/main/doc/impl.md" }, { "label": "LevelDB table format (Google)", "url": "https://github.com/google/leveldb/blob/main/doc/table_format.md" }, { "label": "Hang on! That's not SQLite! Chrome, Electron and LevelDB (CCL, Alex Caithness, 2020)", "url": "https://www.cclsolutionsgroup.com/post/hang-on-thats-not-sqlite-chrome-electron-and-leveldb" }, { "label": "IndexedDB on Chromium (CCL, Alex Caithness, 2020)", "url": "https://www.cclsolutionsgroup.com/post/indexeddb-on-chromium" }, { "label": "Chromium Session Storage and Local Storage (CCL, Alex Caithness, 2021)", "url": "https://www.cclsolutionsgroup.com/post/chromium-session-storage-and-local-storage" }, { "label": "MIC: Memory analysis of IndexedDB data on Chromium-based applications (Jeong, Lee, Park — FSI: Digital Investigation 2024)", "url": "https://www.sciencedirect.com/science/article/pii/S2666281724001331" }, { "label": "ForensicsWiki — LevelDB format", "url": "https://forensics.wiki/leveldb_format/" }, { "label": "Reading the CURRENT — LevelDB Forensics with crush (beBinary)", "url": "https://bebinary4n6.blogspot.com/2026/05/reading-current-leveldb-forensics-with.html" } ] }, { "slug": "mmkv", "url": "https://kalink0.github.io/crush-forensics/formats/mmkv/", "name": "MMKV Key-Value Store", "short_name": "MMKV", "category": "database", "platforms": [ "Windows", "macOS", "Linux", "iOS", "Android" ], "parser_class": "MMKVParser", "crush_support": "Supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "Tencent's mmap-backed key-value store (github.com/Tencent/MMKV, BSD-3-Clause), used by many Android and iOS apps in place of SharedPreferences or NSUserDefaults — including WeChat, TikTok, Temu, SHEIN, Xiaohongshu, Weibo, Discord and Coinbase. Usually found as a file named mmkv.default (the library's default instance) inside a folder literally named mmkv, alongside a same-named .crc sibling file carrying integrity/encryption metadata. Has no magic bytes, so it cannot be auto-detected. The store is append-only between rewrites: setting a key appends a new entry rather than editing the old one, so superseded values and removed keys (recorded as a zero-length value, not a real deletion) remain recoverable in file order until the next full rewrite. Optionally AES-CFB encrypted, with the key stored by neither file — decryptable if the app's key is known.", "signatures": [], "extensions": [], "links": [ { "label": "Tencent/MMKV (upstream project)", "url": "https://github.com/Tencent/MMKV" }, { "label": "MMKV design deep dive (Tencent/MMKV wiki)", "url": "https://github.com/Tencent/MMKV/wiki/design_eng" }, { "label": "abrignoni/mmkv-parser — reference reader crush's parser is built on (MIT)", "url": "https://github.com/abrignoni/mmkv-parser" }, { "label": "You down with MMKV? (LEAPPs Blog, Alexis Brignoni)", "url": "https://leapps.org/blog-post?post=2026-09-04-you-down-with-mmkv" } ] }, { "slug": "mdb", "url": "https://kalink0.github.io/crush-forensics/formats/mdb/", "name": "Microsoft Access Database (MDB / ACCDB)", "short_name": "MDB", "category": "database", "platforms": [ "Windows" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-05", "forensic_relevance": "The Jet / ACE database format of Microsoft Access: .mdb (Jet 3 for Access 97, Jet 4 for Access 2000–2003) and .accdb (ACE, Access 2007 and later); the variant 'MSISAM Database' is used by Microsoft Money. Data is stored in pages of 2048 (Jet 3) or 4096 bytes (Jet 4/ACE). The first page names the database engine at offset 4 and holds the format version at offset 0x14; it is obfuscated with a fixed RC4 key and contains the database password (offset 0x42), in Jet 4 additionally masked with a value derived from the database creation date stored on the same page. Deleted rows are only flagged in the row offset table of their data page, so their content can remain until the database is compacted. Such databases are common in business, accounting and administrative applications.", "signatures": [ { "offset": 4, "hex": "5374616E64617264204A6574204442", "length": 15, "description": "Engine name 'Standard Jet DB' (Jet 3 / Jet 4, .mdb)" }, { "offset": 4, "hex": "5374616E6461726420414345204442", "length": 15, "description": "Engine name 'Standard ACE DB' (Access 2007 and later, .accdb)" }, { "offset": 4, "hex": "4D534953414D204461746162617365", "length": 15, "description": "Engine name 'MSISAM Database' (Microsoft Money variant)" } ], "extensions": [ ".mdb", ".accdb", ".mny" ], "links": [ { "label": "MDB file format notes (mdbtools HACKING.md)", "url": "https://github.com/mdbtools/mdbtools/blob/dev/HACKING.md" } ] }, { "slug": "pst", "url": "https://kalink0.github.io/crush-forensics/formats/pst/", "name": "Outlook Personal Folders (PST / OST)", "short_name": "PST", "category": "database", "platforms": [ "Windows" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "Outlook's mailbox file: e-mails, attachments, calendar, contacts and tasks in a B-tree based node database (.pst for archives and POP accounts, .ost as the offline cache of Exchange/Microsoft 365). Exists as 32-bit ANSI (older Outlook, 2 GB limit), 64-bit Unicode and Unicode with 4 KiB pages. Deleted items can remain in unallocated blocks. Optional 'compressible' or 'high' encoding obscures but does not protect the content.", "signatures": [ { "offset": 0, "hex": "2142444E", "length": 4, "description": "Signature '!BDN'" }, { "offset": 8, "hex": "534D", "length": 2, "description": "Content type 'SM' — Personal Storage Table (.pst)" }, { "offset": 8, "hex": "534F", "length": 2, "description": "Content type 'SO' — Offline Storage Table (.ost)" } ], "extensions": [ ".pst", ".ost" ], "links": [ { "label": "[MS-PST]: Outlook Personal Folders (.pst) File Format, v11.2 (Microsoft)", "url": "https://learn.microsoft.com/en-us/openspecs/office_file_formats/ms-pst/141923d5-15ab-4ef1-a524-6dce75aae546" }, { "label": "Personal Folder File (PFF) format (libyal/libpff)", "url": "https://github.com/libyal/libpff/blob/main/documentation/Personal%20Folder%20File%20(PFF)%20format.asciidoc" }, { "label": "ForensicsWiki — Personal folder file (PAB, PST, OST)", "url": "https://forensics.wiki/personal_folder_file_(pab,_pst,_ost)/" } ] }, { "slug": "realm", "url": "https://kalink0.github.io/crush-forensics/formats/realm/", "name": "Realm Database", "short_name": "Realm", "category": "database", "platforms": [ "Windows", "macOS", "Linux", "iOS", "Android" ], "parser_class": "RealmParser", "crush_support": "Supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "Mobile app local object store used as a SQLite alternative, marketed by MongoDB as Atlas Device SDK until its deprecation in 2024. A single '.realm' file stores all object data in a B+ tree of fixed-size arrays. The file holds the full schema (class/table names such as 'class_Driver', 'class_Event', 'class_Photo'). The header contains two root references (top_ref[0] / top_ref[1]) used for copy-on-write commits — a flag selects the active one, the inactive one points to the previous commit and may still reference superseded data. Class names reveal which app features were in use and what data categories are present (users, locations, media, events, etc.). Some Realm databases are AES-256 encrypted — key material may be hardcoded in the app binary or kept in the Keychain/Keystore.", "signatures": [ { "offset": 16, "hex": "542D4442", "length": 4, "description": "Realm header mnemonic (T-DB)" } ], "extensions": [ ".realm" ], "links": [ { "label": "Realm Studio (open .realm files)", "url": "https://www.mongodb.com/docs/atlas/device-sdks/studio/open-realm-file/" }, { "label": "Realm forensics primer (Alexis Brignoni)", "url": "https://abrignoni.blogspot.com/2019/11/realm-database-storage-primer-for.html" }, { "label": "The Realm Files - Vol 3 - The Realm Header (Damien Attoe)", "url": "https://digital4n6withdamien.blogspot.com/2026/01/the-realm-files-vol-3-realm-header.html" }, { "label": "The Realm Files - Vol 2 - Physical Structure Overview (Damien Attoe)", "url": "https://digital4n6withdamien.blogspot.com/2025/11/the-realm-files-vol-2-physical.html" }, { "label": "Methods for recovering deleted data from the Realm database (Kim et al., FSI: Digital Investigation, 2022)", "url": "https://www.sciencedirect.com/science/article/abs/pii/S2666281722000221" }, { "label": "Mobile Forensics – The File Format Handbook: Realm (Springer, 2022)", "url": "https://doi.org/10.1007/978-3-030-98467-0_8" }, { "label": "Object by Object — RealmDB Forensics with crush (beBinary)", "url": "https://bebinary4n6.blogspot.com/2026/05/object-by-object-realmdb-forensics-with.html" } ] }, { "slug": "rocksdb", "url": "https://kalink0.github.io/crush-forensics/formats/rocksdb/", "name": "RocksDB Database", "short_name": "RocksDB", "category": "database", "platforms": [ "Windows", "macOS", "Linux", "iOS", "Android", "QNX" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-10", "forensic_relevance": "Key-value store developed by Facebook as a fork of LevelDB, used as the storage engine of databases and server software and embedded in some applications. Like LevelDB it is a directory, not a single file, and uses the same file names: CURRENT, MANIFEST-###### (the database's version history: which table files exist and on which level, per column family), ######.sst (sorted string tables) and ######.log (write-ahead log of recent writes). It also writes OPTIONS-###### (its settings as text, including the RocksDB version that wrote them), IDENTITY and LOG. The file formats differ from LevelDB's: block-based tables end in their own footer magic and record their checksum type (CRC32C or xxHash), blocks can be compressed with Snappy, zlib, bzip2, LZ4, ZSTD or Xpress, the MANIFEST records column families and further per-file fields, and the write-ahead log can hold column family IDs, merge operands and range deletions. Older versions wrote block-based tables with LevelDB's footer magic. Column families divide one database into separate sets of keys. Deleted and overwritten values remain in table and log files until compaction rewrites them; a merge operand's final value depends on the application's merge operator.", "signatures": [ { "offset": null, "hex": "F7CFF485B741E288", "length": 8, "description": "Block-based table (.sst) footer magic 0x88e241b785f4cff7 (little-endian) in the last 8 bytes" }, { "offset": null, "hex": "6495BF6396224282", "length": 8, "description": "Plain table (.sst) footer magic 0x8242229663bf9564 (little-endian) in the last 8 bytes" }, { "offset": null, "hex": "B8138F7AEB18344F", "length": 8, "description": "Plain table (.sst) with footer format 0: magic 0x4f3418eb7a8f13b8 (little-endian) in the last 8 bytes" }, { "offset": null, "hex": "7378F1C5D0896792", "length": 8, "description": "Cuckoo table (.sst) footer magic 0x926789d0c5f17873 (little-endian) in the last 8 bytes" } ], "extensions": [ ".sst", ".log" ], "links": [ { "label": "RocksDB (official site)", "url": "https://rocksdb.org/" }, { "label": "RocksDB overview (RocksDB wiki)", "url": "https://github.com/facebook/rocksdb/wiki/RocksDB-Overview" }, { "label": "RocksDB BlockBasedTable format (RocksDB wiki)", "url": "https://github.com/facebook/rocksdb/wiki/Rocksdb-BlockBasedTable-Format" }, { "label": "MANIFEST (RocksDB wiki)", "url": "https://github.com/facebook/rocksdb/wiki/MANIFEST" }, { "label": "Write Ahead Log file format (RocksDB wiki)", "url": "https://github.com/facebook/rocksdb/wiki/Write-Ahead-Log-File-Format" }, { "label": "RocksDB Options file (RocksDB wiki)", "url": "https://github.com/facebook/rocksdb/wiki/RocksDB-Options-File" }, { "label": "Column families (RocksDB wiki)", "url": "https://github.com/facebook/rocksdb/wiki/Column-Families" } ] }, { "slug": "sqlcipher", "url": "https://kalink0.github.io/crush-forensics/formats/sqlcipher/", "name": "SQLCipher Encrypted Database", "short_name": "SQLCipher", "category": "database", "platforms": [ "Windows", "macOS", "Linux", "iOS", "Android" ], "parser_class": "SQLiteParser", "crush_support": "Supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "An SQLite database with every page AES-256 encrypted, used by messengers and other apps (Signal, WeChat, many Android apps). The first 16 bytes hold the random key-derivation salt in place of the SQLite header, so the file looks random and has no signature. Each page carries an IV and an HMAC; with the right key and settings (SQLCipher 4 defaults: AES-256-CBC, HMAC-SHA512, PBKDF2-HMAC-SHA512 with 256,000 iterations) it decrypts to an ordinary SQLite database. Apps can keep a plaintext header instead (cipher_plaintext_header_size, mainly for WAL databases in iOS shared containers): the file then begins 'SQLite format 3' but will not open as plain SQLite, and the salt is stored outside the file.", "signatures": [], "extensions": [ ".db", ".sqlite" ], "links": [ { "label": "SQLCipher design — security approach and features (Zetetic)", "url": "https://www.zetetic.net/sqlcipher/design/" }, { "label": "SQLCipher source (Zetetic)", "url": "https://github.com/sqlcipher/sqlcipher" }, { "label": "SQLCipher 4, plaintext header and key salt (Zetetic discussion forum)", "url": "https://discuss.zetetic.net/t/sqlcipher-4-plaintext-header-and-key-salt-problem/3282" } ] }, { "slug": "sqlite", "url": "https://kalink0.github.io/crush-forensics/formats/sqlite/", "name": "SQLite Database", "short_name": "SQLite", "category": "database", "platforms": [ "Windows", "macOS", "Linux", "iOS", "Android", "QNX" ], "parser_class": "SQLiteParser", "crush_support": "Supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "The dominant embedded database on iOS, Android, macOS, and Windows. Used by virtually every app for messages, call logs, contacts, browser history, location data, and app state. Identified by a 16-byte magic string ('SQLite format 3\\000') at offset 0. 100-byte file header contains: page size, write version (rollback=1, WAL=2), encoding, and change counter. Key forensic recovery mechanisms: (1) Freelist — deleted pages retained in a free-page list; records survive until overwritten by new insertions. (2) Freeblocks and page slack space — deleted records within active pages may survive in freeblocks or partially in the unallocated area below the live cell pointer array. (3) WAL (Write-Ahead Log) — in WAL mode, the -wal file contains uncommitted and recently checkpointed pages; must be analysed alongside the main DB. WAL slack: after checkpoint, old pages remain in the WAL until overwritten from the start — prior database states are recoverable. CRITICAL: opening a WAL-mode database with a standard SQLite driver triggers a checkpoint, irreversibly committing and clearing the WAL — use read-only forensic tools or low-level parsing only. sqlite_sequence table gaps reveal deleted AUTOINCREMENT rows.", "signatures": [ { "offset": 0, "hex": "53514C69746520666F726D6174203300", "length": 16, "description": "SQLite magic string ('SQLite format 3\\x00')" } ], "extensions": [ ".db", ".sqlite", ".sqlite3", ".db3" ], "links": [ { "label": "SQLite file format specification", "url": "https://www.sqlite.org/fileformat.html" }, { "label": "Mobile Forensics – The File Format Handbook: SQLite (Springer, 2022)", "url": "https://doi.org/10.1007/978-3-030-98467-0_5" }, { "label": "Forensic analysis of SQLite databases: free lists, WAL, unallocated space and carving (Belkasoft)", "url": "https://belkasoft.com/sqlite-analysis" }, { "label": "Forensic examination of SQLite Write Ahead Log files (Sanderson Forensics)", "url": "https://sqliteforensictoolkit.com/forensic-examination-of-sqlite-write-ahead-log-wal-files/" }, { "label": "FQLite — deleted SQLite record recovery (Pawlaszczyk; see 'Making the Invisible Visible', 2021)", "url": "https://github.com/pawlaszczyk/fqlite" }, { "label": "A comprehensive analysis and evaluation of SQLite deleted record recovery techniques: a survey (Lee et al., FSI: Digital Investigation 2025)", "url": "https://www.sciencedirect.com/science/article/abs/pii/S2666281725001714" }, { "label": "What Hides in the WAL — SQLite Forensics with crush (beBinary)", "url": "https://bebinary4n6.blogspot.com/2026/05/what-hides-in-wal-sqlite-forensics-with.html" } ] }, { "slug": "sqlite-journal", "url": "https://kalink0.github.io/crush-forensics/formats/sqlite-journal/", "name": "SQLite Rollback Journal", "short_name": "SQLite Journal", "category": "database", "platforms": [ "Windows", "macOS", "Linux", "iOS", "Android", "QNX" ], "parser_class": "SQLiteJournalParser", "crush_support": "Supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "Legacy (pre-WAL) companion file for a SQLite database in DELETE/TRUNCATE/PERSIST journal_mode. Holds the pre-transaction content of every page a still-open or crash-interrupted transaction touched, so SQLite can roll back an incomplete write on next open. Unlike -wal, this is the *old* page content, not the current one — forensically it means the opposite: the base database file's current on-disk pages for a hot journal's page numbers are the interrupted, never-committed write, and the journal itself holds what a proper rollback restores. A journal file present but with a zeroed/invalid header (PERSIST mode keeps the file after every commit but zeroes its header) is stale, not hot — it must not be rolled back, but the page records after the zeroed header may still hold older page versions until the next transaction overwrites them. Header (documented in the SQLite file format specification): 8-byte magic (d9 d5 05 f9 20 a1 63 d7), page-record count, checksum nonce, pre-transaction database size in pages, sector size, page size, then zero or more (page number + page content + checksum) records, possibly repeated across multiple header segments. Deleted rows and unallocated slack within a journaled page are recoverable the same way as in a live database page (freeblock chain, page-content-area gap).", "signatures": [ { "offset": 0, "hex": "D9D505F920A163D7", "length": 8, "description": "SQLite rollback-journal magic" } ], "extensions": [ "-journal", ".db-journal" ], "links": [ { "label": "SQLite rollback journal format (SQLite file format specification, section 4.1)", "url": "https://www.sqlite.org/fileformat2.html#rollbackjournal" }, { "label": "SQLite journal_mode pragma (DELETE, TRUNCATE, PERSIST, MEMORY)", "url": "https://www.sqlite.org/pragma.html#pragma_journal_mode" }, { "label": "SQLite file format specification (main database, for page-level context)", "url": "https://www.sqlite.org/fileformat.html" }, { "label": "What Hides in the WAL — SQLite Forensics with crush (beBinary)", "url": "https://bebinary4n6.blogspot.com/2026/05/what-hides-in-wal-sqlite-forensics-with.html" } ] }, { "slug": "sqlite-wal", "url": "https://kalink0.github.io/crush-forensics/formats/sqlite-wal/", "name": "SQLite WAL", "short_name": "SQLite WAL", "category": "database", "platforms": [ "Windows", "macOS", "Linux", "iOS", "Android", "QNX" ], "parser_class": "SQLiteWALParser", "crush_support": "Supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "Write-Ahead Log companion file for SQLite databases in WAL journal mode. Contains uncommitted database pages and, after checkpoint, WAL slack — old page versions that persist until overwritten from the start of the file. Must be analysed alongside the parent database file using the same schema. CRITICAL: opening the parent database with a standard SQLite driver triggers a checkpoint, committing and clearing the WAL — use read-only forensic tools only. Without the companion database, frames can still be decoded, but column names are only available from the schema. See SQLite Database entry for full forensic context.", "signatures": [ { "offset": 0, "hex": "377F0682", "length": 4, "description": "SQLite WAL magic 0x377F0682 (checksums computed little-endian)" }, { "offset": 0, "hex": "377F0683", "length": 4, "description": "SQLite WAL magic 0x377F0683 (checksums computed big-endian)" } ], "extensions": [ "-wal" ], "links": [ { "label": "SQLite WAL file format (SQLite file format specification, section 4)", "url": "https://www.sqlite.org/fileformat2.html#walformat" }, { "label": "SQLite WAL-mode file format — WAL-index and locking", "url": "https://www.sqlite.org/walformat.html" }, { "label": "Forensic examination of SQLite Write Ahead Log files (Sanderson Forensics)", "url": "https://sqliteforensictoolkit.com/forensic-examination-of-sqlite-write-ahead-log-wal-files/" }, { "label": "What Hides in the WAL — SQLite Forensics with crush (beBinary)", "url": "https://bebinary4n6.blogspot.com/2026/05/what-hides-in-wal-sqlite-forensics-with.html" } ] }, { "slug": "wmi-repository", "url": "https://kalink0.github.io/crush-forensics/formats/wmi-repository/", "name": "WMI Repository (CIM)", "short_name": "WMI repository", "category": "database", "platforms": [ "Windows" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-05", "forensic_relevance": "The Common Information Model repository of Windows Management Instrumentation in %SystemRoot%\\System32\\wbem\\Repository\\ (Windows Vista and later): INDEX.BTR (index B-tree), OBJECTS.DATA (object records) and MAPPING1–3.MAP (mapping of logical to physical pages), with 8192-byte pages. The repository stores class definitions and instances, including event filters, consumers and bindings used for WMI-based persistence. Unreferenced pages in OBJECTS.DATA can retain deleted objects. Mapping files start with the signature 0x0000ABCD.", "signatures": [ { "offset": 0, "hex": "CDAB0000", "length": 4, "description": "Mapping file header signature 0x0000ABCD (MAPPING*.MAP)" } ], "extensions": [], "links": [ { "label": "WMI repository file format (libyal/dtformats)", "url": "https://github.com/libyal/dtformats/blob/main/documentation/WMI%20repository%20file%20format.asciidoc" } ] }, { "slug": "registry-hive", "url": "https://kalink0.github.io/crush-forensics/formats/registry-hive/", "name": "Windows Registry Hive", "short_name": "Registry Hive", "category": "database", "platforms": [ "Windows" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "Windows hierarchical configuration database stored as binary hive files. Key forensic hives: SYSTEM (C:\\Windows\\System32\\config\\SYSTEM) — boot config, services, USB device history (USBSTOR), network interfaces, ShimCache, timezone; SOFTWARE — installed programs, Windows version, run keys, scheduled tasks; SAM — local account metadata, login counts, last login timestamps; NTUSER.DAT (%USERPROFILE%) — UserAssist (GUI execution with run counts and timestamps, ROT-13 encoded), RecentDocs MRU, TypedPaths, ShellBags, OpenSaveMRU, persistence run keys; UsrClass.dat — ShellBags for non-desktop folders, MUICache; Amcache.hve (C:\\Windows\\AppCompat\\Programs\\) — SHA-1 hashes and timestamps of programs present or executed on the system (an entry alone does not prove execution — corroborate with other artifacts). Each key has a LastWriteTime (Windows FILETIME: 100-nanosecond intervals since 1601-01-01 UTC). Transaction logs (.LOG1/.LOG2) contain uncommitted changes not yet written to the primary hive — must be merged for complete analysis. Deleted keys may survive in hive slack space.", "signatures": [ { "offset": 0, "hex": "72656766", "length": 4, "description": "Registry hive signature ('regf')" } ], "extensions": [ ".dat", ".hve", ".log1", ".log2" ], "links": [ { "label": "Windows Registry hive format specification (Maxim Suhanov)", "url": "https://github.com/msuhanov/regf/blob/master/Windows%20registry%20file%20format%20specification.md" }, { "label": "Investigating Windows Registry (ElcomSoft, Oleg Afonin, 2026)", "url": "https://blog.elcomsoft.com/2026/02/investigating-windows-registry/" }, { "label": "AmCache Analysis (ANSSI, Blanche Lagny, 2019)", "url": "https://www.ssi.gouv.fr/publication/amcache-analysis/" }, { "label": "Windows Registry (ForensicsWiki)", "url": "https://forensics.wiki/windows_registry/" }, { "label": "Registry Explorer and RECmd (Eric Zimmerman tools)", "url": "https://ericzimmerman.github.io/#!index.md" } ] }, { "slug": "thumbcache", "url": "https://kalink0.github.io/crush-forensics/formats/thumbcache/", "name": "Windows Thumbnail Cache", "short_name": "Thumbcache", "category": "database", "platforms": [ "Windows" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "Explorer's thumbnail databases (thumbcache_*.db with an index file thumbcache_idx.db under %LOCALAPPDATA%\\Microsoft\\Windows\\Explorer\\, Windows Vista to Windows 11). Each entry holds a thumbnail image keyed by a cache ID but no file name; the original path can be recovered by matching the ThumbnailCacheId against the Windows Search index. Thumbnails can remain after the original pictures, videos or documents were deleted or were on a removable or network drive.", "signatures": [ { "offset": 0, "hex": "434D4D4D", "length": 4, "description": "Cache file signature 'CMMM'" }, { "offset": 0, "hex": "494D4D4D", "length": 4, "description": "Index file signature 'IMMM'" } ], "extensions": [ ".db" ], "links": [ { "label": "Windows Explorer Thumbnail Cache database format (libyal/libwtcdb)", "url": "https://github.com/libyal/libwtcdb/blob/main/documentation/Windows%20Explorer%20Thumbnail%20Cache%20database%20format.asciidoc" }, { "label": "ForensicsWiki — Windows thumbcache", "url": "https://forensics.wiki/windows_thumbcache/" } ] }, { "slug": "kych", "url": "https://kalink0.github.io/crush-forensics/formats/kych/", "name": "macOS Keychain (file-based)", "short_name": "kych", "category": "database", "platforms": [ "macOS" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-05", "forensic_relevance": "The legacy file-based macOS Keychain format used by files such as login.keychain-db and System.keychain. The file starts with the ASCII signature 'kych' and contains a CSSM-style database with tables for keychain items such as generic and internet passwords, certificates and cryptographic keys. Many item attributes, including account, service/server information and metadata, are stored separately from the protected secret data. Secret data is encrypted (3DES-CBC) with item keys wrapped by a database key, which is protected by a master key derived from the keychain password (PBKDF2-HMAC-SHA1); System.keychain is unlocked via /var/db/SystemKey. For forensic analysis, the database can contain credentials, certificates, private keys and other authentication material, while metadata can remain useful even when secrets cannot be decrypted. This file-based format is distinct from the SQLite-based data protection keychain (for example keychain-2.db), which uses a different implementation and format.", "signatures": [ { "offset": 0, "hex": "6B796368", "length": 4, "description": "Signature 'kych'" } ], "extensions": [ ".keychain", ".keychain-db" ], "links": [ { "label": "MacOS keychain database file format (libyal/dtformats)", "url": "https://github.com/libyal/dtformats/blob/main/documentation/MacOS%20keychain%20database%20file%20format.asciidoc" }, { "label": "chainbreaker — macOS keychain forensic tool (n0fate)", "url": "https://github.com/n0fate/chainbreaker" } ] }, { "slug": "aff", "url": "https://kalink0.github.io/crush-forensics/formats/aff/", "name": "AFF Acquisition", "short_name": "AFF", "category": "disk_image", "platforms": [ "Windows", "macOS", "Linux", "iOS", "Android", "QNX" ], "parser_class": "RawImageVFS", "crush_support": "Supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "Advanced Forensic Format (AFF) — an open disk acquisition format from AFFLIB, written by tools such as affconvert and FTK Imager. The disk is stored in compressed pages beside named metadata segments, which can hold the acquisition's own MD5/SHA1 of the disk and a count of bad sectors. AFF can be encrypted. An AFD is the same acquisition split over several .aff files in a folder whose name ends in .afd; an AFM keeps the metadata in an AFF file and the disk data in a separate raw file. A page the acquisition declares but doesn't hold reads as the image's bad-sector marker, not as data from the device. AFF4, the later successor, is a different format.", "signatures": [ { "offset": 0, "hex": "41464631300D0A00", "length": 8, "description": "AFF signature ('AFF10' + control bytes), in every file of an AFD" } ], "extensions": [ ".aff", ".afm" ], "links": [ { "label": "Advanced Forensics Format (Forensics Wiki)", "url": "https://forensics.wiki/aff/" }, { "label": "AFFLIB — the reference implementation", "url": "https://github.com/sshock/AFFLIBv3" }, { "label": "abrignoni/ewfprobe — pure-Python reader for EWF (E01, S01, Ex01, L01), AFF/AFF4, AD1 and virtual/Apple disk images", "url": "https://github.com/abrignoni/ewfprobe" } ] }, { "slug": "aff4", "url": "https://kalink0.github.io/crush-forensics/formats/aff4/", "name": "AFF4 Acquisition", "short_name": "AFF4", "category": "disk_image", "platforms": [ "Windows", "macOS", "Linux", "iOS", "Android", "QNX" ], "parser_class": "RawImageVFS", "crush_support": "Supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "Advanced Forensic Format 4 — an acquisition format stored as a ZIP64 container. The acquired data is held in compressed, chunked image streams, mapped onto the source's address space by map streams, with RDF metadata (information.turtle) describing source, acquisition and streams; the volume URI (aff4://...) is in the ZIP comment and in container.description. A container can be striped across several .aff4 files. Stores hashes of streams, chunks, maps and of the whole source, so the acquisition can be verified. Used for disk images and for memory acquisitions: sparse maps represent physical memory with gaps, and the metadata category (e.g. aff4:category memory/physical) tells which one an image holds. Variants: encrypted AFF4 and AFF4-L for logical evidence.", "signatures": [ { "offset": null, "hex": "616666343A2F2F", "length": 7, "description": "A ZIP whose comment holds the aff4:// volume URI, or whose first member is container.description" } ], "extensions": [ ".aff4" ], "links": [ { "label": "AFF4 Standard (aff4/Standard)", "url": "https://github.com/aff4/Standard" }, { "label": "pyaff4 — the AFF4 reference implementation", "url": "https://github.com/aff4/pyaff4" }, { "label": "ForensicsWiki — Advanced Forensic Framework 4 (AFF4)", "url": "https://forensics.wiki/aff4/" }, { "label": "Cohen, Garfinkel, Schatz — Extending the Advanced Forensic Format to accommodate Multiple Data Sources, Logical Evidence, Arbitrary Information and Forensic Workflow (DFRWS 2009)", "url": "https://dfrws.org/presentation/extending-the-advanced-forensic-format-to-accommodate-multiple-data-sources-logical-evidence-arbitrary-information-and-forensic-workflow/" }, { "label": "Schatz — AFF4-L: A scalable open logical evidence container (DFRWS 2019)", "url": "https://dfrws.org/presentation/aff4-l-a-scalable-open-logical-evidence-container/" }, { "label": "The AFF4 Imager — documentation (incl. memory acquisition)", "url": "https://aff4-imager.readthedocs.io/en/latest/" }, { "label": "abrignoni/ewfprobe — pure-Python reader for EWF (E01, S01, Ex01, L01), AFF/AFF4, AD1 and virtual/Apple disk images", "url": "https://github.com/abrignoni/ewfprobe" } ] }, { "slug": "adcrypt", "url": "https://kalink0.github.io/crush-forensics/formats/adcrypt/", "name": "AccessData AD Encryption (ADCRYPT)", "short_name": "ADCRYPT", "category": "disk_image", "platforms": [ "Windows", "macOS", "Linux", "iOS", "Android", "QNX" ], "parser_class": "RawImageVFS", "crush_support": "Supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "The encryption wrapper FTK Imager can put around an acquisition (raw or E01 segments, or an AD1 logical image). Each encrypted file starts with an 'ADCRYPT' header in a small unencrypted chunk; the content is AES-encrypted and opened with the password or the RSA private key (certificate) chosen at acquisition time.", "signatures": [ { "offset": 0, "hex": "4144435259505400", "length": 8, "description": "AD encryption header 'ADCRYPT'" } ], "extensions": [], "links": [ { "label": "PRONOM fmt/843 — AccessData Custom Content Image (Encrypted)", "url": "https://www.nationalarchives.gov.uk/PRONOM/fmt/843" }, { "label": "abrignoni/ewfprobe — pure-Python reader for EWF (E01, S01, Ex01, L01), AFF/AFF4, AD1 and virtual/Apple disk images", "url": "https://github.com/abrignoni/ewfprobe" } ] }, { "slug": "boot-image", "url": "https://kalink0.github.io/crush-forensics/formats/boot-image/", "name": "Android Boot Image", "short_name": "Boot image", "category": "disk_image", "platforms": [ "Android" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-05", "forensic_relevance": "Android boot partition images (boot, recovery, init_boot, vendor_boot) consisting of a header followed by page-aligned kernel, ramdisk and, depending on the header version, further components. Header versions 0-2 (up to Android 10) can contain a second-stage loader, recovery DTBO (v1+) and DTB (v2); version 3 (Android 11) moves DTB and vendor ramdisk to the separate vendor_boot image ('VNDRBOOT'); version 4 (Android 12) adds a boot signature. The header contains the kernel command line and an OS version/security patch level field, which is zero on Android 13+ GKI devices. Boot images reveal the kernel and early init configuration a device boots with and can show modifications such as patched ramdisks used for rooting. On A/B devices, images exist per slot (_a/_b).", "signatures": [ { "offset": 0, "hex": "414E44524F494421", "length": 8, "description": "Boot image magic 'ANDROID!'" }, { "offset": 0, "hex": "564E4452424F4F54", "length": 8, "description": "Vendor boot image magic 'VNDRBOOT'" } ], "extensions": [], "links": [ { "label": "Boot image header (Android Open Source Project)", "url": "https://source.android.com/docs/core/architecture/bootloader/boot-image-header" }, { "label": "bootimg.h (AOSP mkbootimg source)", "url": "https://android.googlesource.com/platform/system/tools/mkbootimg/+/refs/heads/main/include/bootimg/bootimg.h" } ] }, { "slug": "simg", "url": "https://kalink0.github.io/crush-forensics/formats/simg/", "name": "Android Sparse Image", "short_name": "simg", "category": "disk_image", "platforms": [ "Android" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "Android's space-efficient flash image format that replaces empty and repetitive blocks with metadata chunks, reducing image size for transmission and fastboot flashing. Used in factory images (Google, Samsung, OEM), OTA update packages, and custom ROM distributions. 28-byte header (magic 0xED26FF3A) specifies block size (typically 4096 bytes), total output blocks, and chunk count. Four chunk types: RAW (data), FILL (repeated 4-byte pattern), DONT_CARE (empty/unwritten blocks), and CRC32 (checksum). Must be converted to raw (e.g. ext4/f2fs) before mounting or forensic analysis. Large images are sometimes split into multiple sparse chunks that must be reassembled before conversion. Forensically relevant as the delivery container for Android system partitions (system.img, vendor.img, product.img) — useful for comparing suspect device partitions against factory baselines.", "signatures": [ { "offset": 0, "hex": "3AFF26ED", "length": 4, "description": "Android sparse image magic (0xED26FF3A little-endian)" } ], "extensions": [ ".img", ".simg" ], "links": [ { "label": "Android sparse image format (libsparse — AOSP source)", "url": "https://android.googlesource.com/platform/system/core/+/refs/heads/main/libsparse/" }, { "label": "Android sparse image format explained (2net.co.uk, csimmonds, 2014)", "url": "https://2net.co.uk/tutorial/android-sparse-image-format" }, { "label": "Formal sparse format specification (Kaitai Struct)", "url": "https://formats.kaitai.io/android_sparse/" }, { "label": "simg2img — standalone converter (anestisb/android-simg2img)", "url": "https://github.com/anestisb/android-simg2img" } ] }, { "slug": "vbmeta", "url": "https://kalink0.github.io/crush-forensics/formats/vbmeta/", "name": "Android Verified Boot Metadata (vbmeta)", "short_name": "vbmeta", "category": "disk_image", "platforms": [ "Android" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-05", "forensic_relevance": "Signed metadata of Android Verified Boot 2.0, stored in the vbmeta partition or embedded in other partitions, which then carry a 64-byte 'AVBf' footer at their end. The vbmeta image contains the rollback index, flags, the public key and descriptors (hash, hashtree, chain partition and property descriptors) with the expected digests of the verified partitions. Flags such as disabled hashtree or disabled verification indicate a modified boot chain, as commonly set on unlocked or rooted devices.", "signatures": [ { "offset": 0, "hex": "41564230", "length": 4, "description": "vbmeta image magic 'AVB0'" }, { "offset": null, "hex": "41564266", "length": 4, "description": "Footer magic 'AVBf' in the last 64 bytes of a partition with embedded vbmeta" } ], "extensions": [], "links": [ { "label": "Android Verified Boot 2.0 README (AOSP)", "url": "https://android.googlesource.com/platform/external/avb/+/refs/heads/main/README.md" } ] }, { "slug": "dmg", "url": "https://kalink0.github.io/crush-forensics/formats/dmg/", "name": "Apple Disk Image (DMG)", "short_name": "DMG", "category": "disk_image", "platforms": [ "macOS" ], "parser_class": "RawImageVFS", "crush_support": "Supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "Apple disk image format. A UDIF image consists of data blocks (raw or compressed with ADC, zlib, bzip2, LZFSE or LZMA), an XML property list holding the block map, and a 512-byte 'koly' trailer at EOF instead of a file header; raw images can lack the trailer. Typically contains an HFS+, APFS, FAT32 or ExFAT filesystem. Can be AES-128 or AES-256 encrypted with a password or a certificate; an encrypted image begins 'encrcdsa' (version 2) or ends with 'cdsaencr' (version 1), and the 'koly' trailer is then inside the encrypted data. Variants: segmented UDIF (.dmgpart), sparse image (.sparseimage, header 'sprs', blocks allocated as written), sparse bundle (.sparsebundle, a folder of band files). Common as a software installer (Downloads folders), as user-created encrypted containers, as the storage of Time Machine backups to network destinations (sparse bundle), and as a preferred acquisition format for macOS devices (SWGDE).", "signatures": [ { "offset": null, "hex": "6B6F6C79", "length": 4, "description": "UDIF 'koly' trailer block at EOF-512 (no file header magic)" }, { "offset": 0, "hex": "656E637263647361", "length": 8, "description": "Encrypted disk image, version 2 header" }, { "offset": null, "hex": "63647361656E6372", "length": 8, "description": "Encrypted disk image, version 1 marker in the last 8 bytes" }, { "offset": 0, "hex": "73707273", "length": 4, "description": "Sparse image (.sparseimage) header" } ], "extensions": [ ".dmg", ".sparseimage", ".sparsebundle" ], "links": [ { "label": "Mac OS disk image types — format documentation (libyal/libmodi)", "url": "https://github.com/libyal/libmodi/blob/main/documentation/Mac%20OS%20disk%20image%20types.asciidoc" }, { "label": "DMG format reverse-engineered (newosxbook.com)", "url": "https://newosxbook.com/DMG.html" }, { "label": "Encrypted DMG header versions — dmg2john (John the Ripper)", "url": "https://github.com/openwall/john/blob/bleeding-jumbo/run/dmg2john.py" }, { "label": "Apple Disk Image (Wikipedia — UDIF structure)", "url": "https://en.wikipedia.org/wiki/Apple_Disk_Image" }, { "label": "ForensicsWiki — DMG", "url": "https://forensics.wiki/dmg/" }, { "label": "SWGDE Best Practices macOS Forensic Acquisition", "url": "https://www.swgde.org/documents/published-complete-listing/23-f-005-swgde-best-practices-apple-macos-forensic-acquisition/" } ] }, { "slug": "ewf", "url": "https://kalink0.github.io/crush-forensics/formats/ewf/", "name": "EWF Acquisition", "short_name": "EWF", "category": "disk_image", "platforms": [ "Windows", "macOS", "Linux", "iOS", "Android", "QNX" ], "parser_class": "RawImageVFS", "crush_support": "Supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "Expert Witness Format (EWF) — the .E01 forensic disk image format written and read by many acquisition tools (EnCase, FTK Imager, ewfacquire/libewf, X-Ways, and others). EWF-E01 (version 1) is reportedly based on ASR Data's earlier Expert Witness Compression Format; EnCase itself was originally named 'Expert Witness' before a trademark dispute with ASR Data over that name. Typically the primary evidence file in a case: a bit-for-bit physical or logical disk acquisition, stored as one or more numbered segments (.E01, .E02, ...), optionally compressed and hashed at acquisition time. This EWF-E01 (version 1) format is the one EnCase 6/7 and FTK Imager write and by far the most common in the field. SMART (.s01) acquisitions carry the same signature and are read the same way; the newer EWF2 (.Ex01) and the logical .L01 variant have entries of their own. The acquisition stores its own MD5/SHA1 of the media in a dedicated hash section, written by the acquisition tool — recomputing and comparing against it verifies the acquisition has not been altered since it was made, independent of any chain-of-custody paperwork.", "signatures": [ { "offset": 0, "hex": "455646090D0AFF00", "length": 8, "description": "EWF-E01 / SMART signature ('EVF' + control bytes)" } ], "extensions": [ ".e01", ".s01" ], "links": [ { "label": "EnCase image file format — history and format versions (Forensics Wiki)", "url": "https://forensics.wiki/encase_image_file_format/" }, { "label": "Expert Witness Compression Format (EWF) — libewf project", "url": "https://github.com/libyal/libewf/blob/main/documentation/Expert%20Witness%20Compression%20Format%20(EWF).asciidoc" }, { "label": "abrignoni/ewfprobe — pure-Python reader for EWF (E01, S01, Ex01, L01), AFF/AFF4, AD1 and virtual/Apple disk images", "url": "https://github.com/abrignoni/ewfprobe" }, { "label": "abrignoni/qnxprobe — filesystem reader (QNX, ext, F2FS, FAT, exFAT, NTFS, HFS+, APFS) used alongside ewfprobe", "url": "https://github.com/abrignoni/qnxprobe" } ] }, { "slug": "ex01", "url": "https://kalink0.github.io/crush-forensics/formats/ex01/", "name": "EWF2 Acquisition", "short_name": "Ex01", "category": "disk_image", "platforms": [ "Windows", "macOS", "Linux", "iOS", "Android", "QNX" ], "parser_class": "RawImageVFS", "crush_support": "Supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "EWF2 (.Ex01) — the second version of the Expert Witness Format, introduced with EnCase 7. Like EWF-E01 it holds a bit-for-bit disk acquisition in numbered segments (.Ex01, .Ex02, ...), compressed in chunks, with the MD5/SHA1 the acquisition tool computed stored alongside; recomputing and comparing against it verifies the acquisition has not been altered since it was made. EnCase can also encrypt an Ex01 (AES-256); the encryption scheme is not publicly documented.", "signatures": [ { "offset": 0, "hex": "455646320D0A8100", "length": 8, "description": "EWF2 signature ('EVF2' + control bytes)" } ], "extensions": [ ".ex01" ], "links": [ { "label": "EWF2 format specification — libewf project", "url": "https://github.com/libyal/libewf/blob/main/documentation/Expert%20Witness%20Compression%20Format%202%20(EWF2).asciidoc" }, { "label": "abrignoni/ewfprobe — pure-Python reader for EWF (E01, S01, Ex01, L01), AFF/AFF4, AD1 and virtual/Apple disk images", "url": "https://github.com/abrignoni/ewfprobe" } ] }, { "slug": "iso", "url": "https://kalink0.github.io/crush-forensics/formats/iso/", "name": "ISO 9660 Optical Disc Image", "short_name": "ISO", "category": "disk_image", "platforms": [ "Windows", "macOS", "Linux" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-05", "forensic_relevance": "The CD/DVD filesystem image format, also used to deliver software and malware (mounted by a double-click on Windows); on older Windows versions, files inside mounted images did not inherit the Mark-of-the-Web, which made the format popular for phishing. Volume descriptors from sector 16 on carry the volume name, creating application and separate creation, modification, expiration and effective dates including a time zone offset (in 15-minute steps); Joliet and Rock Ridge extensions add long names and Unix attributes. UDF images may coexist in the same file. Raw images with 2352-byte sectors (.bin/.cue) store the signature at a different offset.", "signatures": [ { "offset": 32769, "hex": "4344303031", "length": 5, "description": "Volume descriptor identifier 'CD001' (sector 16)" } ], "extensions": [ ".iso" ], "links": [ { "label": "ECMA-119 — Volume and File Structure of CDROM (Ecma International)", "url": "https://ecma-international.org/publications-and-standards/standards/ecma-119/" } ] }, { "slug": "vhd", "url": "https://kalink0.github.io/crush-forensics/formats/vhd/", "name": "Microsoft Virtual Hard Disk (VHD)", "short_name": "VHD", "category": "disk_image", "platforms": [ "Windows" ], "parser_class": "RawImageVFS", "crush_support": "Supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "Virtual Hard Disk — a 512-byte footer starting 'conectix' at the end of the file describes the disk. Three types: fixed (the disk's bytes followed by the footer), dynamic (a copy of the footer at offset 0, a dynamic header and a block allocation table; blocks are allocated as written) and differencing (holds only the blocks changed since a parent VHD; the disk's content spans both files). Older Virtual PC versions split a VHD on FAT32 volumes into .v01, .v02 … files. Used by Virtual PC, early Hyper-V, Windows disk management and Windows Backup images. Mounts with a double-click since Windows 8 and is used as a container to deliver malware past Mark-of-the-Web (MITRE ATT&CK T1553.005).", "signatures": [ { "offset": null, "hex": "636F6E6563746978", "length": 8, "description": "Footer cookie 'conectix' in the last 512 bytes" }, { "offset": 0, "hex": "636F6E6563746978", "length": 8, "description": "Copy of the footer at offset 0, in a dynamic or differencing VHD" } ], "extensions": [ ".vhd", ".avhd" ], "links": [ { "label": "Virtual Hard Disk (VHD) image format — format documentation (libyal/libvhdi)", "url": "https://github.com/libyal/libvhdi/blob/main/documentation/Virtual%20Hard%20Disk%20(VHD)%20image%20format.asciidoc" }, { "label": "Unsplitting a split virtual hard disk (Microsoft, Virtual PC Guy)", "url": "https://learn.microsoft.com/en-us/archive/blogs/virtual_pc_guy/unsplitting-a-split-virtual-hard-disk" }, { "label": "ForensicsWiki — Virtual Hard Disk (VHD)", "url": "https://forensics.wiki/virtual_hard_disk_(vhd)/" }, { "label": "MITRE ATT&CK T1553.005 — Mark-of-the-Web Bypass", "url": "https://attack.mitre.org/techniques/T1553/005/" }, { "label": "abrignoni/ewfprobe — pure-Python reader for EWF (E01, S01, Ex01, L01), AFF/AFF4, AD1 and virtual/Apple disk images", "url": "https://github.com/abrignoni/ewfprobe" } ] }, { "slug": "vhdx", "url": "https://kalink0.github.io/crush-forensics/formats/vhdx/", "name": "Microsoft Virtual Hard Disk v2 (VHDX)", "short_name": "VHDX", "category": "disk_image", "platforms": [ "Windows" ], "parser_class": "RawImageVFS", "crush_support": "Supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "Virtual Hard Disk v2 — the successor of VHD. Begins with the file type identifier 'vhdxfile', followed by two redundant headers, a log for crash consistency, a block allocation table and a metadata region. Fixed, dynamic and differencing disks as in VHD; a differencing disk holds only the blocks changed since its parent. Used by Hyper-V, Windows disk management and backup products. WSL 2 stores each Linux distribution as ext4.vhdx under %LOCALAPPDATA%\\Packages\\…\\LocalState\\, and Docker Desktop stores its data in a VHDX, so a Windows host can hold complete Linux filesystems. Mounts with a double-click and is used to deliver malware past Mark-of-the-Web.", "signatures": [ { "offset": 0, "hex": "7668647866696C65", "length": 8, "description": "VHDX file type identifier 'vhdxfile'" } ], "extensions": [ ".vhdx", ".avhdx" ], "links": [ { "label": "[MS-VHDX]: Virtual Hard Disk v2 (VHDX) File Format (Microsoft)", "url": "https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-vhdx/" }, { "label": "Virtual Hard Disk version 2 (VHDX) image format — format documentation (libyal/libvhdi)", "url": "https://github.com/libyal/libvhdi/blob/main/documentation/Virtual%20Hard%20Disk%20version%202%20(VHDX)%20image%20format.asciidoc" }, { "label": "MITRE ATT&CK T1553.005 — Mark-of-the-Web Bypass", "url": "https://attack.mitre.org/techniques/T1553/005/" }, { "label": "abrignoni/ewfprobe — pure-Python reader for EWF (E01, S01, Ex01, L01), AFF/AFF4, AD1 and virtual/Apple disk images", "url": "https://github.com/abrignoni/ewfprobe" } ] }, { "slug": "qcow", "url": "https://kalink0.github.io/crush-forensics/formats/qcow/", "name": "QEMU Copy-On-Write Disk (QCOW)", "short_name": "QCOW", "category": "disk_image", "platforms": [ "Windows", "macOS", "Linux", "iOS", "Android", "QNX" ], "parser_class": "RawImageVFS", "crush_support": "Supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "QEMU Copy-On-Write disk (QCOW version 1, QCOW2 versions 2 and 3). Begins 'QFI' 0xFB and the version, followed by a header, a two-level cluster table (L1/L2) and refcount tables. Clusters are allocated as written and can be compressed; an image can hold internal snapshots, keep its data in an external file, or be an overlay of a backing file, so the disk's content spans both files. Can be encrypted with LUKS or QEMU's older AES. Used by KVM/libvirt, Proxmox, OpenStack and GNS3, and by the Android Emulator, which keeps a virtual device's user data as a QCOW2 overlay (userdata-qemu.img.qcow2).", "signatures": [ { "offset": 0, "hex": "514649FB", "length": 4, "description": "QCOW magic 'QFI' 0xFB, followed by the version (1, 2 or 3)" } ], "extensions": [ ".qcow", ".qcow2" ], "links": [ { "label": "The QCOW2 Image Format (QEMU docs/interop/qcow2.rst)", "url": "https://www.qemu.org/docs/master/interop/qcow2.html" }, { "label": "QEMU Copy-On-Write file format — format documentation (libyal/libqcow)", "url": "https://github.com/libyal/libqcow/blob/main/documentation/QEMU%20Copy-On-Write%20file%20format.asciidoc" }, { "label": "ForensicsWiki — QCOW image format", "url": "https://forensics.wiki/qcow_image_format/" }, { "label": "abrignoni/ewfprobe — pure-Python reader for EWF (E01, S01, Ex01, L01), AFF/AFF4, AD1 and virtual/Apple disk images", "url": "https://github.com/abrignoni/ewfprobe" } ] }, { "slug": "raw", "url": "https://kalink0.github.io/crush-forensics/formats/raw/", "name": "Raw Disk Image", "short_name": "Raw", "category": "disk_image", "platforms": [ "Windows", "macOS", "Linux", "iOS", "Android", "QNX" ], "parser_class": "RawImageVFS", "crush_support": "Supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "A sector-for-sector copy of a disk, partition or flash chip with no container around it: no header, no metadata, no hash, no compression. Often split into numbered segments (.001, .002, … or other schemes such as .aa, .ab, …) that join into one stream. Everything the device held is in it, including unallocated space and slack; how and when it was acquired is only recorded outside the image.", "signatures": [], "extensions": [ ".dd", ".raw", ".img", ".001" ], "links": [ { "label": "ForensicsWiki — Raw image format", "url": "https://forensics.wiki/raw_image_format/" }, { "label": "SWGDE Best Practices for Computer Forensic Acquisitions (17-F-002, v2.0) — raw vs. container formats", "url": "https://www.swgde.org/wp-content/uploads/2024/03/2023-06-15-SWGDE-Best-Practices-for-Computer-Forensic-Acquisitions-17-F-002-2.0.pdf" }, { "label": "dd (Unix) (Wikipedia)", "url": "https://en.wikipedia.org/wiki/Dd_(Unix)" }, { "label": "abrignoni/qnxprobe — MBR/GPT, LVM2 and filesystem reader for raw images (QNX6/QNX4, ETFS, EFS, ext2/3/4, F2FS, FAT32/16/12, exFAT, NTFS, HFS+, APFS, QNX IFS, SquashFS, JFFS2, UBI/UBIFS, YAFFS)", "url": "https://github.com/abrignoni/qnxprobe" } ] }, { "slug": "vmdk", "url": "https://kalink0.github.io/crush-forensics/formats/vmdk/", "name": "VMware Virtual Disk (VMDK)", "short_name": "VMDK", "category": "disk_image", "platforms": [ "Windows", "macOS", "Linux", "iOS", "Android", "QNX" ], "parser_class": "RawImageVFS", "crush_support": "Supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "VMware virtual disk. A disk is a text descriptor ('# Disk DescriptorFile') naming one or more extents — sparse ('KDMV', older ESX 'COWD'), stream-optimized (compressed, as in OVA/OVF exports), flat (the disk's bytes as they are) or SESPARSE — embedded in the descriptor's file or stored beside it, often split into 2 GB pieces. A snapshot is a delta disk holding only what changed since its parent; the disk's content spans the chain. Used by VMware Workstation, Fusion and ESXi, and by VirtualBox. Snapshots and suspended VMs come with .vmem and .vmsn files beside the disk that hold the VM's memory.", "signatures": [ { "offset": 0, "hex": "4B444D56", "length": 4, "description": "Sparse extent magic 'KDMV'" }, { "offset": 0, "hex": "434F5744", "length": 4, "description": "Older ESX sparse (COWD) extent" }, { "offset": 0, "hex": "23204469736B2044657363726970746F7246696C65", "length": 21, "description": "Standalone VMDK descriptor file" } ], "extensions": [ ".vmdk" ], "links": [ { "label": "VMware Virtual Disk Format (VMDK) — format documentation (libyal/libvmdk)", "url": "https://github.com/libyal/libvmdk/blob/main/documentation/VMWare%20Virtual%20Disk%20Format%20(VMDK).asciidoc" }, { "label": "ForensicsWiki — VMware Virtual Disk Format (VMDK)", "url": "https://forensics.wiki/vmware_virtual_disk_format_(vmdk)/" }, { "label": "abrignoni/ewfprobe — pure-Python reader for EWF (E01, S01, Ex01, L01), AFF/AFF4, AD1 and virtual/Apple disk images", "url": "https://github.com/abrignoni/ewfprobe" } ] }, { "slug": "vdi", "url": "https://kalink0.github.io/crush-forensics/formats/vdi/", "name": "VirtualBox Disk Image (VDI)", "short_name": "VDI", "category": "disk_image", "platforms": [ "Windows", "macOS", "Linux" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-05", "forensic_relevance": "Virtual disk format of Oracle VirtualBox. A 64-byte text header (e.g. '<<< Oracle VM VirtualBox Disk Image >>>', older 'innotek' or 'Sun' variants) is followed by the signature and a header with image type, disk geometry, a block map and the UUIDs of the image, its last snapshot, link and parent. Dynamic images only allocate blocks that were written; snapshots are stored as differencing images that reference their parent by UUID, so a complete disk state may require the whole image chain.", "signatures": [ { "offset": 0, "hex": "3C3C3C20", "length": 4, "description": "Start of the text header '<<< … VirtualBox Disk Image >>>'" }, { "offset": 64, "hex": "7F10DABE", "length": 4, "description": "Image signature 0xBEDA107F (little-endian)" } ], "extensions": [ ".vdi" ], "links": [ { "label": "QEMU VDI block driver (source with header layout)", "url": "https://github.com/qemu/qemu/blob/master/block/vdi.c" } ] }, { "slug": "emlx", "url": "https://kalink0.github.io/crush-forensics/formats/emlx/", "name": "Apple Mail Message (EMLX)", "short_name": "EMLX", "category": "document", "platforms": [ "macOS" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-05", "forensic_relevance": "Apple Mail's per-message storage on macOS, typically below ~/Library/Mail/V/ in the Messages subfolders of .mbox mailbox directories, with numeric file names. A file starts with a line holding a decimal byte count, followed by the message in RFC 5322 / MIME form and an XML property list with Apple Mail metadata such as flags (read, replied/forwarded, flagged, junk) and the receipt date. '.partial.emlx' files hold messages whose attachments are stored separately in an Attachments folder. No signature; recognised by the byte count line and the trailing property list.", "signatures": [], "extensions": [ ".emlx" ], "links": [ { "label": "Apple Mail Email Format (EMLX) (Library of Congress)", "url": "https://www.loc.gov/preservation/digital/formats/fdd/fdd000615.shtml" } ] }, { "slug": "eml", "url": "https://kalink0.github.io/crush-forensics/formats/eml/", "name": "E-mail Message (EML / RFC 5322)", "short_name": "EML", "category": "document", "platforms": [ "Windows", "macOS", "Linux", "iOS", "Android", "QNX" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-05", "forensic_relevance": "A single e-mail message as text: header fields (From, To, Date, Subject, Message-ID) and the Received chain, which records each server that handled the message with time and addresses (newest on top; only entries added by trusted servers are reliable, lower entries can be forged), followed by the MIME body and attachments. Authentication results (SPF, DKIM, DMARC) in the headers help judge whether a message is genuine. No signature; recognised by its header lines.", "signatures": [], "extensions": [ ".eml" ], "links": [ { "label": "Internet Message Format (RFC 5322)", "url": "https://www.rfc-editor.org/rfc/rfc5322.html" } ] }, { "slug": "mbox", "url": "https://kalink0.github.io/crush-forensics/formats/mbox/", "name": "Mbox Mailbox", "short_name": "mbox", "category": "document", "platforms": [ "Windows", "macOS", "Linux", "iOS", "Android", "QNX" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-05", "forensic_relevance": "A mailbox stored as one text file of concatenated e-mail messages, each starting with a 'From ' separator line (sender and UTC date). Used by Thunderbird (folder files without extension, e.g. 'Inbox', 'Sent'), Apple Mail exports (.mbox package containing an 'mbox' file), Google Takeout and Unix mail spools. Variants (mboxo, mboxrd, mboxcl, mboxcl2) differ in how body lines starting with 'From ' are escaped ('>From ') or whether Content-Length headers delimit messages; mboxo escaping is irreversible. Messages deleted in the client can remain in the file until it is compacted.", "signatures": [ { "offset": 0, "hex": "46726F6D20", "length": 5, "description": "Separator line 'From '" } ], "extensions": [ ".mbox", ".mbx" ], "links": [ { "label": "The application/mbox Media Type (RFC 4155)", "url": "https://www.rfc-editor.org/rfc/rfc4155.html" }, { "label": "ForensicsWiki — Mbox", "url": "https://forensics.wiki/mbox/" } ] }, { "slug": "cfb", "url": "https://kalink0.github.io/crush-forensics/formats/cfb/", "name": "OLE Compound File (CFB)", "short_name": "CFB", "category": "document", "platforms": [ "Windows", "macOS", "Linux", "iOS", "Android", "QNX" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "Microsoft's Compound File Binary format: a FAT-like filesystem inside one file with storages and streams. It is the container of legacy Office documents (.doc, .xls, .ppt), Outlook .msg messages, Thumbs.db, Jump Lists, MSI installers and many application files. The SummaryInformation streams carry author, last saved by, creation and edit times; unallocated sectors can keep data of earlier versions.", "signatures": [ { "offset": 0, "hex": "D0CF11E0A1B11AE1", "length": 8, "description": "Compound file signature D0 CF 11 E0 A1 B1 1A E1" }, { "offset": 0, "hex": "0E11FC0DD0CF110E", "length": 8, "description": "Signature of early beta OLE2 compound files" } ], "extensions": [ ".doc", ".xls", ".ppt", ".msg", ".msi" ], "links": [ { "label": "[MS-CFB]: Compound File Binary File Format, v12.0 (Microsoft)", "url": "https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-cfb/53989ce4-7b05-4f8d-829b-d08d6148375b" }, { "label": "OLE Compound File format (libyal/libolecf)", "url": "https://github.com/libyal/libolecf/blob/main/documentation/OLE%20Compound%20File%20format.asciidoc" } ] }, { "slug": "onenote", "url": "https://kalink0.github.io/crush-forensics/formats/onenote/", "name": "OneNote Revision Store (ONE)", "short_name": "OneNote", "category": "document", "platforms": [ "Windows", "macOS" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-05", "forensic_relevance": "The OneNote revision store format of section files (.one) and table-of-contents files (.onetoc2). The header identifies the file type and format by GUIDs; content is stored as revisions of object spaces, so earlier page versions and removed content can remain in the file. Sections can embed arbitrary files, which has also been used to deliver malware via OneNote attachments.", "signatures": [ { "offset": 0, "hex": "E4525C7B8CD8A74DAEB15378D02996D3", "length": 16, "description": "guidFileType {7B5C52E4-D88C-4DA7-AEB1-5378D02996D3} (.one section)" }, { "offset": 0, "hex": "A12FFF43D9EF764C9EE210EA5722765F", "length": 16, "description": "guidFileType {43FF2FA1-EFD9-4C76-9EE2-10EA5722765F} (.onetoc2)" }, { "offset": 48, "hex": "3FDD9A101B91F549A5D01791EDC8AED8", "length": 16, "description": "guidFileFormat {109ADD3F-911B-49F5-A5D0-1791EDC8AED8}" } ], "extensions": [ ".one", ".onetoc2" ], "links": [ { "label": "[MS-ONESTORE]: OneNote Revision Store File Format (Microsoft)", "url": "https://learn.microsoft.com/en-us/openspecs/office_file_formats/ms-onestore/ae670cd2-4b38-4b24-82d1-87cfb2cc3725" }, { "label": "pyOneNote — header GUIDs (DissectMalware)", "url": "https://github.com/DissectMalware/pyOneNote/blob/main/pyOneNote/Header.py" } ] }, { "slug": "msg", "url": "https://kalink0.github.io/crush-forensics/formats/msg/", "name": "Outlook Item (MSG)", "short_name": "MSG", "category": "document", "platforms": [ "Windows" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-05", "forensic_relevance": "A single Outlook item (e-mail, appointment, contact, task) stored in a Compound File Binary container. Properties are stored as streams named '__substg1.0_' and in a '__properties_version1.0' stream; recipients and attachments are kept in sub-storages, embedded items as nested storages. Messages contain sender, recipients, subject, body (plain text, compressed RTF and/or HTML) and timestamps such as submit, delivery, creation and last modification time; received mail usually retains the original transport headers including the Received chain. The file carries the CFB signature and is identified by its stream names.", "signatures": [ { "offset": null, "hex": "D0CF11E0A1B11AE1", "length": 8, "description": "CFB signature at offset 0 (shared with all CFB files); identified by '__substg1.0_' / '__properties_version1.0' stream names" } ], "extensions": [ ".msg" ], "links": [ { "label": "[MS-OXMSG]: Outlook Item (.msg) File Format (Microsoft)", "url": "https://learn.microsoft.com/en-us/openspecs/exchange_server_protocols/ms-oxmsg/b046868c-9fbf-41ae-9ffb-8de2bd4eec82" } ] }, { "slug": "pdf", "url": "https://kalink0.github.io/crush-forensics/formats/pdf/", "name": "PDF Document", "short_name": "PDF", "category": "document", "platforms": [ "Windows", "macOS", "Linux", "iOS", "Android", "QNX" ], "parser_class": "PDFParser", "crush_support": "Supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "Portable Document Format — used pervasively for official documents, reports, forms, contracts, and communications. Two metadata layers: DocInfo dictionary (Author, Title, Creator, Producer, CreationDate, ModDate in D:YYYYMMDDHHmmSSOHH'mm' format including timezone) and XMP stream (richer, XML-based, with InstanceID, DocumentID, history). Creator identifies the authoring application (Word, LibreOffice, InDesign); Producer identifies the PDF engine (Acrobat, Ghostscript, pdfTeX) — mismatch between claimed document origin and Creator/Producer is a key fraud indicator (e.g. Creator: Canva on a bank statement). Incremental updates append new cross-reference tables (xref) without overwriting — each save event is preserved and recoverable. xref count > 1 indicates the document was saved multiple times — except in linearized ('Fast Web View') files, which have two xref sections from the start; this structural record is harder to falsify than metadata fields. Earlier content versions (pre-redaction text, prior dates) may be recoverable from superseded objects in the same file. Can embed files, JavaScript (malware vector), digital signatures, and hidden layers (Optional Content Groups). Absent metadata on institutional documents is itself a fraud indicator.", "signatures": [ { "offset": 0, "hex": "255044462D", "length": 5, "description": "PDF header ('%PDF-')" } ], "extensions": [ ".pdf" ], "links": [ { "label": "ISO 32000-2:2020 — PDF 2.0 specification (free via PDF Association)", "url": "https://pdfa.org/resource/iso-32000-2/" }, { "label": "PDF metadata forensics — field-by-field reference (HTPBE, 2026)", "url": "https://htpbe.tech/blog/pdf-metadata-fields-complete-reference" }, { "label": "PDF forensics and XMP metadata streams (Meridian Discovery)", "url": "https://www.meridiandiscovery.com/articles/pdf-forensic-analysis-xmp-metadata/" }, { "label": "PDF forensics and the metadata conundrum (PDF Association, Cherie Ekholm, 2025)", "url": "https://pdfa.org/presentation/pdf-forensics-and-the-metadata-conundrum/" }, { "label": "ExifTool — PDF metadata extraction", "url": "https://exiftool.org/" } ] }, { "slug": "ical", "url": "https://kalink0.github.io/crush-forensics/formats/ical/", "name": "iCalendar", "short_name": "iCal", "category": "document", "platforms": [ "Windows", "macOS", "Linux", "iOS", "Android", "QNX" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-05", "forensic_relevance": "Text format for calendar data used for calendar exports, invitations sent as e-mail attachments and synchronisation. A VCALENDAR object contains events, to-dos, journal entries and alarms with start/end times, location, description, organizer and attendees, time zone definitions (TZID) and change tracking timestamps (DTSTAMP, CREATED, LAST-MODIFIED). Times may be given in UTC, with a time zone reference or as floating local time, which must be considered when building timelines.", "signatures": [ { "offset": 0, "hex": "424547494E3A5643414C454E444152", "length": 15, "description": "Start line 'BEGIN:VCALENDAR' (may be preceded by a byte order mark)" } ], "extensions": [ ".ics", ".ical", ".ifb" ], "links": [ { "label": "Internet Calendaring and Scheduling Core Object Specification (RFC 5545)", "url": "https://www.rfc-editor.org/rfc/rfc5545.html" } ] }, { "slug": "vcard", "url": "https://kalink0.github.io/crush-forensics/formats/vcard/", "name": "vCard Contact", "short_name": "vCard", "category": "document", "platforms": [ "Windows", "macOS", "Linux", "iOS", "Android", "QNX" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-05", "forensic_relevance": "Text format for contact data (versions 2.1, 3.0 and 4.0), used for contact exports and synchronisation by phones, mail clients and address books. A file can contain many contacts, each between BEGIN:VCARD and END:VCARD, with names, phone numbers, e-mail and postal addresses, organisation, notes, embedded photos (PHOTO) and optionally a last revision time (REV). Exports can preserve contacts that were later deleted on the device.", "signatures": [ { "offset": 0, "hex": "424547494E3A5643415244", "length": 11, "description": "Start line 'BEGIN:VCARD' (may be preceded by a byte order mark)" } ], "extensions": [ ".vcf", ".vcard" ], "links": [ { "label": "vCard Format Specification (RFC 6350)", "url": "https://www.rfc-editor.org/rfc/rfc6350.html" } ] }, { "slug": "dex", "url": "https://kalink0.github.io/crush-forensics/formats/dex/", "name": "Android DEX Bytecode", "short_name": "DEX", "category": "execution", "platforms": [ "Android" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "Compiled Android application bytecode executed by the Android Runtime (ART). Found as classes.dex (and classes2.dex, classes3.dex in multi-DEX apps) inside APK packages, which are ZIP archives. Decompilation can recover app logic, hardcoded API keys, credentials, server endpoints, and encryption keys. OAT/ODEX/VDEX companions show the app was compiled for the device; they do not by themselves prove it was executed (preinstalled apps are compiled when the system image is built).", "signatures": [ { "offset": 0, "hex": "6465780A", "length": 4, "description": "DEX magic ('dex\\n'), followed by a 3-digit version and NUL" } ], "extensions": [ ".dex" ], "links": [ { "label": "DEX format specification (AOSP)", "url": "https://source.android.com/docs/core/runtime/dex-format" }, { "label": "jadx — DEX to Java decompiler", "url": "https://github.com/skylot/jadx" }, { "label": "apktool — APK reverse engineering", "url": "https://apktool.org/" } ] }, { "slug": "oat-art", "url": "https://kalink0.github.io/crush-forensics/formats/oat-art/", "name": "Android OAT/ART", "short_name": "OAT/ART", "category": "execution", "platforms": [ "Android" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "Android Runtime (ART) ahead-of-time compiled code artifacts introduced with Android 5.0 (Lollipop). Three file types form a triplet per app: .odex/.oat (ELF binary with AOT-compiled native code from dex2oat), .vdex (verified DEX bytecode — contains a copy of the original DEX since Android 8.0), and .art (optional ART heap image for fast startup). Presence of an .odex/.oat file shows the app was compiled for the device; it does not by itself prove execution (preinstalled apps are compiled when the system image is built). Prior to Android 8.0, the OAT file itself contained an embedded DEX copy — useful for recovering app code when the original APK is absent. Stored under /data/app//oat// for user apps, in an oat/ directory next to preinstalled system apps, and in /data/dalvik-cache/. File timestamps of these artifacts indicate when the app was last installed or (re)compiled.", "signatures": [ { "offset": null, "hex": "6F61740A", "length": 4, "description": "OAT header magic inside the ELF 'oatdata' section (.oat/.odex files are ELF binaries)" }, { "offset": 0, "hex": "76646578", "length": 4, "description": "VDEX file magic" }, { "offset": 0, "hex": "6172740A", "length": 4, "description": "ART image file magic" } ], "extensions": [ ".oat", ".odex", ".vdex", ".art" ], "links": [ { "label": "ART configuration and file types (Android AOSP)", "url": "https://source.android.com/docs/core/runtime/configure" }, { "label": "Android OAT/VDEX/DEX/ART formats (LIEF documentation)", "url": "https://lief.re/doc/latest/tutorials/10_android_formats.html" }, { "label": "Android compilation process and binaries (APK, DEX, OAT, ODEX, VDEX, ART)", "url": "https://github.com/connglli/blog-notes/issues/35" } ] }, { "slug": "elf", "url": "https://kalink0.github.io/crush-forensics/formats/elf/", "name": "ELF Executable", "short_name": "ELF", "category": "execution", "platforms": [ "Linux", "Android", "QNX" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "Native executable and shared library format for Android and Linux. On Android, ELF shared libraries (.so) are bundled inside APK packages under lib/ and loaded at runtime via JNI — they often contain hardcoded strings, API endpoints, encryption keys, and security-sensitive logic not visible in DEX bytecode. Malware authors frequently move sensitive code into native libraries precisely because ELF is harder to decompile than DEX. On Linux, ELF binaries reveal installed software and potential implants. Strings extraction is a fast first step; full analysis requires disassembly.", "signatures": [ { "offset": 0, "hex": "7F454C46", "length": 4, "description": "ELF magic number" } ], "extensions": [ ".so", ".elf", ".ko", ".o" ], "links": [ { "label": "System V ABI — generic ELF specification (gABI)", "url": "https://refspecs.linuxfoundation.org/elf/gabi4+/contents.html" }, { "label": "ELF format specification (man page)", "url": "https://man7.org/linux/man-pages/man5/elf.5.html" }, { "label": "Ghidra — open source reverse engineering tool (NSA)", "url": "https://github.com/NationalSecurityAgency/ghidra" }, { "label": "Reversing Android native libraries (HackTricks)", "url": "https://hacktricks.wiki/en/mobile-pentesting/android-app-pentesting/reversing-native-libraries.html" }, { "label": "ELF shared library injection forensics (Ryan O'Neill, 2016)", "url": "https://engineering.backtrace.io/2016-04-14-elf-shared-library-injection-forensics/" } ] }, { "slug": "class", "url": "https://kalink0.github.io/crush-forensics/formats/class/", "name": "Java Class File", "short_name": "class", "category": "execution", "platforms": [ "Windows", "macOS", "Linux" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-05", "forensic_relevance": "Compiled Java bytecode, usually packaged in JAR, WAR or similar ZIP-based archives. The header holds the magic 0xCAFEBABE followed by minor and major version; the major version identifies the targeted Java release (45 = Java 1.0/1.1 … 65 = Java 21). The constant pool contains class, method and string names, which can reveal functionality, embedded URLs or credentials. The magic is shared with Mach-O universal binaries; they are distinguished by the value at offset 4 (a small architecture count in Mach-O, the class file version in Java).", "signatures": [ { "offset": null, "hex": "CAFEBABE", "length": 4, "description": "Magic 0xCAFEBABE at offset 0 (shared with Mach-O universal binaries; major version at offset 6 is 45 or higher)" } ], "extensions": [ ".class" ], "links": [ { "label": "The class File Format (Java Virtual Machine Specification, Java SE 21)", "url": "https://docs.oracle.com/javase/specs/jvms/se21/html/jvms-4.html" }, { "label": "CAFEBABE disambiguation (file/libmagic)", "url": "https://github.com/file/file/blob/master/magic/Magdir/cafebabe" } ] }, { "slug": "mach-o", "url": "https://kalink0.github.io/crush-forensics/formats/mach-o/", "name": "Mach-O Executable", "short_name": "Mach-O", "category": "execution", "platforms": [ "macOS", "iOS" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "Native executable, library, and object format for iOS and macOS. App binaries can be analysed for hardcoded strings, URLs, API endpoints, encryption keys, and embedded credentials. Entitlements (XML embedded via LC_CODE_SIGNATURE) define app sandbox capabilities and permissions — relevant for identifying over-privileged apps or jailbreak bypass attempts. Code signatures link the binary to a developer identity and detect tampering. Fat/Universal Binaries contain multiple architecture slices (e.g. arm64 + x86_64) in a single file, preceded by a fat_header with magic 0xCAFEBABE — the same magic as Java class files, so the following bytes (architecture count vs. class file version) must be checked to tell them apart.", "signatures": [ { "offset": 0, "hex": "CFFAEDFE", "length": 4, "description": "Mach-O 64-bit little-endian (arm64, x86_64) — most common on modern devices" }, { "offset": 0, "hex": "CEFAEDFE", "length": 4, "description": "Mach-O 32-bit little-endian" }, { "offset": 0, "hex": "CAFEBABE", "length": 4, "description": "Fat/Universal Binary — contains multiple architecture slices (same magic as Java class files)" }, { "offset": 0, "hex": "FEEDFACF", "length": 4, "description": "Mach-O 64-bit big-endian" }, { "offset": 0, "hex": "FEEDFACE", "length": 4, "description": "Mach-O 32-bit big-endian" } ], "extensions": [ ".dylib", ".o" ], "links": [ { "label": "Apple mach-o/loader.h (XNU source — header and load command definitions)", "url": "https://github.com/apple-oss-distributions/xnu/blob/main/EXTERNAL_HEADERS/mach-o/loader.h" }, { "label": "Apple developer docs — Mach-O format reference (archived)", "url": "https://developer.apple.com/library/archive/documentation/Performance/Conceptual/CodeFootprint/Articles/MachOOverview.html" }, { "label": "Mach-O ABI reference (GitHub mirror)", "url": "https://github.com/aidansteele/osx-abi-macho-file-format-reference" }, { "label": "Mach-O format overview (Wikipedia)", "url": "https://en.wikipedia.org/wiki/Mach-O" }, { "label": "So Macho — a look at Apple executable files (Hexiosec, Scott Lester, 2020)", "url": "https://hexiosec.com/blog/macho-files/" } ] }, { "slug": "jump-list", "url": "https://kalink0.github.io/crush-forensics/formats/jump-list/", "name": "Windows Jump Lists", "short_name": "Jump List", "category": "execution", "platforms": [ "Windows" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "Per-application lists of recently and frequently used items, keyed by an AppID, stored under %APPDATA%\\Microsoft\\Windows\\Recent\\ in AutomaticDestinations and CustomDestinations. AutomaticDestinations-ms files are OLE compound files holding one LNK stream per item and a DestList stream with access counts, last-access times, pin status and the host name; CustomDestinations-ms files hold categories of LNK records pinned or provided by the application, closed by a footer signature. They persist after the referenced files are gone.", "signatures": [ { "offset": null, "hex": "D0CF11E0A1B11AE1", "length": 8, "description": "OLE compound file signature (AutomaticDestinations-ms); the same bytes start every OLE compound file" }, { "offset": null, "hex": "ABFBBFBA", "length": 4, "description": "CustomDestinations-ms footer signature 0xBABFFBAB at the end of the file" } ], "extensions": [ ".automaticdestinations-ms", ".customdestinations-ms" ], "links": [ { "label": "Jump lists format (libyal/dtformats)", "url": "https://github.com/libyal/dtformats/blob/main/documentation/Jump%20lists%20format.asciidoc" }, { "label": "ForensicsWiki — Jump lists", "url": "https://forensics.wiki/jump_lists/" } ] }, { "slug": "pe", "url": "https://kalink0.github.io/crush-forensics/formats/pe/", "name": "Windows PE Executable", "short_name": "PE", "category": "execution", "platforms": [ "Windows" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "The Portable Executable format of Windows programs and libraries (.exe, .dll, .sys). An MS-DOS stub points to the PE header with the target machine, a link timestamp, section table, imports and exports; resources hold version information (company, product, original file name) and icons. The link timestamp is not always a date: reproducibly built binaries (including Windows 10+ system files) store a hash there, and 0 or 0xFFFFFFFF mean no timestamp. An undocumented Rich header lists the compiler and linker versions used. An Authenticode signature, if present, names the signer. Relevant for malware analysis and for linking a binary to its origin.", "signatures": [ { "offset": 0, "hex": "4D5A", "length": 2, "description": "MS-DOS header 'MZ' (the PE header follows at e_lfanew)" }, { "offset": null, "hex": "50450000", "length": 4, "description": "PE signature at the file offset stored in e_lfanew (0x3C)" } ], "extensions": [ ".exe", ".dll", ".sys", ".scr", ".cpl" ], "links": [ { "label": "PE Format (Microsoft)", "url": "https://learn.microsoft.com/en-us/windows/win32/debug/pe-format" }, { "label": "MZ, PE-COFF executable file format (libyal/libexe)", "url": "https://github.com/libyal/libexe/blob/main/documentation/Executable%20(EXE)%20file%20format.asciidoc" }, { "label": "Why are the module timestamps in Windows 10 so nonsensical? (Raymond Chen, The Old New Thing)", "url": "https://devblogs.microsoft.com/oldnewthing/20180103-00/?p=97705" } ] }, { "slug": "prefetch", "url": "https://kalink0.github.io/crush-forensics/formats/prefetch/", "name": "Windows Prefetch", "short_name": "Prefetch", "category": "execution", "platforms": [ "Windows" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "Windows execution evidence artifacts created when an application is run for the first time from a specific path. Stored under C:\\Windows\\Prefetch\\ as {EXECUTABLE}-{HASH}.pf, where HASH is derived from the executable's full device path (for hosting processes such as svchost.exe or rundll32.exe also from the command line). Enabled by default on Windows workstations; disabled on Windows Server. Each .pf file contains: executable name, run count, up to 8 last execution timestamps (Windows 8+ — earlier versions store 1), list of files and directories accessed in the first 10 seconds of execution, and volume serial number and creation timestamp. Note: actual execution time is approximately 10 seconds before the .pf file's last modification timestamp. Forensically: proves execution even if the original binary was deleted, reveals path from which malware was executed, detects anti-forensic tools (CCleaner, SDelete prefetch entries). Multiple .pf files for the same executable indicate execution from different paths. Since Windows 10 the files are stored compressed in a MAM container (LZXPRESS Huffman); the SCCA header is only visible after decompression. Format reversed by Joachim Metz (libscca); no official public specification.", "signatures": [ { "offset": 0, "hex": "1100000053434341", "length": 8, "description": "Prefetch v17 header (Windows XP/2003)" }, { "offset": 0, "hex": "1700000053434341", "length": 8, "description": "Prefetch v23 header (Windows Vista/7)" }, { "offset": 0, "hex": "1A00000053434341", "length": 8, "description": "Prefetch v26 header (Windows 8.0/8.1)" }, { "offset": 0, "hex": "1E00000053434341", "length": 8, "description": "Prefetch v30 header (Windows 10, decompressed)" }, { "offset": 0, "hex": "1F00000053434341", "length": 8, "description": "Prefetch v31 header (Windows 11, decompressed)" }, { "offset": 0, "hex": "4D414D04", "length": 4, "description": "Compressed prefetch file, MAM container 'MAM\\x04' (Windows 10+)" } ], "extensions": [ ".pf" ], "links": [ { "label": "Windows Prefetch File format spec (libscca — Joachim Metz)", "url": "https://github.com/libyal/libscca/blob/main/documentation/Windows%20Prefetch%20File%20(PF)%20format.asciidoc" }, { "label": "Prefetch forensics — execution evidence (Magnet Forensics)", "url": "https://www.magnetforensics.com/blog/forensic-analysis-of-prefetch-files-in-windows/" }, { "label": "PECmd — Prefetch parser (Eric Zimmerman)", "url": "https://ericzimmerman.github.io/#!index.md" }, { "label": "ForensicsWiki — Prefetch", "url": "https://forensics.wiki/prefetch/" } ] }, { "slug": "lnk", "url": "https://kalink0.github.io/crush-forensics/formats/lnk/", "name": "Windows Shortcut (LNK)", "short_name": "LNK", "category": "execution", "platforms": [ "Windows" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "Windows shell link files, created when files are opened (Recent folder, Office recent items) and inside Jump Lists. They record the target's path, size and MAC times at the moment the link was written, the volume serial number and type, network share names and often, in the distributed link tracker block, the NetBIOS name of the machine and its MAC address (in the version-1 GUIDs). Evidence of files and volumes that may no longer exist.", "signatures": [ { "offset": 0, "hex": "4C0000000114020000000000C000000000000046", "length": 20, "description": "Header size 0x4C and LinkCLSID {00021401-0000-0000-C000-000000000046}" } ], "extensions": [ ".lnk" ], "links": [ { "label": "[MS-SHLLINK]: Shell Link (.LNK) Binary File Format, v10.0 (Microsoft)", "url": "https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-shllink/16cb4ca1-9339-4d0c-a68d-bf1d6cc0f943" }, { "label": "Windows Shortcut File (LNK) format (libyal/liblnk)", "url": "https://github.com/libyal/liblnk/blob/main/documentation/Windows%20Shortcut%20File%20(LNK)%20format.asciidoc" }, { "label": "ForensicsWiki — LNK", "url": "https://forensics.wiki/lnk/" } ] }, { "slug": "super", "url": "https://kalink0.github.io/crush-forensics/formats/super/", "name": "Android Super Partition (Dynamic Partitions)", "short_name": "super", "category": "filesystem", "platforms": [ "Android" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-05", "forensic_relevance": "The 'super' partition of Android devices with dynamic partitions, holding logical partitions such as system, vendor and product (per slot on A/B devices). After 4096 reserved bytes it contains the partition geometry and a backup copy, followed by the partition metadata (with backup copies per slot) describing each logical partition's name, attributes and extents. The metadata is needed to locate and extract the individual partition images. Images from factory or update packages are often stored as Android sparse images and must be expanded first.", "signatures": [ { "offset": 4096, "hex": "67446C61", "length": 4, "description": "Geometry magic 0x616C4467 (after 4096 reserved bytes)" }, { "offset": 12288, "hex": "30504C41", "length": 4, "description": "Primary metadata header magic 0x414C5030 (after geometry and its backup)" } ], "extensions": [], "links": [ { "label": "Dynamic partitions (Android Open Source Project)", "url": "https://source.android.com/docs/core/ota/dynamic_partitions" }, { "label": "liblp metadata_format.h (AOSP, GitHub mirror)", "url": "https://github.com/aosp-mirror/platform_system_core/blob/main/fs_mgr/liblp/include/liblp/metadata_format.h" } ] }, { "slug": "apfs", "url": "https://kalink0.github.io/crush-forensics/formats/apfs/", "name": "Apple File System (APFS)", "short_name": "APFS", "category": "filesystem", "platforms": [ "macOS", "iOS" ], "parser_class": "RawImageVFS", "crush_support": "Supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "Apple's copy-on-write filesystem on iOS 10.3+ and macOS 10.13+. A container holds several volumes sharing one space pool; metadata is kept in B-trees addressed through an object map, and every change is written to new blocks under a new transaction ID. Older checkpoints and superseded tree nodes can therefore remain on disk. Volumes may be encrypted per volume or per file (Data Protection on iOS) and can carry snapshots. Timestamps are nanoseconds since 1970 UTC.", "signatures": [ { "offset": 32, "hex": "4E585342", "length": 4, "description": "Container superblock magic 'NXSB' (block 0)" } ], "extensions": [], "links": [ { "label": "Apple File System Reference (Apple, 2020-06-22)", "url": "https://developer.apple.com/support/downloads/Apple-File-System-Reference.pdf" }, { "label": "Apple File System (APFS) — format documentation (libyal/libfsapfs)", "url": "https://github.com/libyal/libfsapfs/blob/main/documentation/Apple%20File%20System%20(APFS).asciidoc" }, { "label": "Mobile Forensics – The File Format Handbook: APFS (Rune Nordvik, Springer, 2022)", "url": "https://doi.org/10.1007/978-3-030-98467-0_1" }, { "label": "abrignoni/qnxprobe — MBR/GPT, LVM2 and filesystem reader for raw images (QNX6/QNX4, ETFS, EFS, ext2/3/4, F2FS, FAT32/16/12, exFAT, NTFS, HFS+, APFS, QNX IFS, SquashFS, JFFS2, UBI/UBIFS, YAFFS)", "url": "https://github.com/abrignoni/qnxprobe" } ] }, { "slug": "apm", "url": "https://kalink0.github.io/crush-forensics/formats/apm/", "name": "Apple Partition Map (APM)", "short_name": "APM", "category": "filesystem", "platforms": [ "macOS" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-05", "forensic_relevance": "The Apple Partition Map partitioning scheme used by classic Macintosh systems and PowerPC-based Macs, and also encountered on some older Apple media and disk images. The partition map begins with a driver descriptor record in block 0, which also states the block size, followed by partition map entries starting in block 1 (512-byte entries, or 2048-byte entries on media such as CD-ROMs). Each entry contains the partition name, partition type, starting block, partition size and additional metadata. The map describes itself as a partition of type Apple_partition_map; other common partition types include Apple_HFS, Apple_Driver43 and Apple_Free. The partition map is forensically important because it defines the original partition layout and boundaries, allowing individual partitions to be located and interpreted correctly in a disk image, including partitions that may not currently be mounted or recognized by a modern operating system.", "signatures": [ { "offset": null, "hex": "4552", "length": 2, "description": "Driver descriptor signature 'ER' in block 0 (too short to identify on its own)" }, { "offset": 512, "hex": "504D", "length": 2, "description": "Partition map entry signature 'PM' in block 1" }, { "offset": 2048, "hex": "504D", "length": 2, "description": "Partition map entry signature 'PM' in block 1 on 2048-byte block media (e.g. CD-ROM)" }, { "offset": 560, "hex": "4170706C655F706172746974696F6E5F6D6170", "length": 19, "description": "Partition type 'Apple_partition_map' of the first map entry, which describes the map itself" }, { "offset": 2096, "hex": "4170706C655F706172746974696F6E5F6D6170", "length": 19, "description": "Partition type 'Apple_partition_map' of the first map entry on 2048-byte block media" } ], "extensions": [], "links": [ { "label": "Apple Partition Map (APM) (libyal/libvsapm)", "url": "https://github.com/libyal/libvsapm/blob/main/documentation/Apple%20partition%20map%20(APM)%20format.asciidoc" } ] }, { "slug": "bitlocker", "url": "https://kalink0.github.io/crush-forensics/formats/bitlocker/", "name": "BitLocker Drive Encryption", "short_name": "BitLocker", "category": "filesystem", "platforms": [ "Windows" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "Windows full-volume encryption. The volume keeps a boot sector with the '-FVE-FS-' signature (BitLocker To Go on FAT media: 'MSWIN4.1') and three copies of the FVE metadata, which list the key protectors (TPM, PIN, password, recovery password, startup key) and when the volume was encrypted. The rest is ciphertext, except free space on volumes encrypted 'used space only'; without one of the protectors' secrets the files cannot be read — unless protection is suspended or not yet set up, in which case a clear key is stored unprotected on the volume. BitLocker To Go protects removable drives the same way.", "signatures": [ { "offset": 3, "hex": "2D4656452D46532D", "length": 8, "description": "BitLocker signature '-FVE-FS-' in the volume boot sector" }, { "offset": null, "hex": "2D4656452D46532D", "length": 8, "description": "FVE metadata block signature (three copies; also on BitLocker To Go volumes)" } ], "extensions": [], "links": [ { "label": "BitLocker Drive Encryption (BDE) format (libyal/libbde)", "url": "https://github.com/libyal/libbde/blob/main/documentation/BitLocker%20Drive%20Encryption%20(BDE)%20format.asciidoc" }, { "label": "ForensicsWiki — BitLocker disk encryption", "url": "https://forensics.wiki/bitlocker_disk_encryption/" }, { "label": "BitLocker overview (Microsoft)", "url": "https://learn.microsoft.com/en-us/windows/security/operating-system-security/data-protection/bitlocker/" } ] }, { "slug": "btrfs", "url": "https://kalink0.github.io/crush-forensics/formats/btrfs/", "name": "Btrfs", "short_name": "Btrfs", "category": "filesystem", "platforms": [ "Linux" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-05", "forensic_relevance": "A copy-on-write Linux filesystem with subvolumes and snapshots (default on openSUSE and Fedora desktops, Synology NAS). Metadata trees are written to new locations on every transaction, so earlier tree generations and snapshot contents can hold previous versions of files. The superblock additionally keeps four backup roots referencing earlier tree generations, and superblock mirrors exist at 64 MiB and 256 GiB where the device is large enough.", "signatures": [ { "offset": 65600, "hex": "5F42485266535F4D", "length": 8, "description": "Superblock magic '_BHRfS_M' (superblock at 64 KiB)" }, { "offset": null, "hex": "5F42485266535F4D", "length": 8, "description": "Superblock mirror magic at 64 MiB + 0x40 and 256 GiB + 0x40 (if present)" } ], "extensions": [], "links": [ { "label": "On-disk Format (Btrfs documentation)", "url": "https://btrfs.readthedocs.io/en/latest/dev/On-disk-format.html" } ] }, { "slug": "fat12-16", "url": "https://kalink0.github.io/crush-forensics/formats/fat12-16/", "name": "FAT12 / FAT16", "short_name": "FAT12/16", "category": "filesystem", "platforms": [ "Windows", "macOS", "Linux", "iOS", "Android", "QNX" ], "parser_class": "RawImageVFS", "crush_support": "Supported", "status": "reviewed", "last_reviewed": "2026-10-12", "forensic_relevance": "The 12- and 16-bit File Allocation Table variants, found on small volumes, old media, floppy images and some embedded devices. Directory entries have the same layout as on FAT32. The boot sector's filesystem-type string is informational only; per the specification the FAT type is decided by the cluster count.", "signatures": [ { "offset": 54, "hex": "4641543132202020", "length": 8, "description": "Filesystem type string 'FAT12 ' (informational field)" }, { "offset": 54, "hex": "4641543136202020", "length": 8, "description": "Filesystem type string 'FAT16 ' (informational field)" }, { "offset": 54, "hex": "5446415431362020", "length": 8, "description": "Filesystem type string 'TFAT16 ' (informational field; Windows CE transaction-safe FAT)" } ], "extensions": [], "links": [ { "label": "File Allocation Table (FAT) format (libyal/libfsfat)", "url": "https://github.com/libyal/libfsfat/blob/main/documentation/File%20Allocation%20Table%20(FAT)%20format.asciidoc" }, { "label": "ForensicsWiki — FAT", "url": "https://forensics.wiki/fat/" }, { "label": "abrignoni/qnxprobe — MBR/GPT, LVM2 and filesystem reader for raw images (QNX6/QNX4, ETFS, EFS, ext2/3/4, F2FS, FAT32/16/12, exFAT, NTFS, HFS+, APFS, QNX IFS, SquashFS, JFFS2, UBI/UBIFS, YAFFS)", "url": "https://github.com/abrignoni/qnxprobe" } ] }, { "slug": "fat32", "url": "https://kalink0.github.io/crush-forensics/formats/fat32/", "name": "FAT32", "short_name": "FAT32", "category": "filesystem", "platforms": [ "Windows", "macOS", "Linux", "iOS", "Android", "QNX" ], "parser_class": "RawImageVFS", "crush_support": "Supported", "status": "reviewed", "last_reviewed": "2026-10-12", "forensic_relevance": "The 32-bit File Allocation Table filesystem, used on USB sticks, SD cards, camera media, EFI system partitions and Android SD cards. Directory entries hold an 8.3 name (plus long-name entries), attributes, size, first cluster and creation/modification/access times in local time with 10 ms (creation), 2-second (modification) and day (access) resolution. A deleted entry keeps most of its fields with the first name byte set to 0xE5, but the cluster chain in the FAT is cleared, so recovery beyond the first cluster assumes the file was stored contiguously.", "signatures": [ { "offset": 82, "hex": "4641543332202020", "length": 8, "description": "Filesystem type string 'FAT32 ' in the boot sector" }, { "offset": 82, "hex": "5446415433322020", "length": 8, "description": "Filesystem type string 'TFAT32 ' in the boot sector (Windows CE transaction-safe FAT)" } ], "extensions": [], "links": [ { "label": "File Allocation Table (FAT) format (libyal/libfsfat)", "url": "https://github.com/libyal/libfsfat/blob/main/documentation/File%20Allocation%20Table%20(FAT)%20format.asciidoc" }, { "label": "ForensicsWiki — FAT", "url": "https://forensics.wiki/fat/" }, { "label": "abrignoni/qnxprobe — MBR/GPT, LVM2 and filesystem reader for raw images (QNX6/QNX4, ETFS, EFS, ext2/3/4, F2FS, FAT32/16/12, exFAT, NTFS, HFS+, APFS, QNX IFS, SquashFS, JFFS2, UBI/UBIFS, YAFFS)", "url": "https://github.com/abrignoni/qnxprobe" } ] }, { "slug": "f2fs", "url": "https://kalink0.github.io/crush-forensics/formats/f2fs/", "name": "Flash-Friendly File System (F2FS)", "short_name": "F2FS", "category": "filesystem", "platforms": [ "Linux", "Android" ], "parser_class": "RawImageVFS", "crush_support": "Supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "A log-structured filesystem for NAND flash, used as the userdata partition on many Android devices. Data and nodes are written to new segments rather than in place, and checkpoints alternate between two copies, so earlier versions of files and metadata can remain in segments that have not yet been cleaned. Inodes carry access, change, modification and (optionally) creation times.", "signatures": [ { "offset": 1024, "hex": "1020F5F2", "length": 4, "description": "Superblock magic 0xF2F52010 (byte 1024)" } ], "extensions": [], "links": [ { "label": "Flash-Friendly File System (F2FS) (Linux kernel documentation)", "url": "https://docs.kernel.org/filesystems/f2fs.html" }, { "label": "F2FS on-disk structures — include/linux/f2fs_fs.h (Linux kernel source)", "url": "https://github.com/torvalds/linux/blob/master/include/linux/f2fs_fs.h" }, { "label": "Mobile Forensics – The File Format Handbook: The Flash-Friendly File System (F2FS) (Chris Currier, Springer, 2022)", "url": "https://doi.org/10.1007/978-3-030-98467-0_3" }, { "label": "abrignoni/qnxprobe — MBR/GPT, LVM2 and filesystem reader for raw images (QNX6/QNX4, ETFS, EFS, ext2/3/4, F2FS, FAT32/16/12, exFAT, NTFS, HFS+, APFS, QNX IFS, SquashFS, JFFS2, UBI/UBIFS, YAFFS)", "url": "https://github.com/abrignoni/qnxprobe" } ] }, { "slug": "gpt", "url": "https://kalink0.github.io/crush-forensics/formats/gpt/", "name": "GUID Partition Table (GPT)", "short_name": "GPT", "category": "filesystem", "platforms": [ "Windows", "macOS", "Linux", "iOS", "Android", "QNX" ], "parser_class": "RawImageVFS", "crush_support": "Supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "The UEFI partition scheme: a header in the second logical block, a partition entry array with a type GUID, unique GUID, start and end LBA and a UTF-16 name per partition, and a backup copy of both at the end of the disk. Both copies carry CRC32 checksums, so a primary and backup that disagree show the table was changed or damaged. Used by current Windows, macOS, Linux and Android devices; on 4Kn disks the header sits at byte 4096 instead of 512.", "signatures": [ { "offset": 512, "hex": "4546492050415254", "length": 8, "description": "GPT header signature in LBA 1 (512-byte sectors)" }, { "offset": 4096, "hex": "4546492050415254", "length": 8, "description": "GPT header signature in LBA 1 (4096-byte sectors)" } ], "extensions": [], "links": [ { "label": "UEFI Specification 2.10 — GUID Partition Table (GPT) Disk Layout", "url": "https://uefi.org/specs/UEFI/2.10/05_GUID_Partition_Table_Format.html" }, { "label": "GUID Partition Table (GPT) format (libyal/libvsgpt)", "url": "https://github.com/libyal/libvsgpt/blob/main/documentation/GUID%20Partition%20Table%20(GPT)%20format.asciidoc" }, { "label": "ForensicsWiki — GPT", "url": "https://forensics.wiki/gpt/" }, { "label": "abrignoni/qnxprobe — MBR/GPT, LVM2 and filesystem reader for raw images (QNX6/QNX4, ETFS, EFS, ext2/3/4, F2FS, FAT32/16/12, exFAT, NTFS, HFS+, APFS, QNX IFS, SquashFS, JFFS2, UBI/UBIFS, YAFFS)", "url": "https://github.com/abrignoni/qnxprobe" } ] }, { "slug": "hfs", "url": "https://kalink0.github.io/crush-forensics/formats/hfs/", "name": "HFS Plus / HFSX", "short_name": "HFS+", "category": "filesystem", "platforms": [ "macOS", "iOS" ], "parser_class": "RawImageVFS", "crush_support": "Supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "Apple's filesystem before APFS (Mac OS 8.1 to macOS 10.12, on hard disks and Fusion Drives to 10.13, still on many external drives and older Time Machine disks). Files and folders are records in a catalog B-tree, with an extents overflow file and an attributes file for extended attributes and compressed (decmpfs) data. HFSX is the case-sensitive variant, also used by iOS before 10.3. An optional journal records metadata changes. Timestamps are seconds since 1904, local time on the volume header's creation date and UTC elsewhere.", "signatures": [ { "offset": 1024, "hex": "482B0004", "length": 4, "description": "HFS Plus volume header ('H+', version 4)" }, { "offset": 1024, "hex": "48580005", "length": 4, "description": "HFSX volume header ('HX', version 5)" } ], "extensions": [], "links": [ { "label": "Technical Note TN1150: HFS Plus Volume Format (Apple)", "url": "https://developer.apple.com/library/archive/technotes/tn/tn1150.html" }, { "label": "Hierarchical File System (HFS) — format documentation (libyal/libfshfs)", "url": "https://github.com/libyal/libfshfs/blob/main/documentation/Hierarchical%20File%20System%20(HFS).asciidoc" }, { "label": "ForensicsWiki — HFS+", "url": "https://forensics.wiki/hfs+/" }, { "label": "abrignoni/qnxprobe — MBR/GPT, LVM2 and filesystem reader for raw images (QNX6/QNX4, ETFS, EFS, ext2/3/4, F2FS, FAT32/16/12, exFAT, NTFS, HFS+, APFS, QNX IFS, SquashFS, JFFS2, UBI/UBIFS, YAFFS)", "url": "https://github.com/abrignoni/qnxprobe" } ] }, { "slug": "jffs2", "url": "https://kalink0.github.io/crush-forensics/formats/jffs2/", "name": "JFFS2 (Journalling Flash File System v2)", "short_name": "JFFS2", "category": "filesystem", "platforms": [ "Linux" ], "parser_class": "RawImageVFS", "crush_support": "Supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "A log-structured filesystem for raw NOR/NAND flash in embedded Linux devices. The whole filesystem is a sequence of nodes, each with a version number; the newest node for each inode wins, so older nodes holding earlier file contents and names can remain on the flash until garbage collection erases the block.", "signatures": [ { "offset": 0, "hex": "85190320", "length": 4, "description": "Node magic 0x1985 + cleanmarker node 0x2003 (little-endian)" }, { "offset": 0, "hex": "851901E0", "length": 4, "description": "Node magic 0x1985 + directory entry node 0xE001 (little-endian)" }, { "offset": 0, "hex": "851902E0", "length": 4, "description": "Node magic 0x1985 + inode node 0xE002 (little-endian)" }, { "offset": 0, "hex": "19852003", "length": 4, "description": "Node magic 0x1985 + cleanmarker node 0x2003 (big-endian)" }, { "offset": 0, "hex": "1985E001", "length": 4, "description": "Node magic 0x1985 + directory entry node 0xE001 (big-endian)" }, { "offset": 0, "hex": "1985E002", "length": 4, "description": "Node magic 0x1985 + inode node 0xE002 (big-endian)" } ], "extensions": [ ".jffs2" ], "links": [ { "label": "JFFS2 documentation (Linux MTD project)", "url": "http://www.linux-mtd.infradead.org/doc/jffs2.html" }, { "label": "JFFS: The Journalling Flash File System (David Woodhouse, Red Hat)", "url": "https://sourceware.org/jffs2/jffs2.pdf" }, { "label": "JFFS2 on-disk structures — include/uapi/linux/jffs2.h (Linux kernel source)", "url": "https://github.com/torvalds/linux/blob/master/include/uapi/linux/jffs2.h" }, { "label": "ForensicsWiki — JFFS2", "url": "https://forensics.wiki/jffs2/" } ] }, { "slug": "luks", "url": "https://kalink0.github.io/crush-forensics/formats/luks/", "name": "LUKS Encrypted Volume", "short_name": "LUKS", "category": "filesystem", "platforms": [ "Linux" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-05", "forensic_relevance": "Linux Unified Key Setup, the standard Linux disk encryption format. A header with cipher, UUID and up to 8 (LUKS1) or 32 (LUKS2) key slots, each holding the volume key encrypted with a passphrase or key file; LUKS2 adds a JSON metadata area and a secondary header copy. Key slot material is stored using an anti-forensic splitter, so a wiped key slot is practically unrecoverable. The header can also be detached and stored separately; the encrypted volume then shows no signature and appears as random data, and a header backup may be required for decryption. Without a slot's secret the data area is ciphertext.", "signatures": [ { "offset": 0, "hex": "4C554B53BABE", "length": 6, "description": "Primary header magic 'LUKS' 0xBA 0xBE" }, { "offset": 16384, "hex": "534B554CBABE", "length": 6, "description": "LUKS2 secondary header magic 'SKUL' 0xBA 0xBE at default offset 0x4000 (other fixed offsets up to 4 MiB possible)" } ], "extensions": [], "links": [ { "label": "LUKS1 On-Disk Format Specification (cryptsetup)", "url": "https://gitlab.com/cryptsetup/cryptsetup/-/wikis/LUKS-standard/on-disk-format.pdf" }, { "label": "LUKS2 On-Disk Format Specification (cryptsetup)", "url": "https://gitlab.com/cryptsetup/LUKS2-docs/-/raw/main/luks2_doc_wip.pdf" }, { "label": "LUKS Disk Encryption format (libyal/libluksde)", "url": "https://github.com/libyal/libluksde/blob/main/documentation/Linux%20Unified%20Key%20Setup%20(LUKS)%20Disk%20Encryption%20format.asciidoc" }, { "label": "ForensicsWiki — Linux unified key setup (LUKS)", "url": "https://forensics.wiki/linux_unified_key_setup_(luks)/" } ] }, { "slug": "lvm2", "url": "https://kalink0.github.io/crush-forensics/formats/lvm2/", "name": "Linux Logical Volume Manager (LVM2)", "short_name": "LVM2", "category": "filesystem", "platforms": [ "Linux" ], "parser_class": "RawImageVFS", "crush_support": "Supported", "status": "reviewed", "last_reviewed": "2026-10-16", "forensic_relevance": "Linux volume management: a physical volume label in one of the first four sectors (normally the second) points to a text metadata area describing volume groups and logical volumes with their extents. The metadata area keeps earlier versions of the configuration in a ring buffer, so removed or resized logical volumes can be traced. On the host system, further metadata history is kept as text files below /etc/lvm/archive/ and /etc/lvm/backup/, which can reach further back than the on-disk ring buffer.", "signatures": [ { "offset": 512, "hex": "4C4142454C4F4E45", "length": 8, "description": "Physical volume label 'LABELONE' (normally sector 1)" }, { "offset": 536, "hex": "4C564D3220303031", "length": 8, "description": "Label type indicator 'LVM2 001' (offset 24 within the label)" } ], "extensions": [], "links": [ { "label": "LVM format specification (libyal/libvslvm)", "url": "https://github.com/libyal/libvslvm/blob/main/documentation/Logical%20Volume%20Manager%20(LVM)%20format.asciidoc" }, { "label": "abrignoni/qnxprobe — MBR/GPT, LVM2 and filesystem reader for raw images (QNX6/QNX4, ETFS, EFS, ext2/3/4, F2FS, FAT32/16/12, exFAT, NTFS, HFS+, APFS, QNX IFS, SquashFS, JFFS2, UBI/UBIFS, YAFFS)", "url": "https://github.com/abrignoni/qnxprobe" } ] }, { "slug": "mbr", "url": "https://kalink0.github.io/crush-forensics/formats/mbr/", "name": "Master Boot Record (MBR) Partition Table", "short_name": "MBR", "category": "filesystem", "platforms": [ "Windows", "macOS", "Linux", "iOS", "Android", "QNX" ], "parser_class": "RawImageVFS", "crush_support": "Supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "The classic PC partition scheme in the first sector of a disk: boot code, a 4-byte disk signature at offset 440 (used by Windows to map volumes in the MountedDevices registry key), up to four primary partition entries and the 0x55AA boot signature. Further partitions chain through extended boot records. Each entry carries a type byte and a start and length in sectors; space outside every entry (before the first partition, between partitions, after the last) can hold remnants of earlier layouts. A GPT disk keeps a protective MBR with a single 0xEE entry.", "signatures": [ { "offset": 510, "hex": "55AA", "length": 2, "description": "Boot signature 0x55AA at the end of sector 0 (also present in FAT/NTFS boot sectors)" } ], "extensions": [], "links": [ { "label": "Master Boot Record (MBR) partition table format (libyal/libvsmbr)", "url": "https://github.com/libyal/libvsmbr/blob/main/documentation/Master%20Boot%20Record%20(MBR)%20partition%20table%20format.asciidoc" }, { "label": "ForensicsWiki — Master boot record", "url": "https://forensics.wiki/master_boot_record/" }, { "label": "abrignoni/qnxprobe — MBR/GPT, LVM2 and filesystem reader for raw images (QNX6/QNX4, ETFS, EFS, ext2/3/4, F2FS, FAT32/16/12, exFAT, NTFS, HFS+, APFS, QNX IFS, SquashFS, JFFS2, UBI/UBIFS, YAFFS)", "url": "https://github.com/abrignoni/qnxprobe" } ] }, { "slug": "ntfs", "url": "https://kalink0.github.io/crush-forensics/formats/ntfs/", "name": "NTFS", "short_name": "NTFS", "category": "filesystem", "platforms": [ "Windows" ], "parser_class": "RawImageVFS", "crush_support": "Supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "The Windows filesystem. Every file and directory is an entry in the Master File Table ($MFT) with attributes such as $STANDARD_INFORMATION and $FILE_NAME, each holding its own set of four timestamps (100 ns since 1601 UTC); $STANDARD_INFORMATION times can be set through the API, $FILE_NAME times not readily, so comparing both helps detect timestomping. Small files are stored resident inside the MFT entry, and entries of deleted files remain until reused. Metadata files record history — $LogFile (transaction log), $UsnJrnl:$J (change journal) — next to $Secure (security descriptors) and $Bitmap (cluster allocation). Alternate data streams (e.g. Zone.Identifier) and Volume Shadow Copies live on the same volume.", "signatures": [ { "offset": 3, "hex": "4E54465320202020", "length": 8, "description": "OEM identifier 'NTFS ' in the boot sector" } ], "extensions": [], "links": [ { "label": "New Technologies File System (NTFS) — format documentation (libyal/libfsntfs)", "url": "https://github.com/libyal/libfsntfs/blob/main/documentation/New%20Technologies%20File%20System%20(NTFS).asciidoc" }, { "label": "ForensicsWiki — New Technology File System (NTFS)", "url": "https://forensics.wiki/new_technology_file_system_(ntfs)/" }, { "label": "abrignoni/qnxprobe — MBR/GPT, LVM2 and filesystem reader for raw images (QNX6/QNX4, ETFS, EFS, ext2/3/4, F2FS, FAT32/16/12, exFAT, NTFS, HFS+, APFS, QNX IFS, SquashFS, JFFS2, UBI/UBIFS, YAFFS)", "url": "https://github.com/abrignoni/qnxprobe" } ] }, { "slug": "mft", "url": "https://kalink0.github.io/crush-forensics/formats/mft/", "name": "NTFS Master File Table ($MFT)", "short_name": "$MFT", "category": "filesystem", "platforms": [ "Windows" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "The NTFS metadata file holding one 1 KiB (sometimes 4 KiB) record per file and directory, often exported on its own for triage. Each record has the $STANDARD_INFORMATION and $FILE_NAME timestamps, names, parent reference, size and the data runs or resident data. Records of deleted files stay until reused. A stand-alone $MFT contains resident data only; non-resident file content and the rest of the filesystem are not included.", "signatures": [ { "offset": 0, "hex": "46494C453000", "length": 6, "description": "MFT entry signature 'FILE' with fixup offset 0x30 (NTFS 3.1, Windows XP and later)" }, { "offset": 0, "hex": "46494C452A00", "length": 6, "description": "MFT entry signature 'FILE' with fixup offset 0x2A (NTFS 3.0 and earlier)" } ], "extensions": [], "links": [ { "label": "New Technologies File System (NTFS) — format documentation (libyal/libfsntfs)", "url": "https://github.com/libyal/libfsntfs/blob/main/documentation/New%20Technologies%20File%20System%20(NTFS).asciidoc" }, { "label": "ForensicsWiki — $MFT", "url": "https://forensics.wiki/$mft/" } ] }, { "slug": "efs", "url": "https://kalink0.github.io/crush-forensics/formats/efs/", "name": "QNX Embedded Flash Filesystem (EFS / F3S)", "short_name": "EFS", "category": "filesystem", "platforms": [ "QNX" ], "parser_class": "RawImageVFS", "crush_support": "Supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "The QNX flash filesystem for NOR flash (FFS3, fs-flash3). The flash is divided into units holding extents; changes are copy-on-write, with a pointer from an old extent to the one that supersedes it, so older versions can remain readable until the unit is reclaimed. The partition is found by its boot record containing the text 'QSSL_F3S'.", "signatures": [ { "offset": null, "hex": "5153534C5F463353", "length": 8, "description": "Boot record signature 'QSSL_F3S' (offset depends on the unit layout)" } ], "extensions": [], "links": [ { "label": "FFS3 filesystem — QNX SDP 8.0 System Architecture", "url": "https://qnx.com/developers/docs/8.0/com.qnx.doc.neutrino.sys_arch/topic/fsys_FFS3.html" }, { "label": "qnxmount — QNX6, ETFS and EFS parsers (Netherlands Forensic Institute)", "url": "https://github.com/NetherlandsForensicInstitute/qnxmount" }, { "label": "abrignoni/qnxprobe — MBR/GPT, LVM2 and filesystem reader for raw images (QNX6/QNX4, ETFS, EFS, ext2/3/4, F2FS, FAT32/16/12, exFAT, NTFS, HFS+, APFS, QNX IFS, SquashFS, JFFS2, UBI/UBIFS, YAFFS)", "url": "https://github.com/abrignoni/qnxprobe" } ] }, { "slug": "etfs", "url": "https://kalink0.github.io/crush-forensics/formats/etfs/", "name": "QNX Embedded Transaction Filesystem (ETFS)", "short_name": "ETFS", "category": "filesystem", "platforms": [ "QNX" ], "parser_class": "RawImageVFS", "crush_support": "Supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "A transaction-based QNX filesystem for NAND flash. Every write is a new transaction with a sequence number in the page's spare area; the current state is rebuilt by replaying them, so pages holding superseded versions of files can remain until they are reclaimed (background reclaim and wear levelling decide when). It has no magic number: it is recognised by its reserved files (.filetable, .badblks, .counts) at fixed file IDs.", "signatures": [], "extensions": [], "links": [ { "label": "Embedded transaction filesystem (ETFS) — QNX Neutrino System Architecture", "url": "https://www.qnx.com/developers/docs/6.5.0SP1/neutrino/sys_arch/fsys.html" }, { "label": "etfsctl — reserved files .filetable, .badblks, .counts (QNX utilities reference)", "url": "https://www.qnx.com/developers/docs/6.5.0SP1/neutrino/utilities/e/etfsctl.html" }, { "label": "qnxmount — QNX6, ETFS and EFS parsers (Netherlands Forensic Institute)", "url": "https://github.com/NetherlandsForensicInstitute/qnxmount" }, { "label": "abrignoni/qnxprobe — MBR/GPT, LVM2 and filesystem reader for raw images (QNX6/QNX4, ETFS, EFS, ext2/3/4, F2FS, FAT32/16/12, exFAT, NTFS, HFS+, APFS, QNX IFS, SquashFS, JFFS2, UBI/UBIFS, YAFFS)", "url": "https://github.com/abrignoni/qnxprobe" } ] }, { "slug": "qnx-ifs", "url": "https://kalink0.github.io/crush-forensics/formats/qnx-ifs/", "name": "QNX Image Filesystem (IFS)", "short_name": "QNX IFS", "category": "filesystem", "platforms": [ "QNX" ], "parser_class": "RawImageVFS", "crush_support": "Supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "A QNX boot image: a startup header and startup code followed by a read-only image filesystem holding the kernel, drivers, libraries and the build script the system boots with. The image filesystem may be compressed (zlib, LZO or UCL). On x86 a preboot section can precede the startup header. Shows what software and configuration a QNX device was built to start.", "signatures": [ { "offset": 0, "hex": "EB7EFF00", "length": 4, "description": "Startup header signature 0x00FF7EEB (little-endian)" }, { "offset": 0, "hex": "00FF7EEB", "length": 4, "description": "Startup header signature 0x00FF7EEB (big-endian)" }, { "offset": null, "hex": "EB7EFF00", "length": 4, "description": "Startup header after a preboot section (x86 BIOS/UEFI images)" } ], "extensions": [ ".ifs" ], "links": [ { "label": "The startup header (QNX SDP 8.0 — Building Embedded Systems)", "url": "https://www.qnx.com/developers/docs/8.0/com.qnx.doc.neutrino.building/topic/ipl/ipl_startup_header.html" }, { "label": "dumpifs — Dump an image filesystem (QNX SDP 8.0 utilities reference)", "url": "https://qnx.com/developers/docs/8.0/com.qnx.doc.neutrino.utilities/topic/d/dumpifs.html" }, { "label": "abrignoni/qnxprobe — MBR/GPT, LVM2 and filesystem reader for raw images (QNX6/QNX4, ETFS, EFS, ext2/3/4, F2FS, FAT32/16/12, exFAT, NTFS, HFS+, APFS, QNX IFS, SquashFS, JFFS2, UBI/UBIFS, YAFFS)", "url": "https://github.com/abrignoni/qnxprobe" } ] }, { "slug": "qnx4", "url": "https://kalink0.github.io/crush-forensics/formats/qnx4/", "name": "QNX4 Filesystem", "short_name": "QNX4", "category": "filesystem", "platforms": [ "QNX" ], "parser_class": "RawImageVFS", "crush_support": "Supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "The older QNX filesystem, still found in embedded and automotive devices. It has no magic number: a volume is recognised by its root directory entry and the /.bitmap and /.inodes files. Directory entries hold the file's attributes directly; files with several names or long names use the separate .inodes file.", "signatures": [], "extensions": [], "links": [ { "label": "QNX 4 filesystem — root directory and special files (QNX Neutrino User's Guide)", "url": "https://www.qnx.com/developers/docs/6.6.0.update/com.qnx.doc.neutrino.user_guide/topic/lost_data_Root_directory.html" }, { "label": "QNX4 on-disk structures — include/uapi/linux/qnx4_fs.h (Linux kernel source)", "url": "https://github.com/torvalds/linux/blob/master/include/uapi/linux/qnx4_fs.h" }, { "label": "abrignoni/qnxprobe — MBR/GPT, LVM2 and filesystem reader for raw images (QNX6/QNX4, ETFS, EFS, ext2/3/4, F2FS, FAT32/16/12, exFAT, NTFS, HFS+, APFS, QNX IFS, SquashFS, JFFS2, UBI/UBIFS, YAFFS)", "url": "https://github.com/abrignoni/qnxprobe" } ] }, { "slug": "qnx6", "url": "https://kalink0.github.io/crush-forensics/formats/qnx6/", "name": "QNX6 Filesystem", "short_name": "QNX6", "category": "filesystem", "platforms": [ "QNX" ], "parser_class": "RawImageVFS", "crush_support": "Supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "The QNX Neutrino power-safe filesystem, used in vehicle infotainment and telematics units and other embedded systems. Two superblocks alternate; the one with the higher serial number is current, and the other describes the previous state of the filesystem. Inodes and directory blocks are addressed through block pointer trees. Exists in little- and big-endian byte order.", "signatures": [ { "offset": 8192, "hex": "22111968", "length": 4, "description": "Superblock magic 0x68191122 after the 8 KiB boot block (little-endian)" }, { "offset": 8192, "hex": "68191122", "length": 4, "description": "Superblock magic 0x68191122 after the 8 KiB boot block (big-endian)" }, { "offset": 0, "hex": "22111968", "length": 4, "description": "Superblock magic 0x68191122 at byte 0, layouts without boot block, e.g. Audi MMI 3G (little-endian)" }, { "offset": 0, "hex": "68191122", "length": 4, "description": "Superblock magic 0x68191122 at byte 0, layouts without boot block (big-endian)" } ], "extensions": [], "links": [ { "label": "The QNX6 Filesystem (Linux kernel documentation)", "url": "https://docs.kernel.org/filesystems/qnx6.html" }, { "label": "Mobile Forensics – The File Format Handbook: QNX6 (Conrad Meyer, Springer, 2022)", "url": "https://doi.org/10.1007/978-3-030-98467-0_4" }, { "label": "qnxmount — QNX6, ETFS and EFS parsers (Netherlands Forensic Institute)", "url": "https://github.com/NetherlandsForensicInstitute/qnxmount" }, { "label": "abrignoni/qnxprobe — MBR/GPT, LVM2 and filesystem reader for raw images (QNX6/QNX4, ETFS, EFS, ext2/3/4, F2FS, FAT32/16/12, exFAT, NTFS, HFS+, APFS, QNX IFS, SquashFS, JFFS2, UBI/UBIFS, YAFFS)", "url": "https://github.com/abrignoni/qnxprobe" } ] }, { "slug": "refs", "url": "https://kalink0.github.io/crush-forensics/formats/refs/", "name": "Resilient File System (ReFS)", "short_name": "ReFS", "category": "filesystem", "platforms": [ "Windows" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "Microsoft's copy-on-write filesystem for Windows Server and Dev Drives on Windows 11, in two incompatible format generations (1.x from Windows 8/Server 2012, 3.x from Windows 10/Server 2016). Metadata is held in B+ trees that are written to new locations on every change, so older tree pages can remain. Supports integrity streams (checksums) and block cloning.", "signatures": [ { "offset": 3, "hex": "5265465300000000", "length": 8, "description": "File system signature 'ReFS' in the volume boot record" }, { "offset": 16, "hex": "46535253", "length": 4, "description": "File system recognition structure signature 'FSRS'" } ], "extensions": [], "links": [ { "label": "Resilient File System (ReFS) (libyal/libfsrefs)", "url": "https://github.com/libyal/libfsrefs/blob/main/documentation/Resilient%20File%20System%20(ReFS).asciidoc" }, { "label": "ForensicsWiki — Resilient file system (ReFS)", "url": "https://forensics.wiki/resilient_file_system_(refs)/" } ] }, { "slug": "squashfs", "url": "https://kalink0.github.io/crush-forensics/formats/squashfs/", "name": "SquashFS", "short_name": "SquashFS", "category": "filesystem", "platforms": [ "Linux" ], "parser_class": "RawImageVFS", "crush_support": "Supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "A compressed read-only filesystem used for firmware images of routers, IoT devices, set-top boxes and Linux live systems. Inode and directory tables and file data are compressed in blocks; files are stored once and cannot be changed in place, so the image shows the firmware as built. Timestamps are unsigned seconds since 1970: each inode holds only a modification time, and the superblock records when the image was created.", "signatures": [ { "offset": 0, "hex": "68737173", "length": 4, "description": "Superblock magic 'hsqs' (little-endian)" }, { "offset": 0, "hex": "73717368", "length": 4, "description": "Superblock magic 'sqsh' (big-endian, versions before 4.0)" } ], "extensions": [ ".squashfs", ".sqsh" ], "links": [ { "label": "Squashfs 4.0 Filesystem (Linux kernel documentation)", "url": "https://docs.kernel.org/filesystems/squashfs.html" }, { "label": "Squashfs binary format (dr-emann)", "url": "https://dr-emann.github.io/squashfs/" } ] }, { "slug": "ubi", "url": "https://kalink0.github.io/crush-forensics/formats/ubi/", "name": "UBI (Unsorted Block Images)", "short_name": "UBI", "category": "filesystem", "platforms": [ "Linux" ], "parser_class": "RawImageVFS", "crush_support": "Supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "A volume layer on raw NAND flash in embedded Linux devices. Each physical eraseblock starts with an erase-counter header and (once mapped) a volume-ID header that maps it to a logical block of a volume; a volume table, kept twice in an internal layout volume, names the volumes. Eraseblocks that held earlier copies of a logical block can remain until they are erased.", "signatures": [ { "offset": 0, "hex": "55424923", "length": 4, "description": "Erase-counter header magic 'UBI#'" }, { "offset": null, "hex": "55424921", "length": 4, "description": "Volume-ID header magic 'UBI!' (at the VID header offset given in the erase-counter header)" } ], "extensions": [ ".ubi" ], "links": [ { "label": "UBI documentation (Linux MTD project)", "url": "http://www.linux-mtd.infradead.org/doc/ubi.html" }, { "label": "UBI — Unsorted Block Images, design paper (Linux MTD project)", "url": "http://www.linux-mtd.infradead.org/doc/ubidesign/ubidesign.pdf" }, { "label": "UBI on-flash structures — drivers/mtd/ubi/ubi-media.h (Linux kernel source)", "url": "https://github.com/torvalds/linux/blob/master/drivers/mtd/ubi/ubi-media.h" } ] }, { "slug": "ubifs", "url": "https://kalink0.github.io/crush-forensics/formats/ubifs/", "name": "UBIFS", "short_name": "UBIFS", "category": "filesystem", "platforms": [ "Linux" ], "parser_class": "RawImageVFS", "crush_support": "Supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "The flash filesystem that runs on a UBI volume. Nodes are written out of place and indexed by a wandering B+ tree; a journal holds recent changes. Nodes for superseded data can remain in the volume until it is garbage-collected.", "signatures": [ { "offset": 0, "hex": "31181006", "length": 4, "description": "Node magic 0x06101831 (little-endian), superblock node in LEB 0" } ], "extensions": [ ".ubifs" ], "links": [ { "label": "UBIFS documentation (Linux MTD project)", "url": "http://www.linux-mtd.infradead.org/doc/ubifs.html" }, { "label": "A Brief Introduction to the Design of UBIFS (Adrian Hunter, 2008)", "url": "http://www.linux-mtd.infradead.org/doc/ubifs_whitepaper.pdf" }, { "label": "UBIFS on-flash structures — fs/ubifs/ubifs-media.h (Linux kernel source)", "url": "https://github.com/torvalds/linux/blob/master/fs/ubifs/ubifs-media.h" } ] }, { "slug": "veracrypt", "url": "https://kalink0.github.io/crush-forensics/formats/veracrypt/", "name": "VeraCrypt / TrueCrypt Volume", "short_name": "VeraCrypt", "category": "filesystem", "platforms": [ "Windows", "macOS", "Linux" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-05", "forensic_relevance": "Encrypted containers and partitions of VeraCrypt and its predecessor TrueCrypt. The volume header is itself encrypted with a key derived from the password (and optional key files/PIM), so a volume has no signature and is indistinguishable from random data; a hidden volume can sit inside the free space of an outer one. The first 64 bytes hold the salt; a hidden volume's header is located at byte 65536, and backup headers encrypted with a different salt are stored at the end of the volume. Indicators are a size divisible by 512, high entropy throughout and the absence of any file signature.", "signatures": [], "extensions": [ ".hc", ".tc" ], "links": [ { "label": "VeraCrypt Volume Format Specification (VeraCrypt)", "url": "https://veracrypt.io/en/VeraCrypt%20Volume%20Format%20Specification.html" }, { "label": "ForensicsWiki — TrueCrypt", "url": "https://forensics.wiki/truecrypt/" } ] }, { "slug": "vss", "url": "https://kalink0.github.io/crush-forensics/formats/vss/", "name": "Volume Shadow Copy (VSS)", "short_name": "VSS", "category": "filesystem", "platforms": [ "Windows" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "Copy-on-write snapshots of an NTFS volume (System Restore, backups, previous versions). Changed 16 KiB blocks are kept in store files named {GUID}{3808876B-C176-4E48-B7AE-04046E6CC752} under System Volume Information and catalogued from a header at offset 0x1E00 of the volume. Each snapshot presents the volume as it was at its creation time, including files since deleted or changed.", "signatures": [ { "offset": 7680, "hex": "6B87083876C1484EB7AE04046E6CC752", "length": 16, "description": "VSS identifier {3808876B-C176-4E48-B7AE-04046E6CC752} at volume offset 0x1E00" } ], "extensions": [], "links": [ { "label": "Volume Shadow Snapshot (VSS) format (libyal/libvshadow)", "url": "https://github.com/libyal/libvshadow/blob/main/documentation/Volume%20Shadow%20Snapshot%20(VSS)%20format.asciidoc" }, { "label": "ForensicsWiki — Windows shadow volumes", "url": "https://forensics.wiki/windows_shadow_volumes/" } ] }, { "slug": "i", "url": "https://kalink0.github.io/crush-forensics/formats/i/", "name": "Windows Recycle Bin ($I files)", "short_name": "$I", "category": "filesystem", "platforms": [ "Windows" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "For each file moved to the Recycle Bin (Windows Vista and later), $Recycle.Bin\\\\ holds a $R file with the content and a $I file with the original path, size and deletion time. Version 2 (Windows 10 and later) stores the path length; version 1 a fixed 520-byte path. The header is just a version number, not a signature.", "signatures": [], "extensions": [], "links": [ { "label": "Windows Recycle.Bin file formats (libyal/dtformats)", "url": "https://github.com/libyal/dtformats/blob/main/documentation/Windows%20Recycle.Bin%20file%20formats.asciidoc" }, { "label": "Forensic Analysis of the Microsoft Windows Vista Recycle Bin (Mitchell Machor, Forensic Focus, 2008)", "url": "https://www.forensicfocus.com/articles/forensic-analysis-of-the-microsoft-windows-vista-recycle-bin/" } ] }, { "slug": "xfs", "url": "https://kalink0.github.io/crush-forensics/formats/xfs/", "name": "XFS", "short_name": "XFS", "category": "filesystem", "platforms": [ "Linux" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-05", "forensic_relevance": "A journaling filesystem used as the default on Red Hat Enterprise Linux and its derivatives and on many NAS devices. Allocation groups each manage their own inodes and free space through B+ trees; inodes carry nanosecond timestamps and, on v5 filesystems, a creation time. Newer filesystems can use the bigtime feature (Y2038-safe timestamps with a different epoch and encoding), which must be taken into account when interpreting timestamps.", "signatures": [ { "offset": 0, "hex": "58465342", "length": 4, "description": "Superblock signature 'XFSB'" } ], "extensions": [], "links": [ { "label": "X File System (XFS) (libyal/libfsxfs)", "url": "https://github.com/libyal/libfsxfs/blob/main/documentation/X%20File%20System%20(XFS).asciidoc" }, { "label": "ForensicsWiki — XFS", "url": "https://forensics.wiki/xfs/" } ] }, { "slug": "yaffs", "url": "https://kalink0.github.io/crush-forensics/formats/yaffs/", "name": "YAFFS1 / YAFFS2", "short_name": "YAFFS", "category": "filesystem", "platforms": [ "Linux", "Android" ], "parser_class": "RawImageVFS", "crush_support": "Supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "Yet Another Flash File System, used on NAND flash in older Android devices and embedded systems. Each page carries tags in its spare area naming the object and chunk it belongs to; YAFFS2 adds a per-block sequence number (YAFFS1 uses deletion markers and a 2-bit serial number). The newest chunk wins, so earlier versions of files can remain on the flash. It has no magic number and is recognised by its page and spare-area layout.", "signatures": [], "extensions": [ ".yaffs", ".yaffs2" ], "links": [ { "label": "How Yaffs works (Aleph One, yaffs.net)", "url": "https://yaffs.net/node/409" }, { "label": "Forensic Analysis of YAFFS2 (Zimmermann, Spreitzenbarth, Schmitt, Freiling — SICHERHEIT 2012)", "url": "https://dl.gi.de/handle/20.500.12116/18263" } ] }, { "slug": "zfs", "url": "https://kalink0.github.io/crush-forensics/formats/zfs/", "name": "ZFS", "short_name": "ZFS", "category": "filesystem", "platforms": [ "Linux" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-05", "forensic_relevance": "Copy-on-write filesystem and volume manager (OpenZFS), common on NAS and server systems. Each device carries four 256 KiB labels (two at the start, two at the end), each with a name/value list describing the pool and device configuration and a ring of uberblocks pointing to the current and recent transaction groups. Because blocks are never overwritten in place, earlier transaction groups and snapshots can preserve previous file versions. No signature at offset 0; uberblocks are found in the ring starting 128 KiB into each label.", "signatures": [ { "offset": null, "hex": "0CB1BA0000000000", "length": 8, "description": "Uberblock magic 0x00BAB10C (little-endian) in the uberblock ring at 128 KiB into each label" }, { "offset": null, "hex": "0000000000BAB10C", "length": 8, "description": "Uberblock magic 0x00BAB10C (big-endian)" } ], "extensions": [], "links": [ { "label": "uberblock_impl.h (OpenZFS source)", "url": "https://github.com/openzfs/zfs/blob/master/include/sys/uberblock_impl.h" }, { "label": "vdev_impl.h — vdev label layout (OpenZFS source)", "url": "https://github.com/openzfs/zfs/blob/master/include/sys/vdev_impl.h" } ] }, { "slug": "exfat", "url": "https://kalink0.github.io/crush-forensics/formats/exfat/", "name": "exFAT", "short_name": "exFAT", "category": "filesystem", "platforms": [ "Windows", "macOS", "Linux", "iOS", "Android", "QNX" ], "parser_class": "RawImageVFS", "crush_support": "Supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "Microsoft's Extended FAT for flash media: SDXC cards, large USB drives and cameras. Files are described by entry sets (file, stream extension and file name entries) with timestamps that carry 10 ms resolution and a UTC offset. Contiguous files may have no FAT chain at all. A deleted entry set keeps its data with the in-use bit cleared.", "signatures": [ { "offset": 3, "hex": "4558464154202020", "length": 8, "description": "Filesystem name 'EXFAT ' in the boot sector" } ], "extensions": [], "links": [ { "label": "exFAT File System Specification (Microsoft)", "url": "https://learn.microsoft.com/en-us/windows/win32/fileio/exfat-specification" }, { "label": "File Allocation Table (FAT) format, incl. exFAT (libyal/libfsfat)", "url": "https://github.com/libyal/libfsfat/blob/main/documentation/File%20Allocation%20Table%20(FAT)%20format.asciidoc" }, { "label": "abrignoni/qnxprobe — MBR/GPT, LVM2 and filesystem reader for raw images (QNX6/QNX4, ETFS, EFS, ext2/3/4, F2FS, FAT32/16/12, exFAT, NTFS, HFS+, APFS, QNX IFS, SquashFS, JFFS2, UBI/UBIFS, YAFFS)", "url": "https://github.com/abrignoni/qnxprobe" } ] }, { "slug": "ext", "url": "https://kalink0.github.io/crush-forensics/formats/ext/", "name": "ext2 / ext3 / ext4", "short_name": "ext", "category": "filesystem", "platforms": [ "Linux", "Android" ], "parser_class": "RawImageVFS", "crush_support": "Supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "The Linux extended filesystem family, also the data and system partitions of many Android devices. Files are inodes with up to four timestamps (ext4: nanosecond resolution and creation time), block pointers or extents, and directory entries that link names to inode numbers. ext3/ext4 clear a deleted file's block pointers or extents in the inode, but keep a journal whose older copies of metadata blocks can still describe deleted or changed files. The superblock records last mount path, mount and write times.", "signatures": [ { "offset": 1080, "hex": "53EF", "length": 2, "description": "Superblock magic 0xEF53 (superblock at byte 1024)" } ], "extensions": [], "links": [ { "label": "ext4 Data Structures and Algorithms (Linux kernel documentation)", "url": "https://docs.kernel.org/filesystems/ext4/index.html" }, { "label": "Extended File System (EXT) — format documentation (libyal/libfsext)", "url": "https://github.com/libyal/libfsext/blob/main/documentation/Extended%20File%20System%20(EXT).asciidoc" }, { "label": "ForensicsWiki — Extended file system (ext)", "url": "https://forensics.wiki/extended_file_system_(ext)/" }, { "label": "Mobile Forensics – The File Format Handbook: Ext4 (Rune Nordvik, Springer, 2022)", "url": "https://doi.org/10.1007/978-3-030-98467-0_2" }, { "label": "abrignoni/qnxprobe — MBR/GPT, LVM2 and filesystem reader for raw images (QNX6/QNX4, ETFS, EFS, ext2/3/4, F2FS, FAT32/16/12, exFAT, NTFS, HFS+, APFS, QNX IFS, SquashFS, JFFS2, UBI/UBIFS, YAFFS)", "url": "https://github.com/abrignoni/qnxprobe" } ] }, { "slug": "intrusion-log", "url": "https://kalink0.github.io/crush-forensics/formats/intrusion-log/", "name": "Android Intrusion Log (Advanced Protection)", "short_name": "Intrusion Log", "category": "log", "platforms": [ "Android" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-09", "forensic_relevance": "Security event log of Android's Intrusion Logging, an opt-in part of Advanced Protection Mode (Android 16 and later, linked Google account required; at launch in May 2026 on Pixel devices only). Newline-delimited JSON without a signature, one event per line, wrapped under its type: dns_event, connect_event (both with the requesting package) and security_event (SecurityLog API events such as app starts, package installs, ADB commands and file transfers, lock and unlock attempts). event_time is in milliseconds for DNS and connect events, in nanoseconds for security events; event_id is not unique. Logs are collected about daily, end-to-end encrypted and kept in the Google account for 12 months; 'Download and decrypt' writes them to /sdcard/Download/Intrusion Logging/, where earlier downloads remain. Logs of any device on the account can be downloaded on another one, so files found on a device may belong to a different device. Missing events do not prove absence: logging only covers the time it was enabled, may write fewer events under heavy activity and misses DNS lookups done by an app's own resolver (e.g. Chrome's Secure DNS). Overlapping downloads can repeat events. Private browsing modes are logged as well.", "signatures": [], "extensions": [ ".txt" ], "links": [ { "label": "Log your Android device activity with Advanced Protection (Android Help)", "url": "https://support.google.com/android/answer/16927813" }, { "label": "Android Intrusion Logging as a new source of data for consensual forensic analysis (Amnesty International Security Lab, 2026)", "url": "https://securitylab.amnesty.org/latest/2026/05/android-intrusion-logging-as-a-new-source-of-data-for-consensual-forensic-analysis/" }, { "label": "SecurityLog API reference (Android developers)", "url": "https://developer.android.com/reference/android/app/admin/SecurityLog" }, { "label": "NetworkEvent API reference — timestamp in milliseconds (Android developers)", "url": "https://developer.android.com/reference/android/app/admin/NetworkEvent" }, { "label": "SecurityLog.java — event tags (Android Open Source Project)", "url": "https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/app/admin/SecurityLog.java" }, { "label": "Advanced Protection Mode (Android developers)", "url": "https://developer.android.com/privacy-and-security/advanced-protection-mode" }, { "label": "Check Android Intrusion Logs (Mobile Verification Toolkit documentation)", "url": "https://github.com/mvt-project/mvt/blob/main/docs/android/intrusion_logs.md" } ] }, { "slug": "logcat", "url": "https://kalink0.github.io/crush-forensics/formats/logcat/", "name": "Android logcat (text)", "short_name": "logcat", "category": "log", "platforms": [ "Android" ], "parser_class": "LogParser", "crush_support": "Supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "Text output of Android's logcat: one line per log message with date and time (device local time, no year in the default format; other output formats add the year or use UTC or epoch time), PID, TID, priority, tag and message. Found in bug reports, ADB extractions and app support exports. The binary log buffers on the device (main, system, crash, radio, events) are ring buffers, so a capture only reaches back as far as the buffer did.", "signatures": [], "extensions": [ ".txt", ".log" ], "links": [ { "label": "Logcat command-line tool — output formats and buffers (Android developers)", "url": "https://developer.android.com/tools/logcat" }, { "label": "Understand logging — log levels and logging APIs (Android Open Source Project)", "url": "https://source.android.com/docs/core/tests/debug/understanding-logging" } ] }, { "slug": "fsevents", "url": "https://kalink0.github.io/crush-forensics/formats/fsevents/", "name": "Apple File System Events (FSEvents)", "short_name": "FSEvents", "category": "log", "platforms": [ "macOS", "iOS" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-05", "forensic_relevance": "Persistent file system event logs stored in /.fseventsd on macOS volumes and also encountered in forensic extractions from iOS and other Apple devices. Each log file is a multi-member gzip stream; the decompressed data consists of pages starting with a '1SLD' (Mac OS X 10.5 to macOS 10.12), '2SLD' (macOS 10.13 and later) or '3SLD' (macOS 14 and later) signature. The records contain an event ID, path, and event flags such as created, modified, renamed, removed, metadata or permission changes; version 2 records add a file system node ID, version 3 records additionally a user ID. FSEvents are primarily directory/file activity indicators rather than a complete audit trail: events can be coalesced, and an event does not necessarily prove that a file was opened or read. The on-disk event records do not provide a conventional per-record timestamp; forensic timelines therefore require correlation with the log files' file system timestamps and other evidence. Log file names are hexadecimal event IDs that provide ordering, not time. FSEvents can preserve evidence of paths and file system activity after the corresponding files or directories have been deleted or are otherwise no longer present.", "signatures": [ { "offset": null, "hex": "31534C44", "length": 4, "description": "Page signature '1SLD' at offset 0 of the decompressed (gzip) stream" }, { "offset": null, "hex": "32534C44", "length": 4, "description": "Page signature '2SLD' at offset 0 of the decompressed (gzip) stream" }, { "offset": null, "hex": "33534C44", "length": 4, "description": "Page signature '3SLD' at offset 0 of the decompressed (gzip) stream" } ], "extensions": [], "links": [ { "label": "MacOS File System Events Disk Log Stream format (libyal/dtformats)", "url": "https://github.com/libyal/dtformats/blob/main/documentation/MacOS%20File%20System%20Events%20Disk%20Log%20Stream%20format.asciidoc" }, { "label": "FSEventsParser (G-C Partners)", "url": "https://github.com/dlcowen/FSEventsParser" } ] }, { "slug": "segb", "url": "https://kalink0.github.io/crush-forensics/formats/segb/", "name": "Apple SEGB (Biome store)", "short_name": "SEGB", "category": "log", "platforms": [ "macOS", "iOS" ], "parser_class": "SegbParser", "crush_support": "Supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "Apple's Segmented Binary format — the on-disk storage container for iOS and macOS Biome data, which replaced much of KnowledgeC from iOS 16 onwards. Two versions: SEGB v1 (iOS 14-16, 56-byte header ending with 'SEGB' in ASCII, 32-byte record headers with two Mac Absolute Time timestamps) and SEGB v2 (iOS 17+, 32-byte header, entries + trailer section). Each record payload is a protobuf — requiring schema knowledge for full decoding. Current devices hold 300+ Biome stream folders, dozens of them forensically relevant, covering: app focus/usage (replaces KnowledgeC), app installs, Safari history, Siri/AppIntent interactions (may contain deleted iMessages and Snapchat activity), CarPlay connections, notifications, location events, and screen activity. Located at /private/var/mobile/Library/Biome/streams/ and /private/var/db/biome/streams/ — each stream has 'local/' (device) and 'remote/' (iCloud-synced from other devices) subdirectories. Tombstone/ folder contains expired/deleted records — partially recoverable. Filenames are Mac Absolute Time floats (insert decimal 6 places from end). Data survives app deletion and may outlast primary databases.", "signatures": [ { "offset": 0, "hex": "53454742", "length": 4, "description": "SEGB v2 signature at offset 0 (32-byte header)" }, { "offset": 52, "hex": "53454742", "length": 4, "description": "SEGB v1 signature at offset 52 (within 56-byte header)" } ], "extensions": [], "links": [ { "label": "ccl_segb — CCL parser for SEGB v1 and v2", "url": "https://github.com/cclgroupltd/ccl-segb" }, { "label": "iOS 16 Biome breakdown Part 1 — SEGB format (D20 Forensics, 2022)", "url": "https://blog.d204n6.com/2022/09/ios-16-now-you-c-it-now-you-dont.html" }, { "label": "Understanding and decoding the newest iOS SEGB format (Cellebrite, 2023)", "url": "https://cellebrite.com/en/blog/understanding-and-decoding-the-newest-ios-segb-format/" }, { "label": "Analyzing iOS Biome AppIntent files (Blue Crew Forensics, John Hyla, 2022)", "url": "https://bluecrewforensics.com/2022/03/07/ios-app-intents/" }, { "label": "Bringing it back with Biome data (Magnet Forensics, 2023)", "url": "https://www.magnetforensics.com/blog/bringing-it-back-with-biome-data/" }, { "label": "84 Streams Later: Exploring the Evolution of Apple Biome in iOS (Mattia Epifani, 2026)", "url": "https://blog.digital-forensics.it/2026/07/84-streams-later-exploring-evolution-of.html" }, { "label": "Beyond the C — SEGB and Biome Forensics with crush (beBinary)", "url": "https://bebinary4n6.blogspot.com/2026/05/beyond-c-segb-and-biome-forensics-with.html" } ] }, { "slug": "asl", "url": "https://kalink0.github.io/crush-forensics/formats/asl/", "name": "Apple System Log (ASL)", "short_name": "ASL", "category": "log", "platforms": [ "macOS", "iOS" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-05", "forensic_relevance": "The binary Apple System Log database format used by Mac OS X/macOS up to 10.11 and by early iOS versions. On macOS, persistent ASL databases are commonly found below /private/var/log/asl/. Records can contain timestamps, host, sender, facility, process ID, user/group IDs, severity level and message text, together with additional free-form key-value attributes. ASL can preserve valuable historical evidence of system, application and security-related activity, including events that are no longer reflected in the current system state. Retention is controlled by the ASL configuration (/etc/asl.conf and /etc/asl/), which often keeps only a limited period; missing time ranges may therefore reflect rotation rather than inactivity. Starting with macOS 10.12, Apple superseded ASL with the Unified Logging system, although legacy ASL databases and ASL-compatible logging may still be encountered on later systems.", "signatures": [ { "offset": 0, "hex": "41534C204442000000000000", "length": 12, "description": "ASL database signature" } ], "extensions": [ ".asl" ], "links": [ { "label": "Apple System Log (ASL) file format (libyal/dtformats)", "url": "https://github.com/libyal/dtformats/blob/main/documentation/Apple%20System%20Log%20(ASL)%20file%20format.asciidoc" } ] }, { "slug": "tracev3", "url": "https://kalink0.github.io/crush-forensics/formats/tracev3/", "name": "Apple Unified Log (tracev3)", "short_name": "tracev3", "category": "log", "platforms": [ "macOS", "iOS" ], "parser_class": "UnifiedLogConverter", "crush_support": "Supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "Binary log file format used by Apple's Unified Logging System. Individual .tracev3 files are stored under /private/var/db/diagnostics/ in Persist/, Special/, Signpost/, and HighVolume/ subdirectories, plus logdata.LiveData.tracev3 at its root. Each file is a sequence of chunks — a header, catalogs and LZ4-compressed chunksets holding the timestamped log entries — referencing format strings via uuidtext/ catalogs and the Dyld Shared Cache (DSC). Cannot be parsed in isolation — requires companion uuidtext/, timesync/, and DSC directories for full string resolution and timestamp anchoring. See the Apple Unified Log Archive (logarchive) entry for full forensic context and artifact categories.", "signatures": [ { "offset": 0, "hex": "0010000011000000", "length": 8, "description": "Header chunk: tag 0x1000, sub tag 0x11 (little-endian)" } ], "extensions": [ ".tracev3" ], "links": [ { "label": "Apple Unified Logging formats — tracev3 internals (libyal)", "url": "https://github.com/libyal/dtformats/blob/main/documentation/Apple%20Unified%20Logging%20and%20Activity%20Tracing%20formats.asciidoc" }, { "label": "Mandiant macos-UnifiedLogs parser", "url": "https://github.com/mandiant/macos-UnifiedLogs" }, { "label": "iOS Unified Logs research (Lionel Notari, ios-unifiedlogs.com)", "url": "https://www.ios-unifiedlogs.com/" }, { "label": "Thesis Friday — Unified Log analysis series (Tim Korver)", "url": "https://thesisfriday.com/" } ] }, { "slug": "logarchive", "url": "https://kalink0.github.io/crush-forensics/formats/logarchive/", "name": "Apple Unified Log Archive (logarchive)", "short_name": "logarchive", "category": "log", "platforms": [ "macOS", "iOS" ], "parser_class": "UnifiedLogConverter", "crush_support": "Supported", "status": "reviewed", "last_reviewed": "2026-10-04", "forensic_relevance": "Packaged Apple Unified Log bundle containing tracev3 binary log files, uuidtext string catalogs, timesync boot-anchor records, and a DSC directory. Produced by 'log collect' on macOS/iOS or assembled from a full iOS filesystem acquisition (/private/var/db/diagnostics/ + /private/var/db/uuidtext/ siblings). Provides a complete, timestamp-anchored log timeline with resolved process names, subsystems, and categories; how far back it reaches depends on log volume, as storage is limited by size rather than by a fixed period. Key forensic artifacts: app launches and terminations, lock/unlock and screen events, network connections, Siri activations, biometric authentication attempts, USB/external media connections, userActionEvent entries (explicit user interactions), lossEvent entries (log buffer overflow gaps), and crash precursors. Values logged as private are redacted at write time (masked or hashed) unless private-data logging was enabled; a binary acquisition does not recover them. Full string resolution requires uuidtext/, timesync/, and DSC — without them, message text falls back to raw format-string fragments.", "signatures": [], "extensions": [ ".logarchive" ], "links": [ { "label": "Apple OSLog documentation", "url": "https://developer.apple.com/documentation/oslog" }, { "label": "Mandiant macos-UnifiedLogs parser", "url": "https://github.com/mandiant/macos-UnifiedLogs" }, { "label": "iOS Unified Logs research (ios-unifiedlogs.com, Lionel Notari)", "url": "https://www.ios-unifiedlogs.com/" }, { "label": "Thesis Friday — Unified Log analysis series (Tim Korver)", "url": "https://thesisfriday.com/" }, { "label": "Reviewing macOS Unified Logs (Mandiant, Alexander Holcomb, 2022)", "url": "https://cloud.google.com/blog/topics/threat-intelligence/reviewing-macos-unified-logs/" }, { "label": "Logs Unite! — forensic analysis of Apple Unified Logs (Sarah Edwards)", "url": "https://github.com/mac4n6/Presentations/blob/master/Logs%20Unite!%20-%20Forensic%20Analysis%20of%20Apple%20Unified%20Logs/LogsUnite.pdf" }, { "label": "Apple Unified Logging and Activity Tracing formats (libyal, Joachim Metz)", "url": "https://github.com/libyal/dtformats/blob/main/documentation/Apple%20Unified%20Logging%20and%20Activity%20Tracing%20formats.asciidoc" } ] }, { "slug": "snss", "url": "https://kalink0.github.io/crush-forensics/formats/snss/", "name": "Chromium Session File (SNSS)", "short_name": "SNSS", "category": "log", "platforms": [ "Windows", "macOS", "Linux" ], "parser_class": null, "crush_support": "Not yet supported", "status": "reviewed", "last_reviewed": "2026-10-05", "forensic_relevance": "Session restore files of Chrome, Edge and other Chromium browsers in the profile's Sessions folder (Session_