6 ms·

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 eno

by 0x0 12y ago

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 not. Wonder if FTDI thought this through.

gioele 12y ago
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(); }
- dalke 12y ago
  Yes, I can. I can picture a product vendor using a modified Linux kernel with that code in a driver, or at least a moral equivalent. Eg, a NAS box which is "only compatible with brand X drives". Just because the code is available doesn't mean it does no damage. Only that you have the ability to find and fix the code.
  - pb2au 12y ago
    A NAS box "only compatible with brand X drives" is nowhere near a NAS box that intentionally bricks non-brand X drives when attached. As a side note, are there any known cases where a vendor has released open source code that intentionally bricks a device? I'd be surprised if they were not found legally liable if the intent was spelled out so clearly.
    - dalke 12y ago
      Sorry, I wasn't clear. My "only compatible ..." left out "and does naughty things if otherwise." Perhaps you'll like this example better? https://www.google.com/patents/US4577289 https://www.google.com/patents/US4577289 "Hardware key-on-disk system for copy-protecting magnetic storage media" There are physical holes on the disk. "The test program writes the sections with a test pattern which generates a change in the pattern of magnetic domains of the medium, a subsection at a time, with a subsection responding to the test pattern only in the absence of indicia thereon, to form a stored pattern on the given section. An expected pattern and the stored pattern are compared at least a subsection at a time to determine if corresponding subsections have a predetermined pattern of magnetic domains." If you have "insert key disk now", followed by a write to the disk, and then a verification, then a standard disk/non-key disk will get corrupted. That 'bricks' non-brand floppies by design, under the aegis of copy protection. There's been open source with back doors in it. Eg, Firebird had one that took about 6 months to detect, after source code release. In listening to the various accounts of GPL enforcement, it isn't always easy to track down the actual vendor. Quoting from http://www.infoworld.com/article/2617579/open-source-software/why-the-gpl-licensing-cops-are-the-good-guys.html http://www.infoworld.com/article/2617579/open-source-softwar...: > Always keen to shave the last few cents from their bill of materials, these manufacturers tend to procure their firmware from low-cost suppliers that have in turn delivered open source software without passing on its licensing terms. It can come as a surprise to the hardware manufacturer to discover a violation of the license terms. While that's about incorrect use of licensing terms, it shows there's no reason why the manufacturers are aware of all of the code in the software they sell.
      - pb2au 12y ago
        Thanks for the second example. It's a more clear use-case than the mischievous do_damage() function I had in mind. I think intent would definitely play a role in establishing liability for damaged equipment (i.e. the user misusing the device versus the company tampering with the user's equipment).
  - foxylad 12y ago
    > Just because the code is available doesn't mean it does no damage. Only that you have the ability to find and fix the code. Also your shenanigans become visible. You'd have to code extremely carefully to break the fake with plausible deniability, and even then your name as a developer would forever be mud.
    - dalke 12y ago
      As long as the money comes in before it's discovered, there will be people who take that chance.
- coldpie 12y ago
  Someone submitted a (parody) patch to do just that! https://lkml.org/lkml/2014/10/23/129 https://lkml.org/lkml/2014/10/23/129
npsimons 12y ago
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 I actually hope that this does cause an event drastic enough so that FTDI will have blood on its hands that ends in jail time for management and engineers. I don't want to see anyone hurt, especially not innocent third parties, but fuck FTDI, fuck the management who ordered this, and fuck the engineer(s) who didn't quit in protest. I'm not easily offended, but as a programmer who has been responsible for code that would result in loss of life if I made it defective by design, I have no sympathy for this sort of thing. One other thing that I could hope for is that this teaches everyone the true cost of closed source, especially drivers. Don't put up with it.
- yuhong 12y ago
  I think standardizing the interface would be more important.
  - Kliment 12y ago
    Well, the core issue is that there isn't a standard vendor-independent device class driver for CDC devices in Windows like there is for say HID. This is a solved problem on pretty much every other OS. The only reason a manufacturer would make devices that use the same vid as an FT232R as opposed to a functionally-identical pin-compatible device with a different vid is because the drivers included in Windows are vendor-tied. You don't see this kind of issues with no-name mice or keyboards for example because they don't need a vendor-specific driver.
- simias 12y ago
  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.
  - osivertsson 12y ago
    What if this chip is part of the maintenance interface on a medical device at your local hospital? Meaning regular maintenance can no longer be done, rendering the device unable to help people?
osivertsson 12y ago
Basically all vendors outsource production. Very few vendors will knowingly put a fake chip in their product, the trick is pulled by someone closer to manufacturing, either to cut costs or to try and ship earlier in case the original chip is hard to get right now. I doubt very few vendors will realize if a fake FTDI chip is part off their manufactured product even after rigorous testing since the functionality is correct (until you get this driver). EDIT: I doubt FTDI have thought this through. I will share this with the hardware designers I know and most will probably react like on the linked thread, and just switch to another chip to avoid any possible hassle.
mhandley 12y ago
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-controller-CH340G-Board-Mini-USB-for-Arduino-/121465239079 http://www.ebay.co.uk/itm/Nano-V3-0-ATmega328-16M-Micro-cont...
- rasz_pl 12y ago
  of course you realize those chinese clones NEVER EVER shipped with genuine FTDI chips in the first place, right?
  - kabdib 12y ago
    Doesn't matter. "Does not include an FTDI chip" is a desirable product feature now. Whether FTDI screwed customers is a debatable question. In any event, FTDI definitely screwed themselves.
    - rasz_pl 12y ago
      Of course it matters, yesterday "includes fake, but cheap ftdi" was the desired feature.

by 0x0 12y ago

gioele 12y ago

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(); }

dalke 12y ago
Yes, I can. I can picture a product vendor using a modified Linux kernel with that code in a driver, or at least a moral equivalent. Eg, a NAS box which is "only compatible with brand X drives". Just because the code is available doesn't mean it does no damage. Only that you have the ability to find and fix the code.
- pb2au 12y ago
  A NAS box "only compatible with brand X drives" is nowhere near a NAS box that intentionally bricks non-brand X drives when attached. As a side note, are there any known cases where a vendor has released open source code that intentionally bricks a device? I'd be surprised if they were not found legally liable if the intent was spelled out so clearly.
  - dalke 12y ago
    Sorry, I wasn't clear. My "only compatible ..." left out "and does naughty things if otherwise." Perhaps you'll like this example better? https://www.google.com/patents/US4577289 https://www.google.com/patents/US4577289 "Hardware key-on-disk system for copy-protecting magnetic storage media" There are physical holes on the disk. "The test program writes the sections with a test pattern which generates a change in the pattern of magnetic domains of the medium, a subsection at a time, with a subsection responding to the test pattern only in the absence of indicia thereon, to form a stored pattern on the given section. An expected pattern and the stored pattern are compared at least a subsection at a time to determine if corresponding subsections have a predetermined pattern of magnetic domains." If you have "insert key disk now", followed by a write to the disk, and then a verification, then a standard disk/non-key disk will get corrupted. That 'bricks' non-brand floppies by design, under the aegis of copy protection. There's been open source with back doors in it. Eg, Firebird had one that took about 6 months to detect, after source code release. In listening to the various accounts of GPL enforcement, it isn't always easy to track down the actual vendor. Quoting from http://www.infoworld.com/article/2617579/open-source-software/why-the-gpl-licensing-cops-are-the-good-guys.html http://www.infoworld.com/article/2617579/open-source-softwar...: > Always keen to shave the last few cents from their bill of materials, these manufacturers tend to procure their firmware from low-cost suppliers that have in turn delivered open source software without passing on its licensing terms. It can come as a surprise to the hardware manufacturer to discover a violation of the license terms. While that's about incorrect use of licensing terms, it shows there's no reason why the manufacturers are aware of all of the code in the software they sell.
    - pb2au 12y ago
      Thanks for the second example. It's a more clear use-case than the mischievous do_damage() function I had in mind. I think intent would definitely play a role in establishing liability for damaged equipment (i.e. the user misusing the device versus the company tampering with the user's equipment).
- foxylad 12y ago
  > Just because the code is available doesn't mean it does no damage. Only that you have the ability to find and fix the code. Also your shenanigans become visible. You'd have to code extremely carefully to break the fake with plausible deniability, and even then your name as a developer would forever be mud.
  - dalke 12y ago
    As long as the money comes in before it's discovered, there will be people who take that chance.
coldpie 12y ago
Someone submitted a (parody) patch to do just that! https://lkml.org/lkml/2014/10/23/129 https://lkml.org/lkml/2014/10/23/129

npsimons 12y ago

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 I actually hope that this does cause an event drastic enough so that FTDI will have blood on its hands that ends in jail time for management and engineers. I don't want to see anyone hurt, especially not innocent third parties, but fuck FTDI, fuck the management who ordered this, and fuck the engineer(s) who didn't quit in protest. I'm not easily offended, but as a programmer who has been responsible for code that would result in loss of life if I made it defective by design, I have no sympathy for this sort of thing. One other thing that I could hope for is that this teaches everyone the true cost of closed source, especially drivers. Don't put up with it.

yuhong 12y ago
I think standardizing the interface would be more important.
- Kliment 12y ago
  Well, the core issue is that there isn't a standard vendor-independent device class driver for CDC devices in Windows like there is for say HID. This is a solved problem on pretty much every other OS. The only reason a manufacturer would make devices that use the same vid as an FT232R as opposed to a functionally-identical pin-compatible device with a different vid is because the drivers included in Windows are vendor-tied. You don't see this kind of issues with no-name mice or keyboards for example because they don't need a vendor-specific driver.
simias 12y ago
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.
- osivertsson 12y ago
  What if this chip is part of the maintenance interface on a medical device at your local hospital? Meaning regular maintenance can no longer be done, rendering the device unable to help people?

osivertsson 12y ago

Basically all vendors outsource production. Very few vendors will knowingly put a fake chip in their product, the trick is pulled by someone closer to manufacturing, either to cut costs or to try and ship earlier in case the original chip is hard to get right now. I doubt very few vendors will realize if a fake FTDI chip is part off their manufactured product even after rigorous testing since the functionality is correct (until you get this driver). EDIT: I doubt FTDI have thought this through. I will share this with the hardware designers I know and most will probably react like on the linked thread, and just switch to another chip to avoid any possible hassle.

mhandley 12y ago

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-controller-CH340G-Board-Mini-USB-for-Arduino-/121465239079 http://www.ebay.co.uk/itm/Nano-V3-0-ATmega328-16M-Micro-cont...

rasz_pl 12y ago
of course you realize those chinese clones NEVER EVER shipped with genuine FTDI chips in the first place, right?
- kabdib 12y ago
  Doesn't matter. "Does not include an FTDI chip" is a desirable product feature now. Whether FTDI screwed customers is a debatable question. In any event, FTDI definitely screwed themselves.
  - rasz_pl 12y ago
    Of course it matters, yesterday "includes fake, but cheap ftdi" was the desired feature.