Live data from Hacker News

FTDI removes counterfeit-bricking driver from Windows Update

eevblog.com

41–50 of 131 posts

Re: FTDI removes counterfeit-bricking driver from Windows Update

#41
That's a good lesson for people always wanting the famous brands. FTDI chips are more expensive and not better than the other ones, they need a special driver and they are subject to counterfeiting. You take a no-name one, and you have a standard stuff.

It's a stupid USB to RS232, not a rocket control system, there should be no famous brand, it's the lowest of the commodities.

That said, I do have an FTDI USB to serial adapter (no idea of the authenticity), because I didn't know better or care, I needed to plug my MCU board to my computer and I bought the first one I found (and it's just used for debug, I never ever use serial in real life).

Re: FTDI removes counterfeit-bricking driver from Windows Update

#42
post #32

Earlier quoted context omitted.

And that's assuming it's actually counterfeit. Can you imagine the storm if "isCounterfeit()" turned out to be less than 100.000000% accurate?

Yeah, but looking at the physical differences between the chips it's probably not something that difficult to ensure. The counterfeit chips are built in a totally different fashion, with different size and materials, on a different process tech. http://zeptobars.ru/en/read/FTDI-FT232RL-real-vs-fake-supere...

But that's impossible for something like a Windows driver to determine.

The only way the FTDI driver could determine if the chip counterfeit was a slight difference in how the counterfeit chips handled a certain EEPROM write. And the counterfeiters will be sure the next revision of the chip takes care of this corner case.

Re: FTDI removes counterfeit-bricking driver from Windows Update

#43
post #28

Earlier quoted context omitted.

I don't think that is very straight forward. It's easy to know how your device will operate in various conditions. counterfeits can fail in a million unpredictable ways.

FTDI have code which can tell with some high degree of certainty (at least enough that they trusted it to brick devices!) that a chip is fake. They've used this code to make counterfeits intentionally unpredictable in the last few versions of their driver, rather than simply stopping the device with an error code (like Prolific do) or notifying the user or client library (like all of these vendors should be doing). S…

They might not have the ability to do that - I could quite easily see the bit of code that can tell if its fake being the same code that bricks the device. Maybe all the real ftdi chips will reject a PID of 0 (as it's invalid), while the fake ones accept it.

Re: FTDI removes counterfeit-bricking driver from Windows Update

#44
Their best course of action:

- unbrick devices they bricked, so the chips will at least work with drivers other than theirs

- log something to the windows event log about a clone device being detected

It's their choice whether they should work with the clone device or not; I would hope they would choose to. I understand their reluctance, but people are going to be only slightly less mad about a device not working than a bricked device.

It would be bad for their driver to pop UI warning about a clone device. Drivers that do this make life very, very difficult for devices attached to headless servers (also, I believe it's against the MS WHQL rules).

Re: FTDI removes counterfeit-bricking driver from Windows Update

#45
post #7

There should be lawsuits. I really hope a class action gets started with people who were bitten by this. I'm serious. This kind of behavior needs to be nipped in the bud and made a massive example of, or else we will see it in the future.

We do not want to set a precedent whereby a company responds to customer feedback, and then gets hit by a huge lawsuit anyhow. That just incentivizes companies to dig their heels in, because it means there's no change in outcome between speedily responding and trying to stay the course, at which point staying the course is the only sensible choice. There's a time and a place for mercy, and giving positive feedback to…

I'm totally happy setting a precedent where malware (let's call it what it is) distributed by a company causes financial damage to that company.

I'm guessing they've already done plenty of self-inflicted financial damage that they're going to have to explain to their investors.

Re: FTDI removes counterfeit-bricking driver from Windows Update

#46
post #38
post #36

Earlier quoted context omitted.

Just playing devil's advocate: Do you have any evidence specifically that their driver destroyed your chip, or could there be reasonable doubt that your counterfeit chip died? For a class-action suit that a lot of people seem to be talking about, you would have to have evidence that this was what did your chip in. And getting enough people (who appear to be mostly end-users) to submit the necessary evidence could be…

It's very easy to spot, as the driver 'bricks' the chip by resetting it's PID.

well, the PID is not a physical thing. So for the average user, "the board just died on my one day". Getting wide-spread testing and evidence submitting would be challenging I think.

Re: FTDI removes counterfeit-bricking driver from Windows Update

#47
post #12

I disagree with the consensus. It's their driver, it operates in a specific way, perhaps responding to possible device output. Using it with non-compatible parts advertising themselves as compatible and any resulting behaviour, including unwanted, is the responsibility of the user. To play it safe, don't use any drivers with incompatible hardware.

You'd be right if this weren't just a chip buried in a device. To properly implement that, we'd need to be able to safely scan and verify devices on the chip-level. That's not really an option. The end user is only ever going to be informed by the driver telling them it's invalid; in this case the notification is the silent crippling of the gizmo, with no feed back or diagnostics. As many have noted, all that's neede…

Alerting the user from a driver is a bad, bad thing.

I believe it is not allowed by WHQL certified drivers.

(It's also non-trivial to do in a Windows kernel driver. You can't call MessageBox(), you can't process user input, you can't even get a context to draw on the screen. Basically you have to rely on a user-mode helper app that gets launched at boot time, which is one of the reasons you see so many device-tweaking utilities for graphics cards and sound cards).

Re: FTDI removes counterfeit-bricking driver from Windows Update

#48
post #28

Earlier quoted context omitted.

FTDI have code which can tell with some high degree of certainty (at least enough that they trusted it to brick devices!) that a chip is fake. They've used this code to make counterfeits intentionally unpredictable in the last few versions of their driver, rather than simply stopping the device with an error code (like Prolific do) or notifying the user or client library (like all of these vendors should be doing). S…

They might not have the ability to do that - I could quite easily see the bit of code that can tell if its fake being the same code that bricks the device. Maybe all the real ftdi chips will reject a PID of 0 (as it's invalid), while the fake ones accept it.

Their drivers prior to the bricking drivers (everything after 2.08.14) caused the fake devices to fail, where previously they hadn't.

Whether or not that behavior was intentional, there is clearly an exploitable property of the fake devices which can determine that they are fake without bricking the device.

FTDI should use it rather than playing these games. Their reaction to the discovery of the bricking issue on Twitter and elsewhere yesterday strongly suggests that it was anything but an "oh shit, our driver bricks some of those crappy fakes" moment.

Re: FTDI removes counterfeit-bricking driver from Windows Update

#49

It's also important to keep in mind that the driver bricked not only counterfeits that were illegally marked with FTDI's name, but legal clones (reverse-engineered reimplementations which are not marked as being from FTDI) that had the same slight difference in behaviour from the original.

The reverse-engineered reimplementations / clones would have to have been programmed with an FTDI VID (or included modified FTDI drivers) in order for the FTDI drivers to claim them, so I'm not so sure about the "not marked as being from FTDI" bit.
Post reply on HN