Live vs. Dead Acquisition

You're standing in front of a compromised Linux server. Before you touch anything, you have to make a choice that shapes the entire investigation: do you collect evidence from the live system, or do you pull the plug and image the disk? This article walks through the trade-offs of both.

The core decision

Live acquisition means running commands on the running system to capture volatile data. Dead acquisition means powering it down and imaging the drives in a controlled way. Neither is always right — the correct answer depends on what you're trying to prove and what you can risk losing.

The order of volatility

Evidence disappears at very different rates. RFC 3227 lays out the order in which you should collect, from most to least volatile:

1. Registers and cache (lost instantly)
2. RAM and swap
3. Network state (routes, connections, ARP cache)
4. Running processes and open files
5. Temporary files on disk (/tmp)
6. Disk (persists, but increasingly overwritten)
7. Remote logs and backups (least volatile)

The practical meaning: if you want memory, you must get it while the machine is running. The moment the power is cut, everything above the "temporary files" line is gone forever.

Live acquisition

Choose live collection when:

• Memory contents matter (crypto keys, injected malware, live network connections).
• The system uses full-disk encryption and you don't have the keys — once it's off, it may be impossible to decrypt.
• The system is a critical production server that can't be taken down.
• You need to see the current state: who is connected, what is running.

Risks:

• Every command you run modifies the system.
• A sophisticated attacker may have tampered with tools (a "rootkit" can fake ps output).
• Your forensic tools must be run from read-only media, not the compromised disk.

A minimal live-response kit, executed from a mounted read-only USB:

date -u                      # trusted time from your own env, note offset
mount                        # what's mounted, and how
cat /proc/net/tcp            # TCP connections (better than ss here)
arp -a                       # ARP cache
ss -tulpn                    # listening & established sockets
ps auxww                     # process list
lsof                         # open files per process
cat /etc/passwd              # accounts (tamper-prone, but collect)
history                      # shell history of the current shell

Dead (static) acquisition

Choose dead acquisition when:

• The system is off already, or can be taken offline.
• The drive is not encrypted (or you have the keys).
• You care about deleted-file recovery and unallocated space (a live mount destroys these as the OS writes).
• You need the most defensible, verifiable evidence for court.

The workflow:

1. Power the system down cleanly if possible; pull the drive with a proper write-protected method.
2. Connect the drive to a forensic workstation via a write blocker.
3. Image the drive with dd/dcfldd, hash the original and the image.
4. Analyze the image; never work on the original.

Choosing: a quick comparison

Capturing memory

If you decide the investigation needs RAM, do it first, before anything else on the system. Common capture methods on Linux:

# 1. /dev/mem or /dev/kmem - raw, often restricted
dd if=/dev/mem of=ram.mem bs=1M

# 2. LiME (Linux Memory Extractor) - kernel module, recommended
insmod lime-<version>.ko "path=/evidence/ram.lime format=lime"

# 3. fmem - driver exposing /dev/fmem
insmod fmem.ko
dd if=/dev/fmem of=ram.dd bs=1M

# verify it's a sane dump
file ram.lime
sha256sum ram.lime

Analyze the dump with Volatility, which knows how to read LiME format natively and can also handle raw dd dumps given a profile.

Legal & practical checks

• Do you have authorization? Get sign-off in writing before touching a live system — you can't un-run a command.
• Note the system clock and timezone — Linux logs are typically UTC in the journal, local time in some files.
• Label everything: drive serial, interface, ports, cables.
• Document your decisions and why you made them. A written rationale is half your defense.

← Previous: Introduction to Linux Forensics  ·  Next: Recovering Deleted Files on ext4 →