Securely Erasing a Hard Drive


This post examines methods of insuring that data on a hard disk drive (HDD) does not fall into the wrong hands. The examination begins with a glance at methods of HDD physical destruction. For drives that are to be reused, the standard alternative is to wipe the HDD with programs or commands designed for that purpose.

Disk wiping tools typically attempt to overwrite each sector of a drive. This is relatively feasible in HDDs and, as discussed in another post, relatively infeasible in SSDs. HDD overwriting has been plagued by an unsupported belief that each sector needs to be overwritten multiple times. Ironically, it appears that the so-called DoD (Department of Defense) protocol for multiple overwrites is no longer accepted as a means of securely eliminating sensitive data within the DoD itself.

The final sections of this post (titled Discussion and Recommendations) summarize what I learned, in the process of writing this post, and what I would recommend on the basis of that learning. In simplest terms, the recommendations are this: use the Secure Erase option within Parted Magic (which may require internal mounting), and follow it with a pseudorandom pass in (Heidi) Eraser. Those steps appear sufficient to defeat data recovery by any ordinary user and by most (possibly all) professionals, at least within the next several years. For complete security, of course, physical destruction will help. The following sections explore such options in detail.

With such recommendations, it seems important to emphasize one truth: data travels. There are many ways to leak data, to possess data worthy of a prison sentence, to be caught trying to hide data, and to be investigated for felonious possession or hiding of data (with the possibility of conviction on oblique charges). Even the most innocent of users can be robbed or blackmailed with data recovered via wireless interception, keylogging, or other security breaches.

In short, it could be unwise if not absolutely counterproductive to obsess on hard drive erasure to the neglect of many other potential security threats. Probably the best advice would be, to the extent possible, not to be involved with questionable data, not to possess such data, not to entrust such data to a computer, and not to let others access that computer or its means of data storage and communication.

Physical Destruction

As I approached the question of hard drive secure erasure, I recognized that physical destruction of the HDD was one option. People had attempted various approaches (e.g., torch, bullet, hammer, acid, thermite). (Suggestion: don’t try to pour acid down the drain when you’re done with it.) It deserved mention that data could be recovered from drives that were physically nonworking (e.g., submerged) and to some extent even from those that had been physically damaged (e.g., burned). A key point here was that a single file might occupy a very small portion (i.e., one or two millimeters) of a hard disk, and could be recovered from that portion even if the platter was shredded.

Magnetic erasure seemed to be a dominant approach to erase HDDs securely. There were two general magnetic methods. The more obviously physical method, referred to as degaussing or bulk erasing, would tend to be physically destructive, for two reasons: powerful magnetism covering the entire drive would reportedly erase the manufacturer’s servo tracks, rendering the drive unusable; and the use of magnets powerful enough to erase the contents of multiple stacked hard drive platters would pose a risk of bending critical drive components. It would be possible but risky to open the drive and degauss its platters individually, even if that did not erase the servo tracks: doing so would void drive warranties and introduce a substantial risk of a subsequent drive crash due to undetected dust particles.

Overwriting Data

The less obviously physical form of magnetic erasure involved the use of programs or techniques that would overwrite magnetized, data-carrying spaces on an HDD. Such drive overwriting programs or techniques — often metaphorically described as “wiping” or “shredding” — would apparently be the only option for those who did not have the option of physically damaging the HDD. That would be the case for users who wanted to sell or reuse the HDD. Erasing a drive before reuse would make sense if, for example, it had previously contained sensitive data that should be protected from later recovery by a thief or snoop.

These overwriting methods could also provide another level of defense for those who planned to physically damage their hard drives. Of course, erasure by program or command would require an operational drive capable of running that program or responding to that command, so software-based wiping would have to precede any physical damage. Such wiping would also not remove data from bad sectors of a drive. Presumably CHKDSK would accurately indicate whether the HDD in question had bad sectors.

It was important to recognize that deleting a file or folder was not the same as erasing or overwriting the contents of that file or folder. In an operating system like Windows 7, deleting a file or folder was like being a librarian who encountered a book without a cover. The operating system’s ordinary way of identifying and filing the contents of that information would be removed, but the contents themselves would be unchanged. That is, deleting a file did not typically mean deleting its contents. The focus here is not on mere file deletion or drive reformatting; it is on completely removing the data from the drive.

The problem of data remanence (i.e., remaining) would not necessarily be limited to the contents of a hard drive. Programs and operating systems might have a tendency to create copies of files (or to save their contents) in temporary files and pagefiles on other drives and in RAM. While RAM deprived of a source of power (i.e., not kept in a Sleep state) would typically retain data for no more than a few minutes at room temperature, its data remanence could be extended to hours with the use of cooling (from e.g., a can of compressed air sprayed upside-down) and could be exploited with a cold-boot attack. The recovered contents of such RAM could include passwords and drive encryption keys. Generally, data security involved much more than just wiping drives.

Repeated Wipes

Within this post’s focus on HDD secure erasure, there was a concern that — as with an attempt to erase a pencil mark from a sheet of paper — one pass might not be enough. That is, HDD erasure programs might erase or overwrite the same HDD sector multiple times. Each wiping pass was believed to remove or confuse a bit more of the magnetism lingering from an original data write, making it harder to figure out what that write might have said. So there were various HDD erasure protocols calling for one, or three, or 35, or some other number of erasure passes; and on each pass, the data being written might consist of fixed values (e.g., zero or one) or random values or both, as part of a sequence of rewrites.

There was debate on the need for multiple wiping passes. Some stated that hard drives in previous decades had been relatively sloppy, but that magnetic overspray from the recording head would tend to be very limited on a contemporary drive. Thus, an informative Wikipedia article cited several sources for the contentions that one wiping pass was adequate for all but the most extreme scenarios, especially on modern HDDs, and that it could be counterproductive to fail to take that one-pass wiping step because of fear that it might not provide absolute protection against all contingencies. Numerous articles and posts repeated that view.

In particular, the 35-pass approach linked with the name of Peter Gutmann appeared to reflect a misunderstanding of his 1996 paper. In an epilogue appended to that paper, he said this:

In the time since this paper was published, some people have treated the 35-pass overwrite technique described in it more as a kind of voodoo incantation to banish evil spirits than the result of a technical analysis of drive encoding techniques. . . . [P]erforming the full 35-pass overwrite is pointless for any drive since it targets a blend of scenarios involving all types of (normally-used) encoding technology . . . . For any modern PRML/EPRML drive, a few passes of random scrubbing is the best you can do. . . . [W]ith modern high-density drives, even if you’ve got 10KB of sensitive data on a drive and can’t erase it with 100% certainty, the chances of an adversary being able to find the erased traces of that 10KB in 200GB of other erased traces are close to zero.

There was speculation that magnetic force microscopy (MFM) would facilitate recovery of overwritten data from an HDD platter. On that question, Craig Wright (2009) conducted research yielding this conclusion:

[C]orrectly wiped data cannot reasonably be retrieved even if it is of a small size or found only over small parts of the hard drive. Not even with the use of a MFM or other known methods. The belief that a tool can be developed to retrieve gigabytes or terabytes of information from a wiped drive is in error.

While that 2009 paper was not absolutely lucid on the point, Wright et al. (2008, p. 244) contended that a single wiping pass was entirely sufficient to render a modern drive’s data unrecoverable. That appeared consistent with the claims that there was no evidence that overwritten data can be recovered and that contemporary research indicated that it could not. I noted, moreover, the occasional post in which someone would simply request the name of, or a link to, a program that could recover once-wiped data — and instead of providing such information, replies would warn vaguely of data recovery possibilities. Wright and others (above) found such warnings unpersuasive.

The risk of data loss through post-wiping recovery seemed to pale against the likelihood that law enforcement and various sorts of spies and thieves would continue to use more direct and less easily discovered means to obtain information from computers. It appeared to be misguided to devote inordinate attention to drive wiping while neglecting such other possibilities.

Such remarks raised the questions of who, exactly, might be seeking to recover data from an HDD, and what resources they might bring to the project. There appeared to be multiple levels of data recovery capability, ranging from an average person using a data recovery program (e.g., Recuva) to a commercial data recovery service (e.g., Kroll Ontrack) to law enforcement (e.g., U.S. Federal Bureau of Investigation (FBI)). The general principle seemed to be that it would take increasing amounts of time and money to acquire the tools and expertise to recover data in increasingly difficult situations (e.g., a physically shredded hard drive), and that nobody would have enough time and money for everything they would like to do. That is, it appeared advisable to calibrate one’s data security efforts to the likely level of intrusion or investigation, bearing in mind that a truly motivated party might enjoy significantly greater computing power due to the march of technology, five or ten years down the line.

It appeared, in short, that someone using a drive wiping program like Darik’s Boot and Nuke (DBAN) would probably meet the data security assignment adequately by using one, or at any rate not more than three, passes to wipe a drive. All other things being equal, it seemed better to fill the drive with random data rather than a more predictable pattern of zeroes and ones, if one’s data wiping tool permitted that.

Given these impressions, I was not sure why, judging from the DBAN interface, the U.S. Department of Defense (DoD) would require seven wiping passes. Upon further investigation, the situation seemed to be as follows: the National Industrial Security Program Operating Manual (NISPOM, 2006, p. 8-3-1, PDF p. 75) simply required that media would be sanitized to “provide an acceptable level of protection for the data that was on the media before clearing.” The Manual for the Certification and Accreditation of Classified Systems Under the NISPOM (Defense Security Service, 2013), interpreting that original requirement, made the following statements:

Wiping (overwriting) can be used for the cleanup of spills, but may not be used for sanitization of disks . . . [p. 44].

Classified Spills (also known as contaminations or classified message incidents) occur when classified data is introduced to an unclassified computer system or to a system accredited at a lower classification than the data [p. 43].

Hard drives involved in a classified spill should be wiped using an NSA or NIAP-approved product, however if one is unavailable any commercially available wiping utility that meets the following requirements may be used:

  • If wiping whole disks, it must be able to wipe the entire drive (e.g., partition tables, user data, operating systems and boot records)
  • If wiping whole disks, it must be able to wipe Device Configuration Overlay (DCO) hidden sectors if ATA-6 disks are being used
  • If wiping whole disks, it must be able to wipe a Host Protected Area (HPA)
  • Must be able to sanitize by overwriting with a pattern, and then its complement, and finally with another unclassified pattern (e.g., “00110101” followed by “11001010” and then followed by “10010111” [considered three cycles]). Sanitization is not complete until three cycles are successfully completed [p. 45; see also pp. 116-117]

This explained three passes, not seven. There did not seem to be an official source for the seven-pass option. Sedory (2008) suspected that it originated in a bizarre Symantec document.

There was also a seeming inconsistency, which I did not investigate in detail, within the foregoing quotes: they seemed to say that wiping would, but also would not, be sufficient for sanitization for purposes of the Defense Department. There was also the ironic impression that, regardless of the number of passes, DoD itself no longer accepted the so-called DoD wiping method (or any other software solution) for situations requiring certainty of data destruction. Of course, DoD was not on a tight budget. They could afford to grind up or melt perfectly good hard drives.

The preceding quote also referred to DCO and HPA. According to Berkman (2013), these two areas on the drive were in addition to the drive’s service areas (sometimes called reserved, system, negative, firmware, or microcode areas or sectors). These areas (i.e., DCO, HPA, and service areas) had in common the ability to store information.

These areas could store data that a program like DBAN would reportedly fail to erase. It appeared that data would not be written to these areas during normal usage; indeed, in some cases it appeared that neither the BIOS nor the operating system could even access those areas. Aside from the occasional vendor seeking to add a legitimate tool or capability to a drive, it seemed that the only people who would deliberately write to those areas would be malware authors and people who were trying to conceal data from forensic investigators. In other words, someone who bought a disk, used it, and then sought to sell or otherwise dispose of it would apparently not have to worry about this. It seemed that DoD was worried about it primarily because of the possibility that an employee operating in violation of the rules (e.g., a spy) would have deliberately concealed data in such areas. I did not investigate the question of how one might write data to such areas, beyond noting that Berkman’s paper seemed to outline one such technique. It appeared that the Linux hdparm command (below) could be used to erase at least some such areas.

Wipe Commands

As noted in my post on wiping SSDs, the firmware in HDDs manufactured since 2001 was supposed to include something known as the ATA Secure Erase command. This command would facilitate rapid, secure, and complete erasure of drives, including HPA and DCO areas. One could invoke that firmware command by issuing an hdparm command in Linux. Acccording to an entry in a Superuser discussion, Linux offered dd as a very secure wipe command-line alternative to hdparm. (See also shred.)

There was certainly the option of booting the computer with a Linux live CD or USB drive (e.g., Ubuntu) and issuing an appropriate hdparm command. (I did not explore the question of whether a Windows user could run these commands effectively within an installation of Linux in Windows.) It appeared, however, that there were many hdparm parameters, that some required technical knowledge of HDD architecture, and that an incorrect hdparm command could ruin the drive, perhaps without achieving erasure.

For such reasons, it seemed some would prefer a graphical user interface (GUI) — a program, that is, that would figure out the needed parameters and send the appropriate hdparm command, achieving an ATA Secure Erase. Again, as discussed in that other post, tools to this end included HDDerase and the Erase Disk utility in Parted Magic ($4.99). HDDerase was last updated in 2008. Drives had grown in size and complexity since then. Hence, it appeared that HDDerase would not be the ideal tool.

As described in that other post, not all SSD manufacturers reliably implemented the Secure Erase command. I was not certain whether HDD manufacturers had done a better job. The concern here was that, even if one did issue the correct hdparm command (directly or via Parted Magic), there was the possibility that it would not work as intended. As my testing would indicate, there also appeared to be hardware setups in which Parted Magic (and possibly a direct hdparm command) would not offer the ATA Secure Erase option.

Even when using hdparm, then, it appeared that in some cases a concerned user might follow up with an alternate wiping method. That suggestion appeared consistent with the general observation that, in life, sometimes things did not work out as planned. The problem in this context could be due to the programmer, the manufacturer, the user, or some other player. In other words, rather than depend on a single wiping process repeated multiple times in a program like DBAN, it could make sense to combine two (or, for overkill, three) wiping alternatives, with or without DBAN.

Like Linux, Windows offered certain command-line tools for purposes of wiping drives. One was cipher. Cipher was intended primarily for other purposes, but it had an option for overwriting each free sector, reportedly with three overwriting passes. Here’s what I got when I ran cipher on drive X:

I:\Current>cipher /w:X
To remove as much data as possible, please close all other applications while
running CIPHER /W.
Writing 0x00

That is, it did not indicate how long it might take to finish the job. I was able to kill it with Ctrl-C or by closing the DOS box in which it was running. As with many other Windows commands, it went without saying that I was running this at an elevated command prompt.

SDelete was a Windows alternative to cipher. It, too, would overwrite free space; the difference was that its description suggested that considerable thought had gone into that particular purpose. It also offered options not available in cipher:

I:\Current>sdelete /?
SDelete - Secure Delete v1.61
Copyright (C) 1999-2012 Mark Russinovich
Sysinternals -

usage: sdelete [-p passes] [-s] [-q] <file or directory> ...
       sdelete [-p passes] [-z|-c] [drive letter] ...
 -a Remove Read-Only attribute
 -c Clean free space
 -p passes Specifies number of overwrite passes (default is 1)
 -q Don't print errors (Quiet)
 -s or -r Recurse subdirectories
 -z Zero free space (good for virtual disk optimization)

Since multiple passes seemed unnecessary, and since I didn’t care to target any particular file or directory, I was able to use this command to wipe drive X:

sdelete -c X:

To get it to run without adding anything to my system path, I put a copy of SDelete.exe in C:\Windows. This command, too, was killable with Ctrl-C.

In addition to their uses for wiping free space on a drive with no files present, SDelete or cipher could be set to run regularly, on a drive containing files in active use, by using a batch file triggered by Task Scheduler. The value of such a batch file (which might also incorporate a program or command to clean slack space, another concept not applicable to empty drives) would be to reduce somewhat the amount of information available to a data thief or other intruder. I guessed that wiping free space on an encrypted drive would help only to reduce the amount of information available to someone who had managed to obtain or bypass the encryption password.

Another Windows command-line wiping option involved the use of the diskpart command. Unlike cipher and SDelete, diskpart would open its own little command world: once the user typed diskpart at a Windows 7 command prompt, s/he would have to enter commands that would make sense in the diskpart environment. In that environment, a Windows 7 command like dir or cipher would not work. The specific diskpart command needed for present purposes was “clean all,” which one Microsoft page described thus: “Specifies that each and every sector on the disk is zeroed, which completely deletes all data contained on the disk.” In other words, it was a one-pass wiper. The sequence of diskpart commands needed for this purpose was reportedly as follows: diskpart > list disk > select disk N > clean all > exit. Then fire up Disk Management (diskmgmt.msc) and create the desired kind of new partition on the newly wiped drive.

Disk Management would also provide hopefully reliable guidance to help select the correct disk number within diskpart. But it was probably best not to have extraneous devices connected to the computer; there was always the risk of making a mistake and zeroing the wrong drive by accident.

GUI Wiping Utilities

As noted above, Parted Magic offered a GUI implementing hdparm. But there were many other wiping utilities, with considerable debate (on e.g., Reddit) of their various merits. I did not attempt to exhaust such discussions. Briefly, it appeared that DBAN was most widely mentioned and recommended. Eraser (a/k/a Heidi Eraser) was another that I had often heard of, over the years: for instance, Gizmo preferred Eraser and CCleaner over DBAN, although for reasons I found only partly persuasive. I also encountered several references to KillDisk. Although I encountered one or two claims that Eraser implemented the ATA Secure Erase command, I found no evidence of that on the Eraser website. At this writing, Parted Magic seemed especially capable and widely recommended.

In addition to programs (or program features) dedicated to the wiping of drives, there were other possibilities within the realm of canned software. One possibility was to use the HDD manufacturer’s utility to zero-fill the drive. Gizmodo offered links to several different manufacturers’ utilities for this purpose. I briefly explored these links for three different manufacturers:

  • For a Samsung drive, Gizmodo’s link was no longer relevant — apparently Samsung had rejiggered its website — so instead I had to use their Download Finder. It pointed me toward Seagate SeaTools for Windows 1.2.
  • I installed and ran that Seagate utility. It did not seem to offer a zero-fill option: just drive tests and miscellaneous information. But then I found what I was looking for in Basic Tests >  Advanced Tests > USB Erase Tracks. It offered Basic and Full Disc Erase options. I chose the latter, making sure that I had specified the Samsung drive. Seagate also offered SeaTools for DOS, with a Full Erase option that it considered similar to the idea of low-level formatting.
  • For an old Hitachi drive, I downloaded and installed the HGST WinDFT Windows Drive Fitness Test utility. The bad news was, it did not have an option to create an ISO or a portable version, and in any event was not suited for my old drive. The good news was, I had an older version of the utility (still available for download).

There was still another possible approach. Instead of wiping a drive with a manufacturer’s utility or a third-party program like Parted Magic or DBAN, there was the possibility of encrypting the drive. Several posts in this blog discuss the use of TrueCrypt (or, as a possible alternative, DiskCryptor) to make the contents of a drive available only to the person(s) who hold its password or key. Encryption would have drawbacks of imposing additional hassle and the risks of losing one’s data upon losing the password. It was also possible that future advances in computing power would make it easy to break passwords that were presently considered unbreakable. Along with the security of having one’s data encrypted, encryption of a drive in daily use could provide a line of protection against the risks that someone might forget to wipe a drive before disposing of it, or might not be able to wipe a drive before it was stolen.

It seemed that encryption, used in tandem with a wiping method, might provide an appropriate data sanitation solution in some situations. (Note that, at least in TrueCrypt, encryption would proceed faster if the drive had also been reformatted before encryption: TrueCrypt took much longer to encrypt existing data than to encrypt an empty drive. Note also that TrueCrypt’s quick encryption option would fail to encrypt every sector of the drive, thus defeating the purpose.)

Yet another approach was simply to reformat the drive in Windows. I thought I knew the proper response to that suggestion: I had always understood that formatting would not erase data. As discussed below, I was about to learn something new.

Time Required

I had a 1TB 7200 RPM Hitachi HDD, plugged into an external drive dock and connected to a relatively slow laptop via USB 2.0 cable. I wondered how long these various methods would take to complete their attempts at wiping that drive. It was infeasible to test all possible methods. Accordingly, in this section I sought to take at least a preliminary look at several frequently used methods.

I had just finished a wipe using the Erase Disk utility in Parted Magic 2014_02_26. I had not been able to use Internal Secure Erase, the last option on the Erase Disk list. Not surprisingly, attempts to use that Internal Secure Erase option on this external Hitachi drive had resulted in an error message. So instead of using the Secure Erase option, I wiped the drive using the first option on the list: Disk (External), which was described as writing zeroes to the entire drive using dd. That wipe had taken 10 hours and 23 minutes (10:23). Then I tried the Internal Secure Erase option again, and this time it claimed to have worked, returning a “Successfully Erased” message within just a few seconds. I found that suspiciously fast, given its own estimate that it was going to require 224 minutes (3:44) to erase this drive with that method.

I switched to DBAN 2.2.8. I started several of its wipes, one at a time, and let each one run for five minutes or so, to get a rough idea of how long they would take. At that point, the estimates had not settled down; they were invariably still rising. Experience suggested that the actual elapsed times would be longer — perhaps substantially longer — than the early estimates. In each case I left all other DBAN options unchanged, altering only the wipe method.

On that basis, DBAN’s DoD Short method (3 passes) was going to take an estimated 37:35. DBAN’s regular DoD (5220.22-M) method (7 passes) was going to take an estimated 69:02 (i.e., nearly three days). I didn’t try the Gutmann Wipe, because I understood now that it was both dated and a misconstrual, but I did try the PRNG (pseudorandom number generator) Stream option, which DBAN described as “probably the best method to use on modern hard disk drives because encoding schemes vary.” That one was going to take an estimated 22:51.


In addition to those several methods, DBAN also offered choices of Entropy and PRNG. The basic concern appeared to be that these options would address the choice of data to be written to the drive (e.g., how the written data would be randomly generated), and the manner in which it was written. I knew from prior experimentation that the time required for a given wipe method would vary according to choices in some of these regards. Again, though, a search led to the impression that such concerns were for the future — that, with existing technology, data on wiped sectors was irretrievable regardless of such settings.

I had run both the Parted Magic and DBAN options from my XBoot multiboot DVD. I wrapped up that part of the investigation by running the Hitachi drive utility from that XBoot DVD. It was an old HDD and an old utility; I was primarily interested in verifying that there was a zero-fill option. Unfortunately, it did not recognize the external drive. I suspected that I might have had better luck with an external drive dock or enclosure connected to the computer via eSATA rather than USB cable.

Now it was time to run some alternatives from within Windows. An advantage of a Windows-based wiping approach was that one could use the machine for other tasks during those hours or days of wiping. Parted Magic did have a few utilities that one could run while wiping a disk, and of course Linux and Windows would offer a full suite of multitasking options, whereas DBAN would impose strict monotasking: I wouldn’t be able to use the machine for anything else, during those hours or days while it was wiping the drive.

In Windows, I started with TrueCrypt 7.1a. Encrypting a standard non-system 1TB drive with TrueCrypt’s “create encrypted volume and format it” option, and otherwise using default settings, was projected to take 10 hours. Without its Wipe setting, and with otherwise similar settings, DiskCryptor 1.1 looked likely to need about 24 hours.

I killed DiskCryptor and switched to Windows command line options. Entering Diskpart’s “clean all” command immediately converted the drive from a formatted partition to an unallocated space in Disk Management. But otherwise, the “clean all” option did not provide any time estimates or other progress information. I knew it was running only because I could hear the noise from, and could see the light flashing on, the external drive dock housing the 1TB Hitachi drive. So I just let it run until it was done. Once I entered the “clean all” command, the cursor just blinked for the next 11 hours.

I didn’t catch the exact moment when it finished the task and reported, “DiskPart succeeded in cleaning the disk,” and it didn’t provide any information on what it had achieved. But in light of the Parted Magic experience (above) it did appear that a one-pass wipe of this 1TB HDD, using any of several different methods (e.g., SDelete, in its default mode), could be expected to take about 10 to 11 hours.

Results of Different Wiping Methods

While writing the foregoing paragraphs, I did not have an opportunity to conduct good tests of the several wiping methods mentioned above. Later, however, I found myself with another drive — a 2TB Samsung — that I wanted to wipe. This time around, I decided to try several iterations, each time putting some data on the drive, wiping it with a single method, and then trying to see if I could recover any of the data.

Windows Quick Format

The data I used consisted of 41 plain text files of various sizes, each containing one or more iterations of Yogi Berra’s famous adage, “You can observe a lot by just watching.” Another post describes the technique by which I created those files. These 41 text files ranged in size from 39 bytes to about 6GB. They totaled about 15GB. If I had wanted to create enough dummy files to fill the drive with tightly packed data, I might have tried compressing a bunch of these text files using a ZIP or RAR tool, and then using multiple different-sized copies of those compressed files.

As a starting point, I copied those 41 test files onto the drive, right-clicked on the drive in the right pane in the Windows 7 Disk Management tool (diskmgmt.msc), and chose Delete Volume > right-click > New Simple Volume > default settings. Then I tried to see if I could recover those files. In this and subsequent recovery efforts, I would be using Recuva 1.51 and the trial version of Kroll OnTrack EasyRecovery Home.

After that simple step of deleting the volume and quick-formatting the drive, Recuva was not able to recover the files until I turned on its Deep Scan mode. (I turned off its option to show files found in hidden system directories; these seemed to have been added by the formatting process.) Recuva’s Deep Scan looked like it was going to run for quite a while; however, within the first few minutes, it had already found many thousands of files. Apparently it had detected, not only the 41 test files I had just put onto the drive, but also whatever had been on the drive before my first reformat. Canceling at that point did produce a long list of apparently recoverable files.

Windows Full Format

I tried again. This time, I took the same steps — copy my Yogi Berra text files to the drive; delete the volume in Disk Management; create a new volume — but this time I did a full format, not a quick format, in Disk Management. I hadn’t thought to use that obvious, built-in Windows tool, and now I was curious about it.

I doubted that a simple (full) format would achieve a secure wipe, but there were some conflicting messages out there. According to Microsoft,, and some Superuser comments, reformatting “deletes all data on the disk,” at least in Windows 7 and later; but according to ExtremeTech and others, a full format differed from a quick format merely in that the full format thoroughly scanned the drive for bad sectors. In the latter event, a full format would apparently be equivalent to CHKDSK /B. Someone in that Superuser discussion said that in fact a full format did use CHKDSK.

The full format of the 2TB Samsung drive, connected by USB 2.0, took 22:26. This seemed consistent with the previous experience (above) of spending about 11 hours to wipe a 1TB drive. In this external USB 2.0 drive situation, I appeared to be averaging a one-pass wipe rate of about 90GB per hour — assuming that the Windows full format had in fact done a wiping pass, and not just a disk test. Now it was time to look into what that format had achieved.

Without thinking about it much, I did that full reformat as an exFAT rather than NTFS file system. (It appeared that exFAT might be available only on a newly created partition, as distinct from one already containing data.) Then I realized that I would not sell or reuse the drive in that condition, so I did a follow-up quick reformat into NTFS. After taking these steps, I subjected the drive to a look with Recuva’s Deep Scan mode.

Judging from the previous try, I assumed that Recuva would show results almost instantly if the files were still ready and waiting to be recovered. That did not happen. Recuva initially estimated that it would take 22 hours to complete its Deep Scan. It actually took about 19:30. It did not identify thousands of recoverable files: instead, it found 22 files at the very beginning, and that number remained unchanged. Those 22 files consisted of 16 files that were ignored, presumably because they were in system directories, plus seven other files that Recuva actually listed. Four of those contained zero bytes. I recovered the other three. Their default recovered names were like $TxfLogContainer00000000000000000001. (That’s 19 zeroes.) I viewed them in Notepad. They appeared to consist of a few seemingly random symbols and a large amount of empty space. There was no apparent readable text in them. It appeared, in short, that a plain full (not quick) format in Windows 7 had in fact given the drive a one-pass wipe, and that this wipe had been effective to defeat Recuva’s Deep Scan.

I tried again to recover the drive’s apparently wiped data, this time using OnTrack EasyRecovery Home in evaluation mode. I assumed that this mode, costing me nothing, would specify the files that the program was able to recover, but would not allow me to recover them. My purpose here was just to get a sense of whether OnTrack would do a better job than Recuva in detecting recoverable files — at least my 41 Yogi Berra text files, not to mention the many thousands of files that had existed on the drive before my quick format prior to loading the Yogi Berra files. The program stalled for about three minutes while it was detecting drives, and then came up with a list showing each drive and its partitions. It identified the external USB Samsung drive by its model number, HD204UI. On that drive, it found only partition F, the 1.82TB drive labeled New Volume that I had created on the Samsung in my reformat. I clicked on that drive. It gave me a warning:

Bad blocks have been detected. WARNING: Continuing to operate your system may damage your hard drive beyond repair or cause irretrievable data loss. Please contact product support to further assist you with this recovery scenario.

I rebooted because the system was behaving sluggishly. Now the drive wasn’t visible at all, even in Disk Management. I unplugged and replugged, removed and reinserted the drive, and then it was visible. That was odd. I tried again in OnTrack. This time, I did not get the error message just shown. I selected the Samsung drive. I got a message:

You have selected a disk – choose a disk only if your volume is not available.

Under the Samsung drive (identified again as HD204UI), OnTrack was now showing two partitions, where previously I thought it had been showing only one: in addition to F (New Volume), now it was showing Part00 (NTFS/HPFS/exFAT). Each was registered as being of the same 1.82TB size as the entire drive. I selected Part00. I got another message:

IMPORTANT: Make sure that there is a disk in or connected to your system that has enough space to save the recovered data found during the following scan process!

I figured the evaluation copy would not actually recover anything; but if it came to that, I could attach a drive later. I clicked Continue. Now OnTrack asked what kind of recovery scenario we were talking about. I clicked Formatted Media (i.e., not the default, Deleted File Recovery) and left only NTFS and RAW selected; I had not used other filesystems (e.g., FAT, exFAT) to record any files. It began its scan. It initially estimated more than 1.5 days. That estimate soon dropped to more like 1.2 days. It did take more than 24 hours. How much more, I was not sure, because I was not present when it finished. It did not provide a report of time elapsed. I went into its menu: Extras > Open log file. But nothing happened. Had it not created a log file? I tried Extras > Show scan report. It gave me a plain text file indicating that it had been created just now, at the moment when I chose that menu option, but that its contents were drawn from a log file located on my drive C. I went to that location and found that file. It looked like it might be easier to read. It seemed I had commenced the scan at 12:37 PM one day and had completed it at 10:34 PM the following day, for a total of about 34 hours. The scan of Part00 — the partition formerly containing tens of thousands of files — had found one file containing zero bytes. It did appear that the Windows full format had produced an erase secure enough to foil at least some commercial file recovery software.

Heidi Eraser

I tried again: I copied my 41 Yogi Berra files to the 2TB Samsung drive and wiped the drive again. This time, I used Heidi Eraser 6.0.10. Eraser was an old and stable program. Against Parted Magic, it had the advantage of running in Windows rather than requiring a reboot from a DVD or USB drive. It was also desirable to have its option of a one-pass Pseudorandom Data erasure method. It did seem that even a quasi-random wipe would be better than a predictable wipe of zeroes or ones. Eraser offered the option of just wiping the files in a folder, and I thought I’d try that: no point re-wiping the whole disk, where my file recovery programs had already failed to find anything there. Eraser required just a few minutes to erase the 41 Yogi Berra files (15GB). (On another occasion, I used Eraser’s one-pass pseudorandom erasure method to wipe an entire 2TB HDD. That took about 21 hours.)

Having wiped those 41 files in a matter of minutes, I attempted to recover them. I saw that VirtualLab was the highest-rated data recovery program on CNET and was also the first of five recovery tools recommended by Tech Republic. I downloaded and ran a copy (version 7.0.22). It promptly offered to update me to 7.0.64, which I accepted. I chose its Deleted File Recovery option. In its Advanced Recovery Settings, I set its maximal file size to 1TB. I ran it. It quickly found 41 files. That was not encouraging, but perhaps it was to be expected in a wipe of files rather than of an entire partition.

The recovered names of those 41 files seemed to consist of random characters (e.g., IJJklTjoA{orMX[s). Each was only 4KB in size, suggesting that I had only the shell of the file without contents. Spot checks of a half-dozen of these files confirmed that their recovered contents consisted entirely of zeroes. I did not understand that. Perhaps Eraser had written random values and had then erased them, though presumably VirtualLab would then have recovered the erased random values. Possibly Eraser did not actually write psuedorandom values.

In addition to those 41 files, VirtualLab recovered a folder named Unknown Files. These four file and one subfolder appeared to be approximately the same as the ones recovered by Recuva (above). For instance, there was one called, approximately, $TxfLogContainer00000000000000000001. (I did not count the exact number of zeroes on this one.) As above, that $TxfLogContainer file was large, consisting in this case of a reported 10,486KB (i.e., around 10MB). These files, too, consisted of zeroes, except for a few random characters at the start of one of them.

It appeared, in short, that the Eraser file wipe had removed the targeted files beyond the point of recovery by at least some commercially available file recovery software. I assumed but did not verify that a full partition wipe would similarly remove all files on a partition from recovery.


At this point, not wanting to test every known combination of erasing and file recovery programs and commands, it seemed appropriate to pause and reflect on what I had learned so far.

In the area of physical drive destruction, it seemed ideal to use a drive erasure program or command, if possible, before damaging the drive. For some purposes it would also be advisable to remember that there existed methods to recover files from even a small fragment of a hard drive platter, assuming someone could find the fragment and had a motive to go to that trouble.

In the area of software-based data destruction, I had found a number of file wiping programs and commands. These included DBAN, Heidi Eraser, and other Windows erasing programs (e.g., KillDisk, CCleaner); command-line solutions in Linux (i.e., hdparm, dd, and shred) and Windows (i.e., diskpart, SDelete, cipher); the ATA Secure Erase command built into drive firmware and reportedly accessed by certain tools (notably hdparm, Parted Magic, and HDDerase); the basic Windows full (not quick) format; drive encryption (in e.g., TrueCrypt or DiskCryptor) with an optional reformat (quick or full) afterwards; and hard drive manufacturer zero-fill or disk erase utilities.

There were knowledgeable indications that one wiping pass would be sufficient for all purposes — that even experts with direct access to the drive’s hardware would be unable to retrieve a meaningful portion of the drive’s contents. There did not appear to be any instances in which data had been recovered from a drive wiped with one pass. I suggested ideally making one pass with two different programs, at least one of which would write random data rather than just ones or zeroes, to guard against the possibility of any heretofore undetected flaw in the wiping program.

Experimentation with a few wiping programs and commands, on 1TB and 2TB drives, yielded the tentative impression that a one-pass wipe might proceed at a rate of about 90GB per hour. That was the preliminary sense on an internal SATA drive mounted in an external dock and connected to a slow computer via USB 2.0 cable. I did not know whether a different setup might yield a different rate. It seemed plausible that, within a given drive and physical setup, most well-devised wiping techniques would proceed at about the same rate; presumably most were doing approximately the same thing, which was just to write a value to a specific point on the drive.

The most prominent exception seemed to be the ATA Secure Erase command, apparently available only for internally mounted drives, by which — assuming the programmer and the manufacturer implemented the command correctly — most drives manufactured since 2001 (including user-inaccessible hidden areas) might be securely wiped within just a few hours. As noted in a separate post, there were indications that, at least for SSDs, some manufacturers had failed to implement the command correctly. Pending further insight, it appeared that even the use of the ATA Secure Erase command might ideally be accompanied by a second wipe of random data using a different program.

To recover data from these wiped drives, I had tried Recuva, OnTrack, and VirtualLab. Recuva was free; the other two were evaluation copies. My brief testing had not revealed any meaningful differences between these programs in terms of data recovered. Recuva had seemed faster than OnTrack. That would have been unimportant if OnTrack had been better at recovering data, but at least in this brief test it wasn’t. None of these programs offered exotic intense scans that would have detected residual magnetism. It appeared that kind of analysis was beyond the capabilities of contemporary hard drive heads.


I had investigated HDD secure erasure to some extent. I was not an expert. On the basis of the foregoing discussion, it appeared that the best drive wiping process would include as many of these steps as possible:

  1. Use the ATA Secure Command. For those familiar with Linux commands and drive architecture (or willing to accept drive parameters suggested by others), a direct hdparm command would achieve this; for others, the Secure Erase option within Parted Magic appeared to be a viable alternative.
  2. Make a single wiping pass, writing random or pseudorandom data, by means of a well-known program or technique that would not take the computer out of service for many hours or days. (The loss of service might not matter to users who had other computers that they could use while the process was underway.) The (Heidi) Eraser program appeared to be a good choice. SDelete was an alternative for those who were comfortable with the command line. Alternatives not using pseudorandom data included diskpart and a simple full (not quick) reformat. There may have been other, comparably reliable programs that would offer options similar or superior to those offered by Eraser or SDelete. Those who hoped to anticipate computing developments five or ten years down the line might or might be ultimately justified in preferring other or additional approaches, some of which would greatly extend the time required for the wiping process. These alternatives included the use of multiple wipes and the arcane alternative settings offered by DBAN.
  3. Physically destroy the drive. The best approaches would leave nothing left. Suggestions along these lines included the use of acid, thermite, or a thorough grinder. Second-best alternatives would leave few and relatively small traces of the drive’s platter and its circuit board, preferably not traceable to a particular drive and owner. A good hard drive shredder could achieve this outcome. Third-best alternatives would at least damage the drive so that it would not spin. Bullets, saws, and hammers could achieve this. Drive degaussing offered an alternative to physical destruction, especially if it was then possible to conduct manual testing of the drive’s platters and circuit board with the forensic means that investigators would use.

Based on the information I reviewed, steps 1 and/or 2 would suffice to eliminate the data from recovery by anyone not possessing advanced forensic skill and equipment. In my own tests of several methods mentioned in steps 1 and 2, typical data recovery software was unable to recover any of the drive’s contents. Those results contrasted against use of that software to recover data from a drive that had been merely quick-formatted. In that case, data recovery software appeared able to recover a great deal of information.

This entry was posted in Uncategorized and tagged , , , , , , , , , , , . Bookmark the permalink.

4 Responses to Securely Erasing a Hard Drive

  1. Hi,
    There’s a newish T13-published function called SANITIZE (B4h), which includes one or more of three possible sub-functions: BLOCK ERASE EXT (0012h), CRYPTO SCRAMBLE EXT (0011h) and OVERWRITE EXT (0014h).

    Lenovo has software over at:

    for their products which implements this CRYPTO SCRAMBLE EXT on their laptops.

    hdparm doesn’t offer this function as yet so as far as I know there are no other pubic tools which offer CRYPTO SCRAMBLE EXT for general use on drives which support it.

    Kind Regards


  2. Bob says:

    Thanks for taking the time to write all this, it makes for useful reading.

  3. Anonymous says:

    I second that. I can’t imagine how many total hour you put into this. Thank you so much.

    • Ray Woodcock says:

      I appreciate you guys saying so. Yeah, it was a lot of work. I see the stats on visitor traffic, so I know people are using this stuff. But it’s still nice to hear it. Good luck!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.