Submitted by The FTDI FT232 chip is found in thousands of electronic baubles, from Arduinos to test equipment, and more than a few bits of consumer electronics. It’s a simple chip, converting USB to a serial port, but very useful and probably one of the most cloned pieces of silicon on Earth. Thanks to a recent Windows update, all those fake FTDI chips are at risk of being bricked. This isn’t a case where fake FTDI chips won’t work if plugged into a machine running the newest FTDI driver; the latest driver bricks the fake chips, rendering them inoperable with any computer.
Did microsoft did this on purpose, what’s their incentive ? Who sells the real chips ?
It’s not Microsoft who did this, it’s FTDI who did it. They simply provided Microsoft with the drivers and Microsoft wasn’t made aware of this. And yes, FTDI does this intentionally, the code deliberately checks if it’s official FTDI-product, a counterfeit or an otherwise compatible device and then bricks* it if it isn’t FTDI.
* Technically it’s not a hard brick, it’s a soft brick. FTDI’s software changes the firmware so that the device reports USB ID and VENDOR as 0 and thus renders it unuseable. You could recover if you changed the IDs back, but for that you need special tools. In practice it is a hard brick for most people.
Edited 2014-10-29 17:40 UTC
I understand their frustration. I’m not sure what I would have done in their shoes, but changing the USB ID is too harsh. Especially considering that many people bought the fakes, thinking they were real. The end user shouldn’t be punished for the deception.
I would hope that anyone effected by this would return it to the vender and complain, but return policies may have expired.
The “ethical” thing for FTDI to have done would have been to program their drivers to cease working with the clones, but stop short of actually bricking them. Damaging property for revenge is unethical and probably illegal, so it’s good to hear they “fixed” it!
Edited 2014-10-29 18:59 UTC
Well, that’s kind of what they did … They updated the device to prevent it from identifying itself as an official chip.
I’m not sure if it was possible to prevent it from working without “bricking” the chip.
If there was a way to identify it without modifying the USB ID, then that’s what they should have done, but to a “normal user” the effect would have been the same. They wouldn’t be able to use their formally working device with their recently updated PC.
In reading the link posted by jburnett, it seems the answer is yes, they could have exploited the buffering difference without causing it to get bricked. They engineers clearly knew what they were doing, and they chose to brick it.
It think it makes quite a bit of difference. If a peripheral works on one machine, but not other, I conclude that something is wrong on the machine such that I can take the steps to fix it. However if the peripheral stops working all together and wont work on other machines, I’m lead to believe the peripheral is faulty and forced to buy a new one and never learn that in fact updated FTDI drivers are responsible.
I’ll admit it’s clever, who would suspect that FTDI would actually hack into their peripheral’s chips to brick them?
Edited 2014-10-29 19:35 UTC
Not to mention it’s probably illegal for them to deliberately “destroy” peoples property.
And potentially in violation of the term of Microsoft’s driver signing program.
Interesting. I wasn’t even aware such a thing was possible. I always thought the USB ID/VENDOR was hard-coded and that firmware had no influence over the basic USB handshaking.
No, that would be stupid. That’d make the chips unuseable in any other products, including newer revisions of the same hardware. You’d need to a whole new batch of new chips just for minor upgrades.
Reprogramming chips to modify their USB-characteristics is actually quite a common thing and hackers tend to do that, too; you could, for example, modify the firmware to present itself as a benign device when the system is in use, but then switch to a USB-network adapter when it detects the system being idle, allowing it to monitor on network traffic with low to no risk of detection.
Moreover, if somebody DID try to do this to the Linux kernel, Linus Torvalds would rip off their limbs and beat them to death with the sticky ends, after he rejected the pull request.
*cough*
https://lkml.org/lkml/2014/10/23/129
Texas Instruments submitted just such a patch to poke fun at FTDI.
I can understand why they’re upset over counterfeit components, but this goes too far. It targets the victims of the chip fraud, not those who are guilty of committing it.
It makes me very uneasy that these drivers have conditional code designed to brick peripheral IO chips. This could also brick cheap FTDI compatible “clones” that do not have fake FTDI branding, which has me worried.
FTDI already backed down.
http://www.ftdichipblog.com/?p=1053
If you are curious, the great people over at the EEVBlog reverse engineered the changes and explain how the code worked. It was really a clever technique.
http://www.eevblog.com/forum/reviews/ftdi-driver-kills-fake-ftdi-ft…
and dave made a nice video about the whole desaster:
http://www.eevblog.com/2014/10/27/eevblog-676-rant-ftdi-bricking-co…
On more than one occasion, I have had Windows Update update a video card driver that was working perfectly fine, only to have it blue screen upon reboot. For this reason, I usually block all such updates.
If Microsoft is doing this on purpose as in they’re working with the manufacturer of the legitimate chip, then I’m glad I don’t run MS products anymore! Innocent computer owners are not going to know whether the manufacturer of their computer used a counterfeit chip. It is completely unfair to those users to have their hardware damaged by Microsoft. I hope someone can get to the bottom of this.
not microsoft is bricking other peoples stuff, FTDI is
and ms is pretty pissed becuase of it
Exactly. I am all for stopping the counterfeiters. Personally, if they just marketed their chips as FT232RL compatible instead of using counterfeit branding, this would be a non-issue.
The problem now is that people who see this don’t want to take a risk their chip might be counterfeit and bricked on purpose so they’ll use a different chip in their designs. This was not the solution, it’s only going to hurt FTDI.
I use the FT232RL chips quite a bit to build one-chip SIO->USB adapters for Atari 8-bits (for PC-side peripheral emulation) and occasionally to add a serial console to a WRT54GL. So far, I haven’t been burned by this fiasco but I’d surely be pissed if I was.
I once wrote a Linux driver for an USB TV tuner.
The tuner has an EEPROM chip which contains the USB identification numbers (there was also some calibration stuff that I wanted to access).
While debugging the driver, I accidentally wrote into that chip, bricking the thingy, and had to do a version of the driver that registered to the new USB ID and reversed the breakage.
What surprised me is that they did nothing to write-protect the chip : No hardware protection, not even a lock-sector command.
Isn’t there a standard for USB serial devices? That way, there would be no need for third parties to have to emulate an existing device. Instead they would design the hardware to match the standard. There wouldn’t even need to be a driver. This is an obvious example of where a standard would make sense.
The standard basically is the FTDI driver. That’s what makes this such bullshit.
What tidux meant was that there is a standard that nobody implements. If you want a Serial Device you basically need an USB device with two endpoints (in and out) on a single interface with USB-ACM descriptors that state a few things (configuration details) such as whether it accepts Hayes AT commands or not, with what extensions if it does (e.g. the 3GPP command set extensions), etc. And if you are living in the sad Microsoft world where everything starting from the wheel is reinvented, you also need an MSFT100 USB descriptor as well as the MS Descriptors that tell USBCGP what kind of a device it is.
I still haven’t seen ANY USB Serial dongle that implements that. If anyone writes decent USB descriptors on their device, regardless of the chip (FTDI, Prolific, or otherwise) it should work without a driver. Unfortunately, nobody bothers to check the actual ACM spec so you end up using a proprietary driver instead of the standard Windows (usbser.sys) driver or the Apple OS X (AppleWWANSupport.kext/AppleUSBCDC.kext) driver.
How freaking hard is it to include those descriptors is beyond me. I used FTDI’s tool to write my USB ACM Descriptors on my USB Serial console and got rid of the proprietary drivers.
I would love to live in a world where ELM327, USB Serial consoles and USB 3G modems would work without a driver, but most imbeciles programming those chips never bother to do that, although it took me precisely 25 minutes.
microchip with their mcp2200 come very close to what you describe
http://www.microchip.com/wwwproducts/devices.aspx?dDocName=en546923
I allready smell heavy lawsuit, after massive loss of chritical data.
It’s good that they backed-down about the “clone-bricking” drivers.
Although one can understand their frustrations about the clone chips, bricking the devices purchased by end-users is overly harsh – and potentially subject to legal retribution via a class action suit.
What might have been a preferable course of action would have been a message displayed during driver initialization upon insertion of the connector of the USB device. For example, “This device uses a counterfeited USB chip and may malfunction with future versions of the USB driver”.
Alternatively, they could have provided a test program to manufacturers of USB devices, or even retailers to identify counterfeited USB chips. Having passed the test, the devices or packaging could then be “stamped” as “genuine FTDI USB chip inside”.
BlueofRainbow,
It’s only by a coincidental quirk in the buffering mechanism that the FTDI drivers could detect the counterfeits. Detecting this difference isn’t a long term solution.
In order to effectively detect counterfeits in the future, they’d need to add some kind of new cryptographically secure handshake to future peripherals so that clones could not duplicate them without a secret key. But so long as FTDI needs to support existing devices, then there’s not much they can do once clones replicate the buffering quirk.
I’m not sure how much I like the idea of adding the complexities of crypto into low power devices and drivers that don’t otherwise serve a purpose for the end user – it could potentially introduce new hardships for linux.
Ars pointed out that the EULA for the FTDI driver has also been changed, with this passage added:
http://arstechnica.com/information-technology/2014/10/windows-updat…
Edited 2014-10-30 23:54 UTC
The real problem is not that many manufactures copy the FTDI chip, but why. If you try to buy this FTDI chip, you end up not to be able to obtain it, because you are too small customer for FTDI (unless you need 100 thousands of them). Even you are big customer, you have to make order six month before they are able to ship the chips to you. So what you have to do? Even small e-shops does not have these chips because reason above. If you really need one, you have to buy it somewhere, anywhere where they have it in stock when you need it. And this is the place where copycats steps in. This is really because the managment of FTDI are incompetent and really stupid. This is why so lot people have not real FTDI chip, but the same from other manufacturer. I hoped they realized this, but from what I saw, the FTDI headquartest did not apologize to us. So I never ever will try to find real FTDI chip and I will buy copycats without to be shy and soory about this.
Edited 2014-10-31 08:55 UTC
Milan Kerslager,
That’s somewhat a good point. It’s possible that FTDI could be opening the market up to competitors through it’s own deficiencies, although I don’t know for sure.
My problem isn’t so much that there are copycat chips. If TI or Maxim or FTDI chips become so popular that they become pseudo standards in the industry, I can sympathies with smaller manufacturers who have no market share and are presented with huge barriers to adaption merely due to product line incompatibilities. As a software guy, I get this, our motivation for mimicking another API is almost always to be compatible with it rather than to save ourselves work.
With that said, counterfeiting is immoral and illegal. Being compatible is one thing, but putting someone else’s stamp on your product and selling it as such crosses the line. It’s harmful to both consumers and to the original manufacturers.
Something to think over: with counterfeits you (and likely the resellers) don’t really know if your buying FTDI or a clone since they’re physically branded the same way, the differences are on the inside.
Edited 2014-10-31 12:44 UTC
1
Browser: Mozilla/4.0 (compatible; Synapse)