How to tell if you have a fake sd card

I've been given some flash drives that appear to be fake. The silk screen says 64 gigs, and they show up as 64 gigs to the OS.

However if you attempt to write any files larger than 4 gigs the file becomes corrupted.

How can you quickly tell if a flash drive / sd card is fake, and what the actual size is?

Side note:
I know about h2testw, but it is in german, and I find it extremely difficult to use. I'm looking for an alternative program, or a way to do this from the command line.
Any platform is fine.

spuder

Posted 2013-08-14T01:37:17.297

Reputation: 8 755

5Your conclusion is most likely incorrect. They're not fake, they're just formatted with a filesystem that doesn't support files over 4GB. Most flash drives are shipped this way. – David Schwartz – 2013-08-14T08:09:08.640

Actually, I'd expect the OS to spit out some error message or warning, rather than just writing a corrupt file (but this might be down to the individual program). At least in Windows Explorer you can't simply drag&drop too large files on a FAT32 drive. – Mario – 2013-08-14T08:28:29.873

Not neccessarily - my experience is exactly this - 128 fake disks with 4 gigs flash. – davidgo – 2013-08-14T08:28:51.263

exFAT supports files up to 16EiB in size. But obviously not on a 4GB card. – Ignacio Vazquez-Abrams – 2013-08-14T10:43:38.377

Answers

Open the card device directly, and write 0x00 to it up to the capacity on the label. Write 0x55 0xff 0xaa to the first three bytes, and look for any non-0x00 byte up to the capacity on the label. If you find one, the card is either fake or defective. If you find 0x55 0xff 0xaa... definitely fake.

dd if=/dev/zero of=/dev/mmcblkX bs=16M count=...
echo -e -n '\x55\xff\xaa' > /dev/mmcblkX
hexdump /dev/mmcblkX

Ignacio Vazquez-Abrams

Posted 2013-08-14T01:37:17.297

Reputation: 100 516

Some fake drives don't fake the first N bytes of the drive, for some N, since they don't want to destroy filesystem metadata. – user253751 – 2016-03-23T03:05:43.277

sudo echo -e -n '\x55\xff\xaa' > /dev/sdc1 Output: bash: /dev/sdc1: Permission denied Drive mounted and ready to be used. Why this could be happened? Which command should I use instead? – VladSavitsky – 2019-05-22T19:14:22.703

This is quite clever – Mark Henderson – 2013-08-14T01:48:26.573

3Would it be possible to have more details ? Like why 0x55 0xff 0xaa and not an other sequence ? I'm quite interested. – Levans – 2013-08-14T07:45:20.553

@Levans its because 0x55 = 01010101 0xff = 11111111 0xaa = 10101010 – exussum – 2013-08-14T08:14:59.073

though im not sure why if you find what you write it would be fake – exussum – 2013-08-14T08:23:36.137

4It's just a specific pattern you can find again. The idea is rather simple: first you set everything on the drive to 0, which means all bits should be 0. Then you only modify the very first 3 bytes. If all other bytes stay 0, they're indeed there. If other bytes change as well, the drive is defective (didn't write or read properly). If other bytes are the same, the drive is in "looping" mode, meaning, if you write over the end (which is closer to the start than expected), it will start writing at the beginning again. – Mario – 2013-08-14T08:25:42.880

ah when i first read i assumed it was at the start, the looping makes more sense – exussum – 2013-08-14T20:36:34.857

I believe this is also worth mentionning a replacement for h2testw: f3.

The documentation is at:

https://fight-flash-fraud.readthedocs.io/en/stable/

On my system:

$ sudo apt-get install f3

The most basic usage is simply:

$ sudo f3probe --destructive --time-ops /dev/mmcblk0

$ sudo f3probe --destructive --time-ops /dev/sdb

depending on how your system see the sdcard reader.

On my system this reports:

F3 probe 6.0
Copyright (C) 2010 Digirati Internet LTDA.
This is free software; see the source for copying conditions.

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

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

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

Device geometry:
*Usable* size: 3.75 GB (7860035 blocks)
Announced size: 15.62 GB (32768000 blocks)
Module: 16.00 GB (2^34 Bytes)
Approximate cache size: 1.00 MB (2048 blocks), need-reset=no
Physical block size: 512.00 Byte (2^9 Bytes)

Probe time: 1'11"
Operation: total time / count = avg time
Read: 336.9ms / 4260 = 79us
Write: 1'10" / 57554 = 1.2ms
Reset: 164.9ms / 1 = 164.9ms

If you cannot use f3probe, you'll have to use the legacy approach (f3write followed by f3read):

$ f3write /media/malat/NEW\ VOLUME
Free space: 15.61 GB
Creating file 1.h2w ... OK!
Creating file 2.h2w ... OK!
Creating file 3.h2w ... OK!
Creating file 4.h2w ... OK!
Creating file 5.h2w ... OK!
Creating file 6.h2w ... OK!
Creating file 7.h2w ... OK!
Creating file 8.h2w ... OK!
Creating file 9.h2w ... OK!
Creating file 10.h2w ... OK!
Creating file 11.h2w ... OK!
Creating file 12.h2w ... OK!
Creating file 13.h2w ... OK!
Creating file 14.h2w ... OK!
Creating file 15.h2w ... OK!
Creating file 16.h2w ... OK!
Free space: 0.00 Byte
Average writing speed: 8.48 MB/s

$ f3read /media/malat/NEW\ VOLUME
                  SECTORS      ok/corrupted/changed/overwritten
Validating file 1.h2w ... 2097152/        0/      0/      0
Validating file 2.h2w ... 2097152/        0/      0/      0
Validating file 3.h2w ... 2097152/        0/      0/      0
Validating file 4.h2w ... 1533687/   563465/      0/      0
Validating file 5.h2w ...       0/  2097152/      0/      0
Validating file 6.h2w ...       0/  2097152/      0/      0
Validating file 7.h2w ...       0/  2097152/      0/      0
Validating file 8.h2w ...       0/  2097152/      0/      0
Validating file 9.h2w ...       0/  2097152/      0/      0
Validating file 10.h2w ...       0/  2097152/      0/      0
Validating file 11.h2w ...       0/  2097152/      0/      0
Validating file 12.h2w ...       0/  2097152/      0/      0
Validating file 13.h2w ...       0/  2097152/      0/      0
Validating file 14.h2w ...       0/  2097152/      0/      0
Validating file 15.h2w ...       0/  2097152/      0/      0
Validating file 16.h2w ...      16/  1273792/      0/      0

  Data OK: 3.73 GB (7825159 sectors)
Data LOST: 11.88 GB (24905929 sectors)
      Corrupted: 11.88 GB (24905929 sectors)
Slightly changed: 0.00 Byte (0 sectors)
    Overwritten: 0.00 Byte (0 sectors)
Average reading speed: 3.20 MB/s

malat

Posted 2013-08-14T01:37:17.297

Reputation: 981

Given that the problem shows up at filesizes of 4GB what file system is in use on the card?

If it is FAT32 the problem you are seeing might be caused by FAT32 having an upper file size limit of 4GB. See http://en.wikipedia.org/wiki/File_Allocation_Table#FAT32 for more information

On Windows you can identify the file system by right clicking on the device in "My Computer" and selecting properties. Look at the "file system" field.

Carcophan

Posted 2013-08-14T01:37:17.297

Reputation: 161

I recently found a program Scanflash - http://www.shikadi.net/scanflash/ which scans a disk under Linux, finds out if its fake and partitions the useable areas. It takes a long time though. (Like a full day on a 128 gig fake flash)

davidgo

Posted 2013-08-14T01:37:17.297

Reputation: 49 152