5.1 Storage Media Architecture: Sectors, Clusters, RAM/File Slack & Unallocated Space

5.1 Storage Media Architecture: Sectors, Clusters, RAM/File Slack & Unallocated Space

Quick Answer: Storage media organize raw data into physical sectors (traditionally 512 bytes, now 4096 bytes in Advanced Format drives) and logical clusters (groups of sectors managed by the operating system). When an active file does not completely fill its allocated cluster, the unused trailing area constitutes file slack. File slack is bifurcated into RAM slack (the bytes from the End of File [EOF] to the end of the containing sector, padded with 0x00 in modern OSs but leaking raw volatile memory in legacy Windows) and Drive/File slack (the remaining whole sectors from the end of the EOF sector to the end of the cluster, retaining residual data from previously deleted files). Defective sectors reallocated by drive firmware to the Grown Defect List (G-list) are inaccessible to standard software imaging tools, requiring specialized hardware controllers to acquire.

---

Magnetic Disk Geometry & Addressing Mechanisms

To conduct forensic investigations at the raw bit-stream level, a computer hacking forensic investigator (CHFI) must master the physical and logical layers of storage media. Traditional spinning hard disk drives (HDDs) record magnetic flux transitions across physical platters spinning at high rotational velocities (typically 5,400 to 15,000 RPM).

Physical Disk Components

• Platters & Surfaces: Circular rigid aluminum, glass, or ceramic substrates coated on both sides with a thin ferromagnetic film. A hard drive contains one or more stacked platters mounted on a central spindle.
• Read/Write Heads: Aerodynamic electromagnetic sliders positioned on an actuator arm assembly. The heads fly aerodynamically across the platter surface on an air bearing (slider-to-disk clearance) of approximately 5 to 10 nanometers—thinner than a fingerprint or smoke particle.
• Tracks: Concentric circular rings mapped onto each platter surface where data is recorded magnetically.
• Cylinders: The vertical alignment of identical track numbers across all platter surfaces. For example, Cylinder 0 represents Track 0 across Head 0, Head 1, Head 2, etc.
• Sectors: The smallest physically addressable unit of storage on a platter track, traditionally sized at 512 bytes.

                  MAGNETIC HARD DISK GEOMETRY
               +-------------------------------+
               |          Track n              |
               |     +-------------------+     |
               |     |    Track 0        |     |
               |     |   +-----------+   |     |
               |     |   |  Sector   |   |     |
               |     |   | [512 B]   |   |     |
               |     |   +-----------+   |     |
               |     +-------------------+     |
               +-------------------------------+
               [Platter Surface: Concentric Tracks]
               Actuator Arm ===> Read/Write Head

CHS (Cylinder-Head-Sector) Addressing vs. LBA

Early storage interfaces addressed physical disk locations using three coordinates: Cylinder, Head, and Sector (CHS):

Under legacy ATA-1 specifications and standard BIOS INT 13h routines, the overlapping CHS limitations resulted in a severe barrier:
$1,024 \text{ cylinders} \times 16 \text{ heads} \times 63 \text{ sectors} \times 512 \text{ bytes} = 528,482,304 \text{ bytes} \approx 504 \text{ MiB} \text{ (528 MB)}$

Even with BIOS INT 13h extensions expanding heads to 256, CHS hit an absolute hard limit at 8.4 GB ($1024 \times 256 \times 63 \times 512 = 8,455,716,864 \text{ bytes}$). Modern computing completely abandoned CHS in favor of Logical Block Addressing (LBA).

Logical Block Addressing (LBA)

LBA abstracts physical disk geometry into a flat, linear, one-dimensional array of consecutively indexed sectors, starting at LBA 0 (the Master Boot Record or Protective MBR) up to LBA $N-1$.

• 28-bit LBA (ATA-1 through ATA-5): Addressed $2^{28} = 268,435,456$ sectors $\times 512 \text{ bytes} = 137.4 \text{ GB}$ (128 GiB limit).
• 48-bit LBA (ATA-6 / Big LBA): Addressed $2^{48} = 281,474,976,710,656$ sectors $\times 512 \text{ bytes} = 144,115,188,075,855,872 \text{ bytes} = 144 \text{ PB}$ (128 PiB limit).

When forensic tools process legacy images, investigators can mathematically map CHS coordinates to LBA using the formula: $\text{LBA} = (C \times H_{\text{heads\_per\_cyl}} + H) \times S_{\text{sectors\_per\_track}} + (S - 1)$

---

Sector Architecture: 512-Byte vs. Advanced Format (4Kn / 512e)

For over thirty years, 512 bytes was the universal physical sector size. However, as drive capacities scaled into multi-terabyte densities, 512-byte sectors became structurally inefficient due to the overhead of inter-sector gaps, synchronization marks, and Error Correction Code (ECC) blocks repeating every 512 bytes.

In 2010, the International Disk Drive Equipment and Materials Association (IDEMA) standardized Advanced Format (AF) storage media, establishing 4096-byte (4 KB) physical sectors.

Legacy 512-byte Format:
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
|Gap|Sync| 512B Data |ECC|Gap|Sync| 512B Data |ECC|Gap|Sync| 512B Data |ECC|
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+

Advanced Format (4Kn / 512e):
+-----+-----+-------------------------------------------------------+-----+
| Gap |Sync |           4,096 Bytes User Data                       | ECC |
+-----+-----+-------------------------------------------------------+-----+
 [Format efficiency increases from ~87% to ~96%; ECC robustness increases 50%]

The Three Sector Implementations

1. 512-Byte Native (512n): Physical sectors and logical sectors are both 512 bytes. Universal compatibility with legacy systems and early forensic tools.
2. 4K Native (4Kn): Physical sectors and logical sectors are both 4096 bytes. The operating system, file system, and forensic acquisition utilities communicate exclusively in 4 KB blocks. No internal emulation occurs.
3. 512-Byte Emulation (512e): Physical sectors are 4096 bytes, but the onboard drive controller firmware translates each physical sector into eight virtual 512-byte logical sectors. This ensures backwards compatibility with operating systems and partition tools that expect 512-byte sectors.

The Read-Modify-Write (RMW) Penalty and Partition Alignment

In 512e drives, partition alignment is vital. If a partition starts at an LBA offset that is not a multiple of 8 (e.g., legacy MBR partitions starting at Sector 63), a logical sector will straddle two separate 4096-byte physical sectors.

When writing a single 512-byte logical sector on an unaligned partition:

1. The drive controller must read the entire 4096-byte physical sector into internal RAM.
2. It modifies the specific 512-byte segment.
3. It writes the entire 4096-byte physical block back to the platter surface.

This is known as the Read-Modify-Write (RMW) cycle, which degrades I/O performance by up to 50%. For the forensic investigator, misaligned partitions require careful recalculation of sector-to-cluster offsets when conducting manual hex reconstruction of deleted boot records or file headers.

[!NOTE] Modern operating systems (Windows Vista SP1/7/10/11, modern Linux kernels) resolve misalignment by automatically defaulting partition starts to LBA 2048 ($2048 \times 512 = 1,048,576 \text{ bytes} = 1 \text{ MiB}$), which is cleanly divisible by 8 (yielding physical sector 256) and compatible with 4Kn, 512e, and SSD erase block boundaries.

---

Cluster Allocation & File System Storage

Operating systems do not allocate storage sector-by-sector; tracking millions of individual 512-byte sectors would inflate file system metadata tables to unmanageable sizes. Instead, file systems group consecutive sectors into Clusters (also termed Allocation Units).

• The cluster is the smallest logical volume allocation unit available to an operating system file system (NTFS, FAT32, exFAT, ext4).
• Cluster size is always a power of two ($2^n$) sectors: e.g., 1 sector (512 B), 2 sectors (1,024 B), 4 sectors (2,048 B), 8 sectors (4,096 B), or 16 sectors (8,192 B).
• On standard NTFS volumes under 16 TB, the default cluster size is 4,096 bytes (8 sectors of 512 bytes).

+-------------------------------------------------------------------------+
|                   FILE SYSTEM STORAGE BOUNDARIES                        |
+-------------------------------------------------------------------------+
| Sector (Hardware): Smallest physically addressable unit (512 B / 4 KB)  |
| Cluster (OS):      Smallest logically allocatable unit (e.g., 4,096 B)  |
| File Allocation:   A 100-byte file consumes 1 full cluster (4,096 B)    |
+-------------------------------------------------------------------------+

Even if a file contains only 10 bytes of text, the operating system allocates an entire 4,096-byte cluster to it. No other file can share that cluster. The difference between the actual file size and the total cluster capacity produces Slack Space.

---

The Anatomy of File Slack Space

Slack Space is the unused physical storage space between the logical End of File (EOF) and the end of the last cluster allocated to that file. Slack space is one of the most productive locations for recovering deleted data, concealed messages, and historical system activity.

File slack consists of two distinct components: RAM Slack and Drive/File Slack.

+-------------------------------------------------------------------------+
|                 LOGICAL CLUSTER: 4,096 BYTES (8 SECTORS)                |
+-------------------------------------------------------------------------+
| Sector 0 | Sector 1 |          Sector 2          | Sectors 3 - 7        |
|  (512 B) |  (512 B) |           (512 B)          |  (5 x 512 = 2,560 B) |
|----------|----------|----------------------------|----------------------|
|  Active  |  Active  | Active Data |   RAM Slack  |  Drive / File Slack  |
|   Data   |   Data   |  (476 B)    |    (36 B)    |      (2,560 B)       |
|          |          |             | [0x00 padded]| [Residual Data from] |
|          |          |     EOF====>|              | [ Prior Allocations] |
+-------------------------------------------------------------------------+

Worked Example: The 1,500-Byte File

Consider a user writing a 1,500-byte document (suspect.docx) to an NTFS volume configured with 4,096-byte clusters (8 sectors of 512 bytes):

1. Active Data Allocation:
   • The operating system allocates Cluster #400 (4,096 bytes total).
   • Sector 0 holds bytes 0 to 511 (512 bytes).
   • Sector 1 holds bytes 512 to 1023 (512 bytes).
   • Sector 2 holds bytes 1024 to 1499 (476 bytes).
   • The End of File (EOF) occurs at byte offset 1500 (inside Sector 2).
2. RAM Slack:
   • The space between EOF (byte 1500) and the end of Sector 2 (byte 1535) is:
     $512 - 476 = 36 \text{ bytes}$
   • In legacy operating systems (MS-DOS, Windows 95, Windows 98 pre-OSR2), the OS flushed the entire contents of the volatile I/O memory buffer to the physical disk to complete the 512-byte sector write. Consequently, this space leaked whatever transient data was sitting in RAM at that microsecond: cleartext passwords, decrypted keys, clipboard scraps, or network packet fragments.
   • In modern operating systems (Windows NT 4.0 through Windows 11, modern Linux, and macOS), RAM slack is explicitly zero-padded with null bytes (0x00) before writing to disk to prevent cross-process data leakage.
3. Drive Slack (Sector Slack / File Slack):
   • The space spanning from the start of Sector 3 through the end of Sector 7 (5 full sectors):
     $5 \text{ sectors} \times 512 \text{ bytes} = 2,560 \text{ bytes}$
   • The operating system does not wipe, zero, or alter Sectors 3 through 7. They remain untouched on the platter.
   • Forensic Goldmine: Whatever data previously existed on Sectors 3–7 from deleted files remains fully intact. If Cluster #400 previously held an illicit image, an encrypted key, or an email, those 2,560 bytes of residual data persist until overwritten.

Volume Slack

Volume Slack occurs when the total number of sectors in a partition container is not an exact multiple of the cluster size.

• For example, if a partition contains 10,005 sectors and the cluster size is 8 sectors, the file system allocates:
  $\lfloor 10,005 \div 8 \rfloor = 1,250 \text{ clusters (using 10,000 sectors)}$
• The remaining 5 sectors (2,560 bytes) at the very end of the partition cannot be addressed or allocated by the file system driver.
• Anti-forensics actors use disk-editing utilities (such as WinHex or Linux dd) to write concealed tools, keyloggers, or exfiltrated documents directly into volume slack, knowing standard operating system file browsers, antivirus scanners, and integrity checkers never examine sectors outside the active cluster map.

Unallocated Space vs. Slack Space

Forensic candidates must never conflate slack space with unallocated space:

---

Defect Management: P-List, G-List & Bad Cluster Reallocation

Magnetic media platters inevitably contain or develop physical surface imperfections where magnetic particles cannot hold an electrical charge. Hard drive controllers maintain internal defect management systems to handle bad sectors transparently.

+-------------------------------------------------------------------------+
|                    DRIVE FIRMWARE DEFECT LISTS                          |
+-------------------------------------------------------------------------+
| 1. Primary Defect List (P-list): Factory map of manufacturing flaws.   |
|    Sectors skipped permanently via sector slipping during fabrication.  |
| 2. Grown Defect List (G-list): Dynamic operational reallocations.       |
|    Damaged sectors remapped to reserved spare tracks via sector forwarding.|
+-------------------------------------------------------------------------+

Primary Defect List (P-list)

During fabrication, the manufacturer conducts a rigorous microscopic surface scan of the magnetic platters. Defective sectors discovered during this factory process are recorded in the Primary Defect List (P-list) stored in the drive's reserved system area (the "negative tracks" or Service Area).

• The drive controller performs sector slipping: the addressing sequence simply skips the defective physical sector and assigns the subsequent LBA to the next healthy physical sector.
• The P-list is permanent; it does not change during the operational life of the drive and causes zero performance penalty.

Grown Defect List (G-list)

During normal drive operation, platter degradation, head friction, thermal expansion, or physical impacts can damage sectors. When the drive controller detects repeated CRC or ECC read/write failures on a sector, it executes sector reallocation (sector forwarding):

1. The defective sector's physical address is added to the Grown Defect List (G-list).
2. The drive controller remaps that specific LBA to a healthy spare sector located in a reserved pool on the inner or outer cylinders of the platter.
3. Whenever the operating system subsequently requests a read or write to that LBA, the drive controller silently redirects the read/write head to the spare track.

S.M.A.R.T. Forensic Indicators

Self-Monitoring, Analysis, and Reporting Technology (S.M.A.R.T.) tracks drive reliability metrics. Forensic examiners inspect specific S.M.A.R.T. attributes to evaluate media integrity and detect tampering:

• Attribute 05 (0x05 - Reallocated Sectors Count): Number of bad sectors that have been retired and remapped to the G-list spare pool. A non-zero, rising count indicates ongoing media failure.
• Attribute 196 (0xC4 - Reallocation Event Count): Number of successful and unsuccessful remap attempts.
• Attribute 197 (0xC5 - Current Pending Sector Count): Unstable sectors awaiting reallocation due to read errors. If a pending sector is subsequently written successfully, it may un-flag; if it fails write verification, it moves to the G-list.
• Attribute 198 (0xC6 - Offline Uncorrectable Sector Count): Sectors with uncorrectable errors during background offline scans.

# Inspect S.M.A.R.T. attributes and G-list indicators using smartctl
smartctl -A /dev/sdb

# Sample Output Snippet:
# ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  RAW_VALUE
#   5 Reallocated_Sector_Ct   0x0033   098   098   036    Pre-fail  Always   144
# 197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always   8

The Forensic Challenge of Reallocated Sectors

Standard forensic acquisition software (dd, FTK Imager, Guymager) communicates with storage devices via standard ATA/SCSI commands through the operating system kernel.

• When a standard imaging tool reads an LBA that has been remapped to the G-list, the drive controller serves the data from the spare reserve sector—not the original degraded physical sector.
• Anti-Forensics Exploitation: Sophisticated threat actors can deliberately inject errors or exploit vendor-specific ATA commands to force sectors containing malware or stolen data into the G-list. Once remapped, the original data trapped in the defective sector is completely invisible to software-level forensic imaging tools.
• Hardware Recovery Solutions: To access data in reallocated sectors or corrupted system areas, forensic specialists must use specialized hardware-software platforms like the ACE Laboratory PC-3000. The PC-3000 connects directly to the drive's diagnostic serial/terminal port and issues vendor-specific technological commands directly to the drive processor (DSP), bypassing LBA translation to read raw platter tracks directly.

---

Practical Forensic Extraction: The Sleuth Kit (TSK)

Forensic examiners routinely leverage open-source command-line utilities from The Sleuth Kit (TSK) to inspect volume structures, extract slack space, and isolate unallocated sectors:

# Step 1: Display file system architecture and cluster geometry
fsstat /dev/sdb1
# Output provides: Block Size (Cluster Size), Total Block Count, Free Blocks

# Step 2: Extract only the slack space from an entire partition image
# The -s flag instructs blkls to extract slack space only
blkls -s /dev/sdb1 > /evidence/sdb1_slack.raw

# Step 3: Extract all unallocated clusters for file carving
blkls /dev/sdb1 > /evidence/sdb1_unallocated.raw

# Step 4: Search extracted slack space for specific residual strings or PII
strings -t d /evidence/sdb1_slack.raw | grep -E -i "password|confidential|BEGIN PRIVATE KEY"

---

Real-World Case Scenario: The Patent Theft In Drive Slack

The Case

A defense contractor's IP security team alerted that a departing propulsion engineer had accessed proprietary missile blueprints shortly before tendering a resignation. A corporate forensic investigator imaged the suspect's company-issued laptop using an external hardware write-blocker.

Investigative Findings

1. Active Files Clean: Analysis of the suspect's active NTFS directories revealed no traces of the missing blueprints. The user had created a series of small 500-byte plain text files named recipes.txt and notes.txt in C:\Users\engineer\Documents\.
2. Drive Slack Parsing: The investigator extracted the slack space of the NTFS volume using TSK blkls -s. Analysis of the drive slack belonging to recipes.txt (a 500-byte file sitting inside a 4,096-byte cluster) revealed 3,596 bytes of residual data.
3. Artifact Identification: Within the drive slack (Sectors 1 through 7 of that cluster), the investigator carved fragments of an AutoCAD .dwg header and cleartext engineering parameters detailing hypersonic propulsion nozzles.
4. Nexus & Culpability: The suspect had deleted the proprietary .dwg file, then immediately generated small text files to overwrite the beginning of the cluster, believing that overwriting the file name and first sector would completely destroy the evidence. However, because the text file was smaller than a single sector, the remaining 7 sectors of the cluster preserved the stolen blueprints in drive slack.