9

I've copied a lot of photos on an external hard drive from an old computer that was used by an old person and was probably infected by malwares. I've put the photos on another hard drive. Now my external hard drive is completely empty but I'm paranoid and I'd like to be sure there isn't any malware or malicious code left on the drive.

So I'd like to fill it with zeroes but without destroying the filesystem or the partition table. In a way, I'd like to get my disk back as if I'd just bought it.

Is it possible to do that and is there a Linux command to do that ?

My hard drive is formatted in NTFS with a msdos(mbr) partition table.

Nicryc
  • 675
  • 1
  • 10
  • 21
  • Make and specific model of PC? – Moab Feb 03 '20 at 19:06
  • 8
    It's strongly recommended that you wipe the *entire* disk, including the partition table, not just the free space in the existing filesystem. Just wiping the free space in the filesystem does almost nothing with respect to being sure the drive doesn't have a virus. If all you were concerned about was making sure that it was impossible for someone to recover the information you used to have on the drive, then there's value in overwriting the free space in the filesystem. The drive should be wiped from the first block to the last. – Makyen Feb 04 '20 at 06:12
  • 18
    Could you clarify why you want to do this "without destroying the filesystem or the partition table"? Because the easiest solution is to do just that, and then create both anew. Do you realize that an empty filesystem and partition table are very easy to recreate? Most systems will do so automatically when you try to use the disk. – sleske Feb 04 '20 at 10:17
  • @sleske : That's the core essence of what I wanted to write. I suggest you put that in an answer (even if it is just a copy-and-paste). Your comment got upvoted 6 times "1 hour ago" as of 4am, not including me who is ready to upvote such an answer. User cares about some data, which is the partition details, so that should be backed up somehow (even if that just means MANUALLY recording the partition starting sector, partition size, and partition type ID for each partition, and/or any GPT details I'm not remembering off the top of my head). (Nicyrc already accepted an answer w/ Linux commands) – TOOGAM Feb 04 '20 at 11:59
  • 1
    A virus does not execute just because it is on a disk. You need a piece of software or hardware that tries to execute or at least read it. A virus is just a file like any other file. – 12431234123412341234123 Feb 04 '20 at 16:59

2 Answers2

36

Easy answer:

mount /dev/your/disk /some/free/mountpoint
dd if=/dev/zero of=/some/free/mountpoint/zero bs=512
sync # See edit below
rm /some/free/mountpoint/zero
umount /some/free/mountpoint

This will do exactly what you asked for: Overwrite all space, that is available to files in the file system, with zeroes.

More complex answer:

  • Without nuking the MBR you can't be sure, you don't have an MBR virus
  • an empty file system has no value

So I recommend you just nuke the device (i.e. zero the device, including MBR and file system) and then just recreate the partition table and mkfs.ntfs -f -L LABEL -I

EDIT

As @Nyos pointed out in the comments, if the NTFS driver does not mount sync (I don't know the defaults), it is a good idea to insert an extra sync before the rm. The current version (as of Ubuntu 18.04 fully patched to 2020-05-02) does no delayed block allocated, so the sync is not strictly necessary, as all allocated blocks will be written out on umount, but neither do we know the future nor did I read the full source code.

On the same note: If the NTFS driver once gets sparse file support, we might need to use /dev/urandom instead of /dev/zero to avoid a (nearly) endless write.

Eugen Rieck
  • 19,950
  • 5
  • 51
  • 46
  • 11
    Eugen's right about the possibility of an MBR virus. – K7AAY Feb 03 '20 at 18:45
  • Are you sure there can't be metadata left in some space reserved for metadata, which NTFS won't allocate as data blocks for this `zero` file? Some filesystems (like ext2) have static allocation of blocks as either inode or data, and more advanced FSes may still have free inodes withing a chunk of inodes. I guess that's unlikely to contain malware, so if privacy isn't a concern then that might be ok. – Peter Cordes Feb 04 '20 at 10:53
  • 3
    @PeterCordes As I said: **all space, that is available to files in the file system**. This does not include metadata, as overwriting the metadata equals nuking the file system. – Eugen Rieck Feb 04 '20 at 11:02
  • You might want a "sync" before that rm. Just to be sure your zeros get written. (Linux likes to keep stuff in memory, especially in case of removable drives) – Nyos Feb 04 '20 at 19:01
5

Although this doesn't answer your question at all... nevertheless:

First, it is a really, really bad idea to zero out a disk. That is true for "traditional" disks, and even moreso for solid state disks. Zeroing out a disk is trivial to do (just create a file and fill it, Eugen Rieck gives the exact recipe) but it takes a long time and wears down the disk. Write cycles are not infinite, on any kind of hard disk.
Also, note that you do not even have a guarantee that overwriting actually works as intended. For your purpose, the difference will not be noticeable, but for other purposes (think secure erase of confidential data) the approach is entirely unreliable. That is because you have absolutely no way of knowing what happens when you overwrite something thanks to wear-levelling and reallocation. Drives do a lot of stuff without anyone (including the operating system!) knowing or even having a way of telling, let alone changing. If, for example, a sector has been reallocated because the controller wasn't happy with the number of retries, or the CRC or whatever, you can do whatever you want going forward, you are simply not getting to access that sector any more. Never again. Still, the data, or what's left of it (and you cannot know) stays there, and a potential thief could read it out.

Second, when operating in full paranoia mode, it is a really, really bad idea to keep the filesystem (and MBR) around, especially when the disk is "empty". Other than the filesystem's UUID, you will not lose anything by just creating a new filesystem (which arguably can be a bit of a nuisance in some situations, but that's easy to fix, too). You do, however, gain the certainity that there's nothing left in places where you don't expect it (MBR, for instance).

Third, it is a bad idea to zero out and reuse an "empty" filesystem which is in reality not empty at all. It's bad in terms of performance when you can instead just create a new FS (without stale change journal entries, invisible items, forgotten streams, attributes, fragmented MFTs...) from scratch. Not only is recreating everything from scratch much more secure, it's also much faster, and it will likely result in better overall performance going forward.

tl;dr

Most devices have a dedicated secure erase or "factory reset" option (which is the same) which is supported by the accompanying management tool, or with some other tool via a standard ATA command. The drive will use the most efficient, least destructive method (some drives indeed overwrite the complete disk in lack of truly supporting the feature, but most will just dump the encryption or bit scrambling key, which works almost instantly regardless of disk size).

hdparm which is available on pretty much every Linux distro out of the box has an option --security-erase for that exact purpose.

This will give you a disk "as if just bought" with the exception of having been used for a while. It will do so in the fastest (within what's technically possible) and least disk-murdering way. Following that, partition it and create a filesystem, done.

Community
  • 1
Damon
  • 4,512
  • 3
  • 22
  • 28
  • 4
    "zeroing out disks wears them out enough to care about" sounds unlikely. Many users write, and rewrite again and again huge sections of hard drives as part of normal use. Intuition tells me a full zeroing might be less than 1% of the full lifetime disk use, and even disk-nuking options like dban which might fully write the entire disk many times should not be a big deal. I had to use dban for a previous job, and it would run all day doing nothing but continually rewriting the disk, then the disks would be reused. Not insisting you're wrong, I'm just skeptical. – Loduwijk Feb 04 '20 at 16:33
  • @Loduwijk: Well I'm not going to suggest that zeroing out a disk will instantly kill it. But it sure involves a lot of writes (and seeks) where a lot can go wrong. On a typically sized present-day spinning disk, that's something like one billion sectors being written for nothing (assuming 4kb sectors and a 4TB disk, for example). That doesn't even consider the fact that it will take anywhere between 5 and 10 hours, which is insane for something that can be done in seconds. For SSD it's yet another story, especially since wear-levelling doesn't work well in that case, disk being filled. – Damon Feb 04 '20 at 17:09
  • Although... on a second thought... running a sustained write for 5-10 hours might _indeed_ instantly kill a cheapish drive... that's a kind of smoke test, really. – Damon Feb 04 '20 at 17:11
  • I have had hard drives fail before, and I always thought it was mostly random, but thinking back now I wonder if it could have followed on the heels of some overuse and I didn't connect the dots. I'm still skeptical, but I'm walking away with an open mind. You've provided us with some food for thought. – Loduwijk Feb 04 '20 at 19:02
  • Overwriting a page on an SSD will not immediately overwrite the page where the data is stored. Instead, it will allocate a new location to hold the data, update some metadata to reflect the page's new location, and write the new data there. Storage may only be reused in blocks that are of dozens or hundreds of pages in size. If a drive decides that a block seems to be getting unreliable, it may copy all of the data from it and then mark the block so it never gets reused. – supercat Feb 04 '20 at 19:09
  • @supercat: It is much more complicated than that, even, and details vary a lot on implementations. Write amplification should hopefully not play a role for huge sequential writes, but you never know, it might. Also, some drives have different layers of wear levelling (and with SLC/MLC mixed). Be that as it may, completely filling a SSD necessarily means you overwrite every block at least once, and you also touch its reserve blocks -- the drive has no other choice. Depending on whether TRIM is maybe unsupported, things may be even more desastrous. – Damon Feb 04 '20 at 19:28
  • @Damon: Memory chips are not specified as being 100% reliable. To cope with this, a thumb drive whose memory device has e.g. 16,777,216 pages of 528 bytes each will report its capacity to the OS as somewhat less than 8GiB. If a drive reports the available space as 7,800,000,000 bytes, filling "everything" with data would necessarily overwrite the contents of at least 15,234,375 pages, but not necessarily all 16,777,216 of them. – supercat Feb 04 '20 at 19:33