FTDI driver kills fake FTDI FT232??

[orin]

I could be wrong (it's happened before) but I thought part of the WHQL process was that your drivers have to undergo a code review at Microsoft. That's why WHQL certification costs so much money.

For the USB drivers I've had WHQL certified, you create the driver, sign it with your own certificate and run the WHQL test suite on it on your own computers.  The results get wrapped up along with the signed driver and sent to Microsoft.  Assuming the driver passed the test suite, your driver then gets signed by Microsoft with the WHQL certificate and you download it.  That's it.

OK ... maybe USB is different because it can't really destabilize Windows (it's just a data transfer device).

A kernel mode USB driver sure can destabilize any operating system and cause panics/BSODs/whatever your OS calls it.  The WHQL test suite makes (most?) all the calls to the driver that every USB driver/device must support, but as I said, the driver can make vendor specific calls that the WHQL tests cannot validate.

As for deliberate BSODs, that is the absolute worst thing they could do.  Bricking the device is bad enough, but potentially trashing my filesystem is much worse.  Besides, if I get A BSOD, I run WinDbg on the dump and look for the cause.  If I were to see an FTDI driver as the cause, I would think that FTDI write crappy drivers and it is yet another reason to avoid them like the plague, just like I avoid Prolific chips now.  (I have a most-likely-counterfeit 'Prolific' USB-serial cable.  New drivers refuse to load; old drivers BSOD as soon as you transfer any reasonable amount of data.  That the BSOD was deliberate was news to me... I had assumed bad drivers or bad chip.  The result was that I used to advise that one should use FTDI based cables rather than Prolific.  )

[GaryM]

So I'm dumb and the clone detector tool that I linked before relied on a patched libftdi (which I hacked up when this saga started and then forgot about...)

So instead I rewrote it to use libusb and made it a lot more useful. Now it can:

• Tell you if you have a clone chip
• Fix bricked clones (by undoing exactly what the FTDI driver did, restoring the PID to 6001 but also reverting the value at 0x3e - this might fix string data corruption if your strings area was full when the FTDI driver did its dirty work, or if user data was in use)
• NEW: immunize clone chips against the evil driver by deliberately breaking the EEPROM checksum. This reverts all settings to defaults (and loses the serial number), but if those work for you, then FTDI's driver will not brick your device and will happily work with it. You can also revert this change.
  

https://mrcn.st/t/ftdi_clone_tool.py

Tested on both real devices (where it refuses to do anything) and on clones (where all of the above works; I tested it against FTDI's driver too).

A big thanks to marcan for this script. I have a couple of devices that came from unknown sources in China and which I suspected may contain fake FTDI chips. marcan's script has confirmed that both devices actually contain genuine FTDI chips which came as a bit of a surprise.

One thing to note is that when running the script I was getting the following timeout error:-

Detecting device...
Found FTDI FT232R device (0403:6001)
Traceback (most recent call last):
  File "ftdi_clone_tool.py", line 234, in <module>
    sys.exit(main())
  File "ftdi_clone_tool.py", line 106, in main
    dev.unlock_eeprom()
  File "ftdi_clone_tool.py", line 68, in unlock_eeprom
    timeout=self.timeout)
  File "/usr/local/lib/python2.7/site-packages/usb/legacy.py", line 205, in controlMsg
    timeout = timeout)
  File "/usr/local/lib/python2.7/site-packages/usb/core.py", line 971, in ctrl_transfer
    self.__get_timeout(timeout))
  File "/usr/local/lib/python2.7/site-packages/usb/backend/libusb0.py", line 528, in ctrl_transfer
    timeout
  File "/usr/local/lib/python2.7/site-packages/usb/backend/libusb0.py", line 380, in _check
    raise USBError(errmsg, ret)
usb.core.USBError: [Errno None] error sending control message: Connection timed out

To resolve this I needed to update the self.timeout value on line 60 to something higher than 100. An extended timeout may have been needed because my Linux distro is running under a VM within Windows so it might well take the VM longer to talk to the USB port devices (I'm not sure) but after a few unsuccessful attempts at slightly larger values I eventually found that a value of 2000 worked successfully under my setup.

[Rufus]

The machine was working yesterday because you were stealing FTDI drivers. The machine is not working today because FTDI stopped you stealing their drivers.

"Stealing" is theft, the taking of property with intent to permanently deprive the owner.  Using a software driver without consent of the copyright holder is more akin to pillage and murder on the high seas, so we prefer to call it "piracy" or "terrorism".

Most people do not demand that FTDI's precious drivers work with counterfeit chips, just that they not intentionally destroy them.

Yawn - I shall continue to call unlicensed use of software stealing for as long as other call modifying a USB device PID destroying.

[nathancrum]

Don't care if it's legal.  Don't care if it's ethical.  Don't care if it's destruction or not destruction.  Don't care if it's reversable.

From the perspective of a designer, FTDI has just introduced considerable risk in using their product.  That's all that matters to a designer.  "I might get burned if I use this part - even if I specify genuine parts."  Well - there are several alternatives without that risk - so that's what I'm going to use from now on.  I just pulled an FTDI chip from a new design today in fact - I'm sure I'm not the only one.

[Chasm]

[...] The result was that I used to advise that one should use FTDI based cables rather than Prolific.  )

And there is the moneyshot of this whole debacle.

Why are companies using FTDI in the first place? Because FTDI chips work(ed), pretty much no matter what.
Maybe because they have better supply chain controls.
Maybe because the FTDI fakes, if someone slipped you them into the supply chain, are better than the others.

We now know that FTDI, unlike Prolific, did not play games with their drivers - so far. We also know from decapped fakes that at least some of them use newer production methods than the originals.
Maybe someone in CN said "Gee, reproducing the functions of the FT232 is so damn easy, lets go all the way so that we don't get complaints and have to do it again next month." Because guess what, selling chips for profit that are known not to work is damn hard even if you trade in counterfeits.

Now you have a situation where products that tested perfectly fine in manufacturing could be bricked bay a parts supplier days or even years after they have been sold. Not cool and definitely a red flag for any company.

[a210210200]

Yep, apparently if you get an old enough driver it should work fine for you. It might be "legitimate" breakage due to missing features or something in the counterfeits, but it appears it was common after a certain driver version. Or just use Linux and they all work fine...

So, could one confirm that no problem what so ever on Linux machines with any FTDI chips even counterfeit ones?

How to recognize those FTDI counterfeit chips? Only when we have them in our hands -they look different or automatic by some kind of communication protocol small differences if any?

Anyway, If those FTDI counterfeit chips works under Linux without any problem and are much cheaper than those original FTDIchip.com "idiots" chips, are there any way to find those  counterfeit chips from their competitors and use on custom PCB since this device will never be connected to Micro$oft Window$, but of course embedded Linux system will be used?
Any problems with those FTDI counterfeit chips on small Linux ARM platforms?

Lets forget about company like @ftdichip.com as well as Window$ 

Technically what your talking about doing is illegal especially since your willingly attempting to get counterfeit chips. The legal way would be to find an FTDI pin compatible but non-FTDI PID/non-FTDI labeled chip.

[a210210200]

I am still fairly new to Electronic Engineering. I was going to make something using a FTDI part but with all of the conservancy I don't want to use them. What is a good alternative to FTDI?

Ten seconds with google:

http://www.ti.com/product/tusb3410

http://www.microchip.com/wwwproducts/devices.aspx?dDocName=en546923

Ten seconds on the datasheet. Both require 12Mhz external oscillators and so on. I like FTDI's design and functionality.

[Rufus]

From the perspective of a designer, FTDI has just introduced considerable risk in using their product.  That's all that matters to a designer.  "I might get burned if I use this part - even if I specify genuine parts."

You might get burned by fakes of unknown quality and origin regardless of which manufacturer they are faking.

You are saying that you will choose a part which is more likely to let you get away with shipping low quality shit - nice one, care to let us know what products we should be avoiding?

In the future I will be taking the use of FTDI parts as an indication of a supplier who cares about the quality of their products and has confidence in their supply chain.

[sunnyhighway]

The machine was working yesterday because you were stealing FTDI drivers. The machine is not working today because FTDI stopped you stealing their drivers.

"Stealing" is theft, the taking of property with intent to permanently deprive the owner.  Using a software driver without consent of the copyright holder is more akin to pillage and murder on the high seas, so we prefer to call it "piracy" or "terrorism".

Most people do not demand that FTDI's precious drivers work with counterfeit chips, just that they not intentionally destroy them.

Yawn - I shall continue to call unlicensed use of software stealing for as long as other call modifying a USB device PID destroying.

Source: http://www.thefreedictionary.com/steal

steal  (stl)
v. stole (stl), sto·len (stln), steal·ing, steals
v.tr.
1. To take (the property of another) without right or permission.
2. To present or use (someone else's words or ideas) as one's own.
3. To get or take secretly or artfully: steal a look at a diary; steal the puck from an opponent.
4. To give or enjoy (a kiss) that is unexpected or unnoticed.
5. To draw attention unexpectedly in (an entertainment), especially by being the outstanding performer: The magician's assistant stole the show with her comic antics.
6. Baseball To advance safely to (another base) during the delivery of a pitch, without the aid of a base hit, walk, passed ball, or wild pitch.

Source: http://www.thefreedictionary.com/destroy

de·stroy  (d-stroi)
v. de·stroyed, de·stroy·ing, de·stroys
v.tr.
1. To ruin completely; spoil: The ancient manuscripts were destroyed by fire.
2. To tear down or break up; demolish. See Synonyms at ruin.
3. To do away with; put an end to: "In crowded populations, poverty destroys the possibility of cleanliness" (George Bernard Shaw).
4. To kill: destroy a rabid dog.
5. To subdue or defeat completely; crush: The rebel forces were destroyed in battle.
6. To render useless or ineffective: destroyed the testimony of the prosecution's chief witness.

@Rufus

[a210210200]

On the subject of currency copying that was discussed earlier. I was once I.T. Manager at a company that had a high-end Xerox color copier installed in the Advertizing and Sales Department. The handbook warned us that internal software would prevent making copies of bank notes so with the installation engineer present I tested this with a brand new 20 Euro note.

The machine printed a copy of the note but with the Xerox logo in the center, it then shut down and would not restart until the installation engineer reset an internal flag (could have been an EEPROM or flash) using his laptop. The machine did NOT phone home but the particular internal flag was only set after attempting to copy currency.

Now back to our regular programming 

It probably also prints your machine Serial No and various other info on the color printouts in any case (the yellow dot pattern) its a good way to verify important documents yourself and is probably worse than phone in since every color document has the info, timestamp, ...

[a210210200]

Technically using a driver that says FTDI with a non physically FTDI chip is stealing since your both using their software and hardware IP directly but illegitimately.

Modifying the PID is not breaking anything the device still works properly and if you wrote your own driver it would communicate with that. And if you get WHQL certification your driver can be plug-in play as well. Kills is a poor way to say it in reality it is just the drivers that are saying get your own driver.

If they killed the chips electrically which is possible via the config then that would be considered breaking it.

[a210210200]

I don't understand what the fuss about this is other than their obviously poor/abysmal PR spin control.

Simple facts are that from now on its technically not very legal to use counterfeit chips with FTDI drivers (even old drivers). So any counterfeit product that relies on FTDI's default driver is doing so illegally and if using a modern driver will always not work. So end result they are all bricks, Linux/Windows/Mac's driver repositories would either not include the driver at all or would be crossing some legal lines by keeping the older driver around.

Apparently you haven't been reading the previous few dozen pages, but I've already posted this:

http://en.wikipedia.org/wiki/Semiconductor_Chip_Protection_Act_of_1984#Reverse_engineering_not_prohibited

The SCPA permits competitive emulation of a chip by means of reverse engineering.

FTDI might not like it but they don't have an exclusive right to the API their chips use. The only way around this is a patent, but I haven't seen them claiming anything about patents here...

And for this same reason the "FTDI-compatible" serial cables that use a COB package are completely legal since there is nothing in them branded FTDI. They may have FTDI's VID:PID but those are necessary for interoperability and those numbers cannot be copyrighted.

Yes reverse engineering is allowed but branding something FTDI and using FTDI's software is not legal. Pin compatible, PID 0, unmarked FTDI chips are legal and technically function the same.

I'm talking about reverse engineering the software to find out any detection means or additional hidden functions. (Last time I checked the driver is not a semiconductor chip but a file on your computer, which goes into the DMCA land of things)

[0xdeadbeef]

Can someone create a tool to reproduce the "kill" operation of the 2.12 driver? If this is a "thing" that can happen, I'd prefer to add a few seconds of production test time to screen parts that might cause the end-user grief down the road. This is, in essence, a vulnerability without a clear way to patch it - so the easiest route I can do is attempt to brick any devices that might get a non genuine part in the lot. (I buy all my parts from Mouser and Digikey, but they're not omnipotent or flawless).

Here is some code that will non-destructively test for clones and also fix them if bricked.
https://mrcn.st/t/ftdi_clone_tool.py

It should work on a Linux system with Python2 and libftdi1 with Python bindings. I have not tested it on clones as I don't have any, but I believe it should work. AIUI libftdi also works on Mac OS X and Windows, so you should be able to get it to work on those OSes too.
It should work on a Linux system with Python2 and PyUSB. I have tested it and it accurately detects and restores clones. It should also work on Windows and Mac OS X if you have PyUSB with a working backend installed (although I guess Windows > XP might still complain about the zero PID; haven't tested that, if you do please report back).

Edit: I am dumb and forgot that I was using a patched libftdi1 to make this work. Rewrote the entire thing to use libusb instead. You need PyUSB (under Ubuntu, apt-get install python-usb).

I tested several of my el cheapo FTDI device under Windows7 (Python 2.7.8 and pyusb-1.0.0.b2, used Zadig to exchange driver with libusb) and they were all detected as genuine. I'm honestly surprised. They were ultra cheap and I bought them from the typical eBay dealers you would suspect now to have sold you clones. Note that I was aware at that time that clones even existed.

[hans]

Technically using a driver that says FTDI with a non physically FTDI chip is stealing since your both using their software and hardware IP directly but illegitimately.

Modifying the PID is not breaking anything the device still works properly and if you wrote your own driver it would communicate with that. And if you get WHQL certification your driver can be plug-in play as well. Kills is a poor way to say it in reality it is just the drivers that are saying get your own driver.

If they killed the chips electrically which is possible via the config then that would be considered breaking it.

How can that first example be stealing by the way, when it's not physically taking or copying anything.
I've posted this before in the thread, the way their EULA is like so:

The licence only allows use of the Software with, and the Software will only work with Genuine FTDI Components (as defined in the Licence Terms). Use of the Software as a driver for a component that is not a Genuine FTDI Component MAY IRRETRIEVABLY DAMAGE THAT COMPONENT.

It is your responsibility to make sure that all chips you use the Software as a driver for are Genuine FTDI Components. If in doubt then contact FTDI.

That sounds like the driver is intended to be used with FTDI, and it's not tested beyond that. The damage sounds more like a disclaimer than anything else. It's my own responsibility to check on this, otherwise I may get trouble.

Doesn't that mean that is a FTDI-compatible (not saying FTDI-marked; because obviously that's a trademark deal) device is connected, it may work but is not intentional.

The download page says:

"FTDI drivers may be used only in conjunction with products based on FTDI parts."

I personally think "may be used" is not a very strict term, but I could be wrong as English is not my mother tongue.

[eneuro]

Correcting an invalid PID isn't damage. The 'board' still works under Linux with a driver update so it clearly isn't damaged. The machine is not working today because you don't have any driver for the fake chip.

So, it looks like it affects only Window$ customers, but while most of them fight with trojans, virususes and other malware on daily basis than simply marking this fake FTDI driver as a trojan by security antyvirus software community and preventing from updating existing good drivers to this fake version could help many potential victims who bought something and payed real money for it and one sunny day they can think Window$ sucks again, but it is FTDI driver

Any reliable source of those updated FTDI Linux drivers which changes this PID to valid one or simply opensource community quickly made such patch to existing drivers?

The non-FTDI hardware is a functional equivalent design which is perfectly legal to create, own and use.

Nice, so using it under Linux should be fine even now.
Another reason to forget about Window$, but there is hope that Micro$oft will make lawsuit vs FDTI while they probably has much more emergency calls and its support is overloaded by this fake FTDI driver issue right now 

[nctnico]

Technically using a driver that says FTDI with a non physically FTDI chip is stealing since your both using their software and hardware IP directly but illegitimately.

Actually no and no. The software is provided for free. Ofcourse FTDI would like very much that people use their software with their hardware but there is no legal ground to enforce that. The non-FTDI hardware is a functional equivalent design which is perfectly legal to create, own and use.

[rob77]

if someone would ask me how to solve a situation @ FTDI (before they decided to do what they did) then i would suggest the following:

1. start online selling drivers for FTDI compatible chips a.k.a. fake FTDI chips  (e.g. $ 3.99 one time fee)
2. make that driver to accept a specific PID reserved for fake devices
3. add code to free FTDI drivers which will warn the users, that their product is using counterfeit FTDI product and they should buy another version of the driver in order to keep using it.
4. wait few months to let all the users buy the affordable $3.99 driver.
5. make a release which will re-program all fakes to that specific PID chosen for fake devices

[MikeGTN]

Don't FTDI also do some fancy graphics controller FT800 or similar with aspirations in to the Micro processor market. Might be why this whole situation arose. They might have required some additional cash. In the scheme of things are a very small fish. The bigger cloning fish have stolen money from them.

These companies have no teeth to actually chases the criminals, so simple using Microsoft easy to victimise innocent people. This high flying processor will never get off the ground as no money to make this actually happen. I will wear a kilt in public if this ever happens!

Regards
Mike.

[Simon]

Don't FTDI also do some fancy graphics controller FT800 or similar with aspirations in to the Micro processor market. Might be why this whole situation arose. They might have required some additional cash. In the scheme of things are a very small fish. The bigger cloning fish have stolen money from them.

These companies have no teeth to actually chases the criminals, so simple using Microsoft easy to victimise innocent people. This high flying processor will never get off the ground as no money to make this actually happen. I will wear a kilt in public if this ever happens!

Regards
Mike.

I think FTDI have just lowered the likelihood of people wanting to use their processors, I think it's called shooting yourself in the foot!

[free_electron]

Why don't you try stealing something from a shop and see how far you get accusing a cop taking back that something of theft?

I love to see the reaction if I take a free piece of saucage from the butcher shop and feed it to my dog  What is the butcher going to do legally even if he puts up a sign saying 'don't give free saucage samples to your pets' ? Remember FTDI gives the drivers away for free!

licence clause says to be used with ftdi parts only. they may be free but they are restricted to use in conjuction with real FTDI parts.

[free_electron]

there are some people in this thread asking why we need a ftdi driver at all. why not use the default cdc class.
simple: the ftdi parts implement much more functionality than the cdc class has functions for.
- unique serial numbers
- bitbanging the pins
- the MPSE that can do spi and i2c

these chips have lots of capabilities going beyond default CDC operation. so yes, you need the FTDI driver.

now, that said , that may be an avenue to check for real or fake. pretty sure the fakes can only do the serial stuff, none of the other functionality a real ftdi had

[Rufus]

Technically using a driver that says FTDI with a non physically FTDI chip is stealing since your both using their software and hardware IP directly but illegitimately.

Actually no and no. The software is provided for free. Ofcourse FTDI would like very much that people use their software with their hardware but there is no legal ground to enforce that.

The drivers are copyrighted and the holder can place whatever restrictions they like on their use. Are you suggesting GPL and all the other various open source licences have no legal standing because you were not charged for what they cover?

if someone would ask me how to solve a situation @ FTDI (before they decided to do what they did) then i would suggest the following:

1. start online selling drivers for FTDI compatible chips a.k.a. fake FTDI chips  (e.g. $ 3.99 one time fee)

Complete non-starter. FTDI have absolutely no control over fakes, you and they can't even tell who manufactured them. No way would they take on the responsibility for making drivers work with hardware which is effectively undefined.

[Chipguy]

From the perspective of a designer, FTDI has just introduced considerable risk in using their product.  That's all that matters to a designer.  "I might get burned if I use this part - even if I specify genuine parts."  Well - there are several alternatives without that risk - so that's what I'm going to use from now on.  I just pulled an FTDI chip from a new design today in fact - I'm sure I'm not the only one.

Nathan Crum, that's exactly a 1000% right. You are not alone, I am currently in the process of replacing a FT230X with a CY7C65211 from Cypress.
The evaluation kit should come tomorrow.

I got the first call today from a customer having a problem with his meter connecting to USB.
He was asking, almost accusing if me, we could have used one of the counterfeit FTDI's.
I am 99.999% sure that's not the case since production only buys from FTDI listed suppliers.
Now some of our end customers start worrying if they might have gotten a counterfeit chip in their meters and whenever USB is not working those who got the news start asking/ thinking.

In the end FTDI is now damaging our reputation, I am even afraid that some customers might stay off our products BECAUSE we use FTDI.
This situation is inacceptable.

Until that call today I thought "We are fine... all genuine". I didn't even think that that could even bite me in that way.
You can understand that I am pretty pissed. FTDI DICKHEADS

[sunnyhighway]

Complete non-starter. FTDI have absolutely no control over fakes, you and they can't even tell who manufactured them.

Ask any owner of a bricked fake device. I'm pretty sure they don't share your opinion of having no control over fakes.

No way would they take on the responsibility for making drivers work with hardware which is effectively undefined.

If the hardware of the fake chip was effectively undefined there would be no breach of IP on the hardware side of things would it?

[Rufus]

The CP2104 has all of the right characteristics-- built-in osc, etc. that I need in my designs, and the low-cost development kit [above] is "icing on the cake".

Try searching Aliexpress for the number of vendors feeling the need to describe that part as authentic or genuine or original to get an idea of how likely buying fake CP2104s is.