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?
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.
FTDI doesn't have to ensure that their driver doesn't break chips. It sounds however that FTDI went out of their way to detect whether the chip was a counterfeit or not, and if it was, specifically write to it to disable it when it could have just as easily done nothing (as disabling the driver from functioning).
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
just yesterday, there was a linux kernel patch (on the usb drivers mailing list) that now allows a 0000 pid for ftdi devices.
also, there was a tool by mark lord that allows you to write back any pid value you want, for example, when I ran it, I got this output (and it 'fixed' the chip again, too):
% ./ft232r_prog --old-pid 0x0000 --new-pid 0x6001
ft232r_prog: version 1.24, by Mark Lord.
eeprom_size = 128
vendor_id = 0x0403
product_id = 0x0000
self_powered = 0
remote_wakeup = 1
suspend_pull_downs = 0
max_bus_power = 90 mA
manufacturer = FTDI
product = FT232R USB UART
serialnum = (elided...)
high_current_io = 0
load_d2xx_driver = 0
txd_inverted = 0
rxd_inverted = 0
rts_inverted = 0
cts_inverted = 0
dtr_inverted = 0
dsr_inverted = 0
dcd_inverted = 0
ri_inverted = 0
cbus[0] = TxLED
cbus[1] = RxLED
cbus[2] = TxDEN
cbus[3] = PwrEn
cbus[4] = Sleep
Rewriting eeprom with new contents.
--
"It is now safe to switch off your computer."
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.
Actually, it is not. "Their" USB VID/PID can legally be used by anybody, it just means that the USB logo may not be used. AFAIK (and just checked on some FT232 I have), there is no USB logo on these chips.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.