FTDI driver kills fake FTDI FT232??

[Rufus]

Also they didn't change the VID, only the PID, can you justify only modifying the one?

Which other company do you think they should have made the device claim to be manufactured by? Unlike the low life fake manufacturers they have some respect for the VIDs allocated or to be allocated to other companies.

[markb82]

Which other company do you think they should have made the device claim to be manufactured by? Unlike the low life fake manufacturers they have some respect for the VIDs allocated or to be allocated to other companies.

Look no one is saying that FTDI doesn't have a right to protect their IP, and that they love to buy clones, and that clones are the best.  They're not.  FTDI has a right to protect their IP.  They could have done so by having the driver refuse to work with the clone, but not modifying the clone.  And since they themselves are not even willing to acknowledge the change of the PID was intentional, that leads me to believe they feel there is some liability in what they have done.  Unfortunately I doubt anything will come of this legally, since the small guys can not afford to sue, and the large guys will not admit they were using cloned chips.  So FTDI just has to weather the PR storm, which they definitely underestimated.

[Mike Warren]

I can't believe there is so much argument about this. Damaging an end user's product is unacceptable and illegal, even if the product was made illegally. That is not the user's fault.

It is so simple for FTDI to handle this the proper way. Do not communicate with the clones. Popping up a message to tell the used they have a fake is also fine.

Rendering the chip unusable does not gain anything for FTDI beyond refusing to communicate. 

[a210210200]

I can't believe there is so much argument about this. Damaging an end user's product is unacceptable and illegal, even if the product was made illegally. That is not the user's fault.

It is so simple for FTDI to handle this the proper way. Do not communicate with the clones. Popping up a message to tell the used they have a fake is also fine.

Rendering the chip unusable does not gain anything for FTDI beyond refusing to communicate.

Technically refusing to communicate also going to be making the product unusable. The illegal product may cause the user harm/inconvenience the user did not know of this and the possession of a fake isn't illegal but revoking/blocking/preventing the operation of the fake with official drivers is just what HDCP does to fake/counterfeit/or even real but possibly leaked crypto key products. Firmware for consoles and phones will also brick devices that have "unauthorized" modifications that are not careful. (Bypassing is possible but I don't think there are any successful class actions that say Sony/Microsoft/Nintendo can't brick a console on an automatic update that detects things they don't like.

The chip still works, reprogramming, and bypassing FTDI's DRM is trivial. DRM is everywhere and it doesn't seem like it is being successfully challenged in many cases.

[markb82]

Can you agree that changing the PID stopped the Linux driver from working until about 2 days ago when a patch was released to specifically address the issue caused by FTDI changing the PID?

No, users can still bypass it the device isn't "compatible"

No?  I really don't understand your logic here.  The clone worked on Linux, it was plugged into a windows system with the affected FTDI driver, it was then unplugged and plugged back into the Linux system.  At this point, the clone no longer works. YES!?  How can you dispute this?

Can you agree that any unpatched Linux system, especially embedded systems, will no longer function with a clone which has been exposed to the FTDI windows driver?  Yes, No?  Feel free to

Can you agree that for nearly a month (from the release date of FTDI driver until the release of the Linux patch) the clones were modified to the point where they would not work with Linux? Yes, No? Feel free to elaborate.elaborate.

No, changing the PID in linux does not require an updated driver

I'm really unsure which question you're replying NO to?  Are you are saying that the thousands of embedded devices out in the field (without network connection) will continue to work with a clone exposed to the FTDI Windows driver?

The updated driver just automatically supports fake FTDI chips that were revoked by FTDI. Its bad drm that is for sure but it isn't broken. Bypassing FTDI dumb DRM patch or not can be done with FTDIs own tools, they even have instructions for that as well.

Just use the FT_PROG tool and run,

sudo ./ft232r_prog --old-pid 0x0000 --new-pid 0x6001

I think you're assuming that because the modification (I will refrain from calling it damage) is reversible it has not been caused.

[(*steve*)]

Just a simple question if I might...

It appears to me that the original 2.12.00 FTDI driver will work the first time a clone is used, but not subsequently.  Is that true?  I've not been able to lay my hands on a clone device to test this myself.

[markb82]

Well there's what FTDI *should* have done, and then there is what they did.

So, that ship has sailed-- there is no going back for a "do over", and the PR damage is *done*.

What they *could* do, is offer a free program to fix any damaged hardware, and modify their driver so that it refuses to work with anything non-FTDI.  I don't think anyone would argue that their clone device *must* be supported by FTDI.

With the free program, we could at least fix the broken devices so that they would work with Linux again.  This may already be done on the Linux side, and as suggested, it might be possible to use FT_PROG to "fix" the broken hardware.  I was thinking of something more user-friendly or even transparent [it could be built into the new driver].

If FTDI refuses to do what's Right, we could also write an open-source Windows driver to replace the FTDI driver that does all of these things (and also works with real and cloned FTDI devices).

These things don't happen overnight.  Let's wait and see what FTDI's response is going to be.

For me, it's already *over*-- I will use SiLabs' CP2104 devices from now on...

Well said.  I'm a bit of an SiLabs fan-boy, they've always provided me with good support and samples.   And there is no reason to think they would pull something like FTDI just did, but I'd be just as quick to criticize them.  Companies need to protect their IP, but FTDI went just a step too far.  They should of stopped at preventing the clones from working with their driver, and if they were really nice they would show a popup message explaining that is what they have done, and instruct the end-user to request a full refund.

[a210210200]

Can you agree that changing the PID stopped the Linux driver from working until about 2 days ago when a patch was released to specifically address the issue caused by FTDI changing the PID?

No, users can still bypass it the device isn't "compatible"

No?  I really don't understand your logic here.  The clone worked on Linux, it was plugged into a windows system with the affected FTDI driver, it was then unplugged and plugged back into the Linux system.  At this point, the clone no longer works. YES!?  How can you dispute this?

Can you agree that any unpatched Linux system, especially embedded systems, will no longer function with a clone which has been exposed to the FTDI windows driver?  Yes, No?  Feel free to

Can you agree that for nearly a month (from the release date of FTDI driver until the release of the Linux patch) the clones were modified to the point where they would not work with Linux? Yes, No? Feel free to elaborate.elaborate.

No, changing the PID in linux does not require an updated driver

I'm really unsure which question you're replying NO to?  Are you are saying that the thousands of embedded devices out in the field (without network connection) will continue to work with a clone exposed to the FTDI Windows driver?

The updated driver just automatically supports fake FTDI chips that were revoked by FTDI. Its bad drm that is for sure but it isn't broken. Bypassing FTDI dumb DRM patch or not can be done with FTDIs own tools, they even have instructions for that as well.

Just use the FT_PROG tool and run,

sudo ./ft232r_prog --old-pid 0x0000 --new-pid 0x6001

I think you're assuming that because the modification (I will refrain from calling it damage) is reversible it has not been caused.

It does still work to stop working it would be impossible to talk to it or use it which if you can run the command at the bottom you certainly are using it. If FTDI blocks the use with the VCP part (retroactively) that is their bad choice to make. Their driver just revoked the part (PID) that lets that automatically happen. The device is still detected and enumerates and can be used with custom drivers, the config tool, ... (Its like WGA all over and I had a legit copy but Vista decided to go into lockdown until I called a Microsoft phone robot and had to go through hoops to fix) FTDI put it into "reduced functionality mode" as vista so named the DRM lockdown mode.

WGA is evil, Vista had the worst version of it but I don't think Microsoft got into any trouble for actually depriving users of access.

[markb82]

It does still work to stop working it would be impossible to talk to it or use it which if you can run the command at the bottom you certainly are using it. If FTDI blocks the use with the VCP part (retroactively) that is their bad choice to make. Their driver just revoked the part (PID) that lets that automatically happen. The device is still detected and enumerates and can be used with custom drivers, the config tool, ... (Its like WGA all over and I had a legit copy but Vista decided to go into lockdown until I called a Microsoft phone robot and had to go through hoops to fix) FTDI put it into "reduced functionality mode" as vista so named the DRM lockdown mode.

WGA is evil, Vista had the worst version of it but I don't think Microsoft got into any trouble for actually depriving users of access.

I really don't understand your logic, here is my hypothetical scenario:

0. I'm a poorly trained tech that is responsible for running periodic test routines on an accelerometer.
1. The accelerometer uses an FT232 chip, which happens to be a clone.
2. In normal operation it is connected to an embedded Linux platform which I am not allowed to modify.
3. To perform my periodic test routine, I unplug the accelerometer from the Linux host, and plug it into my Windows 7 PC.
4. My PC happens to have the affected driver from FTDI.
5. When I plug in the accelerometer, the FTDI driver changes its PID.
6. I then unplug the accelerometer and plug it into the Linux machine.

The question is:  Will the accelerometer still send data into the Linux machine?  Here is a hint, the drivers are old because this is an embedded system.  I also don't know that the PID has been changed, nor do I know how to fix it.

Can you honestly say that the accelerometer still works as intended and sends its data to the Linux system?  YES, NO?  Don't explain, I'm really starting to believe you're a troll.

I know it can be fixed.  I know the device isn't permanently damaged.  But in it's state, it does not work until the fixes are performed.

[pickle9000]

I've been bitten by this debacle even though I'm close to 100% confident there will be no FTDI fakes in my products.

We are about to release a new product (was supposed to be today) that contains a FT230X, and as part of my software install I include the installer for the FTDI driver. As a result, I would be responsible for putting this dangerous driver on other people's computers.  That is an unacceptable legal risk for my company.

We now have no choice but to hold off release until FTDI fixes this. And I also have to do all my installer testing again. This will cost my company at least half a day of my time, not to mention possible lost sales because of a late release.

I'm very disappointed and annoyed, and will be looking more closely at the FTDI alternatives in the future.

Unfortunately, our volume is so low that FTDI can safely ignore us.

So hassle factor, extra time, risk of losing customers. Not a small thing for a small company.

[a210210200]

It does still work to stop working it would be impossible to talk to it or use it which if you can run the command at the bottom you certainly are using it. If FTDI blocks the use with the VCP part (retroactively) that is their bad choice to make. Their driver just revoked the part (PID) that lets that automatically happen. The device is still detected and enumerates and can be used with custom drivers, the config tool, ... (Its like WGA all over and I had a legit copy but Vista decided to go into lockdown until I called a Microsoft phone robot and had to go through hoops to fix) FTDI put it into "reduced functionality mode" as vista so named the DRM lockdown mode.

WGA is evil, Vista had the worst version of it but I don't think Microsoft got into any trouble for actually depriving users of access.

I really don't understand your logic, here is my hypothetical scenario:

0. I'm a poorly trained tech that is responsible for running periodic test routines on an accelerometer.
1. The accelerometer uses an FT232 chip, which happens to be a clone.
2. In normal operation it is connected to an embedded Linux platform which I am not allowed to modify.
3. To perform my periodic test routine, I unplug the accelerometer from the Linux host, and plug it into my Windows 7 PC.
4. My PC happens to have the affected driver from FTDI.
5. When I plug in the accelerometer, the FTDI driver changes its PID.
6. I then unplug the accelerometer and plug it into the Linux machine.

The question is:  Will the accelerometer still send data into the Linux machine?  Here is a hint, the drivers are old because this is an embedded system.  I also don't know that the PID has been changed, nor do I know how to fix it.

Can you honestly say that the accelerometer still works as intended and sends its data to the Linux system?  YES, NO?  Don't explain, I'm really starting to believe you're a troll.

I know it can be fixed.  I know the device isn't permanently damaged.  But in it's state, it does not work until the fixes are performed.

Ah, we have just such a setup. Its a linear motor table meant to test active vibration dampening control uses much more advanced data capture than a simple RS-232 can handle but anyways. I have an even better case which is our student's dev boards that have an on board accelerometer piped through an FT232 chip.

So
-1. Students have in the past bricked FTDI chips and broken MSP430 micros by messing around with the config. So we have prepared for many odd situations. One of which includes an invalid VID/PID (assigned by FTDI, a student, their custom programs, ...) and how to fix it. (Overclocking an MSP430 (you must mess up the fail safe DCO config to do so) can be sometimes half resolved by doing a little reset glitch but in the end most of the time the damage is physical and the chip is basically dead)

0. None of our students are what you would call well trained
1. I guess a student could slap a clone chip on a board if they broke it and didn't want to pay the 200+$ fee for discouraging students from breaking/losing things.
2. We do have embedded linux workstations that run control loop simulations (they cannot be modified)
3. We do have mixed OS windows 7, linux, mac os (for flow simulations)
4. Concivably yes a station could update the driver
5. The FTDI driver could "reduce the functionality" of the clone by altering the PID
6. Plugging it into the linux will not work initially, yes but it doesnt stop there.
7. They remember the big bold it doesn't work do this document, and go oh maybe the ID is wrong as it says right there device not being recongized by the FTDI driver check the PID/VID combination. They hop over to a nearby window xp computers (the lab isn't networked as you said, it really isn't for the lab machines) and update the the invalid PID.
8. Plug back in and they go on their merry way.
9. A good student would tell me about it and if I did not already know about it then I would just say we have that covered.

Obviously FDTI's behavior is very similar to evil WGA, HDCP but that doesn't mean its illegal. And yes obviously the reduced functionality means it doesn't automatically work with VCP drivers.



 

[Rufus]

Which other company do you think they should have made the device claim to be manufactured by? Unlike the low life fake manufacturers they have some respect for the VIDs allocated or to be allocated to other companies.

Look no one is saying that FTDI doesn't have a right to protect their IP, and that they love to buy clones, and that clones are the best.  They're not.  FTDI has a right to protect their IP.  They could have done so by having the driver refuse to work with the clone, but not modifying the clone.

You asked why they didn't change the VID and I told you. I will tell you and everyone yet again that they don't want to simply have their driver refuse to work with these non-genuine chips because the faulty implementation of the clone they exploit involves writing to EEPROM and if they kept on doing this every time the device was plugged in or powered the EEPROM would wear out and the chip really would be damaged. The PID change means the device does not cause unlicensed drivers to be loaded in the future including unlicensed previous versions of the drivers which don't perform the check.

The driver performs exactly the same actions on all chips. It doesn't detect or treat differently non-genuine chips. The chip bricks itself because it doesn't accurately mimic a genuine chip. They may have deliberately chosen to let the chip brick itself because of legal implications or perhaps just because it was quick and easy.

[markb82]

You asked why they didn't change the VID and I told you. I will tell you and everyone yet again that they don't want to simply have their driver refuse to work with these non-genuine chips because the faulty implementation of the clone they exploit involves writing to EEPROM and if they kept on doing this every time the device was plugged in or powered the EEPROM would wear out and the chip really would be damaged. The PID change means the device does not cause unlicensed drivers to be loaded in the future including unlicensed previous versions of the drivers which don't perform the check.

The driver performs exactly the same actions on all chips. It doesn't detect or treat differently non-genuine chips. The chip bricks itself because it doesn't accurately mimic a genuine chip. They may have deliberately chosen to let the chip brick itself because of legal implications or perhaps just because it was quick and easy.

You're right you could wear out the EEPROM like you suggest, however there are ways to minimize the risk.

1.  Write once, check the value, restore the old value.  Note the serial number of the device, don't accept it in the future. (Prone to collision if a legitimate FT232 with the same number gets plugged into the same machine, but very unlikely).  So 2 EEPROM writes per Windows PC plugged into.

2.  Write a mark to EEPROM addresses 61 and 62, and check for the mark each time the driver loads. Marginally better, the EEPROM is still written, the PID isn't changed, but the driver refuses to work.

I'm sure someone with much better knowledge of the EEPROM layout could suggest other options.

[markb82]

5. The FTDI driver could "reduce the functionality" of the clone by altering the PID
6. Plugging it into the linux will not work initially, yes but it doesnt stop there.

So the FTDI driver has disabled the clone from working and you need to go through a set of steps (7-9) to fix this.  Thank you.  Thankfully you have an infrastructure in-place to deal with this specific error, many others do not.

7. They remember the big bold it doesn't work do this document, and go oh maybe the ID is wrong as it says right there device not being recongized by the FTDI driver check the PID/VID combination. They hop over to a nearby window xp computers (the lab isn't networked as you said, it really isn't for the lab machines) and update the the invalid PID.
8. Plug back in and they go on their merry way.
9. A good student would tell me about it and if I did not already know about it then I would just say we have that covered.

Obviously FDTI's behavior is very similar to evil WGA, HDCP but that doesn't mean its illegal. And yes obviously the reduced functionality means it doesn't automatically work with VCP drivers.

You may be okay that, as a direct result of FTDI's actions, you are having to troubleshoot and fix the problem, but many other are not.  How you respond to FTDI's actions is your choice, but your response, whether it be acceptance and fixing, or outrage does not make FTDI's actions legal or illegal.

It is my belief that FTDI made the device non-functional and that this could be considered a crime as you own it, and FTDI has no IP claims against a compatible re-implementation of their design.  Yes that sucks, but it is the boat FTDI is in.  Even if they did have a claim, they would need to go through the court system to get an injunction to allow them to do this.  Typically counterfeit goods are seized by the proper authorities (not the manufacturer, although often with their assistance) and destroyed.

FTDI can most certainly disable/prevent their driver from working with the clone, there-by achieving nearly the same effect.  There is the issue of the device still working with previous driver versions, however if FTDI was concerned about clones they very well could have designed security into their product from the very beginning, they did not.  It sucks and I sympathize with FTDI, god know I would hate having something I designed cloned, however I would have stayed within the legal means availiable to me.  FTDI is definately in the gray, since they will not admit this was done on purpose, and have deleted tweets which did (I need a reference for this).

[Mr.B]

I thought Dave mentioned in his video rant that he had captured copies of the tweets...?

I may be wrong.

[nctnico]

Again the device is in no way "destroyed" FTDI's drivers do not have to legally interoperable or even allow them to keep the same PID they report. Altering the PID is not a damaging action and only prevents it from working with FTDI's drivers, third party programs and tools can still use the chip normally.

I think you're a fairly reasonable person a210, but can you admit that this is not true?  The device is prevented from working with any old build of Linux, or BSD, which does not have a fix for the PID being cleared to 0000s.  There are many many embedded devices our there which use Linux, within which it is not simple to update the Linux build.

Exactly. I even have embedded firmware in the field which doesn't work with a bricked FT232 device and this firmware is not easy to update.

[a210210200]

5. The FTDI driver could "reduce the functionality" of the clone by altering the PID
6. Plugging it into the linux will not work initially, yes but it doesnt stop there.

So the FTDI driver has disabled the clone from working and you need to go through a set of steps (7-9) to fix this.  Thank you.  Thankfully you have an infrastructure in-place to deal with this specific error, many others do not.

7. They remember the big bold it doesn't work do this document, and go oh maybe the ID is wrong as it says right there device not being recongized by the FTDI driver check the PID/VID combination. They hop over to a nearby window xp computers (the lab isn't networked as you said, it really isn't for the lab machines) and update the the invalid PID.
8. Plug back in and they go on their merry way.
9. A good student would tell me about it and if I did not already know about it then I would just say we have that covered.

Obviously FDTI's behavior is very similar to evil WGA, HDCP but that doesn't mean its illegal. And yes obviously the reduced functionality means it doesn't automatically work with VCP drivers.

You may be okay that, as a direct result of FTDI's actions, you are having to troubleshoot and fix the problem, but many other are not.  How you respond to FTDI's actions is your choice, but your response, whether it be acceptance and fixing, or outrage does not make FTDI's actions legal or illegal.

It is my belief that FTDI made the device non-functional and that this could be considered a crime as you own it, and FTDI has no IP claims against a compatible re-implementation of their design.  Yes that sucks, but it is the boat FTDI is in.  Even if they did have a claim, they would need to go through the court system to get an injunction to allow them to do this.  Typically counterfeit goods are seized by the proper authorities (not the manufacturer, although often with their assistance) and destroyed.

FTDI can most certainly disable/prevent their driver from working with the clone, there-by achieving nearly the same effect.  There is the issue of the device still working with previous driver versions, however if FTDI was concerned about clones they very well could have designed security into their product from the very beginning, they did not.  It sucks and I sympathize with FTDI, god know I would hate having something I designed cloned, however I would have stayed within the legal means availiable to me.  FTDI is definately in the gray, since they will not admit this was done on purpose, and have deleted tweets which did (I need a reference for this).

We don't even get much money for that part of the course work and I took a few minutes of my time a few years ago to write a help its not working guide. Because its covered and is a joke to fix vs. how I "fixed" HDCP I don't see how they are any different. Both modify hardware and both reduce or add steps that causes issues for a user and I've spend hours troubleshooting various AV setups around work and at home that clearly are a related to HDCP not handshaking properly or not liking certain cheap devices in the device chain. (The moment you get a little more complicated than a standard setup and HDCP is a huge drain on time/resources/money its unpredictable even with professional equipment) To this day I don't have a simple guide on HDCP other than some rare devices really don't listen at all to HDCP and for now haven't been revoked but that can change pretty quickly.

The device certainly is put into a reduced functionality mode but it isn't (rendered non-functional) as it still functions and you can still use it if as you said you know what your doing. FTDI does have an IP claim to the driver and a non-official device talking to the driver might get asked to go jump in a lake and while it definitely is a form of DRM the real FTDI chips say nope not jumping in the lake while the other fake one does and since they were not really evil and didn't use the actually damaging config options you can still get the clone to buddy up with the FTDI driver by locking them in a room with no lake.

FTDI did prevent their drivers from working with it post and present. Just because security didn't exist before doesn't mean FTDI/HDCP can't block a device after the fact by revoking the numbers in hardware. Revocation lists are exactly for that (Every disc, device, ... has the latest version and they automatically update devices nearby even if that means the device should no longer advertise HDCP compliance). HDCP 2.2 is going to be even more "fun" I'm sure of that. (Given how every rev was compromised sometimes massively they are not going to play nice that is for sure)

[a210210200]

I thought Dave mentioned in his video rant that he had captured copies of the tweets...?

I may be wrong.

Aren't the captured screenshots in the rant video?

http://youtu.be/eU66as4Bbds?t=13m56s

[Mike Warren]

I wonder if FTDI have pulled the update. http://www.ftdichip.com/Drivers/CDM/CDM%20v2.12.00%20WHQL%20Certified.zip (the latest version on their site) redirects to the v2.10 download - not sure if it always has done this or not?

I downloaded the 2.12.00 driver a few days ago and got the 2.12.00, not the 2.10.00. This sounds like 2.10 is the latest driver that doesn't do the bricking. If I could just prove that we could go ahead with release only a day or 2 late.

I'll try emailing FTDI.

[markb82]

The device certainly is put into a reduced functionality mode but it isn't (rendered non-functional) as it still functions and you can still use it if as you said you know what your doing. FTDI does have an IP claim to the driver and a non-official device talking to the driver might get asked to go jump in a lake and while it definitely is a form of DRM the real FTDI chips say nope not jumping in the lake while the other fake one does and since they were not really evil and didn't use the actually damaging config options you can still get the clone to buddy up with the FTDI driver by locking them in a room with no lake.

If the device is put into this reduced functionality mode, and can't be used for its intended purpose until it is fixed, then it is non-functional. Period. It cannot function until fixed, hence non-functional.  Yes it can be repaired from this non-functional mode, and made to function again.  I'm even willing to say its not damaged, others would take the view that since its not easily fixed by the average user of the end product, then for all intent and purpose it is damaged or destroyed.  Yes you are very skilled and can fix or solve this problem in the blink of an eye, but that doesn't mean it didn't exist.  If I had to hire you to diagnose and fix this problem you would be looking to get paid right?

FTDI did prevent their drivers from working with it post and present. Just because security didn't exist before doesn't mean FTDI/HDCP can't block a device after the fact by revoking the numbers in hardware. Revocation lists are exactly for that (Every disc, device, ... has the latest version and they automatically update devices nearby even if that means the device should no longer advertise HDCP compliance). HDCP 2.2 is going to be even more "fun" I'm sure of that. (Given how every rev was compromised sometimes massively they are not going to play nice that is for sure)

FTDI could have prevented their drivers from working without changing the PID. It they wanted to have a revocation list, then FTDI's driver could detect a clone (restoring any EEPROM changes they made), and then store the clone's serial number and refuse to load the FTDI driver for it.  Something that I believe would be legal (some people may contest this point, I will not, I think its acceptable).

You either change the driver to not function with the clone, or you change the clone to not function with the driver.  I believe the former is likely legal, while the latter is likely not.

1. A change to the clone's PID for no other reason than to render clones in-operable (non-functional) for the time being or until they're fixed is likely to be illegal.  I think its a fallacy  to consider this a revocation, because you modified the clone in a way that in its current state it would not function with 3rd party drivers in other OS's, until either the device or the 3rd party driver is 'fixed'.

2. A change to FTDI's driver to prevent it from functioning with clones is likely legal.  Such as having the FTDI driver store the clone's serial number, and refuse to work with it in the future.  This would be acceptable in my mind, and I would consider this an implementation of a revocation list.

I don't think this argument is unreasonable, and I suspect many would agree.  I am sympathetic to FTDI's plight, and clones do need to combated, but this should be done in the supply chain, not by involving unsuspecting end users.  And at the very least, the fact that a clone was disabled (made non-functional) should be reported, not done silently.

[a210210200]

The device certainly is put into a reduced functionality mode but it isn't (rendered non-functional) as it still functions and you can still use it if as you said you know what your doing. FTDI does have an IP claim to the driver and a non-official device talking to the driver might get asked to go jump in a lake and while it definitely is a form of DRM the real FTDI chips say nope not jumping in the lake while the other fake one does and since they were not really evil and didn't use the actually damaging config options you can still get the clone to buddy up with the FTDI driver by locking them in a room with no lake.

If the device is put into this reduced functionality mode, and can't be used for its intended purpose until it is fixed, then it is non-functional. Period. It cannot function until fixed, hence non-functional.  Yes it can be repaired from this non-functional mode, and made to function again.  I'm even willing to say its not damaged, others would take the view that since its not easily fixed by the average user of the end product, then for all intent and purpose it is damaged or destroyed.  Yes you are very skilled and can fix or solve this problem in the blink of an eye, but that doesn't mean it didn't exist.  If I had to hire you to diagnose and fix this problem you would be looking to get paid right?

FTDI did prevent their drivers from working with it post and present. Just because security didn't exist before doesn't mean FTDI/HDCP can't block a device after the fact by revoking the numbers in hardware. Revocation lists are exactly for that (Every disc, device, ... has the latest version and they automatically update devices nearby even if that means the device should no longer advertise HDCP compliance). HDCP 2.2 is going to be even more "fun" I'm sure of that. (Given how every rev was compromised sometimes massively they are not going to play nice that is for sure)

FTDI could have prevented their drivers from working without changing the PID. It they wanted to have a revocation list, then FTDI's driver could detect a clone (restoring any EEPROM changes they made), and then store the clone's serial number and refuse to load the FTDI driver for it.  Something that I believe would be legal (some people may contest this point, I will not, I think its acceptable).

You either change the driver to not function with the clone, or you change the clone to not function with the driver.  I believe the former is likely legal, while the latter is likely not.

1. A change to the clone's PID for no other reason than to render clones in-operable (non-functional) for the time being or until they're fixed is likely to be illegal.  I think its a fallacy  to consider this a revocation, because you modified the clone in a way that in its current state it would not function with 3rd party drivers in other OS's, until either the device or the 3rd party driver is 'fixed'.

2. A change to FTDI's driver to prevent it from functioning with clones is likely legal.  Such as having the FTDI driver store the clone's serial number, and refuse to work with it in the future.  This would be acceptable in my mind, and I would consider this an implementation of a revocation list.

I don't think this argument is unreasonable, and I suspect many would agree.  I am sympathetic to FTDI's plight, and clones do need to combated, but this should be done in the supply chain, not by involving unsuspecting end users.  And at the very least, the fact that a clone was disabled (made non-functional) should be reported, not done silently.

The device is still functional and reduced functionality just means its not as easy to use, anyone can just force it to work with the driver as a workaround while they sort things out. I used the slmgr -rearm when windows activation went berserk one time on windows for no good reason and that isn't exactly command everyone knows about automatically. WGA false positives where harder to fix and wasted far more time. The FTDI driver issue is a joke to fix, their guides even tell you how to do it. Some uses don't even have the default PID/VID combination so they wouldn't even notice even if they have fake clone devices.

You wouldn't need to pay me those are so easy to fix and I always get emails from family asking for all manner of simple to fix computer problems. I charge money for support that requires me to visit onsite or write new code/... (Free level of support I provide for any previously paid work is also a given if someone uses my code I stand by it and even if an FTDI driver, windows problem, ethernet misconfiguration, and even a dumb user... affected it I can at least help point them in the right direction for free) I work on the principle that I will provide limited free support by email but if you want timely and defined support it costs money. (Any bugs that are clearly my fault I will also correct for free obviously) I don't exactly charge people after the answer is oh the cable was plugged into the wrong device or the dial was in the wrong position. The FTDI issue is remote desktop detectable/fixable so can easily be under my free support level of fixes. (So no I would not charge you as I would first ask to check remotely before spending money on a site visit which I would have to charge because it cost money to go somewhere and I can't tend to other tasks at the same time when I'm on site)

To me, obviously different than others for something to be "broken" or rendered non-functional it has to require physical repair. Software/driver issues are the norm for me and its just part of the day for me, bad drivers, mean companies, stupid users, ... (As long as I can do it remotely I don't really care). Plus I've seen CAD system say oh your license is in use by someone else I'm just going to crash now instead of letting you save your work say goodbye to those hours of work you just put in because you only have a handful of licenses on the network and for some reason I can't just tell the newest user that there is no free licenses. (The software also had no auto-recover/save feature, and after that I saved every half hour, saving too much can corrupt the file... also no undo, it was a wonderfully "fun" software to use, it was really old to be fair)

Just never let those Indian remote support "Microsoft Tech Support" people get to you. They call me every month or so and I lead them on for as long as they don't notice. I reported them a lot but there isn't much to be done short of setting up a honeypot system (which is in progress) to get more info to report to the legitimate software companies getting tarred by fake support tech call scams. (Remote desktop is powerful stuff)

1) Revocation is valid as it is a updated number that is written to flash memory. If HDCP decides a real legit device should no longer work with anything they have the ability and have in the past done so with no legal challenge. The literal system for HDCP updates is any new device or blu-ray disk has updated revoked device keys and any compliant device should commit them and enforce them even if that means the device itself should invalidate itself. (This as FTDI's driver is all automatic) The drivers do still work with non default VID/PID combinations and the fix is simple vs the very complex hoops to fix HDCP problems (Which includes replacing hardware).

2) FTDI's drivers do not work with clones (past/present) is probably what they intended (which is what the PID revoking did) but it would be far nicer to say please do not use old drivers and clones won't work anymore at all. (But allow people to use it unofficially and unsupported)

(FTDI doesn't control the serial number process for the clones how do they ensure that the clone won't cause a conflict with a real device that collides with the SN#)

FTDI also has no distribution method to ship a revoked device SN list with their drivers or update them automatically and that would just add bloat that legitimate users don't need and would be even more like HDCP. The PID change is revoking access without the need for complicated and very abuse prone revocation lists.

Illegal clones should be rooted out and in the end of all this they shouldn't exist.

I wholly agree that FTDI is very stupid for on how they handled this. And think the PID change is dumb/bad but not illegal because it works very similar to HDCPs systems where devices are subject to automatic updating, revocation, disablement.

I would have just given tools to let people check chips months ago, then inform users of their plans to counter use of clone chips with official drivers, and then provide detailed instructions on what is going to happen and what to do if your affected. Then after everyone is ready press go and everyone won't be surprised and they will know how it works, what it means, how to fix it.

[markb82]

I think we have differing opinions, I most definitely think that if it requires any repair, its broken, however quickly you may repair it whether it be by flipping bits or tightening bolts.  I very much doubt an average end user could perform the repair without contacting you, and since you've graciously said you're willing to help over e-mail, I'll leave it up to them to PM you.

So I'll leave this discussion, because I'm out of stamina, but before I do, I'll add a very practical way for FTDI to use a combined EEPROM check and a SN list to deny clones from loading the FTDI driver, while at the same time protecting the integrity of the clone's EEPROM.

Using a SN (serial number) to revoke clones is not that difficult at all, and requires no distribution of a revocation list.  The list is auto-generated by the driver, stored only on the PC on which the driver is installed, and not shared through any means.  Here is how I would write the code:

1. The driver installs for the first time with an empty SN revocation list.
2. A user plugs in an FT232 chip.
3. The serial number of the chip is checked against the revocation list.
4. If the SN in the list, the driver refuses to load, and it is done.
5. If the SN is not in the list.  Run the current test to see if you can modify the devices EEPROM (ie detect a clone) AND restore the EEPROM to its original form.
6. If you detected a clone, add it to the revocation list and refuse to load the driver.  Display error message.
7. It is not on the list, and it safely passed the clone check, you load the driver.

There are no issues with distributing a SN revocation list.  On any subsequent insertion, the clone would not have the EEPROM check ran, so the EEPROM wear level of the clone would be not be affected.  There is an extremely slight chance (depending on the entropy of FTDI's serial numbers) that a user will have both a clone and a real FTDI device with the same serial number.  Since the list is not shared, and is auto-generated, I feel that this would be an acceptable risk.  I'm sure someone could crunch numbers for different scenarios, but I'm confident that this collision would effect less than 1 in a million users.  The false positive would barely add to the overall failure rate of FTDI devices.

Edit:

You might not even call this a revocation list, but a local cache of devices you've already confirmed to be clones, which do not need to be checked.

[Rick Law]

In the end, in all likelihood, FTDI's product may fade into history, but the name FTDI will not.

All the technicalities and legalities are irrelevant.  Bottom line is did they make their product desirable for designers to incorporate it into their product.  The answer appears to be an emphatic no.

This move is probably going to be studied by business schools in the future years.  Not too many company failures can be attributed to a single act, but this driver release may be one of those few "single act that killed a company."

FTDI probably will succeed in eliminating the counterfeits and the compatibles and thus be the sole manufacturer of that chip.  They will maintain the price premium and perhaps even increase their price premium significantly - for the half dozen people left who continued to use them in their design.  Small runs are expensive and do command a huge premium.

The death spiral has begun.  RIP – FTDI...  You will be remembered at least in Business School case studies.

Rick

[a210210200]

I think we have differing opinions, I most definitely think that if it requires any repair, its broken, however quickly you may repair it whether it be by flipping bits or tightening bolts.  I very much doubt an average end user could perform the repair without contacting you, and since you've graciously said you're willing to help over e-mail, I'll leave it up to them to PM you.

So I'll leave this discussion, because I'm out of stamina, but before I do, I'll add a very practical way for FTDI to use a combined EEPROM check and a SN list to deny clones from loading the FTDI driver, while at the same time protecting the integrity of the clone's EEPROM.

Using a SN (serial number) to revoke clones is not that difficult at all, and requires no distribution of a revocation list.  The list is auto-generated by the driver, stored only on the PC on which the driver is installed, and not shared through any means.  Here is how I would write the code:

1. The driver installs for the first time with an empty SN revocation list.
2. A user plugs in an FT232 chip.
3. The serial number of the chip is checked against the revocation list.
4. If the SN in the list, the driver refuses to load, and it is done.
5. If the SN is not in the list.  Run the current test to see if you can modify the devices EEPROM (ie detect a clone) AND restore the EEPROM to its original form.
6. If you detected a clone, add it to the revocation list and refuse to load the driver.  Display error message.
7. It is not on the list, and it safely passed the clone check, you load the driver.

There are no issues with distributing a SN revocation list.  On any subsequent insertion, the clone would not have the EEPROM check ran, so the EEPROM wear level of the clone would be not be affected.  There is an extremely slight chance (depending on the entropy of FTDI's serial numbers) that a user will have both a clone and a real FTDI device with the same serial number.  Since the list is not shared, and is auto-generated, I feel that this would be an acceptable risk.  I'm sure someone could crunch numbers for different scenarios, but I'm confident that this collision would effect less than 1 in a million users.  The false positive would barely add to the overall failure rate of FTDI devices.

Edit:

You might not even call this a revocation list, but a local cache of devices you've already confirmed to be clones, which do not need to be checked.

A local cache isn't really going to do much good if they actually want them to not work with their software (old/new) as HDCP can do. There is no local cache in HDCP once the revocation is updated it sticks and removing it isn't possible (probably is). The PID change effectively does the same thing.

The nicer and cleaner thing to do would be to give a Microsoft driver error code which doesn't reset automatically and Microsoft would automatically handle the this as if the device doesn't work and keep it that way. If you plug a different chip it should get its own auto-driver install from what I've seen and if its real it can connect properly or not get another driver error. There is no need to store extra info or anything and it won't try to check again if the driver is in a failed state to windows even if the device same is connected again.

PID 0000 is a HDCP style (evil) thing to do. (Throwing a driver error is cleaner and has no bloat) Coupled with telling people well before the patch everyone will be prepared.

Something like Error 43, Windows has stopped this device because it has reported problems.
Or not sure if FTDI can call this error but Error 48, The software for this device has been blocked from starting because it is known to have problems with Windows. Contact the hardware vendor for a new driver. (That is probably an avenue to block older driver versions)



 

[a210210200]

In the end, in all likelihood, FTDI's product may fade into history, but the name FTDI will not.

All the technicalities and legalities are irrelevant.  Bottom line is did they make their product desirable for designers to incorporate it into their product.  The answer appears to be an emphatic no.

This move is probably going to be studied by business schools in the future years.  Not too many company failures can be attributed to a single act, but this driver release may be one of those few "single act that killed a company."

FTDI probably will succeed in eliminating the counterfeits and the compatibles and thus be the sole manufacturer of that chip.  They will maintain the price premium and perhaps even increase their price premium significantly - for the half dozen people left who continued to use them in their design.  Small runs are expensive and do command a huge premium.

The death spiral has begun.  RIP – FTDI...  You will be remembered at least in Business School case studies.

Rick

Goodwill and trust takes years to build up and one mistake to tear down in an instant.

But in any case I think higher levels of integration are more a threat to FTDI you can get micro's with built in USB support, Ethernet, RF, ... and the market moves fast and getting the entire thing on one SoC is quite appealing. I'm looking into getting our 1st year boards down to a single chip solution and I'm pretty sure if spent the time it would be easy to build what we need as most of our stuff is old designs passed down from years ago.

Bottom line is FTDI screwed up their response, started a massive burn goodwill bonfire, and I think is still stoking it. (Regardless of if they are allowed to do it or not) I think that is something that is very clear.

Seriously is probably going to be a good example of failed PR I should recommend it to APSC prof that does a course on that kind of stuff (Business case studies)