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.