Wiping Old Laptop

aardvaak

In my opinion the only guaranteed way no future user will access date is to remove and destroy hard drive - that can be guaranteed to work and if you are recycling computer presumable you are donating it the new owner won't mind getting another hard drive as they have got the computer for free.

suki1964

aardvaak wrote: »

In my opinion the only guaranteed way no future user will access date is to remove and destroy hard drive - that can be guaranteed to work and if you are recycling computer presumable you are donating it the new owner won't mind getting another hard drive as they have got the computer for free.

But then how do you destroy the hard drive?

I mean I've found USB keys before and found some pretty interesting info, who's to say someone wont lift my hard drive from recycling and take it home for a nosy?

securityguy

suki1964 wrote: »

But then how do you destroy the hard drive?

If you're concerned with the kids next door, a hammer is fine.

If you're concerned about someone with slightly more equipment and motivation, drill a couple of holes.

If you're concerned about someone very serious indeed, take the lid off (they're quite interesting to look at anyway) and destroy the platters with a blowtorch. They're made out of very thin metal, and if you've got a decent blowtorch and a couple of bricks, you can actually melt the platters into a liquid (I know someone who cast a nice pair of earrings).

And of course, nothing stops you from DBANing the disk before you get physical.

NIST0800-88 I think recommends reducing the platters to 5mm chips. This looks like fun and you could, if keen, buy your own.

aardvaak

suki1964 wrote: »

But then how do you destroy the hard drive?

I mean I've found USB keys before and found some pretty interesting info, who's to say someone wont lift my hard drive from recycling and take it home for a nosy?

Smash it to little pieces with a hammer then distribute the bits in lots of different places

closed

Risking shards of glass platter in someones face isn't a good idea.

This question has been asked and answered so many time on this forum, and every time it deteriorates into some paranoid smash it burn it thread, totally wasteful. The question was how to wipe and recycle.

tronator

prowla wrote: »

beware that DBAN states up-front:

"DBAN users should be aware of some product limitations, including:

• No guarantee that data is removed"

An approach I have previously used is to boot from alternative media (eg. a Linux "Live" CD), then delete all partitions and reformat the disk, and then copy movies & songs onto it to fill it up.

Once you're booted a Linux Live CD a simple "dd if=/dev/zero of=/dev/sdX" would do a much better job. If you have more time to spare and if you're paranoid , then use /dev/urandom instead of /dev/zero.

prowla

tronator wrote: »

Once you're booted a Linux Live CD a simple "dd if=/dev/zero of=/dev/sdX" would do a much better job. If you have more time to spare and if you're paranoid , then use /dev/urandom instead of /dev/zero.

Well, since you mention paranoia, if there is any means of reading residual data off a disk (you do the search), then overwriting it with uniform content (ie. zeros) would give the overall best chance of being able to recover the previous content...

As far as "better goes", reading from /dev/null or /dev/urandom, would likely be slow as it's bytewise; I suppose you could add the obs=4096 option to chunk it into blocks.

S0litaire

For data wiping you should do more than one pass of ANY software using random (or as random as possible) data.

I use dd a lot. I use /dev/zero for quick "free space" wipes
And if the drive is going to be sold on, I alternate between /dev/zero and /dev/urandom a few times.

Although at times I write a hex or binary string instead:
Hex values: "57 68 79 5f 55 5f 52 65 61 64 69 6e 67 5f 74 68 69 73 3f"
Translation "Why_U_Reading_this?"

And at times I've gotten a simple text document (say any novel or another unimportant .txt file) and written that instead of random data.

I know of at least one company (in the USA!) that are ordered to overwrite the drive with legal jargon "disclaimers" in binary or hex from their legal department.

Something to do with it's not 100% that all the data is gone so if their is a legal disclaimer they company can't be held responsible if data is found on the drive (don't ask me! it's lawyers doing lawyery stuff to earn their pay!)

Working in IT can get boring at times!! to need a geeky way to blow off steam ^_^ (well when you cant take hammers to hard drives that is...) Oh make sure if you DO take a hammer to a drive it's a metal platter drive NOT a silica glass platter! those "EXPLODE" when they shatter in to 1mm - 2mm scalpel sharp shards, that easily go through skin/ and thin clothing!!

I've been on the receiving end of a dropped drive with silica platters! The guy who owned it decided to look inside and didn't replace the cover, he dropped it when he handed it to me! spread shards 5 to 6 meters away when it hit carpeted floor. Lucky I wear glasses and none got in my eyes, though I did feel the shards hit my face! spent the rest of day finding shards all over my clothing and sticking into my skin!

securityguy

prowla wrote: »

As far as "better goes", reading from /dev/null or /dev/urandom, would likely be slow as it's bytewise; I suppose you could add the obs=4096 option to chunk it into blocks.

The default blocksize for dd is 512 bytes, not 1 byte. Any version of dd which doesn't have this default isn't Posix compliant. The Linux, OSX and Solaris versions definitely have a default of 512 bytes (I checked with "dd if=/dev/zero count=1 | wc -c") - interestingly, to judge from the format of the summary line, all three are different versions - and going back to the 1970s, the 7th Edition documentation (page 67) says the default is 512 bytes, so it's probably been one "old" block since forever.

prowla

securityguy wrote: »

The default blocksize for dd is 512 bytes, not 1 byte. Any version of dd which doesn't have this default isn't Posix compliant. The Linux, OSX and Solaris versions definitely have a default of 512 bytes (I checked with "dd if=/dev/zero count=1 | wc -c") - interestingly, to judge from the format of the summary line, all three are different versions - and going back to the 1970s, the 7th Edition documentation (page 67) says the default is 512 bytes, so it's probably been one "old" block since forever.

You're right; I started off meaning reading from /dev/urandom would be byte-wise, and then flipped mid-sentence (which was actually going and getting a coffee in real-time!) into specifying the dd block size. But actually reading the random device will be a lot quicker than anything else (eg. copying another file), so I confused myself!

I generally try and set the block size as big as I can though.