2

My question refers to securely erasing viruses from the usb flash drives, including the MBR, in case there is one.

I was thinking of booting with Linux from a closed CD-R (a cd rather than USB flash drive because of the possibility of a virus jumping from one drive onto another AND bootable in order to prevent the virus from infecting the OS)....

.... and using the terminal to do so with this the disk erasure command:

dd if=/dev/zero of=/dev/sdX bs=4096

Should that be erasing all of the sectors from the flash drive?

Gilles 'SO- stop being evil'
  • 51,415
  • 13
  • 121
  • 180
user288528
  • 21
  • 1
  • Booting from a CD/DVD doesn't prevent it infecting the the OS you use day-to-day. Assuming you still have the hard drive connected, there's no reason why the USB drive couldn't plant files on the hard drive. Similarly, it could affect files on the hard drive, such as encrypting them or deleting them. The only way to be sure is to disconnect the hard drive that you would normally boot off. – Chris Murray Nov 11 '14 at 11:40
  • 1
    @ChrisMurray it's not possible to a virus on a USB drive _magically_ jump from it to the HDD. It's not the way it works. The user must execute it, and I don't think the OP will do it. Booting a live-CD distro is enough, and usind `dd` will surely destroy any trace of the virus. – ThoriumBR Apr 30 '15 at 01:46
  • if=/dev/zero will certainly do it. if=/dev/urandom is better, but slower. Both will work to obliterate a virus. Viruses cannot operate without a filesystem from which to execute. – DrDamnit Aug 09 '17 at 21:30

1 Answers1

1

That will do the trick just fine if you just want the data unreadable by connecting the drive to a computer (an alternative to your command is to use shred : shred -n 1 -v /dev/sdX).

What's more problematic is that data may still be readable by extracting the flash chips, dumping them and then reconstructing the partition layout (not the partition table your PC sees, but the raw table the drive's controller uses for wear leveling).

On a flash disk simply overwriting the data multiple times doesn't have any effect because the internal wear leveling mechanics don't guarantee that the data you overwrite it with will end up on the same physical block of the flash device.

One solution would be to use the secure erase command supported by some SSDs (sadly I don't think it's supported for USB flash drives) and even then, nothing guarantees that the manufacturer correctly implemented the command.

Another solution I thought about would be to overwrite the drive a lot of times (write 10x its capacity), so that even if wear leveling mechanics come into play each block of the flash device will be overwritten at least one time; but that would wear out the device quite a lot and may even kill it.

Until the secure erase command is guaranteed to be reliable, the best solution for secure data destruction is this.

  • Note also that neither option will work for securely deleting data: both `dd` and `shred` will make the data unavailable through ordinary means (including anything a virus would be able to do), but a forensic data recovery effort may be able to read it. – Mark Nov 11 '14 at 05:40
  • @Mark for `shred` I'm not so sure - it's specifically designed to securely erase data. In my example I use only one pass so it's not that secure but with its default settings it's already better (three passes of random data if I remember right). But note that we're talking about flash drives and conventional secure data destruction methods may not be effective on them. –  Nov 11 '14 at 05:42
  • With solid-state media, you can't count on two writes to the same logical sector winding up on the same physical sector the way you can with spinning disks. The drive's wear-leveling algorithms can (and often will) spread them out; if the drive has spare sectors to replace worn-out ones, a "full-disk" shred will miss data on the spare sectors. See http://security.stackexchange.com/questions/5662/is-it-enough-to-only-wipe-a-flash-drive-once for more information. – Mark Nov 11 '14 at 05:54
  • @Mark yes indeed, but for this case it's a bit irrelevant to the original question. –  Nov 11 '14 at 05:56