Hacker News new | past | comments | ask | show | jobs | submit login
FTDI driver kills fake FTDI FT232s (eevblog.com)
342 points by stoey on Oct 22, 2014 | hide | past | favorite | 306 comments

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.

They basically admit it on their license page:


"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."

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

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.

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.

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?

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.

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


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.

They write bad checksum, fake doesnt care.

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.


Nobody would fault FTDI for releasing new drivers that don't work with counterfeit parts.

That alone would cause enough inconvenience to manufacturers to make sure they use legitimate parts.

It's the (unethical) bricking of the parts that has everybody up in arms.

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.

Yes, this would be smart.

Probably just putting a message with priority "Error" in the windows event log would be enough to warn computer-literate users.

Yes, people would fault them for removing functionality.

The problem in that case is not the actual new drivers, but the process of uninstalling the old working drivers.

"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.

Or any other drivers, because it breaks it at the USB level, doesn't it?

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 ok to have SOFTWARE that refuses to work

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.

According to the thread the VID is RO?

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 are other drivers, on other operating systems that are NOT written by FTDI.


Right, I forgot, anyone who isn't part of the lynch mob is a shill.

I rarely eat breakfast in the first place, sadly.

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.

> because breaking other people's stuff is not an authorized method for dealing with trademark infringement.

The device violates the USB specification by using a protected VID; it is already to be considered as broken regarding the USB specification.

Just because a car's missing its wheels doesn't make it legal to steal the bumper.

And in this case, the car's only missing the hood ornament.

> And in this case, the car's only missing the hood ornament.

A more appropriate analogy would be a car that has its chassis number filed off and written back on with black marker.

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"?

What's you point here?

If anyone is curious what a real vs fake FTDI chip looks like under the hood (de-capped chip) this is a great analysis and some beautiful pictures.



"What's the economic reason of making software fake of well-known chip instead of making new one under your own name? This way they don't need to buy USB VID, sign drivers in Microsoft, no expenses on advertisement. This fake chip will be used right away in numerous mass-manufactured products. New chip will require designing new products (or revisions) - so sales ramp up will happen only 2-3 years later. Die manufacturing cost is roughly the same for both dies (~10-15 cents)."

I've seen that one before but what caught my attention this time was the "(M)FTDI FEB 2005" line - the design is approaching 10 years old, and the significance of that is the fact that IC layouts ("mask work") are only protected for 10 years by copyright law:


It's also completely legal to reverse-engineer an existing IC to duplicate its functionality in a different manner, which the cloners have definitely done in this case - they are completely different.

So it appears that the only thing the fake FTDI chip is violating is the trademark "FTDI", which might not even have been put there by the fab that produced the die, since they're branded 'Supereal'.

+1 for the fake chip name. "Supereal" takes the cake

"Supereal" might not be the name of the fake itself, it might be just the name of the mask-programmable microcontroller they used.

"It seems that in this case Chinese designers implemented protocol-compatible "fake" chip, using mask-programmable microcontroller. This way they only needed to redo 1 mask - this is much cheaper than full mask set, and explains a lot of redundant pads on the die."

What is the HN crowd's preferred way of dealing with that kind of parasite?

If someone makes a compatible chip from scratch then they are not a parasite, they are a competitor.

Not if they label the "compatible chip" as the genuine ones.

But how is the driver to know what's written on the chip?

You mean how the driver tells the counterfeit apart? I don't really know. One possibility is that the counterfeit didn't copy some of the "don't care" cases exactly.

You completely missed the point. The driver cannot possibly know the difference between a chip falsely sold as being an FTDI chip, and one that is compatible without being mislabeled.

I got your point now. But then my comment was trying to point out that a "compatible chip" isn't really competing if its branding is deceitful. Whether it's possible for a driver to tell the difference between counterfeit and legitimate compatible chips isn't really relevant here.

Besides, any legitimate compatible chip vendor will need to have their own VID, which also means they need to develop their own compatible driver.

VIDs are not legally protected marks.

Unless there's a valid patent at issue (and nobody's mentioned a patent at all), there is nothing about the chips themselves that violates any law.

Defending vigilantism is disgusting enough when you have a colorable argument that the target of your act is the only one harmed, and is actually guilty of some sort of legal violation.

Here, however, you're defending vigilante destruction of the property of end-users who bought a product with a chip in it that, without the user's knowledge, may or may not have passed through the hands of someone who may or may not have labeled or described it deceptively.

The deceptive party may not even exist, and even if they do, they are not the victim of the vigilante justice. A user who may not have even heard of FTDI is the victim.

I agree that punishing the users of the product that contains the fake chip is a very bad idea.

Again, I'm merely trying to express my opinion that this way of making compatible chips is a very shady practice (and unlike that original comment I replied to was implying, typical market competition). Most users didn't choose the chip just because it's compatible and cheaper. They bought it thinking it's the legitimate FTDI chips with (very specific) guarantees from its manufacturer's datasheet.

> Most users didn't choose the chip just because it's compatible and cheaper. They bought it thinking it's the legitimate FTDI chips with (very specific) guarantees from its manufacturer's datasheet.

Eh....... Lots of people knew/know they are/were getting counterfeit chips. It's certainly shady, but if I were a chinese company making these, I'd simply not use the logo anymore and then sue the pants off FTDI.

Really? I can understand people might want to cheap out for personal projects. But there's no way I'll use it knowingly at work.

Ohh, I agree. I meant that a lot of the makers kind of knew about it. I doubt anyone would spec it in a BOM.

From FTDI's point of view, their driver's are not free, they are distributed for use by FTDI customers. FTDI doesn't want their drivers to run on non-FTDI chips regardless of whether they are marketed as real FTDI chips or not.

Counterfeit isn't the issue here so much as competing non-FTDI chips relying on FTDI to do the hard and expensive work of developing drivers for them.

Bricking non-FTDI hardware was extreme and guaranteed to make people angry. I wonder what the reaction would be if FTDI had instead made the driver not work on non-FTDI chips unless the end customer bought a license key from FTDI to use their drivers.

It'll be very interesting if they start making them as competitors now? I mean, they could.

This will not do wonders for FTDI's credibility. Indeed, it could very well put them out of business for good (from past experience), and we already know whoever's behind these clones can make a chip that does the job at a price people want…

Then any parasitism is restricted to trademarks rather than trade secrets, patents, etc. Who cares about trademarks?

After giving this some more thought, it's no longer clear to me that a simple {vendor, product} id pair is even "protected" by trademark. It would be protected by contract terms, especially if at some point in the supply chain someone had signed a contract with USB-IF. However it's quite clear that no entity is entitled to commit vandalism in order to enforce contract terms for a contract to which that entity is not even a party.

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.

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.

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.

We're talking about bricking a serial to USB chip, not something worth shedding blood really.

We're talking infrastructure: if this was a civil engineer designing a road to spontaneously create potholes that would flatten tires on certain brands of vehicles, they'd be put in the slammer post haste. FDTI has no idea where their chips and drivers will end up, and as designers of such low-level infrastructure type devices, it is criminally negligent to intentionally brick hardware. If I designed a file I/O library to randomly corrupt data when used on Windows, I'd be criminally negligent.

As far as unethical behavior by corporation is concerned I really not think it's even noteworthy.

Destroying other people's hardware to try to ensure your profits? No, not unethical or noteworthy at all.

> if this was a civil engineer designing a road to spontaneously create potholes that would flatten tires on certain brands of vehicles, they'd be put in the slammer post haste

And if a civil engineer designs a bump in the road that will destroy your suspension if you are driving above the speed limit they have set, we'd just call it a speed bump

> Destroying other people's hardware to try to ensure your profits? No, not unethical or noteworthy at all.

I said it was unethical.

I say it might not be noteworthy when you compare it to business who are actually hurting human beings right now: companies who destroy ecosystems, companies who employ underpayed workforce in sweatshops to increase their profit margin. Companies who sell tools and weapons used to oppress people in authoritarian countries. I could go on for a long time enumerating the list of unethical behaviors in the industry before I hit the "releasing drivers that willingly brick IP infringing copies". So yes I find your reaction a bit over the top even if you're right that they deserve to get some backlash for this type of shoddy behavior.

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?


As mentioned elsewhere, it's almost impossible to make sure parts like these aren't counterfeit. And the parts aren't "junk", they're just unlicensed.

Whoever is in charge of sourcing for life-critical application and let the sketchy part slip in should be held responsible for it.

>the parts aren't "junk"

You don't know for sure. How likely is it that the manufacturer of the knock-off part performed full characterization of their chip to ensure they are within spec limits of the original manufacturer? What if the chip starts sending wrong bits when the temperature gets a bit high or voltage supply fluctuates somewhat? Don't you think getting disabled by driver might even be a less disastrous failure mode in this case?

Not any more. Now you can just test the prototype to see if it runs the FDTI driver correctly. If it fails, your supplier doesn't get paid.

Um... how exactly do you think the electronics business works, because it's nothing like what you just described. The vendor is often 3 to 5 times (or more) removed from the sourcing of individual components.

hah... Assuming the prototype is actually identical to the delivered product. People who want to skim money off the top aren't stupid, the prototype will probably contain the specified part and so will the first few lots. To insure validity of every part you need to test every part.

I don't think testing every single unit is reasonable. Luckily we have Random Sampling which typically works quite well. :)


OK, let's run with this a bit. Seems simple enough if you make a single pcba, but what if you're a company like sony and your product has 8 different pcbas in it, some source from other companies and some designed an manufactured in house. Whose testing process should screen the counterfeit chips? If a violation is found, who is liable? Someone has to be, because there will be a cost to the end user when the things go belly up. Also, why the hell would anyone have thought to do this in the past? I work in testing and no one creates a QC process to check for fakes during the PCBA process. You don't test the chips when you're manufacturing the board, you test the integration. Doing a full functional verification of every component during PCBA is really dumb.

No matter how you slice it, this is lunacy. FTDI was extremely short sighted here and any competent engineer or product manager will see this as a sign to be weary of incorporating FTDI into future designs. You don't want your component manufacturers playing shady stuff like this. Supply chain management is complicated enough without having to worry about devices getting bricked weeks, months, or years after you've done the engineering work.

I think standardizing the interface would be more important.

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.

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-cont...

of course you realize those chinese clones NEVER EVER shipped with genuine FTDI chips in the first place, right?

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.

Of course it matters, yesterday "includes fake, but cheap ftdi" was the desired feature.

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

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.

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.

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 "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-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.

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).

> 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.

As long as the money comes in before it's discovered, there will be people who take that chance.

Someone submitted a (parody) patch to do just that!


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.

It's interesting to consider from a legal perspective exactly why this isn't something a company is allowed to do. (Assuming the company did in fact intentionally damage people's chips, reversibly or not -- sounds like we don't know for sure yet?)

- Intentionally sabotaging someone's stuff, legally, is more or less the same as intentionally taking it. Keying a car and driving it away might have different names but are on the same scale.

- There ain't no self help. If you think someone else's stuff should actually be your stuff, your path is through a court.

- We don't fix things with injunctive relief that can be fixed with money. When Apple proves that Samsung violated a patent or vice versa, we don't collect and burn all the infringing phones, we just make someone cut a check. Because we are not idiots.

- The "someone" who cuts the check is Samsung or Apple, not their customers. As far as I know no one's managed to go after end users, even in extreme cases like a $10 designer handbag where the buyer obviously knows it's not real. (And it's at best unclear whether going after the buyers would make any sense, even in those extreme cases -- if someone pays knockoff prices for a knockoff product, it's the seller and not the buyer who has ill-gotten gains. There might be some additional reputation damage and lost profits that the buyer is complicit in, but it makes a lot more sense to me -- and apparently everyone else -- to make the seller pay for those as well.)

- When you do go after the seller of trademarked goods and want to seize those goods, we actually have a procedure for that -- Section 34 of the Lanham Act.[1] Which includes a whole bunch of protections like swearing out an affidavit, getting permission from a judge, informing the attorney general, posting a bond to cover damages, conducting the seizure through government agents, and keeping the seized items in the custody of the court. It's very much unlike showing up at someone's house and breaking their stuff.

(I am a lawyer; I am not a trademark lawyer; I just googled some stuff based on vague memories from law school to write this.)

[1] http://www.bitlaw.com/source/15usc/1116.html

* we don't collect and burn all the infringing phones, we just make someone cut a check. *

Destruction of trademark-infringing goods and copied media is quite common, though.

In the UK, deliberately sabotaging hardware with drivers could be counted as a violation of the Computer Misuse Act, but there are hardly ever any prosecutions under that law.

Destruction after due process and by the proper authorities, yes. After all, it's a reverse engineered product. How does the software know that it's got FTDI stamped on it? Everything else is just implementation details.

These guys are apparently Glaswegian, so Scottish law. Computer Misuse Act territory, perhaps, in my (lay) opinion?

They aren't the first to do malicious copy-protection. It did not go well for the previous contenders. At all.

They may be from scottland, but I bet anyplace they distribute their driver can claim jurisdiction. After all, the crime (or tort or whatever it is) is not writing the offending driver, but distributing it to an unsuspecting public.

One could argue that using the official driver with counterfeit chips is outside intended purpose of the official driver, at which point the user is proceeding at his or her own risk.

I think the counterargument (elsewhere in this thread) is pretty persuasive -- that this defense won't help much if you intentionally set out to damage counterfeit chips.

Think about it this way. Suppose the driver works like this:

``` if(counterfeit()){ // do something harmful to the identified device } ```

If you have a counterfeit chip, and you run the driver, and the driver breaks your chip, then you are in fact using the "official driver" for its "intended purpose." Its intended purpose is to break your chip, and it works just fine. It just lied to you about its intended purpose in order to persuade you to install it.

Of course if the code does something that is safe and useful to do on the legit chip, and just happens to break the counterfeit chip, that's very different. I don't claim to know which thing is happening in this case.

In this case the driver is executing two writes which a legitimate chip would ignore, but which the counterfeit responds to and actions. Those writes just happen to be the position in the counterfeit's EPROM where the USB PID is stored, and just before where the checksum is stored.

"just happen"

In what universe can them doing a preimage attack on the checksum "just happen"?

I think you'll find I'm not in any way suggesting that it was a coincidence. It's a classic Electronic Counter Measure, exploiting the behavioural differences between the 'real' and 'fake' hardware - EXACTLY the same kind of thing you'd see being executed against pirate pay-TV smartcards, for example.

I think if somebody steals your bike, they ride it away at their own risk, but...

* That doesn't mean you can shoot them as they ride away.

* It also doesn't mean you can booby trap your bike.

But if I shoot myself while driving in nails with the butt of a handgun, no one would blame the gun manufacturer.

you can if they release a patch that makes hitting the butt of the gun a firing mechanism without telling you... Also, can we agree that a gun metaphor is rather ridiculous?

Regarding going after buyers, if potential buyers know that buying a counterfeit item puts them at legal risk, I think the market for said counterfeit items will shrink substantially. I think that could be a potentially convincing argument in the case of items where the buyer clearly knows (or should know) that the item they are buying is counterfeit. Is it really all that different from receiving stolen property, which IS illegal?

I think in the FTDI case, though, it would be really hard to argue that the end users should (or even could) know that the chip they have is counterfeit.

What would FTDI be able to go after them for? The end-user isn't copying anything so they can't run afoul of much with regards to copyright law, they know they're getting a counterfeit so they're not being fooled by trademark infringement and probably only care about the functionality of their ICs anyways, and the internals are completely different so the patent risk is minimal.

FTDI have been anti-consumer for years - their last several drivers have introduced intentional instability and Code 10 errors for suspected counterfeit devices.

I think this is totally crappy. I see what they're trying to do (create market incentive for consumers to insist on real FTDI chips) but the reality is that it's just screwing over innocent consumers who buy a device.

screwing over innocent consumers who buy a device

The consumer isn't exactly innocent.

Hold on, hear me out.

It's similar to black market goods. A consumer wants the lowest possible price. It turns out the goods he bought are stolen property. He didn't know, but he is not waived of responsibility. If he was truly unwitting he will not be prosecuted, but the goods will still be repossessed, etc.

Basically, it is the consumer's drive for the lowest price that creates the market for these illicit goods, so they are not blameless. Additionally, illicit supply chains are hard to attack and often times the consumer "really should have known better", so one of the ways to attack that supply chain is by slapping the hand of the consumer who patronized it, whether or not they actually meant to buy stolen goods.

It's hard to deal with the "Well it was cheap and he was shady but I just didn't ask too many questions" purchases; responsibility is very diffuse, with everyone doing their best to avoid responsibility.

No, that's not the case here. Fake FTDI chips are going to be used in absolutely everything, products from Alibaba to name brand professional stuff. It's pretty much guaranteed not everybody has complete control of their semiconductor supply chain, and even if they do there's an incentive for all companies to cut costs where they can. A consumer buying a product doesn't make an informed decision about the type of serial interface in their devices, much less whether it's genuine or not. There's an expectation that the product will work and that falls on the manufacturer, who might not even be responsible either.

It shares the critical element of diffuse responsibility. Everyone can half-reasonably shrug their shoulders and say, "Well it isn't MY fault".

If a Sony product happens to have a fake FTDI chip in it, this is FTDI's way of incentivizing Sony (via angry customers) to manage their supply chain, because as you say there's an incentive even for Sony to cut costs where they can- perhaps by turning a blind eye when they get some suspicious batches of chips for a great price, and claiming ignorance later...

Everyone, in demanding the lowest price no matter what (all the way up the supply chain) bears part of the blame.

We are of course witnessing a visceral response on the part of HN voters reacting to my comment, who are exemplifying why this is a hard problem to tackle. It isn't MY responsibility!

> Everyone, in demanding the lowest price no matter what (all the way up the supply chain) bears part of the blame.

Your use of the word "blame" implies that you think there's some wrongdoing on the part of someone other than FTDI. As far as I can see, there's absolutely nothing wrong with the production and use of these clone chips except that they are being labeled with FTDI's trademark. They're piggybacking on FTDI's software work, but that's nothing that the government has an interest in stopping. If FTDI doesn't like people using their software without buying their hardware, they can resort to more traditional means like not giving out their software so freely or including DRM.

  Your use of the word "blame" implies that you think 
  there's some wrongdoing on the part of someone other than 
I don't see it as particularly controversial to say that, when someone selling an item claims it's a certain brand, I expect that to be the truth.

For example, if I buy an apple iphone I expect to get an apple iphone and if the supplier instead sends me a fake I regard that as wrongdoing on the part of the supplier.

Likewise, if a designer has specified an FTDI part and someone in the supply chain has substituted a fake, I'd regard that as wrongdoing.

Right. That would be the trademark infringement I mentioned. But aside from that, the fakes get the job done. Aside from who ends up getting the revenue, it's basically no different than if FTDI started producing a new revision of the product that had a different internal layout. Accidental second-sourcing doesn't really hurt anyone other than the first source. Everyone downstream of whoever bought the counterfeits is innocent, and even the company that procured the counterfeits has probably only made forgivable mistakes given that the counterfeits are near-perfect substitutes. The supplier of the counterfeits is guilty of trademark infringement, but is otherwise fulfilling all their obligations to provide the required component.

  Accidental second-sourcing doesn't 
  really hurt anyone other than the 
  first source.
It hurts the entire electronics industry industry if I can't trust that a part is what it's labelled as, or if I can't trust a supplier not to deliver fake parts.

If your suppliers can substitute a fake FTDI part, why not label 10% precision resistors as 1% precision, or label 1,000-operating-hour capacitors as 30,000-operating-hour, or label parts that failed temperature range binning as having passed temperature range binning?

And the people who really lose out from this aren't the Apples and Samsungs of this world, who do enough business that the promise of future work can keep the suppliers honest - it's the small manufacturers and kickstarter projects that aren't big enough to have the leverage to keep their suppliers in line.

None of that corner-cutting is being alleged here. Nobody but FTDI has been complaining about the counterfeits. This has every indication of being more like a big pharmaceutical company complaining about generic drugs. If these clones are actually deficient in some way, then they're a much bigger problem, but that doesn't seem to be the case here.

As a consumer I have no way to know if the FTDI in my device is real. It really isn't my fault.

This is FTDI's way of incentivizing companies using consumers, like I said in my original comment, and it sucks.

As a consumer I had no way of knowing the motorcycle I bought was stolen. It came with the keys, the title, there was no evidence of thievery (most commonly broken parts around the ignition). The police said, "Wow we wouldn't have known this was stolen without running it in our database either".

I didn't know. But it still gets repossessed, and I'm still out $1k.

(True story, and my first brush with the laws around black markets)

Except in this analogy, someone sold you a Ducati with Pirelli tires that happened to be counterfeit. And suddenly Pirelli shows up and torches your bike because someone used a tire that had their logo.

Edit: Apparently I don't proof-read

These FTDI fakes aren't stolen, though. There is a massive difference between stolen, counterfeit, and clone. If the chips are only sold as "FTDI-compatible", then I would even say they should be completely legit, like Dalvik vs. Java.

If the person from whom the motorcycle was stolen discovered one night that it was at your house and just took it back, they would be committing a crime. Even though the motorcycle was rightfully theirs, there is a procedure to go through to get it back. Simply showing up and taking it back is a form of vigilantism. What FTDI is doing is also a form of vigilantism.

This is not true. Breaking into your house etc is criminal, but taking back their own property is not.

Did you buy it directly from a dealership? It's really an apples and oranges situation here.

and one can only hope that sony et al manage their supply chain by switching to a different chip entirely

The point of restoring stolen goods to their original owner is to undo the damage to that owner. It's not to punish someone who innocently and unknowingly came into possession of the goods at a later stage. The latter person losing out is necessary in that case only because justice can't be done entirely to both parties at the same time (unless the intermediary responsible for the theft is found and forced to compensate everyone who lost out).

In this case, screwing the innocent purchaser of a chip that is a knock-off is entirely unwarranted. It's hard to see how it wouldn't be a breach of the Computer Misuse Act 1990 in my country (England), which would seem to make impairing the operation of the component a criminal offence here.

Edit 1: Clarify wording/citation.

Edit 2: If I'm looking at the right company web site, these guys are actually headquartered in Scotland. I'm not sure whether the exact same law applies in their jurisdiction.

But a stolen good is entirely different from a lookalike good.

These chips didn't fall off the back of a truck. They were in most cases legitimately manufactured and sold to an informal spec.

You clearly don't know how the semiconducter supply chain works. All of this stuff is made in asia and changes hands 3 or 4 times before it makes it's way into a distribution channel. Unless you are buying straight from ftdi, there's a chance these can end up in your products. Same goes with most commodity ICs.

I'm curious, do you think this applies to you as well, or are you somehow confident that you own no counterfeit hardware?

Of course it applies to me. I am not supremely confident I own no counterfeit hardware. Especially when it comes to some of the cheap cables and adapters I own.

The FTDI OSX drivers will still randomly cause kernel panics when the device is unplugged and a program still holds an open file descriptor for the serial port. While working with a company which was developing and selling products with FTDI chips in them, we made FTDI aware of this issue and attached many panic logs.

It's been about 5 years and they've still yet to actually fix it.

They luckily did fix this in a relatively recent version -- try updating your driver. Still crazy that it shipped in the first place like that.

EDIT: just realized that I was thinking of the PL2303, which had a similar issue, not FTDI.

The newest version I can find on their site says it's from 2012. Link?

Oops, was dealing with a similar issue with the Prolific 2303, which was dealt with by using a newer driver, I haven't run into the issue yet with FTDI (which I don't as much).

Bummer. The FTDI driver crashes my mac quite frequently.

The funny thing is that we reported this sometime in 2009 (might have been 2010), they "fixed it" and released a new version, but the new version only crashed somewhat less often.

OS X ships with an FTDI driver since 10.9. I suspect this one is made by Apple. Maybe because of this kind of issues. Do you still have crashes on 10.9+?

Unfortunately, the Apple driver exhibits the same issue. It also doesn't support the control lines on the FT232 (e.g, DSR/DTR, RTS/CTS).

It's not a great situation, but where does FTDI responsibility for supporting counterfeit devices start and end?

If they let it continue more devices may hijack their USB VID, perhaps with bugs and glitches. Should they patch their driver to protect their reputation?

Your 'bugs and glitches' strawman is humorous because FTDI intentionally introduced bugs and glitches with the counterfeit devices, so they're certainly not trying to protect their reputation, just their profits.

FTDI's responsibility for supporting counterfeit devices ends a long way before tampering with them.

I think the moral high road to take in this situation would be to ignore the clones, but failing that, the approach which Prolific have taken (make the driver refuse to start on a known counterfeit device) seems a lot better than intentionally introducing bugs and not completely ludicrous like damaging the hardware.

Not to mention that FTDI's chips are not exactly known for their bug-free nature. If I had a dollar for every time I ran into a bug in their RS485 implementation, I would be a friggin' millionaire.

I tried reporting this to Microsoft; their handling of calls to report security vulnerabilities was just horrendous.



I've been advised to email this address by 'XXXX' at Microsoft Support.

FTDI is shipping a malware driver for Windows; if it detects what it thinks is a counterfeit device plugged in by USB, it bricks it. Details here:


I've also attempted to report this by phone as suggested by XXXX. I've never experienced such difficulty trying to report a security issue; I'd have expected that you'd have processes in place, but apparently not.

My first attempt was met by a CSR who informed me that he knew of no protocol for reporting security issues, and that he couldn't help me because it wasn't directly effecting my computer. He then hung up on me when I asked to speak to a supervisor.

Second call got me a much more helpful chap, who after conferring with a supervisor, transferred me to professional services. The person I spoke with there said they also didn't have any security reporting protocol, or if they did, he didn't know about it. When I said the issue could effect thousands of devices, he transferred me through to 'corporate'.

I ended up going through an IVR system to an operator, who was no help whatsoever. She was entirely the wrong person to speak to; she was also completely ignorant of any security reporting process, and didn't know who to transfer me to.

Could you please call me on +61 XXX XXX XXX to acknowledge receipt of this report, and to discuss it? Thanks.


An update to this: the security folks have told me it’s not a security issue, but they’re forwarding it to the appropriate team.

Perhaps I’m biased, but I’d have thought that a Windows Update that ships malware that bricks thousands of consumer devices without warning would constitute a security issue.

But hey … at least they’re actioning it, and they responded so quickly. So, FYI: if you have a security issue to report to Microsoft, do it by email. Phone staff are utterly, completely useless for this.

Bureaucratically, it probably isn't a security issue for Microsoft; they have a separate department (probably legal, although maybe a separate hardware vendor relations group) that is much better at dealing with a named, legal organization like FTDI.

Another update: Microsoft had already been made aware of the issue, and were investigating. I've lodged a formal compliment over the way their security team responded to my report (once I found them). Prompt, helpful, efficient and reassuring.

I don't think MSRC is supposed to handle this kind of stuff.

They agree :) Although I'm surprised; I genuinely thought that a company using Windows Update to push malware would count. But even so, MSRC did ensure that the issue was handled by the appropriate team. Kudos.

This is so incredibly tone-deaf and borderline childish, its shocking how badly FTDI as a company is run. It sounds like its run by a handful of pissed off neckbeards who don't know how bad publicity and a class action suit could destroy their company.

From that page: "FTDI is definitely not targeting end users - if you're unsure if ICs are genuine then please don't use the drivers."

This is where I think they are mistaken, because end users may be downloading and installing the drivers themselves. I have done this on more than one occasion: Some gadget has a USB port and I find that it uses the FTDI chip, so I go to the web page and download the FTDI drivers for it. This may happen quite frequently, for instance when an end user moves a gadget from one PC to another, and (mistakenly assumes that) they want the latest driver.

I'm disappointed because I was a big fan of FTDI and use them in a lot of my projects. I won't just go and burn all of my FTDI chips, but I am sufficiently motivated to look for an alternative. Looks like SparkFun has a couple of breakout boards for the Silicon Labs chips.

Have they contracted PR out to Ocean Marketing?

This is the worst response possible.

I think FTDI might be shooting themselves in the foot here.

Plugging in a USB is messy, and you will sometimes get an "Unrecognized Device" error, which you simply fix by unplugging and replugging.

I could see a similar hiccup causing their driver to sometimes "brick" a legitimate device.

Then this false positive ripples back to a manufacturer who bought 50,000 of those chips on the last run, and thinks they might all be fake...

It turns everything into a huge mess.

Very poor management decision, and shame on the engineers for implementing it.

Ouch, something tells me the Arduino, Raspberry Pi, etc. forums are going to be full of people that are confused why they can't talk to their device anymore. IMHO it's pretty bad to target the consumers who probably don't even know or care that there's an FTDI chip in their device. Certainly am not condoning piracy of the chips, but wonder if there's a better way of handling the situation than breaking everyone.

Wow. That is seriously uncool.

I'd never even heard of FTDI before but they can rest assured that if I ever need a USB-to-UART chip that FTDI won't be the company I choose to buy. FTDI's drivers refusing to work with the fake parts is understandable, purposely reprogramming them to make them non-functional isn't.

> purposely reprogramming them to make them non-functional isn't

Dumb question maybe, but why?

In addition to the other posted replies, it's bad software engineering. You really can't be confident enough in your logic to ever start issuing DESTROY_HARDWARE() commands of any kind, short of the small set of very specialized programs that may be deliberately used for such things (FPGA programmers, etc). Any error whatsoever and you may end up nuking your real customer's hardware. Bad plan. Same reason why programs that think they are pirated shouldn't run around being actively destructive... some real customer will find some way to tickle that code, if only through bad hardware, and now you're in trouble.

To a first approximation, all code eventually runs. Relatedly, never put an error message into your product you wouldn't want customers to see, because they will.

Thanks, that's a great answer, but I guess I'm curious about legal/ethical considerations.

I can't find it anywhere, but I remember reading about a software company that wrote an office suite for early computers (like DOS or possibly even pre-DOS), that would detect if it was a legal copy, and if it wasn't a legal copy, would delete your data. I seem to recall that they got slammed by the legal system pretty hard, which is one possible reason for why software companies don't do it nowadays. I personally see this as an action on par with, or worse then, the software company I mentioned's actions.

Making alterations to someone else's property without their consent for the express purpose of rendering it non-functional is commonly called vandalism.

In a culture with intellectual property laws I'm not sure that's true. Is it legal to destroy counterfeit handbags commonly sold on the street? Honest question, the police seem to do it frequently.

Even if it is, there is a difference between the police doing it and the company doing it.

You're damaging someone's hardware without their consent? Its essentially vandalism.

Sure, but the chips are illegal no? Where is the moral high ground coming from...

I'm not a supporter of intellectual property laws, but we have them, so I'd also be curious of any legal ground fake chip users have to stand on.

The label printed on the outside of the plastic package of the chip is the only thing that's illegal, since it's depicting FTDI's trademark. Scrape that off and you've got a 100% legal compatible clone. Whoever decided to use the clones in any given device may be be in breach of a contract if the use of genuine FTDI chips was specified, but that may easily not be the case. (The clones also violate USB specs by using someone else's VID, but that only prevents them from labeling the product with the trademarked USB logo.)

Also, possession of the fake chip as an end user is no more illegal than owning fake Louis Vuitton stuff. It's the sale under false pretenses that gets you in trouble.

"Illegal" is an extremely broad and imprecise way to describe a physical object.

Imagine I buy a car from a dealership, and without my knowledge the dealer has swapped out the original radio for a cheap counterfeit. I guess technically you could argue that makes the car "illegal" but it would be absurd to suggest that the manufacturer has the right to come to my house and slash my tires.

As I see it, it's not about whether "fake chip users" are obeying the laws; the burden should be on FTDI to justify its willful property damage.

To the extent that there is a violation of law involved in the manufacture, sale, or use of the chips (and such violations are much more likely in the first two cateories), there are legal remedies available for those violations, which generally require proving that a violation occurred and that the person against whom remedy is sought is the appropriate person against whom to seek a remedy.

To the extent the violations are with manufacture and sale, the user is not generally the appropriate target, even if destruction of the device was an appropriate remedy.

I could sort of understand it if the driver refused to work and popped up some dialog that said "You're using a counterfeit FTDI device, here's how to get an official device. Sorry this driver is not compatible with unofficial devices." However if it just silently bricks the chip then consumers will have no idea what's wrong. They'll think their Arduino clone is broken or they can't talk to their Raspberry Pi for some reason. I doubt they'll make the connection that the FTDI chip in their device is a clone and understand what to do to fix it.

Because they're intentionally breaking your property. Sure it can be fixed, but it's the intent that's worrying.

Simply refusing to work - perhaps logging something to the event log about counterfeit products - would be fine.

Fortunately, most of the newer Arduinos have moved to firmware implementations of USB-to-serial that use one of the standard USB device classes and drivers, but there's all kinds of stuff out there with FTDI chips in.

I suppose they could beg the Chinese government to enforce their IP rights and crack down on counterfeit manufacturers.

Or they could crack down on end-users. Or let the counterfeit manufacturers free-ride off their driver development.

Hackaday has a good short summary of the situation: http://hackaday.com/2014/10/22/watch-that-windows-update-ftd...

Elsewhere Hackaday links to a Russian microelectronics company's blog[1], where they decapped real and fake FTDI chips and found that:

"It seems that in this case Chinese designers implemented protocol-compatible "fake" chip, using mask-programmable microcontroller. This way they only needed to redo 1 mask - this is much cheaper than full mask set, and explains a lot of redundant pads on the die. Fake chip was working kinda fine until FTDI released drivers update, which were able to detect fake chips via USB and send only 0's in this case. It was impossible to foresee any possible further driver checks without full schematic recovery and these hidden tricks saved FTDI profits."

[1]: http://zeptobars.ru/en/read/FTDI-FT232RL-real-vs-fake-supere...

I am more entertained by that animation than I should be...

This reminds me of the Sony music CDs that came with a rootkit to prevent theft of their IP:


There were lawsuits and Sony ended up having to distribute a removal tool.

Absolutely everything with an FTDI logo on it in the wild is now suspect.

They didn't preserve their brand with this action, they just destroyed it.

Does this qualify as a CFAA violation? I think so and for monetary gain, no less. I would like to hear why wouldn't the DA that leaned so hard on Swartz wouldn't do the same FTDI's CEO.

Technically the counterfeit devices should have never been allowed into the country. So it should be interesting how this plays out.

Are they actually counterfeit?

Legally, I'd be surprised. They are re-implementing the FTDI protocol, which is completely legal. They are reusing FTDI's PID/VID, which might or might not be a violation of the USB specs or USB recommendations -- I'm not sure about that -- but I'd be really surprised if that matches the legal definition of "counterfeit" for which customs has the right (and duty) to stop imports.

I'm guessing they intended to go after devices sold as FT232s with the FTDI logo on them. If there's collateral damage, that could be a problem.

Then again, the users _did_ agree to let that happen in the clickwrap agreement, so it's still uncertain.

Either way, I'm readying the popcorn. This should be interesting.

FTDIs own website says their chips are used on medical devices:


Let's hope that all the manufacturers are 100% certain of their supply chains, from top to bottom. And that there are no bugs in the driver that might cause inadvertent bricking.

Way to go, FTDI.

IF this is on purpose and can be proven so, it is most definitely illegal!

From their website:

>The licence only allows use of the Software with, and the Software will only work with Genuine FTDI Components (as defined in the Licence Terms). Use of the Software as a driver for a component that is not a Genuine FTDI Component MAY IRRETRIEVABLY DAMAGE THAT COMPONENT.

IANAL but I don't believe this disclaimer can possibly be valid. Personal property rights cannot be waived away with a disclaimer.

It amounts to an admission they are bricking clones on purpose.

How are your personal property rights being violated? If an ATI graphics card lied and claimed to be an nVidia card and the drivers cause it to overheat and catch fire, who is at fault? Should you be required to QA your drivers against counterfeit products?

Edit: nobody has shown that the driver is intentionally writing the ID to 0, the counterfeit chip isn't even close to the same circuitry and could be screwing up a legitimate instruction.

This isn't a misconfiguration issue, or that Linux bug that bricked certain SCSI devices. No, they are explicitly asking the counterfeit chip to rewrite its USB PID to 0, which renders it unusable.

That's intentional and clearly malicious.

Has this been proven by a corresponding packet dump listing "Write EEPROM, offset 0, 4 bytes: [0,0,0,0]?

Or are they -sneakily- bricking the device by evoking an unintended reaction to a seemingly innocuous command?

The former will be easy to prove, the latter.. probably not so much.

It's been proved by reverse engineering the FTDI drivers and annotating the code. It exploits some edge case in which the counterfeit device does not behave exactly like the original. https://marcan.st/transf/ftdi_evil.png

Check out FTDI's Twitter feed: https://twitter.com/FTDIChip/status/524928658180304896

They're being somewhat evasive, but it's clear that this is intended as a deliberate anti-counterfeiting strategy.

Wow they could have planned this misadventure a bit more carefully. Having decided to do this stupid destructive thing, they should at least have resolved not to admit they did it on purpose. The general public would have much more sympathy if the story was "after lengthy investigation, we've determined that the bug only affects counterfeit products... we have sympathy for all victims of counterfeiting." Instead, they've gone for "in your face, you cheap bastards!" Honesty is not always the best policy, especially when you're evil.

This isn't about damage from a lack of precautionary measures. It's about damage due to the drivers doing something completely irrelevant to ordinary use- code that has no reason to be in the driver in the first place.

If the drivers caused it to overheat because of an oversight, then that's just sad. If the drivers caused it to overheat because the company went in and wrote, if(counterfeit) overheat(); then they're liable. Surely this should be obvious.

You should look up the word 'intent' in law.

I wonder why this is voted down. The US has some severe laws against vandalizing computing devices and against unauthorized access. Why wouldn't these laws apply here?

There are a variety of laws that would apply here, and doing what they did, if done intentionally, is almost certainly cause for civil liability.

They are not allowed self-help in the form of destroying other pieces of hardware. If they have a problem with counterfeit chips, the solution is customs/legal process/etc

If they aren't happy with what that buys them, they should be pushing for legal change.

It's quite possibly a violation of U.S. Code 1030(a)(5)(A), a federal felony:

(5) (A) [Whoever] knowingly causes the transmission of a program, information, code, or command, and as a result of such conduct, intentionally causes damage without authorization, to a protected computer;

Now "protected computer" and the [ab]use of the Interstate Commerce Clause mean that the device with the FTDI would likely need to be connected to a network for this to apply. Plus I think they still need to show $5,000+ in damage, but it wouldn't be hard to reach that if the driver wrecked a prototype and delayed a product.

Was the driver pushed out by Windows Update from WHQL? That's via a network.

FTDI is not a US company.

But Future Technology Devices International Limited (USA) is. http://www.ftdichip.com/FTContact.htm

Neither was Megaupload.

All they have to say is "We write our drivers to support our chips, if it messes with other chips that incorrectly identify as ours, that's just the way it went, it'd cost us extra to support them and why should we help our competitors". Practically impossible to prove otherwise.

"All they have to say is "We write our drivers to support our chips, if it messes with other chips that incorrectly identify as ours, that's just the way it went, it'd cost us extra to support them and why should we help our competitors"."

Buzz, thanks for playing. :)

That won't get them out of discovery for various torts, and the discovery (emails, code, etc) is likely to show they did this on purpose.

It's not practically impossible, it's trivially easy to disassemble and see if it does this on purpose. Then you argue it to a jury, and it's going to look really really bad for FTDI.

I wish German civil law had something like your discovery process.

Over here the claimant probably would not be able to peek into the defendant's stuff.

Especially if he can't specifically claim "on march 10th, Mr. Meier sent an email to Mr. Schmidt discussing topic X".

A simple "hand over your mails about the matter at hand" would be ruled a "fishing expedition", not admissible as a motion to discover.

They have a track record of trying to fingerprint and screwing with counterfeits, so it would appear there's evidence the driver doesn't happen to disable counterfeits, but actively disables them. To me there's a fuzzy distinction (possibly not reflected in law) between software that breaks when you make it do stuff you didn't design, versus having it attack things you don't want it to work with.

To quote CTZ: "You should look up the word 'intent' in law."

I'm designing an Arduino-compatible board[1] that supposed to have an FTDI chip for ease of design. This whole thing makes me reconsider it, what would be the best way to replace it some other solution? Do I have any real option if I want to stay within the Open Parts Library[2]?

[1]: https://www.hwtrek.com/product_preview/VTZUZV9k [2]: http://www.seeedstudio.com/wiki/Open_parts_library

They're not in the OPL, but Microchip makes several chips that support full-speed USB, and they provide a CDC driver, too. I prefer them to using an Arduino because almost all of them are available in a DIP form factor, making them great for prototyping projects; available with different number of pins and features (10 vs 12-bit ADC, etc); and cost less than an ATMEGA328 +FTDI. Some of the chips are fully USB compliant without a crystal.

I've never used it, but Microchip's IDE for their C compiler and debugger is cross-platform and will work on Linux/Mac/Windows. I prefer to program them in JAL, a Pascal-like language that is easy to learn that has a large library of functions available. There's syntax highlighting available for it in Vim :-) .

If you're committed to Arduino, there's an open-source project (http:www.pinguino.cc) that has its own Python-based IDE that will take Arduino code, convert it to SDCC C code, compile it to assembly, then flash a Microchip chip.

not sure, but shouldn't you be able to use the ATMEGA32U4-AU as the microcontroller and get usb for free? Here's a good place to start for a bootloader that'll do your usb setup for you... http://forum.arduino.cc/index.php?topic=124459.15

Just looked at your product idea, see you already had planned a good microcontroller. Maybe replace the FTDI with the ATMEGA and make a firmware that'll allow in circuit programming so you really can't brick the main microcontroller?

Yeah, people suggested something similar before[1], and definitely will research it. Using two of the ATmegas might not work (the miniPCIe form factor is tiny!), I wonder if a single chip could do that, at the expense of maybe some storage? The current setup needs almost no custom work, and for the proof-of-concept version I'd rather not do firmware programming if I can avoid it (but then maybe I can't be picky about the FTDI:)

Thanks for the suggestion!

[1]: http://www.reddit.com/r/arduino/comments/2ehosj/pcieduino_fe...

Look at the datasheet, it's got a usb DFU bootloader loaded by default. :) Biggest issue would just be making sure it can switch over to serial mode, but that's already done in arduino's, so should be pretty easy.

Best way would be designing it with GENUINE parts instead of planning to populate your own boards with ebay specials.

I'm designing with genuine parts of course, manufactured at Seeed. The problem is that if FTDI is doing monkey business and gets their driver revoked as many people suggesting on the list, my genuine part worth nothing either, my own customers are screwed over because of FTDI's bad moves.

So I'd rather not use FTDI altogether, if I can avoid it.

I'm yet to see someone who does mass production from ebay sourced components (bad price, not enough quantity). If I get parts from Digikey or Mouser, how can I check that they are genuine? I trust them more, but is there really a logical reason to trust any reseller in this sense? Screwed either way.

People are allowed to choose the parts they want to use. I call it voting with your wallet. Maybe FTDI will realize that people don't want to use their products when they pull stunts like this.

So basically "we will show FTDI by CONTINUING to not use their parts at all". People affected didnt want to use FTDI parts in the first place, they wanted fly by night $2 with free shipping special.

No; people affected are people who bought some devices from someone who bought some devices from someone who wanted to use FTDI parts, who bought their parts from someone who bought their parts from someone who didn't want to use FTDI parts.

FTDI action hurts everyone except the ones they were targetting.

No, it's more "I could use FTDI parts(and I bet someplace like seeed would use the real thing), but if they are going to release drivers that have a kill command baked in(and we've seen that it's on purpose), I'm not gonna use them"

actually seed is one of confirmed sources of fakes :) someone had one of these http://www.seeedstudio.com/depot/UartSBee-V5-p-1752.html?cPa...

go pid 0

Seed is a small shenzhen company, I woulndt expect them to have legit parts to begin with anyway.

so, yay, go with something other then FTDI, cause other companies don't seem to have the same fascination with killing clone chips. Alas, other companies actually try to make stuff cheaper and have more features.

Here's someone claiming to have found the responsible function in a driver.

PLEASE NOTE: ALL NAMES HAVE BEEN CHOSEN FREELY BY THE PERSON WHO MADE THE SCREENSHOT! So there's no name "BrickCLoneDevices()", it's probably called UpdateEEPromChksum or something like that in the original code, because it looks like that's what it does.


Assuming that this disassembly/decompiled code indeed is genuine, the interesting thing is explained in the 2nd comment block: A genuine FTDI device seems to be designed such that a write only to the offset that stores the PID is ignored, hence for a genuine part this code will only update the word at offset 62, and that would be matching the functionality to just update the eeprom checksum.

For comparison, here's a random mainling-list post which includes a dump of the 232 eeprom. The VID/PID is stored at word 1 and 2 of the eeprom, something that could be a checksum is down at the word with offset 0x7f (word 0x3f = 63? There's probably a off-by-one here).


Neither write has any effect on a genuine FTDI chip because both writes are to even addresses. That's also why they write to word 62 even though the checksum is in word 63 - they can't modify the checksum directly because that'd affect genuine devices, so instead they modify word 62 so that the data has the same checksum as before their changes. The entire thing has no purpose other than bricking clones.

Does anyone know of good FTDI alternatives? Are there any clone makers that are relatively legit (i.e. they put their actual brand name on the chip, they support drivers, etc)? At $4.50 a pop for bog-standard bit-banging in a day and age where you can get ARM M4 SoCs for $2.75 a pop (n=1 prices) I would think FTDI would have more above-the-table competition than they do.

Is the subterfuge required for illegitimate cloning really that much easier than getting a website, writing docs, and supporting drivers?!

Someone in the linked thread recommended the Cypress CY7C65213 and posted a link where Cypress claims it is a direct pin-for-pin compatible replacement that doesn't need proprietary drivers: http://www.cypress.com/?rID=83118

It's also cheaper; $2.44 for one and it goes down to $1.44 for 2500: http://www.digikey.com/product-detail/en/CY7C65213-32LTXI/CY...

As mentioned in the eevblog forum, Microchip make the MCP2200 which is about $2 in single quantities. Seems similar in features to FT232 chips and reasonable in price.


The Microchip part needs an external crystal or ceramic resonator for a time reference. The FTDI part doesn't need any external parts beyond bypass caps.

If you're already soldering, a crystal isn't so much work or expense these days.

FTDI's major advantage is that their WHQL'd drivers are already installed with Windows. That's why people build chips to the same API.

Ah, that makes sense. The "right" answer would probably be to convince the USB-IF to standardize the interface. FT232 and FT245's popularity should be argument enough that it's worth doing. I have no idea how politically viable that would be.

EDIT: looks like they did standardize a USB-to-serial device class [1]. Maybe they just need to update it?

[1] http://www.atmel.com/Images/doc4322.pdf

Didn't see your post when I was posting mine, but anyway -- CP210x.

Do you know if it supports non-standard baud rates on OS X> (Maybe Linux too?)

I use FTDI because I can easily run comm ports at 3 Mbit/s. OSX (and I think Linux too) does support comm ports at non common baud rates. I'm looking for a way to add decently quick USB comms to a device without writing my own drivers. FTDI seems like the only option. Using HID is limited to 64KB/s.

Yes, Linux too. I'm running 2 MHz, the fastest that my jelly bean microcontroller du jour can do. I'm using FTDI on the remote end, and Python serial port drivers on the PC. I'm finding that with relatively little effort, I can make my gadgets and support software run on both Windows and Linux with no code changes, which probably sounds pretty mundane to experienced hackers, but is a convenient benefit nonetheless.

You could always just use libusb to talk to your device (e.g., an AVR w/ V-USB or another microcontroller with actual USB support) from user space, instead of fooling around with fake COM ports.

That's probably what I should do. I bought a book on usb and started learning a bit about the protocol. Are there any good Libusb projects that would be a good example? Most I was were for using libusb to talk to an existing device class. I'd like a sample that contains both device and host?

Take a look at how avrdude works over libusb. That's a pretty good example of bulk-upload and bulk-download and various types of things you're likely to want to do with a microcontroller.

I have not designed for FTDI and new in embedded desings but, for USB interfacing cypress PSoCs have served me well till now. They have dedicated USB chips as well.

Me and my buddy were going to work on a couple of projects last weekend and got bit by this.

The workaround once your chip has been flashed by the new driver is modifying the driver to communicate with devices that have a PID of 0.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact