Module 1 · Foundations: Hardware, OS & Indian Cyber Law
Operating Systems, Boot Process and File Systems
UEFI to MFT to APFS snapshots, MAC timestamps, file slack and shadow copies, mapped to digital forensics and BSA 2023 Section 63 admissibility.
Practice with national-level exam (FACT, FACT Plus, NET, CUET, etc.) mocks, learn from structured notes, and get your doubts solved in one place.
UEFI to MFT to APFS snapshots, MAC timestamps, file slack and shadow copies, mapped to digital forensics and BSA 2023 Section 63 admissibility.
An operating system is the layer that schedules processes, manages RAM and virtual memory, owns the file system, and brokers every I/O request from user-space to hardware. The forensic examiner sees the OS through its persistent artifacts: partition tables (MBR or GPT), file system structures (FAT, exFAT, NTFS, ext2/3/4, HFS+, APFS), the journal that records changes-in-flight, and the metadata each file carries (MAC timestamps, attributes, permissions). The boot process starts in firmware (BIOS or UEFI), is gated by Secure Boot and TPM 2.0 measurements on modern Windows and Linux installs, and hands off to a bootloader that loads the kernel into RAM. Every step writes evidence: UEFI variables, bootloader logs, kernel ring buffer, file-system journal entries. A trained examiner reads them in that order.
The point the working examiner sees, and the contrarian point most candidates miss, is that the file system is not just "where files live." It is a transactional ledger with its own journal, its own time model, and its own definition of "deleted." On NTFS, a deleted file's MFT entry typically still exists; on ext4, the inode is cleared but extents may remain in the journal; on APFS, the deletion may be reversible through a snapshot the OS still has. The hidden zones (slack space, page file, hibernation file, $Recycle.Bin, Volume Shadow Copy on Windows; swap and ~/.Trash on Linux and macOS) hold data the user thinks is gone. Hardware (covered in Computer Hardware Fundamentals) only sets the upper bound. The OS decides what is actually there.
Five jobs, five families, one set of artifacts.
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:
Six stages, each with its own forensic artifact.
The boot process is the sequence the machine runs from power-on to a usable OS. Every stage writes evidence. Knowing the stages in order is what lets an examiner pick the right artifact to support a particular timeline question.
The partition table is the first thing the lab reads.
When an imaged disk lands on the examiner's bench, 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.
| Property | MBR | GPT |
|---|---|---|
| Year established | 1983 (IBM PC DOS 2.0) | 2010 (UEFI 2.0) |
| Disk size limit | 2 TiB | Around 9.4 ZB |
| Primary partitions | 4 (more via extended) | Around 128 by default |
| Partition identifier | 1-byte type code | 16-byte GUID |
| Header integrity | No checksum | CRC32 on header and entries |
| Backup table | None | Mandatory backup at end of disk |
Where each one keeps its records and what survives deletion.
The forensic examiner has to know each major file system at the structure level, not just the name. The differences decide what tools to use, what is recoverable, and what evidence the courtroom will see.
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.
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.
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.
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 , or the command to find it.
Three slack spaces, three timestamps, and where the bytes hide.
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:
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.
Every file carries metadata, and the metadata is what an examiner reasons about for timeline questions.
On a Windows 11 NTFS volume, a 100-byte text file is created on an 8 KiB-cluster volume. What is the total amount of slack space associated with this file?
lsSecure 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.
| Firmware pairing | Legacy BIOS, also bootable on UEFI in CSM mode | UEFI (UEFI 2.x required for boot) |
| Forensic recoverability of damaged table | Difficult, single copy | Easier, backup at end of disk lets the examiner reconstruct |
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.
extundeleteext4magicdebugfslsdelHFS+ 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 system | Default on | Journal / COW | Deletion artifact | Forensic recovery surface |
|---|---|---|---|---|
| FAT32 / exFAT | USB sticks, SD cards, EFI System Partition | None | Directory entry first byte 0xE5, rest preserved | Directory entry + data clusters until reuse |
| NTFS | Windows C: | $LogFile journal | MFT record marked unused, $FILE_NAME and $DATA usually intact | $MFT, $LogFile, $UsnJrnl, Volume Shadow Copy |
| ext4 | Linux / | Dedicated journal inode 8 | Inode cleared, dirent may persist briefly | Journal replay (extundelete, ext4magic), block scanning |
| APFS | macOS, iOS | Copy-on-write, no classical journal | Old extents survive until garbage collection; snapshots may hold prior state | APFS snapshots, Time Machine local snapshots, container metadata |
| HFS+ | Pre-2017 macOS, legacy iPods | Optional journal | Catalog file entry marked unused | Catalog file + journal replay |
tmutil listlocalsnapshotsFor 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.