Skip to content

martijnvanbrummelen/nwipe

Repository files navigation

nwipe

GitHub CI badge GitHub release

nwipe is a fork of the dwipe command originally used by Darik's Boot and Nuke (DBAN).
It was created to run the DBAN erase engine on any Linux distribution, with better and more modern hardware support.

nwipe securely erases the entire contents of block devices. It can wipe a single drive or multiple disks in parallel, either:

  • as a command-line tool without a GUI, or
  • with an ncurses-based GUI, as shown below:

Warning
For some of nwipe’s features such as SMART data in the PDF certificate, HPA/DCO detection and other functions, nwipe uses external tools: smartmontools and hdparm.
Both hdparm and smartmontools are mandatory if you want all nwipe features to be fully available.
If they are not installed, nwipe will log a warning and continue, but many important features will not work as intended.

Example wipe

The animation above shows six drives being erased in parallel. The view jumps to the completion of all six wipes and shows five drives successfully wiped and one that failed due to an I/O error. The failing drive would typically be physically destroyed. Drives that complete with zero errors can be safely redeployed.

nwipe_certificate_0 35_5s

The screenshot above shows nwipe’s three–page PDF certificate. Drive-identifying data such as serial numbers has been anonymised using the -q / --quiet option.


New in v0.40 (upcoming)

The upcoming v0.40 release introduces several major improvements:

  • AES-256-CTR PRNG
    High–performance, cryptographically secure stream generator (AES-NI accelerated where available).
  • Large, aligned I/O buffers
    Significantly fewer syscalls and better throughput, especially on fast SSDs and NVMe.
  • Configurable I/O modes
    • --io-mode=auto (default): try O_DIRECT, fall back to cached I/O if not supported
    • --directio / --io-mode=direct: force direct I/O (O_DIRECT), no fallback
    • --cachedio / --io-mode=cached: force kernel cached I/O, never attempt O_DIRECT
  • Improved sync behaviour for cached I/O
    Sync intervals are again based on a predictable number of bytes written, ensuring timely detection of disk / USB errors without excessive overhead.
  • Enhanced device exclusion
    --exclude now works cleanly with paths like /dev/disk/by-id/*, making it easier to exclude specific drives by stable IDs.
  • Stronger seeding with getrandom()
    nwipe now uses the Linux getrandom() syscall for PRNG seeding and no longer depends on /dev/urandom.
  • New BMB21-2019 erase method
    Implements the Chinese State Secrets Bureau BMB21-2019 technical requirement for data sanitisation.

Erasure methods

The user can select from a variety of recognised secure erase methods, including:

  • Fill With Zeros
    Fills the device with zeros (0x00).

  • Fill With Ones
    Fills the device with ones (0xFF).

  • RCMP TSSIT OPS-II
    Royal Canadian Mounted Police Technical Security Standard, OPS-II.

  • DoD Short
    U.S. Department of Defense 5220.22-M short 3-pass wipe
    (passes 1, 2 & 7 from the full specification).

  • DoD 5220.22-M (Full)
    Full 7-pass U.S. DoD 5220.22-M wipe.

  • Gutmann Wipe
    Peter Gutmann's 35-pass method (“Secure Deletion of Data from Magnetic and Solid-State Memory”).

  • PRNG Stream
    Fills the device with a stream generated by the selected PRNG engine.

  • Verify Zeros
    Reads the device and verifies it is filled with zeros (0x00).

  • Verify Ones
    Reads the device and verifies it is filled with ones (0xFF).

  • HMG IS5 Enhanced
    UK HMG IS5 (Enhanced) sanitisation method for protectively marked or sensitive information.

  • Schneier Wipe
    Bruce Schneier's 7-pass mixed–pattern algorithm.

  • BMB21-2019 (new in v0.40)
    Chinese State Secrets Bureau BMB21-2019 technical requirement for data sanitisation.
    This method overwrites the device with ones (0xFF), then zeros (0x00), followed by three passes of PRNG-generated random data, and finishes with a final pass of ones (0xFF).


PRNG engines

nwipe includes multiple pseudorandom number generators (PRNGs) for methods that require random data:

  • AES-256-CTR (new in v0.40)
    Cryptographically secure, high–throughput counter-mode stream cipher, using hardware AES-NI where available.

  • XORoshiro-256
    Very fast, high–quality non-cryptographic generator, suitable for high–volume random wiping where a CSPRNG is not strictly required.

  • Mersenne Twister
    Well-known high–period PRNG.

  • ISAAC / ISAAC-64
    (Indirection, Shift, Accumulate, Add, and Count) generators.

  • Additive Lagged Fibonacci Generator

These PRNGs can be selected at runtime (see the man page for the exact CLI options) and are used by any wipe method that requires random patterns (for example PRNG Stream, Schneier or BMB21 random passes).


I/O subsystem and Direct I/O

Starting with v0.40 the nwipe I/O layer has been significantly modernised:

Large, aligned I/O buffers

nwipe now uses large, aligned multi-megabyte buffers when reading and writing:

  • Reduces the number of read() / write() calls.
  • Improves throughput on fast devices (SSD / NVMe / high-speed RAID).
  • Ensures correct alignment for Direct I/O (O_DIRECT) where supported.

I/O mode selection

You can now explicitly control how nwipe accesses the device:

--io-mode=auto      # default
--io-mode=direct    # equivalent to --directio
--io-mode=cached    # equivalent to --cachedio

--directio          # force O_DIRECT (no fallback)
--cachedio          # force kernel cached I/O only
  • auto Try to open the device with O_DIRECT. If the kernel or filesystem does not support it (EINVAL/EOPNOTSUPP), nwipe falls back to cached I/O and logs a warning.

  • direct / --directio Force Direct I/O. If O_DIRECT is not supported for the device, opening the device fails and the wipe will not proceed. This is useful for strict testing and benchmarking.

  • cached / --cachedio Always use kernel buffered I/O. O_DIRECT is never attempted. This is closest to the behaviour of older nwipe releases.

Sync behaviour

The --sync option controls how often nwipe performs fdatasync() when using cached I/O:

  • The value represents the number of device hardware blocks (typically 512 or 4096 bytes) between syncs.

  • Internally this value is scaled to match nwipe’s large I/O buffer size so that the effective bytes between syncs remain in a reasonable range (tens to hundreds of MB, depending on the default and device).

  • This ensures:

    • timely detection of I/O and hardware errors in cached I/O mode, and
    • good throughput for normal use.

In Direct I/O mode (--directio / --io-mode=direct), periodic sync is disabled: write errors are reported immediately by write(), so fdatasync() provides no additional safety.

See the nwipe(8) man page for detailed --sync semantics and examples.


SSD considerations and limitations

In its current form, nwipe cannot fully sanitise solid state drives (SSDs) of any interface type:

  • SAS / SATA / NVMe
  • Form factors such as 2.5", 3.5", M.2, PCIe, etc.

This is due to how SSDs internally manage data:

  • SSDs use wear-levelling and frequently maintain additional, non-host-accessible memory (overprovisioning).
  • Failed blocks may be remapped to reserved areas that are not directly addressable by the OS.
  • Many vendors restrict low-level access to these areas to the drive’s own controller and firmware.

For secure SSD sanitisation, it is strongly recommended to:

  1. Use nwipe / ShredOS in combination with vendor-specific tools, for example:

    • manufacturer Secure Erase,
    • NVMe format / sanitize commands, or
    • hardware vendor–provided utilities, and
  2. Independently validate the result, comparing drive contents before and after sanitisation where feasible.

A list of common SSD vendor tools and guidance can be found in the separate SSD Guide.


Compiling & installing

For development work, see the Hacking section below. For a bootable image with the latest nwipe master that you can write to a USB stick or CD/DVD, see Quick & easy, USB bootable version.

Dependencies

nwipe requires the following libraries:

  • ncurses
  • pthreads
  • parted
  • libconfig

nwipe also requires the following program and will abort with a warning if not found:

  • hdparm (as of current master and v0.35+)

The following tools are optional but strongly recommended:

  • dmidecode
  • coreutils (for readlink)
  • smartmontools

These tools enable features such as:

  • HPA/DCO detection
  • SMART data for PDF certificates (especially for USB bridge devices)
  • SMBIOS/DMI host information in the log
  • Correct bus type detection (ATA/USB/etc.) and proper operation of --nousb

Debian & Ubuntu prerequisites

If you are compiling nwipe from source on Debian/Ubuntu:

sudo apt install \
  build-essential \
  pkg-config \
  automake \
  libncurses5-dev \
  autotools-dev \
  libparted-dev \
  libconfig-dev \
  libconfig++-dev \
  dmidecode \
  coreutils \
  smartmontools \
  hdparm \

Fedora / RHEL / CentOS Stream prerequisites

sudo bash
sudo dnf update -y
sudo dnf groupinstall -y "Development Tools" "C Development Tools and Libraries"
sudo dnf install -y \
  ncurses-devel \
  parted-devel \
  libconfig-devel \
  libconfig++-devel \
  dmidecode \
  coreutils \
  smartmontools \
  hdparm

Arch Linux / Manjaro prerequisites

sudo pacman -Syu --needed \
  base-devel \
  ncurses \
  parted \
  libconfig \
  dmidecode \
  coreutils \
  smartmontools \
  hdparm

openSUSE (Leap / Tumbleweed) prerequisites

sudo zypper refresh
sudo zypper install -y \
  gcc \
  make \
  automake \
  autoconf \
  libtool \
  ncurses-devel \
  libparted-devel \
  libconfig-devel \
  libconfig++-devel \
  dmidecode \
  coreutils \
  smartmontools \
  hdparm

Note: dmidecode, readlink (from coreutils) and smartmontools are technically optional, but recommended for full feature support.

Compilation

Generate the autoconf files:

./autogen.sh

Then configure, build and install:

./configure
make format    # only required if you intend to submit pull requests
make
sudo make install

Run nwipe:

cd src
sudo ./nwipe

or simply:

sudo nwipe

Hacking

If you intend to submit patches or pull requests, we recommend enabling full warnings in your development build.

For a debug–friendly build:

./configure --prefix=/usr CFLAGS='-O0 -g -Wall -Wextra'
make format      # necessary if submitting pull requests
make
sudo make install
  • -O0 -g Disables optimisation and includes debug symbols. This is important if you are debugging with gdb or an IDE (e.g. KDevelop), and want accurate stepping and variable inspection.

  • -Wall -Wextra Enables most useful compiler warnings. Please submit code with zero warnings.

The code style is defined via .clang-format. Before submitting:

make format

You will need clang-format installed for this step.

To rebuild a "release-like" binary with normal optimisations after development:

./configure --prefix=/usr
make
sudo make install

Automating download and compilation (Debian-based distros)

Below is a convenience script that:

  1. Creates ~/nwipe_master
  2. Installs all required build dependencies
  3. Downloads the latest master branch from GitHub
  4. Builds nwipe
  5. Runs the freshly built nwipe

It does not overwrite any nwipe installed from your distribution’s repository.

Save the following as buildnwipe, then make it executable with chmod +x buildnwipe:

#!/bin/bash
cd "$HOME"
nwipe_directory="nwipe_master"
mkdir -p "$nwipe_directory"
cd "$nwipe_directory"

sudo apt install -y \
  build-essential \
  pkg-config \
  automake \
  libncurses5-dev \
  autotools-dev \
  libparted-dev \
  libconfig-dev \
  libconfig++-dev \
  dmidecode \
  readlink \
  smartmontools \
  hdparm \
  git

rm -rf nwipe
git clone https://github.com/martijnvanbrummelen/nwipe.git
cd nwipe
./autogen.sh
./configure
make

cd src
sudo ./nwipe

To run the latest master later on:

sudo ~/nwipe_master/nwipe/src/nwipe

If you already have nwipe from your distro’s repo installed, remember:

  • nwipe → runs the packaged version in your $PATH
  • ./nwipe in ~/nwipe_master/nwipe/src → runs the freshly built master

Quick & easy, USB bootable version of nwipe master for x86_64 systems

If you prefer a bootable image containing the latest nwipe master, use ShredOS:

ShredOS:

  • is ~60 MB in size,
  • can be written to a USB flash drive in seconds,
  • boots directly into a minimal environment running the latest nwipe,
  • is available for x86_64 (64-bit) and i686 (32-bit),
  • supports both legacy BIOS and UEFI.

It is provided as:

  • .img (USB bootable image), and
  • .iso (for CD/DVD).

See the ShredOS README for detailed instructions on downloading and writing the image.


Which Linux distro uses the latest nwipe?

You can see an overview at:

Distributions known to include nwipe:

If you know of other distributions that ship nwipe, please let us know or send a PR updating this README.


Bugs

Bugs, feature requests, and pull requests are welcome on GitHub:

Please include:

  • your distribution and version,
  • the nwipe version (or git commit hash),
  • hardware details (especially for I/O-related issues),
  • log output and command line options used.

License

nwipe is licensed under the GNU General Public License v2.0. See the LICENSE file for details.

About

nwipe secure disk eraser

Resources

License

Stars

Watchers

Forks

Packages

No packages published

Languages