Hacker News Reader

Comment by Someone1234 | Hacker News Reader

Microsoft should revoke the driver's signature via their next CRL update, so that it refuses to install (effectively making the drivers unsigned). It is acting maliciously and will break consumer's hardware, even hardware which doesn't contain any FTDI chips.

If FTDI have an issue with a company ripping off their IP then go sue that company. But what they're doing is catching consumers in the firing line, who will wind up with multiple dead USB devices. There's no reasonable way a consumer can know they are buying something with a fake chip and this could kill devices years old, which will be outside of warranty.

I am totally serious that Microsoft should step in. FTDI's driver is so defective that it is literally killing hardware, if they won't step in for this then what will they step in for?

View on HN

Can we be sure that FTDI has programmed their driver with malicious intent? It may be that this an accidental side-effect of using counterfeit hardware with a genuine driver.

Without access to the source code or a well-reversed disassembly of the FTDI driver, and a good grasp of the logic used in the counterfeit chip, one cannot be certain about this. And surely not to the extent of urging Microsoft to revoke driver signatures.

I don't know if you can be sure, but almost certainly MS can.

It shouldn't matter what their intent was. If the new version of a network driver accidentally started DDOSing servers, it should also be pulled, regardless of whether the vendor did it on purpose.

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?

Seems like there's a few people who don't seem to understand the difference between copyright, trademark, criminal and civil law (op above you included).

The only law broken by the counterfeiters is trademark violation for printing the FTDI logo on their chips. That's it! Everything else they did was legal. Otherwise, Intel and AMD would be bricking CPUs right now.

Reverse engineering is legal. Emulation is legal. Creating hardware that's compatible with another vendor's software is legal. Flashing your hardware with another vendors firmware is legal. Modifying hardware you purchased from a vendor is legal. Modifying software you purchased from a vendor is legal.

etc... etc...

Going with your example, if AMD uses "Core" or "Xeon" in the name of their chip, it is most likely infringing the trademark of Intel. But in this case, it's more like AMD is simply branding their chip with exact Intel product name and sold as if it's from Intel. I don't think this is a trademark issue any more, it's more like fraud.

Does anyone even know what entity designed and made the fake FTDI chip?

I find many people don't seem to understand what making compatible chip means. It's very common to have legitimate, drop in replacement for popular ICs. But this fake FTDI chip is certainly not the case here.

No, it's trademark and trademark only. Generic medicine puts on the label of their products "compare to brand name XXX." There's nothing wrong with this. As long as you don't impersonate another companies mark. Is it a flagrant violation? Sure. Doesn't change that this is still (only) a civil matter.

Wouldn't flashing your hardware with another vendor's firmware, thereby distributing said firmware, be copyright infringement?

Only the distribution, and even then only if the firmware is eligible for copyright protection. Purely functional configuration data like vendor and product IDs aren't copyrightable.

Well... The Fake's logos are significantly fatter than the FTDI logo. It spells FTDI, but it's not the FTDI logo....

:-)

(I'm speaking more from a moral standpoint than a legal standpoint. IANAL)

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?

They basically admit it on their license page:

http://www.ftdichip.com/Drivers/FTDriverLicenceTerms.htm

"Use of the Software as a driver for, or installation of the Software onto, a component that is not a Genuine FTDI Component, including without limitation counterfeit components, MAY IRRETRIEVABLY DAMAGE THAT COMPONENT."

Even though their TOS might state that, it's extremely poor PR to go after the end user rather than the distributor. Most people won't even know that they have a counterfeit chip. Even though it may be well within their rights the customers will eventually find out what they have done and bear a grudge.

May cause more problems than it fixes.

It appears that from @FDTIChip's twitter stream that in fact they do think that this ambiguous license clause makes it OK to deliberately destroy hardware. https://twitter.com/FTDIChip/status/524918979840585729

A statement being in a license does not imply intent, it is there to protect them if they accidentally do damage. "may damage rip-offs" doesn't mean "will intentionally damage rip-offs", it means "we won't care if it accidentally does damage rip-offs, we can't test out code against every rip-off on the market, you paid your money you took your choice".

Of course if they have deliberately broken people's hardware that is a different matter, that clause in the license does not give them permission to in any way (either by my reading of the wording, or my understanding of how the law usually works in such cases).

Of course they should roll back the drive and investigate, but what if the problem is due to a new feature that can't be implemented some other way, and there is no way to detect a "genuine" chip? Should users of their chips do without a feature (or have to mess around opting in) because some other manufacturer's chip has a problem with it?

http://www.eevblog.com/forum/reviews/ftdi-driver-kills-fake-...

marcan: "In case anyone was still wondering if this is intentional and malicious... Straight out of their driver. Function/variable naming and comments mine.

https://marcan.st/transf/ftdi_evil.png

I figured out what's going on with the real chips: turns out their EEPROM is written in 32bit units. Writing to even addresses is ignored; the value is buffered and the address discarded. Writing to odd addresses writes the entire 32bits, using whatever value was last buffered for the other half. So both the PID write and the checksum write are ignored on real FTDI chips, as they are both written to even addresses. I still don't know why it works on clone chips though, since the checksum is written to the wrong place (it should normally be on an odd address); presumably they don't check it."

Basically driver is fuzzing 'chips claiming to be FTDI' with illegal instructions. Want to play clone games? better emulate me completely, otherwise tough titties. I like it. Might not work to well for FTDI in the end due to PR nightmare, but from engineering standpoint its quite brilliant.

So, definitely intentional then. They went to quite some effort to fix up the checksum by calculating and writing a suitable value to the address before the checksum location (updating the checksum would cause a write on genuine FTDI chips because it's an odd address). If they'd just written the VID as zero, presumably the checksum would fail and the device would revert to a default, non-bricked configuration.

They write bad checksum, fake doesnt care.

Intent doesn't matter if the patch is causing damage.

There are legal routes available to FTDI that don't involve bricking devices. I'm guessing that FTDI didn't talk to internal counsel before making this change.

I'll be quite surprised if Microsoft doesn't pull this patch.

Isn't the WHQL process supposed to vet for malware like this?

They may not be WHQL certified, per Wikipedia:

> A company can choose to sign their own drivers rather than go through the WHQL testing process. These drivers would not qualify for the "Certified for Windows" logos, but they would install on 64-bit versions of Windows and install without a warning message on 32-bit versions of Windows Vista or Windows 7. However, it will not install without a warning message on Windows XP.

If they are, I don't know enough about how rigorous Microsoft's certification process is now to comment. It used to be just looking for things that would cause kernel instability but it seems the standards have increase a lot since its exception.

But they are pushed through Windows Update? Doesn't everything there have to be WHQL?

Correct. To use the non-MSFT signed approach, the driver has to add the cert to the registry beforehand somehow (eg. using certutil -addstore -f TrustedPublisher), which obviously rules out a straight install using Windows Update.

I would be surprised if WHQL tested drivers on counterfeit hardware.

Reply on news.ycombinator.com