Quick revision - Lecture 4


1. Kernel evidence

The Linux kernel manages processes, memory, devices, filesystems and networking. Investigators can examine three main types of kernel evidence:

  • Physical-memory map: Shows which physical address ranges are assigned to different purposes.

  • Kernel message buffer: Contains surviving messages about system events, devices, drivers and errors.

  • Loaded kernel modules: Shows functionality added to the running kernel.

Kernel message buffer limitation: It is a finite ring buffer. Older messages can be overwritten by newer ones, so a missing message does not prove an event never occurred.

2. Loadable kernel modules

  • Kernel module: Adds functionality to the running kernel without rebuilding the whole kernel.

  • .ko file: The file format used for a Linux kernel module.

  • LiME: A legitimate example of a module used for memory acquisition.

  • Module parameters: Values supplied when a module is loaded.

  • Module sections: Parts of the module, such as .text and .data.

  • Module address and size: Help locate the module's code and data in memory.

A module may support a device driver, filesystem or network functionality.

Forensic warning: An unfamiliar module deserves investigation, but its name alone does not prove malicious activity. Check its purpose, parameters, sections, load context and related kernel messages.

3. Filesystem mounts

A mount connects a filesystem to a location in the Linux directory tree.

A mount record helps answer four questions:

  1. Source: What device or filesystem backs it?

  2. Mount point: Where does it appear?

  3. Filesystem type: What kind of filesystem is it?

  4. Options: What rules affect access and interpretation?

Example:

Field

Example

Meaning

Source

/dev/sda1

Storage device or partition

Mount point

/

Root directory

Type

ext4

Filesystem format

Options

rw,relatime

Mount behaviour

Common filesystem types and paths:

  • ext4: A disk-based filesystem format.

  • tmpfs: A temporary filesystem backed by memory; its pages may be swapped.

  • procfs: Provides a filesystem-style view of process and kernel state, commonly at /proc.

  • sysfs: Provides a view of devices and kernel objects, commonly at /sys.

Important: /tmp may be disk-backed or mounted as tmpfs, depending on the system's configuration. Never assume the storage type from the path alone.

4. Mount options

Keyword

Simple meaning

rw

Normal writes are permitted through the mount

ro

The mount is read-only

exec

Direct execution from the mount is permitted, subject to other restrictions

noexec

Restricts direct execution from the mount

relatime

Influences when access times are updated

Exam tip: noexec does not prove that content cannot be run or interpreted by another program. Mount options provide context, not standalone proof of activity.

5. VFS — Virtual File System

The VFS (Virtual File System) provides a common way for Linux to work with different filesystems.

The main structures connect a file's name, metadata, content and the process that used it.

Keyword

Simple definition

Mount / superblock

Provides context about the filesystem

Dentry

Connects a filename to its parent directory

Inode

Describes the filesystem object and its metadata

Address space

Represents the file's memory-mapping context

Page cache

Holds cached file content in memory

File descriptor

Links a process to an open resource

How do these structures connect?

Example: /tmp/update.sh

  1. Mount: Identify which filesystem contains the path.

  2. Dentry: Follow the filename and parent relationships to reconstruct the path.

  3. Inode: Examine metadata such as size, ownership and permissions.

  4. Page cache: Check whether any file content remains in memory.

  5. Open file / descriptor: Connect the file to the process that referenced it.

Remember: Finding a filename, recovering its metadata and recovering its content are three different achievements.

6. Inodes and timestamps

An inode describes the filesystem object behind a name.

Important inode fields:

  • Type: Whether the object is a regular file or another type.

  • UID / GID: Owner and group identifiers.

  • Mode: File permissions.

  • Size: File size in bytes.

  • Mapping: Connects the object to its file-backed data.

The three important timestamps

Keyword

Meaning

ATIME

Access time — when the file was last accessed, subject to filesystem and mount policies

MTIME

Modification time — when the file's content was last changed

CTIME

Status-change time — when inode metadata or status last changed

Common exam question: Is CTIME the file creation time?

Answer: No. CTIME records an inode or status change, not the file's creation time.

Timestamps can help establish a timeline, but they must be correlated with process, network and other evidence.

7. Page cache and file recovery

The page cache can preserve some file content in memory, but not necessarily the whole file.

A file may be:

  • Complete: All required content was recovered.

  • Partial: Some content is missing.

  • Stale: The cached content may not reflect the latest version.

  • Internally inconsistent: The recovered parts may not form a reliable, coherent file.

Missing pages may result in gaps or zero-filled sections in reconstructed output.

Important: Recovering a path does not guarantee that the file's complete content is available.

8. File recovery plugins

Your Week 4 slides identify two recovery approaches:

Plugin

Purpose

linux_find_file

Targeted recovery when a relevant path or object is known

linux_recover_filesystem

Broader recovery of a resident filesystem view

Choose the approach based on the investigative question.

  • If you know the file you want to investigate, try targeted recovery.

  • If you need a wider view of recoverable filesystem objects, consider broader recovery.

A failed targeted recovery does not mean the investigation is over. Try another approach and check related evidence.

9. Week 4 — Important forensic rules

  • Memory evidence is incomplete: Not every filesystem object or file page will remain in memory.

  • Absence is not proof: A file missing from the memory image may still exist on disk.

  • Correlate evidence: Connect kernel messages, modules, mounts, processes and filesystem objects.

  • Interpret hashes carefully: Reconstructed module hashes may differ from original files because runtime changes and reconstruction can affect the result.

  • An anomaly is a lead, not a verdict: An unexplained difference requires further checks, not an immediate malware conclusion.