I hope this causes a major and publicly visible malfunction in some important device/installation/machinery, of course with no harm done to any persons, but enough of an embarrasment to really set an example, so no vendor will think of pulling tricks like these in the future. Takeaway lesson: End users should never touch anything remotely FTDI-like, since it's probably impossible to verify if the device is genuine or…
My takeaway lesson is that end users should never trust closed source drivers. Can you picture a Linux or *BSD driver in which there is an intentional if (counterfeit) { do_damage(); }
FTDI driver kills fake FTDI FT232s
281–290 of 315 posts
Re: FTDI driver kills fake FTDI FT232s
#282Earlier quoted context omitted.
Well, that didn't take long! Arduino Nano's on Ebay are already starting to ship with the CH340G instead of the FTDI clone. Way to go FTDI - pissed off your end users and caused manufacturers to move to a completely different chipset. That worked out well for you didn't it? http://www.ebay.co.uk/itm/Nano-V3-0-ATmega328-16M-Micro-cont...
of course you realize those chinese clones NEVER EVER shipped with genuine FTDI chips in the first place, right?
Whether FTDI screwed customers is a debatable question. In any event, FTDI definitely screwed themselves.
Re: FTDI driver kills fake FTDI FT232s
#283Earlier quoted context omitted.
If the counterfeit FTDI chips are using FTDI's registered USB vendor ID (I assume they are, otherwise the driver wouldn't recognize them?) I think the blame falls solely on the counterfeit chip makers.
Why? The counterfeits aren't seeking USB compliance certification, they're just trying to provide 100% compatibility. Are you saying that reverse engineering and spoofing for the sake of compatibility is wrong? Or do you think that USB vendor IDs are covered by some trademark?
It doesn't matter if it's trademarkable. The entire purpose of VIDs is to distinguish between different vendors' devices. If I'm allocated a VID it's not my responsibility to ensure my drivers interoperate with other vendors' products.
How many products using counterfeit FTDI chips don't advertise USB compliance?
Re: FTDI driver kills fake FTDI FT232s
#284Earlier quoted context omitted.
> because breaking other people's stuff is not an authorized method for dealing with trademark infringement. The device violates the USB specification by using a protected VID; it is already to be considered as broken regarding the USB specification.
Just because a car's missing its wheels doesn't make it legal to steal the bumper.
Re: FTDI driver kills fake FTDI FT232s
#285Earlier quoted context omitted.
Come on, take a deep breath. We're talking about bricking a serial to USB chip, not something worth shedding blood really. As far as unethical behavior by corporation is concerned I really not think it's even noteworthy.
We're talking about bricking a serial to USB chip, not something worth shedding blood really. We're talking infrastructure: if this was a civil engineer designing a road to spontaneously create potholes that would flatten tires on certain brands of vehicles, they'd be put in the slammer post haste. FDTI has no idea where their chips and drivers will end up, and as designers of such low-level infrastructure type devic…
And if a civil engineer designs a bump in the road that will destroy your suspension if you are driving above the speed limit they have set, we'd just call it a speed bump
Re: FTDI driver kills fake FTDI FT232s
#286Earlier quoted context omitted.
You could always just use libusb to talk to your device (e.g., an AVR w/ V-USB or another microcontroller with actual USB support) from user space, instead of fooling around with fake COM ports.
That's probably what I should do. I bought a book on usb and started learning a bit about the protocol. Are there any good Libusb projects that would be a good example? Most I was were for using libusb to talk to an existing device class. I'd like a sample that contains both device and host?
Re: FTDI driver kills fake FTDI FT232s
#287Earlier quoted context omitted.
It's quite possibly a violation of U.S. Code 1030(a)(5)(A), a federal felony: (5) (A) [Whoever] knowingly causes the transmission of a program, information, code, or command, and as a result of such conduct, intentionally causes damage without authorization, to a protected computer; Now "protected computer" and the [ab]use of the Interstate Commerce Clause mean that the device with the FTDI would likely need to be co…
FTDI is not a US company.
Re: FTDI driver kills fake FTDI FT232s
#288Earlier quoted context omitted.
I think the counterargument (elsewhere in this thread) is pretty persuasive -- that this defense won't help much if you intentionally set out to damage counterfeit chips. Think about it this way. Suppose the driver works like this: ``` if(counterfeit()){ // do something harmful to the identified device } ``` If you have a counterfeit chip, and you run the driver, and the driver breaks your chip, then you are in fact…
In this case the driver is executing two writes which a legitimate chip would ignore, but which the counterfeit responds to and actions. Those writes just happen to be the position in the counterfeit's EPROM where the USB PID is stored, and just before where the checksum is stored.
In what universe can them doing a preimage attack on the checksum "just happen"?
Re: FTDI driver kills fake FTDI FT232s
#289I haven't gotten into the DIY/Hacker/Arduino stuff but it seems like there would also be plenty of consumer devices that may be impacted that don't have correct supply chain control (or care about the source of their chips). I wonder if Windows will pull the driver.
Microsoft has confirmed that they're aware of the issue, and are investigating. No news yet on what (if any) action they'll take. But I'd expect they'll do something, as it would appear to the end user that "Windows Update broke my $DEVICE".
Re: FTDI driver kills fake FTDI FT232s
#290Earlier quoted context omitted.
Tangentially: people totally would fault FTDI for releasing drivers that don't work with counterfeit parts. See: Apple detecting and rejecting counterfeit iPhone cables.
Yes, people would fault them for removing functionality. The problem in that case is not the actual new drivers, but the process of uninstalling the old working drivers.