Serious bug in Drive Wiper tool

[John Hind]

I have found a serious bug in the Drive Wiper tool which causes it to terminate early before completing the wipe. This applies to all methods except Simple Overwrite. On an empty 300GB partition, the process terminated after wiping only about a third of the space. I am testing using v3.02.1343(64-bit)on Windows 7 64-bit. However I first noticed the problem on v3.01 when I saw that disk wipes typically took only a fraction of the time estimate given by the program.

 

In order to speed up testing, I reduced the partition size to 5151MB and tested with each of the Security settings in turn with the following results:

 

Simple Overwrite 1-pass - Terminated after wiping all 5151MB.

DOD 3-pass - Terminated at approx. 4420MB.

NSA 7-pass - Terminated at approx. 4125MB.

Gutmann 35-pass - Terminated at approx. 4125MB.

 

Note that the program is NOT crashing - it returns to the initial Drive Wiper screen in exactly the same way as if the process had completed at 100%.

[Augeas]

There are factors that cause certain areas not to be wiped. Have a look at the documentation. This might explain why the first test wipe wiped all, then subsequent wipes wiped less. How are you measuring in mb how much is wiped?

[John Hind]

There are factors that cause certain areas not to be wiped. Have a look at the documentation. This might explain why the first test wipe wiped all, then subsequent wipes wiped less. How are you measuring in mb how much is wiped?

None of the factors mentioned in the documentation should effect an empty disk (i.e. one that has just been formatted either by CCleaner or, as in this case, by me in Disk Management).

 

I am simply watching the MB counter in CCleaner like a hawk and noting the maximum number just before the process finnishes - so I could easily be out by +/- 10MB but no more than this as the rate of increment is pretty constant. For example, in the Gutmann (slowest increment, so easiest to follow) the counter is at "4125MB of 5151MB", the progress bar is at 80% and it is still forecasting several minutes to complete. This is just before it returns to the initial screen and stops writing to the disk.

 

I am absolutely convinced this is a real bug with the wiping process, because I am wiping a batch of old disks of differing sizes for sale on eBay and have noticed this problem on them all. The time taken for the larger disks (which only complete 20%-35%) is much too short for the number of writes required at the maximum write speed of the drive, or indeed even for SATA2!

[Guest MrT]

Can you please let us know if you can recover any data from the disk after wiping it?

 

Thanks!

[John Hind]

Can you please let us know if you can recover any data from the disk after wiping it?

OK, you seem to have enlisted me as an unofficial tester!

 

I used the WinHex editor to establish what is actually on the disk at various stages and CaptureWizPro to record videos of CCleaner in action so I can catch exactly what it is reporting.

 

Firstly the bug does seem to depend on the exact partition size - in trying to replicate my earlier results I tried sizes of 3031MB, 6062MB and 5155MB (all as reported by CCleaner as the total size of the free space when newly formatted). All of these seemed to be OK i.e. the wipe progressed linearly to 100%. However when I reset the size to exactly 5151MB as before, the problem recurred. On the 35-pass wipe the count reached 4127MB (80%) and then jumped directly to 5151MB (100%) fleetingly before returning to the start screen. On the 3-pass wipe the count reached 4445MB (86%) before jumping directly to 100%.

 

To see what was actually happening on the disk surface I did the following:

 

1. Reformatted the drive.

2. Created a TrueCrypt container file 5150MB in size in the root directory.

3. Deleted this file and emptied the trash.

4. Used WinHex to confirm that the entire free space was filled with pseudo-random data.

5. Executed a 3-pass free space wipe in CCleaner (v3.02.1343(64-bit)).

6. Examined the result in WinHex - most of the free space had been zeroed, but there were very significant zones throughout still containing pseudo-random data.

7. Executed a 1-pass free space wipe in CCleaner.

8. Examined the result in WinHex - now *almost* all the free space had been zeroed, however a 578 cluster block right at the logical end of the disk had still been missed.

 

I have not tested the 32-bit version, but intuition is telling me this is probably an integer truncation problem introduced in the conversion from 32-bit to 64-bit and if I had access to the source this is the first thing I would be looking for.

 

I have attached a video of the tail end of a 7-pass NSA wipe so you can see the problem for yourself.CCleanerBug.wmv

 

Happy hunting,

 

John.

[Guest MrT]

Thanks, we'll look into this.

[John Hind]

Thanks, we'll look into this.

Just to complete the picture, I did a further test using the above methodology with a partition spanning the entire disk. As you can see from this video, it cuts out at only 33%: CCleanerBug2.wmv

 

In WinHex, the clusters are a roughly equal mixture of those surviving as pseudo-random data from the deleted TrueCrypt container, all '0' and all '1'. The last surprised me as it seems to show that CCleaner is cutting out between passes for some clusters i.e. it has done the first two passes but not the third.

 

I hope this additional data will help you zero in on the problem.

 

- John.