Chapter 4: Where Things Live
Arc 1: Learning the System

"Where Things Live" — File Systems, Directories & Storage

Jake Torelli lost a file and needs your help finding it. Along the way, you'll discover how Windows organizes every byte on disk — and find a folder that shouldn't be open to everyone.

Why File Systems Exist

A hard drive or SSD is, at the lowest level, just a long list of numbered sectors — 512-byte or 4096-byte blocks of raw storage. There are no filenames, no folders, no structure. If an application wanted to store data, it would have to remember "my spreadsheet starts at sector 4,819,203 and occupies sectors through 4,819,347." Usable? Barely. Shareable? Not at all.

A file system is the layer of organization that turns raw sectors into the files and folders you see in Explorer. It maintains a database of every file on the disk — its name, its size, where its data physically lives, when it was modified, and who is allowed to access it.

Without a file system, a disk is like a warehouse with no shelves, no labels, and no inventory system. With one, every item has an address, an owner, and a location.

What a File System Tracks (per file):
  • Name — The human-readable filename (e.g., "Q3_Proposal.docx")
  • Location — Which disk clusters hold the file's data
  • Size — How many bytes the file contains
  • Timestamps — Created, Modified, Accessed (the MAC triad in forensics)
  • Attributes — Hidden, System, Read-Only, Archive, Compressed, Encrypted
  • Permissions — ACLs defining who can read, write, or execute the file

FAT32 vs NTFS vs exFAT vs ReFS

Windows has used several file systems over the decades. Understanding their differences matters for security, compatibility, and forensics.

Feature FAT32 NTFS exFAT ReFS
Max File Size 4 GB 16 TB (theoretical 256 TB) 16 EB 35 PB
Max Volume Size 2 TB 256 TB 128 PB 35 PB
Journaling No Yes ($LogFile) No Yes (integrity streams)
ACLs (Permissions) No Yes (full DACL/SACL) No Yes
Encryption (EFS) No Yes No No (use BitLocker)
Compression No Yes (per-file/folder) No No
Alternate Data Streams No Yes No No
Typical Use USB drives, SD cards Windows system & data drives Large USB drives, cross-platform Windows Server, Storage Spaces
Security Implication: FAT32 and exFAT have no permissions system. Any user with physical access to a FAT32 USB drive can read every file on it. This is why removable media policies matter in enterprise environments — a FAT32 thumb drive bypasses all NTFS access controls.

NTFS Internals: The Deep Dive

NTFS (New Technology File System) is the default file system for every modern Windows installation. It was introduced with Windows NT 3.1 in 1993 and has been continuously improved. Understanding its internals is critical for security, forensics, and system administration.

MFT — Master File Table

The MFT is the heart of NTFS. It is a database where every file and folder on the volume has at least one entry (called an MFT record). Each record is typically 1024 bytes and contains:

  • The file's name (stored as a $FILE_NAME attribute)
  • Timestamps (stored as a $STANDARD_INFORMATION attribute)
  • The file's data location — either stored directly in the MFT record if the file is small enough (called a resident file) or as pointers to disk clusters (called data runs)
  • Security descriptor (or a reference to one in the $Secure system file)

The MFT itself is a file: C:\$MFT. It starts at a fixed location on disk, and a backup of the first few entries is stored at C:\$MFTMirr for crash recovery.

Journaling — $LogFile

NTFS is a journaled file system. Before any metadata change is written to disk, NTFS first writes a record of what it's about to do into $LogFile. If the system crashes mid-write, NTFS replays or rolls back the journal on the next boot, preventing file system corruption.

This is called write-ahead logging — the journal entry is always written before the actual data. It's the same principle used in database engines.

ACLs — Access Control Lists

Every NTFS file and folder has an ACL that defines exactly who can do what. There are two types:

  • DACL (Discretionary ACL) — Controls who can access the object (Read, Write, Execute, Modify, Full Control)
  • SACL (System ACL) — Controls what actions get audited (logged to the Security Event Log)

We'll cover ACLs in depth in Chapter 7 (Who Can Do What), but the key insight is: permissions live on the file system, not in a separate database. No NTFS = no permissions.

ADS — Alternate Data Streams

This is one of NTFS's most unusual (and security-relevant) features. Every file can have multiple named data streams attached to it. The "normal" file content is the unnamed default stream. Additional streams are invisible to most tools — they don't show up in dir, they don't change the file's apparent size, and most users never know they exist.

Security Implication: Malware has historically used Alternate Data Streams to hide payloads. A file named readme.txt could have a hidden stream readme.txt:payload.exe containing an executable. Windows also uses ADS legitimately — the Zone.Identifier stream marks files downloaded from the internet (the "this file came from another computer" warning).

Compression & EFS Encryption

NTFS supports transparent compression on a per-file or per-folder basis. Compressed files take less disk space but require CPU overhead for every read/write. Compressed files are shown in blue in Explorer.

EFS (Encrypting File System) provides transparent per-file encryption. Only the user who encrypted the file (and designated recovery agents) can decrypt it. EFS keys are tied to the user's Windows account — if the password is reset by an admin (rather than changed by the user), EFS-encrypted files become permanently unreadable.

Important: A file cannot be both NTFS-compressed and EFS-encrypted at the same time. You must choose one or the other.

The C:\ Directory Structure

Every Windows installation follows a standardized directory layout. Knowing what lives where is essential for troubleshooting, forensics, and security.

PathPurposeKey Details
C:\Windows Operating system files Protected by WRP (Windows Resource Protection). Modifying files here triggers Defender alerts.
C:\Windows\System32 64-bit system binaries Despite the "32" in the name, this contains 64-bit executables on 64-bit Windows. The naming is a legacy from the NT era. cmd.exe, notepad.exe, kernel32.dll all live here.
C:\Windows\SysWOW64 32-bit compatibility binaries "WOW64" = "Windows on Windows 64-bit." This is the 32-bit subsystem. The naming paradox: System32 = 64-bit, SysWOW64 = 32-bit.
C:\Windows\WinSxS Component Store (Side-by-Side) Stores every version of every system component. Can grow very large (10+ GB). Used for Windows Update rollback and repair. Never manually delete contents.
C:\Users\{username}\AppData\Local Machine-specific app data Data that stays on this computer. Caches, logs, local databases. Does NOT roam with the user profile.
C:\Users\{username}\AppData\LocalLow Low-integrity app data Used by sandboxed applications (like browsers running in Protected Mode). Lower trust level than Local.
C:\Users\{username}\AppData\Roaming Roaming app data Data that follows the user across machines in a domain (if roaming profiles are enabled). Browser bookmarks, app settings.
C:\Program Files 64-bit installed applications Protected location. Standard users cannot write here — only admins (or installers with elevation) can modify contents.
C:\Program Files (x86) 32-bit installed applications Same protection as Program Files, but for 32-bit applications. The WOW64 redirector sends 32-bit apps here.
C:\ProgramData Machine-wide app data Hidden folder. Shared application data that applies to all users on the machine. Not per-user like AppData.
The System32/SysWOW64 Naming Paradox: New IT professionals are regularly confused by this. On 64-bit Windows: System32 contains 64-bit binaries (legacy name kept for compatibility), and SysWOW64 contains 32-bit binaries (WOW64 = Windows on Windows 64-bit). Microsoft kept the old name because thousands of scripts and applications hardcoded "System32" in their paths.

MBR vs GPT: Partition Table Formats

Before a file system can be placed on a disk, the disk needs a partition table — a map that defines how the disk is divided into sections (partitions). There are two formats:

FeatureMBR (Master Boot Record)GPT (GUID Partition Table)
Max Partitions 4 primary (or 3 primary + 1 extended with logical drives) 128 partitions
Max Disk Size 2 TB 18 EB (exabytes)
Redundancy No backup — single point of failure Backup header at end of disk + CRC32 checksums
Boot Mode BIOS (Legacy) UEFI (modern, Secure Boot capable)
Security Vulnerable to boot sector viruses Supports Secure Boot — verifies bootloader signatures
Status Legacy — still on older systems Standard for all modern systems (Windows 11 requires GPT + UEFI)
Why GPT Matters for Security: MBR-based boot is vulnerable to bootkits — malware that infects the Master Boot Record and loads before the OS, making it invisible to antivirus. GPT combined with UEFI Secure Boot creates a verified chain of trust from firmware to OS, making bootkits significantly harder to deploy.

NTFS I/O Stack: From Application to Disk

Click any layer to explore what happens at that stage when a file is read or written. Every file operation passes through every layer in order.

📁 C:\ Directory Tree

Key folders in a standard Windows installation. Understanding this layout is essential for troubleshooting and forensics.

C:\
Windows
System32 (64-bit!)
SysWOW64 (32-bit!)
WinSxS
Temp
Users
Default
Public
j.torelli
DesktopDocumentsDownloads AppData → Local / LocalLow / Roaming
Program Files
Program Files (x86)
ProgramData
(Hidden)

💿 MBR vs GPT Partition Layout

How disks are organized at the partition level. GPT replaced MBR as the standard for modern systems.

MBR Disk (Legacy)
Boot Sector
446 bytes — bootstrap code
Partition Table
4 entries max — 64 bytes total
Partition 1 — System
Partition 2 — Data
Max 2 TB • 4 primary partitions • No redundancy
GPT Disk (Modern)
Protective MBR
Backwards compatibility
GPT Header + CRC32
Self-validating integrity check
Partition Entries (128 max)
EFI System
Microsoft Reserved
Windows OS
Recovery
Backup Header
Redundant copy at end of disk
Max 18 EB • 128 partitions • CRC32 integrity

X-Ray Mode: NTFS Write Operation

Watch step by step what happens when an application saves a file to an NTFS volume. The diagram highlights the active component while the terminal shows the internal operations.

Press Play to begin X-Ray walkthrough...

Investigation Lab: Jake's Missing File

Scenario: Jake Torelli from Sales (workstation MD-LT-SALES07) calls the help desk in a panic. He's been working on a proposal for a big client and now he can't find it. "I saved it, I swear!" he says. Priya asks you to remote into Jake's machine, find the file, and while you're at it, check the shared drives for any permission issues she's been meaning to audit.
1
Run dir C:\Users\j.torelli\AppData\Local\Temp /a to check Jake's temp folder — applications often auto-save here.
Hint: The /a flag shows all files including hidden and system files
2
Run tree C:\Users\j.torelli /F to see Jake's full directory structure and locate any misplaced files.
Hint: The /F flag includes file names in the tree output
3
Run attrib C:\Users\j.torelli\Desktop\*.* to check for hidden or system files on Jake's Desktop.
4
Run net use to see Jake's mapped network drives and check connectivity.
5
Run dir \\\\MD-FS01\SharedDocs to browse the company file server's shared documents.
6
Run dir \\\\MD-FS01\Archived_Projects to check the archived projects share. Does this folder seem too open?
Hint: This is the anomaly. Ask yourself: should every domain user have access to old project files?

Terminal — MD-LT-SALES07