Shufflecake on Linux: what deniable, multi-layer volumes mean for DFIR

Shufflecake implements plausible deniability on Linux by scattering several independently-keyed volumes across what looks like random free space, making both the existence and the number of volumes hard to prove in deadbox exams. The design ships as a device-mapper target (kernel module) plus a userland CLI, with volumes exposed as virtual block devices under /dev/mapper when opened (Shufflecake project site). The project originated at Kudelski Security and EPFL in November 2022 (Kudelski Security blog), and the research was later peer-reviewed at ACM CCS 2023 (Shufflecake ePrint).

Shufflecake’s core properties matter for forensics: headers and position maps are encrypted and intended to be indistinguishable from noise; each hidden volume is opened with a distinct key; and the system can present up to 15 volumes per device with overcommitment, so any unopened volumes remain indistinguishable from unused space (Shufflecake project site)(Shufflecake ePrint). Compared to ORAM-style designs, Shufflecake prioritizes speed over multi-snapshot resistance; the authors explicitly note it does not natively protect against a multi-snapshot adversary (Shufflecake ePrint).

Here’s why this matters for forensics: deadbox entropy tests won’t help much, but live-capture footprints (module loads, dm tables, mounts, and userland execution) usually will.

Overview

The following isn’t an intrusion chain so much as the operational flow you should model during response. Knowing these steps tells you where artifacts will exist:

1. Initialize a device

• Shufflecake ‘init’ overwrites the device with random data, writes an encrypted header with slots for up to 15 volumes, and builds a per-volume position map. Unused header slots are also random, masking how many volumes exist (Shufflecake project site)(Shufflecake ePrint).

2. Open one or more volumes

• Providing one password unlocks its slot and automatically unlocks all less-hidden volumes in the chain; volumes appear as mappable devices under /dev/mapper and can be formatted/mounted like normal (Shufflecake project site).
• On typical installs the kernel component is a device-mapper target loaded via a module (packaged as dm-sflc in community builds), and the CLI is invoked as shufflecake (Arch Linux AUR)(MakeTechEasier guide).

3. Use and close

• Volumes behave like normal block devices while open. Closing the device tears down the mappings (Shufflecake project site).
• Overcommitment means each volume can appear full-size even if the total exceeds the physical medium; writes beyond aggregate capacity return I/O errors, a potential clue in kernel logs (Shufflecake ePrint).

Threat model note

• The design aims for plausible deniability against single-snapshot adversaries. It does not inherently protect against adversaries who can compare multiple snapshots over time; the paper discusses add-on ideas for that but it’s not native (Shufflecake ePrint).

Operational leakage note

• Prior work on deniable filesystems shows that OS and application traces often betray hidden-volume usage once mounted (recent files, app caches, link files, previews, etc.). The lesson carries over: deniability of storage isn’t deniability of usage traces (USENIX HotSec'08 paper).

Artifact Locations and Paths

Here’s what we’d pull first in a live capture before power-off. Expect noisy evenings and brittle tooling - prioritize collection over perfect parsing.

• Device-mapper state

  • dmsetup ls and dmsetup table --showkeys (keys only if target exports them) to enumerate mappings and target types; you can also filter by target with dmsetup ls --target <type> (dmsetup manual).
  • ls -l /dev/mapper and lsblk -o NAME,TYPE,FSTYPE,MOUNTPOINTS,UUID to catch active sflc-named nodes if present (community guides show names like sflc_0_2) (MakeTechEasier guide).

• Kernel modules and kernel messages

  • cat /proc/modules | grep -i sflc, lsmod | grep -i sflc for the Shufflecake device-mapper target (often built/installed as dm-sflc) (Arch Linux AUR).
  • journalctl -k --since -2h and dmesg for device-mapper attach/detach messages and I/O errors (overcommitment can surface as I/O errors during stress) (Shufflecake ePrint).

• Mounts and block device activity

  • cat /proc/self/mountinfo, findmnt -rno TARGET,SOURCE,FSTYPE,OPTIONS, and mount output around the time of suspicion; active Shufflecake volumes appear as mapper devices (dmsetup manual).

• Userland execution traces

  • Running processes: ps aux | grep -i shufflecake and shell history (~/.bash_history, Zsh history). Packaging logs for installs/updates: Debian/Ubuntu (/var/log/dpkg.log*), Arch (/var/log/pacman.log).

• Memory

  • If volumes are open, acquire RAM (LiME/AVML/EDR memory capture) before teardown; device-mapper targets and keys are managed in-kernel, and dm state is inspectable live on the box. Use the live tables plus process/module context to steer post-processing. dmsetup table is the authoritative in-kernel view (dmsetup manual).

• Audit trail for kernel module loads (preconfigure where possible)

  • Ensure audit rules for init_module/finit_module to capture module activity during future events; STIG guidance provides ready-to-use examples: -a always,exit -F arch=b64 -S init_module,finit_module -F auid>=1000 -F auid!=unset -k module_chng (and a matching b32 rule) (RHEL 9 STIG).

Analysis and Correlation

• Disk entropy won’t prove hidden volumes exist

  • Shufflecake’s header and position maps are designed to be indistinguishable from random noise; unopened volumes look like unused space (Shufflecake ePrint). Deadbox entropy scans are low-value here.

• Look for live device-mapper evidence

  • If the kernel target is loaded and volumes are open, dmsetup will show mapper devices and target types; all active volumes present under /dev/mapper (dmsetup manual).

• Multi-snapshot advantage (if you have it)

  • The authors state Shufflecake does not natively defend against multi-snapshot adversaries; collect historical images where legally and operationally possible to compare block-level allocation and detect inconsistent slice placement over time (Shufflecake ePrint).

• OS/application traces will still talk

  • Once a hidden volume is mounted, normal applications leak traces (recent files, thumbnails, editor caches). This is a classic failure mode for deniable storage - the 2008 TrueCrypt study remains a useful reminder when building hunts (USENIX HotSec'08 paper).

• Naming and process hints

  • Community usage shows shufflecake open /dev/<device> and mapper nodes like /dev/mapper/sflc_0_<n> when volumes are open (MakeTechEasier guide). Treat these as strong leads, not proof of count.

Validation and Pitfalls

• Prioritize a calm live triage before shutdown

  • Collect: dm tables, /dev/mapper listing, process list, loaded modules, recent kernel logs, mount tables, package logs, and shell history. Script it to reduce errors under pressure.

• If you must image the disk

  • Document write-blocking and baseline: note that unopened Shufflecake volumes will be indistinguishable from random space. Don’t expect post-facto carving or entropy analysis to surface them (Shufflecake ePrint).

• If volumes are open

  • Mount points and mapper nodes are in scope for acquisition. Grab RAM if policy allows. Export dm tables (dmsetup table --concise) and note target types/timestamps (dmsetup manual).

• Prepare your environment ahead of time

  • Add audit rules for kernel module loads (init_module/finit_module) to catch future Shufflecake module activity (RHEL 9 STIG). If you run EDR on Linux, ensure it collects process creation, module loads, and block-device operations.

• Legal and policy

  • Remember: plausible deniability means you may not be able to prove additional volumes exist from a single snapshot. Where appropriate, pursue lawful multi-snapshot or corroborating host/app evidence (Shufflecake ePrint).

Takeaways

• Expect deniable volumes to look like random free space; plan on live capture, not deadbox entropy tests (Shufflecake ePrint).
• On Linux, your strongest signals are device-mapper state, kernel module loads, and mounts under /dev/mapper (dmsetup manual).
• Pre-deploy audit rules for module loads to create investigative signal at the moment it matters (RHEL 9 STIG).
• If you can lawfully collect multiple snapshots over time, do it - Shufflecake does not natively defeat multi-snapshot analysis (Shufflecake ePrint).
• Hunt the userland: shufflecake CLI execution, package install logs, and application traces often provide the pivot you need (MakeTechEasier guide).