FTDI driver kills fake FTDI FT232??

[daveshah]

The redir still works if you go to the link for the zip, (http://www.ftdichip.com/Drivers/CDM/CDM%20v2.12.00%20WHQL%20Certified.zip), it's just that they've changed the URL on the site to the EXE, perhaps so that they can show a warning message or EULA.

EDIT: Yes, after it extracts a EULA is shown with the warning about genuine products. The exe is signed yesterday afternoon, so I wonder they were advised to do this by their lawyers?

[BartManInNZ]

I just reinstalled windows 7 with FTDI driver not yet installed and still have some updates i need to install.
Anyone know which windows update is causing this?

Also I've ready by using FTDI/utilities/FT_PROG 2.8.2.0 u can change back the PID, but if it's a permanent solution, I can't tell.

As I mentioned here:
https://www.eevblog.com/forum/reviews/ftdi-how-to-remedy-the-dangerous-driver/msg535202/#msg535202
It's not a traditional "Windows Update" - it comes via the Windows Update drivers service which you will need to disable if you don't want updated drivers installed automatically.

[uski]

WTF? I just noticed that the FTDI download for drivers is a setup executable, and you need to email them if you want to use custom VID/PID - what's that all about?
 
Is this a recent thing or has it been like that for a while?

I *think* that the VID/PID pair is part of the INF file which is signed, so they have to re-sign the driver if they change the VID/PID. So it's normal you have to get in touch with them to get a custom driver package signed if you want to change the VID/PID.

[Monkeh]

The redir still works if you go to the link for the zip, (http://www.ftdichip.com/Drivers/CDM/CDM%20v2.12.00%20WHQL%20Certified.zip), it's just that they've changed the URL on the site to the EXE, perhaps so that they can show a warning message or EULA.

They no longer provide a link to the zip.

[FPGAcrazy]

I was under the impression that FTDI already can change the VID/PID in the chip?
If so, they can always, with a driver update brick any device. Technically speaking the device is not bricked it just has a new VID/PID. After reprogramming it with the correct VID/PID the chip will function again with older drivers or can be used on Linux.

I even think there are more vendors which can change the VID/PID of their product.
This is not new and often will be used as a feature. I know one vendor which has a chip which can be configured over the USB bus. That is it starts out as generic device and through an upload of the firmware and disconnect/reconnect it is recognized as the new device.

All these devices can always be compromissed from within in the driver.

Still understand FTDI, but this method not very nice, actually plain stupid. Still curious if it on purpose or if it a side effect of the detection method  I guess I will never know 

[Kjelt]

One product will be most likey be changed to Silicon Labs CP2110 or CP2104.

Don,t know the large quantity pricing, but looking at farnell and mouser you can even safe more then half the cost for that ic, so why not change?

[Chipguy]

WTF? I just noticed that the FTDI download for drivers is a setup executable, and you need to email them if you want to use custom VID/PID - what's that all about?
 
Is this a recent thing or has it been like that for a while?

I got 2.10.00 drivers which still came as INF files.

[rsjsouza]

The redir still works if you go to the link for the zip, (http://www.ftdichip.com/Drivers/CDM/CDM%20v2.12.00%20WHQL%20Certified.zip), it's just that they've changed the URL on the site to the EXE, perhaps so that they can show a warning message or EULA.

They no longer provide a link to the zip.

I just saved the file pointed to by the link above.

[Monkeh]

The redir still works if you go to the link for the zip, (http://www.ftdichip.com/Drivers/CDM/CDM%20v2.12.00%20WHQL%20Certified.zip), it's just that they've changed the URL on the site to the EXE, perhaps so that they can show a warning message or EULA.

They no longer provide a link to the zip.

I just saved the file pointed to by the link above.

Congrats.

[LabSpokane]

One product will be most likey be changed to Silicon Labs CP2110 or CP2104.

From the CP2110 manual:

The CP2110 is a USB Human Interface Device (HID), and as most operating systems include native HID drivers,
custom drivers do not need to be installed. The CP2110 does not fit one of the standard HID device types, such as
a keyboard or mouse, and so any CP2110 PC application needs to use the CP2110’s HID specification to
communicate with the device. The low-level HID specification for the CP2110 is provided in “AN434: CP2110/4
Interface Specification.” This document describes all of the basic functions for opening, reading from, writing to,
and closing the device as well as the ROM programming functions.
A Windows DLL that encapsulates the CP2110 HID interface and also adds higher level features such as read/
write time-outs is provided by Silicon Labs. This DLL is the recommended interface for the CP2110. The Windows
DLL is documented in CP2110 Windows DLL Specification.
Both of these documents and the DLL are available in the CP2110EK CD as well as online at
http://www.silabs.com/.

So, you are going to write additional software to bridge between the low-level HID driver and serial port functionality?  Or is the change simpler than that?

[XFDDesign]

So, you are going to write additional software to bridge between the low-level HID driver and serial port functionality?  Or is the change simpler than that?

With the CP2102 & CP2101, they appear to be direct competitors to the FTDI part. I think the big hangup for most people has been the QFN package vs. SSOP.

[rob77]

interresting....

http://www.ftdichip.com/Drivers/CDM/CDM%20v2.12.00%20WHQL%20Certified.zip

redirects to:

http://www.ftdichip.com/Drivers/CDM/CDM%20v2.10.00%20WHQL%20Certified.zip

so even if you try to download the 2.12 you'll get the older 2.10... interesting , apparently they changed the redirect again 

it looks like some kind of schizophrenic fight 

[mrflibble]

The redir still works if you go to the link for the zip, (http://www.ftdichip.com/Drivers/CDM/CDM%20v2.12.00%20WHQL%20Certified.zip), it's just that they've changed the URL on the site to the EXE, perhaps so that they can show a warning message or EULA.

They no longer provide a link to the zip.

Looks like they indeed quickly changed the linking page.

Current version:
http://www.ftdichip.com/Drivers/D2XX.htm

Snapshot a few days ago:
https://web.archive.org/web/20141012061236/http://www.ftdichip.com/Drivers/D2XX.htm

Google cache also still shows the zip link:
http://webcache.googleusercontent.com/search?q=cache:CK-LKzirhLAJ:www.ftdichip.com/Drivers/D2XX.htm

No idea why they think this helps, but oh well.

And while we're at it, direct link to archived version of that zip:
https://web.archive.org/web/20140710231626/http://www.ftdichip.com/Drivers/CDM/CDM%20v2.10.00%20WHQL%20Certified.zip

Just checked it, and that is indeed the exact same zip file.

[LabSpokane]

So, you are going to write additional software to bridge between the low-level HID driver and serial port functionality?  Or is the change simpler than that?

With the CP2102 & CP2101, they appear to be direct competitors to the FTDI part. I think the big hangup for most people has been the QFN package vs. SSOP.

OK, it just appears to me that with FTDI you get the serial port handling within Windows with the driver, and with CP21XX one might have some more to do.  And this is actually an honest, "I don't know" question, I'm not trying to shill for FTDI. 

[Vendan]

So, you are going to write additional software to bridge between the low-level HID driver and serial port functionality?  Or is the change simpler than that?

With the CP2102 & CP2101, they appear to be direct competitors to the FTDI part. I think the big hangup for most people has been the QFN package vs. SSOP.

OK, it just appears to me that with FTDI you get the serial port handling within Windows with the driver, and with CP21XX one might have some more to do.  And this is actually an honest, "I don't know" question, I'm not trying to shill for FTDI.

Honestly, half the time I want to do more on the windows side.  It's stupid to say "Find the com port, it may change depending on what usb port you plug into and if you've restarted since last time" rather then being able to write my software to look for my specific usb device.

[XFDDesign]

OK, it just appears to me that with FTDI you get the serial port handling within Windows with the driver, and with CP21XX one might have some more to do.  And this is actually an honest, "I don't know" question, I'm not trying to shill for FTDI.

I am taking this as a sort of "Don't trust, and instead verify" approach. I ordered the CP2102EK kit in order to see how different they are. My core goal is for the user to plug the thing in, and not muck with anything. Also, don't fret, I didn't take anything you said as having malicious intent. SILabs' thing is that they have a number of odd permutations, so not all of them are actually competitive to the FT232R parts.

[LabSpokane]

OK, it just appears to me that with FTDI you get the serial port handling within Windows with the driver, and with CP21XX one might have some more to do.  And this is actually an honest, "I don't know" question, I'm not trying to shill for FTDI.

I am taking this as a sort of "Don't trust, and instead verify" approach. I ordered the CP2102EK kit in order to see how different they are. My core goal is for the user to plug the thing in, and not muck with anything. Also, don't fret, I didn't take anything you said as having malicious intent. SILabs' thing is that they have a number of odd permutations, so not all of them are actually competitive to the FT232R parts.

I hope that once you and others have the chance to try it out, that you will post your impressions of the platform and process. 

[sewnbacktogetherwrong]

After a bit of hunting around, I found a way to unbrick my bricked device (set the PID back to 6001) using the ft232r utility in Linux.

I wrote up the steps here: http://www.minipwner.com/index.php/unbrickftdi000

*Disclaimer - I am not promoting the use of these fake FTDI chips.  They've given me nothing but headaches.  I order Arduino Nano's in batches for workshops I run, and for the last year I've had to pre-order one, check that its a legit chip to the best of my ability, and then order the rest of the batch from the same supplier.  (And yes I do ask the supplier ahead of time but they don't always get it right either).

[ttt]

Franky i don't understand why the counterfeiters don't just release their own driver and separately Id the chip,.........

Frankly speaking, and call me a bigot if you need, but many Chinese manufacturers operate on cloning for cost reduction and not innovation.

Bingo. Writing drivers which work across a whole set of Windows version is difficult to say the least and requires long term commitment. FTDI has a track record of keeping their drivers running as the Windows platform evolves. There is a lot of value to that. The minimum you need is to to pay a driver engineer on a continuous basis to keep the driver working. I've dealt with driver level engineering for years: At minimum you have to make changes a few times a year to keep drivers working with new OS versions, new architectures, new security models etc.

Take a look at the FTDI driver page and realize the amount of platforms they support: http://www.ftdichip.com/FTDrivers.htm It's pretty amazing and every single one has it's own issues/bugs which need to be worked around. They still support Windows 98!

I expect the next big change in drivers to be around USB security in general. As the 'BadUSB' exploit becomes used in the wild Microsoft will have to start to lock down USB to mitigate these kind of attacks. That will likely affect all drivers.

In the end a Chinese fly by company could never afford to write their own drivers. I also doubt that an open source project would be able to handle that given the amount of QA you need to do on drivers. It's very costly.

What I expect to see, honestly, is a slight change to the clones which inhibit the write, and then FTDI is back to square one, with a large consumer base that is FTDI phobic. Any man can create a lock which he himself cannot pick.

Correct. It sounds like the cloners will just adjust to the current situation and continue to make more fake chips. It could even drive more sales for them by selling it under a 'works with new FTDI driver' tag. In meantime you have a large base of angry customers.

I think the right strategy for FTDI would have been to enter the arms race like everyone else and start to include fingerprint/authentication silicon into their new chips like most companies now start to do. It sucks that we have to this route, but the lack of IP/copyright enforcement in various countries really forces the hand here. This lack of enforcement also affects open source software BTW. Tons of Chinese products use GPL software without ever releasing source code. My recent stint with security cameras show they are pretty much all using GPLd video/H.264/linux software. And no way for me to fix the broken software in those devices since they don't release source code...

[German_EE]

"Honestly, half the time I want to do more on the windows side.  It's stupid to say "Find the com port, it may change depending on what usb port you plug into and if you've restarted since last time" rather then being able to write my software to look for my specific usb device."

Agreed, the constantly changing COM port numbers are annoying. My suggested fix is that the USB driver asks the device what COM port it would like to use, and this number is also written on the outside of the case of the peripheral in question.

[sleemanj]

OK, it just appears to me that with FTDI you get the serial port handling within Windows with the driver, and with CP21XX one might have some more to do.  And this is actually an honest, "I don't know" question, I'm not trying to shill for FTDI.

The CP2102 works just fine.  I use USB-Serial modules that all use the CP2102 and have for years, I've sold piles of the things too, no complaints.

Drivers for Linux, Windows and Mac (and WinCE and Android) if your OS doesn't automatically find them...
  http://www.silabs.com/products/mcu/pages/usbtouartbridgevcpdrivers.aspx

[ve7xen]

A MAC address is in its nature not unique nor does it needs to be. As long as you have one MAC address on a segment it works correctly. The IPV6 address needs to be unique if some one clones them you get a lot of problems.

How do you think a constrained device gets an IPv6 address in the IoT universe?
Answer: it is a direct substitute of its MAC address. So NO it is not allowed to have two devices with the same MAC address in this setting

Uhm not quite. Assuming we're talking about SLAAC here because that's the only time the MAC address is related at all to the IPv6 address.

A MAC address is 48-bits. An IPv6 network address is 128-bits. They're not directly related. In a normal situation, the local router will advertise itself, along with a 64-bit (or shorter) network address for the segment. Any host that attaches is then free to select an address (or addresses) it would like to use from within that network; it will have at least 64-bits of address space to work with. In early implementation this was straight-up the MAC address, encoded in a trivial manner, but most OSs now use "privacy addresses" that are basically random and change periodically. Once an address is chosen, default address detection (DAD) is performed to verify that the address is not already in use on the local segment. Then it is bound to the interface.

So you end up with <64 bits of network address, set by the network device>:<64 bits of host address, randomly assigned>. Even when the host part is generated from the interface identifier (MAC), the whole address is still globally unique due to the network address portion.

[hobbes]

How do you think a constrained device gets an IPv6 address in the IoT universe?
Answer: it is a direct substitute of its MAC address. So NO it is not allowed to have two devices with the same MAC address in this setting

The IPv6 EUI-64 address is a function of the MAC address, and the gateway prefix. So the MAC address has to be unique only within the same /64 which mostly falls in the same scope as an IPv4 subnet, or the underlaying layer-2 LAN.

[nctnico]

OK, it just appears to me that with FTDI you get the serial port handling within Windows with the driver, and with CP21XX one might have some more to do.

No, I have used the CP2101 and CP2102 in the past and they work out of the box just like the FT232R does. The only difference is that the CP2101 doesn't come in TSSOP.

[Vendan]

I just did a little poking, and the CP2110 actually looks freaking awesome.  Looks like it has support for making your own "devices" that don't just show up as com ports, but they do use standard usb HID drivers on windows.  All you need is a simple dll bundled with your app and you've got a serial style connection to the device.  No crazy drivers, no hunting for the right ports.  Looks awesome to me!