Kali Linux Forensics Mode: How It Works & Evidence Workflow

What is Kali Linux forensic mode?

Kali Linux forensic mode is a boot option in the Kali Live image that disables automatic mounting of internal disks and removable media, and avoids using an internal swap partition. It is designed to reduce unintended changes to evidence when starting a forensic workstation.

It is not a hardware write blocker, and it does not automatically establish chain of custody. An operator can still change a disk by mounting it with write access or running a command against the wrong device. Validate your exact boot media, hardware and tools before using them for an investigation.

Forensic mode versus a normal Kali Live session

• Internal disks: forensic mode does not auto-mount them.
• Internal swap: an existing swap partition is not used.
• Removable media: inserted USB drives and other removable media are not auto-mounted.
• Manual actions: commands still run with the permissions you give them. The boot option cannot prevent every operator mistake.

These behaviors are described in the official Kali forensic mode documentation. Kali recommends validating forensic tools rather than assuming that a feature works identically in every environment.

How to start and check forensic mode

1. Prepare and verify a Kali Live image using the official image download instructions. Forensic mode is a Live boot option, not a setting that retroactively protects disks in a running installation.
2. Boot from the Live media and select the forensic-mode option in its boot menu. The wording can vary by release.
3. Record the Kali version, boot media, workstation, date, time zone and connected storage devices.
4. Inspect mounted filesystems and active swap before accessing evidence.

# Inspect device names and mount points
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS

# Show mounted filesystems and active swap
findmnt
swapon --show

These commands report state; they do not make a mounted evidence disk read-only. If evidence is already mounted or swap is active on an evidence device, stop and investigate the setup before proceeding. Practice first with a disposable test disk containing known files.

An image-and-hash workflow for a practice investigation

Start with a training image or a disk you are authorized to examine. Identify the source device and a separate destination with enough capacity. Use a validated acquisition tool and, where appropriate, a hardware write blocker. Avoid copying a generic disk-imaging command without checking its source and destination: reversing them can destroy data.

1. Identify: record the source device model, serial number, capacity, case identifier and who supplied it.
2. Acquire: create a forensic image and retain the acquisition log, including tool version, start/end times and any read errors.
3. Verify: calculate a cryptographic hash such as SHA-256. For a raw, complete, error-free bitstream image, a source hash and image hash should match when measured over the same bytes. Container formats require their own verification procedure.
4. Preserve: retain a protected master image and record its hash.
5. Analyze: work on a separate copy and save results to a separate output location.

# Example: hash an existing practice image, not a live device
sha256sum practice-disk.img

# Save a hash record and verify that image later
sha256sum practice-disk.img > practice-disk.img.sha256
sha256sum -c practice-disk.img.sha256

A matching hash supports integrity verification between two measurements. It does not prove who created a file, that an acquisition was complete, or that evidence was handled correctly before the first measurement.

What to record in a chain-of-custody log

Use an evidence identifier, collector name, acquisition time and time zone, device details, image location, hash algorithm and value, tool versions, transfers between people, and the purpose of each transfer. Keep observations separate from conclusions so another analyst can reproduce your reasoning.

Disk forensics and memory forensics are different

A disk image contains persistent storage. A memory image captures volatile state and normally requires a separate acquisition step. Booting a machine into another operating system changes its memory state, so decide whether live memory collection is required before shutting down or rebooting a relevant system.

For memory analysis, follow the documentation for your installed framework and version. Old Volatility 2 commands using profiles should not be presented as universal commands for Volatility 3. Identify the image format and supported operating system before choosing plugins.

Practice task: create a small evidence report

Use a disposable training image. Record its SHA-256 hash, identify its partitions and filesystem, list three observable artifacts, and write a short report describing what each artifact does and does not establish. Include your commands, tool versions and output paths. Another learner should be able to repeat the work from your notes.

Continue learning

Explore the digital forensics course for evidence collection, disk and memory analysis, and reporting topics. For network-based evidence, read our network forensics guide. New to the environment? Start with the Kali Linux beginner guide.