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?
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.
"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.
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?
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.
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.
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.
(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?
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.
marcan:
"In case anyone was still wondering if this is intentional and malicious...
Straight out of their driver. Function/variable naming and comments mine.
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.
> 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.
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.
Tangentially: people totally would fault FTDI for releasing drivers that don't work with counterfeit parts. See: Apple detecting and rejecting counterfeit iPhone cables.
The correct way is to detect counterfeit parts, display a huge warning and let the customer continue on their own risk. A similar process is used by the Linux kernel developers for non-opensource kernel modules: If you load them, the kernel becomes "tainted" and you won't get any support from the kernel developers if something goes wrong.
"bricking" doesn't seem to be the right word. FTDI is making it so that the counterfeit chips don't work with any FTDI drivers, old or new. (Per the thread, all that happens is the PID is changed to a PID that no FTDI driver will recognize)
It's not that they just won't work with their drivers, it's that it disables the device so that it's not operable without special (and costly, if they're widely deployed) intervention.
The new Windows driver changes the PID to 0, and then the driver won't
recognize the device (even if you edit the INF file), and you can't use
the config tool. The workaround is to use a Windows XP or Linux system to
change the PID back, and then don't use the new driver.
Seems an awful lot like bricking to me.
This is really skirting the ethical line and I'm not sure I can agree with their methods. I'm fine with them writing a driver that fails to work with counterfeit chips, but not actively disabling the chip. What if the device is attached to more expensive equipment that will also fail? We can't ensure that these chips are knowingly purchased after all.
This motivation reminds me of when the U.S. and Syrian governments disseminated sabotaged munitions that explode in the weapon, killing/maiming the operator, among their opponents. The danger is that they will find their way back to friendlies.
I don't think so. There was at least one guy in the thread who reprogrammed the PID back, and the chip worked with the old FTDI drivers again, which means the USB interface was working just fine (or else how could he access it to change it back).
Having to write custom driver-level code to repair something falls pretty well inside the accepted usage of "bricked". It's only marginally easier than just hooking up a JTAG interface.
They change the PID to zero, which means Windows won't associate it with FTDI or any other driver. You have to jump through some manual hoops to undo it, which is something most people can't do. So for all intents and purposes it is bricked, a.k.a "locked out".
Most HN'ers seem to agree it is OK for FTDI to prevent their own drivers from working with the fakes, right? The fact that there are no OTHER drivers that are compatible (no matter what the pid is) with the fakes isn't their problem, is it?
It is NOT OK to modify the HARDWARE in ANY WAY, including changing the PID.
That is the issue.
Further Most people defending FTDI assume this code will be 100% pure and never incorrectly identify a real chip as fake, I find that claim to be suspect.
Lastly I would find it very hard to support vendors that take these aggressive risks and stances, I certainly would never incorporate a device from a manufacturer that uses these types of tactics into a mass produced product.
Honest question: are you participating in this thread as a greenbean because you want to hide your identity from harassment from those who disagree with your unpopular opinion, or because you want to hide the fact that you are affiliated with FTDI?
Honestly? I rotate accounts on most major sites periodically. It is a tinfoil-hat foible, a way to distance myself from the exceedingly dumb things I have almost certainly said in years past.
Unfortunately for me, I chose today to rotate.
I don't work for FTDI; I'm not even British. But I did build that Adafruit altoid tin MP3 player eight years ago, which used a FT232.
Why am I wasting my time on this argument? I don't really know, aside from I hate the "internet dogpile" effect.
My credibility as a greenbean is nil of course, but oh well.
Edit: obviously folks do not believe me. Serves me right for trying to answer. jessaustin, I hope you at least feel like you got your answer. I get the feeling it doesn't actually matter what I say or even who I really work for- I'm branded.
I didn't downvote any of your posts and I believe you when you say you're not affiliated with FTDI. But I vehemently disagree with your stance that the sabotage of hardware is warranted or even that it's a minor inconvenience.
Let's take this from another point of view:
You purchase a device or some piece of hardware for a project which becomes useful to others and you decide to make the project marketable and release your own line. You source your components and one of them happens to have an FTDI chip that you believe legitimately came from the company. Your project is accepted by others and everyone is happy.
Then one day, your supplier decides to switch out a source for the chip in one of the components of your project to one that's cheaper (the supplier may not suspect these are counterfeit). You don't see any difference either as you haven't tested it with the latest driver, which may not be out yet. The project is now shipped.
A new driver is released. An overwhelming number of customers now hit your support system saying the update has stopped your project cold. Rolling back the update has no effect. You don't know which component caused the problem as your project uses several from different suppliers. It may take days or even weeks to track down the problem, but meanwhile, your customers grow angry.
This is now your fault and you're left holding the bag.
This scenario need not be hypothetical, as this is just the same as GM "fixing" a problem with their ignition switch that has already claimed lives, but leaving the part number the same. This makes recalling a nightmare as there's now no way to tell which cars are affected until the switch fails or someone dies again.
Just the same as there's no way to tell which one of your project's components carry counterfeit chips and you need to issue a recall for potentially 100K units since you don't know which ones carry a counterfeit and there's no software fix anymore as the chip is bricked. Your project is also potentially being used in mission critical infrastructure that cannot be shut down to do a test without costing a lot of money. Better hope no one follows "best practices" and updates the driver as it may also contain a security fix.
FTDI is well within their rights to protect their product. But are they doing the ethical thing by costing unsuspecting customers and potentially hundreds of other businesses that rely on their product valuable time and money? All for not knowing that somewhere along the supply chain, someone cut a few corners and got their chips from a counterfeiter? Should they be victims twice; once by the counterfeiter and again by the company?
I hope you at least feel like you got your answer.
Yes, I take this answer at face value. I didn't really think there were only two possibilities here. Perhaps I was a bit blunt in the hopes of eliciting a "real" answer like this one.
It's interesting that you're more eager to dispel the notion that you work for FTDI than that you support the crime of destruction of property. You need to think long and hard about the direction of your moral compass.
It's asshole behavior to put code in their drivers specifically to detect and abort even trying to work with fakes, but they are fully entitled to do so.
They are not entitled to break the hardware by changing the PID so it doesn't work with any drivers.
There are other drivers that work when the PID is left intact.
Well, FTDI is leaving their vendor ID intact, and given their behavior so far it wouldn't surprise anyone if they tried to interfere with third-party drivers that enabled using non-FTDI hardware identifying itself with FTDI's vendor ID.
So? Does anyone actually think that fact will somehow make FTDI want to be more reasonable? They'll just say that those devices being hard-coded to spoof FTDI's VID is further justification for mistreating them.
There is no apology sufficient for maliciously and intentionally damaging the private property of your customers.
Refusing to work with counterfeit hardware is entirely appropriate, destroying it in a way that most consumers cannot recover from is in no way acceptable or defensible.
You may as well have come into my home and destroyed my cookware because I bought a stove from you and the pots I had weren't your brand. It's uncalled for, inappropriate, unethical, and immoral and I'm not certain that it's not illegal. Your employer has no leg to stand on.
FTDI is almost certainly trying to exercise IP rights that don't actually exist, because breaking other people's stuff is not an authorized method for dealing with trademark infringement.
Then they don't have any options, period. But if someone slaps a Toyota badge on a car and takes it to be serviced, Toyota don't suddenly have the right to instead smash the car with sledgehammers.
... thus they have moral right and obligation to damage the hardware belonging to other people because some other people don't recognize their "IP rights"?
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?