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.
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.
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"
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
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
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...
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 driverI'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.
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.
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.
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.
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.
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.
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).
I thought Dave mentioned in his video rant that he had captured copies of the tweets...?
I may be wrong.
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?
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)
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.
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.
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