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?
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.
And even without the law it seems fairly simple.
You do not INTENTIONALLY break equipment that you do not own. You do not do that. No matter how you feel about that equipment. Particularly when the person who now owns said equipment has no idea that there is a problem.
And I'd be wary of any company that could not understand that.
... that make me so happy to run Linux Mint and CyanogenMod exclusively as my OS's ...
We should learn what we need to know about issues, before we decide what we need to feel about them.
Two wrongs don't make a right, was hopefully something that your parents taught you when you where quite small.
The issue is that the FTDI driver is deliberately reprogramming a chip that is not theirs and for which they have no authorisation to do so. This is an unauthorised modification and illegal.
You cannot stick something in a license agreement that allows you to break the law, because the courts will hold that part of the license agreement null and void.
As many many people have said the right and legal thing was to simply stop working and post a message to the user that the chip is a counterfeit/clone.
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).
Again (as per previous posts) :) FTDI didn't break anything - they moved the USB ID off their allocated(and payed for/licensed range) and that was that
The chip still works. However, not with FTDI's drivers. this would be the case if the chip was blocked by their drivers or the device ID was changed.
For example linux has a patch that allows the chips to work as a PID of 0. This is the driver that's been updated to recognise it. FTDI have no such obligation in their drivers
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
If FTDI provided a standalone counterfeit detection tool that manufacturers could use at final test or just as a spot check, then that could be helpful for conscientious designers/manufacturers like you or me who might find fake chips in our supply chain and then be really angry about that. We want to discover the problem before our finished goods end up in our customer's hands! It wouldn't address the problem of manufacturers who knowingly use fake parts or who just don't care, but it would be a step in the right direction. Deliberately and silently borking the fake chip after it's already in the end user's hands potentially causes a support burden for legitimate manufacturers of products using FTDI chips, without giving those manufacturers the information they need to constructively address the problem.
You do know that the routine inside thier drivers as assertained from the symbol tables in the driver code was called "BrickClonedDevices" I think that is a smoking gun, and shows intent. How much chance does 99% of the population have of recovering the functionality of a bricked device, even if pid 0 is rewritable. Its like telling a comsumer that a phone that has scrambled its eeprom is still perfectly ok, all they have to Do is buy a JTAG interface, hook it up, learn several years of embedded systems knowledge. But its not bricked is it. For all intentive purposes it is Bricked as far as a consumer is concerned who has never heard of FTDI.
That may be a matter of interpretation.
They are changing a number which is theirs (not sure if they'd have IP law on their side, or only the USB association's 'hear, hear!').
However, this change occurs by actually modifying EPROM states, said EPROM most not being theirs.
Of course then there's the bit about them not knowing that because it identifies itself as being theirs, thus it being the counterfeiters' fault for not counterfeiting it well enough to match the genuine article when sent this particular set of instructions, and the counter-issue that there doesn't appear to be any good reason to use those instructions except for targeting counterfeits, but that plain warnings don't seem to stem the tide of counterfeits, and whether counterfeits really are as big of an issue in the markets where they get most actively used anyway, and you've got a bit of a clusterfornication.
Except they're only doing this to their USB VID/PID - which IS THEIRS.
No. They're doing it to property that other people own. Just because that property advertises a fraudulent USB ID does not transfer ownership of that property to FTDI. They are intentionally breaking other peoples' property and even crowing about it.
FTDI is taking an end-justifies-the means stance, and implementing a vigilante approach. It's drinking the imaginary property Kool-Aid that gets people drunk on ideas like this, and they seem to lose all judgment.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
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.
Why would FTDI have to ensure their driver doesn't break chips that aren't theirs? There's no agreement, licensing, or goodwill. The problem is that this was not accidental. The FTDI anti-clone code in the driver is very sophisticated and actually performs a "preimage" cryptographic attack, to ensure that the clone chip doesn't detect the invalid configuration and auto-reset to factory defaults. Deliberately and with premeditation setting out to "damage" (which in legal terms includes temporary malfunction or impaired function) hardware is not legal without a court order or similar legal basis. The 2nd issue, is that of ensuring that they do not inconvenience wholly innocent parties. They failed at this. The FTDI anti-clone code will also deactivate genuine FTDI chips which have been configured with an external configuration memory in certain circumstances. This has been reported by a company which build development boards with numerous FTDI chips in different configurations; they found that the chip with an external EEPROM would get corrupted by new driver, even though the components were obtained from an authorized distributor.