FTDI - How to remedy the dangerous driver

[BartManInNZ]

Given that the orginal thread about the FRTDI malware has been over-run with inane bullshit rather than constructive comment/criticism/advice I propose we use this thread to help remedy the situation for those stuck with "bricked" FTDI clones...

So has anyone actually identified the Windows Update that introduced the updated driver?
Seems to me that removing this should restore the previous driver preventing the issue- has anyone tested this?

I have a Windows 7 laptop that has a shiny new driver - date 10/09/2014 version 2.12.0.2. I am trying to determine where this came from - I cannot find any evidence to point back to a Windows Update. A search of microsoft's support site should reveal any files named ftdibus.sys that are included in a windows update...

[linux-works]

I did post (repost) some instructions on how to fix the problem.  I have not tried it yet (still at work) but I plan to.

I also did find (not hard, just search for ftdi win7 drivers) many vendors that have older copies of the driver on their site.  some link to ftdi but some have local copies.

the best fix I can think of is to remove the win update version, perhaps even run a registry cleaner to remove all traces of ftdi and then install a previous version that some other vendor provides.  files are often like 'cdm20814_setup.zip'.

not sure what else to say about this. yes, the other thread has gone plaid (so to speak) but there was nothing more to say about it.  ftdi screwed us and what else IS there to say, really?

search for the older drivers and avoid windows updates that you don't know or need, specifically.

[BartManInNZ]

...the best fix I can think of is to remove the win update version...

I have searched extensively - have yet to identify the windows update that delivered the driver files, which will never happen.
It would have been downloaded via the "device installation settings" feature - yes via Windows Update but sadly via a mechanism over which there is little control and rollback is only an option if you have older driver files and disable the auto-installation of "the best driver software":

[linux-works]

wish I saved it before I deleted it (at least a screen shot).

not to worry, easily done on another windows box.  if I can find one that I can do a quick backup on, first, I'll see if a manual run of win-update gets the ftdi kiss-of-death.  I can't remember if I found it in windows update listing or 'programs and files' listing, though.

[BartManInNZ]

You will find evidence for device driver installation in the "reliability monitor"
Control Panel\All Control Panel Items\Action Center\Reliability Monitor

[westfw]

Does anyone know how the driver is detecting counterfeit chips?  It would be nice to package that up for running on an old system, just for checking suspect boards/etc...

[BartManInNZ]

Does anyone know how the driver is detecting counterfeit chips?  It would be nice to package that up for running on an old system, just for checking suspect boards/etc...

https://www.eevblog.com/forum/reviews/ftdi-driver-kills-fake-ftdi-ft232/msg535270/#msg535270

In case anyone was still wondering if this is intentional and malicious...



Straight out of their driver. Function/variable naming and comments mine.

Edit: Ooooh this is cleverer than I thought. So what's going on is that on real FT232RLs, the EEPROM is written in 32-bit units: writes to even addresses are buffered, and writes to odd addresses write 32 bits at once: the buffered 16 bits, and the supplied 16 bits. So, on a real FT232RL, this code does nothing; it just buffers 16 bits then buffers another 16 bits and no writes are issued. On a clone FT232RL, this writes the PID to 0 (breaking the checksum) and writes not the checksum, but the value required to make the existing checksum match to address 62. In combination, these two writes make the checksum at address 63 valid again (without modifying it). I've updated the image above with the new analysis.

[BartManInNZ]

So with this information, can the driver be modified to reverse the situation on clone chips where the PID has been set to 0000?

In other words - someone with an XP laptop (or driver signing disable windows 7/8) could revive a 'bricked' clone FTDI chip simply by installing the modified driver.

[rew]

Ehhhh. If they find it reasonable to write "values" to hardware devices that disables some devices but not others, would it be reasonable for me to drop/change a  few bytes in some some software routines before it gets run?

(I'm not normally into hacking software, but when a vendor promised to get me their hardware key in three days and sent me a 3-day software-key to "hold me over until that time", I had nothing else to do when the software key expired and the hardware key had not yet arrived. So some NOP instructions accidentally corrupted the binary of their product so that it would work with the expired software key...)

[alex.forencich]

Does anyone know how the driver is detecting counterfeit chips?  It would be nice to package that up for running on an old system, just for checking suspect boards/etc...

It's NOT detecting counterfeit chips, it's writing a sequence of commands that are ignored if the EEPROM on the chip is implemented the way it is on the FT232RL.  The code is specifically designed to set the PID to zero and fix the checksum by only writing to locations that are buffered and not written in a legitimate FTDI chip. 

It would be possible to make a version of this that performs a test read, write, read, and restore operation to check to see how the EEPROM is implemented, but it would not be without risk as interrupting the cycle between writes could leave the non-FTDI part in an inconsistent state. 

I think there is one point that needs to be made clear: the counterfeit chips are counterfeits because they are marked with the FTDI logo and part number, not because they present the FTDI VIN and PIN and speak (nominally) the same protocol.  I think many of the 'counterfeit' FTDI chips are actually legitimate FTDI-compatible clones that have been re-marked.  This is the main reason why FTDI's actions are illegal as they target legitimate clones as well as counterfeit chips, where the only difference is the package marking. 

[alex.forencich]

So with this information, can the driver be modified to reverse the situation on clone chips where the PID has been set to 0000?

In other words - someone with an XP laptop (or driver signing disable windows 7/8) could revive a 'bricked' clone FTDI chip simply by installing the modified driver.

This already exists.  FTDI makes a program so you can change the VID and PID to customize the chip for your product.  The only reason you can't use this to fix it on windows 7/8 is the USB stack on windows 7/8 does not like a PID of 0 and as a result the chip does not enumerate correctly.  I do not believe this is a problem in windows XP.  Just change the driver inf file so that it recognizes the PID of 0, then use the FTDI configuration software to write back the correct PID. 

[Rufus]

This is the main reason why FTDI's actions are illegal as they target legitimate clones as well as counterfeit chips, where the only difference is the package marking.

FTDI drivers are only licensed for use with genuine FTDI parts the marking is irrelevant they are preventing illegal use of their drivers not 'attacking' counterfeits. Changing the PID prevents the drivers repeatedly testing the parts which would really brick them when the EEPROM is worn out. Changing the PID also makes it more difficult to illegally use older drivers which didn't check for non-genuine parts.

And yes blah blah blah it caused a problem with legal use of open linux drivers which has already been fixed with a driver update.

[Fungus]

I have a Windows 7 laptop that has a shiny new driver - date 10/09/2014 version 2.12.0.2. I am trying to determine where this came from - I cannot find any evidence to point back to a Windows Update.

It was definitely via Windows Update. It was in my list of "optional" updates yesterday but it's mysteriously vanished since then.


(I don't enable automatic install of updates precisely because of crap like this. Once bitten, twice shy... )

[alex.forencich]

This is the main reason why FTDI's actions are illegal as they target legitimate clones as well as counterfeit chips, where the only difference is the package marking.

FTDI drivers are only licensed for use with genuine FTDI parts the marking is irrelevant they are preventing illegal use of their drivers not 'attacking' counterfeits. Changing the PID prevents the drivers repeatedly testing the parts which would really brick them when the EEPROM is worn out. Changing the PID also makes it more difficult to illegally use older drivers which didn't check for non-genuine parts.

And yes blah blah blah it caused a problem with legal use of open linux drivers which has already been fixed with a driver update.

When I say 'legal' and 'illegal' I am not referring to whatever BS they put in the license.  There are laws against wilful destruction of property that the license does not make them immune to.  They do not have the legal authority to destroy devices that have not been proven to be counterfeit.  The 'brick' result in these particular cloned chips is the result of a piece of code which serves no other purpose but to attempt to brick cloned chips.  Hence wilful destruction of property.  I suppose it will take a court to determine if overwriting the internal configuration memory qualifies as destruction of property, though.  I personally say that it does; that config EEPROM is not modified during normal operation, it's only meant to be written once at the factory when the device is built.  It's akin to Windows overwriting your BIOS if it fails any WGA check. 

[Fungus]

I suppose it will take a court to determine if overwriting the internal configuration memory qualifies as destruction of property, though.  I personally say that it does; that config EEPROM is not modified during normal operation, it's only meant to be written once at the factory when the device is built.  It's akin to Windows overwriting your BIOS if it fails any WGA check.

Even if their 'hack' is reversible I could still suffer loss of business as a result of it.

My production line could go down for a couple of days if all the serial ports stop working, possibly bankrupting my company.

FTDI is liable for that - they chose to disable the device with no warning instead of, eg., popping up a dialog box to tell me about the problem and giving me time to remedy it.