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.
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.
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