Operating Systems, Boot Process and File Systems

Process scheduling, virtual-memory management, filesystem services, device I/O and access control provide useful ways to organise an examination. They do not imply a one-to-one mapping between each function and one guaranteed artefact. For example, Prefetch is a Windows performance feature rather than the processor scheduler’s universal audit log.

Identify the OS version, filesystem features, audit configuration and capture type before selecting parsers. A missing log can reflect disabled collection, retention, permissions or incomplete acquisition as well as deletion. Distinguish a setting inferred from records from a setting observed directly.

Kernel and user-space boundaries matter when assessing trust in live results. A compromised operating system can misreport processes or files. An independent offline examination can avoid relying on that running kernel, but encryption, firmware, storage-controller behaviour and acquisition limitations remain relevant.

Windows, Linux, macOS, Android and iOS expose different data models, even where they share underlying components. Linux systems can use ext, XFS, Btrfs and other filesystems; Android can use ext4 or F2FS; Apple platforms commonly use APFS. Identify what is present instead of treating an OS family as proof of a particular on-disk layout.

Choose live or offline examination for the question and state. Booting a trusted environment on the source can still change firmware or storage state and may lose existing decryption access. Record the collection path and any changes rather than equating an offline method with universal completeness.

A simplified startup sequence moves through firmware initialisation, boot selection, an operating-system loader, kernel startup and user-space services. The exact stages, stored diagnostics and security mechanisms depend on the platform. Not every stage creates a durable log.

Legacy BIOS boot commonly executes code from a boot sector. UEFI can select an executable on an EFI System Partition using configured boot entries. Partition style and firmware mode are related implementation choices, not a rule that every GPT disk requires UEFI for all uses or that every UEFI boot executes MBR code.

Secure Boot evaluates authorised boot components under a configured trust policy. Measured boot records measurements of selected components and configuration, often using a TPM and associated event records. Verification, measurement and encryption-key release are different functions; none automatically proves a complete historical sequence.

BitLocker can use TPM-based protectors whose release depends on the configured conditions. Boot changes can affect access, so record the actual protectors and recovery options through an authorised method before altering the system. Platform requirements should not be mistaken for proof that a feature was enabled on a seized device.

Kernel and service records can assist timeline work when captured and retained. Interpret event meaning and clock settings, and distinguish a current measurement or setting from evidence of what was configured at an earlier time.

A partition table describes address ranges and associated metadata; it is not the filesystem within each range. Work from a preserved acquisition and inspect supported structures before attempting repair. An apparently missing partition can reflect damage, an offset, unsupported formatting or access restrictions.

Conventional MBR layouts include boot-related bytes and four primary partition entries in the first sector, with extended partition structures supporting additional logical partitions. The often-quoted approximately 2 TiB addressing boundary assumes 512-byte logical sectors. Do not transfer that number to every sector size or implementation.

GPT normally has a protective MBR, primary header and partition-entry array, plus backup structures. Headers describe locations and sizes; CRC checks can assess consistency, not malicious intent or historical authenticity. The number of entries is represented by the layout rather than fixed universally at 128.

A zeroed LBA 0 does not establish that a primary GPT header at another location is also erased. Inspect the actual headers and candidate filesystem structures. If a backup layout survives, validate it against the image size and other evidence before using it for reconstruction. Preserve the original image and explain any derivative repair.

For damaged layouts and file-content recovery, see Data Recovery and File Carving. Metadata-led recovery and carving address different information.

Filesystems organise names, allocation, metadata and access, with different consistency and deletion mechanisms. A journal, allocation bitmap, directory record and snapshot serve different purposes. Select a parser for the actual format and features.

FAT12, FAT16 and FAT32: Structure and Deleted File Entries

FAT structures include volume parameters, allocation tables, directories and data clusters. FAT12/16 and FAT32 differ in how the root directory is represented. A deleted directory entry may retain useful name and allocation information, but allocation chains, long names and data can be overwritten or incomplete. A starting cluster alone does not establish a fragmented file’s complete contents.

exFAT: Flash Storage and Recovery Considerations

exFAT uses an allocation bitmap and directory-entry sets with stream information, including details relevant to contiguous allocation. Its deleted-entry handling must be parsed according to exFAT’s in-use flags; it is not simply FAT32’s 0xE5 first-byte rule. Evaluate bitmap state, entry completeness and surviving data together.

NTFS: MFT Records, File Attributes and Journaling

NTFS represents files through file records and typed attributes. Relevant attributes can include $STANDARD_INFORMATION, $FILE_NAME and $DATA. Small data may be resident within a record; larger or differently stored data can use external allocations. A file can require extension records, and hard links or named streams complicate a simple one-record/one-name model.

The $MFT includes information about itself and other system files. The volume’s $Bitmap tracks cluster allocation, while an MFT bitmap concerns record use. $LogFile supports transactional consistency; the USN change journal records specified change information when present. None is a complete transcript of file contents or the person performing an operation.

ext2, ext3 and ext4: Inodes, Extents and Journals

An inode records metadata and references to data structures; directory entries connect names to inode numbers. Extent support, inline data, journal configuration and other features affect parsing. Deletion and later reuse can alter both records and data, so there is no universal rule that the entire inode is cleared or that a journal retains every old extent.

For ext3/ext4, journal contents depend on mode, workload, retention and acquisition. ext2 does not have the same journaling model. Recovery tools need support for the actual features, and replay or repair should not silently modify the evidence source.

HFS+ vs APFS: File System Structure and Snapshots

HFS+ and APFS use different structures and capabilities. APFS supports copy-on-write metadata, space sharing, clones and snapshots. Copy-on-write does not mean every overwritten file version remains accessible indefinitely. A retained snapshot can preserve referenced earlier content; its existence, time, scope and accessibility must be established.

Snapshots, backups and current volume data may provide overlapping but different views. Encryption, deleted snapshots, deallocation and incomplete acquisition can limit access. Identify the container and volumes rather than assume one disk image is one complete filesystem.

Logical file length and allocated storage are different measurements. For a specifically nonresident, uncompressed, nonsparse 5,000-byte file allocated two 4,096-byte clusters, the allocation is 8,192 bytes and the tail beyond logical content is 3,192 bytes. Those assumptions matter: a small resident NTFS file need not have its own external cluster.

Terms such as sector slack, RAM slack and cluster slack occur in forensic literature with differing conventions. Define the byte boundaries being examined. Historical RAM-padding descriptions are not a rule that modern slack contains a current or meaningful memory sample.

Slack may contain zeros, padding or residual material, depending on the filesystem, earlier allocation, device and acquisition. Its location alone does not establish a previous owner, file or time. Keep unallocated space distinct from unused bytes inside an allocation.

File Metadata: Timestamps, Attributes and Permissions

Interpret each timestamp by its structure and semantics. POSIX mtime concerns content modification, atime concerns access under the configured policy, and ctime concerns inode change rather than creation. Some systems also record birth time. NTFS structures can expose multiple timestamp sets whose update behaviour is not identical.

Access-time updates can be suppressed, deferred or policy-dependent. Linux mount options and Windows settings need actual verification; a nominal default does not prove the relevant configuration or historical behaviour. Copying, restoring, synchronising and deliberate changes can also affect timestamps.

Attributes, permissions, alternate streams and extended attributes add context. They are different mechanisms, not interchangeable hiding locations. Explain whether a finding records a setting, content, an allocation relationship or an interpreted activity.

Preserved system data can supplement current user files. Identify the mechanism, actual state and acquisition scope rather than treat every system as containing the same recovery sources.

Windows Recycle Bin records can link metadata and retained contents for eligible deletions; some deletion routes bypass the bin and contents can later be removed. Parse the actual version and surviving record pairs. Volume Shadow Copy can provide earlier views when enabled and retained, but an update or calendar schedule does not guarantee a usable snapshot.

Pagefiles can retain selected paged memory, not a complete running state. Hibernation and Fast Startup files have platform- and type-dependent content. A parser’s support must be established for that format; the mere presence of hiberfil.sys does not guarantee a full RAM image or compatibility with every Volatility workflow.

Linux swap, temporary directories, desktop trash and snapshots depend on configuration. A path such as /tmp can be memory-backed or subject to cleanup; desktop trash conventions do not establish that all deletions pass through a retained trash store.

On macOS, consider relevant swap, trash and APFS snapshots where accessible. Keychain records have their own storage and protection arrangements; they are not a universally decrypted database of all credentials. Use the dedicated platform lessons for supported artefact interpretation.

Preserve original offsets, paths, parser versions and relationships between recovered fragments. A fragment can support a content observation without proving a complete conversation, execution or user action. Authorisation, retention and admissibility requirements vary by jurisdiction.