I wrote a Linux/BASH tester [0] for this recently that includes instructions on how to create simulated fake devices:<p>To create simulated (2GiB) fake devices<p><pre><code> fallocate -l 1G fff_test.flash
DEV=$(losetup --show --find fff_test.flash); echo $DEV
DEVNUM=$(stat -c %Hr:%Lr $DEV); echo $DEVNUM
</code></pre>
With wrap-around sectors:<p><pre><code> dmsetup create --concise "fff_wrap,,,,0 2097152 linear $DEVNUM 0, 2097152 2097152 linear $DEVNUM 0"
</code></pre>
With silently dropped writes:<p><pre><code> dmsetup create --concise "fff_drop,,,,0 2097152 linear $DEVNUM 0, 2097152 2097152 zero"
</code></pre>
To test:<p><pre><code> fake_flash_finder.bash /dev/mapper/fff_wrap
Capacity mismatch at LBA 2097152, data wrapped around to block 0. Size is most likely really 1073741824 bytes
fake_flash_finder.bash /dev/mapper/fff_drop
Capacity mismatch at LBA 2097152, data does not match what was written. Size is most likely really 1073741824 bytes
</code></pre>
To wipe the device if repeating tests:<p><pre><code> dd if=/dev/zero of=/dev/mapper/fff_wrap bs=64M status=progress conv=fdatasync
dd if=/dev/zero of=/dev/mapper/fff_drop bs=64M status=progress conv=fdatasync
</code></pre>
To remove the device:<p><pre><code> dmsetup remove fff_wrap
dmsetup remove fff_drop
losetup --detach "$DEV"
rm fff_test.flash
</code></pre>
[0] <a href="https://salsa.debian.org/-/snippets/732" rel="nofollow">https://salsa.debian.org/-/snippets/732</a>
This appears to be a cross-platform version of h2testw, which is widely recommended for finding the true capacity of a storage device. Another common recommendation is ChipGenius and the various manufacturer-specific tools, which can read the real ID of the NAND ICs, that AFAIK is beyond the ability of nearly all the fakers to change:<p><a href="https://blog.elcomsoft.com/2019/01/identifying-ssd-controller-and-nand-configuration/" rel="nofollow">https://blog.elcomsoft.com/2019/01/identifying-ssd-controlle...</a><p>From the research I've done (mainly related to data recovery), the NAND flash industry seems extremely secretive and shady in many ways --- from the near-zero availability of public datasheets, to the many rebrands/"reclaimed"/recycled part sources, to what they're doing to SLC and higher-reliability technologies. There are also ways to determine how worn-out a NAND IC is, but even those may be reversible with the right physical treatments.
Somebody should make this up as a handheld device. Something that you can use to inspect new items, and retailers can use to inspect what their suppliers are sending them.<p>Can a Flipper Zero be programmed for this? It connects to Micro SD cards and USB ports.
So this always overwrites the device to test it, and I was wondering if that was necessary (say, you had started using it). Presumably you only need to write at most N+1 blocks, where N is the number of blocks the device <i>actually</i> has.l, in order to detect exaggeration. But at that point the fake device will have overwritten all of your files anyway, even if they were theoretically on different blocks (of the exaggerated inventory). So I guess the minimum harm to test a device is to hash all your files, then write at most N+1 (unused) blocks, stopping after each to check if any of your files got harmed. In theory that risks at most one block...<p>Of course, it's better to back up the suspect one.
How long does this tool take to verify a real drive?<p>"it only writes what’s necessary to test the drive"<p>How does that actually work, wouldn't that mean the whole stated capacity would have to be written?
Does anyone know how robust it is? Could sophisticated malicious firmware detect that it's being probed by f3 and fake reads such that f3 thinks everything is OK?
As stated somewhere else, flash fraud has already been committed when you start testing.<p>Once you grab your dubious device, the seller has already got your bucks in exchange of a fake device.<p>You've been already and effectively cheated when those flash devices are being tested against cheats.