Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
BTW, AFAIK there's no need for the count=<whatever>. Without it, dd will keep going until it gets to the end -- which avoids the danger of not calculating it correctly.
Distribution: Debian /Jessie/Stretch/Sid, Linux Mint DE
Posts: 5,195
Rep:
Not at all. If this is a reasonable modern system, the speed should be limited by the transfer rate of the disk. The specified transfer rate of a 1 TB disk is about 3 GB/s. Let's be pessimistic and assume 1 GB/s. Then it would be done in 20 minutes or so.
Returning to the original question and given the demonstrations of how slow dd is, I wonder if there is some OEM-specific way of telling the HDD firmware to do the job, perhaps a destructive low level format?
I always smile when the 'how to clear a drive' question comes up. The various recipes for DD, the hours of work, DBAN and our local council even link to this: http://www.killdisk.com/downloadfree.htm when telling people how to clear old hard discs. All this is fine and dandy but....
http://cmrr.ucsd.edu/people/Hughes/SecureErase.shtml
...probably the quickest way to do it is with Gordon Hughes 'Secure Erase' which is built in to most post 2001 HDD drives. It takes about 2 1/2 hours to per 500gb - fraction of the time of other methods.
To run it requires a bootable floppy/cd/usb as it's a dos.exe file that talks to the ATA controller on the motherboard and sends the drive the correct ATA commands to securely erase it.
As drives get bigger the time taken to use other tools rises exponentially so I hope that helps someone out.
On a side note I was recently read that wiping drives with patterns more than 1 time is really a waste of time. A single wipe of any pattern will render any data beyond recovery for your average Joe. Even a forensics lab using an atomic force microscope to view the platters would take three months to recover a 36k jpeg file that has been single wiped with any pattern.
Adding to that, Scott gives some great 'talks' on drives. Normally I'm not a fan of Youtube videos but this series is rather good. It's well shot, to the point and without the usually waffle:
On a side note I was recently read that wiping drives with patterns more than 1 time is really a waste of time. A single wipe of any pattern will render any data beyond recovery for your average Joe. Even a forensics lab using an atomic force microscope to view the platters would take three months to recover a 36k jpeg file that has been single wiped with any pattern.
I didn't know they could recover it at all. Any links ? Cuz I would like to see some undeniable proof for this urban myth, that if you wipe once with zeros, the gubmint using uber technology, can still reliably recover something.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.