FTDIgate 2.0?

[RFZ]

Intel used fake FTDI chips for their Gen 2 Galileo?

I expect it was a USB serial lead the guy was using with a fake FTDI chip in it...

And that is one of the major problems with this FTDI driver. Even as a developer, if you hook up a device to your PC using a USB-RS232 converter and you get "NON GENUINE DEVICE FOUND!" on your terminal, you won't expect it to be the converter generating this message. You would think it comes from the device. This is why the user thought the Galileo board was faulty and even Intel opened a support case because they didn't know about the strange FTDI driver.
The message doesn't even contain the words USB-Serial, RS232 or FTDI in it. How, even as a developer, should you supposed to know that the message is talking about the RS232 converter?

[rasmithuk]

apparently Microsoft is okay with it (I don't see how this should have passed WHQL).

They were ok even with the previous version that was bricking the chips and then pulled it later. I think the WHQL doesn't mean much here - FTDI has some sort of privileged position because their drivers ship directly with Windows, unlike most third-party vendors. So their stuff likely gets only the basic "does it cause BSOD/eat data" test and that's it, because they are trusted.

FTDI don't have any special deal with Microsoft because WHQL doesn't test for anything like this.

To get a WHQL cert you get the tools, take a clean machine and run them on your driver. It produces a log which gets sent back to Microsoft along with the driver.
If it passes the tests it get signed.
If your device claims to meet a standard device type it gets tested for the normal responses but that's all.

Even if Microsoft did test the driver themselves, they'ld do so with the provided hardware, which would be from TFDI and pass their tests.

If the bad driver gets reported to Microsoft they'll probably pull it. As the last version changed the VID/PID it broke hardware which is why it got pulled so fast.

[Barny]

Sadly I have visited this forum to late.
Today morning, I played a little around with my dev-board while eating my breakfast.

For debug I use the UART to write most registers of my AtMega32.
I was to lazy to use proper check-sums.

And now guess who is proud owner of an fake FT232 chip on his USB-UART bridge without knewing.


The AVR was a little bit upset about getting his Pins shorted to ground while switched to output & deliver 5V.

[FrankBuss]

Incidentally, I took a look at the code and empirically tested a clone device to confirm.

I found another interesting (unicode) string in the ftdibus.sys file: "The FTDIBUS driver detected a Type 1 counterfeit device and will disable this device." (and the same string with 2-5 instead of 1, can't they use sprintf in a driver?). Can't find the xref with my IDA Pro disassembler, when is it used?

[janoc]

Maybe you can answer some question, because you are already using this chip: From the datasheet it is not clear to me if it supports more than 115,000 baud. The formula says 12 MHz / x (with x integer), but in other chapters it says it supports only 300-115,200 baud. Can I use it with 1 MHz baud rate?

I haven't tried this, but I seem to recall that on paper it does support it, but you get lower bandwidth than the FTDI one because they do some silly delays between the USB transactions or something to that effect. The Microchip chip is nothing else but one of the cheap 18F14kxx PICs with a pre-programmed firmware. I think Dangerous Prototypes tried to hook it up to a PICKit when it first came out and it matched the MCU ID. It is apparently 16F1455:

http://blog.zakkemble.co.uk/mcp2221-hid-library/
and
http://www.eevblog.com/forum/reviews/alternatives-to-ftdi-usb-to-uart-converter/msg540581/#msg540581

And the datasheet says it doesn't need a driver, it uses the standard virtual COM port driver on Windows. Does this mean you don't even need a custom INF file  for it? I think it is possible in Windows, if the device enumerates as CDC USB device class (see here). Is this the case for the MCP2221? And does MacOS and Linux support it?

In Windows you don't need an inf file because it is a standard CDC device. Linux certainly supports it out of the box, no hassle. No idea about Mac, but Macs support standard CDC ACM devices without drivers as well so I would say it is supported there too. It is only Windows that is so screwed up in this regard.

For me the only use for the FTDI hw remains the bit bang mode (I have an adaptor with the FT2232H in it) and the built-in JTAG support and not needing to supply a driver. However, those things are often easier and cheaper done by simply sticking a small micro in there anyway - USB CDC code is pretty much a standard example code from every vendor of USB capable micros I have seen.

J.

[aandrew]

FTDI put/puts a lot of time and money into writing and maintaining their drivers, getting them signed and certified, integrated into the Windows Update ecosystem and the Linux kernel, etc.  They recoup this cost through a slightly higher sales price on their products, and people pay it because of the convenience.  Why would you expect to be able to use FTDI's drivers, for free, forever, without purchasing their product?  That attitude just blows my mind.  You should consider every day you've been able to use FTDI's drivers with your counterfeit device as a gift, rather than freaking out when that privilege is finally revoked.  This attitude of entitlement bothers me to no end.  I suppose Microsoft's "Genuine Advantage" system should be renamed into Microsoft-gate too?

These counterfeit companies are welcome to build their own devices, but they should also be writing their own drivers and going through the same process as FTDI to integrate those drivers into consumer operating systems, maintaining them, etc., in order to make their devices usable to end-users.  What's that?  Doing so would mean they'd have to charge FTDI-like prices?  Oh shucks, I guess the world does make sense after-all.

Don't want to deal with this kind of BS?  Then quit shopping on eBay and Alibaba and spend an extra dollar on the real thing.

Note: I'm using "you" in the collective sense, not you specifically.

AMEN! I was very much against FTDI when they decided to "brick" (blank the EEPROM) of counterfeits because it was a (sort of) destructive operation. This, however? I'm okay with this. I buy from aliexpress/ebay all the time and expect weird shit to go down occasionally. It's the price I pay for bottom-dollar electronics and I'm okay with the risk.

[aandrew]

Nobody is out there looking to save a few pennies buying counterfeit FTDI chips.

This is not true.

Manufacturers are under constant pressure to lower costs. They in turn put pressure on their procurement departments to get the price down, who then go out and find anyone offering the same line item at a lower cost. Eventually they find it.

We dealt with counterfeit Intel 80196 (motor controller) microprocessors 15 years ago. How did we get it? Exactly how I described above. No, I don't believe for a moment that Arrow will get a line of counterfeit FTDI chips since they're big enough to be talking to FTDI and its manufacturers directly.

Who will be getting counterfeit FTDI devices? The smaller suppliers/distributors who go through a supply chain that does not have the traceability required to ensure a genuine component. It's a cost of doing business with smaller outfits, who are under incredible pressure to get something as cheap as possible.

[dack]

The linux drivers are not made by FTDI. They are made by the linux community. That's why they've never had any issues with bricking clones, and will even undo the bricking done by the FTDI drivers.

[marcan]

Incidentally, I took a look at the code and empirically tested a clone device to confirm.

I found another interesting (unicode) string in the ftdibus.sys file: "The FTDIBUS driver detected a Type 1 counterfeit device and will disable this device." (and the same string with 2-5 instead of 1, can't they use sprintf in a driver?). Can't find the xref with my IDA Pro disassembler, when is it used?

I'm not a Windows expert, but I believe those are translation/textual string resources used for the system event log. Messages are logged by code, so there wouldn't be a direct xref there, instead that's a table that maps codes to strings and something inside Windows itself does the mapping - so yeah, they can't use sprintf, this is Windows' dumb design I think? (someone with more Windows knowledge might be able to correct me here). I did find the logging code earlier, and what triggers it, but didn't check if it is indeed logged on my windows box. I just did and yeah, it's there:



Of course, they say they'll disable the device, but then go ahead and corrupt its data instead. Nice definition of "disabling".

Types 1-4 mean integrity checks on EEPROM addresses 0x40-0x4f failed (which seem to store manufacturer info, perhaps non-writable? haven't tried, the normal EEPROM user/config area is 0-0x3f), while type 5 does the good old 16-bit EEPROM writes check (what they used to brick devices in the previous version, except this time they revert their changes). It actually writes a 0 to the PID field (without fixing the checksum to match), reads it back, and restores it if written (original chips won't write it as its address is even). Amusingly, all of this is still wrapped in a "if EEPROM checksum is correct" conditional, so you can still use my Python tool to deliberately corrupt your EEPROM which will make the chip work with the official driver (if you're okay with all default configs and no serial number), but even better, if you plug it into a Windows machine with the new driver and unplug it at *just the right time*, the written PID field will cause a checksum failure and the driver will start to work fine with that device!

[FrankBuss]

For me the only use for the FTDI hw remains the bit bang mode (I have an adaptor with the FT2232H in it) and the built-in JTAG support and not needing to supply a driver. However, those things are often easier and cheaper done by simply sticking a small micro in there anyway - USB CDC code is pretty much a standard example code from every vendor of USB capable micros I have seen.

Right, I guess all USB UART chips will have some kind of CPU in it and some firmware. Then it is better to use a standard microcontroller, where you can at least update the firmware, if you need to (e.g. if Windows doesn't support CDC anymore) and where you can implement special things, like bitbanging or JTAG over the serial port.

[Russ.Dill@gmail.com]

FTDI put/puts a lot of time and money into writing and maintaining their drivers, getting them signed and certified, integrated into the Windows Update ecosystem and the Linux kernel, etc. 

Hah, FTDI and open source. They have made extremely limited contributions to open source. The Linux kernel driver would not exist if it were up to FTDI. They have a userspace library which is of course *not* open in any way. Luckily people have taken time to make both an open kernel driver and user library. Of course, now I can't do cool things like make my Arduino act like an FTDI directly via v-usb to make integration for windows users easier.

[Monkeh]

Of course, now I can't do cool things like make my Arduino act like an FTDI directly via v-usb to make integration for windows users easier.

Why would you need to?

And why would you think it reasonable to make your Arduino behave like a piece of hardware with very specific capabilities when it is nothing of the sort?

[antokadam]

I think I found a workaround for this new January FTDI driver. Here's my blog post about it:
http://electropit.com/index.php/2016/02/01/unbrick-your-non-genuine-ftdi-device-2016-january/

This is for Windows 10 x64. It includes CDMUninstaller and Windows Registry editing.

[mikerj]

the FTDI driver makes a fake chip send "NON GENUINE DEVICE FOUND!"

What's wrong with that? their driver isn't designed to work with counterfeit chips and god knows what dire consequences they could be if the counterfeit mis-behaved

But it's completely safe to send "NON GENUINE DEVICE FOUND!" to the clone device repeatedly right?  I think that particular argument is a non-starter.

[c4757p]

the FTDI driver makes a fake chip send "NON GENUINE DEVICE FOUND!"

What's wrong with that? their driver isn't designed to work with counterfeit chips and god knows what dire consequences they could be if the counterfeit mis-behaved

But it's completely safe to send "NON GENUINE DEVICE FOUND!" to the clone device repeatedly right?  I think that particular argument is a non-starter.

The "it's not supposed to work with this device anyway, so screw it, might as well make demons fly out your nose" argument is just reckless and stupid. Can't we just ignore the trolls who keep making that one?

[nctnico]

the FTDI driver makes a fake chip send "NON GENUINE DEVICE FOUND!"

What's wrong with that? their driver isn't designed to work with counterfeit chips and god knows what dire consequences they could be if the counterfeit mis-behaved

But it's completely safe to send "NON GENUINE DEVICE FOUND!" to the clone device repeatedly right?  I think that particular argument is a non-starter.

I have seen some (safety related!) devices get upset when they receive data which they don't expect so yes: sending random data to a device can lead to damage, injuries and even death. In the case I was involved in those issues where fixed but who knows what is out there and vulnerable for mis-behaving.

[all_repair]

I used to specify only FTDI for all USB-serial converters for my deployment as they did not pull the trick like a Taiwanese company that made their driver stop working.   For me, if you want to hold me accountable, the only point is when I got my goods and was doing the first testing.  After that, I have no recourse with the sellers and any "update" to disable, to inhibit, to slow down my installations and deployments are not acceptable.  Why should the end users and all the middle tier pay for these problems? And what benefits do these bring to FTDI?  Any corrective action must not affect already deployed and installed devices, too bad if they are too late for the game.  FTDI either is a company full of hatred that seek to hurt all people that use the compatible chips, or is at the brink of going down.   The uncertainty that FTDI and the other taiwanese company bring is not something I want to absorb.  Last batch of FTDI that I got is likely to be geniune so far as it is able to survive all the updates.  But FTDI and the taiwanese chip are in my ban list, whatever chips they may make.

[lovemb]

As a developer, I love this. I always buy important ICs from reputable vendors, and on top of that now I can even properly test them for fakes.
(I also could with the previous ftdi driver that erased PID, but this is easier now.)

Also, whenever I can I've been using ft230x/ft231x in new designs instead of the common ft232r because of the price.

[winfieldhill]

Replacing FT232R with CY7C65213 ...
http://www.cypress.com/knowledge-base-article/replacing-ft232r-cy7c65213-usb-uart-lp-bridge-controller-kba85921

The Cypress chip looks good, isn't expensivve, what driver do the use?

[miguelvp]

Replacing FT232R with CY7C65213 ...
http://www.cypress.com/knowledge-base-article/replacing-ft232r-cy7c65213-usb-uart-lp-bridge-controller-kba85921

The Cypress chip looks good, isn't expensivve, what driver do the use?

They use their own driver.
Edit: However I recall they recomend that you use your own PID, not sure if they'll let you share their VID. But if you leave the defaults for just the USB-UART vanilla functionality I guess it should be ok to leave the default Cypress PID and VID.

[f4eru]

As a developer..... I always buy important ICs from reputable vendors, and on top of that now I can even properly test them for fakes.
.....
Also, whenever I can I've been using ft230x/ft231x in new designs instead of the common ft232r because of the price.

Aha. So you have a price sensitive application ? that's interesting...  you seem to have a lot of budget for testing fakes though.
That will bite you at some point, because you cannot be sure your test will detect 100% of the fakes, whatever you test.

Never ever think a risk can be brought to 0.
For me, I use reputable vendors who do not push malware to drivers, never ever FTDI any more.

Also, I try to minimize the amount of fakes by using cheap and recent chips in my designs, who do not get copied often because it's probably not worth it.

[RFZ]

As a developer, I love this. I always buy important ICs from reputable vendors, and on top of that now I can even properly test them for fakes.

Yeah, sure... And what if there are already fakes that aren't recognized by the driver today? You buy thousands, test them (costs you extra money), sell the products... and a year later, it turns out they all were fake and FTDI driver blocks them. What would you do? Still thank FTDI that they now recognize even more fakes?

[diyaudio]

Can someone please confirm the Windows KB update... 

[miguelvp]

As a developer, I love this. I always buy important ICs from reputable vendors, and on top of that now I can even properly test them for fakes.

Yeah, sure... And what if there are already fakes that aren't recognized by the driver today? You buy thousands, test them (costs you extra money), sell the products... and a year later, it turns out they all were fake and FTDI driver blocks them. What would you do? Still thank FTDI that they now recognize even more fakes?

What if your processor is an Intel or AMD clone?

It's been asked before, someone show proof of a valid claim of a consumer product. If you pay little for a  USB to Serial cable that has a fake FT232 then take it to who sold it to you. Or order in Italy where counterfeiting is heavily enforced.
 

[RFZ]

What if your processor is an Intel or AMD clone?

It's been asked before, someone show proof of a valid claim of a consumer product. If you pay little for a  USB to Serial cable that has a fake FT232 then take it to who sold it to you. Or order in Italy where counterfeiting is heavily enforced.

If my processor is an Intel clone, I'm pretty sure Intel won't release a driver update causing my CPU to suddenly write "FAKE CHIP DETECTED" all over my RAM, causing Windows to fail with a BSOD. And this is exactly what FTDI is doing.

We don't have to argue about cloned chips or if FTDI has the right to fight them. They do, and it's okay. Just the way they do it is pointless dangerous bullshit.