🛡 ZeroDisk — Enterprise Secure Disk Sanitization Suite

Version: 0.3.0 | License: AGPL-3.0-only | Language: Rust

Türkçe README için tıklayın →

What Is ZeroDisk?

ZeroDisk is an enterprise-grade, Linux-native secure disk sanitization suite written in Rust. Designed for data centers, IT departments, and security professionals, it delivers:

Parallel multi-disk wiping (100+ disks simultaneously)
Hardware-level secure erase (ATA Secure Erase / NVMe Format with HPA/DCO unlock)
Cryptographic erase (LUKS key slot destruction — instantaneous)
SMART-based health gate (--strict-health aborts on bad sectors)
Resumable wipes (survives power loss, resumes from checkpoint)
Compliance profiles (nist-clear, nist-purge, ieee2883-clear, ieee2883-purge, ssd-purge, crypto-erase)
Batch wipe plans (JSON, TOML, or CSV inventory manifests)
Professional HTML + JSON certificates (auto-generated per wipe)
Enterprise target identity lock (serial/model/size checks before destructive writes)
Chain-of-custody audit metadata (operator, ticket, asset, site, organization)
Evidence bundles (report, certificate, hashes, signatures, runtime/tool metadata)
Tamper-evident reports (JSON SHA256 sidecar + optional HMAC-SHA256 and Ed25519 signatures)
Hardware sanitization capability probe (ATA/NVMe preflight evidence)
Verification levels (none, sample, full)
Webhook notifications (Discord, Slack, custom API)
Bootable Live ISO (Alpine-based, UEFI + Legacy BIOS)
PXE network boot server (wipe 100+ servers over the network)
AutoNuke mode (datacenter kiosk — wipe all disks and shutdown)
Safer file/free-space tools (symlink refusal, unique temporary files)

Requirements

Tool	Purpose
Rust 1.85+	Build ZeroDisk with Rust 2024 edition
`smartctl`	SMART health data
`hdparm`	ATA Secure Erase + HPA/DCO unlock
`nvme` (nvme-cli)	NVMe secure format
`cryptsetup`	LUKS cryptographic erase
`wipefs` (util-linux)	Signature removal
`lsblk`, `findmnt`, `ip`	Disk discovery, mount checking, PXE interface detection
`syslinux` / `pxelinux`	BIOS PXE network bootloader
`dnsmasq`	Native PXE DHCP/TFTP server
`xorriso`	ISO build and PXE artifact extraction from generated ISO files
`docker` (optional fallback)	Alternative dnsmasq runner when native `dnsmasq` is unavailable

Quick Install

git clone https://github.com/cumakurt/ZeroDisk.git
cd ZeroDisk
chmod +x install.sh
./install.sh

Build from Source

cargo build --release
cargo install --path .
cargo run -- --help

Detailed Feature Guide

ZeroDisk is intentionally built as an operational workflow, not just a single overwrite command. The goal is to help an operator identify the correct media, choose the right sanitization strategy, prevent accidental destruction, produce evidence, and verify that the generated evidence has not been modified later.

Disk Discovery and Inventory

zerodisk list discovers whole block devices through lsblk and falls back to /sys/block when lsblk is unavailable. The command shows the device name, path, size, transport, media type, vendor, model, serial number, detected filesystem types, and filesystem space information. This information matters because destructive work should start with target identification, not with a blind /dev/sdX assumption.

--with-smart enriches the list with health data such as SMART pass/fail state, temperature, power-on hours, reallocated sectors, pending sectors, uncorrectable sectors, and an overall bad-sector risk summary. Use it before a wipe when you need to decide whether a device should be wiped normally, skipped, quarantined, or handled through a stricter hardware purge workflow.

--json exists for automation. It returns a stable machine-readable document so asset systems, shell scripts, inventory pipelines, or PXE orchestration tooling can consume device data without scraping terminal tables.

SMART Health Assessment

zerodisk smart --device DEVICE gives a focused SMART summary for one disk. It is useful before selecting a wipe method because unhealthy drives can behave unpredictably under heavy sequential writes. ZeroDisk uses SMART counters to classify bad-sector risk:

ok: no reallocated, pending, or uncorrectable sector signals were found.
warn: pending sectors exist and the drive may be unstable.
critical: SMART failed, reallocated sectors exist, or uncorrectable errors were reported.

--strict-health turns this assessment into a gate. If the disk has a critical SMART condition, the wipe is aborted before destructive writes begin. This is useful in enterprise workflows where failed media should be separately documented or physically destroyed instead of pushed through a normal overwrite process.

Compliance Profiles

Compliance profiles are named policy presets. They do not magically certify an organization by themselves; they make the selected method, verification level, evidence behavior, and health policy explicit and repeatable.

Built-in profiles:

Profile	Default method	Verification	Strict health	Evidence bundle	Intended use
`nist-clear`	`zero`	`sample`	no	yes	Reusable media clear workflow with sampled validation evidence
`nist-purge`	`secure-erase`	`none`	yes	yes	Hardware-native purge workflow for ATA/NVMe devices
`ieee2883-clear`	`zero`	`sample`	no	yes	IEEE 2883 aligned clear-style workflow
`ieee2883-purge`	`secure-erase`	`none`	yes	yes	IEEE 2883 aligned purge-style workflow
`ssd-purge`	`secure-erase`	`none`	yes	yes	SSD-focused workflow that avoids relying only on overwrites
`crypto-erase`	`crypto-erase`	`none`	no	yes	Encrypted media workflow based on key/header destruction

Use --profile when you want consistent policy behavior across operators or batches. Use explicit --method, --passes, or --verify-mode when a specific job needs to override the profile default. ZeroDisk records the selected profile in the JSON report and HTML certificate so an auditor can see both the technical action and the policy intent.

Hardware Sanitization Capability Probe

zerodisk probe-sanitize --device DEVICE inspects whether a disk appears to support hardware sanitization features. For NVMe devices, it probes capabilities related to format, sanitize, crypto erase, block erase, and overwrite support. For ATA/SATA devices, it checks ATA security support, frozen/locked/enabled state, enhanced erase signals, HPA state, and DCO restore availability.

This command is a preflight evidence tool. Use it before --method secure-erase to understand whether a drive is likely to accept a hardware erase command, whether it may be frozen by firmware, and what method ZeroDisk recommends. It is especially useful for SSDs, where ordinary overwrites may not reach every physical NAND location due to wear leveling, remapping, and controller behavior.

Wipe Engine and Wipe Methods

zerodisk wipe is the main disk sanitization command. It validates the operator confirmation, discovers and locks the target identity, checks system-disk and mount safety, optionally evaluates SMART health, performs the selected method, optionally verifies output, and writes reports.

Wipe method guidance:

zero: writes zero bytes across selected ranges. It is simple, fast, deterministic, and easy to verify.
random: writes random bytes from /dev/urandom. It is useful when the final media state should not look like a zeroed disk, but random verification is probabilistic rather than exact.
dod3, dod7, nato, gutmann: multi-pass overwrite schedules. They exist for operational compatibility with legacy policies. For modern SSDs, prefer hardware or cryptographic erase when supported.
quick-destroy: wipes only the beginning and end of the device. This is fast and useful for destroying partition tables, filesystem metadata, and common headers, but it is not a full media sanitization method.
secure-erase: uses device-native ATA Secure Erase or NVMe Format behavior. This is preferred for SSD purge-style workflows when the device supports it.
crypto-erase: destroys LUKS key slots where possible, then removes signatures or wipes encryption headers. This is fast because encrypted data becomes inaccessible when keys are destroyed.
custom: lets operators define a pass sequence such as zero,random,zero. This is useful when a local policy specifies a custom pattern.

Verification Modes

ZeroDisk separates wiping from validation because verification has a cost. You can choose the level appropriate for the job:

--verify-mode none: no post-write data validation. This is appropriate for hardware or cryptographic erase methods where the relevant proof is command success and capability evidence.
--verify-mode sample: reads representative offsets from the wiped ranges. It is fast and suitable for routine large-disk jobs where full verification would take too long.
--verify-mode full: reads every selected wipe range. It provides the strongest validation for deterministic patterns such as zero or one, but it can be very slow on large disks.

The legacy --verify flag maps to sampled verification. Reports include the verification mode, checked offsets or ranges, sample hashes, status, and entropy score where applicable.

Resume and Checkpoint Safety

Long-running wipes can be interrupted by power loss, reboot, terminal failure, or process termination. ZeroDisk writes checkpoint state periodically under reports/state_*.json and uses atomic replacement so a partial checkpoint does not corrupt the previous one.

Resume is identity-locked. A checkpoint is reused only when the current device path, serial number, model, size, method, custom sequence, pass count, and wipe-plan hash match. This prevents a dangerous scenario where /dev/sdb later points to a different physical disk but an old checkpoint tries to resume against it.

Target Identity Lock

The identity lock options are designed to prevent accidental destruction:

--expect-serial requires the discovered serial number to match.
--expect-model requires the model string to match.
--min-size-bytes and --max-size-bytes enforce expected capacity boundaries.

For multi-disk jobs, identity values can be repeated in target order or mapped explicitly, such as --expect-serial sdb=SERIAL_A. Explicit mappings are safer in automation because they remain understandable even when command order changes.

Confirmation and Destructive Safety

ZeroDisk intentionally requires typed confirmation. A single-device wipe must be confirmed with the device path or device name. A multi-device wipe requires WIPE-N, where N is the number of targets. A batch plan requires PLAN-N.

The tool also blocks common catastrophic mistakes:

It refuses to wipe the system disk unless --force is used.
It refuses mounted filesystems and active swap (not bypassable). Unmount or swapoff first.
shred refuses symlinks and unsupported special file types.
wipe-freespace creates a unique hidden temporary file with exclusive creation to avoid overwriting an existing user file by name collision.

Reports, Certificates, and Evidence Bundles

Every wipe writes a JSON report and SHA256 sidecar. The JSON report is the machine-readable audit record; the HTML certificate is the human-readable evidence document. Reports include device identity, method, pass log, timestamps, duration, audit metadata, profile selection, verification details, SMART snapshot, and hardware capability evidence when available.

--evidence-bundle creates a dedicated evidence directory containing copied report artifacts plus evidence.json and evidence.json.sha256. The evidence manifest records runtime metadata such as host, user, kernel, OS release, current directory, and versions of relevant tools when available. Use evidence bundles for ticketed IT disposal, chain-of-custody workflows, datacenter decommissioning, or customer-facing erasure proof.

HMAC and Ed25519 Attestation

ZeroDisk supports two signing models:

HMAC-SHA256 (--report-signing-key-env) proves that someone with the shared secret signed the report. This is simple and useful inside a single trusted operational environment.
Ed25519 (--report-ed25519-private-key-env) produces an asymmetric signature. The private key signs reports, and a public key can verify them later without exposing the signing secret.

Use Ed25519 when reports must be verified by another team, an auditor, a customer, or an offline archive process. Use verify-report --report-ed25519-public-key HEX_OR_PATH to validate the .ed25519 sidecar.

Batch Wipe Plans

run-plan executes an inventory manifest in JSON, TOML, or CSV format. It exists for repeatable batch work where command-line arguments become too error-prone. Defaults define shared policy; each target can override profile, method, passes, verification, identity expectations, audit metadata, report path, and webhook.

Use plans for datacenter racks, IT asset disposal batches, ticket-driven workflows, or PXE sessions where each physical disk must be tied to an asset ID and expected serial number. Plan execution requires PLAN-N confirmation unless --dry-run is used.

Webhook Notifications

--webhook posts completion data to Discord, Slack, or a custom HTTP endpoint. Discord and Slack URLs receive platform-specific payload shapes; other URLs receive the full JSON report. Webhooks are best used for operational visibility, not as the primary audit record. Keep the local report and evidence bundle as the source of truth.

Bootable ISO, USB, PXE, and AutoNuke

The Live ISO packages ZeroDisk into an Alpine-based boot environment. This is useful when disks should be sanitized outside the installed operating system, when the installed OS is untrusted, or when the target system has no usable OS.

make-usb writes the generated ISO to a USB block device after confirmation and safety checks. It is destructive to the USB target.

pxe-server serves the ZeroDisk live environment over the network. It prepares PXE boot files, starts an HTTP server for the SquashFS root filesystem, and runs native dnsmasq or Docker fallback. PXE is intended for controlled lab/datacenter networks; do not run it on a production network segment without understanding DHCP impact.

auto-nuke discovers every eligible non-system, non-mounted disk, wipes them in parallel, and shuts down the machine. It is meant for kiosk-style decommissioning workflows and should only be used in tightly controlled environments.

Logging and Operational Diagnostics

-v and -vv raise log verbosity. --log-file mirrors logs to a file, and --syslog sends logs to the host syslog. Use logging when running long wipes, batch plans, PXE operations, or incident-sensitive workflows where terminal output alone is not enough.

Commands

`list` — Enumerate disks

sudo zerodisk list
sudo zerodisk list --with-smart          # Include SMART health columns
sudo zerodisk list --json                # JSON output (for scripts)
sudo zerodisk list --with-smart --json   # SMART-enriched JSON

`smart` — Full SMART detail

sudo zerodisk smart --device /dev/sda

`analysis` — Unique facts + health assessment (noise-reduced)

analysis merges multiple data sources and prints only unique facts, plus an operator-facing health assessment (OK, WARN, CRITICAL) with actionable findings.

# Analyze all detected disks
sudo zerodisk analysis

# Analyze a specific disk
sudo zerodisk analysis --device /dev/sdb

# Analyze multiple disks
sudo zerodisk analysis --device /dev/sdb /dev/sdc

# JSON output (for automation)
sudo zerodisk analysis --json

`analysis --json` schema versioning

Stability: The JSON output is intended for automation and evolves via an explicit version field.
Compatibility: When the schema changes, version is bumped. Consumers should branch on version.

Minimal example (shape only; fields may be omitted when unavailable):

{
  "version": 1,
  "generated_at_unix": 0,
  "targets": [
    {
      "selector": "/dev/sdb",
      "found": true,
      "disk": { "name": "sdb", "path": "/dev/sdb", "size_bytes": 0, "model": "", "vendor": "", "serial": "", "transport": "unknown", "rotational": false, "fs_types": "-", "fs_space": "-" },
      "mounts": [],
      "smart": { "health": "passed", "temperature_c": 0, "power_on_hours": 0, "reallocated": 0, "pending": 0, "uncorrectable": 0 },
      "bad_sector_assessment": { "level": "ok", "summary": "..." },
      "sanitize": { "device": "/dev/sdb", "interface": "ata", "tool_available": true, "recommended_method": "...", "nvme": null, "ata": null, "notes": [] },
      "assessment": { "level": "OK", "summary": "...", "findings": [], "recommended_actions": [] },
      "unique_facts": [["key", "value"]]
    }
  ]
}

`profiles` — Built-in compliance profiles

zerodisk profiles
zerodisk profiles --json

`probe-sanitize` — ATA/NVMe capability probe

sudo zerodisk probe-sanitize --device /dev/nvme0n1
sudo zerodisk probe-sanitize --device /dev/sdb --json

`verify-report` — Verify report attestation

zerodisk verify-report --report reports/wipe-1713690000-dod3-sdb.json
zerodisk verify-report --report reports/wipe-1713690000-dod3-sdb.json \
  --report-signing-key-env ZERODISK_REPORT_KEY
zerodisk verify-report --report reports/wipe-1713690000-dod3-sdb.json \
  --report-ed25519-public-key ed25519-public-key.hex
zerodisk verify-report --report reports/wipe-1713690000-dod3-sdb.json --json

This validates the JSON report against its .sha256 sidecar. If a report was signed with --report-signing-key-env, pass the same environment variable to verify the .hmac sidecar. If a report was signed with --report-ed25519-private-key-env, pass the corresponding public key with --report-ed25519-public-key HEX_OR_PATH to verify the .ed25519 sidecar.

`preflight` — Non-destructive safety checks

preflight runs non-destructive checks against the selected target(s): identity policy validation, system disk guard, mount/swap guard, and optional SMART / hardware capability probes.

# Preflight a specific disk (human-readable)
sudo zerodisk preflight --device /dev/sdb --with-smart --probe-sanitize

# Preflight everything detected (JSON)
sudo zerodisk preflight --json --with-smart

`wipe` — Disk sanitization

# Single disk
sudo zerodisk wipe --device /dev/sdb --confirm sdb

# JSON summary (for scripts / orchestration)
sudo zerodisk wipe --device /dev/sdb --confirm sdb --json

# Multiple disks (parallel)
sudo zerodisk wipe --device /dev/sdb /dev/sdc /dev/sdd \
  --method dod3 --confirm WIPE-3

# DoD 7-pass + verification + Slack webhook
sudo zerodisk wipe --device /dev/sdb --confirm sdb \
  --method dod7 --verify --webhook https://hooks.slack.com/...

# SMART health gate (abort if critical bad sectors)
sudo zerodisk wipe --device /dev/sdb --confirm sdb \
  --method dod3 --strict-health

# Compliance profile + evidence bundle + full verification
sudo zerodisk wipe --device /dev/sdb --confirm sdb \
  --profile nist-clear --verify-mode full --evidence-bundle

# Enterprise identity lock + audit metadata + signed report
export ZERODISK_REPORT_KEY='use-a-secret-from-your-vault'
export ZERODISK_ED25519_KEY="$(openssl rand -hex 32)"
sudo zerodisk wipe --device /dev/sdb --confirm sdb \
  --expect-serial SERIAL123 --expect-model "Enterprise SSD" \
  --min-size-bytes 1000000000000 --max-size-bytes 2000000000000 \
  --operator alice --organization "Example Corp" --location "DC1/Rack42" \
  --asset-id ASSET-00912 --ticket-id CHG-2026-0042 \
  --report-signing-key-env ZERODISK_REPORT_KEY \
  --report-ed25519-private-key-env ZERODISK_ED25519_KEY \
  --evidence-bundle

# Dry-run (no data written)
sudo zerodisk wipe --device /dev/sdb --confirm sdb --dry-run

# Fast metadata destruction
sudo zerodisk wipe --device /dev/sdb --confirm sdb --method quick-destroy

# Hardware-level ATA/NVMe erase
sudo zerodisk wipe --device /dev/sdb --confirm sdb --method secure-erase

# Cryptographic erase (LUKS key destruction)
sudo zerodisk wipe --device /dev/sdb --confirm sdb --method crypto-erase

# Custom pass sequence
sudo zerodisk wipe --device /dev/sdb --confirm sdb \
  --method custom --custom-sequence zero,random,zero

--profile applies a compliance-oriented default method, verification level, strict-health policy, and evidence bundle behavior. Explicit --method, --passes, or --verify-mode values override profile defaults.

--verify-mode sample checks representative offsets. --verify-mode full reads every selected wipe range; this is strongest for deterministic patterns and can be very slow on large disks.

For multi-device wipes, --confirm must be WIPE-N where N is the number of target disks. If --confirm is omitted, ZeroDisk prints the required token interactively.

For single-device wipes, omitting --confirm now opens an interactive confirmation prompt. Non-interactive runs must provide --confirm explicitly.

For multi-device identity locks, repeat --expect-serial/--expect-model once per target in the same order, or use explicit mappings such as --expect-serial sdb=SERIAL_A --expect-serial /dev/sdc=SERIAL_B.

Wipe Methods

Method	Passes	Description
`zero`	1+	Zero-fill
`random`	1+	Random overwrite
`dod3`	3	DoD 5220.22-M (3-pass)
`dod7`	7	DoD 5220.22-M (7-pass)
`nato`	4	NATO standard
`gutmann`	35	Gutmann method
`quick-destroy`	1	Header + tail only (fast)
`secure-erase`	—	ATA Secure Erase / NVMe Format
`crypto-erase`	—	LUKS key slot destruction
`custom`	n	User-defined sequence using `zero`, `one`, and `random` (e.g. `zero,random,zero`)

`shred` — Secure file deletion

sudo zerodisk shred /secret/file.txt --passes 3 --remove
sudo zerodisk shred /secret/dir/ --passes 5 --remove

shred refuses symlinks and unsupported special file types. Pass the resolved target path explicitly if that is really intended.

`wipe-freespace` — Wipe free space on live filesystem

sudo zerodisk wipe-freespace /mnt/data --passes 2

Free-space wiping uses a hidden unique temporary file created with exclusive creation, so an existing user file is not overwritten by name collision.

`run-plan` — Batch wipe inventory manifest

sudo zerodisk run-plan --plan wipe-plan.toml --confirm PLAN-3
sudo zerodisk run-plan --plan wipe-plan.csv --dry-run
sudo zerodisk run-plan --plan wipe-plan.json \
  --confirm PLAN-12 --report-dir reports/batch-42 --evidence-bundle

Use the bundled dry-run templates as a starting point:

cp examples/wipe-plan.toml wipe-plan.local.toml
$EDITOR wipe-plan.local.toml
sudo zerodisk run-plan --plan wipe-plan.local.toml --dry-run

The files under examples/ are safe dry-run templates. Replace placeholder device paths, serials, asset IDs, and webhook values before using them in an operational plan.

Minimal TOML plan:

[defaults]
profile = "nist-clear"
operator = "alice"
organization = "Example Corp"

[[targets]]
device = "/dev/sdb"
expect_serial = "SERIAL_A"
asset_id = "ASSET-001"

[[targets]]
device = "/dev/sdc"
profile = "ssd-purge"
expect_serial = "SERIAL_B"
asset_id = "ASSET-002"

CSV plans use headers matching target fields, for example: device,profile,expect_serial,asset_id,ticket_id.

`make-usb` — Burn bootable USB

sudo zerodisk make-usb --device /dev/sdc --iso iso/zerodisk-live-YYYYMMDD-HHMMSS.iso
sudo zerodisk make-usb --device /dev/sdc --iso iso/zerodisk-live-YYYYMMDD-HHMMSS.iso --confirm sdc

Omitting --confirm opens an interactive device-name confirmation prompt.

`pxe-server` — PXE network boot server

# Build the ISO first
cd iso && ./build.sh

# Start PXE server (uses native dnsmasq; Docker is only a fallback)
sudo zerodisk pxe-server --interface eth0

The ISO build leaves only iso/build.sh, the timestamped iso/zerodisk-live-YYYYMMDD-HHMMSS.iso, and its .sha256 sidecar in iso/.

pxe-server can run in either mode:

From the Live ISO, it reads /media/bootmedia/boot/* and /media/bootmedia/live/filesystem.squashfs.
From a development checkout, it extracts vmlinuz, initramfs, and filesystem.squashfs from the newest generated ISO using xorriso.

`auto-nuke` — Datacenter kiosk mode ⚠️

sudo zerodisk auto-nuke --method dod3
sudo zerodisk auto-nuke --method secure-erase --strict-health

WARNING: Wipes ALL non-system disks in parallel, then shuts down. Requires typing a confirmation token.

Reports, Certificates & Attestation

Every wipe produces tamper-evident artifacts in reports/:

reports/
├── wipe-1713690000-dod3-sdb.json          ← Machine-readable audit report
├── wipe-1713690000-dod3-sdb.json.sha256   ← JSON report SHA256 checksum
├── wipe-1713690000-dod3-sdb.json.hmac     ← Optional HMAC-SHA256 signature
├── wipe-1713690000-dod3-sdb.json.ed25519  ← Optional Ed25519 signature
└── wipe-1713690000-dod3-sdb.html          ← Professional erasure certificate

HTML certificate includes:

Device path, method, pass count, timestamps, duration
Target identity snapshot (serial, model, size, transport)
Identity policy that was enforced before wiping
Chain-of-custody metadata (operator, organization, location, asset, ticket)
SMART health snapshot (pre-wipe)
Per-pass log with status
Verification result + entropy score
Compliance profile and hardware sanitization capability evidence
Unique certificate ID

--report-signing-key-env ENV_VAR reads the HMAC key from an environment variable. This keeps the signing secret out of shell history and report files.

--report-ed25519-private-key-env ENV_VAR signs the JSON report with an Ed25519 private seed/keypair in hex. verify-report --report-ed25519-public-key HEX_OR_PATH verifies the .ed25519 sidecar offline with the corresponding public key.

With --evidence-bundle, ZeroDisk creates reports/evidence/<bundle-id>/ containing copied report artifacts plus evidence.json and evidence.json.sha256.

Architecture

src/
├── main.rs          ← Entry point, command dispatch
├── cli.rs           ← clap CLI definitions
├── profile.rs       ← Compliance profile defaults and verification policy
├── plan.rs          ← JSON/TOML/CSV batch wipe plan parser
├── disk.rs          ← Disk discovery (lsblk / /sys/block fallback)
├── analysis.rs       ← Disk analysis (unique facts + health assessment)
├── wipe.rs          ← WipeRequest + wipe engine (native Rust, multi-pass, resume)
├── secure_erase.rs  ← ATA Secure Erase + NVMe Format + HPA/DCO
├── smart.rs         ← SMART data collection and assessment
├── safety.rs        ← System disk + mount + confirmation guards
├── autonuke.rs      ← Datacenter kiosk mode
├── shred.rs         ← Secure file shredding
├── freespace.rs     ← Free-space wiping
├── usb.rs           ← Bootable USB writer
├── pxe.rs           ← PXE DHCP/TFTP + HTTP rootfs server (native dnsmasq, Docker fallback)
└── logger.rs        ← fern logging (stderr + file + syslog)

tests/
└── cli_contract.rs  ← Integration tests for the documented CLI surface

examples/
├── wipe-plan.toml   ← Safe dry-run TOML batch plan example
└── wipe-plan.csv    ← Safe dry-run CSV batch plan example

iso/
└── build.sh         ← Alpine-based Live ISO generator with custom live initramfs

Performance

I/O block size: 16 MiB large buffered writes
Parallel: One worker thread per target disk via std::thread::scope
Resume: Checkpoint every 1 GiB with atomic rename
Progress: Independent indicatif progress bar per disk

Security Mechanisms

Guard	Description
Disk name confirmation	`--confirm` must match device name or path
System disk protection	Disk containing `/` cannot be wiped without `--force`
Mount check	Mounted filesystems and swap are blocked (not bypassable)
SMART health gate	`--strict-health`: aborts if critical SMART issues detected
Target identity lock	`--expect-serial`, `--expect-model`, `--min-size-bytes`, `--max-size-bytes`
Dry-run	`--dry-run`: Zero data written
Resume state	Atomic checkpoint write prevents corruption on crash
Resume identity lock	Checkpoints only resume when serial/model/size and wipe-plan hash still match
Multi-device confirmation	`WIPE-N` token required for parallel wipe
Symlink refusal	`shred` does not follow symlinks
Free-space temp safety	Unique hidden temp file with exclusive creation
Report attestation	JSON SHA256 sidecar plus optional HMAC-SHA256 and Ed25519 signatures

Logging

sudo zerodisk -v list           # INFO level
sudo zerodisk -vv list          # DEBUG level
RUST_LOG=debug sudo zerodisk list
sudo zerodisk --log-file /var/log/zerodisk.log wipe ...
sudo zerodisk --syslog wipe ... # Write to /var/log/syslog

Development Checks

make fmt
make test
make clippy
make doc
cargo check --locked
cargo test --locked --all-targets
cargo clippy --locked --all-targets -- -D warnings
RUSTDOCFLAGS="-D warnings" cargo doc --locked --no-deps
make dev-smoke   # Safe CLI smoke tests; does not touch block devices
make safe-checks # Hardware-safe end-to-end checks; does not write to disks

The project also enforces unsafe_code = "forbid" through Cargo lints and keeps CLI contract tests under tests/.

For a detailed non-destructive integration test plan, see docs/HARDWARE_SAFE_TEST_PLAN.md.

The ISO builder can be checked without creating files:

bash -n install.sh iso/build.sh
bash iso/build.sh --dry-run

⚠️ Critical Notes

SSD overwrite is not 100% guaranteed — use --method secure-erase or --method crypto-erase.
Operations are irreversible. Wrong disk selection means permanent data loss.
Root privileges are required for block device access.
AutoNuke also shuts down the system — use with extreme care.
PXE interface names are validated before dnsmasq configuration is generated.

Legal Disclaimer

ZeroDisk is a destructive data sanitization tool. It can permanently erase disks, files, partitions, boot media, and free-space contents. Before using it, you are solely responsible for confirming that every selected target is correct, that you have valid authorization, and that all required backups, approvals, retention obligations, chain-of-custody requirements, and legal or regulatory duties have been satisfied.

This software is provided as is, without any warranty of correctness, fitness for a particular purpose, compliance outcome, recoverability, or data destruction effectiveness on every device type. The authors, maintainers, and contributors accept no responsibility or liability for data loss, service interruption, business loss, hardware damage, failed sanitization, incorrect target selection, misuse, unauthorized use, regulatory non-compliance, or any direct, indirect, incidental, special, consequential, or punitive damages arising from the use or inability to use this software.

Use ZeroDisk only if you fully understand the risks. If you are unsure, stop and consult a qualified system administrator, security professional, legal advisor, or compliance officer before running any destructive command.

License

AGPL-3.0-only — See LICENSE

Author

Cuma KURT

Name		Name	Last commit message	Last commit date
Latest commit History 19 Commits
.github/workflows		.github/workflows
assets		assets
docs		docs
examples		examples
iso		iso
reports		reports
scripts		scripts
src		src
tests		tests
.gitignore		.gitignore
Cargo.lock		Cargo.lock
Cargo.toml		Cargo.toml
LICENSE		LICENSE
Makefile		Makefile
README.md		README.md
README_TR.md		README_TR.md
install.sh		install.sh

Folders and files

Latest commit

History

Repository files navigation

🛡 ZeroDisk — Enterprise Secure Disk Sanitization Suite

What Is ZeroDisk?

Requirements

Quick Install

Build from Source

Detailed Feature Guide

Disk Discovery and Inventory

SMART Health Assessment

Compliance Profiles

Hardware Sanitization Capability Probe

Wipe Engine and Wipe Methods

Verification Modes

Resume and Checkpoint Safety

Target Identity Lock

Confirmation and Destructive Safety

Reports, Certificates, and Evidence Bundles

HMAC and Ed25519 Attestation

Batch Wipe Plans

Webhook Notifications

Bootable ISO, USB, PXE, and AutoNuke

Logging and Operational Diagnostics

Commands

list — Enumerate disks

smart — Full SMART detail

analysis — Unique facts + health assessment (noise-reduced)

analysis --json schema versioning

profiles — Built-in compliance profiles

probe-sanitize — ATA/NVMe capability probe

verify-report — Verify report attestation

preflight — Non-destructive safety checks

wipe — Disk sanitization

Wipe Methods

shred — Secure file deletion

wipe-freespace — Wipe free space on live filesystem

run-plan — Batch wipe inventory manifest

make-usb — Burn bootable USB

pxe-server — PXE network boot server

auto-nuke — Datacenter kiosk mode ⚠️

Reports, Certificates & Attestation

Architecture

Performance

Security Mechanisms

Logging

Development Checks

⚠️ Critical Notes

Legal Disclaimer

License

Author

About

Topics

Resources

License

Uh oh!

Stars

Watchers

Forks

Releases

Packages 0

Uh oh!

Contributors

Uh oh!

Languages

`list` — Enumerate disks

`smart` — Full SMART detail

`analysis` — Unique facts + health assessment (noise-reduced)

`analysis --json` schema versioning

`profiles` — Built-in compliance profiles

`probe-sanitize` — ATA/NVMe capability probe

`verify-report` — Verify report attestation

`preflight` — Non-destructive safety checks

`wipe` — Disk sanitization

`shred` — Secure file deletion

`wipe-freespace` — Wipe free space on live filesystem

`run-plan` — Batch wipe inventory manifest

`make-usb` — Burn bootable USB

`pxe-server` — PXE network boot server

`auto-nuke` — Datacenter kiosk mode ⚠️

Packages