MF1.3 Linux Acquisition with LiME and AVML

LiME — kernel module acquisition

This section covers the tool the course uses for Linux captures. The kernel-module architecture is LiME's strength and its constraint — understand both before you compile.

LiME (Linux Memory Extractor) is a loadable kernel module that reads physical memory through the kernel's internal page-mapping interface. Because it runs inside the kernel, it has the same level of access as the kernel itself — no page is off-limits, no mapping is restricted. This gives LiME the highest-fidelity read possible on a Linux system.

The cost is version coupling. Linux kernel modules are compiled against specific kernel headers, and the resulting .ko file contains a vermagic string that must exactly match the running kernel's version. insmod checks this string before loading the module and rejects mismatches. There is no cross-version compatibility, no "close enough" — the version must be identical down to the patch level and any distribution-specific suffix.

For the course's Target-Linux VM (Ubuntu 22.04 with a kernel you control), this isn't a problem. You install the kernel headers for your running kernel, compile LiME, and the module loads.

For production incident response against a server whose kernel version you didn't prepare for, this is a significant constraint. The options are: pre-build LiME modules for every kernel version in your fleet and carry them on your IR toolkit USB drive, compile on the target (which requires build-essential and headers, adding forensic footprint), or use AVML instead.

LiME supports three output modes. Disk output writes to a local file in LiME's own format, which Volatility 3 reads natively:

sudo insmod lime.ko "path=/evidence/mem.lime format=lime"

Raw padded output writes a raw image with zero-filled gaps for non-addressable physical ranges — similar to WinPmem's raw output but for Linux:

sudo insmod lime.ko "path=/evidence/mem.raw format=padded"

Network output streams the memory image over a TCP socket to a remote listener, avoiding any disk writes on the target:

# On analysis workstation (listener):
nc -l -p 4444 > target.lime

# On target (sender):
sudo insmod lime.ko "path=tcp:4444 format=lime"

Network capture is LiME's killer feature for minimal-footprint acquisition: the module loads, reads memory, streams the data to your analysis workstation, and unloads without ever writing to the target's filesystem.

AVML — userspace acquisition without kernel module constraints

This section covers the alternative when LiME's kernel-version coupling makes it infeasible. AVML trades slightly higher smear for dramatically broader compatibility.

AVML (Acquire Volatile Memory for Linux) is Microsoft's open-source Linux memory acquisition tool. Unlike LiME, AVML runs entirely in userspace — it reads memory through /proc/kcore, a pseudo-file the kernel exposes that represents physical memory as a virtual file.

Because AVML doesn't load a kernel module, it doesn't have a version-coupling constraint. The same AVML binary works on any Linux kernel that exposes /proc/kcore, which is most standard distributions.

The tradeoff is fidelity. A userspace read through /proc/kcore goes through the kernel's page-fault handler and mapping infrastructure rather than reading physical pages directly. AVML's capture is subject to slightly more smear than LiME's kernel-level read, because the userspace read path is longer and involves more kernel scheduling points.

In practice, the difference is small on systems with reasonable load — both tools produce images with comparable analysis results. The difference matters most on heavily loaded servers where the extra scheduling overhead produces measurably more torn structures.

AVML's constraint is that /proc/kcore must be accessible. Some hardened distributions restrict access (setting it to mode 0400 or disabling it via CONFIG_PROC_KCORE=n). Containerised environments and minimal kernel configurations may not expose it at all. When /proc/kcore isn't available, you're back to LiME or hypervisor-based acquisition.

The command is straightforward — download the static binary, make it executable, run with root:

sudo ./avml /evidence/target-linux.lime

AVML writes LiME-format output by default, which Volatility 3 reads natively. No compilation step, no kernel headers, no version matching. Hash the output immediately after capture.

When to use which — the Linux acquisition decision

This section gives you the decision rule. Don't memorise it — understand why each branch exists, and the decision falls out naturally.

The decision between LiME and AVML maps to the same fidelity-footprint-feasibility frame from MF1.1, with Linux-specific constraints layered on top.

Use LiME when you control the kernel version or have pre-built the module. The course lab is the canonical example: you installed Ubuntu 22.04 on Target-Linux, you know the kernel version, you can compile LiME against it. Production environments where you maintain a fleet of identical servers (same distribution, same kernel, same patch level) are similarly suited — pre-build LiME modules for your fleet's kernel versions and carry them on the IR toolkit. LiME's kernel-level read provides the highest fidelity, and the network output mode provides the lowest disk footprint.

Use AVML when you can't match the kernel version. Heterogeneous server estates, unfamiliar systems during incident response, cloud VMs where you don't control the kernel build, containerised environments where you have host access but not the kernel headers — AVML's single-binary portability solves the version-coupling problem. The fidelity tradeoff is acceptable for most investigations.

Use hypervisor-based acquisition (MF1.4) when you have hypervisor access. Same logic as Windows: zero guest footprint, zero version coupling, highest fidelity. VMware .vmem capture works identically for Linux guests and Windows guests.