Safely deleting files off of computer

Recently took my computer to a repair shop and got sort of aranoid this guy went through all my files and put something on my computer or looked at all the stuff I have saved how do I safely delete files off my computer so they cannot be retrieved. I understand that if you delete a file off your computer its still there the space on the hard drive its stored on is just marked as cleared is there a program that would over write these physical locations on my hard drive ?

you're literally one google search away from knowing the answer to this

Use the shred program, or BleachBit. For SSD hard drives, there isn't really a way to be sure aside from overwriting the entire drive with random data, shucking the electromagnetic protections, and throwing it in the microwave for five minutes. Or just use full disk encryption from the start.

disk encryption from the start is the best. Also don't give your harddrive away. If you're lending your laptop to a repair guy, take the disk out, or better yet don't give the laptop away to begin with and do your own work. Finally, shred or DD, but research filesystems to figure out whats right/possible on yours.

>>20747 how could I quickly overwrie all the soykaf on my hard drive

>>20749 dd if=/dev/zero of=/dev/sdX where sdX is the name of your disk, do check and double check before you use the command which disk you're overwriting.

>>20749 In Windows: cipher /W:C:\Path\To\Folder

>>20751 though, dd if=/dev/urandom of=/dev/sdX is preferred, albeit a tad bit slower

>>20749 If you want to completely nuke your HDDs/SSDs, use DBAN (I recommend you physically disconnect the drives you don't want to erase to eliminate the possibility of screwing up). Use shred(1) if you want to delete individual files. Keep in mind that it's pretty hard to actually securely erase SSDs.

>>20756 >>20747 why is it so difficult to securely get rid of data on a solid state drive

>>20744 At the point you are wise enough to figure out how to secure wipe your drive, can’t you simply repair it by yourself?

>>20762 Because of wear leveling (that's done in the hardware).

Smash it, burn it, put it in acid. Then start over with new hardware with full disk encryption from the start. There's no other way. Forensics are too hard.

just take the hard drive out of the computer before you take it into another repair shop lmao. swap it out with another one if you need to

Use this as a learning experience, and from now on use FDE on every drive in your system. With modern CPUs the overhead is totally negligible. These days when I'm wiping disks (hdds) I use cryptsetup to spawn an encrypted filesystem over it (just plain dm-crypt) and use shred to fill the device with 0's (which end up as encrypted data). This gives the added bonus of filling the drive with random data so you can just encrypt it right away.

>>20749 DBAN is still around. You boot it up and let it run, I think it takes forever I would rather physically destroy the drive and maybe have actual fun doing it, after running something like dban and encrypting the drive. https://sourceforge.net/projects/dban/files/dban/dban-2.3.0/dban-2.3.0_i586.iso/ that link will try to autodownload it so be warned, I couldn't be bothered figuring out how to use scroteforge.

>>20749 sudo rm -rf /

>>20788 No. rm will only unlink the file. for targeted paths: find <dir> | xargs shred -z live boot and zero, then overwrite with random data this will depend on your hard drive, and many would argue just using a random overwrite is sufficient. dd if=/dev/zero of=/dev/<device> bs=1M dd if=/dev/urandom of=/dev/<device> bs=1M

After deleting your files, run a script to populate your newly emptied hard drive with loli porn until you max out its capacity so the guy at the repair shop won't be able to recover any traces of the data you do not wish for them to see. Geez, and I thought people here were good with puters..

>>21634 Storage devices have extra hidden space built in for when a HDD sector goes bad or a flash block goes bad. The firmware automatically re-routes new writes to one of the spare blocks. So even overwriting everything doesn't actually overwrite everything. You can still have bad blocks a forensic investigator can read with the right tools. The best thing to do is encrypt the whole drive from the start.

>>20744 You already should have your entire drive(s) encrypted via an application such as Veracrypt.

>>21637 even if you do that, isn't it still possible for the (unencrypted) data to be moved to one of these spare blocks upon deletion? If you cannot completely wipe or overwrite everything in a disk, then you probably can't completely encrypt it either..

>>20744 As others have already mentioned, overwriting a 'classic' HDD is the way to get rid of all data there securely. SSDs are much more complicated, but there are (at least) commercial solutions to this. Host protected areas (and other stuff like that) should also be overwritten if you want to be 100% sure no data is there. If you are using a file system that has journaling, that is another thing you need to worry about. Depending on the hardware, you might have hardware commands available for changing the cryptocraphic keys which essentially makes all data on the drive unreadable. This is much faster than overwriting the whole device. One thing that has been left unmentioned (bar my dyslexia) is verification. If you are really worried about someone reading that data, you need to verify that the data really is gone. So after erasing the device, you should check that the device contains only the overwriting pattern. (and with hardware commands, you need to do two phase verification)

>>22020 SSDs have a finite number of reads and writes. Think of it like a stone tablet that you carve into until there is nothing left, not the best example, but eventually the read writes will run out. Realistically as long as the device exists, some data is recoverable. >One takeaway lesson is that securely erasing data on a SSD is a bit tricky. One reason is that overwriting data on a SSD doesn't work the way you'd think it does, due to wear-leveling and other features. When you ask the SSD to "overwrite" an existing sector, it doesn't actually overwrite or delete the existing data immediately. Instead, it writes the new data somewhere else and just change a pointer to point to the new version (leaving the old version laying around). The old version may eventually get erased, or it may not. As a result, even data you think you have erased, may still be present and accessible on the SSD. >The most reliable way to securely erase an entire SSD is to use the ATA Secure Erase command. However, this is not foolproof. The FAST paper found that most SSDs implement this correctly, but not all. In particular, 8 of the 12 SSDs they studied supported ATA Secure Erase, and 4 did not. Of the 8 that did support it, 3 had a buggy implementation. 1 buggy implementation was really bad: it reported success, but actually left the data laying around. This is atrociously bad, because there is no way that software could detect the failure to erase. 2 buggy implementations failed and left old data laying around (under certain conditions), but at least they reported failure, so if the software that sends the ATA Secure Erase command checks the result code, at least the failure could be detected.

pretty much the reason why I use hdds

If I remember right, there's is BleachBit that is a program for that.It should be fairly easy to do that but I remember the same process being a bit harmful for SSDs so you shouldn't do it often or there's an alternative option or something.

One thing I don't see mentioned in this thread is that nowadays HDDs also include some amount of flash memory and wear-leveling (or equivalent mechanisms) both on said memory and on the actual platters themselves (much worse with SMR than CMR). Basically, encrypt everything because even if you delete stuff and either clear with with ATA Erase or overwrite it (depending on the hardware type), you just have no guarantees. A platter with bad blocks or blocks otherwise ignored as decided by internal drive management firmware might well retain data that can be recoverable through more advanced cleanroom forensics. Of course that's not a relevant risk for simple computer repair shops, but it's a risk that needs to be more well-known. On re-reading the thread I see that >>21637 did actually mention some of that. One of the good things about encrypting everything from the start is that it means you don't need to destroy the drives when you're done with them. It's unnecessarily wasteful to destroy equipment rather than reuse it until it's near-failure.

>>20744 Use file shredder software which comes with multiple algorithms to overrite data with random number in multiple passes .

Do problems with SSDs also apply to USB flash drives?

>>22695 yes, it is a problem with almost all flash storage on the market.

>>20744 The best tools I have seen are bleach but: https://www.bleachbit.org/ And shred: https://linux.die.net/man/1/shred Your biggest enemy is that some file systems create redundancy so you'll need to watch out for that. Best way in my opinion is to use dd and take input from /dev/null or /dev/urandom. I prefer I prefer taking from urandom instead of null because zeroed out bit may look suspicious anday indicate the intent of destroying information.

>>20749 blkdiscard /dev/sd* Will make data on an ssd practically irrecoverable for a usual repair shop bumblefuck

Destroy entire computer and cut every circuit board into triangles scatter parts all over the city Same with any memory storage

>>20744 You're probably fine, but the only 100% way is to swap the drive with a fresh one prior to taking it to a repair shop. Never physically leave your drives with strangers. Don't do that again.