How secure is the cipher/ w?

Securely deleting data, otherwise known as “wiping” can be surprisingly difficult.

Overwriting data even once with “cipher/ w”, or any other tool, makes the data effectively gone. The old bugaboos about multiple pass wipes being necessary to thwart magnetic force microscope recovery of partial track wipes is urban legend. It was theoretically possible back in the days (20 years ago) preceding IDE disk drives with storage capacities measured in MEGAbytes. Even then it was a laboratory curiosity never successfully demonstrated at scales beyond a few bytes. A one pass write of anything; zeroes, random, pattern, whatever, securely wipes the data. Yes, “cipher.exe” and others offer multiple pass wiping, but this is a marketing holdover because so many people still believe it’s necessary. It’s not and it’s a waste of time, but feel free to multipass if you like.

But I said it can be difficult, then described something simple?

The hard part is actually overwriting the data, because the data is often not as static as it seems. Tools like “cipher.exe” overwrite unallocated disk space, commonly referred to as deleted. For the most part, this works as you would think. So where does this fail? Slack Space (smallish risk) File storage is allocated in blocks. Any file that does not use an exact multiple of blocks will have filler making up the difference. Typically this is fragments of whatever file last used this disk block. Realistically, this is a relatively low risk of useful content. On solid state drives with properly functioning TRIM, slack space should be empty.

Bad Tracks/Sectors (small risk) Tracks that have been remapped due to failures may contain chunks of data that will not be touched by overwrite attempts. Generally these are genuinely bad and data is not retrievable, or even if retrieved contains system fragments not associated with anything important. Yes bad tracks can be artificially created, but if you did that you’d know you did it, it’s not accidental.

Wear Leveling (insignificant risk) Solid state drives attempt to reduce wear by switching out memory chunks internally. When this happens, old data cannot be reached to overwrite it. Again, these are tiny chunks and accessing the chunks requires “Chip-Off”, removing the memory chips and controllers in order to bypass the wear leveling control. Even if this is done, good luck getting anything useful from it.

Databases and MFT (significant risk) Databases delete entries by marking the space as available to be reused, however this is not unallocated to the system because it’s still part of the allocated database file. It will not be overwritten by “cipher.exe”. The Windows Master File Table works in an analogous manner. It’s main function is to hold file attributes and point to the disk location(s) actually containing the file data. However if a file is small enough (approaching up to 981 bytes), the actual file data may be stored directly in the MFT. Deleting this file marks the entry as available to the MFT, but the MFT as a whole is still allocated so will not be touched by “cipher.exe”.

Shadow Volumes (big risk) Microsoft supports the ability to perform recovery “rollbacks”. It accomplishes this feat of magic with the Volume Shadow Service (VSS). In essence, Windows maintains prior version copies of files that have changed. Not just a single previous version, but potentially many previous versions. These previous version files are easily recoverable even if the current version has been successfully wiped. “cipher.exe” will not touch shadow volumes.