LX1.6 Memory Acquisition with LiME

LiME is a loadable kernel module (LKM). Like all kernel modules, it must be compiled for the exact kernel version running on the target system. A module compiled for kernel 5.15.0-91-generic will not load on kernel 5.15.0-88-generic — the kernel rejects modules compiled for a different version (unless module signature enforcement is disabled, which it should not be on production servers).

This means you cannot download LiME during an incident and compile it for the target. By the time you determine the kernel version, find the kernel headers, compile the module, and transfer it to the target, you have lost 30–60 minutes of volatile evidence. The solution: pre-compile LiME for every kernel version in your infrastructure and store the compiled modules in your IR toolkit.

The practical approach: maintain a script that runs monthly, queries every Linux server in your infrastructure for its kernel version (uname -r), and compiles LiME for any new versions. Store the compiled modules on your forensic workstation, on a USB drive in your IR kit, and in a shared network location accessible during incidents.

Acquisition Procedure

When you arrive at a compromised system with a pre-compiled LiME module, the acquisition procedure takes 5–15 minutes depending on the amount of RAM.

Method 1: Dump to network (preferred — no writes to compromised disk)

The format=lime parameter creates a LiME-format dump that includes memory range metadata — Volatility 3 and other analysis tools can read this format directly. The path=tcp:4444 parameter streams the memory contents over TCP to your workstation. No data is written to the compromised system's disk. The only modification to the compromised system is loading the kernel module (which allocates kernel memory and appears in lsmod).

Method 2: Dump to local file (when network dump is not feasible)

This method writes the memory dump to the USB drive (or other external media) mounted on the compromised system. It is faster than network transfer (no TCP overhead) but requires sufficient space on the external media — a system with 64GB RAM produces a ~64GB memory dump.

Method 3: Dump to remote filesystem via SSH (fallback)

What Happens When LiME Is Not Available

If you do not have a pre-compiled LiME module for the target's kernel version — a common situation with unmanaged servers, cloud instances with auto-updated kernels, or systems where you did not proactively prepare — you have limited alternatives.

/proc/kcore is a pseudo-file that represents the kernel's virtual address space. On systems where it is accessible (not all hardened kernels expose it), you can copy it: sudo dd if=/proc/kcore of=/mnt/usb/kcore bs=1M. The limitation: /proc/kcore is a virtual memory representation, not physical memory. It contains the kernel's view of memory, which includes unmapped regions that appear as zeros. It is significantly harder to analyze than a LiME dump and not all Volatility 3 plugins work correctly with /proc/kcore input.

/dev/mem provides access to physical memory on older kernels. Modern kernels (4.x+) restrict /dev/mem access to the first 1MB by default (controlled by CONFIG_STRICT_DEVMEM). This is insufficient for forensic analysis. On systems where CONFIG_STRICT_DEVMEM=n, you can read physical memory: sudo dd if=/dev/mem of=/mnt/usb/devmem.raw bs=1M. But this configuration is rare on modern production systems.

Compile LiME on the compromised system (last resort). If kernel headers are installed on the compromised system and you have no other option: apt install linux-headers-$(uname -r) && cd /tmp/LiME/src && make. This modifies the compromised system significantly (package installation, compilation, disk writes) and should only be done when the alternative is no memory evidence at all. Document every step and every modification.

Skip memory acquisition. If none of the above options are viable, document that memory was not acquired and why, then proceed to Phase C (live volatile collection). You can still capture significant volatile data from /proc — running processes, network connections, open files — using the live response commands from LX1.2. You will not be able to detect hidden rootkit processes (which require kernel-level memory analysis) or recover deleted binaries from process memory (which requires a full memory dump).

Forensic Implications of Loading a Kernel Module

Loading LiME is itself a forensic action that modifies the system. The modifications:

The module is loaded into kernel memory — this modifies the kernel's module list and allocates kernel memory. The insmod command execution may appear in the audit log (if auditd is monitoring module loads). The kernel ring buffer (dmesg) records the module load event. The module's memory acquisition process reads every page of physical memory sequentially — this does not modify memory content, but the act of reading may update CPU cache state and TLB entries.

These modifications are minimal compared to the evidence value of the memory dump. The key requirement is documentation: record when you loaded the module, which module file you used, and when you removed it. This information goes into the chain of custody log.

On systems with Secure Boot enabled, unsigned kernel modules may be rejected. LiME modules are not signed by default. If Secure Boot is blocking the module load (insmod: ERROR: could not insert module: Required key not available), you have three options: disable Secure Boot in BIOS/UEFI (requires physical access and a reboot — which destroys the memory you are trying to capture), sign the LiME module with a Machine Owner Key (MOK) that is enrolled in the system's firmware (must be done proactively), or use /proc/kcore as a fallback.

Worked artifact — LiME pre-compilation and readiness checklist:

Maintain this checklist monthly. When the incident call comes, your LiME readiness determines whether you capture memory or skip it.

Organization: Northgate Engineering Last updated: [date] Maintained by: [name]

Infrastructure kernel inventory:

BASTION-NGE01: Ubuntu 22.04, kernel 5.15.0-91-generic. LiME compiled: ☐ Yes ☐ No. Module at /toolkit/lime/ WEBSRV-NGE01: Ubuntu 22.04, kernel 5.15.0-91-generic. LiME compiled: ☐ Yes ☐ No. Module at /toolkit/lime/ DBSRV-NGE01: RHEL 9.2, kernel 5.14.0-284.el9. LiME compiled: ☐ Yes ☐ No. Module at /toolkit/lime/ K8S-NGE-node01: Ubuntu 22.04, kernel 5.15.0-97-generic. LiME compiled: ☐ Yes ☐ No. Module at /toolkit/lime/

Pre-compilation script runs: ☐ Monthly cron ☐ Manual ☐ Not scheduled

Modules stored at: ☐ Forensic workstation ☐ USB IR kit ☐ Network share ☐ All three

Secure Boot status: ☐ Disabled (LiME loads without signing) ☐ Enabled — MOK enrolled for LiME ☐ Enabled — no MOK (LiME will be rejected)

Last test acquisition: [date] On system: [hostname] Result: ☐ Success ☐ Failed (reason: ___)

Decision points: choosing the acquisition method

Network access to forensic workstation is available: Use Method 1 (TCP dump to workstation). This is the cleanest acquisition — zero bytes written to the compromised system's disk. The memory streams directly from kernel space to your workstation over TCP.

No network path between target and forensic workstation (air-gapped, firewalled): Use Method 2 (dump to USB drive). Requires physical USB access or a mounted external volume. The dump writes to external media, not to the compromised disk. Ensure the USB drive has sufficient free space — a 64GB system produces a ~64GB dump.

SSH is the only access method (cloud VM, remote server, no USB): Use Method 3 (SSH pipe). This combines LiME's TCP output with SSH tunneling. The dump passes through the SSH connection to your workstation. Slower than direct TCP (SSH encryption overhead) but works through firewalls and NAT.

Target kernel version not in your LiME inventory: Follow the fallback chain: /proc/kcore if accessible, compile on target as last resort, or skip memory and document. Do not spend 30+ minutes resolving the LiME issue while other volatile evidence degrades — start live volatile collection (Phase C) in parallel.

Cloud VM with hypervisor-level memory access (rare): If the cloud provider offers memory capture from the hypervisor (some specialized forensic services provide this), use it — it captures memory without any modification to the guest VM. Check with your provider before the incident.

Troubleshooting: common memory acquisition issues

insmod: ERROR: could not insert module: Required key not available. Secure Boot is enabled and the unsigned LiME module is rejected. Options: check if a MOK (Machine Owner Key) is enrolled that can sign the module with mokutil --list-enrolled, use /proc/kcore as a fallback, or if physical access is available disable Secure Boot in BIOS/UEFI — but this requires a reboot which destroys the memory you are trying to capture. In practice, Secure Boot blocking is unrecoverable for memory acquisition unless you proactively enrolled a MOK.

insmod: ERROR: could not insert module: Invalid module format. The LiME module was compiled for a different kernel version than the one running on the target. Verify: modinfo lime-*.ko | grep vermagic shows the compiled version, uname -r shows the running version. They must match exactly. If they do not, check your toolkit for other versions.

Memory dump file is much smaller than expected (e.g., 2GB on a 32GB system). The dump may have been interrupted (network timeout, process killed, disk full). Check if LiME is still loaded: lsmod | grep lime. If it is, the dump may still be in progress. If LiME was removed but the file is too small, restart the acquisition. Some cloud VMs use memory ballooning where the hypervisor reclaims unused memory — the physical memory may be less than allocated RAM.

nc is not available on the forensic workstation for Method 1. Use ncat (from the nmap package), socat, or redirect through SSH: on the target run sudo insmod lime.ko "path=tcp:4444 format=lime", then from your workstation use ssh -L 4444:localhost:4444 target and nc localhost 4444 > memory.lime through the tunnel.

Memory dump completes but Volatility 3 cannot parse it. Ensure you used format=lime (not format=raw or format=padded). LiME format includes memory range metadata that Volatility needs to correctly map physical addresses. Also verify the dump was not truncated during transfer — compare file size against expected RAM size.