Hacker News Reader

Comment by NewsaHackO | Hacker News Reader

In the intentionally dropped section, it lists shed as "Not particularly useful on Windows." Does anyone know why? Is thre already a shred-like command in Windows?

View on HN

The one in that section that kills me is the lack of `uname`. So you build a bunch of posix-compatible stuff, note that some things will be missing and some work slightly differently. It sure would be nice if we had a standard way of telling which kind of system you were on then, WOULDN'T IT?? (a very common use case for uname)

One possible alternative is cipher.exe: https://learn.microsoft.com/en-us/troubleshoot/windows-serve...

Shred isn't very useful on SSDs in general. Because of TRIM, deleting a file instantly makes the sectors read back as 00 bytes. (Yes the data is technically still on the flash chips scattered across memory blocks without any mapping telling you where each piece of the data is, but is not readable through normal drive commands)

From shred man:

The shred command relies on a crucial assumption: that the file system and hardware overwrite data in place.

...

many modern file system designs do not satisfy this assumption. Exceptions include:

...

Log-structured or journaled file systems, such as.

...

NTFS.

I think SSDs also randomize where data ends up? But I'm not sure if that's true for existing files too.

Yes. All of the assumptions made with shred and sdelete apply only for spinning HDDs. SSDs require different methods of wiping.

Is there no way to track down where the data actually lives?

It depends on the firmware running on the SSD, so theoretically it’s possible but practically it’s not. Instead, SSDs use a special command to zero all cells on the chip at once, so it’s all or nothing. You can’t target specific files.

To clarify: the host can issue a command to the SSD to securely wipe the whole drive including spare area that is not directly accessible to the host. The SSD controller in the drive issues erase commands to the NAND to erase individual erase blocks, with typical sizes on the order of 16MB.

The SSD controller does not usually keep a history of where older versions of a block of data were stored, so it's not practical to erase an individual file and catch any partial older versions that may not yet have been garbage collected.

The filesystem may choose to store new data at different logical block addresses than older versions. The SSD will definitely choose to store those newly written blocks at different physical addresses, both for the sake of wear leveling and for performance, because a read-erase-rearite cycle on an entire NAND flash erase block (several MB at minimum) is a very slow operation.

I assume it requires something exposed by the underlying filesystem.

No. Shred will "work" - as in, compile, run, and have the expected logical effects of ultimately removing the file from the directory index - on any filesystem backed by any block device. The problem is that overwriting any part of a file is not guaranteed to actually erase the overwritten data. Actually, it never has been; shred is kind of a hack that assumes an overwriting file system driver and a block device dumb enough to not remap sectors writing to media that's intrinsically erasable. e.g. try running shred on a mounted CD-R and see how far that gets you.

Reply on news.ycombinator.com