OS - Revision

Week 2: Introduction
Forensic Principles
Definition: Digital forensics is a scientific process involving the preservation, collection, validation, and presentation
of digital evidence to support investigations or legal actions.

Locard’s Exchange Principle: Every contact leaves a trace. In forensics, this principle applies to digital interactions,
where traces of activity can often be recovered even if attempts were made to delete them.

The Forensics Process

1. Collection: Secure and acquire data from sources (e.g., devices, network, cloud) with integrity.

2. Examination: Extract data using automated/manual techniques, preserving integrity.

3. Analysis: Answer investigative questions with contextually relevant evidence.

4. Reporting: Document findings clearly, considering the audience’s understanding and presenting recommendations.

Core Concepts
Evidence Integrity: Forensic evidence should remain unchanged to ensure admissibility in legal settings.
Techniques include:

Write-Blockers: Prevent alterations during data acquisition.

Hashing: Use SHA256 or MD5 to verify data integrity by generating unique data "fingerprints."

ACPO Principles:

Principle 1: Evidence collection should not alter data.

Principle 2: Only competent individuals should access original data, with explanations of their actions.

Principle 3: Maintain an audit trail of all evidence-handling processes.

Principle 4: Ensure all forensic work follows legal and procedural guidelines.

Investigative Techniques
Data Reduction: Techniques such as keyword searches, hash lookups, and sorting by recent usage narrow the
focus.

Artifact Analysis: Common OS artifacts include filesystems, registry entries, browser data, and logs, each
containing potential evidence of user activity.

Binary and Data Structures

Binary/Hex Calculations: Essential for analysing data stored in binary (base-2) and hexadecimal (base-16).

Binary to Hex Conversion: Convert binary data into hex by grouping binary in “nibbles” (4 bits each).

Endianness:

Big-Endian: Higher-order byte first (common in network protocols).

Little-Endian: Lower-order byte first (common in CPU architecture).

Practical Consideration: Endianness impacts data interpretation, particularly with raw disk data, as it affects how
dates, times, and other fields are read.

Additional Forensic Concepts

Slack Space: Unused space within file clusters often contains remnants of old data, which can yield forensic
evidence even if a file is deleted.

OS - Revision 1
 ACPO Good Practice Guide: Lays out best practices for evidence handling, ensuring preservation, reproducibility,
and adherence to legal standards.

Week 3: FAT File System

Introduction
Introduced in the 1970s for floppy disks. Became popular on hard drives with the introduction of DOS and Windows
95.

Present on many hard drives as well as different types of flash media.

Three main ‘flavours’: FAT12, FAT16 and FAT32

Differences Between Versions

FAT 12 uses 12 bits to represent the cluster number. Therefore, 4096 possible clusters.

FAT 16 uses 16 bits to represent the cluster number. Therefore, 65,536 possible clusters.

FAT 32 uses 28 bits to represent the cluster number. Therefore, 268,435,456 possible clusters.

FAT 32 also made several changes to the system area. Namely, changes to the volume boot record and the location
of the root directory.

FAT 12/16 Disk Structure

Partition Boot Sector: Contains basic information about the volume

Reserved Sectors

FAT Table 1: Maintains the cluster list of files and free clusters

FAT Table n: Backup copy(s) of the FAT Table

Root Directory: Root folder of the volume

Data Area: Contains all the file data and any other folders

FAT 12/16 PBR

Present in the first sector of the FAT volume.

Contains boot code.

Contains basic information about how to interpret the volume.

FAT 12/16 Calculating Cluster 2

𝑅𝑒𝑠𝑒𝑟𝑣𝑒𝑑 𝑆𝑒𝑐𝑡𝑜𝑟𝑠 + 𝐹𝐴𝑇 𝑇𝑎𝑏𝑙𝑒𝑠 + (𝑅𝑜𝑜𝑡 𝐷𝑖𝑟𝑒𝑐𝑡𝑜𝑟𝑦)
𝑅𝑒𝑠𝑒𝑟𝑣𝑒𝑑 𝑆𝑒𝑐𝑡𝑜𝑟𝑠 + 𝑛𝑜 𝑜𝑓 𝐹𝐴𝑇 ∗ 𝑆𝑒𝑐𝑡𝑜𝑟𝑠 𝑝𝑒𝑟 𝐹𝐴𝑇 + (𝑅𝑜𝑜𝑡 𝐸𝑛𝑡𝑟𝑖𝑒𝑠 / 𝐵𝑦𝑡𝑒𝑠 𝑝𝑒𝑟 𝑆𝑒𝑐𝑡𝑜𝑟) ∗ (𝑠𝑖𝑧𝑒 𝑜𝑓 𝑑𝑖𝑟 𝑒𝑛𝑡𝑟𝑦)
Cluster and Sector Calculations

OS - Revision 2
 Cluster 2 Calculation: The location of Cluster 2 (start of data area) can be calculated by adding the reserved
sectors, FAT tables, and root directory entries.

(𝑅𝑒𝑠𝑒𝑟𝑣𝑒𝑑 𝑆𝑒𝑐𝑡𝑜𝑟𝑠) + (𝐹𝐴𝑇 𝑇𝑎𝑏𝑙𝑒𝑠) + (𝑅𝑜𝑜𝑡 𝐷𝑖𝑟𝑒𝑐𝑡𝑜𝑟𝑦)

𝑅𝑒𝑠𝑒𝑟𝑣𝑒𝑑 𝑆𝑒𝑐𝑡𝑜𝑟𝑠 + 𝑛𝑜 𝑜𝑓 𝐹𝐴𝑇 ∗ 𝑆𝑒𝑐𝑡𝑜𝑟𝑠 𝑝𝑒𝑟 𝐹𝐴𝑇 + (𝑅𝑜𝑜𝑡 𝐸𝑛𝑡𝑟𝑖𝑒𝑠 𝐵𝑦𝑡𝑒𝑠 𝑝𝑒𝑟 𝑆𝑒𝑐𝑡𝑜𝑟) ∗ (𝑠𝑖𝑧𝑒 𝑜𝑓 𝑑𝑖𝑟 𝑒𝑛𝑡𝑟𝑦)

Directory Entries

Structure:

Fields: File/folder name, extension, attributes, timestamps (creation, access, modified), starting cluster, and file
size.

8.3 Format: Compatible with DOS, storing filenames in 8 characters with a 3-character extension.

Attributes: Each entry has bit flags indicating read-only, hidden, system, directory, archive, and reserved bits.

Date/Time Fields: FAT uses DOS date and time formats for tracking creation, access, and modification.

Long File Names (LFN): Filenames exceeding 8.3 format require multiple directory entries using Unicode, with
checksum to verify data integrity.

Converting Clusters to Sectors

S=(C−2)×n+s OR C=n(S−s)​+2

n = number of sectors per cluster

s = sector of cluster 2

C = cluster number

S = sector number

FAT 32 Disk Structure

Partition Boot Sector: Contains basic information about the volume

Reserved Sectors

FAT Table 1: Maintains the cluster list of files and free clusters

FAT Table n: Backup copy(s) of the FAT Table

Root Directory: Root folder of the volume

Data Area: Contains all the file data and any other folders

FAT 32 PBR

Section Offset (Hex) Size (Bytes) Description

Jump Instruction 0x00–0x02 3 Jump code to start boot process

OS - Revision 3
 OEM Identifier 0x03–0x0A 8 Typically identifies the file system

Bytes per Sector 0x0B–0x0C 2 Size of each sector

Sectors per Cluster 0x0D 1 Defines cluster size in sectors

Reserved Sectors 0x0E–0x0F 2 Reserved sectors, usually 32

Number of FATs 0x10 1 Typically, 2 FATs for redundancy

Total Sectors 0x13–0x14 2 Set to 0 in FAT32 (large sector count in Extended BPB)

Sectors per FAT32 0x24–0x27 4 Total sectors occupied by each FAT

Root Directory Cluster 0x2C–0x2F 4 Start cluster for root directory

FSInfo Sector 0x30–0x31 2 Typically points to sector 1 for FSInfo

Backup Boot Sector 0x32–0x33 2 Typically points to sector 6 for backup boot sector

Volume Serial Number 0x43–0x46 4 Unique identifier for the volume

Volume Label 0x47–0x51 11 Volume label, such as "NO NAME "

File System Type 0x52–0x59 8 Typically "FAT32 "

Boot Code 0x5A–0x1FD 420 Code to continue the boot process

Boot Sector Signature 0x1FE–0x1FF 2 0x55AA - indicates valid boot code

FAT 32 Calculating Cluster 2

𝑅𝑒𝑠𝑒𝑟𝑣𝑒𝑑 𝑆𝑒𝑐𝑡𝑜𝑟𝑠 + 𝐹𝐴𝑇 𝑇𝑎𝑏𝑙𝑒𝑠
𝑅𝑒𝑠𝑒𝑟𝑣𝑒𝑑 𝑆𝑒𝑐𝑡𝑜𝑟𝑠 + 𝑛𝑜 𝑜𝑓 𝐹𝐴𝑇 ∗ 𝑆𝑒𝑐𝑡𝑜𝑟𝑠 𝑝𝑒𝑟 𝐹𝐴𝑇

Directory Entries
Each item (file and folder) on the file system has an associated directory entry within the parent folder.

Contains the files or folders metadata.

Directory Entries - Fields

Directory Entries

Bit Map Meaning

00000001 Read Only

00000010 Hidden

00000100 System

00001000 Volume Label

00010000 Directory

00100000 Archive

01000000 Reserved

10000000 Reserved

If the entry relates to a long file name, then the attribute field will contain the value 0x0F.

Marked in most documents are reserved.

However, 0x18 filename should be shown in all lowercase.

0x00 filename should be uppercase or LFN entry.

OS - Revision 4
 Date: 44 D1 – 17 06 2014
Time: 56 ED – 10 55 26
Hundredths of a second: C0 – 192
Time: 17/06/2014 10:55:27 and 92 hundredths.

DOS File Time

15 14 13 12 11 10 9 8

h h h h h m m m

H: Indicates the number of hours (0-23)

M: Indicates the number of minutes (0-59)

X: Indicates the number of two-second periods (0-29) representing 0 to 58 seconds

DOS File Date

15 14 13 12 11 10 9 8

y y y y y y y m

Y: Indicates the number of years offset from 1980 (0-119) representing years 1980 to 2099.

M: Indicates the month number (1-12)

D: Indicates the day of the month (1-31)

Last Accessed only has a date

Modified date and time only have granularity to 2 second intervals.

FAT Table
Tracks cluster usage on the disk, including the status of clusters (used, unused, or bad).

Valid codes in the FAT Table:

0x0000: Cluster unused

0xFFF7: Bad cluster

0xFFF8-0xFFFF: End of file marker

File Creation and Deletion

Creating a File: Adds an entry in the parent directory, writes data to the HDD, and updates the FAT table with used
clusters.

Deleting a File: First byte of the filename in the directory entry is replaced with 0xE5, and FAT clusters are marked
as 0x0000 (indicating unused), but data remains on the disk.

Long File Names (LFN)

LFN entries created for filenames that do not conform to the 8.3 DOS format.

Metadata for LFNs includes sequence numbers, checksum verification, and Unicode filename storage.

File Recovery

OS - Revision 5
 When a file is deleted, its filename is partially erased (first byte replaced), but FAT table entries may still retain
cluster information, allowing recovery.

For long filenames, sequence numbers are replaced, but the name can still be recovered as it is not overwritten
entirely.

Forensic Considerations for FAT

Time is stored in local format, which can result in discrepancies if files are copied or moved.

Allocation strategy used in Windows XP onward may result in old entries remaining in the directory table.

ExFAT File System

Developed to overcome FAT limitations, supporting larger volumes (>2TB) and files (>4GB) with faster I/O.

ExFAT Disk Structure: Features Boot Parameters, OME Parameters, Cluster HEAP, and FAT locations.

Week 4: New Technology File System (NTFS)

Introduction to NTFS
Introduced with Windows NT 3.1.

Designed for a multi-user environment, adding:

Security (user IDs, quotas).

Journaling system to prevent disk errors.

64-bit cluster addressing, allowing up to 264−12^{64} - 1264−1 in size, though Windows XP is limited to
232−12^{32} - 1232−1.

Adds features such as:

Hard links, compression, and encryption.

Sparse files to save disk space for large empty files.

Alternative Data Streams (ADS) for additional file information.

NTFS Versions
Version 1.0: Released with Windows NT 3.1 (1993).

Version 1.1: Released with Windows NT 3.5 (1994).

Version 1.2: Released with Windows NT 3.51 (1995), adding support for compressed files, named streams, and
access control lists.

Version 3.0: Released with Windows 2000, adding disk quotas, encrypted file systems, sparse files, update
sequence number (USN) journaling, $Extend folder, and reorganized security descriptors.

Version 3.1: Released with Windows XP (2001), expanding the MFT record.

NTFS Key Concepts

Lazy Write: Caches data in a "write-back" cache, then writes it to the final destination during idle times. It can lead
to data loss if power is cut before the cache is cleared.

Seizure Issues: Files written/deleted before cache clear may be lost or remain deleted.

NTFS Logging: Changes are logged first, allowing the OS to check if the changes were successful and to roll back
or re-commit as necessary.

NTFS Disk Structure

The NTFS system differs from FAT in that everything is a file.

System files store metadata, and each has a Master File Table (MFT) entry.

OS - Revision 6
 System files have filenames that start with $.

NTFS PBR
The Partition Boot Record (PBR) in an NTFS file system is crucial for initiating the loading of NTFS-specific structures.
The NTFS PBR contains fields and metadata needed to locate and load the Master File Table (MFT) and handle NTFS-
specific features.

NTFS PBR Sections Table

Section Offset (Hex) Size (Bytes) Description

Jump Instruction 0x00–0x02 3 Jump code for boot process

OEM Identifier 0x03–0x0A 8 Typically, "NTFS "

Bytes per Sector 0x0B–0x0C 2 Size of each sector

Sectors per Cluster 0x0D 1 Defines cluster size in sectors

Reserved Sectors 0x0E–0x0F 2 Usually, zero for NTFS

Total Sectors 0x28–0x2F 8 Total number of sectors in the partition

MFT Start Cluster 0x30–0x37 8 Starting cluster for the Master File Table (MFT)

MFT Mirror Start Cluster 0x38–0x3F 8 Starting cluster for the MFT Mirror

File Record Size 0x40 1 Size of file record segments in clusters

Index Buffer Size 0x41 1 Size of index buffers in clusters

Volume Serial Number 0x48–0x4F 8 Unique identifier for the volume

Boot Code 0x50–0x1FD 446 Code to continue the boot process

Boot Sector Signature 0x1FE–0x1FF 2 0x55AA - indicates valid boot code

1. Jump Instruction (Bytes 0x00–0x02)

Purpose: This 3-byte instruction allows the CPU to skip the BPB (BIOS Parameter Block) and jump directly to the
executable code, starting the NTFS boot process.

Example: Commonly EB 52 90, where EB represents a short jump, 52 is the jump offset, and 90 is a NOP (no
operation).

2. OEM Identifier (Bytes 0x03–0x0A)

Purpose: This is an 8-byte field typically containing the ASCII string "NTFS ". It helps identify the file system as
NTFS.

Example: 4E 54 46 53 20 20 20 20 translates to "NTFS ".

3. BIOS Parameter Block (BPB)

The BPB contains disk layout and geometry information, which NTFS uses for managing the file system’s organization.

OS - Revision 7
 Bytes per Sector (Bytes 0x0B–0x0C):

Specifies the size of each sector, typically 512 bytes (00 02 in hexadecimal).

Sectors per Cluster (Byte 0x0D):

Defines the number of sectors in a cluster. Common values are 08, meaning 8 sectors per cluster.

Reserved Sectors (Bytes 0x0E–0x0F):

Usually 0x00 00 in NTFS, meaning no reserved sectors (used by FAT but not NTFS).

Always Zero (Bytes 0x10–0x13):

These fields are typically zero in NTFS. They represent fields like "Number of FATs" in FAT filesystems, which
are irrelevant to NTFS.

4. Extended BIOS Parameter Block (Extended BPB)

The extended BPB contains more NTFS-specific fields.

Total Sectors (Bytes 0x28–0x2F):

This is an 8-byte field representing the total number of sectors in the partition, which allows support for very
large volumes.

MFT Start Cluster (Bytes 0x30–0x37):

Indicates the starting cluster for the Master File Table (MFT), the main database for file and directory entries in
NTFS.

MFT Mirror Start Cluster (Bytes 0x38–0x3F):

Points to a backup of the MFT, providing a recovery point if the main MFT becomes corrupted.

5. Cluster Factor for File Records (Byte 0x40)

Purpose: Specifies the size of file record segments in clusters. This value is typically 0xF6 or similar, indicating
1024-byte file records.

6. Cluster Factor for Index Buffers (Byte 0x41)

Purpose: Defines the size of index buffer segments, used for indexing directories in NTFS. This size is typically set
to a multiple of the cluster size.

7. Volume Serial Number (Bytes 0x48–0x4F)

Purpose: An 8-byte unique identifier for the volume. This serial number is generated during volume formatting.

8. Boot Code (Bytes 0x50–0x1FD)

Purpose: Contains executable code to load the NTFS file system and continue the boot process. This code locates
and loads the NTFS bootloader, such as bootmgr or ntldr, depending on the Windows version.

Description: This boot code is machine-specific, customized for the NTFS file system, and includes instructions to
locate the MFT and proceed with loading system files.

9. Boot Sector Signature (Bytes 0x1FE–0x1FF)

Purpose: The last two bytes of the PBR are a boot sector signature, 0x55AA, which is a standard identifier
indicating the sector contains valid boot code.

Master Boot Record (MBR)

MBR always found at sector 0 on disk

BIOS always knows where to find it

512 bytes in length

Boot code + partition list (3 bootable (active) + 1 extended)

Only supports bootable partition sizes up to 2TiB

OS - Revision 8
 Calculating C:H:S start / end
Take the starting head, starting sector, and starting cylinder values in binary (or the ending)
Then take the first 2 bits (not bytes) from the start sector and add them to the start of the binary for the starting
cylinder. After this is done convert all into decimal and order as cylinder : head : sector
Example (numbers here are random)
head = 14, sector = 3A, cylinder = 10
Convert to binary
head = 18 (decimal), sect = 00111010, cylinder = 00010000
Then sect = 111010 and cylinder= 0000010000
Concert to decimal
Sect = 58 and cylinder = 16
So, the C:H:S = 16:18:58

Partition Table – GUID Partition Table (GPT)

BIOS uses MBR

UEFI uses GPT (GUID Partition Table)

GPT has:

Support for more partitions (up to 128)

Partition sizes up to 1 ZiB for 512 byte sectors (4 ZiB for 4KiB)

A “Protective MBR” to prevent legacy devices from overwriting parts of the disk

A backup table at the end of the disk

OS - Revision 9
 Master File Table (MFT)
The main file in NTFS, containing file records for each file in the file system, including itself.

Structured as an array of records, each with a header and a set of attributes.

Metadata Files
$ MFT Record
File Name Description Details
#

Contains one base file record for each file and folder on an NTFS volume. If
$Mft Master File Table 0 the allocation information for a file or folder is too large to fit within a single
record, other file records are allocated as well.

Guarantees access to the MFT in case of a single-sector failure. It is a

$MftMirr MFT mirror 1
duplicate image of the first four records of the MFT.

Contains information used by NTFS for faster recoverability. The log file is
used by Windows Server 2003 to restore metadata consistency to NTFS after
$LogFile Log file 2
a system failure. The size of the log file depends on the volume size, but it
can be increased using the Chkdsk command.

Contains information about the volume, such as the volume label and the
$Volume Volume 3
volume version.

Attribute
$AttrDef 4 Lists attribute names, numbers, and descriptions.
definitions

Root file name

. 5 The root folder.
index

$Bitmap Cluster bitmap 6 Represents the volume by showing free and unused clusters.

Includes the BPB used to mount the volume and additional bootstrap loader
$Boot Boot sector 7
code if the volume is bootable.

OS - Revision 10
 $BadClus Bad cluster file 8 Contains bad clusters for a volume.

$Secure Security File 9 Contains unique security descriptors for all files within a volume.

$Upcase Upcase table 10 Converts lowercase characters to matching Unicode uppercase characters.

NTFS extension Used for various optional extensions such as quotas, reparse point data, and
$Extend 11
file object identifiers.

Reserved for
Reserved 12–15 Reserved for future use.
future use

Tracked by the MFT, metadata files include:

MFT Entry Structure

Each entry has:

A header containing the entry's status, bytes used, and other info.

Attributes: Describe different aspects of the file (e.g., name, data).

Fix-Up Array (MFT Verification)

End of each sector in an MFT entry has a 0x55AA signature to verify it was written correctly.

MFT fix-up array keeps a record of values that may have been overwritten by this signature.

MFT Attributes
Each attribute describes part of the file or metadata. Key attributes include:

1. $STANDARD_INFORMATION: Contains timestamps and DOS attributes.

2. $FILE_NAME: Contains filename, creation time, and file size.

3. $DATA: Contains file data.

Attributes can be resident (stored directly within the MFT entry) or non-resident (pointing to clusters where data is
stored).

Data Runs
In non-resident attributes, a run list is used to describe the clusters storing the file's data. Each entry in the list
describes an extent (continuous data section) of the file.

Named Streams (Alternative Data Streams, ADS)

ADS allows files to have multiple data streams beyond the main content, stored as additional $DATA entries in the
MFT.

Week 5: Windows Artefacts and the Registry

Windows Registry Overview
The Windows Registry is a hierarchical database storing configuration settings, hardware and software
information, user preferences, and more.

Acts as a central repository for settings, essential for both OS functionality and forensic analysis.

Evolution of the Registry

1. DOS: Used config.sys and autoexec.bat files for configuration.

2. Windows 3.0: Began using INI files for settings.

3. Windows 3.1: Concept of a central repository started.

4. Windows 95 and beyond: Full establishment of the Registry, expanding its scope.

Structure of the Registry

OS - Revision 11
 Hives: Files that store data in the Registry.

Located at %SYSTEMROOT%\System32\config.

Main hives include:

HKEY_USERS: User-specific settings.

HKEY_CURRENT_USER: Settings for the currently logged-in user.

HKEY_LOCAL_MACHINE: System-wide hardware and software settings.

HKEY_CURRENT_CONFIG: Current hardware configuration.

HKEY_CLASSES_ROOT: Information on file associations.

File Locations and Purpose in Windows 10

Registry files have different extensions:

.alt: Backup for critical HKEY_LOCAL_MACHINE\System hive.

.log: Transaction logs of changes.

.sav: Backup copies for restoring in case of setup failures.

Registry Data Insights

Valuable information recoverable from the Registry includes:

System configuration, connected devices, user details, browsing activity, files accessed, programs executed,
and potential passwords.

Time in the Registry

System Time: Time and date information is critical in forensics for building timelines.

Local and UTC Time: Modern OS store time in UTC and calculate differences based on time zones.

Date Representations:

DOS (FAT): Stored as local time.

Windows FILETIME (NTFS): Stored in 100-nanosecond intervals since 1601.

Unix Time: Seconds since 1970, 64-bit for modern systems.

It effectively holds the time zone as an offset from UTC, this gives us the absolute time for the system relative to the
rest of the world, regardless of where it is located

Without this we would have a lot of trouble matching up times between different devices, particularly when they are
in different parts of the world (consider network traffic logs, etc)

Windows System Files

Swap and Hibernation Files:

pagefile.sys: Used for virtual memory.

hiberfil.sys: Stores RAM contents for hibernation.

Recycle Bin
Recycle Bin (pre-Vista):

Files are renamed and stored with INFO2 records for each deleted file, which include original paths and deletion
timestamps.

Recycle Bin (Vista and later):

Each file has associated $I (index) and $R (recycle) files.

Prefetch Files

OS - Revision 12
 Location: Stored in C:\Windows\Prefetch.

Purpose: Speeds up application loading by recording the trace activity of applications.

Forensic Relevance: Provides execution timestamps and application usage information.

Link Files
Purpose: Created whenever a file is accessed or modified.

Attributes: Contain metadata such as the volume serial number, file paths, and timestamps.

Linked files are essentially shortcut files which get created when a user interacts with (by opening or modifying) a
file.

They contain the path to the original file, MAC times of the original file, volume serial/identifier (which file system it
comes from), network details (if applicable) and original file size.

They tell us which files the user has been accessing and using (some degree of attribution), as they are stored on a
per-user basis.

They can store information for files which have been deleted, or those which are no longer accessible (USB drive or
networked resource).

ShellBags
Purpose: Stores user view settings for folders, valuable for tracking accessed directories.

Location: Stored in BagMRU and Bags keys within the Registry.

Volume Shadow Copy

Function: Provides block-level snapshots of files, allowing recovery of older versions.

Forensics: Used to retrieve past versions of files for analysis.

OS Thumbnail Caches
Function: Caches thumbnails to reduce loading time for image previews.

Forensics: Cached thumbnails may retain images even after the original file is deleted.

Registry Data Types

REG_BINARY: Raw binary data.

REG_DWORD/REG_QWORD: 32-bit/64-bit numbers.

REG_SZ/REG_EXPAND_SZ: Null-terminated strings, the latter with environment variable references.

REG_MULTI_SZ: Array of null-terminated strings.

Week 6: Windows Registry and Web Browsers

Registry Analysis:
Important Registry files and keys, such as NTUSER.DAT, store artifacts of user activity, like recent files, typed URLs,
and user account details.
Key Registry items include:

User Account Information: Tracks login history, password requirements, and user privileges.

MountedDevices and USB Devices: Registry entries track devices connected to the system, including details like
vendor ID, product ID, and serial numbers.

Forensic Analysis of NTUSER.DAT:

Stores information on files accessed, searches, network connections, and applications launched.

OS - Revision 13
 Typed URLs in Internet Explorer can be traced, and activity is timestamped.

ShellActivities in Windows 10 track even the titles of windows, such as browser tab titles, including for Tor
Browser.

Most Recently Used (MRU) Entries:

OpenSaveMRU tracks the latest opened files via dialog boxes, useful for discovering recent activity.

RunMRU: Logs items entered in the "Run" dialog box, providing insight into command use.

Shellbags:
Shellbags store folder view preferences, which reveal folder paths and modifications even after folders are deleted.

Web Browser Artifacts:

Browsers store user activity details:

Browsing History: Tracks pages visited, frequently accessed sites, and timestamps.

Internet Cache: Stores data for faster page loading; useful for seeing past page access.

Cookies: Stores session information, helping forensic analysts understand interactions with specific sites.

Browser-Specific Analysis:

Internet Explorer: Data stored in WebCacheV01.dat (an ESE database format).

Chrome & Firefox: Use SQLite databases for history, cookies, and cache.

Private Browsing Mode:

Forensic analysis has tested browsers' private modes for security, finding that artifacts may still remain in RAM or local
storage under certain conditions.

Tools for Analysis:

ESEDatabaseView and ESENTUTL: Analyze ESE database files, such as WebCacheV01.dat, used by IE and Edge.

DB Browser for SQLite: Examines SQLite files from Firefox, Chrome, and other browsers.

Week 8: Unix System Forensics

Unix System Overview
Unix Family Tree: Brief history and structure of Unix systems, including Linux.

File System Structure:

No central Registry; settings distributed across configuration files and directories such as /proc/ (kernel info),
/etc/ (software config), /var/log/ (logs), and /var/lib/.

Important Directories and Files

1. System Information:

/etc/hostname: Stores computer name.

/etc/timezone & /etc/localtime: Timezone settings.

/etc/os-release, /etc/lsb-release, /proc/version: OS version information.

2. Services:

SystemV, Upstart, Systemd: Configuration files for managing services.

Scheduled Tasks: Files in /etc/cron.* and /var/spool/cron/crontabs/.

Networking and User Accounts

OS - Revision 14
 Networking:

/etc/hosts: Local DNS resolver.

/etc/resolv.conf: DNS server configuration.

Wi-Fi Configurations: /etc/wpa_supplicant/*.conf.

User Accounts:

Account Info: /etc/shadow (hashed passwords), /etc/group (user groups), /etc/sudoers (sudo permissions).

Logs and User Activity

Auth Logs: /var/log/auth.log captures sudo usage and login history.

Command History: Stored in .bash_history.

Login Records: /var/log/utmp, wtmp, and btmp track current and past login sessions and failed attempts.

Software Installation Logs

Package Managers:

rpm (Redhat/SUSE), apt (Debian/Ubuntu), and pacman (Arch).

Logs in /var/log directories, database in /var/lib.

Device Files and File System Structure

Device Files: Located in /dev/, with naming conventions based on device type.

Mount Points:

/etc/fstab and /etc/mtab for managing mounted file systems.

Forensic Imaging: Using dd command for creating disk images.

EXT File System Structure

EXT Versions:

EXT, EXT2 (no journaling), EXT3 (journaling added), EXT4 (supports large files).

Inodes:

Unix file systems use inodes to store file metadata but not file names.

Directories are structured with inodes, with more complex links in larger files.

Mac OS File System Structure

File Systems: HFS+, MFS, APFS (Apple’s file system for SSDs).

User Folders: Located in /Users/<username> with subdirectories like Documents, Desktop, and Library.

Forensic Artifacts
Thumbnails:

Stored in Linux at ~/.cache/thumbnails/.

Mac stores thumbnails in /private/var/folders/.../thumbnailcache, accessible with specific permissions.

Swap Files and File Slack: Track residual data storage areas for recovering deleted data.

HEX
In the MBR data will be big-endian so for example the bytes per sector may contain “0x0002” which will need to be
little-endian before being converted. So 0x0002 becomes 0x0200 which is 512 so translates to 512 bytes per sector.

Calculating MiB or GiB

OS - Revision 15
 To calculate the size of a partition in MiB (Mebibytes) when examining an MBR in digital forensics, follow these steps:

1. Locate the Total Sector Count for the partition:

In the MBR, the partition table starts at offset 0x1BE and contains four 16-byte entries (one for each possible
primary partition).

Each entry includes the Total Sectors field, which specifies the number of sectors allocated to that partition.
This field is 4 bytes long and located at offset 0x0C within each 16-byte partition entry.

2. Convert the Total Sectors Value from hex to decimal:

The Total Sectors value is typically in little-endian format (meaning the bytes are ordered from least significant
to most significant).

Convert this 4-byte hex value to decimal to get the total number of sectors in the partition.

3. Multiply by the Sector Size:

Most MBRs use a sector size of 512 bytes.

Multiply the decimal Total Sectors value by 512 to obtain the partition size in bytes.

4. Convert from Bytes to MiB:

To get the partition size in MiB (Mebibytes), divide the result by 1024210242 (1,048,576).

This division gives you the partition size in MiB.

FAT 32 MBR Example

1. Jump Instruction (Offset 0x00 - 0x02)

Bytes: EB 3C 90

Explanation: This is a 3-byte jump instruction to skip over the next fields and start executing the boot code. Here,
EB 3C is a jump command (jmp short), and 90 is a NOP (no operation) instruction, filling in space.

2. OEM Identifier (Offset 0x03 - 0x0A)

Bytes: 4D 53 44 4F 53 35 2E 30

Explanation: This is an 8-byte OEM name or identifier. Here, 4D 53 44 4F 53 35 2E 30 translates to ASCII as

"MSDOS5.0." It identifies the operating system or formatting tool that created the disk.

3. Bytes per Sector (Offset 0x0B - 0x0C)

Bytes: 00 02

OS - Revision 16
 Explanation: This 2-byte field specifies the number of bytes per sector. Here, 0x0200 in hexadecimal translates to
512 bytes per sector.

4. Sectors per Cluster (Offset 0x0D)

Byte: 08

Explanation: This 1-byte field indicates the number of sectors per cluster. In this example, the value 0x08 means
there are 8 sectors per cluster.

5. Reserved Sectors (Offset 0x0E - 0x0F)

Bytes: 00 00

Explanation: This 2-byte field specifies the number of reserved sectors before the file system's first data section.
Here, 0x0000 means there are no reserved sectors (or it could be a placeholder, depending on the file system
type).

6. Number of FATs (File Allocation Tables) (Offset 0x10)

Byte: 02

Explanation: This 1-byte field indicates the number of File Allocation Tables (FATs) on the disk. Here, 0x02
signifies two FAT copies.

7. Max Root Directory Entries (Offset 0x11 - 0x12)

Bytes: 00 02

Explanation: This 2-byte field specifies the maximum number of entries in the root directory. Here, 0x0200 in
hexadecimal translates to 512 root directory entries.

8. Total Sectors (Offset 0x13 - 0x14)

Bytes: 00 00

Explanation: For FAT12/FAT16 file systems, this 2-byte field specifies the total number of sectors on the volume if
it's less than 32,768. A value of 0x0000 here suggests the actual count is specified elsewhere (in the “Large
Sectors” field for larger disks).

9. Media Descriptor (Offset 0x15)

Byte: F8

Explanation: This 1-byte value represents the media descriptor, indicating the storage type. 0xF8 is commonly
used for fixed (non-removable) disks.

10. Sectors per FAT (Offset 0x16 - 0x17)

Bytes: 01 00

Explanation: This 2-byte field specifies the number of sectors per FAT table. Here, 0x0001 means 1 sector per
FAT.

11. Sectors per Track (Offset 0x18 - 0x19)

Bytes: 3F 00

Explanation: This 2-byte field indicates the number of sectors per track. Here, 0x003F translates to 63 sectors
per track.

12. Number of Heads (Offset 0x1A - 0x1B)

Bytes: FF FF

Explanation: This 2-byte field specifies the number of read/write heads. The value 0xFFFF suggests 65535 heads
or could be a placeholder, depending on the context.

OS - Revision 17
 13. Hidden Sectors (Offset 0x1C - 0x1F)
Bytes: 3F 00 00 00

Explanation: This 4-byte field indicates the number of hidden sectors preceding the partition. 0x0000003F means
63 hidden sectors.

14. Large Sectors (Offset 0x20 - 0x23)

Bytes: 80 00 29

Explanation: This 4-byte field is used for disks with more than 32,768 sectors. Here, it’s a placeholder and may
contain other data for compatibility.

Boot Code
Following these fields, the Boot Code starts from offset 0x24 and typically continues until offset 0x1FD. The boot code
contains executable instructions for the initial stages of the OS boot process, including loading system files from the
active partition. The code is machine-specific and varies based on the OS and disk configuration.
These fields form the initial and essential parts of the MBR, setting up parameters for the OS to understand the disk’s
structure and access its contents. If you’d like further details on specific fields or parts of the boot code, let me know!

Data Runs Example

The example run list is: 31: 04 00 00 0C 32: 7C 03 04 00 F4

In this simple example, there are only two “runs”. Let's decode these and place them into the table below.
The first run is 31: 04 00 00 0C

As this is the first run, it contains the starting clusters of the attribute content. There is no jump value as such, so the
jump value for the 1st run should always be left blank.
Next, we need to split the rest into the fragment size and the starting cluster.

Here the header is 31. The first nibble is 3 and the second nibble is 1; so, there is one byte in the run list for the
fragment length and 3 bytes the starting cluster.

The thing to remember here is that the right-hand nibble points to the first piece of data and the left-hand nibble points
the second piece of data. This is a lot easier to show in a drawing:

So, we know that the fragment length (the number of clusters in this run) is given by the first byte of the run itself. This
is 0x04, decimal 4.
As the left nibble in the header is 3, the next 3 bytes give us the starting cluster of this first run (in subsequent runs, this
would be the jump). This gives us 0x00 0x00 0x0C in little endian, so the real value is: 0x0C0000 or decimal 786432.
This is our starting cluster (starting extent). These values are in the first row of the table.
Now onto the second run which is: 32: 7C 03 04 00 F4

We can split this as before, into fragment size and jump value. The fragment size is two bytes this time, 0x7C 0x03.
This is little endian, so the final value is 0x037C.

The jump value, 0x04 0x00 0xF4, is little endian again so convert to big endian: 0xF40004.
A jump could be negative (if the second run is earlier on the disk than the first). To represent this, it is a signed binary
number. A signed binary number uses the most significant bit to indicate that it is a negative. To convert a signed binary
number to decimal, first take two's complement of the binary value (i.e. invert every bit and add 1), then convert to
decimal. Doing this here gives –786428 in decimal.

OS - Revision 18
 Finally, to work out the starting cluster of this second run, we need to add the jump to the start of the previous cluster.
I.e. we need to take 0x0C0000 (from the first run) and apply the jump (-786428). We need both values in the same
format, either hex: 0x0C0000 – 0xBFFFC or decimal: 786432 + –786428. Either way, this gives us 0x04 or 4.

Summary Table of the Example

Jump Value Starting Cluster # of Clusters

RunList Hex Dec Hex Dec Hex Dec

1stRUN n/a n/a 0x0C0000 786432 0x04 4

2ndRUN 0xF40004 -786428 0x04 4 0x037C 892

Windows Artefacts
Registry Files
Location: C:\Windows\System32\Config\ (System-wide), C:\Users\<username>\NTUSER.DAT (User-specific)

Description: The Windows Registry is a hierarchical database that stores critical configuration information for the OS,
hardware, installed applications, and user-specific settings. Key hives (major sections) include:

SYSTEM: Stores configuration for system devices, drivers, and services.

SOFTWARE: Contains installed applications and OS components settings.

SECURITY: Includes security-related configurations, like user rights and policies.

SAM (Security Account Manager): Stores hashed passwords and user account details.

NTUSER.DAT: Stores user-specific configurations such as recent files, desktop settings, and application
preferences.

Forensic Use:

Installed Programs: Tracks installed software in the SOFTWARE hive, useful for identifying unauthorized
installations.

USB Device Connections: SYSTEM and SOFTWARE hives record details on connected USBs, including timestamps,
which is helpful for tracking data transfers or unauthorized device usage.

User Activity: NTUSER.DAT files reveal files recently opened, applications executed, and network connections,
allowing investigators to build a timeline of user behavior, pinpoint unauthorized access, or detect signs of data
exfiltration.

Event Logs

Location: C:\Windows\System32\winevt\Logs\
Description: Event logs record system, application, and security events, including
information, warnings, and errors. Key logs:

System: Logs OS and device events like driver loads, crashes, and system reboots.

Application: Logs software events, such as application errors and updates.

Security: Logs login/logout events, policy changes, and access control changes. It includes Audit Success and
Audit Failure events, critical for security assessments.

Forensic Use:

Login/Logout Tracking: Security logs track user access, including successful and failed login attempts, which can
help identify unauthorized access.

Policy and System Changes: Detect changes like user account creations, privilege changes, or system
reconfigurations, potentially indicating privilege escalation or malware deployment.

OS - Revision 19
 Application Errors: Application log entries can reveal system instability or pinpoint the time malware or
unauthorized software ran.

Browser Artifacts
Locations:

Internet Explorer: C:\Users\<username>\AppData\Local\Microsoft\Windows\WebCache\

Chrome: C:\Users\<username>\AppData\Local\Google\Chrome\User Data\

Firefox: C:\Users\<username>\AppData\Roaming\Mozilla\Firefox\Profiles\

Description: Browsers save browsing history, cache, cookies, and bookmarks. Chrome and Firefox use SQLite
databases (History, Cookies, Downloads, and Places files), while Internet Explorer uses the WebCacheV01.dat file
format.
Forensic Use:

Browsing History: Reveals the web pages visited, useful for tracking user interests, research, or interaction with
potentially malicious sites.

Cache and Cookies: Cache files contain copies of visited web pages, and cookies store login sessions and
preferences. These can provide information on accessed accounts, online communications, or the presence of
session tokens.

Downloads: Download logs within browser history can help identify files downloaded, supporting evidence for
malware downloads or unauthorized data access.

Prefetch Files
Location: C:\Windows\Prefetch\

Description: Prefetch files are created when an application is run, containing metadata to optimize loading times. Each
file has a .pf extension and records the last run timestamp and the paths of associated files.

Forensic Use:

Application Usage Timeline: Prefetch files show the last time an application was executed and the number of
executions, aiding in reconstructing user behaviour.

Identifying Suspicious Programs: Suspicious applications or malware may leave traces in Prefetch files even if
deleted. The presence of unusual or unauthorized program names can alert investigators to potentially harmful
software.

Recycle Bin
Location: C:\$Recycle.Bin\
Description: The Recycle Bin stores deleted files temporarily, assigning each a unique identifier and keeping metadata
on the original location and deletion date.
Forensic Use:

Recovery of Deleted Files: Files in the Recycle Bin can be restored to their original state, often revealing attempts to
hide or remove sensitive information.

Deletion Timeline: By examining the deletion timestamps, investigators can identify when files were deleted, which
may coincide with suspicious activities or indicate efforts to cover tracks.

Link (LNK) Files

Location: C:\Users\<username>\AppData\Roaming\Microsoft\Windows\Recent\

Description: LNK files (shortcut files) are created when a user accesses a file or application, containing metadata such
as the path to the original file, MAC times of the original file, volume serial/identifier (which file system it comes from),
network details (if applicable) and original file size.

Forensic Use:

OS - Revision 20
 Access Verification: LNK files provide evidence that a file was accessed even if it’s since been deleted or moved,
proving user interaction with specific files.

Tracking Removable Devices: If LNK files reference files on external drives, they may reveal use of removable
devices, helpful for investigations of data transfers or exfiltration attempts.

Shellbags
Location: Windows Registry at HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\BagMRU

Description: Shellbags store folder view settings for Windows Explorer, tracking the directories that users have
accessed.
Forensic Use:

Folder Access History: Shellbags track folder access even if the folder is deleted, giving insight into directories that
were accessed on the system.

Evidence of Deleted Folders: This artifact can prove access to sensitive folders that may have been deleted to
cover tracks, valuable for timeline reconstruction and uncovering hidden files or directories.

Jump Lists
Location: C:\Users\<username>\AppData\Roaming\Microsoft\Windows\Recent\AutomaticDestinations\

Description: Jump Lists track recently accessed documents and applications on Windows 7 and newer. Each entry
contains timestamps and file paths.

Forensic Use:

Recent Activity Tracking: Jump Lists help establish recent user activities, showing what files or programs were
accessed and when.

Behavioral Patterns: Patterns in application and file usage can indicate typical user behavior or identify anomalies,
such as the execution of uncommon programs or access to sensitive files.

Hibernation and Page Files

Location: C:\hiberfil.sys (Hibernation) and C:\pagefile.sys (Paging)

Description: Hibernation files store the system’s RAM state during hibernation, while page files are used to extend RAM
on the hard drive, containing data moved from RAM.

Forensic Use:

Volatile Data Recovery: Since hibernation and page files store RAM content, they may contain remnants of open
documents, network activity, or unsaved work, useful for retrieving unsaved passwords or chat history.

Active Session Analysis: Hibernation files may capture data on active sessions, including open programs and
network connections, which can be crucial in cases where the system was powered down during the investigation.

System Restore and Volume Shadow Copies

Location: C:\System Volume Information\

Description: System Restore points and Volume Shadow Copies provide snapshots of
system files and settings at different points in time.
Forensic Use:

File Recovery: Volume Shadow Copies can retain previous versions of files, making it possible to recover data
modified or deleted over time.

System State History: These snapshots help investigators access historical versions of files and Registry settings,
enabling them to track changes to critical files, system settings, or configurations that may indicate tampering.

Windows Registry Keys

OS - Revision 21
 NTUSER.DAT Keys (User-Specific Settings)
Location: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs

Stores: A list of recently opened documents by file type.

Usefulness: Helps investigators identify recent files accessed by the user, which is essential for understanding
recent user activity and building a timeline.

Location: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU

Stores: A history of commands run via the "Run" dialog box.

Usefulness: Provides insight into recent actions taken by the user, especially useful if suspicious commands or
scripts were executed.

Location: HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\TypedURLs

Stores: URLs typed into Internet Explorer’s address bar.

Usefulness: Tracks user’s web browsing behavior, which can reveal access to suspicious or malicious websites.

Location: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\OpenSaveMRU

Stores: Recently opened or saved files in Windows applications.

Usefulness: Useful for establishing a list of files the user interacted with, which may indicate the user’s actions
leading up to an incident.

Location: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders

Stores: Paths to user-specific folders, such as Desktop and Documents.

Usefulness: Indicates common storage locations and preferred directories, which may contain relevant data for
investigation.

System-Wide Settings
Location: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run

Stores: Programs configured to run automatically on startup.

Usefulness: Detects potentially malicious software set to persistently run on startup, indicating malware or
unauthorized programs.

Location: HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices

Stores: Information on all connected storage devices, including USB drives.

Usefulness: Tracks connected storage devices, which can reveal if external drives were used for data transfer or
exfiltration.

Location: HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\

Stores: Details on installed services, including third-party and system services.

Usefulness: Investigates changes in system services, as malicious software often installs its own services for
persistence.

User Assist
Location: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist
Stores: Counts and last accessed timestamps for applications run by the user.

Usefulness: Shows what applications were used frequently or recently by the user, which helps in identifying patterns
of activity or suspicious software usage.

Shellbags
Location: HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\BagMRU and
HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Bags
Stores: Folder view settings for directories accessed by the user.

OS - Revision 22
 Usefulness: Tracks access to specific folders, even if they were deleted later. Useful for identifying folders the user
viewed or modified, including hidden or sensitive directories.

Last Known Networks

Location: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\NetworkList\Signatures\Unmanaged
Stores: Information on previously connected networks, including SSIDs (Wi-Fi network names) and MAC addresses.

Usefulness: Reveals network connections made by the device, useful for tracking potential unauthorized network
access points.

USB Device History

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USBSTOR

Stores: Information on USB storage devices previously connected, including device IDs and connection timestamps.
Usefulness: Identifies external storage devices connected to the system, which can indicate potential data transfers or
unauthorized access.

Windows Search History

Location: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\WordWheelQuery
Stores: Search terms recently used by the user in Windows search.

Usefulness: Tracks searches conducted on the system, potentially revealing search terms related to suspicious
activities or efforts to locate sensitive files.

MRU (Most Recently Used) Lists

Location: Various locations, such as
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs
Stores: Recently accessed documents, often categorized by file extension.

Usefulness: Establishes a clear record of user activity on specific files, helpful for creating a timeline or identifying
sensitive documents accessed.

Security Settings
Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

Stores: Security policies, including login restrictions and authentication protocols.

Usefulness: Assesses if security settings have been altered, which could indicate attempts to weaken security or
unauthorized changes by an intruder.

Time Zone and Time Change Logs

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation
Stores: Current time zone and time changes. It effectively holds the time zone as an offset from UTC, this gives us the
absolute time for the system relative to the rest of the world, regardless of where it is located.

Usefulness: Without this we would have a lot of trouble matching up times between different devices, particularly when
they are in different parts of the world (consider network traffic logs, etc). Inconsistencies in time settings may suggest
attempts to alter timestamps on files, which is a common tactic in covering tracks.

RDP Connection History

Location: HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Default
Stores: IP addresses of Remote Desktop Protocol (RDP) sessions.

Usefulness: Useful for identifying remote connections to the system, which could indicate unauthorized access or
lateral movement within a network.

OS - Revision 23
 Application-Specific Artifacts
Location: Varies by application, e.g., HKEY_CURRENT_USER\Software\Microsoft\Office for Microsoft Office.

Stores: Application usage details, preferences, and last accessed documents.

Usefulness: Allows investigation into specific applications like Office or third-party software, identifying potentially
sensitive files accessed or changes made by the user.

Communication Forensics
Skype Forensics
Artifacts and Storage Locations:

Skype for Windows Desktop stores data locally in a database file called main.db, which is found at: C:\Users\
<username>\AppData\Roaming\Skype\<Skype username>\

Database Format: SQLite, containing information on chat messages, call logs, file transfers, and contacts.

Cloud-Based Data: In recent versions, much of Skype’s data is stored on Microsoft servers, so local artifacts may
be limited depending on the platform version. Cloud-stored data may require legal authorization to access.

Data Retrieved:

Messages and Chat History: Individual and group messages are stored in main.db under tables like Messages,
allowing investigators to retrieve chat content, timestamps, and sender/receiver information.

Call Logs: Tables in the database, like Calls, contain information on call participants, start/end times, and call
duration.

File Transfers: Records of sent/received files, including filenames, timestamps, and sometimes file paths.

Contacts: Stores contact information, which can link the user to other Skype users or correlate with other contact
lists.

Forensic Use:

Reconstructing Conversations: Chat and call logs allow investigators to piece together conversations, identify
discussion topics, and find references to suspicious activities or relationships.

Timeline Creation: The timestamps on messages, calls, and file transfers help build a chronological timeline of user
interactions.

Link Analysis: Contact and communication frequency data can help establish relationships, potentially linking the
user to associates or uncovering patterns of repeated contact with certain individuals.

Email Forensics
Artifacts and Storage Locations:

Local Email Clients (e.g., Outlook, Thunderbird) store emails on the user’s device in database formats like .pst or
.ost files (Outlook) or in folders like AppData\Roaming\Thunderbird\Profiles\.

Web-Based Email (e.g., Gmail, Outlook.com): Webmail data is generally stored on servers rather than locally.
Accessing this data usually requires legal processes such as subpoenas or cooperation from the email provider.

Logs and Metadata: Email metadata includes headers with information about the sender, recipient, subject, sending
IP address, timestamps, and routing paths.

Data Retrieved:

Message Content: The body of emails, including any attached files, which can reveal discussions, agreements, or
plans.

Attachments: Files sent with emails, potentially containing additional evidence (documents, photos, malware).

Headers and Metadata: Includes details like sender and recipient IP addresses, which can trace the geographical
origin of an email or identify potential spoofing attempts.

Deleted Emails: Deleted messages can sometimes be recovered from backup files, local storage, or provider
archives.

OS - Revision 24
 Forensic Use:

Communication Analysis: Email threads provide insights into communication patterns, enabling investigators to
track discussions and identify key participants in certain activities.

Attachment Examination: Attached files may contain incriminating evidence, such as documents related to the
case or malicious files (e.g., malware sent in phishing attacks).

Geolocation and IP Tracking: Email headers often contain IP addresses that can trace the location from which an
email was sent, which is crucial for identifying potential locations of interest or verifying alibis.

Timeline and Behavior Analysis: Email timestamps and patterns (e.g., frequency, timing of emails) can offer
insights into user routines or anomalies in communication that coincide with suspicious events.

Messaging App Forensics (e.g., WhatsApp, iMessage)

Artifacts and Storage Locations:

WhatsApp: Data is stored locally on devices, and backups may be in iCloud (iOS) or Google Drive (Android). Local
storage often includes databases like msgstore.db.crypt12 (Android), which contain chat history.

iMessage: Stored in SQLite databases on iOS/macOS devices. The chat.db file on macOS stores iMessage history.

Other Apps: Many other apps (e.g., Facebook Messenger, Signal) use encrypted storage and may also store
backups in the cloud or offer end-to-end encryption.

Data Retrieved:

Chat History: Messages with timestamps, sender/receiver data, and group chats.

Media Files: Photos, videos, and audio files sent/received in conversations.

Contact Information: Information about contacts or group members, linking the user to other individuals.

Location Data: Some messaging apps store location data shared within conversations, which can be critical for
determining user movements.

Deleted Messages: Although many apps provide “delete” functions, forensic software can often recover deleted
messages from databases, especially if the app does not employ strong encryption.

Forensic Use:

Reconstructing Conversations: Chat logs provide a comprehensive record of interactions, and messages can
reveal plans, discussions, or incriminating evidence.

Media Analysis: Shared photos and videos may contain additional clues, like image metadata (e.g., geolocation in
EXIF data), which can provide insights into where and when media was created.

Timeline and Location Correlation: Messaging timestamps and any shared location data help in reconstructing
timelines, placing individuals in certain locations at specific times.

Linking Participants: Contact and group chat data establish associations between individuals, valuable for
determining communication networks and understanding relationships in an investigation.

Internet Browsers
Browsing History
Location:

Chrome: C:\Users\<username>\AppData\Local\Google\Chrome\User Data\Default\History

Firefox: C:\Users\<username>\AppData\Roaming\Mozilla\Firefox\Profiles\<profile>\places.sqlite

Internet Explorer/Edge: C:\Users\<username>\AppData\Local\Microsoft\Windows\WebCache\WebCacheV01.dat

Description: Stores records of websites visited, including URLs, visit dates, and times.
Forensic Use: Browsing history provides a record of websites accessed, which can be used to reconstruct a timeline of
user activity, confirm interactions with specific sites, and identify suspicious or inappropriate online behavior.
Investigators can determine what sites were accessed, when, and how often.

OS - Revision 25
 Cache Files
Location:

Chrome: C:\Users\<username>\AppData\Local\Google\Chrome\User Data\Default\Cache

Firefox: C:\Users\<username>\AppData\Local\Mozilla\Firefox\Profiles\<profile>\cache2

Internet Explorer/Edge: C:\Users\<username>\AppData\Local\Microsoft\Windows\INetCache

Description: The cache stores copies of web pages, images, and other media to load websites faster on subsequent
visits.

Forensic Use: Cache files allow forensic investigators to retrieve content from web pages the user has visited, which
can be crucial when examining deleted or inaccessible online content. For instance, cached images, videos, or page
snapshots might show material related to illegal activity or support evidence of specific web interactions.

Cookies
Location:

Chrome: C:\Users\<username>\AppData\Local\Google\Chrome\User Data\Default\Cookies

Firefox: C:\Users\<username>\AppData\Roaming\Mozilla\Firefox\Profiles\<profile>\cookies.sqlite

Internet Explorer/Edge: C:\Users\<username>\AppData\Local\Microsoft\Windows\INetCookies

Description: Cookies are small files that store user session data, login states, preferences, and tracking information for
websites.
Forensic Use: Cookies reveal session data, such as login status and timestamps, indicating if a user was logged into an
account or interacting with a website at a particular time. They can also track website-specific activity, which is useful
for corroborating access to certain online accounts or services.

Download History
Location:

Chrome: History database in C:\Users\<username>\AppData\Local\Google\Chrome\User Data\Default

Firefox: places.sqlite database in C:\Users\<username>\AppData\Roaming\Mozilla\Firefox\Profiles\<profile>

Internet Explorer/Edge: WebCacheV01.dat

Description: A record of files downloaded through the browser, including file names, download URLs, and timestamps.

Forensic Use: Download history allows investigators to track potentially suspicious files retrieved from the internet,
which may include malware or unauthorized documents. The download timestamp and source URL help establish when
and from where files were obtained.

Form Autofill Data

Location:

Chrome: Web Data SQLite database in C:\Users\<username>\AppData\Local\Google\Chrome\User Data\Default

Firefox: Stored within formhistory.sqlite

Description: Browsers often store form data (such as names, addresses, and email addresses) that users have entered
in web forms.

Forensic Use: Autofill data can reveal user-provided information, including addresses, credit card numbers (if saved),
and account credentials. This information can be instrumental in linking a user to online accounts or services and
providing clues to a user’s identity or personal details.

Search History
Location:

Chrome: Stored within the History database

Firefox: Also in places.sqlite

Internet Explorer/Edge: Part of WebCacheV01.dat

OS - Revision 26
 Description: Search history contains records of search terms entered by the user.

Forensic Use: Search queries can provide insights into user intent or areas of interest, which might reveal motives or
suspicious activity. For example, searches related to specific topics can suggest interest or research related to those
subjects.

Session Restore Data

Location:

Chrome: C:\Users\<username>\AppData\Local\Google\Chrome\User Data\Default\Sessions

Firefox: C:\Users\<username>\AppData\Roaming\Mozilla\Firefox\Profiles\<profile>\sessionstore.jsonlz4

Description: Browsers store session data to restore open tabs and windows if the browser crashes or is reopened.

Forensic Use: Session restore files provide snapshots of a user’s browsing session, including all open tabs and their
URLs. This can be crucial for retrieving web pages that were accessed but not saved in browsing history, or for seeing
the user’s immediate online behaviour prior to a shutdown or crash.

Bookmarks and Favourites

Location:

Chrome: C:\Users\<username>\AppData\Local\Google\Chrome\User Data\Default\Bookmarks

Firefox: places.sqlite database in Firefox profile

Internet Explorer/Edge: Stored as individual files in Favourites folder

Description: Stores URLs saved by the user for quick access.

Forensic Use: Bookmarks indicate sites of particular interest to the user. If bookmarks are organized or labelled, they
can reveal insights into the user’s areas of interest, frequent resources, or even illicit materials bookmarked for easy
access.

ACPO
Principle 1: No Action Alters Data
"No action taken by law enforcement agencies or their agents should change data held on a computer or storage
media which may subsequently be relied upon in court."

Explanation: This principle emphasizes that digital evidence must remain unaltered from the time it is collected to
the time it is presented in court. Any actions taken should not modify the original data, ensuring the evidence’s
authenticity.

Implementation: This is often achieved through write blockers (devices that prevent any writing to a drive),
hashing (creating a digital fingerprint of data), and forensic imaging (creating an exact copy of the original data for
analysis).

Principle 2: Competent Individuals Handle Original Evidence

"In circumstances where a person finds it necessary to access original data held on a computer or on storage
media, that person must be competent to do so and be able to give evidence explaining the relevance and the
implications of their actions."

Explanation: Only qualified individuals should access the original evidence, as they understand the potential impact
of their actions on the data. This helps ensure that handling procedures are appropriate and minimizes the risk of
accidental data modification.

Implementation: Investigators handling evidence should be trained in digital forensic techniques and should
document any actions they take with the data. If possible, analysis should be conducted on a forensic image rather
than the original evidence.

Principle 3: Detailed Audit Trail Maintained

OS - Revision 27
 "An audit trail or other record of all processes applied to computer-based electronic evidence should be created and
preserved. An independent third party should be able to examine those processes and achieve the same result."

Explanation: This principle calls for comprehensive documentation of all actions taken with digital evidence, so that
the process can be independently reviewed and replicated. This audit trail enhances transparency and ensures that
any findings are reproducible.

Implementation: Every step in the handling, analysis, and storage of digital evidence should be recorded. This
includes documenting who accessed the evidence, when it was accessed, and what actions were taken. Chain of
custody forms are often used to track who has had possession of the evidence at each stage.

Principle 4: Responsibility for Compliance with Laws and Principles

"The person in charge of the investigation has overall responsibility for ensuring that the law and these principles
are adhered to."

Explanation: The lead investigator is responsible for making sure that all actions in the investigation comply with
relevant laws and ACPO principles. This person ensures that evidence is handled properly and that legal standards
are met.

Implementation: The investigator must oversee the evidence-handling procedures, provide guidance to the
forensic team, and confirm that the principles are followed throughout the investigation.

Importance of the ACPO Principles

These principles help ensure that digital evidence is preserved in its original state, remains reliable for court purposes,
and can be trusted as accurate representations of the original data. By following these principles, forensic investigators
maintain high standards of evidence handling, reducing the risk of evidence contamination or inadmissibility in court.

The ACPO principles have been central to digital forensics but, as some experts have noted, may need to be adapted
as technology and the field of digital forensics evolve. However, they continue to form a core framework for evidence
handling in digital investigations worldwide.

Recommended Reading
ACPO principles for digital evidence: Time for an update?
The article "ACPO principles for digital evidence: Time for an update?" by Graeme Horsman evaluates the long-
standing ACPO principles, which guide digital evidence handling and forensic practices, questioning their relevance
given rapid advancements in digital forensics. Horsman discusses the four ACPO principles established by the
Association of Chief Police Officers, which have been a benchmark for over a decade in ensuring digital evidence
integrity. He highlights that these principles, while foundational, may now be insufficient due to technological
advancements and evolving investigative challenges.

Horsman proposes a revised framework with eight principles to address current gaps, such as the need for validated
forensic methods, respect for privacy, and limitations on intrusive methods. He argues that an updated set of principles
would offer clearer guidance and more robust standards, particularly in terms of quality assurance and evidence
reliability. The article encourages ongoing debate and review of digital forensic standards to adapt to changes in the
field and improve the quality and accountability of forensic practices.

Tool testing and reliability issues in the field of digital forensics

The article "Tool Testing and Reliability Issues in the Field of Digital Forensics" by Graeme Horsman discusses the
critical role that forensic tools play in digital investigations and examines the challenges related to ensuring their
reliability. Horsman argues that the accuracy and dependability of digital forensic tools are essential, as they directly
impact the integrity of evidence presented in legal proceedings. However, the digital forensics field lacks
comprehensive standards and protocols for tool testing, which poses risks for practitioners who rely on these tools to
produce factual results.

The article highlights several issues with current testing practices, such as the difficulty in verifying that tools function
correctly across all possible scenarios, the lack of industry-wide standards, and the scarcity of accessible, validated
test data. Horsman reviews the efforts of the National Institute of Standards and Technology (NIST) and its Computer

OS - Revision 28
 Forensics Tool Testing (CFTT) project, acknowledging its contributions but also noting its limitations, especially
regarding the scalability of tool validation efforts.

To address these challenges, Horsman presents a survey of industry practitioners, revealing that many are concerned
about tool reliability but lack the resources to conduct thorough testing themselves. He concludes by emphasizing the
need for more standardized testing frameworks and the importance of transparency from forensic tool vendors about
error rates and tool limitations, ultimately advocating for improvements in tool validation to support the credibility and
accuracy of digital forensic evidence.

“I couldn’t find it your honour, it mustn’t be there!” - tool errors, tool limitations
and user error in digital forensics
The article, “I Couldn’t Find it, Your Honour, It Mustn’t Be There!” - Tool Errors, Tool Limitations and User Error in Digital
Forensics by Graeme Horsman, addresses the challenges and implications of errors in digital forensic tools. Horsman
explores three types of issues: tool errors (TE), tool limitations (TL), and user errors (UE), discussing how each impacts
forensic investigations.

Tool Errors (TE): Defined as mistakes within the software that cause incorrect or misrepresented data. These errors
can lead to inaccurate forensic findings, affecting the credibility of evidence.

Tool Limitations (TL): Represent the functional boundaries within which a tool operates effectively. If practitioners
are unaware of these limitations, they may rely on tools beyond their capability, leading to incomplete analysis or
oversight.

User Errors (UE): Occur when users misapply tools or lack understanding of their proper usage, often stemming
from inadequate training or unclear tool documentation.

Horsman highlights the importance of validating forensic tools to ensure reliability, given the impact of inaccurate
evidence in legal contexts. The article suggests improvements, such as greater transparency in tool limitations, better
testing protocols, and enhanced user training. Horsman emphasizes that accountability in digital forensics requires
awareness of tool limitations and the necessity of standardized testing practices.

Digital Forensics in the Next Five Years

The article "Digital Forensics in the Next Five Years" by Laoise Luciano, Ibrahim Baggili, Mateusz Topor, Peter Casey,
and Frank Breitinger discusses future challenges, opportunities, and required skills for the field of digital forensics.
Based on a workshop organized by the University of New Haven, supported by the National Science Foundation, the
article presents insights from digital forensic experts on how the field must evolve to address current and anticipated
issues.

Key points include:

1. Anticipated Challenges: Challenges like increased encryption, managing massive volumes of data, the rise of
cloud and Internet of Things (IoT) forensics, and integrating cross-disciplinary knowledge from fields like
psychology and social network analysis.

2. Research Opportunities: The article highlights emerging areas for research, including IoT, AI-based forensic
methods, and cloud storage. It also underscores the need for advanced techniques to handle encrypted data and
password recovery.

3. Job-Ready Skills: Emphasizes the need for education in foundational forensics, encryption, memory analysis, and
network traffic analysis, alongside skills in communication and problem-solving to meet future job market demands.

The article concludes that for digital forensics to keep pace with technological advancements, ongoing updates to
educational curricula, standardization of forensic tools and methods, and increased collaboration within the community
are essential.

OS - Revision 29