Bootable Hardware Audit & Secure Erasure Tool
A single Linux script that turns an unknown, operating-system-less device into a complete hardware record and a certified erasure. It runs from a SystemRescue USB, reads the machine directly from firmware and sysfs, optionally performs a NIST-aligned purge, verifies the result, and uploads everything to the ITAD platform.
- Role
- Designer and engineer
- Timeline
- Jun 2025 — Present
- Status
- live
- Hardware categories captured
- 10Identification, system, CPU, memory, storage, graphics, display, battery, network, security.
- Erase methods dispatched
- 4NVMe format, NVMe sanitize, ATA secure erase, and overwrite — chosen per drive capability.
- Safety gates before any erase
- 2Off by default in config, plus a typed confirmation per machine.
The problem
Devices arrive for disposition already wiped. That is good for the client and inconvenient for the process: with no operating system there is nothing to run an inventory agent on, so every specification has to be typed in by hand from a label that may not exist. Meanwhile the erasure step — the part with legal weight — was being recorded as an assertion rather than performed and proven.
Research
I worked through what a live Linux environment can actually see without an installed OS: DMI tables for machine identity, lscpu for processor topology, sysfs for battery, TPM and UEFI state, lspci for graphics and network, and smartctl for drive health and wear. The gap analysis was as valuable as the capability list — operating system build, BitLocker state, BIOS password status and EDID display data are frequently unreadable on a wiped, live-booted unit, and I chose to omit those fields rather than guess at them.
Challenges
- 01
Verification has to be method-aware
An overwrite should read back as zeros; a cryptographic erase leaves ciphertext and never will. Verifying both the same way would either fail every crypto erase or pass every failed overwrite. The tool samples the start, middle and end of each drive after an overwrite, and falls back to a full zero-overwrite and re-verify if a fast erase does not read clean — while recording a crypto erase as controller-confirmed instead.
- 02
A locked drive is worse than an unwiped one
ATA secure erase sets a password before erasing. If the erase fails partway, the drive is left locked and effectively bricked. The implementation handles the frozen-state case explicitly and always runs the password-disable cleanup, so a failure degrades to 'not erased' rather than 'unusable'.
The solution
The tool boots unattended via SystemRescue's autorun, reads its credentials and target from a config file beside it, and asks the operator only what it genuinely cannot infer — which purchase lot the device belongs to. It builds a nested hardware profile, optionally erases the internal drives, verifies the erase, and posts the result. Every erase command targets exactly one device explicitly; there is no autonuke path that could take a whole bus with it. USB, removable and SD media are excluded structurally, so the boot stick can never be a target.
Result
Field-tested on real machines across Dell and Lenovo hardware. The capture path is reliable enough that devices are now created in the inventory system directly from the audit, rather than being registered by hand first — and the same pass produces the erasure record that the compliance certificate is generated from.
What I took from it
Documentation describes what a standard permits, not what a drive implements. An NVMe SSD that reported no crypto erase via FORMAT supported it via SANITIZE.
Destructive tools should be hard to misfire and easy to abort. Two gates, single-device commands, structural exclusion of removable media.
Write for the operator you actually have. The console guidance had to be explicit, one command at a time, and safe against spaces in paths.