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.
Is there a way to detect a counterfeit chip without bricking it? If that's the case, they could have just added a System Log message "FTDI device attached to system is not genuine! Driver will not start." Then the driver would return an error and Control Panel would show a yellow exclamation mark for the device.
When you send your fake Rolex (that you think is real) into Rolex for service, they don't send it back to you, they confiscate it as a counterfeit and it's destroyed. I went through this myself with a fake Mophie battery pack. They sent me back a photograph of the giant piles of counterfeit batteries that they confiscate because they came in for warranty work, and they weren't real.
This is functionally no different from that.
My involvement with hardware is currently only as a hobbyist, but there's a hardware project I might get on soon at work. FTDI has shown that it is willing to punish both direct and indirect customers for a wrong committed by a third party, and has not even remotely recanted that view. Management apparently thinks that they merely went too far when the world is shouting at them that going in that direction at all is unacceptable.
The obvious alternatives for USB-to-serial are:
1) Prolific 220x
2) Build a soft UART with a suitable microcontroller (PIC, AVR, Cortex-M0, whatever); this is apparently how the fakes work anyhow. Conform to USB CDC and most operating systems should have a built-in driver.
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"
The FTDI driver license states "The license only allows use of the Software with, and the Software will only work with Genuine FTDI Components. Use of the Software as a driver for a component that is not a Genuine FTDI Component may irretrievably damage that component. It is your responsibility to make sure that all chips you use the Software as a driver for are Genuine FTDI Components." Surely they neglected to share this with their lawyer. You can't punish users because the manufacturers are breaking the law. How is my mother going to know if she has a genuine FTDI chip or not? That's just asinine.
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.
I'm quite certain that most people wouldn't even know that they invited anybody into their house - as it is, they're technically already in the house (FTDI's drivers come with Windows). The invitation would be with the update - but as the occupant, I'm even unaware of this invitation. In this analogy, I trust my landlord, and my landlord trusts the maintenance people. The maintenance people broke that trust, no matter how well-intentioned their actions.
As far as the winding gear bit - FTDI merely cause a re-write of the USB PID to 0000. Nothing that can't be restored, just as a winding gear can be put back into place. It's not so much destruction as it is disabling.
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.
I work somewhere (a large chip manufacturer) where we use USB serial adapter cables all over our testing lab to interface things like thermal controllers. Since these are COTS items we have no control over what chip is in them. If this update had bricked our entire lab, it would have been a disaster and a total show-stopper for our testing schedule until we located (and understood!) the problem and fixed it. Personally I think it was a childish way for them to handle this situation and I'm glad they saw reason and yanked it back before it created a total disaster.
Are YOU using the TOOL, or is the TOOL using YOU? Think about it!
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
I don't have a problem with FTDI technology itself, the problem is with the hardware clones.
But FTDI could have taken a different route and instead show an annoying pop-up or only allow 300bps on counterfeit chips. That would work until the counterfeit chip makers goes so far in their work to create a clone that it would cost as much as the real thing at which time it's useless.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
The comma might recieve a pardon, but the first period and capital B on "But" will be tried, found guilty, and executed immediately.
McFly777
- - -
"What do people mean when they say the computer went down on them?" -Marilyn Pittman
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
.
You can't go destroying hardware owned by consumers, no matter what the reason.
You very clearly didn't see the die exposure article.
The counterfeit chip is in fact WAY more complex. It's not off the shelf, so to speak. They custom-modified. It's obvious once you start looking at the physical silicon.
Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
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.
FTDI didn't choose that specific value(though, thinking back to Intel's amusing choice of '8086' as their PCI vendor ID, you probably can choose a VID if you push hard enough or have a cute reason); but there are still some commonalities(though arguably some differences as well):
The USB spec (and, probably more importantly, USB as implemented on basically all commercially relevant systems) supports essentially two mechanisms for telling the OS what driver your device requires:
If supported by a generic class driver; your device descriptors include a bDeviceClass field containing a defined USB device class code; but isn't 0xFF(which is valid; but means 'vendor defined'), a bDeviceSubClass field with a valid subclass code, and a bDeviceProtocol field with a valid protocol code.
If your device is supported by a specific driver(or one of the hybrid arrangements, not uncommon, where a versatile device class like USB HID will be used to do most of the low-level work; but a vendor-specific driver will implement whatever device specific behavior is offered on top of that), then you need to supply the correct VID/PID combination.
Now, let me be clear, I see absolutely no reason why FTDI should need to provide driver support for clones, so even if Windows(correctly, as an OS) responds to a USB device with an FTDI VID/PID by loading the FTDI driver, it is fully within their rights to have a driver that detects and ignores non-FTDI parts.
However, (and this is where the analogy to consoles and trademarked-but-technically-necessary really comes in), the USB spec does not offer a 'compatible with VID/PID' device description option. Either you specify the appropriate generic class, or you specify a VID/PID and a vendor-specific class. There is no other way (barring atypical configurations and kernel hacker tricks that aren't of much use in the wider world) to do it.
If you want a Game Boy or whatever to load your cartridge, you need that logo to be present at the appropriate address. If you want to specify "I need the driver that supports device X", you have to supply device X's VID/PID. There is no 'compatible with device X; but actually made by me' mechanism.
If you are buying fake FTDI gear to take advantage of FTDI's driver devs, then I have no pity. Not FTDI's problem to support you. However, there are 3rd-party FTDI-device-supporting drivers (notably on Linux and BSD, maybe somebody has ported one to Windows or OSX, maybe you plan to implement your own, whatever) that it would be perfectly legitimate for an FTDI-compatible device to request, and (so long as it doesn't involve copyright or patent infringement, or fraudulent misrepresentation) there are perfectly licit non-FTDI chips that implement FTDI-compatible behavior. The USB-IF certainly doesn't have enough power over short hex values to stop that; and I'm not convinced that we would want them to.
A large number of now standard or semistandard devices, protocols, and command sets we don't even think about today started life as dirty clones of the more popular brand: The PC BIOS, the (still spoken, in extended form, by a moderately alarming number of things) Hayes command set, the 16550 UART (originally a National Semiconductor model number; now register compatibility with those is practically a standard in itself, thanks to about a zillion clones), the NE1000/2000-compatible NICs that helped make ethernet ubiquitous and cheap...
Again, FTDI has every right to make the use of their drivers contingent on the use of their ICs (or some other licensing terms, if that amuses them). Also, non-FTDI parts being sold (with varying degrees of sophistication, from pure nonsense to nearly perfect fakes) as FTDI is a bad thing. For FTDI, for the buyer being defrauded, for the electronics supply chain generally.
However, we would not be well served to be blinded to the (generally desirable and helpful, as much as incumbents dislike them) history of 3rd-party in