How to zero a failing disk drive before disposal?

15 views
Skip to first unread message

Ronald F. Guilmette

unread,
Oct 10, 2024, 7:58:16 AM10/10/24
to ques...@freebsd.org
I have a pretty ancient 4TB spinning rust drive (WD4001FAEX) that is unambiguously at
death's door:

1 Raw_Read_Error_Rate 0x002f 200 173 051 Pre-fail Always - 0
3 Spin_Up_Time 0x0027 167 161 021 Pre-fail Always - 10641
4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 155
5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 1
7 Seek_Error_Rate 0x002e 200 200 000 Old_age Always - 0
9 Power_On_Hours 0x0032 099 099 000 Old_age Always - 829
10 Spin_Retry_Count 0x0032 100 100 000 Old_age Always - 0
11 Calibration_Retry_Count 0x0032 100 253 000 Old_age Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 80
192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 24
193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 130
194 Temperature_Celsius 0x0022 126 098 000 Old_age Always - 26
196 Reallocated_Event_Count 0x0032 199 199 000 Old_age Always - 1
197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 36
198 Offline_Uncorrectable 0x0030 200 200 000 Old_age Offline - 32
199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0
200 Multi_Zone_Error_Rate 0x0008 200 200 000 Old_age Offline - 40

In addition to the above clear indications of failure, "smartctl -t long" dies almost
immediately with a fatal error.

Now I plan to dispose of the drive (appropriately, at a proper e-waste recycling place)
however there may be some confidential data on the thing that should be wiped first...
because I'm paranoid.

I used to own an old RadioShack bulk tape eraser (basically just a big electromagnet)
that I would use on drives before disposing of them but I don't have that any more.

I could try using smartctl to initiate a secure erase, but for various reasons it would
just be more convenient if I could just dd /dev/zero to the thing. But there's a catch.

According to what I have read, dd will halt if it encounters a write error. That's a
clear problem in this context. Also, according to the dd man page, the conv=noerror
option for dd won't really be helpful in this case since that just prevents dd from
stopping on _input_ errors.

Any suggestions? If worse comes to worse I guess I will end up writing my own tiny
little C program to just write 4KB blocks to a designated output file while ignoring
all output errors, but I don't want to reinvent the wheel if somebody else already
created something I can use in this context.

Suggestions welcome.

Matthias Apitz

unread,
Oct 10, 2024, 8:22:03 AM10/10/24
to ques...@freebsd.org
El día jueves, octubre 10, 2024 a las 04:57:49 -0700, Ronald F. Guilmette escribió:

> I have a pretty ancient 4TB spinning rust drive (WD4001FAEX) that is unambiguously at
> death's door:
>
> ...

I used once an axe to destroy the (metal) case and slices and
then I throw it into the wastebin of my house which is emtied once a
week into a big truck and perhaps it content is put on fire.

> Any suggestions? If worse comes to worse I guess I will end up writing my own tiny
> little C program to just write 4KB blocks to a designated output file while ignoring
> all output errors, but I don't want to reinvent the wheel if somebody else already
> created something I can use in this context.

Overwriting the data will not help. The reading head(s) could be
adjusted and read the data on the side of the old track.

matthias

--
Matthias Apitz, ✉ gu...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

Annalena Baerbock: "We are fighting a war against Russia ..." (25.1.2023)

I, Matthias, I am not at war with Russia.
Я не воюю с Россией.
Ich bin nicht im Krieg mit Russland.

Odhiambo Washington

unread,
Oct 10, 2024, 8:36:59 AM10/10/24
to Matthias Apitz, ques...@freebsd.org
On Thu, Oct 10, 2024 at 3:21 PM Matthias Apitz <gu...@unixarea.de> wrote:
El día jueves, octubre 10, 2024 a las 04:57:49 -0700, Ronald F. Guilmette escribió:

> I have a pretty ancient 4TB spinning rust drive (WD4001FAEX) that is unambiguously at
> death's door:
>
> ...

I used once an axe to destroy the (metal) case and slices and
then I throw it into the wastebin of my house which is emtied once a
week into a big truck and perhaps it content is put on fire.

> Any suggestions?  If worse comes to worse I guess I will end up writing my own tiny
> little C program to just write 4KB blocks to a designated output file while ignoring
> all output errors, but I don't want to reinvent the wheel if somebody else already
> created something I can use in this context.

Overwriting the data will not help. The reading head(s) could be
adjusted and read the data on the side of the old track.

        matthias

I open the case, remove the platters and the magnets (for use elsewhere), and repurpose the casing! 


--
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
 In an Internet failure case, the #1 suspect is a constant: DNS.
"Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-)

Michael Sierchio

unread,
Oct 10, 2024, 8:47:31 AM10/10/24
to Ronald F. Guilmette, ques...@freebsd.org
On Thu, Oct 10, 2024 at 7:58 AM Ronald F. Guilmette <r...@tristatelogic.com> wrote:
I have a pretty ancient 4TB spinning rust drive (WD4001FAEX) that is unambiguously at
death's door:
 
Any suggestions?  If worse comes to worse I guess I will end up writing my own tiny

little C program to just write 4KB blocks to a designated output file while ignoring
all output errors, but I don't want to reinvent the wheel if somebody else already
created something I can use in this context.

There is no method of writing to a disk that can reliably delete or obscure all data – modern disk drives silently remap sectors, making them unavailable to the host for writes.  If the data on the drive is particularly sensitive, physical destruction of the media is the best approach.  The DOD method is crush, then burn. ;-)

– M 

mike tancsa

unread,
Oct 10, 2024, 9:05:00 AM10/10/24
to Ronald F. Guilmette, ques...@freebsd.org

We do both for disks.  We do a dd if=/dev/urandom first. Regardless if that fails/passes, we then physically destroy the disk.  The idea being if for some reason step 2 is missed, low effort prying eyes will not find anything.    Depends on your situation and sensitivity of the data.

    ---Mike


rob...@rrbrussell.com

unread,
Oct 10, 2024, 9:16:51 AM10/10/24
to Michael Sierchio, Ronald F. Guilmette, ques...@freebsd.org
> -M

True M but you’re completely ignoring applicable threats. Unless you’re likely a target of supply chain tampering, just use the ATA Secure Erase feature built into the drives firmware and send the failing drive out for proper recycling.

Physical destruction of the drives is the only option if supply chain tampering is a concern otherwise encrypt the disk, use the ATA Secure Erase, and reuse or recycle depending on estimated drive life left.

The hdparm manual page discusses how to invoke the ATA Secure Erase feature. It may require hot plugging the data cable for the drive.

Ralf Mardorf

unread,
Oct 10, 2024, 11:17:48 AM10/10/24
to ques...@freebsd.org
On Thu, 2024-10-10 at 15:36 +0300, Odhiambo Washington wrote:
> remove the [...] the magnets (for use elsewhere)

Hi,

in terms of sustainability and children's education, this is my
favourite piece of advice.

https://www.youtube.com/watch?v=rn6rgxsm5oA
https://www.youtube.com/watch?v=NXD9gDCw7uU

On Thu, 2024-10-10 at 04:57 -0700, Ronald F. Guilmette wrote:
> I'm paranoid.

Someone might have the skills to extract data even after the plates have
been shredded and fused into a lump.

Maybe it is best to sherd the plates, mix the fragments and shoot one
half into the sun with a rocket and the other half onto Venus.

On Thu, 2024-10-10 at 08:16 -0500, rob...@rrbrussell.com wrote:
> invoke the ATA Secure Erase feature

ATA Secure Erase or ATA Cryptographic Key Reset are as secure as a pager
or walkie-talkie, as it is impossible to know whose fingers were
involved in their manufacture or in the supply chain.

How paranoid were you when the drive was still in use? Was the computer
hidden deep in a secret vault in a bunker in a mountain?

If you are not too paranoid, consider to dismantle the drive and dispose
a part of it in an environmentally friendly way, while placing the
damaged plates in public waste bins in various places.

Regards,
Ralf

Matthew Seaman

unread,
Oct 10, 2024, 12:14:08 PM10/10/24
to ques...@freebsd.org
On 10/10/2024 16:17, Ralf Mardorf wrote:
> Someone might have the skills to extract data even after the plates have
> been shredded and fused into a lump.

The Néel temperature for steel is typically somewhere around 200 -- 500
ºC depending on the alloy. Steel that is hot enough to "fuse into a
lump" will need to be significantly hotter than that -- nearly at the
melting point. All of the magnetic information will have been wiped.

Other ferromagnets useable for magnetic recording are going to behave
similarly.

Cheers,

Matthew

Tomek CEDRO

unread,
Oct 10, 2024, 12:16:14 PM10/10/24
to Ronald F. Guilmette, ques...@freebsd.org
sysutils/ddrescue helped me to read broken drives several times, it
retries then skips on errors.

sysutils/e2fsprogs has program badblocks that can help disk rebuild in
read only mode, or make things worse depending how its broken, and you
can use it many loops of destructive write test to overwrite data.

the safest way to dispose sensitive data is by physical destruction :-)

--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

Ralf Mardorf

unread,
Oct 10, 2024, 12:40:21 PM10/10/24
to ques...@freebsd.org
On Thu, 2024-10-10 at 17:13 +0100, Matthew Seaman wrote:
> Steel that is hot enough to "fuse into a lump" will need to be
> significantly hotter than that -- nearly at the melting point.  All of
> the magnetic information will have been wiped.
>
> Other ferromagnets useable for magnetic recording are going to behave
> similarly.

Hi,

you only need a morphogenetic field resonator to read data from a
demagnetised lump, see
https://static.spektrum.de/fm/912/f2000x857/245808923_pa.jpg ;).

Regards,
Ralf

Tomek CEDRO

unread,
Oct 10, 2024, 1:46:53 PM10/10/24
to Ralf Mardorf, ques...@freebsd.org
On Thu, Oct 10, 2024 at 6:40 PM Ralf Mardorf wrote:
> On Thu, 2024-10-10 at 17:13 +0100, Matthew Seaman wrote:
> > Steel that is hot enough to "fuse into a lump" will need to be
> > significantly hotter than that -- nearly at the melting point. All of
> > the magnetic information will have been wiped.
> > Other ferromagnets useable for magnetic recording are going to behave
> > similarly.
>
> you only need a morphogenetic field resonator to read data from a
> demagnetised lump, see
> https://static.spektrum.de/fm/912/f2000x857/245808923_pa.jpg ;).

I have something like this somewhere in my basement.. we only need to
make it pocket size now and battery powered plus the USB interface so
it works on FreeBSD :D :D :D

Chris Craft

unread,
Oct 10, 2024, 2:08:01 PM10/10/24
to ques...@freebsd.org

The message was intended to go back to the list... (Sorry, Matt!)



-------- Forwarded Message --------
Subject: Re: How to zero a failing disk drive before disposal?
Date: Thu, 10 Oct 2024 10:19:03 -0600
From: Chris Craft <ccr...@netgenius.org>
To: Matthew Seaman <mat...@FreeBSD.org>


I was going to mention "Curie point", but this seems to be a complex topic. (Forum discussion: https://www.overclockers.com/forums/threads/what-is-the-curie-point-of-hdd-magnetic-platters.454159/ )

I think you'd be just fine putting it in the oven on the cleaning cycle (about 550F).

-C


On 10/10/24 10:13, Matthew Seaman wrote:
On 10/10/2024 16:17, Ralf Mardorf wrote:
Someone might have the skills to extract data even after the plates have
been shredded and fused into a lump.

The Néel temperature for steel is typically somewhere around 200 -- 500 ºC depending on the alloy.  Steel that is hot enough to "fuse into a lump" will need to be significantly hotter than that -- nearly at the melting point.  All of the magnetic information will have been wiped.


Other ferromagnets useable for magnetic recording are going to behave similarly.

    Cheers,

    Matthew

rob...@rrbrussell.com

unread,
Oct 10, 2024, 2:35:28 PM10/10/24
to ques...@freebsd.org
On Thu, Oct 10, 2024, at 10:17, Ralf Mardorf wrote:
>
> On Thu, 2024-10-10 at 08:16 -0500, rob...@rrbrussell.com wrote:
>> invoke the ATA Secure Erase feature
>
> ATA Secure Erase or ATA Cryptographic Key Reset are as secure as a pager
> or walkie-talkie, as it is impossible to know whose fingers were
> involved in their manufacture or in the supply chain.

Quit spreading FUD. The cost of building a subverted drive isn’t worth the time or money for general distribution in the economy. You need a high percentage of the drive’s physical capacity dedicated to spare space to get a decent chance of catching useable data in “reallocated” space. Of course your competition can just sell a higher capacity drive and put you out of business.

The easiest way to destroy information is forgetting the encryption key but most people don’t use FDE.

Doug Hardie

unread,
Oct 10, 2024, 3:22:53 PM10/10/24
to ques...@freebsd.org
Encryption is not the answer. There is always a key that will decrypt the data. The only issue is to find it. NSA, M4, KGB (or whatever they are know as now), and possibly several other intel agencies have the resources to decrypt it. Chances they would be interested in your data is pretty slim, but I have seen several times where people were able to guess the key in just a few tries.

I believe the easiest approach is to disassemble the unit, remove the platter and sand it. The information is in the iron oxide (brown stuff). Sanding it removes it as dust. This is essentially what a head crash does. It doesn't take a lot of effort to sand it. The head contacting the disk does a great job.

-- Doug


Ralf Mardorf

unread,
Oct 10, 2024, 5:08:02 PM10/10/24
to ques...@freebsd.org
On Thu, 2024-10-10 at 12:22 -0700, Doug Hardie wrote:
> I believe the easiest approach is to disassemble the unit, remove the
> platter and sand it.

Then "they" don't know what was on the hard drive, but "they" do know
that something was on it. Who owns a sandblasting machine?

However, I'm sure most of us agree that sheer force is more effective
than nerdy software. You wouldn't make notes on paper illegible with an
eraser, you would first tear up the paper, then burn the shreds and
grind the ashes in a mortar and mix the ashes into the dog food.

For HDDs the Italian mafia probably uses pizza ovens. So it looks like
an accident to the public prosecutor's office if the hard drive got into
the pizzeria's pizza oven.

On Thu, 2024-10-10 at 13:34 -0500, rob...@rrbrussell.com wrote:
>The cost of building a subverted drive isn’t worth the time or money
>for general distribution in the economy.

The first step is owning a company, this is possible:
https://en.wikipedia.org/wiki/Crypto_AG

The second step, which concerns your counter-argument, is possible by
switching from CMR to a well-developed SMR-like process. Who really
knows what efficient writing methods are available today? Even if it's
probably just a silly fantasy with HDDs, it's not far-fetched with SSDs.

The advantage of SSDs could be that the data is probably lost relatively
quickly if they have not been supplied with power for a long time.



Ralf Mardorf

unread,
Oct 10, 2024, 5:20:03 PM10/10/24
to ques...@freebsd.org
On Thu, 2024-10-10 at 19:46 +0200, Tomek CEDRO wrote:
> > https://static.spektrum.de/fm/912/f2000x857/245808923_pa.jpg ;).
>
> I have something like this somewhere in my basement.. we only need to
> make it pocket size now and battery powered

In my garage is a fuel cell powered Ocean's Eleven electromagnetic pulse
machine, https://www.youtube.com/watch?v=A1H4LqEnAnY .


Ralf Mardorf

unread,
Oct 10, 2024, 5:33:33 PM10/10/24
to ques...@freebsd.org
On Thu, 2024-10-10 at 23:07 +0200, Ralf Mardorf wrote:
> The advantage of SSDs could be that the data is probably lost
> relatively quickly if they have not been supplied with power for a
> long time.

Hearsay, therefore "quickly" vs "long time" :D

AFAIK SSDs really do function in such a way that the actual storage
space is significantly larger than the space available to the user. It
would cost a secret service nothing, just a backdoor to access the whole
space.

Ronald F. Guilmette

unread,
Oct 10, 2024, 8:39:13 PM10/10/24
to ques...@freebsd.org
In message <CAAdA2WNgKoxpb-=p1gMDyZ5XMZEMfz3_...@mail.gmail.com>,
Odhiambo Washington <odhi...@gmail.com> wrote:

>I open the case, remove the platters and the magnets (for use elsewhere),
>and repurpose the casing!

Thank you. Yes, as a last step I shall be opening the case & pouring some
small amount of sand inside (and then shaking vigorously).

But if a nation state was determined to get my old credit card number, even
that might not stop them! :-)

Ronald F. Guilmette

unread,
Oct 10, 2024, 8:52:29 PM10/10/24
to ques...@freebsd.org
In message <4592b3d058a5c2c2c5acf75...@riseup.net>,
Ralf Mardorf <ralf-m...@riseup.net> wrote:

>On Thu, 2024-10-10 at 15:36 +0300, Odhiambo Washington wrote:
>in terms of sustainability and children's education, this is my
>favourite piece of advice.
>
>https://www.youtube.com/watch?v=3Drn6rgxsm5oA
>https://www.youtube.com/watch?v=3DNXD9gDCw7uU

I wish that I understood German.

>Someone might have the skills to extract data even after the plates have
>been shredded and fused into a lump.
>
>Maybe it is best to sherd the plates, mix the fragments and shoot one
>half into the sun with a rocket and the other half onto Venus.

Thank you. I will be contacting Elon Musk to see if I can arrange
interplanetary passage for my platters.

>How paranoid were you when the drive was still in use? Was the computer
>hidden deep in a secret vault in a bunker in a mountain?

Yes! How did you know? Has someone leaked photographs of my secret
mountain lair??

>If you are not too paranoid, consider to dismantle the drive and dispose
>a part of it in an environmentally friendly way, while placing the
>damaged plates in public waste bins in various places.

Thank you. That shall be done also.

Ronald F. Guilmette

unread,
Oct 10, 2024, 9:00:26 PM10/10/24
to ques...@freebsd.org
In message <4d4886050a110040091998c...@riseup.net>,
Ralf Mardorf <ralf-m...@riseup.net> wrote:

>you only need a morphogenetic field resonator to read data from a
>demagnetised lump, see
>https://static.spektrum.de/fm/912/f2000x857/245808923_pa.jpg ;).

You guys are kraken me up!

Dewayne Geraghty

unread,
Oct 10, 2024, 10:44:06 PM10/10/24
to ques...@freebsd.org
A good question Ronald. I worked for a provider of services for the
statutory care of children (eg removed from parents). There are
significant penalties for certain types of information loss. We
bench-drilled the hard-disks before sending them (out of our chain of
custody) to a furnace. Admittedly this is an extreme case and for the
reasons already stated in this thread, there was no other way to ensure,
say a name and location, were not available.

And yes, all machines have full disk encryption (FDE).

For personal devices we overwrite the device multiple times, though I'm
interested in what a "ATA Secure Erase" does to a healthy storage device
and whether all sectors are touched?


Ralf Mardorf

unread,
Oct 11, 2024, 3:13:55 AM10/11/24
to ques...@freebsd.org
On Fri, 2024-10-11 at 13:42 +1100, Dewayne Geraghty wrote:
> I worked for a provider of services for the statutory care of children
> (eg removed from parents). [...] We bench-drilled the hard-disks
> before sending them (out of our chain of custody) to a furnace.

+1

> For personal devices we overwrite the device multiple times

After countless discussions about [1] and having recovered and not
recovered lost data myself, I am firmly convinced that it is sufficient
for a private household to overwrite just 1 time. After that Joe and
Jane Lunchbucket can't recover the data anymore and it's also quasi
impossible for a geek to recover something.

The problem with the Lunchbucket family's HDDs is that they only replace
them when they are defective anyway. At best, you can free up stuck
heads and be happy if you can get your 4 TB drive overwritten at all. In
these cases, the question of how often you should overwrite does not
even arise.

It is not for nothing that it is said that you should mount a drive
"read only" as soon as possible after data has been lost in order to
have any chance of recovering anything at all.

Criminals and secret services will think twice about whether it is worth
subjecting the Lunchbucket family's hard drive to time-consuming and
costly forensic treatment.

[1]
• rocketmouse@archlinux ~
$ man shred | grep -eiterations -eCAUTION -A1
-n, --iterations=N
overwrite N times instead of the default (3)
--
CAUTION: shred assumes the file system and hardware overwrite data in place. Although this is common, many platforms operate otherwise. Also, backups and mirrors may contain unre‐
movable copies that will let a shredded file be recovered later. See the GNU coreutils manual for details.

Ronald F. Guilmette

unread,
Oct 11, 2024, 3:34:06 AM10/11/24
to ques...@freebsd.org
In message <2544410a-8a99-4b2e...@heuristicsystems.com.au>,
Dewayne Geraghty <dew...@heuristicsystems.com.au> wrote:

>A good question Ronald. I worked for a provider of services for the
>statutory care of children (eg removed from parents). There are
>significant penalties for certain types of information loss. We
>bench-drilled the hard-disks before sending them (out of our chain of
>custody) to a furnace. Admittedly this is an extreme case and for the
>reasons already stated in this thread, there was no other way to ensure,
>say a name and location, were not available.

Interesting.

I decided to go ahead and use S.M.A.R.T. secure erase on this drive
after all, and then take the cover off and then...

(Fortunately I have the necessary Torx[tm] screwdrivers to get the cover off.)

I hadn't thought of drilling some holes in the platters after that, but that
is part of my plan now. NICE IDEA! THANKS!

I'm pretty sure that will render the platters entirely un-spinable.

Ronald F. Guilmette

unread,
Oct 11, 2024, 3:45:05 AM10/11/24
to ques...@freebsd.org
In message <0bd5d79d35bb036fc73cd22...@riseup.net>,
Ralf Mardorf <ralf-m...@riseup.net> wrote:

>After countless discussions about [1] and having recovered and not
>recovered lost data myself, I am firmly convinced that it is sufficient
>for a private household to overwrite just 1 time. After that Joe and
>Jane Lunchbucket can't recover the data anymore and it's also quasi
>impossible for a geek to recover something.

Agree. But I'm a "belt & suspenders" kind of guy. :-)

>The problem with the Lunchbucket family's HDDs is that they only replace
>them when they are defective anyway. At best, you can free up stuck
>heads and be happy if you can get your 4 TB drive overwritten at all.

I should know one way or the other in about 8 hours.

>It is not for nothing that it is said that you should mount a drive
>"read only" as soon as possible after data has been lost in order to
>have any chance of recovering anything at all.

Fortunately, I had the Good Sense to have multiple recent backups, so
I don't believe I lost anything. But I cloned the failing drive onto
a fresh near-new drive (which I'm using now) which could posibly mean
that I have some corrupted files on the new production drive. I'm in
the process of md5'ing all important files on both the new production
drive and one of my backups. When that's all done I'll compare the two
sets of md5 hashes and retrieve anything where I got a mismatch from
the backup drive. (I believe that the backup in question was made
_before_ I installed the now-failing drive and tried to use it as a
production drive.)


Markus Graf

unread,
Oct 11, 2024, 3:46:49 AM10/11/24
to ques...@freebsd.org

Years ago I heared the recommended way for embassies was to have
an emergency set ready, consisting of a solid chisel and a heavy
hammer.

Make shure to shatter the disks.

When you have time put your chisel to the the hard disk where the
platters are, then hit hard.

If in a hurry put the chisel to the laptop where the disks are an
hit hard ;-)

Tomek CEDRO <to...@cedro.info> writes:

> sysutils/ddrescue helped me to read broken drives several times,
> it
> retries then skips on errors.
>
> sysutils/e2fsprogs has program badblocks that can help disk
> rebuild in
> read only mode, or make things worse depending how its broken,
> and you
> can use it many loops of destructive write test to overwrite
> data.
>
> the safest way to dispose sensitive data is by physical
> destruction :-)


--
Markus Graf


Ralf Mardorf

unread,
Oct 11, 2024, 3:48:14 AM10/11/24
to ques...@freebsd.org
On Fri, 2024-10-11 at 09:12 +0200, Ralf Mardorf wrote:
> After countless discussions [...] I am firmly convinced that it is
> sufficient for a private household to overwrite just 1 time.
>
> The problem with the Lunchbucket family's HDDs is that they only
> replace them when they are defective anyway.

For sure we will not use kind of a shred program that tries to overwrite
files, we will use kind of a dd command with a random pattern, zeros or
else.

On Thu, 2024-10-10 at 04:57 -0700, Ronald F. Guilmette wrote:
> I could just dd /dev/zero to the thing. But there's a catch.
> According to what I have read, dd will halt if it encounters a write
> error.

By

https://unix.stackexchange.com/questions/229354/how-to-ignore-write-errors-while-zeroing-a-disk

a "sdd" command is mentioned, wich seems to be provided by
https://sourceforge.net/projects/schilytools/files/

and it might be available for FreeBSD,
https://www.freshports.org/devel/schilybase .

FWIW the Arch User repository provides schily-tools-sdd, but Arch Linux
doesn't provide a live media. Ubuntu and friends provide a live media,
but they don't provide schilytools, but it might build without issues on
an Ubuntu or so live media,
https://www.unixmen.com/install-schily-tools-on-linux/ .

Ronald F. Guilmette

unread,
Oct 11, 2024, 4:00:22 AM10/11/24
to ques...@freebsd.org
In message <d093f0ac42c0bb9c05ce855...@riseup.net>,
Ralf Mardorf <ralf-m...@riseup.net> wrote:

>https://unix.stackexchange.com/questions/229354/how-to-ignore-write-errors-while-zeroing-a-disk
>
>a "sdd" command is mentioned, wich seems to be provided by
>https://sourceforge.net/projects/schilytools/files/
>
>and it might be available for FreeBSD,
>https://www.freshports.org/devel/schilybase .
>
>FWIW the Arch User repository provides schily-tools-sdd, but Arch Linux
>doesn't provide a live media. Ubuntu and friends provide a live media,
>but they don't provide schilytools, but it might build without issues on
>an Ubuntu or so live media,
>https://www.unixmen.com/install-schily-tools-on-linux/ .

Thanks Ralf. I'll definitely give this a try if I can't get the SMART
secure erase to complete.

Ralf Mardorf

unread,
Oct 11, 2024, 4:22:23 AM10/11/24
to ques...@freebsd.org
On Fri, 2024-10-11 at 00:44 -0700, Ronald F. Guilmette wrote:
> > It is not for nothing that it is said that you should mount a drive
> > "read only" as soon as possible after data has been lost in order to
> > have any chance of recovering anything at all.
>
> Fortunately, I had the Good Sense to have multiple recent backups, so
> I don't believe I lost anything.

I just wanted to say that on the one hand we rightly fear data loss and
therefore make backups instead of relying on the fact that one time
overwritten data possibly can be restored, because it's basically not
possible, at least not without a lab with glowing green liquids,
flashing Tesla coils and stuff like that and on the other hand, we
believe that data that has only been overwritten once can be recovered
by any petty criminal who can wear a black hoodie and is able to sit on
a chair in front of a keyboard, without equipment such as glowing green
liquids, flashing Tesla coils. Data that has been overwritten even once
is gone, to be able to read it you need at least the right Torx[tm]
screwdriver, wearing a hoodie and being able to sit on a chair is no
longer enough.

Ralf Mardorf

unread,
Oct 11, 2024, 4:40:42 AM10/11/24
to ques...@freebsd.org
On Thu, 2024-10-10 at 14:21 +0200, Matthias Apitz wrote:
> Overwriting the data will not help. The reading head(s) could be
> adjusted and read the data on the side of the old track.

There is no side of an old track on a Shingled Magnetic Recording HDD,
the tracks are overlapping. Apart from this triviality, what do you use
to adjust the position of the heads, green glowing liquid or Tesla
Colis? What is possible is by no means affordable for everyone. You have
to be very special and have very specialised opponents for such forensic
methods to come into question.


Ralf Mardorf

unread,
Oct 11, 2024, 5:31:53 AM10/11/24
to ques...@freebsd.org
On Fri, 2024-10-11 at 13:42 +1100, Dewayne Geraghty wrote:
> We bench-drilled the hard-disks before

Sorry for the flood of emails, a virus (for humans, not computers) is
keeping me glued to the keyboard.

Drill holes probably have a much more dramatic effect on hard discs than
on CDs, as the burr of a drill hole alone ensures that there is no
clearance to the heads, so that the discs can no longer rotate. Open and
deburr? ;)

I've just googled the old audio CD myth from the early days of the CD,
namely that you could drill large holes in them and still use them
without any loss of quality, and I've actually found a video in German
that is only 5 years old and still claims this IMO nonsense and
justifies it with
https://en.wikipedia.org/wiki/Cross-interleaved_Reed%E2%80%93Solomon_coding
. However, the whole thing was not demonstrated. If thick holes have
been drilled into all the places where the audio recording is stored in
which you say the PIN of your debit card, then even "interpolation"
cannot restore the spoken PIN.

I will now try to keep my fingers off the keyboard. My point should be
clear by now. There are too many myths about how data can still be
recoverd. What may potentially be possible is hardly to be expected in
reality.



rob...@rrbrussell.com

unread,
Oct 11, 2024, 11:34:53 AM10/11/24
to ques...@freebsd.org
On Thu, Oct 10, 2024, at 21:42, Dewayne Geraghty wrote:
> A good question Ronald. I worked for a provider of services for the
> statutory care of children (eg removed from parents). There are
> significant penalties for certain types of information loss. We
> bench-drilled the hard-disks before sending them (out of our chain of
> custody) to a furnace. Admittedly this is an extreme case and for the
> reasons already stated in this thread, there was no other way to ensure,
> say a name and location, were not available.
>
> And yes, all machines have full disk encryption (FDE).
>

I agree with securing the data, but drilling is not thorough enough to stop recovery and marks the drive as a high value target. You are basically betting that microscopic magnetic domain scanning will not improve faster than the areal storage density of the drives you throw away. Not a bet I want to take personally.

>
> For personal devices we overwrite the device multiple times, though I'm
> interested in what a "ATA Secure Erase" does to a healthy storage device
> and whether all sectors are touched?

ATA Secure Erase is a firmware level overwrite and reread of all physical drive sectors. I have seen the drive’s bad sector count increased by this process. It takes slightly longer than a simple dd if=/dev/zero of=drive.

I don’t suggest filling a drive entirely with zeros or ones. Those writes can be “optimized” out by the firmware. It might set a bit flag in the sector header instead of performing the full write. They don’t complete faster, they just aren’t guaranteed to actually overwrite the old data. The why has to do with a very long side tangent about how MFM encodings with error correction work.

If you want to overwrite use anything except for a string of all ones or zeros.

Ronald F. Guilmette

unread,
Oct 13, 2024, 9:40:43 AM10/13/24
to ques...@freebsd.org
In message <746da1d5-72f8-42fc...@app.fastmail.com>,
rob...@rrbrussell.com wrote:

>I agree with securing the data, but drilling is not thorough enough to
>stop recovery and marks the drive as a high value target. You are basically
>betting that microscopic magnetic domain scanning will not improve
>faster than the areal storage density of the drives you throw away. Not a
>bet I want to take personally.

OK, so this brings up a new, different, but related problem I have.

I'm basically cleaning out my closet and erasing all the drives I no
longer need in preparation for selling them on eBay. (If any of you
folks need SATA drives, some w/ high mileage, some low, of any size
including 4TB, 2TB, 1TB, 500GB, or 250GB let me know via off-list
email. I got a lot of them that need to go. Most of what I've got
is WD or HGST. I've never been a Seagate fan.)

Anyway, one of the drives I've got that I am hoping to dispense with soon
is an older model WD "Passport" external 4TB USB3 drive. Optimally, I'd
like to simply perform a S.M.A.R.T. secure erase on the thing, but there's
a catch. Various online sources say that one needs to use S.M.A.R.T.
to set a passowrd on the drive before initiating a S.M.A.R.T. secure
erase, HOWEVER it is also said in mutiple places that using S.M.A.R.T.
to set a password on a USB external drive can be deadly, as in it may
brick the device. HOWEVER it is also said in mutiple places that the
exception(s) to this general rule are at least _some_ WD Passport USB
external drives.

So, do any of you folks happen to know whether I can sefely do this on an
older model WD 4TB USB3 Passord drive? The original box, which I still have,
says:

MODEL: WDBYFT0040BBK-WESN

The thing identifies itself to S.M.A.R.T. as follows:

Model Family: Western Digital Elements / My Passport (USB, AF)
Device Model: WDC WD40NMZW-11GX6S1
Serial Number: WD-WX41D77D4DX6
LU WWN Device Id: 5 0014ee 607feedd8
Firmware Version: 01.01A01
User Capacity: 4,000,753,475,584 bytes [4.00 TB]
Sector Sizes: 512 bytes logical, 4096 bytes physical
Rotation Rate: 5400 rpm
Form Factor: 2.5 inches
Device is: In smartctl database [for details use: -P show]
ATA Version is: ACS-3 (minor revision not indicated)
SATA Version is: SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)

Is there a list someplace of which WD USB Passport drives are safe to
manipulate via S.M.A.R.T.?

I need to erase this for disposal, but obviously, I would prefer not to brick
it. Unless I can be sure that I can do that safely using S.M.A.R.T. commands
I'll have no choice but to just dd /dev/zero to the thing and hope that does
the job.


Regards,
rfg


P.S. My apologies that this topic is not really FreeBSD specific. I won't
complain if someone hits me with a wet noodle and/or chastizes me for being
off-topic. I beg all indulgence.


P.P.S. I'm actually not THAT paranoid. I kinda don't think that there are any
nation state actors waiting around for me to sell my tired old drives on eBay.
:-) That having been said, I still don't plan on buying any pagers anytime soon.

Ralf Mardorf

unread,
Oct 13, 2024, 11:05:52 AM10/13/24
to ques...@freebsd.org
On Sun, 2024-10-13 at 06:40 -0700, Ronald F. Guilmette wrote:
> Anyway, one of the drives I've got that I am hoping to dispense with
> soon is an older model WD "Passport" external 4TB USB3 drive. 
> Optimally, I'd like to simply perform [snip]

Hi,

Since I use Linux daily and FreeBSD only rarely, I do not know the
programmes that FreeBSD offers for this purpose, but I fear that there
will only be insignificant differences in this area.

Under Linux it is, apart from allegedly existing exceptions, not
possible to access an underlying, mostly SATA drive via the USB
controller.

From off-list correspondence, I know with absolute certainty that the
joys of normal operation with drives in USB enclosures are actually
always the plague, no matter which OS you use.

I use a specific enclosure from a specific company, whose controller has
firmware that causes me no problems in normal operation. I assemble
these things myself.

If you don't have an alternative connection to the USB port and the case
can't be opened, then the desired commands will most likely not get
through to the drive.

Regards,
Ralf

Translated with DeepL.com (free version)


rob...@rrbrussell.com

unread,
Oct 13, 2024, 12:43:16 PM10/13/24
to ques...@freebsd.org
hdparm is the required program on both Linux and *BSD. The procedure is set drive security password and then issue Secure Erase.

— Robert

Ralf Mardorf

unread,
Oct 13, 2024, 1:04:34 PM10/13/24
to ques...@freebsd.org
On Sun, 2024-10-13 at 11:42 -0500, rob...@rrbrussell.com wrote:
> hdparm is the required program on both Linux and *BSD.  The procedure
> is set drive security password and then issue Secure Erase.

Hi,

regarding brand new information from 2013 you shouldn't use hdparm for
this task.

"hdparm
Warning: Do not attempt to issue a Secure Erase ATA command on a device
connected through USB; see
https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase and this answer
for [*] details."
- https://wiki.archlinux.org/title/Securely_wipe_disk#hdparm

The kernel.org link is obsolete, "This page was last modified on 22 July
2013, at 16:58."

[*]
https://web.archive.org/web/20180711170859/http://www.tomshardware.co.uk/answers/id-1984547/secure-erase-external-usb-hard-drive.html
I get "The connection has timed out".

Regards,
Ralf

Kevin P. Neal

unread,
Nov 5, 2024, 11:17:48 PM11/5/24
to ques...@freebsd.org
A bit late to the game, I know, but...

On Fri, Oct 11, 2024 at 09:12:01AM +0200, Ralf Mardorf wrote:
> On Fri, 2024-10-11 at 13:42 +1100, Dewayne Geraghty wrote:
> > I worked for a provider of services for the statutory care of children
> > (eg removed from parents). [...] We bench-drilled the hard-disks
> > before sending them (out of our chain of custody) to a furnace.
>
> +1

> Criminals and secret services will think twice about whether it is worth
> subjecting the Lunchbucket family's hard drive to time-consuming and
> costly forensic treatment.

This actually hints at the correct way of thinking about this problem.

Anytime you think about security, you need to think about what you are
trying to be secure against. That is, what's the threat?



If you are trying to be safe from the garbage man then a hammer on the
circuit board is probably good enough.

If you are trying to be safe from corporate espionage then putting the
drive into a smelt and watching it melt away is my guess for the best
method.

If you are in the US and trying to be safe from the FBI then you are setting
yourself up for "obstruction of justice" charges. Don't do that. A whole lot
of don't do that, ever.

More generally, state actors are impossible to stop unless you are a state
actor or otherwise have some serious money.

With enough money it's possible to recover data from platters that have
been broken into tiny pieces. Is it worth it for someone to spend that
money? Depends on the circumstance.


Ok, but what about the case where _legally_ you are required to render the
device "unreadable" (or similar)? Well, consult a lawyer or some other
in-house expert to find out what the definition of "unreadable" actually
is in your context. If you get brought up on charges, or even just sued
by the government, it won't do to try and defend yourself with "but the
people on the FreeBSD mailing list said...."

--
Kevin P. Neal http://www.pobox.com/~kpn/

"A pig's gotta fly." - Crimson Pig

Michael Sierchio

unread,
Nov 6, 2024, 10:22:50 AM11/6/24
to Kevin P. Neal, ques...@freebsd.org
"If you are in the US and trying to be safe from the FBI then you are setting
yourself up for "obstruction of justice" charges. Don't do that. A whole lot
of don't do that, ever."

Even though there is a fine tradition of playing lawyer on the net, don't.  You're wrong.

18 U.S. Code Chapter 73 - OBSTRUCTION OF JUSTICE does not apply.

Federal spoliation of evidence is a procedural violation of the rules of evidence, and can be civil or criminal.  This only applies if the destroyer of documents, etc. is aware of current or pending action, subpoena, etc. for the artifacts as evidence in a civil or criminal issue.

If you can reasonably assume this is not the case, destroy.  Crush, then burn, as the DOD recommends.

– M

infoomatic

unread,
Nov 6, 2024, 11:02:07 AM11/6/24
to ques...@freebsd.org
On 10.10.24 20:34, rob...@rrbrussell.com wrote:
>
> The easiest way to destroy information is forgetting the encryption key but most people don’t use FDE.
>

Exactly. Highly recommend it to get rid of old defunct disks without
worries. geli(8) is great. I do use it personally on all my disks and
all my clients use it.

Frank Leonhardt

unread,
Nov 15, 2024, 7:37:24 AM11/15/24
to FreeBSD questions mailing list

On 2024-10-10 12:57, Ronald F. Guilmette wrote:

Any suggestions?  If worse comes to worse I guess I will end up writing my own tiny
little C program to just write 4KB blocks to a designated output file while ignoring
all output errors, but I don't want to reinvent the wheel if somebody else already
created something I can use in this context.

Suggestions welcome.


I spent many years dealing with forensics and disk drives, as well as writing about the technology in 1980s and 1990s. My take is this:

If you want to pretty much guarantee nothing can be recovered, drilling a hole through the platters is the easiest way. Getting data off the undamaged cylinders once you've done that requires serious money and expensive equipment. If you want to go further, take the top off and bend the platters. After that you'll need an electron microscope and a lot of time to get anything back.

Don't bother with a software erase alone. Modern drives lie to the OS. They'll almost certainly have data on blocks they'll pretend don't exist as they're presenting a "perfect disk" to the OS, but data on such blocks can be read it other ways by transferring the platters out.

This was all true until Flash-EPROM appeared in hybrid drives. If you've got one of these, drill through the flash chips on the controller (again, Flash-EPROM presents as perfect so bad hidden blocks may contain useful data). If you're not sure which chips contain flash, drill-them all.

I'm aware defense erasure standards go further than this, but I regard them as over-paranoid unless the data is of interest to a nation state with an unlimited budget and plenty of time.

As to erasing old hard disks for re-use, the same applies. Don't rely on a software erase if it matters that someone could retrieve fragments. However, if you've been encrypting sensitive data (as you should), all they'd get is impossible to decrypt fragments - no problem.

--
------
25-Sept-24 My apologies to everyone who I appear to have ignored for the last few years. A procmail script was misfiling some replies to Questions to the wrong folder.
Reply all
Reply to author
Forward
0 new messages