FTDIgate 2.0?

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

[miguelvp]

The dangerous part is all speculation.

[Karel]

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 that case the designer was incompetent. If a device can cause injuries or death, it should have at least some crc check over the
communication channels, specially with rs232. Rs232 is well known for possible glitches on the line.
Only incompetent engineers send plain and unprotected data via rs232 to a potential dangerous device.

[RFZ]

The dangerous part is all speculation.

Maybe it is. Maybe it won't actually cause a serious malfunction of a device ever.

What it does cause is damage to people that have nothing to do with it. And I mean really nothing. Like Intel and their Galileo board:
https://communities.intel.com/thread/80586
A user connected the board to its PC using a USB to serial converter and after some debugging he found the Galileo sending "NON GENUINE DEVICE FOUND!". He thought the Galileo was sending that. And that's fine, who would really consider that the Serial Converter might intentionally alter the data? That's like considering electrons falling out of your device if you hold it upside down...
Even the guys at Intel thought there was something wrong with their Galileo board. They opened a support case for this guy to investigate further. Only this one case kept them busy for one month. And it was complete pointless debugging and burning several hours of Intel employees and the user for no reason. And, it would have been completely avoidable if FTDI did it right or even mention "FTDI USB to Srial Converter" in their f**** message.
I'm pretty sure thousands of completely innocent developers have to waste lots of hours on debugging because of that...

[RFZ]

In that case the designer was incompetent. If a device can cause injuries or death, it should have at least some crc check over the
communication channels, specially with rs232. Rs232 is well known for possible glitches on the line.
Only incompetent engineers send plain and unprotected data via rs232 to a potential dangerous device.

So... All G-Code compliant CNC machines were designed by idiots? G-Code, as far as I know, doesn't specify any type of CRC or error correction. But unexpected movements of CNC machines can be pretty dangerous... And G-Code is just an example here. There might be lots of use cases where you just have to use a given protocol and cannot add security mechanisms to it. That might be dangerous, right, but it's not incompetence!

Edit: With such a product you might be able to accept the risk of 0.001% chance for a corrupted byte being received. But FTDI now raises the chance of data corruption to 99.99% deliberately.

[filssavi]

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 that case the designer was incompetent. If a device can cause injuries or death, it should have at least some crc check over the
communication channels, specially with rs232. Rs232 is well known for possible glitches on the line.
Only incompetent engineers send plain and unprotected data via rs232 to a potential dangerous device.

You are actually aware that CRC is more of a conveniance to avoid glitch than anything else, it's well known that CRC collisione are not only possibile, they are not all that uncommon the only way (for now) to use a hash check to secure a come channel is to use a cryptographic hash function, for example sha2 (there are no collisione found but they are thaught to be close) or more likely sha3

Now sha2 is not known for being resource friendly, try running it on an 8bitter, or even on a low end cm0 or cm0+


Sending random garbage over the channel is really never a good idea no matter how well the system is designed...

[helge]

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.

... and I assume most of the frustration is rooted in the fact that Microsoft never managed to provide a generic USB-Serial device driver.

If you are writing a custom driver:  Before writing a driver for your USB device, determine whether a Microsoft-provided driver meets the device requirements. If a Microsoft-provided driver is not available for the USB device class to which your device belongs, then consider using generic drivers, Winusb.sys or Usbccgp.sys. Write a driver only when necessary.

It might have prevented some funky features like the speed of the D2XX library or MPSSE but for most of the applications it would have worked a treat. Need SPI and JTAG simultaneously? Sure, why not, use the FT2232H. Just need the good 'ol 115200 8N1? Use <generic driver> with <generic usb serial adapter>. Imagine having to install a vendor driver for a mouse or keyboard before being able to use it.

[janekm]

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.

... and I assume most of the frustration is rooted in the fact that Microsoft never managed to provide a generic USB-Serial device driver.

If you are writing a custom driver:  Before writing a driver for your USB device, determine whether a Microsoft-provided driver meets the device requirements. If a Microsoft-provided driver is not available for the USB device class to which your device belongs, then consider using generic drivers, Winusb.sys or Usbccgp.sys. Write a driver only when necessary.

It might have prevented some funky features like the speed of the D2XX library or MPSSE but for most of the applications it would have worked a treat. Need SPI and JTAG simultaneously? Sure, why not, use the FT2232H. Just need the good 'ol 115200 8N1? Use <generic driver> with <generic usb serial adapter>. Imagine having to install a vendor driver for a mouse or keyboard before being able to use it.

It was political; Intel/Microsoft didn't want lazy device manufacturers shipping all their devices with generic serial adapter drivers (eliminating the perceived benefits of USB plug&play) so they decided to not ship a standard driver (well sort of did eventually, but requiring the .inf config file). Can't find the source any more though...

[Karel]

You are actually aware that CRC is more of a conveniance to avoid glitch than anything else, ...

Yes, I am. It was just an example of how to make communication more robust.
It's true that there's no 100% failsafe solution. But not using any protection because nothing is 100% secure, proves incompetency.
You want to use your credit card online via an unencrypted channel? Please do, in the end, nothing is 100% secure... no?

Do you know how Google (and other companies) test and improve their software? By feeding it random data and see what happens.

I repeat my statement. Only incompetent engineers use rs232 in possibly dangerous devices without some protocol to check if the data is valid.

[all_repair]

The dangerous part is all speculation.

Surprise that you said this.  Of course, it is speculation when you have no real body count to prove .   Once you have one, it becomes a crisis when something not suppose to happen happens, and people started to ask where are all the planning, thinking, and were the engineers sleeping?

[donotdespisethesnake]

In that case the designer was incompetent. If a device can cause injuries or death, it should have at least some crc check over the
communication channels, specially with rs232. Rs232 is well known for possible glitches on the line.
Only incompetent engineers send plain and unprotected data via rs232 to a potential dangerous device.

So... All G-Code compliant CNC machines were designed by idiots?

Pretty much, yes. G-code was invented sometime last millenium, when CPUs were expensive, so there is some small excuse, but not for the past 30 years.

I've been working in comms and embedded for about 30 years, and anyone doing comms without a robust protocol is definitely incompetent. In a safety critical area, I would expect integrity checking on anything read from disk as well.

Unfortunately, incompetence is quite widespread in the software industry, many people I have worked with are little better than untrained amateurs. The management are usually even more clueless. So it does not surprise me at all.

If your safety critical device fails due to the FTDI data, it was never properly designed or tested, and should never have been certified safe.

[RFZ]

So... All G-Code compliant CNC machines were designed by idiots?

Pretty much, yes. G-code was invented sometime last millenium, when CPUs were expensive, so there is some small excuse, but not for the past 30 years.
[...]
If your safety critical device fails due to the FTDI data, it was never properly designed or tested, and should never have been certified safe.

Okay. So nevertheless, you agree that there actually are lots of devices out there, designed by idiots, that may fail in not the best way if they receive garbage. Right?

[nctnico]

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 that case the designer was incompetent. If a device can cause injuries or death, it should have at least some crc check over the

It is not only about a CRC check but also about buffer overflows. I totally agree about the incompetent designer remark but the fact is those kind of designers are out there and put their software in products which are on the market. We don't live in an ideal world so it is better to be cautious and not send random data to a device.