Jump to content
xisto Community
Sign in to follow this  
FirefoxRocks

Wiping Out A Hard Drive Most secure method?

Recommended Posts

Like the old LaserJet Printers... HP i believe. I remember them from back in my high school days. Also some Apple Laserwriters (the laser printers) as support adding SIMM(s). If you've ever asked someone who managed a computer lab with network laser printers or someone who ran a print shop back in the day, they'll tell you the same.

You might have to update the firmware on the NIC enabled printers for the printer to recognize the new amount of ram. Then upload the fonts you most commonly use. Edited by levimage (see edit history)

Share this post


Link to post
Share on other sites

(on topic of OP)When I wipe hard drives, I use a live linux cd/floppy (a linux floppie should work as most of them will have dd and the device tree) and do dd if=/dev/urandom of=/dev/<hard drive> then collow it with dd if=/dev/zero of=/dev/<hard drive>, I do that a couple of times esp if I am setting up a encrypted partition, that way if they try to look at the drive down some layers all they see is garbage or null bytes.

Share this post


Link to post
Share on other sites

(on topic of OP)When I wipe hard drives, I use a live linux cd/floppy (a linux floppie should work as most of them will have dd and the device tree) and do dd if=/dev/urandom of=/dev/<hard drive> then collow it with dd if=/dev/zero of=/dev/<hard drive>, I do that a couple of times esp if I am setting up a encrypted partition, that way if they try to look at the drive down some layers all they see is garbage or null bytes.

I'm sorry but that is much too confusing. Perhaps you could explain that more? I'm not trying to encrypt a partition here, and is the method you mentioned really secure?

Share this post


Link to post
Share on other sites

Yes it is secure as what happenes is this

First run 000000000000
2nd run 4gv3h904hgw4
4th run 000000000000
3rd run 32r98hg43g[34


and so forth, the reason i brought up encryption is that is one of the main causes people zero out their hard drive.

but beware this method takes a while to run then just running it once, which the NSA has said 32 times is best as most NON government software can't read that far down and they actually have to take the drive to the labs and take them apart to read that far :mellow:.

but the commands again (32times in 1 shot if i can recall my bash scripting)
NOTE: DO NOT RUN THIS IT WILL WIPE OUT YOUR HARD DRIVE BEYOND THE POINT OF RECOVERY

#!/bin/bash$DRIVE = /dev/sda # change this to your hard drive you wanna erase$COUNT = 0while [ $COUNT -lt 16 ] : do	dd if=/dev/zero of=$DRIVE && dd if=/dev/urandom of=$DRIVE	COUNT = $[$COUNT+1]donedd count=1 bs=1024 if=/dev/zero of=$DRIVE # erase the first 1megabyte to clear the MBR and partition table
EDIT:
save as blah.sh and and chmod +x it so you can run it, and run it as root and goto sleep and when you wake up it will be cleared.
(i had a guy double check the script for me) it will erase your hard drive 32 times and clear out the MDR and partations of any garbage the last urandom did
Edited by Gr33nN1nj4 (see edit history)

Share this post


Link to post
Share on other sites

4-18-2009

Anyone who really wants to know how secure the methods are, should take the time to read Peter Gutmann's views---imo, he's still the leading authority, and by reading how it all REALLY works, instead of assuming that every program will always sufficiently do the job at hand, you have a hands on type feeling of what is going on in our hard drives---In fact some drives have programming built into them that may prevent 'erase' programs from being fully implemented and applied correctly...

What I walk away with out of his views are, today's modern drives have a much higher density than they used to, so recoverability (especially after re-writes) becomes increasingly difficult even for the most advanced of forensic tools---older drives are incapable themselves of being able to read or write from an EXACT location, so the space in between tracks was much wider (that's why older drives the same physical size couldn't hold as much) so this means that it was possible to recover data after (some reported to be over 100) rewrites...

What it boils down to is magnetics, and magnetic ranges being able easy to predict, and through using sort of 'reverse engineering' calculations it be possible to piece data back together---this is of course easier with old drives, and very tough with newer drives as there is virtually no track space in between...Writing your disk with simply 1's, 0's, or even a combination of, isn't going to create the same magnetic resonance as genuine data will, so the method by which the drive itself stores your information (each drive may use a different encoding scheme) has to be targeted and 'typical' encoding streams used...

I assume this information from the Gutmann source:
https://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html

-reply by Secure For Real

 

Share this post


Link to post
Share on other sites

minir changes to script

Wiping Out A Hard Drive

There was several small mistakes with the script (there should not be spaces near equal sign and there should not be dollar signs when setting the varibles). Here is the correct script:

{{{

#!/bin/bash

DRIVE="/dev/sda" 

# change this to your hard drive you wanna erase

COUNT=0

While [ $COUNT -lt 16 ] ; 

do dd if=/dev/zero of=$DRIVE && dd if=/dev/urandom of=$DRIVE COUNT=$[$COUNT+1] 

echo $COUNT

Done

Dd count=1 bs=1024 if=/dev/zero of=$DRIVE # erase the first 1megabyte

}}}

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.