The bigger supply-chain problem there wasn't the fake FTDI chips, which actually worked reasonably well; it was the totally genuine and authorized FTDI driver update which FTDI designed to brick your customers' hardware if they installed it, if you had been so unfortunate as to get fake FTDI chips.
I look at it the other way around, the driver update is a rare case where it was publicly exposed just how widespread of an issue forgery is in the electronics industry. FTDI likely expected the number of fake devices already in the field to be significantly lower than they actually were. If that was the case, it is unlikely it would have become the story it did.
> "And I would have gotten away with it too, if it weren't for you meddling kids!"
No, I don't think that was the thought process. I think they wanted to send a message and I think they wanted to test the waters to see if anyone would hold them accountable for deploying first party malware.
If I remember correctly, in the FTDI case that was very unlikely to happen. It wasn't a case of `if (looks_fake) do_brick()`. Rather, it accessed registers in a way that they knew their implementation supported but that was buggy in a widely counterfeited version.
(And I understand it they did this knowing the effect it would have. It wasn't some accident.)
The converse: they performed EEPROM writes in a way that was ignored by that particular chip from FTDI (only one - it would've bricked other FTDI products) but honored by the clones. They exploited a bug in their own product to make their bricking code only affect the (non-buggy) clones.
The code was blatantly deliberate; to pull this off they had to perform a preimage attack on the EEPROM checksum, etc.
I think ironically it was other way around - they issued write in such way that due to quirk in genuine chip it was no-op but actually worked on the clone.
More specifically: many of FTDI's devices, including the FT232RL, can store configuration data in an EEPROM. EEPROMs are conventionally organized as an array of bytes, but FTDI devices always access the EEPROM 16 bits at a time. The FTDI devices include some commands to read/write the EEPROM. For convenience, these commands use an address counting in bytes, but the official drivers and tools only ever use even addresses (so that the EEPROM addresses accessed never go "across" fields).
The FT232RL is one of FTDI's parts which has an internal EEPROM. An implementation quirk means that any attempt to perform a EEPROM write on this part with an odd address will be ignored. (This quirk is specific to this one part -- most of FTDI's other parts will perform this operation as expected.) This fact was apparently not known by the developers of the FT232RL clone; it will perform the write.
FTDI released a driver update which would, upon detecting a FT232RL, attempt to write zeroes to several odd addresses near the locations used for the device's VID/PID (vendor ID and product ID). These writes were ignored by the genuine devices, but were interpreted by clones as writing zeroes to these fields. This caused the devices to fail to be recognized when next connected to a host.
What's funny is that, as far as documented functionality is concerned, the clones work perfectly. In some regards, they actually work better than the originals!
That's not quite right. The addresses are in 16-bit word units; there are no unaligned accesses or byte offsets. You can write to any 16-bit word on other FTDI chips. However, the FT232RL has a quirk where it expects you to write adjacent pairs of 16-bit words sequentially, and only commits the write on the second one. If you only write the first half (at an even word address), nothing happens.
Usually, when programming the EEPROM in these devices (e.g. with FTDI's tools or open source ones), you write the whole thing at once, so those pairs are always written sequentially and it works anyway. However, if you try to write to some words at even addresses without following up with the next one, the FT232RL misbehaves and ignores the write.
Specifically, what happened seems to be that the FT232RL uses an internal 32-bit EEPROM. So when you write to even addresses, those writes are staged to a buffer in anticipation that you will subsequently write to the next odd address. At that point all 32 bits are written. The bricking code only ever wrote to even addresses, which involved a preimage trick to keep the existing checksum valid, since the checksum is at an odd address they couldn't write to. Instead they calculate what the value for the word before the checksum should be to make the existing checksum valid, and write that instead. Genuine chips would just stage all these writes in a holding register and never get to commit them.
Basically, FTDI decided to use an internal 32-bit EEPROM macro when developing this chip, and came up with this hack to shoehorn it into the 16-bit protocol (in what is arguably a buggy way). The clones just implemented 16-bit writes properly, which is the same thing all other FTDI chips (with external 16-bit EEPROMs) do.
(Source: I'm the guy who first figured all this stuff out back when this happened, including reverse engineering the FTDI bricking code and writing an unbricker).
You’re right - I think I was misremembering the details and it was something like a poisoned supply chain leading to people who thought they had bought the real thing shipping devices that ended up breaking or something.
Well, it was "a poisoned supply chain leading to people who thought they had bought the real thing shipping devices that ended up breaking"; it's just that FTDI was the company that poisoned the supply chain and broke the devices.
While clearly that's a thing that could happen when FTDI goes around injecting malware into the supply chain, I'm not aware of any accounts that it actually did happen. Did it?
Sure, and they would have gotten precious little criticism if they had displayed a big warning message on detecting a questionable part. The problem was that they decided to unilaterally destroy customer property.
Much worse: FTDI's customers are the distributors, whose customers are (usually) board assembly houses, whose customers are electronics vendors, whose customers are electronics users. FTDI decided to unilaterally destroy the property of their customers' customers' customers' customers. Or, rather, the customers of people who thought they were FTDI's customers' customers' customers, but whose suppliers' suppliers were actually cheating them.
The miraculous thing is that FTDI escaped criminal prosecution for this.
It wasn't that the chips were fake, they could only be fake if they claimed to be FTDI. They could have been merely FTDI compatible, at which point did FTDI have any grounds to destroy compatible parts?
They were using FTDI's USB VID. Probably most of them also were marked as "FTDI" on the chip package, but of course that's not what FTDI's drivers looked at.
There is no law against using someone else's USB VID, as long as you don't put a USB certification logo on your product.
What FTDI did, on the other hand, is malware and clearly illegal. It is destroying private property and I guarantee violated multiple laws in many countries.
I don't know the laws elsewhere, but here in Europe trademark holders absolutely have the right to demand counterfeit products be seized and destroyed. Even if the owner acquired them in good faith. Also it would be interesting whether any compatible chips exist that use FTDI USB VID but were not marked with the FTDI logo.
Of course this kind of vigilante justice by FDTI is illegal, but who is going to press charges if that means they will get their devices taken from them and destroyed?
Right, we're talking about clones that don't use FTDI's logo. I don't know if they exist, but they well might. The point is that the VID itself doesn't have any legal protection.
