I would like to know how to delete a USB flash drive via the terminal if possible so data can't be recovered.

  • 31
    A flash drive? Crack the thing open, pry all the chips off of the green circuit board thingy, and mash them up into itty bitty shiny little pieces, then go buy another one. Physical destruction is really the only way to be sure, 'cos of all the wear-leveling and stuff. In the future, use full-disk encryption and lose the keys|password when you don't want it anymore. Jan 1, 2016 at 9:50
  • 1
    @BlacklightShining - that's the only realy answer. a lot of the cheap sticks are recycles, too.
    – mikeserv
    Jan 1, 2016 at 10:08
  • 1
    @BlacklightShining Turning it into plasma works well too. Jan 1, 2016 at 15:15
  • 3
    If it is important to you that the data is unrecoverable, the only "secure" solution is physical destruction. If it's sufficient to merely be difficult to recover, then there's really no need to to more than format/overwrite.
    – Sobrique
    Jan 2, 2016 at 12:25
  • Burn it in a charcoal fire, ensuring all parts reach a red heat.
    – Ben
    Jan 2, 2016 at 22:33

5 Answers 5


TL/DR: Make sure you get the right device name, ensure it's not mounted, and do as many random overwrites as you can afford. You can follow it by an erase command designed for flash hardware, if you are on a recent enough distribution. In these checks, always use the drive (like /dev/sdh) and not the partition name (which would be /dev/sdh1)

# dmesg|grep sdXX
[3600.000001] sd 6:0:0:0: [sdXX] 125106176 512-byte logical blocks: (64.0 GB/59.6 GiB)
# blkid|grep sdXX
/dev/sdXX1: PARTUUID="88a03bb2-ced8-4bb2-9883-0a51b4d460a8"
# df|grep /dev/sdXX
# shred -vzn8 /dev/sdXX
shred: /dev/sdXX: pass 1/9 (random)...
shred: /dev/sdXX: pass 1/9 (random)...46MiB/3.8GiB 1%
shred: /dev/sdXX: pass 9/9 (000000)...3.8GiB/3.8GiB 100%
# blkdiscard -s /dev/sdXX
blkdiscard: /dev/sdXX: BLKSECDISCARD ioctl failed: Operation not supported
# blkdiscard /dev/sdXX
blkdiscard: /dev/sdXX: BLKDISCARD ioctl failed: Operation not supported

In theory, overwriting with zero with dd is just fine. However, due to how the internals of a flash drive are built, if you use a single overwrite pass, there may be several layers of data hidden behind the actual blocks that are still storing leftover information.

Typically a part of flash storage is faulty, and is marked so during manufacturing. There are also other bits that can go wrong (becoming unchangeable, unsettable, or unclearable), these parts must be marked faulty as well during the lifetime. This information is stored in a reserved space, on the same chips as your data. This is one of the several reasons a 4GB thumb drive is not showing 2^32 bytes capacity.

Flash storage is also internally organised in larger blocks, sometimes much larger than the filesystems working on the drive. A typical filesystem block size is 4KB, and the flash segments that can be erased in one go may range from 64KB to even several megabytes. These large blocks can only be erased in whole, which resets all of the block to a known state (all 1s or all 0s). Afterwards a data write can alter any of the bits (change the default 1s into 0s where needed, or change the default 0s into 1s), but only once. To change any of the bits back into the default, all of the segment needs to be erased again!

So, when you want to change a 4KB block (the filesystem is asked to change a single character in the middle of a file), the flash controller would need to read and buffer all 64KB of the old data, erase all of it, and write back the new contents. This would be very slow, erasing segments is the slowest operation. Also, a segment can only erased by a limited times (tens of thousands is typical), so if you make too many changes to a single file, that can quickly deteriorate the drive.

But this is not how it's done. Intelligent flash controllers simply write the 4KB new data elsewhere, and make a note to redirect reads to this 4KB of data in the middle of the old block. They need some more space, that we can't see to store this information about redirects. They also try to make sure that they go through all the accessible segments to store data, this is called wear levelling.

This means that typically old data is still on the drive somewhere! If you just cleared all accessible blocks, all the hidden blocks still keep a quite recent version of the data. Whether this is accessible to an attacker you want your data to be protected from, is a different question.

If you have a recent enough distribution, and the USB drive is programmed to reveal that it is a flash drive, blkdiscard can use the underlying TRIM operation, which is the segment erase that we talked about above. It also has an additional flag to make sure that even the invisible hidden data is fully erased by the hardware:

# blkdiscard -s /dev/myusbdevice

-s, --secure Perform a secure discard. A secure discard is the same as a regular discard except that all copies of the discarded blocks that were possibly created by garbage collection must also be erased. This requires support from the device.

It won't necessarily work, as I demonstrated above. If you get Operation not supported, either your kernel, your utilities, or the USB gateway chip (which allows the flash controller to look like a drive via USB) does not support passing TRIM command. (The flash controller must still be able to erase segments on its own). If it is supported by the vendor of your drive, this is the safest way.

Another, less safe way to make sure you're allowing less of the old data to linger around somewhere is to overwrite it several times, with random values, if possible.

Why random, you ask? Just imagine if the USB drive were made too intelligent, and detected that you wanted to clear a sector, and just made a change in a bitmap that this sector is now free, and will need clearing later. As this means it can speed up writes of zeros, so it makes for a pendrive that appears more efficient, right? Whether your drive is doing it, hard to tell.

At the most extreme, the drive could just remember how much from the start you have cleared, and all it needs to store is about 4 bytes of information to do this, and not clear anything from the data you want to disappear. All so that it could look very fast.

If you are overwriting the data with random, unpredictable values, these optimizations are impossible. So the drive has to make sure the data ends up stored inside the flash chips. But you still won't be able to rule out that some of the previously used sectors are still there with some old data of yours, but the drive just didn't consider important to erase it just yet, since it's not accessible normally. Only the actual TRIM command can guarantee that.

To automate overwriting with random values, you may want to look into using shred, like:

# shred -vzn88 /dev/myusbdrive

The options used:

  • -v for making it show the progress
  • -z to zero it at as a final phase
  • -n8 is to do 8 random passes of overwrites

If possible, use both blkdiscard and shred, if blkdiscard -s is supported by your drive, it's the optimal solution, but can't hurt to do a shred beforehand to rule out firmware mistakes.

Oh, and always double-triple-check the device that you are trying to clear! dmesg can help to see what was the most recently inserted device, and also it's worth to check the device name you intend to clear with ls -al, even for the devices node numbers, and the blkid output to see what partitions may be available that you DON'T want to clear.

Never use these commands on an internal drive that you want to keep using - blkdiscard will only work on solid state drives, but it's not worth to try to lose data!

There may be other ways to clear data securely as technology progresses.

One other way mentioned is the ATA SECURITY ERASE command that can be issued via hdparm commands. In my experience, it is not really supported on flash drives. It was designed for enterprise hard drives, and the feature is not always implemented in lowest cost storage devices.

The TRIM/DISCARD operation is much newer than the SECURITY ERASE command, and was created in response to the flash features, so it has a much higher chance of being implemented, even in cheap USB drives, but it's still not ubiquitous. If you want to erase an SD/micro SD card in an USB dongle, and blkdiscard reports it is not supported, you may want to try a different dongle/card reader, and/or do it in a machine with a direct SD/MMC slot.

  • Thank you for the cutting edge information. blkdiscard is in Debian Jessie, and only in the most recent two releases of Ubuntu, but not Ubuntu LTS 14.04. blkdiscard was added to package util-linux version 2.23.
    – RobertL
    Jan 1, 2016 at 1:58
  • Do you know how blkdiscard compares to the hdparm solution in another comment by @zhenech (specifically the link: ata.wiki.kernel.org/index.php/ATA_Secure_Erase).
    – RobertL
    Jan 1, 2016 at 1:59
  • Not sure if this is also the case with flash drives, but this might be worth reading howtogeek.com/234683/…
    – hhaslam11
    Jan 1, 2016 at 20:51
  • 1
    @RobertL Equal, in a bad way. Most cheap flash drives implement neither ATA Secure Erase nor TRIM, so both methods will probably fail.
    – user130738
    Jan 3, 2016 at 1:18

I realize this isn't really an answer to your question, but the simplest way is to physically destroy the drive (smashing it repeatedly with a sledgehammer generally does the trick, but industrial shredding or incineration are also options). If you're worried enough about security to want to make sure the data is unrecoverable, the value of that data is likely many times more than the cost of the drive itself, and the physical method is cheap and reliable.

  • 6
    If it's a cheap, replaceable flash drive, definitely go with physical destruction. If you do use a hammer, make sure you get the actual storage chip. I cracked open an old flash drive for fun a couple weeks back, and most of its physical volume was actually case and air. Jan 1, 2016 at 19:24
  • 1
    Apart from my answer, I agree completely - it's just difficult to smash them to pieces via ssh access :) Given how unreliable these dongles are for data storage, it's surprisingly difficult to get them actually get rid of the same data.
    – chexum
    Jan 2, 2016 at 11:58
  • Agreed - if it's important to you that the data is unrecoverable, then physical destruction is the only option. Lets face it, compared to the commercial value of the data on it, even the most expensive drives probably aren't that significant. If it's not that important almost any wipe/overwrite is 'good enough'.
    – Sobrique
    Jan 2, 2016 at 12:31
  • 1
    This method is not only the most effective, it is also the most fun. Never pass up an opportunity to use a sledgehammer and get paid for it.
    – zetetic
    Jan 13, 2016 at 1:22

The simplest and fastest way I know is to write zeros (0) to the entire drive:

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

where /dev/sdX is the device node of your thumbdrive.

Some suggest a more thorough process with more iterations and other patterns. Specific utilities are available to do this. The GNU coreutils package contains the shred command specifically for this purpose. Many people also use badblocks -w, which is part of the e2fsprogs package. On FreeBSD the shred utility is called gshred and should be available in either the /usr/ports/sysutils/coreutils or /usr/ports/sysutils/fileutils ports.

  • This isn't really enough to do a secure wipe. I would go for at least 20 series of writes of random stuff. Best of all i would use a tool for secure wiping e.g. shred. Even though some people say that it makes no sense and that zeroing is enough - i wouldn't trust that.
    – monsune
    Dec 31, 2015 at 23:47
  • 5
    @monsune That's just an urban legend. While some standards require that, there's doesn't seem to be any practical attack. Jan 1, 2016 at 0:05
  • Flash drives use wear leveling to not destroy the flash cells too fast. Imagine it like: the drive has 1200 cells but only tells you it has 1000 and the controller selects which cell it actually writes to. So after a dd you have erased 1000 cells but not the 200 in reserve and those might be readable by attaching the actual flash to a controller without reserve. I'd suggest doing a secure erase after the dd, but not all flash media supports that.
    – zhenech
    Jan 1, 2016 at 0:17
  • @zhenech, what is "secure erase"?
    – RobertL
    Jan 1, 2016 at 0:18

Almost all of the available secure-delete functions were designed for spinning magnetic media, where the computer can usually determine the physical location[1] of the blocks used for the file and write over those same blocks. Solid-state storage controller chips abstract the physical location of the data from the system and likes to move it around.

Your question really depends on who is going after your data. If you are concerned about random loss or casual theft then a regular format will be fine. If you are concerned about being targeted by a highly motivated, technically competent user with substantial resources at their disposal[2] then just incinerate the drive and spend $10 on a new one.

  1. yes, there is logical block mapping. But logical block A will always map to physical block B.

  2. this person would open the drive up, pull the memory chip off the card and read the flash memory directly, bypassing the controller


This should be able to securely wipe your flash drive if you plan on reusing it: http://linux.die.net/man/1/scrub If not then melt it...

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .