Slashdot Mirror
FTDI Reportedly Bricking Devices Using Competitors' Chips.
janoc writes It seems that chipmaker FTDI has started an outright war on cloners of their popular USB bridge chips. At first the clones stopped working with the official drivers, and now they are being intentionally bricked, rendering the device useless. The problem? These chips are incredibly popular and used in many consumer products. Are you sure yours doesn't contain a counterfeit one before you plug it in? Hackaday says, "It’s very hard to tell the difference between the real and fake versions by looking at the package, but a look at the silicon reveals vast differences. The new driver for the FT232 exploits these differences, reprogramming it so it won’t work with existing drivers. It’s a bold strategy to cut down on silicon counterfeiters on the part of FTDI. A reasonable company would go after the manufacturers of fake chips, not the consumers who are most likely unaware they have a fake chip."
Update: 10/24 02:53 GMT by S : In a series of Twitter posts, FTDI has admitted to doing this.
Now consumers are becoming aware that there's a massive counterfeiting problem and can be better educated to ask their vendors "Hey, is my device legit?" I certainly had no idea that this was going on.
If you were me, you'd be good lookin'. - six string samurai
A component manufacturer is unhappy that someone else is using his product id so he puts code in a driver that sets the product id to zero. This prevents the fake component being recognized by his driver or any other driver. The license for the driver explicitly states that using the driver with a fake component may irretrievably damage the component.
If the component manufacturer doesn't want the fake product to work with his driver he can code his driver to ignore the fake. Modifying the product id to brick the component is another matter entirely.
This doesn't hurt the people who created the fake, or even the people who purchased the fake and used them in their manufacturing. It only hurts end users who have done nothing except purchase a product in retail channels. Deliberately destroying equipment because it uses a fake component goes to a whole new level of nastiness.
Most people won't have any technical knowhow to understand why their device bricked, just that it bricked. Bricked devices will be blamed on the device manufacturer not the chip supplier.
Device manufacturing companies may just avoid FTDI chips outright. This is especially true if some suppliers are mixing the real chips with the counterfeit chips.
Worse, since it's coming through Windows Update, the engineers working on Windows Update might outright blacklist FTDI. And Microsoft would be at least partially liable for any bricked device, which would make their lawyers a bit uncomfortable. I wouldn't be surprised to see Microsoft release a patch in the future to automatically unbrick the affected devices.
"If a nation expects to be ignorant and free in a state of civilization, it expects what never was and never will be."
Intent.
Whose fault is it that FTDI is intentionally destroying other people's property? FTDI's. The ends don't justify the means.
This all goes out the window the minute you write code that intentionally does harmful things to your hardware. And it would be fairly easy to prove said intent: no driver should be mucking with USB PIDs ever, especially not when they've proven that the hardware in question isn't theirs. A driver that says, "Okay, this hardware clearly isn't mine, let's go break it" is malicious software.
This is shit that Nintendo flashcart vendors do.
Can you tell, by merely looking at it, whether a given device is using GenuineFTDI(TM)(R)(C)(BFD) chips, or whether it's a counterfeit? Can you tell by using whatever the Windows equivalent of lsusb is? No? Then there is a random, non-trivial chance that plugging in your serial-ish device will either:
Thus, in the mind of the user, FTDI == Flaky. And Flaky == Avoid.
Congratulations, FTDI. Ten points for avoiding your feet, but minus several million for shooting yourself straight in the head.
Editor, A1-AAA AmeriCaptions
Except the chip wasn't, as you put it, "killed." The chip is still fully functional with a driver that will support it.
The chip was pretty killed. With a PID of 0, Windows, Mac OS, and Linux wouldn't recognize it. It's theoretically possible to fix the PID, but most end users wouldn't really know how to do that.
Why should FTDI support chips it didn't make?
They shouldn't have to support chips that they didn't make, but at the same time, they shouldn't brick* chips that they didn't manufacture.
What FTDI really should have done is to set a generic PID for the chip type. That way, the chip would no longer use the FTDI driver, and they wouldn't have to support it.
*I use "brick" in the sense that using their Windows driver to set the PID to 0 makes the chip no longer function in other OSs, either. I am aware that an unbricking procedure is available.
They don't grade fathers, but if your daughter's a stripper, you fucked up. --Chris Rock
However, when you find a contract manufacturer and ask them to make 100,000. You require an XYZ, Inc. ABC123 chip and ask the manufacturing contractor to source it. Unbeknown to you, they obtain a counterfeit source. The chip is virtually identical externally, and functionally very similar, so that your product passes validation testing.
You as the device designer and seller may have no idea that you have fake chips on your device. Perhaps, your RMA rate is higher than you expected due to chip failures, or perhaps you are getting a lot of bug reports from the field which are not reproducible on your prototypes, but are on production devices.
This isn't the first time a USB->UART vendor has taken vigilante action against fakes. The vendor Prolific had major problems with low-quality, buggy and slow fake chips, causing major support headaches for customers and themselves. I believe they ended up discontinuing their main product and replacing it with an incompatible version, while poisoning the drivers so that they would BSOD/Kernel panic if they detected a fake chip.