FAQ
Questions about NAILS
Short answers about what NAILS does, where it stops and how to set it up. NAILS narrows what an offline examination of the decoy can find. The hidden volume and any deniability it has come from the storage backend you choose.
What NAILS is
What is NAILS?
NAILS is a command-line tool that runs a hidden session on an ordinary-looking Linux system, the decoy. It soft-reboots the machine into one overlay over the whole decoy root, so changes made in the hidden session are written to an encrypted hidden volume that you provide. A second soft-reboot takes you back to the plain decoy, and nothing that starts the hidden session is installed on it. NAILS is alpha software for NixOS, Debian 13, Ubuntu 24.04 and Ubuntu 26.04.
Is NAILS anti-forensics software?
Only in a narrow sense. NAILS narrows what an offline examination of the decoy can find. After a clean session on a correctly prepared decoy, the decoy disk holds nothing of the hidden session except a short, documented list of residual channels. NAILS gets there by keeping the session off the decoy disk, not by removing traces afterwards. It never touches a journal on the decoy disk, because destroyed log history is itself a tell, and it cannot clean up what happens before it runs. NAILS does not make you invisible, it encrypts nothing, and any deniability of the hidden volume comes from the storage backend you choose.
What anti-forensics means for NAILS
Is NAILS a hidden operating system like VeraCrypt's?
No. The hidden session is the decoy's own system started again on the same kernel, or on NixOS a hidden generation of it, with its writable layer on your hidden volume. It gets no separate machine, kernel, account or online identity, and nothing that starts it is installed on the decoy, not even a boot entry. A VeraCrypt hidden operating system is installed in a hidden volume, in the partition behind the decoy system's partition. As of October 2026, VeraCrypt says its system encryption supports only Windows.
How NAILS compares with VeraCrypt, Tails and Shufflecake
How is NAILS different from Tails?
Tails says it is designed to be a live system that runs from a USB stick or DVD, and that its recommended installation methods cannot install it permanently on a hard disk. NAILS is not a live system. It runs a hidden session of the Linux system installed on your computer, the session's changes persist on the hidden volume between sessions, and the session shares the decoy's network identity. Tails is one place to do the first installation of NAILS, outside the decoy system.
How NAILS compares with VeraCrypt, Tails and Shufflecake
Deniability and limits
Does NAILS give me plausible deniability?
Not by itself. Any deniability comes from the storage backend you choose, such as a VeraCrypt hidden volume, and NAILS adds nothing to the backend's claim. NAILS narrows what an offline examination of the decoy can find, but it does not hide setup traces such as encryption tooling, and removing or explaining them is up to you. An examiner may still believe a hidden volume exists without being able to prove it, and coercion beyond one unlock of the decoy is out of scope.
If you are made to unlock the decoy
Can an examiner who knows NAILS tell that it was used?
NAILS is public, and its threat model does not count on the examiner not knowing it. A knowledgeable examiner looks for NAILS's own files and markers, a sudo record that names a binary on another volume, encryption tools with recent access times and random-looking disk space. NAILS keeps its own files and markers off the decoy and reports the others, so you can remove or explain them beforehand. Whether they have a plausible explanation is yours to establish, and the examiner may still believe a hidden volume exists without being able to prove it.
An examiner who knows NAILS List the setup traces an examiner looks for
Does NAILS encrypt anything or hide that a hidden volume exists?
No. NAILS encrypts nothing itself and never unlocks or mounts the hidden volume, and whether a hidden volume can be found depends on your backend. A LUKS volume is visibly an encrypted volume, while VeraCrypt's hidden volume documentation says it should be impossible to prove that a hidden volume exists, provided its instructions and security requirements are followed. NAILS adds nothing to the backend's claim and keeps the session off the decoy.
The hidden volume and its backends
What does NAILS not protect against?
NAILS is built for someone with offline access to the disks after the fact, who may make you unlock the decoy once. It does not protect against:
- anyone with access to the running machine, memory forensics or cold-boot attacks
- being made to disclose the hidden volume, physical or repeated coercion, or someone who images the disk more than once and compares the images
- a persistent decoy, whose journal, syslog or audit log records the soft-reboots on its disk (activation refuses one unless you override it)
- firmware or hardware compromise, keyloggers, side channels or a compromised root account on the decoy
- records kept by network providers, VPNs and online services
- operator mistakes, such as skipping deactivation or leaving the hidden volume mounted
What NAILS does not protect against
Does NAILS hide my network activity?
No. The hidden session shares the decoy's kernel, machine ID, hostname and MAC addresses,
and by default its user account and home. Internet providers, VPNs and online services see
whatever it does, and their records are out of scope. Links, addresses, routes and VPN
tunnels the session set up also stay in the decoy until power-off, and the decoy's
NetworkManager records a link the session created on the decoy disk as soon as the decoy
starts. Take down what you brought up and delete the links you created before you
deactivate, or end the session with nails deactivate --poweroff.
What the hidden session shares with the decoy
Why power off after a session?
A soft-reboot back to the decoy keeps the kernel running, and a warm reboot does not clear
RAM either. Until the machine powers off, RAM holds data from the hidden session, as well
as signs of the switch such as the kernel ring buffer, the soft-reboot counter on systemd
256 and newer, and an unchanged boot ID and uptime. nails deactivate --poweroff also powers off before the decoy's NetworkManager can record a network link the session created.
Leave the machine off for a few minutes before you hand it over.
Setup and platforms
Which distributions are supported?
NixOS, Debian 13, Ubuntu 24.04 and Ubuntu 26.04, with systemd 254 or newer, on x86-64. On Ubuntu 26.04, chrony and CUPS fail in the hidden session, and the decoy shows chrony as failed until a full reboot. A later Debian or Ubuntu release runs with a warning that NAILS has not been tested on it, and Debian and Ubuntu derivatives are accepted provisionally. Fedora, Arch, Debian 12, Ubuntu 22.04, image-based systems and systems without systemd are refused, and Fedora and Arch support is planned but not available.
Does NAILS still work on NixOS?
Yes. NixOS is the first-class platform. A declarative hidden NixOS configuration is built
into the hidden root's store and entered in the same soft-reboot, with no bootloader
install and no change to the decoy's system profile. The decoy root must stay on a disk,
so a tmpfs root, such as impermanence on /, is refused. A /var or
/home on its own tmpfs, wiped at boot, is fine. On NixOS as elsewhere, NAILS narrows
what an offline examination of the decoy can find, and any plausible deniability comes from
the backend of the hidden volume.
How the hidden session works on NixOS
Which storage backends work?
Two encrypted backends are tested: LUKS2 with ext4 on a whole block device, and a VeraCrypt hidden volume opened with cryptsetup, with ext4 inside. Shufflecake and volumes mounted by the VeraCrypt application itself have not been evaluated, so NAILS makes no claims about them. As of October 2026, no cryptsetup release can open a VeraCrypt volume made with Argon2id, so make the outer and the hidden volume with PBKDF2.
For Linux, VeraCrypt's security requirements for hidden volumes say to mount hidden volumes only while a "live-CD" system runs that is entirely stored on
and booted from a CD or DVD and writes any system-volume data to a RAM disk. During that session,
only filesystems inside hidden volumes may be mounted read-write. If you cannot comply, and
cannot ensure that applications and the operating system write no sensitive data to non-hidden
volumes or filesystems, VeraCrypt says you "must not mount or create hidden VeraCrypt volumes
under Linux." With NAILS, you unlock and mount the hidden volume on the decoy before you run
nails activate.
The hidden volume and its backends How NAILS compares with VeraCrypt, Tails and Shufflecake
Can I use the decoy and the hidden session at the same time?
No. Only one of them runs at a time, and switching logs you out of the other. Both switches are soft-reboots, so every program closes and the other environment starts at its own login screen. A display manager set to log an account in automatically logs it in again at each switch. Save your work before you switch.
Why does NAILS need a soft-reboot?
So that every process of the hidden session starts inside the overlay, and nothing on the decoy side is left to find, restart or kill. The earlier design overlaid the running system directory by directory, and a writer it missed went on writing to the decoy without any sign. An overlay set up at boot would need a full reboot and leave an enabler on the decoy, such as a boot entry. A soft-reboot needs systemd 254 or newer and leaves nothing installed on the decoy.
Why one overlay over the whole root
Does the hidden session get its own account?
Not yet. By default it runs as the decoy user, in the decoy home seen through the overlay,
so the decoy's browser profiles, SSH and GPG keys and history are live in it. The fresh-home persona gives it an empty home instead. A separate hidden account is planned for a later release.
Why is there no apt, Nix or crates.io package?
Each would leave a lasting record on the decoy or in a public index. A .deb or
.rpm package is recorded in the package database and cached on the decoy disk,
a nixpkgs package or a NixOS module on the decoy names the tool in its store, and a crate on
crates.io is a permanent public record. NAILS is installed only by copying a verified static
binary onto the mounted hidden volume. You can build later versions from source inside a hidden
session, where the build caches land on the hidden volume.
Install NAILS Distribution channels
Releases and trust
Is NAILS ready to rely on?
NAILS is alpha software, meant for technically experienced users who can test their exact
machine, storage backend and procedure before relying on it. Interfaces and workflows can
still change between releases. Before you rely on a setup, run nails rehearse on
the real machine and nails verify --offline --examiner against an image of the decoy. A clean nails verify is evidence, not proof.
Has NAILS had a security audit?
The project does not claim an independent security audit. Automated tests run the session in NixOS, Debian 13 and Ubuntu 24.04 virtual machines and check images of the decoy disk, and fuzzing runs every day. A NixOS decoy with a VeraCrypt hidden volume was evaluated by hand once, before the current design, and that evaluation has to be repeated. Encrypted backends other than LUKS2 and a VeraCrypt hidden volume opened with cryptsetup are outside what has been evaluated, and so is physical hardware. The release checks show where a file was built, not that the code is free of flaws.
Which release do these docs describe?
The docs on this site describe v0.3.0-rc.3, a release candidate published as a prerelease on Oct 20, 2026. The latest stable release, v0.2.0, is the earlier design for NixOS only, with per-directory overlays and a YAML configuration, and the docs do not apply to it.
The security policy says that only the most recent 0.2.x release carries security fixes. A problem in a release candidate
is fixed in a new -rc.N, because a published release
never changes.
Download NAILS All releases on GitHub
How do I verify a download?
Download and check it away from the decoy, from a live system that keeps nothing for the
first installation, or inside a hidden session for an update. Compare the binary with checksums.txt using sha256sum, then check its signed build provenance with cosign and provenance.sigstore.json, which needs no GitHub account. Together they show that the file is the one the release
lists and that the project's release workflow built it from the tagged commit, not that
the code is free of flaws.
What changed since 0.2?
NAILS 0.2 was the earlier design for NixOS only. It overlaid the running decoy directory by directory, and a process it missed could keep writing to the decoy without any sign. The 0.3 line replaces it with one overlay over the whole root, entered and left with a soft-reboot. It also adds Debian 13, Ubuntu 24.04 and Ubuntu 26.04 as decoys, and moves the configuration from YAML to strict TOML.
NAILS 0.3 also refuses setups that 0.2 accepted. The hidden volume must be storage of its
own, so a folder, a network filesystem or a FUSE mount is refused. The decoy root must
stay on a disk, so a tmpfs root, such as impermanence on /, is refused. A /var or /home on its own tmpfs, wiped at boot, is fine. There is no compatibility
shim, so convert your setup before you run the new binary.
Upgrading from 0.2 What changed in NAILS 0.3 Changelog
The project and this site
Who maintains NAILS and how is it licensed?
NAILS is maintained by one developer, WitteShadovv, so support and security response are best effort. It is free software under GPL-3.0-or-later and comes with no warranty. The project states that it was developed with AI-assisted tooling for drafting code, tests and documentation, and that all security-relevant design decisions, code changes and published documentation remain the maintainer's responsibility.
Does this website track me?
No. nails.run is a static site that sets no cookies, runs no analytics and loads nothing from other servers. GitHub Pages hosts it, so GitHub can see your IP address and the pages you request, as any web host can. Reading these pages on the decoy system leaves them in its browser history, and following the news feed there leaves the subscription behind, so do both somewhere else when that matters.