FAQ

FAQ

Common questions about AAD-50, answered directly.

---

General

What is AAD-50?

AAD-50 is a firmware-enforced, 50-cycle NVMe sanitization framework. It issues hardware-level NVMe Sanitize commands directly to your drive's internal controller and verifies completion of every single cycle via Log Page 0x81 polling before advancing. It generates a SHA-256 tamper-evident audit chain and a PDF Certificate of Destruction for compliance purposes.

Is AAD-50 free?

Yes. Completely free and open source. Linux CLI, Windows CLI, and Windows GUI are all available at github.com/yonasabeselom/aad50.

Who is AAD-50 for?

Anyone who needs to prove — not just assume — that a drive is forensically clean. ITAD operators, compliance officers, system administrators, security researchers, and anyone retiring NVMe drives in HIPAA, GDPR, or defence contexts.

Where does the name come from?

AAD-50 stands for Abeselom ASIC-Direct 50. ASIC-Direct refers to the architecture — commands are issued directly to the drive's Application-Specific Integrated Circuit via IOCTL passthrough, bypassing the OS filesystem layer entirely. 50 refers to the total cycle count across all three phases.

---

Technical

Why 50 cycles? Isn't one sanitize cycle enough?

One correctly executed NVMe Sanitize cycle is enough to reach all physical locations — NVMe Sanitize with NSID=0xFFFFFFFF broadcasts to over-provisioned zones, bad-block retirement pools, and wear-levelling reserves in a single correctly executed cycle.

The 50-cycle allocation exists for two reasons:

First — firmware fault redundancy. Wei et al. (USENIX FAST 2011) documented that 3 of 12 drives failed to correctly execute the sanitize command they reported supporting. Multiple hardware-confirmed cycles provide redundancy against transient firmware faults that cause a specific cycle to execute incompletely.

Second — analog threshold voltage remanence. Hasan and Ray (USENIX Security 2020) demonstrated that data is partially recoverable from NAND flash even after digital sanitization via threshold voltage analysis. Repeated overwrite cycles progressively smooth the analog voltage distribution toward an indistinguishable baseline.

For most threat models, far fewer cycles are sufficient. The 50-cycle allocation is a conservative engineering default for high-assurance and nation-state threat contexts. A future --cycles N flag will allow operators to select a lower cycle count appropriate for their threat model.

Why B -> C -> A and not A -> B -> C?

Destroying the cryptographic key first — before physical overwrite — creates a window of vulnerability. If a hardware fault terminates the sequence mid-way through physical overwrite, an adversary with physical chip access could attempt to reconstruct the original key through side-channel analysis before the overwrite completed.

B -> C -> A ensures physical destruction leads and cryptographic destruction seals. Partial execution of B -> C -> A is always safer than partial execution of A -> B -> C.

Does AAD-50 work on non-SED drives?

Yes — but Phase A (Cryptographic Key Destruction) is effective only on Self-Encrypting Drives that maintain an internal Media Encryption Key. On non-SED drives, Phase A may return a success code without performing any meaningful operation. On such hardware the protocol's security rests entirely on Phases B and C — which together provide physical NAND overwrite and FTL index teardown across 45 hardware-confirmed cycles.

Does AAD-50 work on USB-connected NVMe drives?

Yes. AAD-50 v1.1 supports NVMe drives in USB 3.x enclosures with UASP via three-tier auto-detection. The tool probes the device at runtime and selects the highest available command pathway. Tier 1 (NVMe Direct) provides Log Page 0x81 hardware confirmation per cycle. Tiers 2 and 3 use conservative time-based polling where the USB bridge intercepts NVMe log page reads. For maximum assurance, direct M.2/PCIe connection is always recommended.

How long does AAD-50 take?

Because AAD-50 uses firmware-level NVMe Sanitize commands — not host-driven sequential writes — runtime is dramatically faster than software tools like Gutmann or DoD 5220.22-M.

Drive Capacity	Single Cycle	AAD-50 (50 cycles)
256 GB	3-10 seconds	2-8 minutes
512 GB	5-15 seconds	4-12 minutes
1 TB	8-20 seconds	7-17 minutes
2 TB	10-30 seconds	8-25 minutes
4 TB	15-60 seconds	12-50 minutes

Times vary by manufacturer, controller generation, and NAND geometry.

What does Log Page 0x81 actually tell you?

Log Page 0x81 is the NVMe Sanitize Status log page. After a sanitize command is dispatched, the host can poll this page and read the SSTAT field to determine actual hardware completion status:

SSTAT	Meaning
0x0	Idle - no recent sanitize
0x1	Completed successfully
0x2	Sanitize in progress
0x3	Completed with errors

AAD-50 polls this page on a 2-second interval after every cycle and refuses to advance until SSTAT = 0x1 is returned. SSTAT = 0x3 causes immediate abort with a fault record written to the audit log.

What is the SHA-256 audit hash?

After all 50 cycles complete, AAD-50 computes a SHA-256 hash over the key-sorted JSON serialisation of all cycle records. This hash is printed at the end of every run, embedded in the JSON audit log, and printed on the PDF Certificate of Destruction. Any modification to any cycle record changes the hash — making the audit log tamper-evident.

Can drive firmware lie to AAD-50?

A drive that deliberately misrepresents both sanitize execution and SSTAT reporting simultaneously cannot be caught by any software-level protocol. Against that threat model, physical destruction is the only reliable method. This limitation is documented explicitly in the whitepaper. AAD-50 detects and catches the class of silent failure Wei et al. documented — unintentional firmware bugs causing incorrect SSTAT reporting. It does not claim to defeat a drive that is deliberately designed to deceive.

---

Compliance

Does AAD-50 meet NIST SP 800-88 Rev.2?

AAD-50 is designed to align with NIST SP 800-88 Rev.2 Purge classification. Formal evaluation has not yet been conducted. The whitepaper documents the alignment in detail. See Standards Alignment for the full breakdown.

Is the PDF Certificate of Destruction legally recognised?

The PDF Certificate of Destruction provides operator name, drive serial number, SHA-256 audit hash, cycle-by-cycle completion confirmation, and compliance alignment documentation. Whether it satisfies specific regulatory requirements depends on your jurisdiction and regulatory framework. For HIPAA, GDPR, and enterprise ITAD contexts it provides the documentation chain compliance officers and auditors typically require.

Can I use AAD-50 for HIPAA compliance?

AAD-50 provides the technical sanitization and the audit documentation that HIPAA's media sanitization requirements call for. Whether it satisfies your organisation's specific HIPAA compliance programme depends on your programme's requirements. The PDF Certificate of Destruction and SHA-256 audit chain are designed to support exactly this use case.

---

Contributing

How do I submit a hardware test report?

See the Hardware Test Reports page. Add your result as a comment on Issue [#1] (Windows) or Issue [#2] (Linux), or email yonas_abeselom@protonmail.com.

Why do hardware test reports matter?

The USENIX FAST '27 paper submission requires empirical validation across multiple NVMe drive manufacturers, controller generations, and NAND geometries. Your retired drive is a direct contribution to that validation programme. Even a single result from a manufacturer not yet in the table is meaningful.

I found a bug. Where do I report it?

Open an issue at github.com/yonasabeselom/aad50/issues. Include your platform, Python version, drive model, and the full error output.

---

Contact

Yonas Abeselom
Independent Security Researcher - Addis Ababa, Ethiopia
yonas_abeselom@protonmail.com
github.com/yonasabeselom/aad50

---

AAD-50 v1.1 - github.com/yonasabeselom/aad50