I was talking about CDC. If FTDI chips did implement the CDC, then they'd work out of the box on Vista and higher, and of course on OS X and Linux. Now since the FTDI chips don't implement the CDC, Microsoft doesn't provide drivers for them, and FTDI has to have their own drivers bundled with Windows and available via Windows Update.

Perhaps the only way to spot a fake is to attempt a config EEPROM write to an address that's larger than the size of the EEPROM. On FTDI chips, such writes fail (I checked). On fakes, perhaps they wrap around... Still, they could have perhaps written somewhere safe, like at the end of the data area, not at the beginning. But then, perhaps the wraparound bug is an off-by-one and you can only kill the PID that way. Who knows.

The driver has no legitimate reason to do any EEPROM writes that are expected to succeed. It'd decrease the life of the EEPROM - it only has a finite number of writes. The driver can, of course, attempt to do EEPROM writes that are expected to fail. Perhaps the counterfeit chips don't fail such writes, but instead do the wrong thing and wrap around as you suggest.

First of all, the FTDI chips themselves have no firmware. They are implemented using fixed function logic IIRC. Even if they did have firmware, it'd be on a mask ROM and wouldn't be changeable. What FTDI chips and their clones do have is a configuration EEPROM. On some chips it's internal, but they do support external EEPROM too. That's where the VID, PID and USB descriptors are stored, allowing vendors to use those chips with their own manufacture, serial number and device descriptor strings, as well as their own device-specific VID/PID. Heck, you can get blocks of PIDs from FTDI so that you don't have to buy your own VID.

I don't know what sort of functionality does the driver use to discriminate between legit chips and copies, but it's possible that it could do something like attempt to write an EEPROM byte at an address that's too large. Perhaps on the genuine chip, such write is ignored, but on the counterfeit chip the write wraps around. That'd be an implementation bug in the chip, pure and simple. The negative effect (zeroing out of the PID) is a bug, even if it's exploited by the driver. I wouldn't shed any tears for the people who use the fake stuff. You can buy FTDI-branded serial converters from mainstream vendors, there's no need to buy Chinese copycat crap.

You're assuming that there are patents involved. Not all clones are protected by anything. In fact, last time I looked into it, it's perfectly OK to make functional clones of FTDI chips, as long as you don't use their drivers. If you use their drivers, you must purchase their silicon, or license the driver from them.

Except that the driver is provided through Windows Update and you don't need to accept its license to have it installed. You just need to select the optional hardware updates and click "Install".

Their drivers come with licensing terms, but it's arguable whether such terms hold any water when all you did was accept a Windows Update... Is the driver available via Windows Update the same one as downloadable from their website?

The change "mechanism" is to write into the configuration EEPROM. That EEPROM is accessible as a "generic" memory area. It is only interpreted and copied into configuration registers when the device powers up, and maybe on USB disconnect but I don't recall the details. For older devices that had external EEPROM, it's trivial to reprogram by shorting the CS line to VCC, powering it up, then re-writing the config EEPROM (BTDT). For newer devices, you need to attach an external EEPROM, IIRC they will recognize one and use it if present. All you need for that is a little bed-of-nails adapter board with an EEPROM.

The FTDI USB bridges most definitely do not support CDC. If they did, there'd be no need for an FTDI driver on anything other than Windows XP. Besides, those devices have no firmware. They have some configuration bits and identifier strings in an on-chip EEPROM - well, not all of them, some require an external EEPROM.

CDC is a reasonably simple protocol and I don't know where you got the idea that it's somehow inherently power hungry. I have an implementation that fits in 2kB of flash...

I've always been buying them from reputable vendors (big names like Newark, Mouser, ...) so I don't really have that problem. Where the heck do people buy their chips?

OS X and Linux support CDC out of the box. RPi is not an OS.

Sure. A $2 MCU with a USB Device and a UART will do it just fine, and you can have it implement the comm device class, so that on Windows Vista and up the drivers come with the OS. CDC is supported out-of-the-box by both Linux and OS X.

Those chips make most sense if you have a legacy MCU that doesn't come with a USB Device peripheral. Otherwise, emulating the FTDI chip is only somewhat useful for compatibility with Windows XP. If you don't need to connect to XP, you can implement the communication device class, and then Windows Vista and newer has built-in drivers for it. The only reason I even bother using the FTDI protocol is to support XP-based customers. We have a cutoff date for that, and that date is near.

If you buy from legit vendors (DigiKey, Newark, Mouser, etc.), you're not gonna get counterfeit FTDI chips. Period.