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