Testing for Counterfit Flash Drives

[emw129]

There is a growing problem in the Flash Drive Market being flooded with Counterfiet Flash drives that have had their firmware dongled to report more storage than they really have.  This is a huge problem for Flash Drives being sold on Amazon, eBay, and other online stores. 

Usually the problem isn't revealed with small flash drives like 8G, 16G or 32G, but as soon as you try to purchase Flash Drives bigger than this, counterfiet flash drives everywhere.  Even though the Technology exists to make a true Flash Drive as large as 2T Bytes, many are reporting far more storage than they really have.

Does anyone know where I can find documentation on how to communicate with a Flash Drive at the Machine code level and force writing and reading at specific memory locations?  If I could test a Flash Drive by writing data at the beginning, middle, end and at every 1/4 memory point, I can probably do a very quick test to see of the flash drive is counterfiet or not.  Otherwise I will have to write the full storage capacity of the Flash drive, making the test last for a great many hours.

What I've found so for as that flash drives are programmed through firmware to write in a way that all memory cells are written to an equal number of times so when the flash drive wears out, all memory goes at the same time.  However testing has reavealed most flash drives can survive 100's of petacycles and still store data and read it back many times more.

[aputman]

You don't mention Labview anywhere in your post.  So I can only assume that since this was posted in the Labview forum that you want to accomplish this task using Labview software.  

I don't know of any built-in functionality within Labview that can write to a certain sector of a drive.  Your "best" solution (and I put that in quotes because this probably isn't the best solution) may be to write/find a DLL that does have this low-level ability and make a call to that DLL within Labview.  

[billko]

I'm guessing that any drive diagnostic software should be able to expose something like this.

[emw129]

Actually it does not, standard diagnostics only looks at what the flash drive firmware is reporting as its size, even if it is lying about it.  The only real test is to write and verify at key locations on the flash drive.  The fastest way would be to write at the and before the halfway point of full storage, and again at the 1/4 points, then go back and read those hand full of locations to see if any of them over wrote the other.  All memory is constructed in powers of 2, even the counterfit ones, if a read error occures, then you know something is wrong.

Unfortuantely the flash drive firmware controls the actual location of each write location, and it is that control that I'm trying to aquire.  But this is at the low level machine code communications that lays behind the firmware.

[RTSLVU]

Seems like a lot of work when the real solution is to only buy name brand flashdrives from a reputable source instead of counterfeits from China through Amazon.

Seriously, 64GB Sandisk flashdrives are only $16 and 256GB Sandisk Ultra flashdrives are only $50 at Bestbuy

http://www.bestbuy.com/site/searchpage.jsp?_dyncharset=UTF-8&_dynSessConf=&id=pcat17071&type=page&sc....

[rolfk]

I would have to agree with the post saying that there is not much money to gain from such a test application considering what a modern 64G or 128G flash driver from a reputable resource costs.

And this whole idea about testing beyond the firmware of the flash drive itself is most likely doomed. The firmware provides a standard interface that the OS driver interfaces too and even going on that level is a major hassle as you have to directly go and put in a kernel device filter driver that can hook in the datapath of the standard system driver in order to intercept that data path. However this still passes through the standard firmware interface so the firmware is free to lie about anything it wants to.

While each firmware also has a factory test interface, this interface is both proprietary, and safe from some people with state sponsored resources, only known to the actual manufacturer self. So you would have to write a manufacturer specific kernel filter driver for each drive manufacturer and still couldn't be sure that even that interface wasn't patched up to lie just as much about its real resources.

So there are probably functions in the firmware manufacturinig test interface that could write to specific locations but they are in a proprietary interface that is not openly documented and highly manufacturer specific. And if I would be in the business of producing counterfeited products I would actually simply make these interfaces return an error code, so your test app still just can conclude that it can't access the interface for some reasons, which could be special security or a misdetection of the device type and therefore trying to access the wrong manufacturer specific interface. Many legitime producers of hardware nowadays protect their production and test interfaces in their hardware by extra passwords or hashkey sequences that you have to match exactly before those interfaces will produce anything else than an error code or pure garbage as return value. 

[emw129]

There are many merchants on Amazon, eBay, shopify, etc., ... that are trying to source flash drives from China and directly from manufacturers.   Many of which are counterfiet, these merchants are constantly finding themselves selling worthless low capacity Thumb drives reporting large capacity storage.  A huge problem for these merchants and for Amazon, eBay, shopify, etc., ...

Some of these Manufacturers might even be using brand names like Sandisc, Kestone, etc., ...  But are nothing more than conterfiets.

In the older days of programming, there were some simple comands in programming that permitted writing to specific locations on mass storage devices like floppy disks and hard drives.  But I've long forgotten what those commnds were (simular to peek and poke).  In LabView is there a simular command?

[Blokk]

---

@emw129 wrote:

There are many merchants on Amazon, eBay, shopify, etc., ... that are trying to source flash drives from China and directly from manufacturers.   Many of which are counterfiet, these merchants are constantly finding themselves selling worthless low capacity Thumb drives reporting large capacity storage.  A huge problem for these merchants and for Amazon, eBay, shopify, etc., ...

Some of these Manufacturers might even be using brand names like Sandisc, Kestone, etc., ...  But are nothing more than conterfiets.

In the older days of programming, there were some simple comands in programming that permitted writing to specific locations on mass storage devices like floppy disks and hard drives.  But I've long forgotten what those commnds were (simular to peek and poke).  In LabView is there a simular command?

---

I wonder if you really read and understood what rolfk wrote in his post?

[Minions]

It is possible too that this is a binning exercise gone awry.  We know that devices are tested at the max speed first to see if they meet those specs to bring in a higher margin, then those that fall out get tested at slower speeds with lower margins.  Memory is known to have inherent issues as the sizes get larger and the feature sizes get smaller.  Many manufacturers offer spare cells that get mapped into slots that do not work properly.  If the die of these devices is truly the size recorded in the firmware, then it could be a testing/mapping issue.  Each manufacturer controls their mapping codes for accessing spare locations and will be reluctant to just give out that proprietary information.

[emw129]

I've actually talked to manufacturer suppliers at Alibaba and they admit they are selling 8GB Thumb Drives as if they were 64GB or 128GB Thumb Drives.  Because they believe that their customers will never use more than 8GB...  While thinking they are getting something bigger.

That is why I no longer sell Thumb drives from anyone.  Until I can find a way of proving that a 128GB Thumb drive is actually 128GB.