EnCE · Domain 3
File Systems
About 14% of the exam
Allocation vocabulary
- Sector
- smallest unit the device handles
- Cluster
- smallest unit the file system allocates
- File slack
- unused bytes in the last cluster
- Unallocated
- clusters no file currently claims
- Sparse file
- logical size exceeds written data
- Bad sector
- flagged unreliable, no longer allocated
Larger clusters waste more per file, which is exactly why slack space grows with cluster size
Allocation table systems
- The table chains clusters for each file
- Directory entries hold names and start clusters
- Deleting marks the entry and frees the chain
- Short and long name entries coexist
- Cross platform variant lifts the size limit
- Case mapping table supports name comparison
Master file table
- Record
- one entry per file or directory
- Resident data
- small content stored inside the record
- Non-resident data
- run list points at clusters
- Attribute list
- record overflowed into extension records
- Index entries
- directory contents with name timestamps
- Named stream
- extra content hidden on a file
- Mirror
- copy of the first critical records
Two timestamp sets
- Standard information times change easily
- Name attribute times live in the index
- Compare both sets for disagreement
- Record change time moves on metadata edits
- Identical values to the second look manufactured
- Clock errors shift every timestamp together
Before trusting any timestamp, confirm the system clock and time zone for the period in question
Journals and logs
Transaction log
- Records metadata operations for consistency
- Holds remnants of recent changes
- Can show a previous file state
- Circular, so it overwrites in time
Change journal
- Lists changes with a reason code
- Sequence numbers only increase
- Wraps once the size limit is reached
- Names files that no longer exist
Unix journaling
- Journal replays interrupted metadata operations
- Old metadata blocks may linger
- Orphan list references unlinked open files
- Extent headers mark modern block mapping
A journal entry describes an operation as it happened, while current metadata only shows the final state
Unix and Apple structures
- Inode
- metadata and block pointers, no name
- Directory entry
- name paired with an inode number
- Extents
- contiguous ranges instead of pointer chains
- Superblock
- volume parameters and orphan references
- Catalog file
- names and metadata in a tree
- Extents overflow
- records for heavily fragmented files
- Snapshot
- earlier volume state preserved cheaply
Partitioning
- Older scheme caps volume size sharply
- Newer scheme uses identifiers and a backup table
- Protective entry hides the new layout
- Conversion can leave remnants behind
- Boot sector values can be stale or altered
- Gaps between partitions can hold data
Hiding inside the file system
- Named streams attached to ordinary files
- Content tucked into file slack
- Extension changed to mislead sorting
- Data placed in unpartitioned regions
- Sectors marked bad but readable
- Nested archives inside ordinary documents
Signature analysis
- Compare header bytes against the extension
- Run the check across the whole volume
- Mismatches surface files nobody would check
- Some mismatches are innocent renames
- Validate internal structure before concluding
- Record the tool and version used
A volume wide signature pass finds disguised files that a targeted check would never think to open
Encryption and compression
Volume encryption
- Whole volume unreadable without the key
- Header signature identifies the scheme
- Capture while the volume is mounted
- Recovery keys may exist centrally
File encryption
- Content protected file by file
- Names and structure often stay visible
- Recovery agents can decrypt centrally
- Copies elsewhere may be plaintext
Compression
- File system compression is transparent
- Compressed archives raise entropy legitimately
- Proprietary variants need matching tools
- Damage in one entry may spare others
Snapshots and shadow copies
- Snapshots preserve an earlier volume state
- They may hold files later deleted
- Registry hives inside snapshots differ from live
- Disabled or deleted snapshots are themselves a finding
- Mount snapshots read only for analysis
- Note which snapshot each finding came from
Corruption and repair
- Name the specific corruption you observed
- Damaged index differs from inconsistent allocation
- Repair tools can destroy evidence
- Work on a copy of the copy
- Record every repair action taken
- Explain what repair may have changed
Key artifacts
- Run list
- clusters holding non-resident content
- Index slack
- removed directory entries still present
- Volume serial
- identifier linking artifacts to media
- Boot record
- layout values, sometimes stale
- Reason codes
- why the journal recorded a change
- Symbolic link
- recorded target path even when broken
Know the order
- Identify the file system
- Parse the metadata
- Read the journals
- Check snapshots
- Sweep slack and unallocated
- Carve what remains
Metadata driven recovery before carving, because the file system already knows where the content lived
Reference strip: file system map
Windows
- Allocation table chains
- Master file table records
- Two timestamp attribute sets
- Transaction log and change journal
Unix
- Inodes and directory entries
- Extent based block mapping
- Journal replay behavior
- Superblock and orphan list
Apple
- Catalog file structure
- Extents overflow records
- Copy on write allocation
- Volume level snapshots
Hiding places
- Named streams and file slack
- Gaps between partitions
- Sectors flagged as bad
- Nested containers in documents
Examiner checks
- Signature analysis across the volume
- Timestamp set comparison
- Snapshot presence and gaps
- Cluster size against slack yield
Quick exam traps
- Trap: Deleting a file removes its metadata record entirely
- Trap: File level encryption also conceals the file names
- Trap: The boot sector always reflects the live file system
- Trap: Named streams appear in an ordinary directory listing
- Trap: A small cluster size produces more slack space
- Trap: Journals keep a permanent history of every change
- Trap: A sparse file's logical size equals data written to disk
cybercertprep.com · original revision sheet written from the public body of knowledge