FTDI - How to remedy the dangerous driver - Page 1
Forum section: electronics / general

author: BartManInNZ
author_rank: Contributor
timestamp: October 23, 2014, 01:06:42 am
content: Given that theorginalthread 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...Quote from: BartManInNZ on October 22, 2014, 11:34:54 pmI 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. Asearchof microsoft's support site should reveal any files named ftdibus.sys that are included in a windows update...

author: linux-works
author_rank: Super Contributor
timestamp: October 23, 2014, 01:13:24 am
content: 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.

author: BartManInNZ
author_rank: Contributor
timestamp: October 23, 2014, 01:21:24 am
content: Quote from: linux-works on October 23, 2014, 01:13:24 amI 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":

author: linux-works
author_rank: Super Contributor
timestamp: October 23, 2014, 02:24:12 am
content: 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.

author: BartManInNZ
author_rank: Contributor
timestamp: October 23, 2014, 02:43:58 am
content: You will find evidence for device driver installation in the "reliability monitor"Control Panel\All Control Panel Items\Action Center\Reliability Monitor

author: westfw
author_rank: Super Contributor
timestamp: October 23, 2014, 08:34:09 am
content: 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...

author: BartManInNZ
author_rank: Contributor
timestamp: October 23, 2014, 08:56:04 am
content: Quote from: westfw on October 23, 2014, 08:34:09 amhttps://www.eevblog.com/forum/reviews/ftdi-driver-kills-fake-ftdi-ft232/msg535270/#msg535270Quote from: marcan on October 23, 2014, 03:31:05 am

author: BartManInNZ
author_rank: Contributor
timestamp: October 23, 2014, 09:50:49 am
content: 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.

author: rew
author_rank: Contributor
timestamp: October 23, 2014, 09:59:52 am
content: 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...)

author: alex.forencich
author_rank: Frequent Contributor
timestamp: October 24, 2014, 06:41:16 am
content: Quote from: westfw on October 23, 2014, 08:34:09 amIt'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.

author: alex.forencich
author_rank: Frequent Contributor
timestamp: October 24, 2014, 06:45:10 am
content: Quote from: BartManInNZ on October 23, 2014, 09:50:49 amThis 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.

author: Rufus
author_rank: Super Contributor
timestamp: October 28, 2014, 05:04:04 am
content: Quote from: alex.forencich on October 24, 2014, 06:41:16 amFTDI 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.

author: Fungus
author_rank: Super Contributor
timestamp: October 28, 2014, 08:27:56 am
content: Quote from: BartManInNZ on October 23, 2014, 01:06:42 amIt 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... )

author: alex.forencich
author_rank: Frequent Contributor
timestamp: October 28, 2014, 08:48:42 am
content: Quote from: Rufus on October 28, 2014, 05:04:04 amWhen 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.

author: Fungus
author_rank: Super Contributor
timestamp: October 28, 2014, 09:05:16 am
content: Quote from: alex.forencich on October 28, 2014, 08:48:42 amEven 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.