Linux Memory Acquisition

Linux memory acquisition with LiME (kernel module, format-aware) and AVML (single binary, source-portable). Includes ISF generation with dwarf2json so Volatility 3 can interpret the dump. Linux memory acquisition is harder than Windows because every kernel needs its own symbol file generated locally.

Side: blue

Tool selection

Situation	Tool
Build toolchain available, kernel headers installable, target stable	LiME — preserves per-range address-space metadata via `format=lime`
Target is restricted, no build environment, in-and-out fast	AVML — single x86_64 binary, no compilation
Disk is itself evidence or target has no free space	LiME `path=tcp:<port>` — stream over network
Target on Azure / cloud, network egress allowed	AVML `--url` / `--sas-url` — direct upload
Kernel is custom-built (no distro debug package)	document constraint; dump may be unanalysable without target’s vmlinux

LiME’s repo was archived May 2024. Still works on current Kali / Debian. AVML is actively maintained.

LiME — compile and dump

LiME is a kernel module. It must be compiled against the running kernel.

uname -r                                                  # confirm kernel version, e.g. 6.12.13-amd64
 
sudo apt install -y linux-headers-$(uname -r) build-essential
git clone https://github.com/504ensicsLabs/LiME
cd LiME/src
make
# build output: lime.ko -> lime-6.12.13-amd64.ko

Use $(uname -r) instead of hardcoded version — survives kernel upgrades. build-essential pulls gcc, make, libc-dev.

Dump

sudo insmod ./lime-<kernel>.ko path=dump.mem format=lime timeout=0
ls -la dump.mem                                           # size should match RAM allocation
sudo lsmod | grep lime                                    # confirm loaded
sudo rmmod lime                                           # unload when done

Parameter	Why
`path=dump.mem`	output file. LiME writes full physical memory here
`format=lime`	preserves per-range metadata so Volatility maps captured pages back to virtual addresses. `raw` loses this; `padded` is bigger
`timeout=0`	disables the 1000ms per-page read timeout. Forensics needs every page, not “most pages quickly” — without this LiME silently skips slow ranges

The module name (lime) and the .ko filename are different. lsmod shows the module name to pass to rmmod.

Network mode (no disk writes on target)

# on target
sudo insmod ./lime-<kernel>.ko path=tcp:4444 format=lime timeout=0
 
# on analysis host
nc <target-ip> 4444 > dump.mem

LiME closes the connection when the dump finishes. Trust trade-off: any passive listener on the network path sees full memory contents. Network bandwidth is the bottleneck.

AVML — single binary

mkdir ~/avml && cd ~/avml
wget https://github.com/microsoft/avml/releases/download/v0.14.0/avml
chmod +x ./avml
 
sudo ./avml memory.dmp                                    # raw output, no format choice
sudo chown $USER:$USER memory.dmp                         # so analyst can read without sudo

Source selection

--source picks which kernel interface AVML reads from. If unspecified, AVML tries each in order and uses the first that succeeds.

Source	When
`/dev/crash`	RHEL/CentOS with crash dump driver loaded — safest
`/dev/mem`	classic direct physical memory device — often disabled on modern distros (`CONFIG_STRICT_DEVMEM`)
`/proc/kcore`	ELF view of kernel memory — broad compatibility, sometimes restricted

Direct upload (informational)

sudo ./avml --url https://analysis.example/upload memory.dmp
sudo ./avml --sas-url 'https://...storage...' --delete memory.dmp

Useful on hosts with tight disk but open egress. Same passive-listener trust concern as LiME tcp mode.

ISF generation (dwarf2json)

Volatility 3 needs kernel symbols to interpret a Linux dump. Windows gets these from Microsoft’s symbol server. Linux gets them from you, locally, against the target’s kernel.

Install the matching debug kernel

sudo apt install -y linux-image-amd64 linux-image-amd64-dbg
ls /usr/lib/debug/boot/                                   # confirm vmlinux-<kernel> exists

The standard installed kernel is stripped. The -dbg variant adds a separate vmlinux with full DWARF debug info at /usr/lib/debug/boot/vmlinux-<kernel>.

Build dwarf2json

cd ~
git clone https://github.com/volatilityfoundation/dwarf2json.git
cd dwarf2json
sudo apt install -y golang-go
go build .

Generate the ISF

./dwarf2json linux \
  --elf /usr/lib/debug/boot/vmlinux-$(uname -r) \
  --system-map /boot/System.map-$(uname -r) \
  > isf-$(uname -r).json
 
ls -la isf-*.json                                          # ~50 MB typical for amd64

Input	Provides
`--elf`	debug kernel binary — struct layouts, type definitions, field offsets
`--system-map`	symbol-name to virtual-address mapping

Tag the output with the kernel version. ISFs are kernel-specific — different kernels need different ISFs.

Mismatched kernels

If the analysis VM’s kernel differs from the target’s, install the target’s debug package explicitly and hardcode the version:

sudo apt install -y linux-image-<target-version>-dbg
./dwarf2json linux \
  --elf /usr/lib/debug/boot/vmlinux-<target-version> \
  --system-map /boot/System.map-<target-version> \
  > isf-<target-version>.json

Do not use $(uname -r) here — it would expand to the analysis host’s kernel.

Wire ISF into Volatility 3

git clone https://github.com/volatilityfoundation/volatility3.git
mkdir -p volatility3/volatility3/symbols/linux
cp ~/dwarf2json/isf-$(uname -r).json volatility3/volatility3/symbols/linux/
 
cd volatility3
./vol.py isfinfo                                           # should list the ISF and identify the kernel

The output identifying string echoes the kernel build info — match against the dump’s uname -a (if known) to confirm you have the right ISF.

Triage commands (pointer)

./vol.py -f dump.mem linux.pslist                          # process list
./vol.py -f dump.mem linux.bash                            # recovered bash history from memory
./vol.py -f dump.mem linux.netstat                         # network connections
./vol.py -f dump.mem linux.lsof                            # open files

For the full plugin set, see Volatility 3’s plugin docs.

Pitfalls

LiME without timeout=0 silently skips pages that take longer than 1000ms. Always set it for forensic capture.
insmod of LiME built against the wrong kernel can panic the target. Use AVML if there is any doubt.
AVML default source order works on most Kali / Debian. If it fails, try --source /proc/kcore explicitly — /dev/mem is restricted on hardened hosts.
ISF generation can OOM during DWARF parsing. The activity prerequisites call for 4 GB VM RAM; if the output is 0 bytes, raise memory allocation.
ISFs are not portable across kernels. A 6.12.13-amd64 ISF will not work on a 6.12.14-amd64 dump.
.vmem from a suspended VM is a raw image — Volatility reads it directly, no LiME / AVML needed. Generate the ISF for the guest’s kernel if Linux.
Hash the dump immediately (md5sum dump.mem) and record the hash plus the exact acquisition command. Both go into the evidence record.

links:

Field Manual | Memory Forensics | Data Acquisition | Data Recovery

DFIR-Field-Manual

Explorer