Testing Fake 2TB thumb drive

Ordered a 2TB thumb drive to use for backups off Amazon. It was only 30$ so I gave it a shot. I should have known as Sandisks are in the hundred or more dollar range.

The drive: https://www.amazon.com/gp/product/B09TPDPDW8/ref=ppx_yo_dt_b_asin_title_o03_s00?ie=UTF8&psc=1

Anyhow, it was acting suspicious off the bat. It came with NTFS and I tried to immediately put ext on it. I loaded it on my NAS but it couldnt mount it (that could just be my NAS not liking NTFS). So I overwrote it with ext4 and it wouldnt mount.

I even tried to partition it with GPT and MBT. I was able to get it to write ext4 to it. However it couldn’t mount it. I would get this error.

[85359.229884] EXT4-fs (sdg1): error loading journal

So I went online to check for tools to check real USB drive sizes and came across a tool called f3.

f3: https://fight-flash-fraud.readthedocs.io/en/latest/introduction.html

It comes with 2 tools that are important

f3write, f3probe, and a few others. f3write is for testing drives that can mount, it writes to a mount point. f3probe is for drives that can’t mount, it writes to a device.

This was all done on my ReadyNAS 6.10 (intel version) that uses Debian base linux system. Not sure if this will work on an arm version; but it worth a try if you have it. When I apt install f3, it was missing f3probe which is what I need. So I looked into getting a docker setup, that way I can install it without any problems as it will all be containerized.

Step 1. Install docker on my Readynas. There is a free app that you can install on the Readynas called “Docker CE CLI”. Install it and then you have access to the “docker” commands.

Step 2. Identify what the device file for your drive is.

lsblk

cat /proc/partitions

I see that my drive is /dev/sdg. We know its the write device because its the last listed device and its also /dev/sdg. You can also run dmesg and see what device the usb loaded into:

dmesg | grep -A10 usb

Look for the messages that refer to the usb loading up and then then the drive device coming up

[70327.204021] usb 2-3: new high-speed USB device number 3 using ehci-pci [70327.319309] usb-storage 2-3:1.0: USB Mass Storage device detected [70327.319561] scsi host7: usb-storage 2-3:1.0 [70328.320665] scsi 7:0:0:0: Direct-Access General UDisk 5.00 PQ: 0 ANSI: 2 [70328.321672] sd 7:0:0:0: Attached scsi generic sg6 type 0 [70328.322248] sd 7:0:0:0: [sdg] 4096000000 512-byte logical blocks: (2.10 TB/1.91 TiB) [70328.322999] sd 7:0:0:0: [sdg] Write Protect is off [70328.323014] sd 7:0:0:0: [sdg] Mode Sense: 0b 00 00 08 [70328.323640] sd 7:0:0:0: [sdg] No Caching mode page found [70328.323644] sd 7:0:0:0: [sdg] Assuming drive cache: write through [70328.329546] sdg: sdg1 [70328.332884] sd 7:0:0:0: [sdg] Attached SCSI removable disk [80103.309662] sdg: sdg1

Step 3.

Launch into the f3 container. If you have never downloaded this container, It will first download it <- thats one of the beautiful aspects of docker. Note we also tell it that we want access to the /dev/sdg device.

docker run -it --rm --device /dev/sdg peron/f3 bash

Step 4.

Now you are in docker, check that you still have the same partitions.

I was able to see all of my partitions (so perhaps –device /dev/sdg was not necessary), so we have to becareful with the next command. Do not accidentally typo and put in one of your raids devices.

f3probe --destructive --time-ops /dev/sdg

Wait this out and explore the results. For me it took like 15 minutes.:

WARNING: Probing normally takes from a few seconds to 15 minutes, but it can take longer. Please be patient.

Bad news: The device `/dev/sdg' is a counterfeit of type limbo

You can "fix" this device using the following command: f3fix --last-sec=104972831 /dev/sdg

Device geometry: Usable size: 50.05 GB (104972832 blocks) Announced size: 1.91 TB (4096000000 blocks) Module: 2.00 TB (2^41 Bytes) Approximate cache size: 1.00 MB (2048 blocks), need-reset=no Physical block size: 512.00 Byte (2^9 Bytes)

Probe time: 5'25" Operation: total time / count = avg time Read: 263.5ms / 4212 = 62us Write: 5'24" / 53412 = 6.0ms Reset: 0us / 1 = 0us

Step 5. Draw your conclusion and exit

In our case we see this drive is clearly only 50G and not the reported 2TB

If you want to fix the reporting of this drive being 2TB and report its correct size of 50GB run the command:

f3fix --last-sec=104972831 /dev/sdg

Error: Error informing the kernel about modifications to partition /dev/sdg1 -- Permission denied. This means Linux won't know about any changes you made to /dev/sdg1 until you reboot -- so you shouldn't mount it or use it in any way before rebooting. Error: Partition(s) 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64 on /dev/sdg have been written, but we have been unable to inform the kernel of the change, probably because it/they are in use. As a result, the old partition(s) will remain in use. You should reboot now before making further changes. Drive `/dev/sdg' was successfully fixed

According to the output we need to reboot the system (or take out the flash drive and use it anywhere else) to see the new correct size. Also we can’t forget to repartition and reformat with a correct filesystem.

Now we can exit.

exit

docker ps -a

The above command will show the f3 container is no longer running as we used –rm command. If we hadn’t when we exited it would still be running in the background and we would have to kill it with docker stop <container image>

infotinks

My Notes, Articles & Guides for Linux, Windows and Networking.

Testing Fake 2TB thumb drive

Leave a Reply Cancel reply