Slashdot Mirror


FTDI Driver Breaks Hardware Again (eevblog.com)

janoc writes: It seems that the infamous FTDI driver that got famous by intentionally bricking counterfeit chips [NOTE: that driver was later removed] has got a new update that injects garbage data ('NON GENUINE DEVICE FOUND!') into the serial data. This was apparently going on for a while, but only now is the driver being pushed as an automatic update through Windows Update, thus many more people stand to be affected by this.

Let's hope that nobody dies in an industrial accident when a tech connects their cheap USB-to-serial cable to a piece of machinery and the controller misinterprets the garbage data.

40 of 268 comments (clear)

  1. First PoNON GENUINE DEVICE FOUND by Anonymous Coward · · Score: 5, Funny

    ...

  2. Keeping me happy for disabling auto-updates by blind+biker · · Score: 3, Insightful

    I think I'll keep my Windows computers with updates disabled, as all the updates have been detrimental to the user, lately.
    Checking the eevblog thread, though it seems it affects Windows 10, which I also elected not to touch.

    --
    "The agriculture ministry is not in charge of Gundam" - Japanese ministry official.
    1. Re:Keeping me happy for disabling auto-updates by ArmoredDragon · · Score: 4, Informative

      I don't know why this is happening to USB to Serial drivers, of all things, because even worse shit happens with Prolific chipsets. Prolific did a hardware refresh and then instantly obsoleted all of the previous generation chips. Otherwise not a problem, except if you use Windows 8 or newer then the fucking driver they issue causes a code 10 hardware. If you use an older on 8 or newer then they work fine, but stupid Windows Update keeps replacing it with the bad driver unless you use a bit of ini file hackery.

      What makes this worse than the FTDI situation is that Prolific is doing it to their own hardware to force you to buy a new one.

    2. Re: Keeping me happy for disabling auto-updates by Anonymous Coward · · Score: 2, Interesting

      Potentially compromised and working or not working.

      Damned if you do, damned if you don't.

    3. Re:Keeping me happy for disabling auto-updates by Aighearach · · Score: 2

      it's possible the driver actually choose to cause BSOD, there's no way to know.

      Stop there and don't pretend to be providing analysis. That is very knowable. Not knowing is no excuse to pretend it is not knowable, and that people just have to wave their hands and guess.

      People don't care if their hardware is genuine, they care if they use a thing with that brand on the label, is it likely to work or not. They expect the vendor to punish the people counterfeiting, if they can, not the end user who correctly read the label. It is their own nose they cut.

    4. Re:Keeping me happy for disabling auto-updates by ArmoredDragon · · Score: 5, Informative

      So, your problem may well be that you have a counterfeit "Prolific" chip that Prolific's driver no longer plays nice with.

      No, that's not the problem at all. You can read yourself from Prolific's website:

      http://www.prolific.com.tw/US/...

      Note on that page how they no longer support "EOL chipsets" even though they work fine in windows 8 and 10 if you simply use an older driver that doesn't care about what OS version you have. If you use a newer one though, the driver throws a code 10 error so it won't work, unless of course, it detects a non-EOL chipset.

    5. Re:Keeping me happy for disabling auto-updates by AmiMoJo · · Score: 2

      It's best to avoid custom drivers for USB to serial adapters. There is a standard for them called CDC. All major operating systems support it, including Windows and Linux.

      The reason that FTDI and the like provide a custom driver, apart from to screw users, is that the Windows driver has a few flaws. The only big one is that it doesn't handle disconnection. Apparently Windows 10 fixes it.

      Use the genetic OS driver for CDC. Don't get screwed by the manufacturer.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
  3. Supply chains by Anonymous Coward · · Score: 5, Insightful

    Thanks to the reality of supply chains, companies intending to buy the real deal can accidentally buy the knockoffs. Anyone willing to do this(or their previous actions, like bricking devices) is someone I intend to never purchase from, real deal or not.

    There are now plenty of competitors to FTDI. Don't buy FTDI- even if you think you're buying the real deal, reality can intervene.

    1. Re:Supply chains by willaien · · Score: 5, Informative

      MCP2221, CH340G, etc. Just see:

      http://www.eevblog.com/forum/r...

    2. Re:Supply chains by willaien · · Score: 4, Insightful

      And why is this the end-user's fault, again? Why do they feel that they need to cause it to malfunction or (in the case of a year ago), brick the device with an official driver from microsoft that gets pushed on the end user without them asking for it (or agreeing to their onerous T&C)?

      Why punish the end user who doesn't even know what FTDI is or what a USB chipset even does for buying a product?

    3. Re:Supply chains by Anonymous Coward · · Score: 5, Interesting

      But you sure as fuck won't be sure you're getting ACTUAL FTDI components. FTDI WILL NOT GUARANTEE that a chip is real unless it is purchased directly from them. This includes chips purchased THROUGH THEIR DISTRIBUTORS.

      They can't police their own fucking distributors, dude. Get a fucking grip.

    4. Re: Supply chains by guruevi · · Score: 4, Interesting

      The problem I've found with a LOT of USB things even the FTDI ones is that they're only putting out a stepped up 12V or even just 5V while classically the serial port was a bit above 12V.

      Although the spec allows for +3V/-3V at the lowest end, most stuff just won't work well. Also the stepped up voltages seem to have a lot of noise and variation, again something the spec allows but "back in the day" few allowed for those.

      Also, the USB data bus frequency leaks noise into the serial bus portion, sometimes visibly on a scope or definitely noticeable on a spectrum analyzer. The problem probably being poor design and shielding on modern computers. I've also had some issues with ground loops but that is only in very specific circumstances.

      For critical applications, I've found the Ethernet serial servers are more reliable. Even running commands through an Arduino will do better in a pinch. But those cheap USB adapters are good enough for setting up a switch or uploading a firmware when the device is out of order anyway but are not intended to be permanently attached.

      --
      Custom electronics and digital signage for your business: www.evcircuits.com
    5. Re:Supply chains by ukoda · · Score: 2

      You saved me posting the same thing. I worked in China and know first hand that you can pay premium prices from an authorised dealer and still be supplied counterfeit parts. It only take one corrupt person in the supply chain and you are stuffed. The good news is everyone learnt their lesson last time not to use FTDI parts and is now manufacturing with alternative parts. A decision that has now been proven to be the wise choice.

    6. Re:Supply chains by meerling · · Score: 2

      Except it went dead because someone else intentionally sabotaged it. You do know that in most places that it is illegal to destroy or otherwise intentionally damage or render inoperable someone elses property.

    7. Re:Supply chains by willy_me · · Score: 2

      Tested them all. The only USB to serial devices that worked flawlessly are FTDI based adapters and some from Tripp-Lite (USA-19HS). The advantage of FTDI devices is they work without additional drivers on Linux and MacOS. And unlike the Tripp-Lite adapters, they work with MacOS hosted virtual machines. For some reason the Tripp-Lite driver can not switch between host and client operating systems when hosted by MacOS.

      The FTDI devices are by far the easiest devices to get working and support. Send support an email and they'll provide you with a PID block for your device. They will also sign the Windows driver after being modified to work with this PID. So no annual USB fees or Windows development costs. The little extra you spend to use a FTDI IC is so much less then the other costs associated with low volume products. And who else sells ICs that can also act as a SPI, I2C, or JTAG bridge? And is natively supported by openocd...

      Guess if you are only doing USB->serial then the alternatives are fine. But try to do something fancy or support legacy code on a PC and the FTDI chips have no real competition.

  4. Microsoft's responsibility and WHQL by Anonymous Coward · · Score: 4, Interesting

    What is Microsoft's responsibility here?

    They are pushing out drivers that bricks hardware through their Windows Update service?

    How the hell did this pass their WHQL?

    1. Re: Microsoft's responsibility and WHQL by ZorinLynx · · Score: 5, Insightful

      Yep, Microsoft should revoke WHQL on future driver versions and refuse to certify FTDI drivers in the future.

      This is a blatant violation of trust; end users have no way to know if the FTDI chips in their devices are genuine.

    2. Re:Microsoft's responsibility and WHQL by fuzzyfuzzyfungus · · Score: 3, Insightful

      What I'd be curious to know is how FTDI managed to pull this again. I would have imagined that Microsoft would have been less than pleased with them after their last attempt and either watching them more carefully or only letting them back with some sort of stern warning. One would certainly think that it would hurt FTDI more than it hurts Microsoft if FTDI chips become 'those ones you have to manually download drivers for'.

    3. Re: Microsoft's responsibility and WHQL by Opportunist · · Score: 3, Insightful

      Why do you expect this of all the things in Windows 10 to be in the interest of the end user? Why should this be the odd man out?

      --
      We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
    4. Re:Microsoft's responsibility and WHQL by FatdogHaiku · · Score: 5, Insightful

      I would imagine Windows Hardware Quality Labs tests the drivers against the hardware they are made to support. Requiring anyone to test real drivers against fake hardware would be a Gordian knot as new knockoff distributors appear and then fade away when someone starts trying to find them. I'm sure the same factory would produce the same knockoff and a "new" distributor would get it into the supply chains.

      All that being said, I learned long ago not to let Windows update my hardware drivers, any hardware drivers. I just fixed one the other day where suddenly a favorite resolution on an LCD TV was missing. It took a bit to figure out the latest graphics driver (Intel via Windows update) installed a management program limiting display resolutions. Removed that program (and hid the update) and everything was back to normal.

      Of course, in this case it would not matter where you got the update, if your device is counterfeit it gets tagged.

      --
      You have the right to remain sentient. If you give up the right to remain sentient, you will be elected to public office
    5. Re:Microsoft's responsibility and WHQL by OzPeter · · Score: 4, Insightful

      If Whipslash is reading this - one thing that would be a REALLY interesting addition to Slashdot would be to go find someone from the company to speak to these issues, if possible. Something of an immediate Q&A to either clear up the news or confirm that the situation is as crummy as it appears.

      I don't think that /. will every be able to work like that. Compare /. with Ars. Ars actually employs genuine technical minded journalists and produce long form stories of their own. When appropriate they do reach out to all parties to get comment from both sides. /. on th either hand is really just a news aggregator with a fancy commenting system. If anything it should be up to the producers of the original story to looking for comment.

      --
      I am Slashdot. Are you Slashdot as well?
    6. Re: Microsoft's responsibility and WHQL by Anonymous Coward · · Score: 5, Interesting

      Yep, Microsoft should revoke WHQL on future driver versions and refuse to certify FTDI drivers in the future.

      This is a blatant violation of trust; end users have no way to know if the FTDI chips in their devices are genuine.

      This would be how I'd handle it.
      1) After you login you see a message from windows. Automatic update of FTDI serial driver has failed. FTDI serial driver reports non genuine hardware. Warning the use of counterfeit hardware may cause system instability or other undesirable behaviour. Wouuld you like to disable the previous driver, or continue using it and mark it as non upgradeable? A non upgradeable driver may have bugs and other issues that could, in time, expose your system to threats. Long term use is not recommended.

    7. Re: Microsoft's responsibility and WHQL by Pentium100 · · Score: 2

      In my opinion, this is worse. The previous driver corrupted the chip, but did not do anything else and the chip could be repaired in Linux. However, inserting fake data in the stream is much worse because of how the device might react to it, for example, if such a thing happened with a USB-to-serial converter connected to an APC UPS, it would cause the UPS to run battery calibration discharging the battery. This may not be that bad unless power failed soon after, but if the system is left unattended, the UPS will run the calibration over an over staying at low battery and wearing out the battery in the process.

      What about some industrial machines? the fake data may open/close valves etc causing damage to the machine or even an injury.

      And all this because the manufacturer of the machine was scammed - paid full price for a fake chip (or the chips got switched out in the assembly plant).

      How about making the driver just not work or at most cause bluescreens?

  5. Pure crap by OzPeter · · Score: 2

    Let's hope that nobody dies in an industrial accident when a tech connects their cheap USB-to-serial cable to a piece of machinery and the controller misinterprets the garbage data.

    If a rogue USB to serial connector (on a windows box, with automatic updates no less) can endanger your workers, then your machinery wasn't safe in the first place.

    --
    I am Slashdot. Are you Slashdot as well?
    1. Re:Pure crap by Darlok · · Score: 4, Insightful

      Not necessarily true. Low-level technology like this is frequently the source of "cascading failure" that can endanger people or property.

      For instance, we have many USB-to-Serial devices installed in chains that capture weight readings from industrial scales. If this suddenly and inobtrusively starts causing that measurement data to be misaligned in the output, those weight readings could be transmitted to shippers who may or may not re-weigh the product based on our volume. In the worst case scenario, something like this could be done as the last check-weight for loading an aircraft -- a weight-critical application where getting it wrong can cause a tail-strike on takeoff.

      Screwing with low-level data INTENTIONALLY is never a good thing. End users have no way of ever knowing that it's happening. Pushing it by Windows Update, where no devs are involved to catch the error, is a recipe for potential disaster somewhere.

      This IS Pure Crap... on the part of FTDI.

      --
      Notice: Your mouse has been moved. Windows will now restart so this change can take effect.
    2. Re:Pure crap by sumdumass · · Score: 2

      Nothing and the concept originally imputed as not being safe has nothing to do with machine safety either.

      The control input on many industrial machines are rs232 or some other serial interface and it has been a standard for a long time. You use computers to directly control them in most cases and n some cases, it has the ability to store the commands and replay them. In either case, you have to connect directly to diagnose certain aspects. Whether this is getting the boards to do a self check or to manually position parts to be physically examined, it takes control input in much the same way that would cause the machines to actually run. Some machines are connected to others and with a functioning system, you can stop one while the others remain active but if your serial communications send errant messages, it could effect the operation of other machines in the series or even send the one you are working on into an uncontrolled state.

      And example of this that I can extrapolate from for instance is where I had a CNC lathe with a bearing going bad in the tail stock which also moved the piece to the holder in the milling process directly after the lathing process. We didn't know it was a bearing but we knew produced products were out of spec so we had to shut down, lock out - tag out everything and inspect it. After not finding anything obvious (the bearing was on a bind), we stepped it through the process to see where the error was happening. During this stepping process, you had to stop the machine and manually rotate the spindle to check the sizes and ensure the sensors were reading properly which is not a problem at all (done all the time on manual lathes). If an errant signal is sent, it could move the tool, start spinning the lathe or a host of other uncontrolled things unexpectedly.

      The unexpectedly part is the problem. If you expect something to not have power then all the sudden is does, you do not know you cannot treat it as if there is no power. If your tools are functioning properly, you know the state of the machines. It is not unsafe at all.

    3. Re:Pure crap by phantomfive · · Score: 2

      Low-level technology like this is frequently the source of "cascading failure" that can endanger people or property. For instance, we have many USB-to-Serial devices installed in chains that capture weight readings from industrial scales. If this suddenly and inobtrusively starts causing that measurement data to be misaligned in the output, those weight readings could be transmitted to shippers who may or may not re-weigh the product based on our volume. In the worst case scenario, something like this could be done as the last check-weight for loading an aircraft -- a weight-critical application where getting it wrong can cause a tail-strike on takeoff.

      If a single USB-to-Serial mis-reading can cause a disaster, then disaster is coming. It's a matter of if, not when.
      It might not be a malicious driver that causes disaster - it could be a programmer error, or a hardware fault.

      If a design relies on a single point of failure, then the designer is at fault. End of story.

      --
      "First they came for the slanderers and i said nothing."
  6. here's the safe driver for these chips by raymorris · · Score: 4, Informative

    Here's the safe driver, in the form of source code so you could check it yourself if you want to.

    http://lxr.free-electrons.com/...

    This driver does require a non-crap operating system, of course. Linux, FreeBSD, OpenBSD, etc probably OSX will work too.

  7. Re:FTDI Serial Driver? by drinkypoo · · Score: 4, Informative

    Why would a vendor of a basic USB-Serial port converter bother writing a driver?

    Because the FTDI chip actually works. It's one of the very few USB to Serial chips that has proper timing and signals to make it work with marginal, antiquated hardware. A lot of people trying to use old automotive scan interfaces and the like which interface with serial have serious problems when using other chips.

    I have literally never had a USB device outside of HID or mass storage which didn't need its own special snowflake driver, even though USB has driver profiles for several types of device.

    --
    "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
  8. Going after the wrong people by wisewellies · · Score: 4, Insightful

    Why can't FTDI realise that this kind of behaviour is only going to hurt innocent end users, rather than the people responsible for peddling counterfeit devices? I've bought hundreds of these devices in the past from reputable suppliers, and in precisely zero cases can I determine whether the chipset is genuine or not before purchase. If I can't tell what I'm buying, then why am I being punished when I've bought in good faith? Why can't FTDI instead use existing mechanisms and laws to find the people responsible?

    Of course Linux drivers for these devices work every time, counterfeit or not. Perhaps a different approach might be for someone to take the Linux code and create a decent open-source Windows driver to replace the buggy (i.e. injecting unwanted serial data) FTDI code?

  9. At this point, I think I'd avoid FTDI hardware... by stazeii · · Score: 5, Interesting

    Son of a.... I spent, literally, 4 hours yesterday trying to troubleshoot a 3d Printer (Tinyboy 3D), with it not working. MProg from FTDI said the chip was fine (right vendor and product ID), but it just wouldn't work. I tried every driver I could find. Finally, I uninstalled the driver, disabled wifi, plugged it in, waited for Windows 7 to install the version it knew (2.4 something), used Mprog 3.5 to reprogram the chip as legit (as per: https://www.youtube.com/watch?...), unplugged, replugged (at which point windows reinstalled it again, with 2.4), and suddenly it started working! I can confirm this "Non Genuine" serial data, since I opened up the Arduino IDE and saw that on the serial console. You know, I sympathize with FTDI. They're having their tech ripped off. But, it's inappropriate to punish end users who don't have any say. Sure, we could not buy stuff that uses counterfeit chips, but many sellers aren't even going to know. FTDI should be pursuing the counterfeiters in China, and using what legal system China has to stop it. Either that, or create a version of the chip that has such a low price point, they put the cloners out of business by providing legit-working-alternatives for a price point. So annoying that I've lost time because FTDI does this crap, and apparently Microsoft is okay with it (I don't see how this should have passed WHQL).

  10. Re: What? by drolli · · Score: 2

    If you build something critical, you don't just replace a pat by another just because you may be a few days late.

    In controlled areas (airospace, pharma, medical devices, automotice suppliers) replacing some part by something cheaper without the suppliers of the parts (in this case the driver) certifying that this change is ok will bring you directly to jail. In others, it could also happen that the court considers such a development method to be criminal, if somebody was killed.

  11. Re:At this point, I think I'd avoid FTDI hardware. by JustNiz · · Score: 3, Insightful

    Wait, you're actually surprised that Microsoft is okay with screwing users over something they already paid for?

  12. CH340 works just FINE! by MindPrison · · Score: 3, Interesting

    I'm a big consumer of the Arduino clones (and FYI - Arduinos are FREE to clone for everyone, it's a part of the concept).

    The chip has now been replaced with the CH340 - which even though it lacks some of the FTDI features, is a bang up chip that gets the job done - even at really high Serial speeds, I've yet to see one of them fail on me (I use Linux, where CH340 runs right out of the box, windows needs a driver).

    I've not even heard of the FTDI before all of this came up.

    --
    What this world is coming to - is for you and me to decide.
  13. FTD Driver? by PPH · · Score: 3, Funny

    Those damned florists and their delivery vans!

    --
    Have gnu, will travel.
  14. FTDI is malware by stooo · · Score: 5, Informative

    FTDI is malware.

    Use Linux.
    use MCP2221.

    --
    aaaaaaa
    1. Re:FTDI is malware by TheGratefulNet · · Score: 2

      this is why all the arduinos (nanos and other shield style boards) are moving away from ftdi and onto ch340, pl2303 (not great) or other usb/serial chips.

      ch340 has been fine for me, so far. no driver problems, and so far not caring about fakes vs real ones (if there is such a thing for ch340).

      ftdi can go fuck themselves. I think I need to send more notices to my corp (who does arduino stuff; at least in some groups) and we should stop patronizing ftdi.

      --

      --
      "It is now safe to switch off your computer."
  15. Re:Patent? by RealGene · · Score: 3, Informative

    'Compatible' chips that report FTDI's USB Vendor ID (VID) and Product ID (PID). That way, they don't have to actually write their own driver and get it approved by MS.
    So, when Windows interrogates the device, it appears to be FTDI, so Windows loads the FTDI driver.
    That driver makes an undocumented call that only genuine FTDI chips will respond to correctly, so the driver can tell whether a knockoff part is attached.
    Other legit serial chip makers use their own PID/VID, so it's not an issue with TI, Silabs, etc., only with 'Best Lucky Interface Ltd' parts.

    --
    Mission: To provide products that consume time and energy as entertainingly as permitted by the laws of thermodynamics.
  16. I don't blame FTDI, fake chips hurt them by AaronW · · Score: 4, Informative

    One problem these counterfeit chips pose is that all the sudden companies like FTDI end up with a lot of support costs for people who bought shoddy products with the fake chips, which often don't work nearly as well as the real thing. This is a way for FTDI to crack down on the counterfeit chips. While it sucks for the consumers that end up with the fake chips, it will also help put a stop to the counterfeit chips since any product that uses them will not work.

    At my company we make a number of development boards using the quad FTDI chips for the serial interface. We use them because in addition to RS232 they also can talk I2C and JTAG, among other things. I can reliably run the FTDI chips at 10Mbps. I've used other USB to serial devices in the past but I've had lots of problems with them. Some cables I bought, for example, will just suddenly stop working and I have to periodically reset the baud rates.

    Why should FTDI have to bear the burden and support costs of counterfeit chips? If somebody else slaps the FTDI manufacturer ID and product ID onto their USB device then they deserve whatever happens. Why should FTDI have to spend resources supporting fake chips? By doing what they are doing, it will drive the fake chips out of the system and prevent future ones.

    I work for a chip manufacturer and while there's a very low risk that someone will make fake chips like ours (very complex network processors), we have had to add features to our chips so that our end customers can prevent counterfeit equipment which just copies their software. We have some large customers who have been battling Chinese made counterfeit equipment.

    --
    This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.
    1. Re:I don't blame FTDI, fake chips hurt them by AaronW · · Score: 2

      Just using a counterfeit chip could potentially introduce unintended behavior. I've dealt with a number of USB to serial chips and many of them are crap. I have cables that will just suddenly stop working, or the baudrates that suddenly change. I wouldn't be surprised if the counterfeit chips have similar problems. FTDI should be able to program their chip and expect it to work as designed. If it's counterfeit and it doesn't, then it's not their fault. They shouldn't have to debug problems in counterfeit chips. On top of that, the counterfeit chips eat into their bottom line. FTDI chips tend to be more expensive and for good reason. They're better chips. On top of that they have excellent documentation as well as library support for doing all sorts of things. Want to do i2c or JTAG with their USB to serial chips? It's fully documented with a library to support it.

      I can tell you as someone who writes device drivers that trying to debug problems caused by some unknown counterfeit chip is a nightmare. After all, it's not your job to Q/A not only your own hardware, but cheap Chinese counterfeit chips as well.

      As far as I can tell, sending an ASCII string is probably the best thing they could have done given that they're screwed no matter what they do.

      --
      This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.