How a USB Flash Drive Is Made: NAND, Controllers and Fake Capacity

A USB flash drive is made by pairing one or more NAND flash memory dies with a small controller chip that speaks USB on one side and NAND on the other, soldering both to a tiny circuit board behind a connector, and then loading firmware that maps the flash into a simple block device. The firmware decides how much capacity the drive reports, which is why a counterfeit drive can claim 1 TB while holding a fraction of that. To protect yourself, test real capacity with a tool such as f3 before trusting a drive, and erase sensitive drives with encryption or physical destruction rather than an overwrite.

This post goes one level deeper than our SSD build and our guide to hardware encrypted USB drives and bootable recovery media. It focuses on what is different about a thumb drive: a cheaper controller, little spare flash, factory set firmware, fake capacity, and no sanitize commands. Flash makers keep yields and grading rules private, so arithmetic not taken from a source is labelled illustrative.

Key takeaways

• A USB flash drive is NAND flash, a controller with a USB physical layer (PHY), a clock source and a circuit board with a connector. Many small drives combine controller and NAND in one package.
• The controller firmware runs the flash translation layer, wear levelling, bad block management and error correction, and it sets the capacity the drive reports.
• Counterfeit drives report more capacity than they hold. The f3 project calls the most common kind "limbo"; in its example a drive announced 15.33 GB but held 7.86 GB, about 51 percent.
• USB-IF asks vendors to market speeds as USB 5Gbps, 10Gbps, 20Gbps, 40Gbps and 80Gbps, not "USB 3.2 Gen 2" or "SuperSpeed Plus".
• NIST SP 800-88 Revision 2 (September 2025) says wear levelling and spare cells make it infeasible to sanitize all previous data on flash by overwriting.
• A 2011 USENIX FAST paper found 0.57 to 84.9 percent of data remained on a USB drive after single file overwrite methods, and that USB mass storage devices do not support ATA security commands.
• For sensitive data, encrypt from first use and physically destroy drives that held high value data.
• People plug in found drives: in a study of 297 drives dropped on a campus in April 2015, an estimated 45 to 98 percent were connected, the first within six minutes.

Wafer to finished drive: the step table

No maker publishes per stage yields for thumb drives, so each row names the check made instead.

Steps 7 and 8 are where honesty is decided: the tool that matches firmware to the NAND can also set a capacity the flash cannot hold. See also how a printed circuit board is made and how semiconductors are made.

A dated timeline of the standards and research

What is inside a USB flash drive?

Open the shell of a typical drive and you find a board a few centimetres long.

The NAND flash

NAND flash is organised as pages (the unit you program) grouped into blocks (the unit you erase). A page cannot be overwritten in place, and each block survives a limited number of program and erase cycles. Everything the controller does follows from those two facts.

On larger drives the NAND sits in a separate TSOP or BGA package that can hold several stacked dies, the same kind of 3D NAND that goes into SSDs. One flash maker describes its tenth generation 3D flash as having 332 layers and a 32 die memory assembly for high capacity packages.

The controller and its USB PHY

The controller is a small system on chip: a microcontroller core, a NAND interface for one or a few channels, an error correction engine, a little SRAM and the USB PHY, the analog circuitry that drives the USB wires. A USB 5Gbps or 10Gbps drive needs a second, faster transceiver for the SuperSpeed lanes, which adds cost. On many designs a boot ROM loads the main firmware from a reserved area of the NAND, which is why the factory tool writes firmware to the flash.

Board, connector and chip on board designs

A crystal, a few passives and a Type A or Type C connector complete the board; the connector does not tell you the speed. Many small drives skip separate chips: chip on board designs bond bare dies to the board under epoxy, and monolithic designs package controller and NAND into a single slab that is itself the plug. There is then no separate NAND package to remove or crush at disposal.

What the computer sees

When you plug a drive in, the computer does not see NAND. It sees a USB device that declares the Mass Storage Class and, almost always, the Bulk-Only Transport protocol. USB-IF published Bulk-Only Transport Revision 1.0 in September 1999, and it is still how most thumb drives move data: the host sends a SCSI command wrapped in a small command block, data flows over bulk endpoints, and the device returns a status block. Faster drives may also support USB Attached SCSI Protocol (UASP), which USB-IF publishes as a separate specification and which lets the host queue several commands at once.

On Linux, the kernel's usb-storage driver (or the uas driver for UASP devices) binds to the device, and a SCSI disk node such as /dev/sdb appears. The size of that disk is whatever the firmware answers when the host asks for capacity. Short of writing to every sector and reading it back, the host has no way to check it. Hold on to that fact for the counterfeit section.

How is NAND made and binned?

From wafer to die

NAND is built on 300 mm wafers in the same kind of fab as other memory. In 3D NAND, alternating thin films are deposited hundreds of layers deep, vertical holes are etched through the stack, and each hole becomes a string of memory cells stacked on top of each other. Our SSD build post walks through that process. For a thumb drive the important part comes after the wafer is finished.

Wafer sort and grading

Every die on a finished wafer is tested by a probe card before the wafer is cut. The tester checks which blocks fail, how long programming and erasing take, how much the cells leak and how many raw bit errors appear. NAND ships with some factory marked bad blocks by design, and the controller is expected to map around them. Dies are then sorted into grades. Dies with few bad blocks, good speed and good retention go to the most demanding products, such as enterprise and client SSDs or phones. Dies with more bad blocks or weaker margins go to products that tolerate them.

Flash makers do not publish their grading thresholds or how many dies land in each grade, and the cheapest storage products rarely name the NAND they use.

Why cheap drives use lower grade dies

Thumb drives tolerate weaker flash than SSDs because they are written far less. Practices described in the trade, though not documented by flash makers, include partial dies with bad regions mapped out, dies run at fewer bits per cell, and reclaimed flash of unknown endurance. None is visible on the label; a buyer can only test real capacity, sustained speed and data integrity.

SLC, MLC, TLC and QLC in a thumb drive

Each extra bit per cell doubles the voltage levels a cell must hold apart: two for SLC, four for MLC, eight for TLC, sixteen for QLC. Less margin means more errors and fewer cycles, which is why industrial boot drives often run flash in an SLC mode.

How does the controller firmware manage flash?

Raw NAND is unusable as a disk. Its pages cannot be overwritten in place, its blocks wear out, some blocks arrive broken, and every read returns some wrong bits. The controller firmware hides all of that behind the simple interface a computer expects: a numbered list of 512 byte sectors that can be read and written in any order.

The flash translation layer

The flash translation layer (FTL) is a mapping table from logical block addresses, the sector numbers the host uses, to physical locations in NAND. When the host rewrites sector 1,000, the firmware writes the new data to a fresh page somewhere else, updates the map so sector 1,000 points there, and marks the old page as stale. Later, garbage collection copies the still valid pages out of a mostly stale block and erases it so it can be reused.

A thumb drive controller has very little SRAM, so many use coarse mapping, for example mapping whole blocks or large groups of pages rather than every page. Coarse mapping is cheap but makes small random writes very slow, because changing one sector may mean copying a whole block. That is the main reason a thumb drive that copies one large video quickly can crawl when you extract an archive with thousands of small files.

Wear levelling

Wear levelling spreads writes so blocks age evenly. Static wear levelling also moves data that never changes; cheaper controllers may do only dynamic levelling.

Bad block management

Every die ships with some factory marked bad blocks, and more fail over the drive's life. During the factory low level format the controller scans every block, reads the bad block markers and records them in a table. In use, when a program or erase operation fails or errors grow too large, the firmware retires that block and pulls a replacement from a spare pool. A thumb drive usually has a much smaller spare pool than an SSD, so when the spares run out the drive often fails abruptly, commonly by switching itself to read only or by vanishing from the bus.

Error correction

Every NAND read returns some flipped bits, more as the flash wears. The controller stores parity bytes with each page and runs an error correcting code on every read; dense TLC and QLC flash needs stronger codes such as LDPC rather than older BCH codes. The Linux kernel documents a simple Hamming code for older raw NAND, a useful illustration of why ECC exists. ECC strength largely decides how weak a die a controller can live with. A drive left unpowered also gets no refresh of drifting data.

Factory configuration with mass production tools

Controller vendors supply assemblers with a mass production tool. On a test rack it identifies controller and NAND, loads firmware, scans every block to build the bad block table, picks the flash mode and ECC strength, sets the reported capacity, writes USB IDs and the serial number, then formats and tests the drive. Its documentation is not public. The capacity field a factory sets to match the flash can be set by anyone with the same tool to a number the flash does not support.

Firmware is writable, and that is a security question

Because firmware lives in the NAND and the factory updates it over USB, the same path can exist after the drive leaves the factory. Independent researchers have published work showing that the firmware on one widely used thumb drive controller family could be read out and replaced from a computer, and that modified firmware could make the drive present itself to the host as a keyboard instead of storage. We describe this only conceptually: the lesson is that a USB device declares what it is, and the computer believes it.

The defensive answers are on the host side. Linux lets an administrator stop new USB devices from being configured until they are explicitly authorized: the kernel documents an authorized_default setting per host controller and an authorized flag per device. With a policy daemon or fleet device control, "plug it in and it works" becomes "plug it in and an allow rule decides". None of this inspects the drive's firmware; it limits what an unknown device can become.

CISA's long standing advice on USB drives makes the user side point: it notes that attackers have infected devices such as USB drives during production, tells people not to plug in a drive they find, and recommends disabling Autorun.

How do counterfeit capacity drives work?

The trick

A counterfeit capacity drive is a real flash drive with firmware configured to report a capacity larger than the flash it contains. A drive with 8 GB of flash might report 128 GB, 1 TB or 2 TB. The operating system believes the reported size, formats the full space, and shows plenty of free room.

Nothing goes wrong at first. The damage appears once the total written passes the real capacity. Writes to addresses beyond the real flash have nowhere honest to go. Depending on how the firmware was configured, those writes are dropped, return garbage when read, or land on top of data that was written earlier. Files copied weeks ago turn into corrupted data, and the file system itself can be destroyed if its metadata gets overwritten.

What f3 says about the types

The open source f3 project (Fight Flash Fraud) is the best documented public tool for this problem. Its documentation describes the drive types f3probe reports: good; damaged, meaning seriously failing; limbo, which it calls the most common type of fake drive; wraparound, which it describes as rare "if existing at all"; and chain, another rare type. That correction matters. Popular explanations often say fake drives "wrap around" so that address 8 GB lands back on address 0. The f3 author's experience is that the common case is limbo, where blocks beyond the real flash simply do not hold what was written, and true wraparound is rare.

The f3 documentation also describes fake drives with an internal cache. In the author's example, the last file written read back fine straight away but was gone after the drive was disconnected and reconnected. A test that reads immediately after writing can be fooled this way.

Worked example 1: reading the f3probe result

The f3 documentation includes a real f3probe run on a fake drive. The numbers it reports are:

• Announced size: 15.33 GB, 32,155,648 blocks of 512 bytes.
• Usable size: 7.86 GB, 16,477,879 blocks.
• Module: 16.00 GB, which is 2 to the power 34 bytes.
• Probe time: 1 minute 13 seconds.
• Suggested fix: f3fix --last-sec=16477878 /dev/sdb.

Here is the arithmetic, so the numbers mean something:

• 32,155,648 blocks times 512 bytes is 16,463,691,776 bytes. f3 reports sizes in binary gigabytes (2 to the power 30 bytes), so that is 16,463,691,776 divided by 1,073,741,824, which is about 15.33.
• 16,477,879 blocks times 512 bytes is 8,436,674,048 bytes, about 7.86 binary gigabytes.
• The usable share is 7.86 divided by 15.33, about 0.512, or 51.2 percent, which is the figure the f3 author gives.
• The fix argument is the last good sector. Sectors are numbered from 0, so with 16,477,879 usable blocks the last one is number 16,477,878. f3fix rewrites the partition table so the one partition ends there.

The author also points out how little f3probe wrote: 2,158 blocks to find the real size, against at least 16,477,879 for a tool that must fill all the good memory. That speed comes from f3probe's model of how fake drives behave, which is why the author still labelled it experimental at the time of writing.

Worked example 2: why a partial test can miss a fake

Illustrative: a drive reports 1 TB but holds 64 GB, so 6.4 percent is real. A check of the first 32 GB passes; a check of 25 percent of the reported size fails once it passes 64 GB. As the f3 author notes, counterfeiters can include enough real flash to pass a partial test. f3write and f3read catch every fake but are slow; f3probe is fast because it writes chosen blocks across the whole reported space.

How to detect a fake drive

Warning signs include a price far below the market for that capacity, a huge capacity in a generic shell, and files that open right after copying but are corrupt after a replug. None is conclusive. The reliable check is to write known data to the entire reported space and read it back after a power cycle, which is what f3write and f3read do.

What f3fix does and does not do

f3fix does not repair the drive. It creates a partition covering only the usable region, so the operating system never writes past the real flash. The drive still reports the false total size to anything that looks at the whole device, so it will mislead the next computer that reformats it. For anything that matters, the honest fix is to return the drive and report the seller.

What changed from USB 2.0 to USB 3.x and USB4?

The bus generations and their names

The USB 2.0 specification was released on 27 April 2000 and defined high speed signalling at 480 Mbit/s. Later specifications added SuperSpeed lanes in parallel with the USB 2.0 wires. USB-IF's own page on USB 3.2 says the USB 3.2 specification "absorbed all prior 3.x specifications" and identifies three rates: 5 Gbps, 10 Gbps and 20 Gbps, the last using two lanes of 10 Gbps over a USB Type C cable. USB4, based on the Thunderbolt protocol specification contributed by Intel according to USB-IF, doubles the maximum aggregate bandwidth and, in Version 2.0, supports up to 80 Gbps over certified cables.

The naming has confused buyers for years, so in January 2024 USB-IF published data performance language guidelines. They set marketing names by signalling rate and say that terms such as USB 3.2, SuperSpeed Plus and Enhanced SuperSpeed are defined in the specifications but are not meant for product names or packaging.

A 5 Gbit/s link is about 625 MB/s before encoding and protocol overhead, and a 480 Mbit/s link is 60 MB/s before overhead. Real transfers are lower in both cases, and Bulk-Only Transport, which sends one command at a time, loses more than UASP does.

Why a fast bus does not make a fast drive

The bus is rarely the bottleneck. Write speed depends on how many dies program in parallel, so a one die 32 GB drive writes slower than a four die 256 GB drive on the same controller.

Why sustained writes slow down

Many drives write fast into an SLC mode cache, then drop to native TLC or QLC speed once it fills, while garbage collection and heat slow them further.

Worked example 3: copying 64 GB to a cached drive

Illustrative: a drive writes 300 MB/s into an 8 GB cache, then 30 MB/s. The first 8 GB take about 27 seconds; the other 56 GB take about 1,867 seconds. The 64 GB copy takes roughly 31.5 minutes, averaging about 34 MB/s, close to the sustained figure rather than the "up to 300 MB/s" on the box.

How do you erase a flash drive properly?

What NIST SP 800-88 Revision 2 says

NIST published SP 800-88 Revision 2, Guidelines for Media Sanitization, in September 2025. It defines three methods:

• Clear uses logical techniques over the normal interface to sanitize all user addressable locations, protecting against simple non invasive recovery. Overwriting with non sensitive data is the classic clear technique.
• Purge makes recovery infeasible even with state of the art laboratory techniques while leaving the media potentially reusable. NIST points to IEEE 2883 for acceptable purge techniques by media type, which can include overwrite, block erase and cryptographic erase through dedicated sanitize commands.
• Destroy makes recovery infeasible with state of the art laboratory techniques and leaves the media unusable.

On flash specifically, NIST is direct. It says that flash memory based devices with spare cells and wear levelling make it infeasible for a user to sanitize all previous data by overwriting, because the device cannot address every area where data has been stored through the normal read and write interface. It warns that people who carried magnetic disk overwrite habits over to flash "can be exposing their data to increased risk of unintentional disclosure". It says degaussing should not be used on flash, and that multiple pass overwrites, historically up to 39 passes, achieve very little on media with overprovisioning.

Why overwriting is unreliable on a thumb drive

The FTL explains it. When you overwrite a file, the new data goes to new pages and the old pages linger until garbage collection gets to them. When you overwrite the whole drive, you write every logical sector, but retired bad blocks, spare blocks and blocks the controller is holding back still contain old data, and you cannot address them.

The 2011 USENIX FAST paper "Reliably Erasing Data From Flash-Based Solid State Drives" measured this by reading flash chips directly after sanitizing. It included a USB drive alongside SSDs. For single file overwrite methods, between 0.57 and 84.9 percent of the data remained on the USB drive. Overwriting free space 100 times left 64 percent of the target data recoverable with 6 MB of free space and 53 percent with 500 MB free. The authors also noted that removable USB drives do not support the built in sanitize commands, because those commands are not part of the USB Mass Storage class. A full device overwrite reaches every logical sector, but it is still only a clear, not a purge.

What you can and cannot do on a USB thumb drive

SSDs offer controller level commands such as ATA Sanitize, NVMe Sanitize and NVMe Format with secure erase (see our post on NVMe and ATA sanitize). A USB mass storage device behind Bulk-Only Transport usually supports none of them. Many do not implement discard (TRIM) either, in which case blkdiscard fails. That leaves these routes:

For our own guidance on controls, see NIST 800-53 MP-6 media sanitization.

When physical destruction is the answer

Choose destruction when the drive is dead, held data whose disclosure would cause serious harm, or cannot be shown to have been encrypted from first use. Thumb drives cost little; their data often does not. NAND dies are small, so destruction must reduce the package itself, not just snap the board. A hammer that cracks the plastic shell but leaves a monolithic package intact has not destroyed the data. Use a shredder or disintegrator rated for solid state media, or a certified destruction service, and record serial numbers before and certificates after.

Step by step on Linux: identify, test, erase

The commands below run on any recent Linux distribution with util-linux, systemd's udevadm, cryptsetup and the f3 package installed. Several steps destroy data. Each destructive block has a warning and a device path check before it. Never copy a device name from this post; always use the one you confirmed.

1. Identify the drive before and after plugging it in

Run lsblk before you insert the drive, then again after, and compare. The f3 author recommends exactly this.

lsblk -o NAME,SIZE,TYPE,TRAN,RM,MODEL,SERIAL,MOUNTPOINTS
# insert the drive, then run it again
lsblk -o NAME,SIZE,TYPE,TRAN,RM,MODEL,SERIAL,MOUNTPOINTS

The new entry with TRAN usb and TYPE disk is the drive, for example sdb, with partitions such as sdb1 under it. Device level steps use the whole disk. Do not rely on the RM (removable) flag alone; some thumb drives report 0.

2. Confirm identity with udevadm and the kernel log

udevadm info --query=property --name=/dev/sdX | grep -E '^ID_(BUS|VENDOR|MODEL|SERIAL_SHORT|USB_DRIVER|VENDOR_ID|MODEL_ID)='
sudo journalctl -k -n 30

ID_BUS should be usb and ID_USB_DRIVER shows usb-storage or uas. The vendor and model strings were written by the factory tool, so they identify this drive but prove nothing about what is inside it. The kernel log shows the reported capacity and the link speed at enumeration.

3. Record the reported capacity

lsblk -bdno SIZE /dev/sdX

This prints the size in bytes that the firmware reports. Write it down with the serial number. It is the number f3 will test.

4. Device path check (run before every destructive step)

Set the device once and make the shell refuse to continue unless it is a whole USB disk with nothing mounted.

DEV=/dev/sdX   # replace with the device you confirmed in steps 1 and 2
[ "$(lsblk -dno TYPE "$DEV")" = "disk" ] || { echo "STOP: $DEV is not a whole disk"; exit 1; }
[ "$(lsblk -dno TRAN "$DEV")" = "usb" ] || { echo "STOP: $DEV is not on USB"; exit 1; }
lsblk -no MOUNTPOINTS "$DEV" | grep -q . && { echo "STOP: $DEV has mounted partitions"; exit 1; }
lsblk -o NAME,SIZE,MODEL,SERIAL "$DEV"
echo "Checked: $DEV is an unmounted USB disk. Compare the serial above with your notes."

Run this as a script or in a subshell so exit stops only the check. Unmount any partitions first with sudo umount /dev/sdX1.

5. Non destructive full test with f3write and f3read

This test writes 1 GB files into the free space of the mounted file system and then reads them back. It does not delete existing files, but it fills the drive, and on a fake drive writes past the real capacity can corrupt existing files. Back up anything you care about first.

f3write /media/$USER/LABEL
# unplug the drive, plug it back in, let it mount again
f3read /media/$USER/LABEL

Unplugging between the two commands defeats the drive cache problem the f3 documentation describes. f3read reports, per file, how many sectors were correct, changed, overwritten or corrupted, and a summary of the real data capacity. On an honest drive every sector is OK. Delete the .h2w files afterwards.

6. Fast whole device test with f3probe (destroys data)

Warning: the next command overwrites data on the drive. With --destructive, f3probe does not try to restore the blocks it writes. Without it, f3probe tries to put the original contents back, but the f3 author warns not to rely on that, because it fails if the probe crashes and may not restore some fake drives exactly. Back up first, run the device path check in step 4, then:

sudo f3probe --destructive --time-ops "$DEV"

The result line says whether the drive is good, damaged or a counterfeit, and the geometry block gives usable size, announced size and the f3fix command for a fake.

7. Make a fake drive usable for low value data with f3fix (rewrites the partition table)

Warning: f3fix rewrites the partition table, which removes access to existing data. Run the device path check again, then use the exact last sector f3probe printed:

sudo f3fix --last-sec=NNNNNNNN "$DEV"
sudo partprobe "$DEV"
sudo mkfs.vfat -n F3FIXED "${DEV}1"

Label the drive clearly as a counterfeit with its real size. Better still, return it.

8. Clear the whole drive by overwriting (destroys all data)

Warning: this erases every user addressable sector on the device. It meets NIST's clear method for user addressable space only. Run the device path check in step 4, then:

sudo wipefs --all "$DEV"
sudo dd if=/dev/zero of="$DEV" bs=4M status=progress conv=fsync

wipefs removes file system, RAID and partition table signatures so tools no longer recognise old structures; dd then writes zeros to every logical sector the drive reports. On a counterfeit drive dd writes past the real flash, which is another reason to destroy fakes instead of clearing them. To verify, read the device back and compare it with zeros:

sudo cmp -n "$(lsblk -bdno SIZE "$DEV")" /dev/zero "$DEV" && echo "All reported sectors read back as zero"

9. Encrypt for reuse, so the next disposal starts with key destruction

Warning: luksFormat destroys all data on the device. Run the device path check, then:

sudo cryptsetup luksFormat --type luks2 "$DEV"
sudo cryptsetup open "$DEV" usbcrypt
sudo mkfs.ext4 -L SECURE /dev/mapper/usbcrypt
sudo cryptsetup close usbcrypt

When this drive is retired, run the device path check and then destroy the key slots:

sudo cryptsetup luksErase "$DEV"

The cryptsetup documentation describes luksErase as erasing all keyslots, which makes the LUKS container permanently inaccessible unless you have a header backup. Follow it with the overwrite in step 8. This only protects data that was written after encryption was set up. If the drive ever held plaintext, treat it under the rows above for unencrypted drives.

10. Restrict which USB devices a Linux machine accepts

On machines that should not accept arbitrary storage, the kernel's USB authorization interface lets you stop new devices from being configured by default. As root:

cat /sys/bus/usb/devices/usb1/authorized_default
echo 0 | sudo tee /sys/bus/usb/devices/usb1/authorized_default

New devices on that host controller then stay unconfigured until authorized by writing 1 to their authorized file. In practice, use a policy daemon or your device management tool to express allow rules rather than doing this by hand, and test it on a spare machine first so you do not lock out your own keyboard.

11. Record what you did

For each drive, record the serial number, reported capacity, f3 result, method used (clear, encrypted reuse or destroy), date and operator. That record is what an auditor asks for, and it is how you notice a batch of suspect drives from one supplier.

Common mistakes

• Trusting reported capacity. The size your computer shows is whatever the firmware says. Test new drives, especially cheap high capacity ones, before you trust them with data.
• Testing only the first part of the drive. A counterfeit can contain enough real flash to pass a partial test. Use f3probe or a full f3write and f3read, with a replug before reading.
• Treating a quick format as erasure. A quick format writes a new empty file system and leaves the old data in place. Recovery tools find it easily.
• Using multi pass overwrite patterns on flash. NIST says these achieve very little on media with spare capacity. One full overwrite is a clear; more passes do not make it a purge.
• Adding encryption later and assuming old data is covered. Plaintext written before encryption can remain in spare and retired blocks.
• Using flash drives as the only backup. Drives get lost, wear out and fail abruptly when spare blocks run out. Unpowered drives slowly lose charge.
• Plugging in found drives. Research and CISA advice agree: people do it, and it is how unknown devices get onto your machines.
• Copying a device name from a guide. /dev/sdb on one machine is a system disk on another. Run the device path check every time.
• Buying without a batch test. Test a sample of every purchase with f3 before issue; one fake in a batch is a supplier problem.
• Breaking the plastic shell and calling it destroyed. The data lives in the NAND die, which may be inside a solid monolithic package.
• Reusing a drive you know is fake. f3fix makes it usable on one computer, but the drive still advertises the false size everywhere else.

FAQ

How is a USB flash drive made?

NAND dies are made on wafers, tested and graded, then packaged or bonded to a small board with a controller, crystal and USB connector. A mass production tool loads firmware, maps bad blocks, sets the reported capacity and serial number, and tests the drive before casing.

What is inside a USB flash drive?

NAND flash for the data, a controller with a USB PHY that runs the firmware, a clock crystal, passives, a circuit board and a Type A or Type C connector. Many small drives combine controller and NAND in one chip on board or monolithic package.

How do fake capacity USB drives work?

The firmware is configured to report more capacity than the flash holds. The computer formats the full reported size, and data written beyond the real capacity is lost or corrupts earlier data. The f3 project describes "limbo" as the most common type of fake drive.

How can I check if my USB flash drive is fake?

On Linux, run f3probe on the whole device for a fast result, or run f3write and then f3read on the mounted drive, unplugging and replugging in between. On any system, write data to the entire reported space and read it all back after a power cycle.

Why does my USB drive slow down during large copies?

Many drives write fast into a small SLC mode cache, then drop to the native TLC or QLC speed once it fills. Garbage collection and heat slow them further.

Is USB 3.2 Gen 1 the same as USB 3.0?

Both refer to the 5 Gbit/s rate. USB-IF says the USB 3.2 specification absorbed earlier 3.x specifications, and its guidelines ask vendors to label this rate USB 5Gbps on products rather than using specification names.

Does formatting a USB drive erase the data?

A quick format does not; it writes a new empty file system. A full overwrite of the whole device clears user addressable data but cannot reach spare or retired blocks, which NIST SP 800-88 Revision 2 says makes overwriting insufficient to sanitize all previous data on flash.

How do I securely wipe a USB flash drive?

For low sensitivity reuse, overwrite the whole device. For confidential data, encrypt the drive from first use and destroy the keys before overwriting at disposal. For high value data, failing drives or drives of unknown history, physically destroy the drive with equipment rated for solid state media.

Can a USB flash drive's firmware be changed?

On many controllers, yes. Factories load firmware over USB with mass production tools, and published research has shown one widely used controller family could be reprogrammed from a computer. Host side controls such as Linux USB authorization limit what an unknown device can do.

Where Safeguard fits, honestly

Safeguard does not test flash drives, inspect controller firmware, scan USB devices for malware, generate hardware bills of materials or manage endpoints, and nothing in this post depends on it. Its models are single-purpose security models for software. The fit is indirect. The software around removable media is ordinary software: the imaging scripts that build bootable drives, the kiosk and provisioning tools that flash and test drives in bulk, the internal dashboards that track drive inventory, and the open source tools they bundle, such as f3, util-linux and cryptsetup. Safeguard scans those repositories, container images and SBOMs for known vulnerable components and shows which projects contain a given version. That helps you find, and with approval fix, known vulnerable dependencies in the tooling you rely on to test and erase drives; autonomous remediation ships switched off by default.

A thumb drive's firmware is outside anything your team builds, but the tools you use to provision, test and erase drives are software you do maintain, and they pull in open source components like any other project. Keeping those dependencies patched is ordinary supply chain hygiene, and it is the part of this topic where Safeguard can help directly.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session asked to fix a lodash CVE: it reads the finding and advisory, asks before any command that changes something, edits package.json, runs npm install and npm test with approval, and pushes nothing. The same flow fits an internal drive provisioning or inventory tool your team maintains.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with its device code and scans from the terminal. That suits teams who build imaging or kiosk images, with tools such as f3 and cryptsetup inside, on their own hardware.

Click through it at your own pace, or open it full screen.

The third demo is a real Android session: send work to a computer running the CLI and approve each command on the phone with Allow once, Allow for turn or Deny. Nothing destructive runs without a person approving it, which is the same discipline the device path checks above apply to erase commands.

Click through it at your own pace, or open it full screen.

To try it on your own repositories, download Safeguard and follow the CLI documentation.

Quick check

Sources

• NIST CSRC, SP 800-88 Rev. 2, Guidelines for Media Sanitization (September 2025)
• NIST, SP 800-88 Rev. 2 full text (PDF)
• f3, Fight Flash Fraud documentation
• f3 documentation, Usage: f3write, f3read, f3probe and f3fix
• f3 documentation, Introduction
• f3 documentation, History
• USB-IF, USB 3.2 Specification
• USB-IF, USB4 Specification
• USB-IF, USB Data Performance Language Usage Guidelines (January 2024, PDF)
• USB-IF, USB 2.0 Specification
• USB-IF, Universal Serial Bus Mass Storage Class Bulk-Only Transport Revision 1.0 (PDF)
• USB-IF, Mass Storage Class Specification Overview 1.4
• USB-IF, USB Attached SCSI Protocol (UASP) v1.0
• USB-IF, Document library
• Linux kernel documentation, Authorizing (or not) your USB devices to connect to the system
• Linux kernel documentation, USB support
• Linux kernel documentation, NAND Error-correction Code
• lsblk(8) manual page
• udevadm(8) manual page
• wipefs(8) manual page
• blkdiscard(8) manual page
• cryptsetup(8) manual page
• cryptsetup-erase(8) manual page
• Wei, Grupp, Spada and Swanson, Reliably Erasing Data From Flash-Based Solid State Drives, USENIX FAST 2011 (PDF)
• Tischer et al., Users Really Do Plug in USB Drives They Find (PDF)
• CISA, Using Caution with USB Drives
• Kioxia America, BiCS FLASH 3D flash memory

Last reviewed: 25 October 2026.