The Lie Your OS Tells You.

Deleting a file doesn't make it disappear. A law firm learned this the hard way when supposedly erased files showed up in a data breach. The data was still there on the recovered drives.

But there’s an important detail that’s often missed: whether your data is really gone depends on the type of storage you use.

On a traditional hard drive (HDD), deleting a file just removes its index entry and marks the space as available. The actual data stays until something else overwrites it. It’s like taking away a library’s index card, the book is still on the shelf, just harder to find.

On an SSD with TRIM enabled, which is standard on most modern systems, things work differently. When you delete a file, the operating system tells the SSD to erase those blocks. This makes recovery much less likely. If your drive uses proper encryption, deleted data is already scrambled and unreadable without the key.

So, the real rule, “deleted doesn’t mean gone,” is true for HDDs, sometimes true for SSDs, and mostly false for encrypted drives. Remember this before making any assumptions.

SHRED

shred is a Linux command-line utility that overwrites files before deleting them, making forensic recovery significantly harder. Basic usage:

bash

bash shred -u -z -v <FILENAME>

The -u flag deletes the file after shredding, -z adds a final pass of zeros to hide the shredding, and -v shows detailed output. It’s straightforward and works well on the right system.

Here’s the catch: shred works well on traditional HDDs. On SSDs, wear leveling can cause the controller to write your overwrite somewhere else, so the original data might still be there, just marked as inactive. On copy-on-write filesystems like Btrfs or ZFS, which are common on Linux, snapshots can keep the original file even after shredding. The Linux manual for shred warns about these issues.

Another point: the idea that you need three overwrite passes is outdated. This comes from Peter Gutmann’s 1996 paper, which was about much older drives. Gutmann later said his method doesn’t apply to modern drives. On today’s HDDs, one overwrite is enough to prevent recovery. Doing more passes just feels safer, but it isn’t necessary.

The History File Problem

Your shell: bash, zsh, or fish, keeps a record of every command you type. The ~/.bash_history file is a valuable source for forensics, showing a timeline of your terminal activity. Shredding this file is a good and useful step:

bash

bash shred -u -z -v ~/.bash_history

You can also prevent future logging:

bash

export HISTFILE=/dev/null # send history nowhere

export HISTSIZE=0 #store zero commands in memory

But most guides leave out an important point: the history file is only one piece of the puzzle. An experienced examiner will look for more.

Commands can also show up in files like .zsh_sessions, .local/share/fish/, .viminfo, .lesshst, the auditd log, and the systemd journal. If you run journalctl on many Linux systems, you might still find command traces even after deleting the history file. RAM, swap files, and crash dumps can also hold traces if the system was running when commands were used these are places that shred doesn’t reach.

If you use cloud sync or any backup service, those systems probably saved the history file before you deleted it. Shredding your local copy doesn’t affect those backups. The real risk is often the record of what you did months ago, which could still be in a backup, a journal log, or a thumbnail cache.

CIPHER on Windows

Windows has a built-in tool almost nobody knows about:

cipher /w:C:

This command overwrites all free space on the drive you choose, not your current files, but the leftover pieces of deleted files. It makes three passes: first with zeros, then ones, then random data. It’s free, built-in, and a good idea before selling or giving away a computer.

The limitations are real. cipher /w does nothing about Volume Shadow Copies, System Restore points, the hibernation file (hiberfil.sys), or the page file, all of which can contain sensitive data fragments. A forensic examiner knows to check these first.

On SSDs, the same issues as with shred apply. Wear leveling and TRIM make wiping free space mostly ineffective. cipher /w is helpful, but mainly for Windows systems with HDDs.

The SSD Problem, Honestly

For SSDs, the more reliable approaches are:

Use full-disk encryption from the start. If the drive is encrypted before you store any sensitive data, any leftover bits in hidden cells are already scrambled. This is the best solution, but it only works if you set it up before using the drive, not after years of unencrypted data.

Use hardware-level Secure Erase with hdparm on Linux or with manufacturer tools. This is better than software overwrites, but it’s not perfect. Some research shows that certain SSDs only clear the mapping tables and leave the actual data in place. Secure Erase is better than nothing, but it’s not a guarantee.

In truly high-risk situations, like an activist crossing a dangerous border or a whistleblower facing state-level threats, only physical destruction is certain. Use degaussers for HDDs and shredders for SSDs. Software methods are not guaranteed, but physical destruction is.

Don't forget the Metadata

Everyone focuses on file content. Forensics loves file metadata.

If you delete secret.pdf, the file’s content might be gone. But files like recently-used.xbel, Windows Jump Lists, thumbnail caches, Spotlight indexes, and access timestamps can still mention the file by name, show when it was opened, and reveal where it was stored. It’s like erasing a book but leaving the library’s notes about it.

Good data hygiene means paying attention to filenames, access logs, thumbnail caches, indexing databases, and cloud version histories not just the files themselves.

The Takeaway

Anti-forensics is not just one tool or command. It’s a process with many layers, and each layer can fail in its own way.

shred works well on HDDs, but not on SSDs. cipher /w is helpful before you transfer a computer, but not on encrypted or flash drives. Deleting your history file only removes one of many traces. Secure Erase is better than overwriting, but it’s not a sure thing. No software can protect data that’s already been synced to the cloud, saved in a backup, or logged in a system journal.

Your approach depends on your threat model. Basic cleanup will stop a casual snooper, like a curious coworker or roommate. A forensic investigator with access to your drive needs strong encryption and hardware erasure. If you’re facing a state-level adversary with live system access, you need a much more advanced strategy.