about

I bought some used hard drives, from a vendor that was new to me. I was careful with burn-in and testing, as they were being shipped and deployed remotely. I checked for defects and verified capacity. Testing quickly was important, so I could return something that wasn’t working, and get a replacement.

checking for defects

Most drives have SMART diagnostics built-in. It’s a good first pass, requiring little CPU or I/O from the system.

Using an external USB enclosure, and a Linux system, I ran smartctl to test them. I ran smartctl --scan-open to detect the device and type. Of the SMART tests:

• conveyance wasn’t available.
• short was quick, a few minutes.
• long took around 10 hours.

I can’t find my references for parsing the results; perhaps refer to the Wikipedia page.

Of the three drives, one wasn’t recognized. I plugged it in internally; it was recognized, though it yielded errors in the system logs, and smartctl was unable to start any tests. I returned this one drive for replacement, without issue.

verifying capacity

Or, Checking for counterfeits, bootlegs, and fakes

An issue mostly seen with flash drives: scammy, dodgy firmware lets it claim to have a multiple of its real capacity. If you try writing beyond its real capacity, it could:

• quietly discard the data
• quietly loop back and overwrite earlier data

badblocks is a classic tool for testing drives – however, it was first built for floppy disks. For the nondestructive mode, it would notice the first one (discarding data) but not the second (wrap around to earlier data). The Arch Linux wiki page for badblocks has a suggestion about using a crypto layer above the device.

I’m largely working from a Synology NAS. It lacks cryptsetup, and I’m not going to investigate how to install it, but the idea is sound:

Using an encryption key, we’ll fill the drive with encrypted zeroes. This would be ordering-sensitive – one can’t start decrypting from the middle. Then we’ll decrypt, starting from the beginning, and count how many zeroes we get back from the drive.

About encryption mode

(Avoiding ECB mode.)

CBC mode

“In CBC mode, each block of plaintext is XORed with the previous ciphertext block before being encrypted. This way, each ciphertext block depends on all plaintext blocks processed up to that point.”

Writing encrypted zeroes

Note: this can destroy any data on a drive, so check and double-check the device, sdq on mine. If it breaks, you keep both pieces.

This quick-and-dirty attempt worked quickly enough on my Synology NAS:

date
(for i in $(seq 800); do 
    cat /dev/zero | head -c 10000000000
    >&2 printf "."
    done) | \
  openssl aes256 -pass "pass:testing" > \
  /dev/sdq
date

That writes 800 x 10GiB chunks, for a total of 8TiB. It prints “.” every chunk, about one a minute.

Verifying encrypted zeroes

This doesn’t print progress information:

# cat /dev/sdq | \
  openssl aes256 -d -pass "pass:testing" | \
  cmp - /dev/zero

For my 8TB drive, the output:

- /dev/zero differ: char 8000000000001, line 1

There’s some difference between that and 8TB, due to base-10 terabytes vs base-2 tebibytes, but this ruled out that it was really a 1TB drive, handling my concern.

Side notes

Performance

My first attempt at reading zeroes involved xxd -a, which would essentially hexdump one line of zeroes, and skip other all-zero rows. I estimated the rate as under 1/10th the writing speed.

Hardware acceleration for aes 256 is common, along with Linux kernel support; I don’t think this method takes advantage. Adding -evp might do the trick though.

why not use pv on the Synology?

I would have loved to use pv – pipe viewer – for a handy progress meter and estimate for how long it would take, but it wasn’t readily available for my NAS.

Raspberry Pi notes

Side note: I tried this on my Raspberry Pi 4. I was able to use pv here for a nifty progress meter, get an ETA, etc. However, it ran at something like 1/4 the speed – unoptimized openssl? – so, non-starter. openssl required -md -md5 to accept the password; that’s deprecated. For what I’m doing, I didn’t have to worry about zeroes falling into the wrong hands.

Other software for this

I didn’t use these, but they’re likely better-put-together and more usable than my quick draft above. 🙂

• “F3 stands for f, or Fight Fake Flash.” Github repo, docs – available on several platforms.
• h2testw – from 2008, Windows only, download page is in German

No comments