Quick revision - Lecture 2

1. Target state determines acquisition

Running physical system

  • Volatile memory is still changing.

  • Live acquisition is possible.

Virtual machine

  • Hypervisor/guest-memory acquisition may provide additional options.

Powered down/hibernated

  • Live RAM is no longer available.

  • Must rely on another preserved source.

The Week 2 practical focus is:

Running Linux → software-based live acquisition → preserve memory → analyse later

⭐ 2. Linux kernel vs Linux distribution

Linux kernel

The privileged core that manages:

  • Memory

  • Processes/execution

  • Devices

  • Filesystems

  • Networking

Linux distribution

Combines the kernel with:

  • User-space applications

  • Libraries

  • Utilities

  • Configuration

  • Package ecosystem

⭐ For memory analysis

The kernel version/build matters because Volatility needs compatible information about how that particular kernel organises memory.

3. User space vs kernel space

User space

Contains:

  • Applications

  • Shells

  • Services

  • Tools

Has restricted access.

Kernel space

Contains the privileged kernel.

Can control:

  • Physical memory

  • Devices

  • Filesystems

  • Networking

  • Process execution

On x86 Linux:

Ring 3 → User space

Ring 0 → Kernel space


⭐ 4. Linux paths you need to recognise

The slides specifically discuss:

/dev/sda

Block-device interface to a storage device.

/sys/class/net

Provides a sysfs view of network-interface/device information.

/proc/<pid>

Provides a procfs view of a running process.

Important

/proc can expose live process state.

That information can change or disappear when the process changes/exits.

⭐ 5. Kernel modules

A kernel module is a .ko file that can add functionality to a running kernel.

Example from this week's acquisition:

lime.ko

LiME uses a kernel module because it needs privileged access to physical memory.

Important forensic point

Loading a kernel module changes the running system and therefore introduces acquisition-related activity.

⭐ 6. LiME

Highlight this:

LiME = Linux Memory Extractor

The slides describe LiME as a Linux memory-acquisition tool.

Its role is:

Linux RAM → LiME → .lime memory image

LiME uses a compatible kernel module:

lime.ko

and produces an image such as:

capture.lime

VERY IMPORTANT

LiME acquires memory.

Volatility analyses memory.

Do not mix up their roles.

7. LiME doesn't blindly capture every address

Physical address space can contain:


  • System RAM


  • Reserved regions


  • Device-mapped regions


  • MMIO

LiME captures appropriate System RAM ranges rather than blindly reading everything.

This can produce a .lime image containing:

RAM range A → GAP → RAM range B → GAP → RAM range C

The gaps don't automatically mean the acquisition failed.

8. .lime image

A .lime image contains:


  • Captured physical-memory data


  • Physical-range information/metadata

But it does not automatically explain:


  • Linux record structures


  • Field meanings


  • Kernel symbol locations


  • What every byte represents

That's why a Linux profile is required.

⭐ 9. Linux profile

This is one of the most important Week 2 topics.

A Linux profile provides Volatility with the information required to understand the target kernel's memory structures.

The profile consists of:

module.dwarf

Provides:


  • Structure/type information


  • Record layouts


  • Field relationships

System.map

Provides:


  • Kernel symbol names


  • Corresponding addresses

Therefore:

module.dwarf + System.map
              ↓
        Linux profile
              ↓
       Volatility 2


⭐ 10. Profile compatibility

The profile must match the kernel represented in the memory image.

For example, the slides use:

4.9.0-13-amd64

A profile from a different/nearby kernel might produce output that looks plausible but is incorrectly interpreted.

Highlight:

Compatible kernel profile = essential for reliable Linux memory interpretation.

⭐ 11. Hashing during transfer

There are two separate artefacts:


  1. Memory image


  2. Linux profile

Each should be:

Hash before transfer

↓

Transfer to Kali

↓

Hash after transfer

↓

Compare

If the values match, this supports byte-for-byte consistency between the files before and after transfer.

⚠ It does not prove that the acquisition was complete or that the artefact was interpreted correctly.

💻 ⭐ 12. MOST IMPORTANT WEEK 2 COMMAND

The slides give this actual Volatility command:

volatility -f week2dump.lime --profile=LinuxDebian_4_9_0-13-amd64_profilex64 linux_pslist

Break it down:

volatility

Runs Volatility.

-f week2dump.lime

Specifies the memory image/file.

--profile=LinuxDebian_4_9_0-13-amd64_profilex64

Specifies the Linux profile.

linux_pslist

Plugin that asks for recoverable Linux process records.

Output includes:

Offset
Name
Pid
PPid
Uid

For example:

systemd
kthreadd
ksoftirqd/0


⭐ 13. What does linux_pslist prove?

If linux_pslist successfully returns plausible processes:

It supports that the selected image + profile can work together for this particular reconstruction method.

But it does NOT prove:


  • Perfect acquisition


  • Complete memory capture


  • Every Volatility plugin will work


  • Every reconstructed artefact is correct

This distinction is important for forensic reasoning.

⭐ 14. ELF

ELF = Executable and Linkable Format

Native Linux programs commonly use ELF.

Examples from the slides:

Executable
.so → shared object
.ko → kernel module

LiME's:

lime.ko

is an ELF-based kernel module.

15. ELF sections vs segments

Sections = file/linking view

Examples:

.text

Code

.rodata

Read-only constants

.data

Variables/data

.symtab / .strtab

Symbol/string metadata

Segments = runtime/memory view

Program headers describe regions that are mapped into memory for execution.

⭐ Remember:

Sections describe file organisation.

Segments describe runtime mapping.

They are not the same thing.

🧠 Week 2 revision workflow

Memorise this:

RUNNING LINUX
     ↓
Identify target kernel
     ↓
LiME / lime.ko
     ↓
Physical RAM acquisition
     ↓
.lime memory image
     ↓
Create/find matching Linux profile
     ↓
module.dwarf + System.map
     ↓
Hash before transfer
     ↓
Transfer to Kali
     ↓
Hash after transfer
     ↓
Compare hashes
     ↓
Memory image + Linux profile
     ↓
Volatility 2
     ↓
linux_pslist
     ↓
Linux artefact reconstruction



Week 2

Definitely highlight these:

LiME
lime.ko
.lime
Volatility 2
linux_pslist

Linux paths

/proc/<pid>
/sys/class/net
/dev/sda

Linux profile

module.dwarf
System.map

Actual command

volatility -f week2dump.lime --profile=LinuxDebian_4_9_0-13-amd64_profilex64 linux_pslist

ELF

ELF
.text
.rodata
.data
.symtab
.strtab
.so
.ko

Hashing

MD5 BEFORE
      ↓
TRANSFER
      ↓
MD5 AFTER
      ↓
COMPARE

⭐ The biggest things to know for an exam