Operating Systems, Boot Process and File Systems

The OS has five jobs an examiner is expected to name without hesitation: process scheduling, memory management (including virtual memory and paging), file-system management, I/O management, and security or access control. Each job produces forensic artifacts. Process scheduling writes prefetch entries and event-log records (covered later under Windows Forensic Artifacts). Memory management writes a page file or swap file that the examiner can image. File-system management writes the journal entries the lab will replay. I/O management writes device installation logs (USB sticks plugged in, printers attached). Security or access control writes login records.

The kernel-versus-user-space distinction matters because anti-forensic and rootkit techniques live or die on whether they can run kernel-mode code. A kernel rootkit can hide files from a user-mode tool like Windows Explorer; it cannot hide them from a raw disk image read offline. This is the central justification for the dead-disk imaging workflow in Indian forensic SOPs.

The five OS families a digital forensic examiner sees in Indian field practice:

• Windows. Dominant on government and corporate desktops, the bulk of laptop fleet. Versions 10 and 11 are the working population in 2026; Windows 7 and XP still appear on legacy industrial control kit. NTFS is the default file system.
• Linux. Server-room dominant; rising on developer laptops. Ubuntu and RHEL derivatives are common; ext4 is the default file system. Indian government cloud (MeghRaj) infrastructure is heavily Linux.
• macOS. Workstation and creative-shop population, smaller in India than in the West but growing in tier-1 cities. APFS replaced HFS+ as the default for SSDs in 2017 with macOS High Sierra; HDDs and Fusion Drives continued to use HFS+ until later releases.
• Android. The mobile bulk. Linux kernel, custom user space, ext4 or F2FS on the data partition. Covered in detail in Module 6.
• iOS. Apple's mobile OS, BSD-derived kernel, APFS file system. Acquisition is its own specialty.

The boot process runs from power-on to a usable OS across six distinct stages. Each stage writes its own evidence, and knowing the stages in order allows the examiner to identify the correct artifact for a given timeline question.

1. POST and firmware init
   Power-On Self Test inside BIOS or UEFI. Inventories DRAM, runs CPU microcode, enumerates PCIe and USB. UEFI writes a boot log to NVRAM that survives power-off; older BIOS does not.
2. Firmware boot device selection
   UEFI reads its boot-order list from NVRAM and picks the first available device. With Secure Boot on, the firmware verifies the bootloader signature against keys in the UEFI key store before handover.
3. Partition table read
   Firmware reads LBA 0. If the disk is MBR, the firmware executes the 446-byte boot code in the MBR. If the disk is GPT, the firmware reads the EFI System Partition directly and looks for a signed EFI binary listed in NVRAM. The partition table itself is forensic evidence.
4. Bootloader execution
   On Windows, bootmgr.efi reads the BCD (Boot Configuration Data) hive and loads winload.efi. On Linux, GRUB or systemd-boot reads its config (grub.cfg or loader.conf) and loads the chosen vmlinuz and initramfs. On macOS, boot.efi handles selection and unlock. Each bootloader writes its own log.
5. Kernel load
   The kernel image is loaded into RAM, decompressed if needed, the early console comes up, and the kernel mounts the root file system. The Linux ring buffer (dmesg) starts collecting messages here. Windows starts populating the System event log.
6. Userspace init and login
   Windows starts the Session Manager (smss.exe), then csrss.exe and winlogon.exe. Linux starts PID 1 (systemd on modern distros). The Windows Security event log starts recording 4624 logon events. From this point the running OS owns the disk.

Secure Boot is the firmware-level signature check on the bootloader. It is on by default on Indian-market Windows 11 OEM installs because Microsoft mandates it. TPM 2.0 is a discrete or firmware-resident security chip that holds keys and measurements (PCRs, Platform Configuration Registers) that record the hash of every boot component. BitLocker on Windows binds the volume master key to specific PCR values, which is why a tampered bootloader breaks BitLocker auto-unlock and why TPM 2.0 status is a recordable artifact at seizure.

The 2024 CERT-In advisory on a UEFI vulnerability in a major OEM's firmware (representative of a recurring class of issues) is the kind of artifact NFSU SoCS lectures use to make the point that the boot chain itself is a forensic surface, not just the OS that sits on top of it. A compromised UEFI can survive a full disk wipe and reinstall.

When an imaged disk reaches the forensic workstation, the first byte range read is the partition table. On an MBR disk, that is LBA 0: 446 bytes of boot code, then a 64-byte partition table (4 entries of 16 bytes each), then the 0x55AA signature. On a GPT disk, LBA 0 holds a protective MBR (a single dummy entry covering the disk) for backwards compatibility, then LBA 1 holds the GPT header, and a backup GPT sits at the end of the disk.

For the examiner, GPT is the friendlier table because the backup at the end of the disk lets a damaged primary be reconstructed. MBR's single copy means a deliberate or accidental overwrite of LBA 0 can wipe the partition layout entirely, and the examiner has to fall back on file-carving (covered in Data Recovery and File Carving).

A common reference question: "A seized 1 TB SSD shows no partitions in Autopsy. The hex viewer shows LBA 0 is zeroed out for the first 512 bytes. What is the immediate next step?" The expected answer is to inspect the end of the disk for a GPT backup header (the disk may have been GPT, with only the primary header wiped); if the disk was MBR, fall back to carving from signatures.

Each major file system has a distinct on-disk structure, journal mechanism, and deletion behavior. These differences determine which tools apply, what data is recoverable, and what can be presented as evidence.

FAT12 / FAT16 / FAT32

The original DOS file system, still used on small USB sticks, SD cards, and the EFI System Partition on every UEFI Windows install. The structure is a Boot Sector, two copies of the File Allocation Table, the Root Directory (on FAT12 / FAT16) or a regular cluster chain (on FAT32), and the data area. Deleted files are marked by replacing the first character of the directory entry with 0xE5; the rest of the entry, including the starting cluster, is preserved. This is why FAT is the textbook "easy to recover" file system: the directory entry tells the examiner where the file was, and the data clusters are often intact until reused.

exFAT

Microsoft's extension of FAT for large flash media (SDXC cards, large USB drives). Same general structure as FAT32, no journaling, supports files over 4 GiB. exFAT is the default file system for SDXC cards. From a forensic recovery standpoint it behaves like FAT.

NTFS

The Windows production file system since Windows NT 3.1. Built around a single special file, the Master File Table ($MFT), which holds one record per file on the volume. Each MFT record is 1024 bytes by default, and contains a set of typed attributes: $STANDARD_INFORMATION (timestamps, attributes), $FILE_NAME (name, parent reference, a second copy of timestamps), $DATA (the file content, either resident in the MFT record for small files or as cluster runs), $INDEX_ROOT and $INDEX_ALLOCATION (for directories, organised as B-trees). The journal lives in $LogFile. The $MFT is also self-describing: record 0 of the MFT is itself, record 5 is the root directory, record 6 is the bitmap of which records are in use, record 8 is the bad-cluster file. An examiner can reconstruct most of an NTFS volume from $MFT alone if the data clusters are intact.

ext2 / ext3 / ext4

The Linux production file systems. ext2 was the original, ext3 added journaling, ext4 added extents, the htree directory index, larger files and volumes, and more accurate timestamps. The structure is built around inodes: every file is one inode, and the inode holds the file's metadata and a list of extents (in ext4) or block pointers (in ext2/3). The journal lives in a reserved inode (typically inode 8). On deletion, the inode is cleared, but the directory entry may still hold the inode number for a window, and the journal often preserves the inode contents long enough for extundelete, ext4magic or the debugfs lsdel command to find it.

HFS+ and APFS

HFS+ was Mac's file system from 1998 until 2017. APFS replaced it across iOS, iPadOS, watchOS and macOS High Sierra and later. APFS is copy-on-write: every write to a file is to a new extent, and the metadata is updated to point at the new extent, leaving the old extent in place until garbage collection. APFS snapshots are a first-class feature: a snapshot freezes the metadata at a point in time and the snapshot can be mounted read-only later. Time Machine on modern macOS uses APFS snapshots. For the examiner this means a freshly imaged APFS volume often contains several days of past file-system state in snapshots, and a "deleted" file may be readable from a snapshot even after the user has emptied Trash.

File allocation on every modern OS happens in clusters (NTFS, FAT) or blocks (ext, APFS). A cluster is a fixed group of sectors. On a 4 KiB-cluster NTFS volume, a 100-byte file occupies one cluster of 4096 bytes, of which only the first 100 are the file's contents. The remaining 3996 bytes are slack, and they hold whatever was in that cluster the last time it was used.

Slack space has three named regions the examiner must distinguish:

• File slack. The unused space from the end of the file to the end of the last cluster. On a 4 KiB cluster volume holding a 5000-byte file, the file uses two clusters (8192 bytes); the last 3192 bytes are file slack.
• RAM slack. The portion of file slack from the end of the file to the end of the sector. The OS pads writes to the sector boundary with bytes from RAM (historically), which means RAM slack can hold data the kernel had recently touched. On modern Windows, RAM slack is typically zeroed, but legacy images still show meaningful content.
• Drive slack. The portion of file slack from the end of the sector to the end of the cluster. Drive slack contains whatever was previously on those sectors and is the most common location for older deleted-file fragments.

The forensic implication: a file system that reports a 100-byte file is sitting on, in the case of a 4 KiB cluster, just under 4 KiB of potentially evidentiary slack. Multiplied across a 1 TB drive with millions of files, slack is a major recoverable surface, and Autopsy, FTK and EnCase all expose slack space as a first-class data source.

Metadata: timestamps, attributes, permissions

Every file carries metadata, and the metadata is what an examiner reasons about for timeline questions.

• MAC timestamps. On POSIX (Linux, macOS, BSD) the standard set is mtime (last modify), atime (last access), ctime (last metadata change). On NTFS the set is Modified, Accessed, Created (also called "MFT-Modified" for the fourth, internal time). APFS adds a "first added" time on top of POSIX.
• File attributes. System, Hidden, Read-Only, Archive on NTFS and FAT (the legacy DOS attribute set). On NTFS there is also Encrypted, Compressed, and reparse-point.
• Permissions. POSIX permissions on ext and APFS (owner / group / other read / write / execute, plus setuid / setgid / sticky). NTFS uses Access Control Lists, where each ACL entry binds a SID to an allow-or-deny mask covering read, write, execute, modify, delete, take ownership and more.
• Extended attributes. xattrs on Linux, ADS (Alternate Data Streams) on NTFS, finder info on HFS+ and APFS. Each is a place where data can hide outside the visible file contents.

The hidden data zones on a typical Windows workstation, in the order an Indian examiner usually checks them:

• $Recycle.Bin. Per-user directory at the volume root. Each deleted item is a paired $I file (metadata: original path, deletion timestamp, original size) and $R file (contents). Until the user empties the Recycle Bin, the file is fully intact under a renamed path.
• Volume Shadow Copy Service (VSS). Windows' snapshot system. By default, Windows creates shadow copies before major updates and on a schedule. Mounting a shadow copy as a virtual volume often reveals files the current state has overwritten. vssadmin list shadows enumerates them on a live system; on a dead image, Autopsy and libvshadow expose them.
• Page file (pagefile.sys). The on-disk overflow for RAM. Holds pages the OS swapped out. The page file can contain fragments of process memory, including decrypted document content, browser sessions and chat data, that never made it to a deliberately written file. Examined with bulk-extractor and grep across the raw image.
• Hibernation file (hiberfil.sys). A compressed image of RAM written when the machine hibernates. Bigger than the page file and contains the kernel state at the moment of hibernation. Volatility can parse hiberfil.sys as if it were a RAM dump.
• File and drive slack. As covered in Section 5.
• Alternate Data Streams (ADS). NTFS feature that lets a file carry a named secondary data stream (file.txt:hidden.exe). Common anti-forensic location for malware. Autopsy and EnCase enumerate ADS by default.

On Linux, the equivalent set is the swap partition (raw block device, often /dev/sda2 or a swapfile, parseable with strings and bulk-extractor), /tmp and /var/tmp (often cleared at boot, but not always), ~/.Trash or ~/.local/share/Trash, journal blocks in ext4, and snapper or timeshift snapshots on btrfs systems.

On macOS, the relevant zones are the swap files in /private/var/vm/, the ~/.Trash, the APFS snapshots accessible via tmutil listlocalsnapshots, and the Keychain (which is itself an SQLite database with a binary-format envelope).

For deep recovery from these zones, the next topic to read is Data Recovery, File Carving and Deleted / Encrypted Content, which covers the tools and the signature databases. The courtroom side of presenting recovered data is covered in Bharatiya Sakshya Adhiniyam: Forensic Evidence in Court.