Slashdot Mirror
FTDI Removes Driver From Windows Update That Bricked Cloned Chips
New submitter weilawei writes: Last night, FTDI, a Scottish manufacturer of USB-to-serial ICs, posted a response to the ongoing debacle over its allegedly intentional bricking of competitors' chips. In their statement, FTDI CEO Fred Dart said, "The recently release driver release has now been removed from Windows Update so that on-the-fly updating cannot occur. The driver is in the process of being updated and will be released next week. This will still uphold our stance against devices that are not genuine, but do so in a non-invasive way that means that there is no risk of end user's hardware being directly affected." This may have resulted from a discussion with Microsoft engineers about the implications of distributing potentially malicious driver software.
If you design hardware, what's your stance on this? Will you continue to integrate FTDI chips into your products? What alternatives are available to replace their functionality?
If you design hardware, what's your stance on this? Will you continue to integrate FTDI chips into your products? What alternatives are available to replace their functionality?
They are a Scottish firm subject to U.K. Law (specifically Scottish law). As such unauthorised modification of computer materials is a criminal offence punishable with a maximum sentence of six months in jail or a 5000GBP fine.
Stopping their device driver working with clone/counterfeit chips is fine. Making modifications to data help on such chips is outright illegal.
I can only imagine that the lucky guy who picked up the call from Redmond about 'so, we understand that you...made a few changes...to the behavior of your WHQL drivers that frankly don't make Windows Update look very good...' got quite an earful.
Even if MS thinks FTDI is on the crusade of the righteous, it certainly isn't to their advantage to have Windows Update involuntarily pulled into the fiasco.
FTDI's chip is popular, and heavily counterfeited. Right or wrong they felt they had to go to these lengths to protect their business, and it has had the effect of bringing counterfeited chips into the public consciousness.
The problem however, is that switching to another chipset won't eliminate the counterfeiters and the people who slip these chips into the supply chain to save a few bucks.
So the better question is how can we improve the system to ensure that counterfeit chips aren't being secretly swapped into our products.
If I was a hardware manufacturer, this would make me MORE likely to use FTDI chips. It means I have greater confidence that what I'm getting is "real", because I know that they are actively trying to make counterfeiting their product more difficult.
We don't use any of the serial only chips, but on the higher end with JTAG and SPI the FTDI parts work great and aren't too expensive. If any "clone" chips get into our supply chain we would be very pissed at whoever did it. We specify actual FDTI parts for a reason. The "clones" have very hit or miss quality. We don't use them under windows either.
When Rolex sneaks into your house because somewhere in your apartment lease you agreed that trusted maintenance people could do so to make sure that everything is on the up and up, finds your Rolex to be a fake, and takes a winding gear out... would you consider that to also be functionally no different?
Because that's more akin to what has happened.
Windows users allow Windows (by default) to let WHQL drivers to be updated silently. FTDI made use of this mechanism to update their driver. Their driver, when called upon to communicate with the device, then sends it some data which either does nothing (genuine) or reversibly disables it (if counterfeit).
Any BOM that passes through my hands will get FTDI crossed off. I'm sorry they have a counterfeit problem. They need to improve anti counterfeiting measures instead of inflicting collateral damage. Their abrupt decision is smelly no matter how you look at it.
Take the cheese to sickbay, the doctor should see it as soon as possible - B'Elanna Torres, "Learning Curve"
That isn't actually so clear:
According to the die shots, the clone chips' implementation is more or less entirely different from the FTDI implementation. Intended to be pin-compatible, and exhibit the same behavior; but totally different silicon, not a cut and paste job.
The clones that are then labelled and sold as 'FTDI' are, certainly, in all kinds of violation of trademark law; but what of any that are just blob-topped or generically packaged and not represented as being actual FTDI? Not something FTDI likes, or is obliged to provide driver support for; but neither was the Compaq 'IBM PC compatible' BIOS.
Even if the (typically very harsh, though widely unenforced) laws regarding trademark infringing goods do actually allow FTDI to brick them in the field, they haven't actually established that a given chip is a counterfeit, rather than a mere clone, before bricking it. Unless they wish to claim that "0x0403" is entitled for trademark protection, the driver is hardly in a position to distinguish between the two.
We had a similar situation come up with one of our older products. People copied our initial hardware designs some 12 years ago, built (crappy) knock offs and sold them as their own along with copies of our chips to go along with it. The black market was clearly going to run us out of business and I despised the idea of having to basically compete with ourselves just to keep handing new features over to leeches. It was infuriating to the point that I had seriously considered just shutting the business down and moving on to other things.
Instead, we spent a LOT of time redesigning our stuff to prevent anyone from (reasonably) being able to do that again. We basically wasted an entire year just dealing with counterfeit issue rather than improving our core product.
Luckily it paid off and we were able to shut that whole black market segment down. But at one point we had to consider the same option FTDI did. We gave thought to effectively bricking devices that we were able to identify as counterfeit or, worse, someone would send us one of these counterfeit packages asking us for support or service on the item. We had to basically return to them a chip and adapter we knew, without a doubt, was a bogus copy of our stuff.
It was hard, but we knew full well we could not possibly damage or keep something they had purchased through what they considered legitimate channels. FTDI should have realized this as well. They royally screwed up on this one.
It's a little strange, though, because if you buy something somewhere and it ends up being a stolen item, you're obligated to give it back to the original owner. I mean the police trail leads to your doorstep, you're out the item you bought whether you knew it was stolen or not. I guess the same concept doesn't applied to IP somehow. I'm not even sure how it would. I guess IP isn't really "property" after all.
Today Atmel, Microchip and others make inexpensive microcontrollers with native USB peripherals. The Atmel "8u2" chip, for example, is less expensive than even most of the FTDI clones, and certainly a LOT less than a genuine FTDI chip.
For years, I've published a very simple and easy-to-use USB code for those chips.
http://www.pjrc.com/teensy/usb...
I also publish a signed INF installer that works with ALL USB Serial based on this standard protocol (called Communications Device Class, Abstract Control Model, or CDC-ACM). All 3 operating systems have the necessary driver built in. Mac OS-X and Linux load it automatically. Windows needs the user to add a INF.
http://www.pjrc.com/teensy/ser...
Sadly, the CDC-ACM driver in Windows (called USBSER.SYS) is buggy. About a year ago, I sent Microsoft this reproducible bug report.
https://www.youtube.com/watch?...
In a follow up email a few months ago, they were supposedly testing a fix. I'm hopeful that Windows 10 may be the first version of Windows to ever ship with a good quality USB Serial driver (as Linux has done for many years, and Apple as done since releasing Lion a few years ago).
PJRC: Electronic Projects, 8051 Microcontroller Tools
FTDI tried to also get the "brick-patch" to Linux, but Greg Kroah-Hartman blocked it with this response:
Funny patch, you should have saved it for April 1, otherwise people might have actually taken this seriously :)
Patches as performance art, now I've seen everything...
greg k-h
Yesterday a number of my clients called me to say they wanted me to design out the FTDI FT232R from current designs and replace it with an alternative (I settled on the Microchip MCP2200). Today, after this news, I called each of them to explain FTDI's change in policy and see if they still wanted to make this change. All of them said yes.
The feedback was essentially this: FTDI's actions left a bad taste in their mouth and they didn't appreciate this action being taken without any real attempt to notify resellers and manufacturers; and now that they know the alternate chip I proposed was about half the price as FTDI's offering they are happy to change. Now none of these people are high volume manufacturers, so it will unclear if FTDI will even notice.
The reason I have found for most clients wanting FTDI is confidence in the brand more than anything else. This move will affect it a little, but people's memories are short, and FTDI responded quickly enough that they won't suffer too much damage. My prediction is that FTDI will take a dip in sales for a quarter , and then things will return to more or less normal; but companies like Microchip will likely see an uptick, because manufacturers more aware of the alternatives.
What do you know I wrote a novel
They explicitly wrote code that intentionally bricks the connected device. It takes advantage of a bug/ implementation detail such that it does NOTHING on a FTDI device. Because it doesn't do anything at all on a genuine FTDI device, there is no innocent reason for FTDI to put it in their driver.
If the code did something useful on an FTDI device but broke counterfeit devices, that could be accidental. That's not the case, though - the code never does anything good, it only breaks things.