Jump to content

John Hind

  • Posts

  • Joined

  • Last visited

Everything posted by John Hind

  1. 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.
  2. 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.
  3. Good call! The only place I'd use it is from the Drive Wiper and then only when preparing a drive for sale. Also as I've reported in another thread, I have recently had reason to distrust CCleaner Drive Wipe and have little confidence that it is actually doing what it claims. My criticism is mainly about transparency and reporting - it ought to do what the user might reasonably expect it to do, or else clearly state what it is going to do. My point is simply that, given there is no explicit setting for WFS wiping method and there is a setting for file wiping method, many users will assume as I did that the setting for files applied to free space also, or as the original poster did, that the setting in the Drive Wiper tool would also apply to the WFS option. I do not think the point about the time taken is very germain - even the one-pass method is going to take a long time on most disks, but having a separate option for files and freespace would satisfy if this is thought to be a real issue.
  4. Hm.. That seems like a sub-optimal design. I would certainly expect that if I select a higher security option for file deletion then that option would be honoured for WFS in Options/Settings. If I am paranoid, I am paranoid, paranoia is not selective! Indeed if WFS is selected, it should not be necessary to do the secure deletion for any files deleted in that run because the sectors in those files will become free space and would then be wiped by the free space wiper at the end of the process.
  5. 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!
  6. Most likely explanation is that you have got different security options set. The method for the Cleaner Advanced processing is set on Options/Settings (I assume that leaving the setting at "Normal file deletion" is the same as selecting "Secure file deletion" and leaving it at "Simple Overwrite"). However the method for Drive Wiper is set on the Security dropdown on the tool itself - if you set a multi-pass method the time will be multiplied by the number of passes (roughly). I tested it on my system with the "Simple Overwrite" method set for both and it estimates roughly 30 minutes in both Drive Wiper and Cleaner.
  7. 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%.
  8. I believe I can throw some light on this thread (if anyone is still interested), rather than heat! From what I can see, "Drive Wiper" is at root a free space wiper. i.e. it overwrites all the bytes in sectors which the file system has marked as not in use. Except with the use of advanced forensic kit, this should render the data in these sectors unreadable on a PC to any software including Recuva, even with just a single pass. If you select the "Entire Drive" option it simply does a fast format making all of the disk (except the root directory) free space, then it does the free space wipe function as described above. This means that it will not necessarily overwrite directory entries in any directory (Free Space Only mode) or just in the root directory (Entire Drive mode). This is because a directory sector will contain many directory entries and is not freed while any are still in use - the directory records are just marked to show the file has been deleted. Even after a format operation, at least one sector of the root directory will remain. So Recuva may well find directory entries even after a wipe, but it would only be able to recover the file length and size, the content of the file will have been fully deleted. So the good news is that "Entire Drive" wipe will permanently delete everything except maybe some file directory records from the root directory. If you are concerned about even root directory filenames and dates being recovered, you will need to use a whole disk eraser that erases the entire disk sector by sector at a lower level.
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.