Wiping disk space, bit by bit? [Resolved]


I saw a data recovery and forensics expert speaking on a disk imaging tool which, unlike typical disk imagers that only read forward (and skip over sectors when they hit bad spots), this tool integrates code from dcfldd and "changes direction" in order to read backward, and forward again. It also comes back to sectors, like it's mimicking a torrent. In this way, he has recovered data in which other data recovery guys had previously marked "unreadable" and assumes them all as 0's. So naturally, my first thought turned to BleachBit. ...

The documentation (in the Limitations of Shredding Files section) compares the overwritten file to "floating in a pool of noise", but states that some parts of not overwritten.

The question that arose in my mind is, "When BleachBit is overwriting (either a full drive or only free space), does BleachBit actually fully rewrite over every bit to mark them as 0's, or does it only seek out certain parts to rewrite, leaving the rest of it accessible to tools such as this?"

Do you mean this tool makes a special effort to recover data from bad sectors? Or is it re-reading the same (good) sectors multiple times? What is the name of this tool?

Andrew, lead developer

To answer your question: yes, the man referring to it is specifically interested in attempting to recover bad sectors as fully as possible.
Here's the ShmooCon video referring to it: https://www.youtube.com/watch?v=eR8x8T5cZlM&list=UUhGDEluRG9r5kCecRAQTx_Q

The "CRU Ditto" (http://www.cru-inc.com/products/wiebetech/ditto_forensic_fieldstation/) implements dcfldd with SMART logging, and they are - 1) either trying to implement, or 2) have already implemented - ddrescue.

Since the whole point of BleachBit is data destruction, my question is whether BleachBit destroys by - 1) overwriting just the beginning of files, or 2) overwriting every single bit of data of every file.


Pre-emptive action:

If the following two conditions are true, then BleachBit can take pre-emptive action on this:
1) BleachBit does not already overwrite every single bit of every file with zeroes, and;
2) CRU Ditto has not already implemented ddrescue.

If, however, BleachBit already operates this way, then they're ahead of the curve. But if not, then maybe BleachBit can use ddrescue as a means of measuring files to ensure that they're 100% completely overwritten.

Again, maybe BleachBit already does this. Whether or not it does would be a good thing to make clear on the front page. And if it doesn't, then maybe that should be priority #1? "Implementing ddrescue to verify file overwrite"? It would make sense that it would take longer for the program to complete. Maybe to counter this, an option to overclock the CPU by certain percentages could be added?


This is all speculation on my part. I'm not an expert, but it sounded like stuff that should be brought to attention.

When deleting a file with overwrite enabled, BleachBit attempts to overwrite the whole file (every bit), including the unallocated parts of the last block. The documentation covers some limitations. For example, if when saving a new version of an existing document your word processor creates a copy, deletes the original, and renames the copy to the original, then it is difficult to find and erase the original without wiping the whole free space or partition.

When overwriting free space, BleachBit overwrites all the unallocated blocks. If this option overwrite every bit of every file, then it would not be overwriting free space: it would be wiping a partition or device. The documentation lists some limitations here.

CPU is not relevant to this issue. First, the speed is an issue of the disk speed, not the CPU speed. Second, the thoroughness is generally determined mainly by the amount of inconvenience a person is willing to endure: wiping a whole partition vs. just free space, using strong encryption, not storing information, securing backups, etc.

The documentation covers some of these details and suggests that people with strong privacy needs should consider multiple layers of protection.

Andrew, lead developer

Ah okay, that answers the question (so I changed the post to [Resolved]). Before I start securing someone's computer, I like to flash the BIOS, run anti-rootkits, and wipe them. But recently, I've questioned whether wiping before encrypting was even worthwhile. But it sounds like - yes, it is. Thank you for having this out there, guys.

Yes: when encrypting a partition, you should wipe the partition unless the encrypted file system does it. If possible, wipe the device (including the bad blocks using something like DBAN) instead of just the partition.

(BleachBit version 1.6 does not wipe partitions or whole disks.)

Andrew, lead developer