NAND Sanitization: Pages, Erase Blocks and Bad-Block Evidence

Short answer

NAND programming and NAND erasure operate at different granularities. Replacing a file, programming selected pages or reading an empty filesystem does not establish that every physical location containing the old data was erased. A sanitization result must identify the blocks processed, the treatment of bad or remapped blocks, and the storage regions excluded from observation.

For raw or serial NAND, preserve the device's geometry and bad-block evidence before destructive work. Then use a qualified removal procedure and retain its actual results. A successful erase of accessible good blocks must not silently become a claim about inaccessible blocks or the entire board.

Who this is for

This guide is for engineers reviewing embedded-storage sanitization before board reuse or disposal. It concerns chip-level NAND and its host interface. Managed SSD, eMMC and UFS procedures add controller-specific behavior and need their own qualification.

The concrete example is W25N01GVxxIG/IT, Revision L, May 9, 2018, a serial SLC NAND device. This is an explicitly dated case study, not a claim that this is the newest datasheet or that the same commands apply to another suffix. Match the actual part, revision, board and tool before acting.

When to use this

Use the review when a process says “write zeros to NAND,” “erase all pages” or “skip bad blocks and pass.” These phrases hide different questions: what the host addresses, what hardware operation occurs, and what remains outside the completed scope.

Before selecting a technique, establish the data's sensitivity and the destination of the board. Decide what must be removed, what must be retained and which copies are authorized. If an engineering backup is created, it becomes another controlled copy requiring its own retention and eventual disposition.

When not to use this

Do not use this article as a generic NAND programmer recipe. There is no universal page size, spare-area layout, ECC mode, address sequence or erase timeout. Stop when the target geometry or controller behavior is unknown.

Do not clear factory bad-block markers to make a memory image look blank. Do not force writes to unreliable blocks merely to increase an erased-block count. If required data may remain in locations that the approved process cannot sanitize, keep the asset on hold for an approved alternative disposition.

Workflow

1. Separate the units of work

A page is a unit used in programming and reading; an erase block groups multiple pages. Host-visible sectors and filesystem clusters belong to still other layers. A command that updates a page is not equivalent to an operation that erases its containing block.

In the W25N01GV example, a main-data page contains 2,048 bytes, with 64 bytes of spare area. An erase block contains 64 pages: 64 × 2,048 = 131,072 main-data bytes, or 128 KiB. This arithmetic describes geometry only; spare bytes are a separate part of the page layout. It gives neither a wipe duration nor a probability of recovery.

Use the exact device definition rather than inferring geometry from a capacity label. Record how the reader handles main data, spare/OOB data, ECC and addressing. A “raw” filename is not evidence that the capture includes every one of those elements.

2. Keep cell density separate from removal assurance

SLC stores one bit per cell; the common two-bit MLC, three-bit TLC and four-bit QLC labels describe increasing bits per cell. They do not specify a sanitization method or tell you how many overwrite passes to run.

The SLC example here establishes no erase sequence, timing, endurance or recovery probability for TLC or QLC. Nor can a cell-density label establish whether a host operation reaches remapped storage. Obtain the applicable device and controller behavior rather than turning a marketing category into an erasure guarantee.

3. Preserve the bad-block map before changing data

Record existing invalid-block markers, the host's bad-block table and any device-level replacement mapping used by the approved interface. Keep the distinction between factory-invalid blocks and blocks retired during service. The latter may have held target data before they became unreliable.

For the example part, initial invalid-block markers must be identified before program or erase operations because accidentally erased factory information cannot be recovered. Its bad-block-management lookup table can redirect accesses to replacement blocks. A scan through a translated view therefore needs a mapping explanation before it can support physical-coverage claims.

Linux NAND designs can maintain bad-block information in RAM or flash, including mirrored flash tables. Document the actual driver policy. A memory-image length alone cannot tell a reviewer whether excluded blocks, OOB or reserved table locations were included.

4. Build a coverage ledger

Create an internal ledger before execution. The following is a proposed review aid, not a standard-mandated form:

• Included good blocks: addressed by the approved operation, with individual or batch completion evidence.
• Initially invalid blocks: identified and preserved in the inventory, with their disposition explained.
• Retired or redirected blocks: assessed for prior target data and supported removal coverage.
• Spare, reserved and special areas: listed separately with applicable access and treatment.
• Unresolved regions: kept visible as exceptions that prevent an unsupported whole-device claim.

Do not calculate success solely as “processed blocks divided by accessible blocks.” That denominator can omit exactly the locations that create the confidentiality concern. If coverage is incomplete, state the completed subset and the unresolved scope separately.

5. Qualify the erase and its status evidence

For the dated example, block erase addresses a 64-page block and returns it to an all-ones logical state. A write-enable prerequisite and protection conditions apply. The exact instruction transaction and permitted electrical conditions must come from the matching device procedure; this article does not supply a generic bus script.

Record the result before resetting the device or beginning another operation. On this example, program/erase failure indicators can be cleared by a subsequent operation or reset. Capturing only a final status snapshot after an entire batch can lose the evidence needed to identify an earlier failure.

A ready indication means the device can accept another operation; it must be interpreted together with failure status and the addressed scope. If a block fails, retain its identity, status and disposition. Do not reclassify it as erased merely because the process continued to the next block.

6. Verify the accessible result and decide disposition

Where the qualified procedure calls for read-back, record whether ECC was enabled, which regions were read, which addresses were excluded and how read errors were handled. Corrected data, uncorrectable data and an unobserved address are different outcomes.

An all-ones read is a logical observation through the selected path. It is not an analog examination of cell remanence or a proof about skipped locations. An interrupted command, lost connection or read failure leaves an exception to resolve using model-specific guidance.

The release reviewer should compare the final ledger with the original target-data scope. Escalate required but unsanitized regions to the approved method or disposition. Preserve that decision instead of hiding the exception behind a generic “PASS.”

Verification checklist

• The actual chip, suffix, revision, interface and tool build are recorded.
• Page, erase-block, spare-area and host-address units are distinguished.
• Bad-block markers and mapping evidence were captured before modification.
• Every required region has a completed result or an explicit exception.
• Failure evidence was retained before another command or reset could clear it.
• Read-back interpretation states ECC, exclusions and observation limits.

Resale and evidence checklist

Keep the target-data map, initial block inventory, approved procedure, operation results, failed-region list and reviewer decision together. If an inaccessible retired block remains a confidentiality concern, the record must show how the board was held or otherwise disposed of.

NIST SP 800-88 Rev. 2 separates checking an operation's outcome from deciding whether the result is adequate. Use that distinction to prevent a successful subset from being recorded as an accepted whole-device result. Do not assign a stronger sanitization classification from the word “erase” alone.

What not to publish

Keep customer fragments, raw dumps, identifiers and sensitive mapping details in the authorized evidence system. Do not publish fabricated microscope findings, recovery percentages or chip-off resistance claims. This guide establishes no capability, certification or availability of forthcoming wiping software.

Common mistakes

Counting page writes as block erases. The operations act at different levels and need different evidence.

Calling skipped blocks irrelevant. A retired block may have held data; its disposition needs a reason.

Erasing first and collecting markers later. Destructive work can remove the inventory needed to interpret the device.

Saving only a final ready status. Earlier failures may no longer be visible.

Using SLC behavior as a TLC recipe. The dated example is a single model, not a universal NAND operating rule.

CliDeck workflow fit

A runbook can require the initial mapping record, per-operation evidence and exception decision before release. Attach actual observations when the approved workflow supports the record. This is a process recommendation, not a claim that CliDeck currently performs raw NAND erase or validates physical cell behavior.

FAQ

Does an all-ones read prove complete sanitization?

It describes the selected read path and scope. It does not independently establish treatment of inaccessible blocks or analog remanence.

Should I erase bad-block markers to get a blank image?

No. Preserve the information needed for safe interpretation and use the approved disposition for unresolved regions. A cosmetically blank image is not the objective.

Do TLC and QLC require extra overwrite passes?

The labels alone establish no pass-count rule. Use the actual device's supported sanitization behavior and its coverage evidence.

Related guides

Review flash translation and host coverage, compare eMMC area boundaries, and examine separate storage in SPI NOR.

Verification note: geometry and documentation review

The geometry multiplication was checked; relevant model-scoped datasheet and driver material were reviewed. No NAND chip was read, programmed, erased or physically examined for this article. Operational checks describe evidence that a qualified future procedure must collect.