FTDI driver kills fake FTDI FT232??

[janoc]

That's not how HDCP works. All they can do is make new discs not work on players which they have revoked the keys for. Old discs are unaffected, as is the Bluray player itself. Nothing is bricked, it just wont work with new discs.

I have seen this article:
http://hackaday.com/2014/09/08/unbricking-a-bluray-drive/

Which seems to imply the contrary (disk can revoke the key of the player and the device stops working ...). However, why someone would design a player with the revocation list in a writeable flash is beyond me. Maybe the HDCP/Bluray spec/license requires it.

[geppa.dee]

I have seen this article:
http://hackaday.com/2014/09/08/unbricking-a-bluray-drive/

Which seems to imply the contrary (disk can revoke the key of the player and the device stops working ...). However, why someone would design a player with the revocation list in a writeable flash is beyond me. Maybe the HDCP/Bluray spec/license requires it.

In any case, it's not the disk that does the bricking. The disk only caries the list of revoked keys. The device itself, if it respects the "standard", reads the list, introspects and compares, then self performs the bricking if "necessary". Quite the difference from FTDI clones that are being directly.... molested.

[ziq8tsi]

I have seen this article:
http://hackaday.com/2014/09/08/unbricking-a-bluray-drive/

Which seems to imply the contrary (disk can revoke the key of the player and the device stops working ...).

That is AACS, where a disc does not want to reveal its keys to a player it does not trust.  a210210200 has been banging on about HDCP, where a player does not want to send restricted video to an untrusted display.

I think he must know his analogy is false.  The player just declines to interact with the "revoked" display, it does not brick its EDID to 0×0 pixels like FTDI would have.

Also, the fact that some technical means exists, and licensees have been forced to agree to it, does not mean it is lawful to use.  Expect the courts to become involved if the keys to a best-selling display are ever revoked while millions of units are still under warranty.

[janoc]

I have seen this article:
http://hackaday.com/2014/09/08/unbricking-a-bluray-drive/

Which seems to imply the contrary (disk can revoke the key of the player and the device stops working ...).

That is AACS, where a disc does not want to reveal its keys to a player it does not trust.  a210210200 has been banging on about HDCP, where a player does not want to send restricted video to an untrusted display.

I think he must know his analogy is false.  The player just declines to interact with the "revoked" display, it does not brick its EDID to 0×0 pixels like FTDI would have.

Ah, right, you are correct. I have mixed up the two. Then the analogy is even more BS ...

Also, the fact that some technical means exists, and licensees have been forced to agree to it, does not mean it is lawful to use.  Expect the courts to become involved if the keys to a best-selling display are ever revoked while millions of units are still under warranty.

Yup. The protection under the DMCA or the European directive is not a blank check to do whatever and whenever the right owners please. That's why this whole thing is just one big red herring.

[janoc]

In any case, it's not the disk that does the bricking. The disk only caries the list of revoked keys. The device itself, if it respects the "standard", reads the list, introspects and compares, then self performs the bricking if "necessary". Quite the difference from FTDI clones that are being directly.... molested.

Well, yeah, but that is a technicality that would most likely be completely irrelevant if someone sued over it. The end effect is very much the same for the owner of the device.

Anyhow, see my later post - I was actually talking about AACS and not HDCP, confusing the two. Thanks to ziq8tsi for the correction. HDCP analogy is even less relevant to this whole farce, as no "bricking" is involved - the devices merely refuse to work together.

[amyk]

Also anyone feel like writing an FTDI compatible implementation based on a microcontroller with USB?  Could be fun

Someone has already done it with a Microchip PIC, link is posted in this thread: https://www.eevblog.com/forum/reviews/alternatives-to-ftdi-usb-to-uart-converter/

[zapta]

At least not as weird as...

I hate people who post XKCD images with no link - often the rollover text is as important as the comic.

I hate people who post XKCD images.

[a210210200]

All that HDCP does is that Bluray discs can update a table of revoked keys and potentially "brick" unauthorized Bluray players. That is most likely illegal as well and the studios could get sued if someone got their player damaged like that.

That's not how HDCP works. All they can do is make new discs not work on players which they have revoked the keys for. Old discs are unaffected, as is the Bluray player itself. Nothing is bricked, it just wont work with new discs.

It's still evil of course, and they have used it in the past with software Bluray players which can be updated easily, but I don't know if they have ever used it with stand alone players or if a firmware update was possible. In any case, you can easily buy HDMI capture cards that let you rip protected content bit-perfect.

www.extron.com/download/files/whitepaper/hdcp_wp.pdf
"
HDCP devices are obligated to check for SRMs and to update their own internal memories as new revocation lists are distributed. The revocation list is used during HDCP authentication to check for blacklisted public keys.
"

It also isn't just blu-rays that can update the list, new devices carry them too, and they stick otherwise it would be easy to bypass.

Please google stuff if you never been personally affected by something.

[a210210200]

I have seen this article:
http://hackaday.com/2014/09/08/unbricking-a-bluray-drive/

Which seems to imply the contrary (disk can revoke the key of the player and the device stops working ...). However, why someone would design a player with the revocation list in a writeable flash is beyond me. Maybe the HDCP/Bluray spec/license requires it.

In any case, it's not the disk that does the bricking. The disk only caries the list of revoked keys. The device itself, if it respects the "standard", reads the list, introspects and compares, then self performs the bricking if "necessary". Quite the difference from FTDI clones that are being directly.... molested.

The revocation updates self propagates and compliant (PID updating, just more complex) devices will happily store the new list. (It can brick an entire system instead of one device) It doesn't even care if the devices are actually real or not. (The threshold for revocation is arbitrary and not anything a user can easily fix once it has been done)

It is also isn't just discs that can do that, updated firmware can also contain updated revocations (new detections just like FTDI's driver) and then the go breaking you other stuff just because they can. (All the equipment is not fake, clones, or anything, it just does it because it can) It is by far worse than what FTDI did with PID 0000 on one device. Even my GPU has key revocation lists that seem to be updated somehow. (probably the drivers...)

[eneuro]

Linux is perfectly fine with the tools as well, just use "sudo ./ft232r_prog –old-pid 0x000 –new-pid 0x6001" there is also a .py script to even do it automatically for you someone else made that I posted a while ago in what you call "spam". Or are those tools not working?

Those Linux tools are not available on FTDI official website.
They only provide 5 years old ftdi_sio.c drivers, which will not work with this fake FTDI PID for reasons I've shown above.
http://www.ftdichip.com/Drivers/VCP.htm

In comparision Silicon Laboratories CP210x USB to RS232 serial adaptor driver which I use as fake FTDIs replacement cp210x.c do not have all this mess with verifying vendor and product for >0 but as simply as it is in its cp210x_init:

Code: [Select]

static int __init cp210x_init(void)
793 {
794         int retval;
795
796         retval = usb_serial_register(&cp210x_device);
797         if (retval)
798                 return retval; /* Failed to register */
799
800         retval = usb_register(&cp210x_driver);
801         if (retval) {
802                 /* Failed to register */
803                 usb_serial_deregister(&cp210x_device);
804                 return retval;
805         }
806
807         /* Success */
808         printk(KERN_INFO KBUILD_MODNAME ": " DRIVER_VERSION ":"
809                DRIVER_DESC "\n");
810         return 0;
811 }
I've made this investigation only because of I was interested in why those chips faked by FTDI stopped working under Linux.

Prosecutors and lawyers also may want to know and have black&white without messing with Linux modules details how they [FTDI] made those faked devices useless  under Linux too by this stupid override of product ID (PID) in someones hardware attached to USB -PID needed to attach device to module by its aliased USB vid:pid  numbers 
.

[a210210200]

Arguably you could say HDCP isn't legal either since the master key is leaked and it is no longer an "effective technical measure" it isn't really as anyone can make new HDCP keys themselves. But HDCP still is allowed to disable user equipment and is not banned in the EU and I don't think is facing any current legal challenges. Also with HDCP 2.2 it is just going to get even "better...", now it will be not backwards compatible, have distance latency checks, and all sorts of fun stuff.

Could we put this HDCP red herring out to pasture, please?

All that HDCP does is that Bluray discs can update a table of revoked keys and potentially "brick" unauthorized Bluray players. That is most likely illegal as well and the studios could get sued if someone got their player damaged like that.

You seem to imply that because nobody got sued, it is somehow legal, thus what FTDI did is legal too. Nonsense - the big difference with HDCP is that in order to legally (because of patent licenses, not applicable in FTDI case) implement a Bluray player, you must license the HDCP and agree to implement this sort of "feature" (and get the player certified that it does!). The Bluray consortium is extremely vigilant in stopping the unauthorized players from hitting the markets - typically via customs (same method as Fluke used to stop Sparkfun meters, Apple stopping sales of Samsung phones over patents, etc.). That is what FTDI should have done instead.

It is thus extremely rare that someone gets bitten by the player key revocation, thus the likelyhood of a lawsuit is very low - basically only greymarket imports can get affected, where you know that you are buying a product not intended for your market and thus all bets are off, not something you buy at Amazon in good faith (like a generic serial to USB adaptor), for example.

It is a difference between designing-in a killswitch and actually using it. Doesn't make it any more legal to brick the players, but the chance of actually doing harm to legit users (and thus getting sued) is fairly low. Basically HDCP is only "legal" because nobody has bothered to sue over a bricked grey market $200 player yet, that's all. The directive/DMCA protections don't apply here at all - nobody is trying to circumvent the protection mechanism. Also you have ignored the part 48 about not interfering with the normal functioning of the device.

Also you rarely get a critical equipment depend on a Bluray player - unlike something like the FTDI USB bridges, which can be parts of complex machinery and where breakage costs millions in lost production, for ex. I can guarantee you that the lawyers would come out in force should that happen somewhere - it is not end-user's responsibility to verify that all chips in his machine are genuine.

I wonder what other BS analogy will you come up with. 

AV equipment costs a lot of money and some of my stuff is far more expensive than a serial cable USB adapter. At the university we have HDCP problems too with equipment an order of magnitude more expensive and complex. If a key gets revoked in some professional installation setup the damage can be extreme and it only takes one invalid key to break an entire device chain (Nice of them to not tell you anything other than the HDCP handshake failure behavior that I dread to see). Maybe you thought a splitter looked great for the application but it turns out that device works perfectly and is fully complaint but someone stole the key from the mfg and now your installation doesn't work at all. Say it was an information display system now its all blank. (My nvidia GPU in my desktop clearly doesn't like some switches I have and they probably have revoked keys)

It isn't just Blu-ray players that have key revocations. HDMI, Displayport, DVI, wireless links all have HDCP x.x support and important systems need displays and GPUs, switches, matrix switches, video processors, ... all are products that can be affected. Arguably complex systems are bound to have lots of displays (control rooms, media systems, info displays, ...) and if one day your AV setup dies because someone updated a firmware/driver and the blacklisted keys were updated it isn't going to be easy to fix especially with HDCP 2.2.

Now see were getting into the "harm" level just as you claim FTDI causes total destruction because your USB converter needs 1 minutes work to bypass a DRM. I raise that by the hours/days and hundreds to thousands of dollars spent fixing HDCP "compatibility" issues in various systems. Arguably HDCP is much more common than RS-232 and HDCP is a true pain to deal with if you actually have complex setups that are not just a bluray player to a TV (HDCP is very widely in use).

And then we are getting to the you must be using fakes or shady equipment which is very similar to FTDI just in HDCP it is worse because it doesn't care if you have real and professional sourced equipment. Again the comparison of HDCP to FTDI is apt and HDCP is far far worse.

Don't give me the BS thing when I've personally dealt with both situations (the FTDI PID 0000 case for me was caused by students having fun but that was a joke compared to HDCP doing "fun" things) And of course suing them is no chance situation like FTDI and with HDCP it is very hard to debug by design of course.

Again it isn't blurays that are the only things that contain revocation lists they are just the most common ones there are many other sources (TV's with audio return for example will count as an HDMI source in that mode and must by the standard push out revocation lists as well)(AV recievers, GPUs, ...)

So just like FTDI can disable a 5$ chip with a joke bypass, HDCP can literally brick 1000's of dollars worth of legit equipment and make entire systems break down without any messages, warnings, tools to help you find the offending component(s) while FTDI does the same to one chip and all it takes is pressing force driver install to bypass. Once an HDCP device stores its own blacklisted key it will not work with HDCP and removing the blacklist is not simple.

[miguelvp]

I wonder what the next thing will be:



Only half kidding, I think what they did is important but they aren't going to do it anymore.
People that need to run their clones on windows will find a suitable driver and everyone is happy again.

[a210210200]

Linux is perfectly fine with the tools as well, just use "sudo ./ft232r_prog –old-pid 0x000 –new-pid 0x6001" there is also a .py script to even do it automatically for you someone else made that I posted a while ago in what you call "spam". Or are those tools not working?

Those Linux tools are not available on FTDI official website.
They only provide 5 years old ftdi_sio.c drivers, which will not work with this fake FTDI PID for reasons I've shown above.
http://www.ftdichip.com/Drivers/VCP.htm

In comparision Silicon Laboratories CP210x USB to RS232 serial adaptor driver which I use as fake FTDIs replacement cp210x.c do not have all this mess with verifying vendor and product for >0 but as simply as it is in its cp210x_init:

Code: [Select]

static int __init cp210x_init(void)
793 {
794         int retval;
795
796         retval = usb_serial_register(&cp210x_device);
797         if (retval)
798                 return retval; /* Failed to register */
799
800         retval = usb_register(&cp210x_driver);
801         if (retval) {
802                 /* Failed to register */
803                 usb_serial_deregister(&cp210x_device);
804                 return retval;
805         }
806
807         /* Success */
808         printk(KERN_INFO KBUILD_MODNAME ": " DRIVER_VERSION ":"
809                DRIVER_DESC "\n");
810         return 0;
811 }
I've made this investigation only because of I was interested in why those chips faked by FTDI stopped working under Linux.

Prosecutors and lawyers also may want to know and have black&white without messing with Linux modules details how they [FTDI] made those faked devices useless  under Linux too by this stupid override of product ID (PID) in someones hardware attached to USB -PID needed to attach device to module by its aliased USB vid:pid  numbers 
.

Sorry forgot they are all third party FOSS tools that work with it regardless of the PID change and are not exactly new.

I believe I posted the link before but here it is again, http://www.minipwner.com/index.php/unbrickftdi000

Also I think the library it uses and obviously works is obtained by using, sudo apt-get install make gcc libftdi-dev

Its a joke to bypass FTDI's DRM, literal peanuts compared to dealing with real monsters of a DRM hardware system.

[a210210200]

I have seen this article:
http://hackaday.com/2014/09/08/unbricking-a-bluray-drive/

Which seems to imply the contrary (disk can revoke the key of the player and the device stops working ...).

That is AACS, where a disc does not want to reveal its keys to a player it does not trust.  a210210200 has been banging on about HDCP, where a player does not want to send restricted video to an untrusted display.

I think he must know his analogy is false.  The player just declines to interact with the "revoked" display, it does not brick its EDID to 0×0 pixels like FTDI would have.

Also, the fact that some technical means exists, and licensees have been forced to agree to it, does not mean it is lawful to use.  Expect the courts to become involved if the keys to a best-selling display are ever revoked while millions of units are still under warranty.

AACS and the bluray encryption is different than HDMI HDCP revocation and source path protection but are used in conjunction (layers of DRM yay!). The software (drivers) in the firmware do in fact carry the ability to brick other devices. A bluray, software update, new hardware can all contain updated revocation lists. As others have posted a device like the FTDI chip has the functionality to accept commands to brick itself or change its IDs. Once the update is applied a device can and by HDCP standards no longer work properly.

Lets put it this way your cable box can have certain channels with ICT like and more flags on them and I don't think that is a bluray disc going into the back of the cable box. Blurays also have software on them which is part of BD+ (Yay even more DRM) so it also is not just a static entity (The Disc runs special security software in an hardware provided isolated VM space that can do all manner of checks, updates, blacklists, detection steps, ...)

EDID is not modified but the HDCP data channel is. (And unlike the EDID channel you cannot override the HDCP one without breaking everything in terms of the encryption ready status, so you do get "reduced function mode") So I'm not sure how that is better that they are using an designed to be very hard to bypass HDCP data channel instead of a easy to modify data channel.

The player is just one of the ways HDCP can revoke device keys and AACS is another form of DRM and is more related to the disc/player itself. HDCP is the cable/hardware DRM which has functions very similar to FTDI's PID change with revocation and a degraded functionality state when it activates.

They could argue probably successfully that those evil displays could be used and modified by consumers to pirate content and then the courts would be yup ban away. (Plus how long is a best selling TV warranty?) Also that doesn't even matter even if you TV could accept content that will be HDCP 2.2 the older ones will not display it without downsampling and restricting quality to the (arbitrarily, for example have a 4K display without HDCP2.2 support then no 4K for you). HDCP 2.2 has provisions for the "broken" HDCP 1.x devices as in reduced functionality for everyone (YAY!) half bricking for everyone (Spent money on a display get the value of a cheap display because your DRM hardware isn't good enough). Not only did they just make the top selling TV less useful they made every HDMI 1.x device less useful and makes my life even harder because just one non-HDCP2.2 device will "contaminate" the device chain. Even computer monitors at the 4K resolution are probably going to require HDCP2.2 support as soon as the GPUs get HDCP2.2 support or at least if you want to display flagged content at native res it will. (Displayport 1.3 is also going to have HDCP2.2)

HDCP is like what FTDI did just everything is doing it and its a monster so large people have been lulled into not thinking about it anymore because its so horrible and simple setups are typically not affected.

[a210210200]

Again, all of this is irrelevant to the fact that FTDI may have committed a cyber-crime by making unauthorized changes to end-user's equipment.  It is also at least possible that there have been other [indirect] damages caused by their actions.  For example, if a control system in a plant suddenly stopped working because of the FTDI driver with trojan malware in it, and that plant malfunctioned and killed some people, well, if I were on the jury in that trial I think I would have to go with the plaintiff.  Same thing if there was a medical device that suddenly malfunctioned due to FTDI's driver with trojan malware in it-- and somebody died [or were seriously harmed] because of that.  It's too early right now to know if any of these things have happened [or may be in the process of happening].

We will have to wait and see how all of this unfolds, but one thing is very clear-- I can no longer design in FTDI chips into my products, because of all of the FUD [Fear, Uncertainty, and Doubt] surrounding these parts-- I don't want my clients, and customers of my client's products worrying over this issue.  So far the FTDI devices have worked well for me, and I really hate to change to another product that I have no experience with [the SiLabs CP2104], but unfortunately, FTDI actions on this matter have forced my hand-- I *must* change to a different part, and just make it work.  It's going to be interesting to watch all of this unfold over the next few years-- kind of like a slow motion train wreck...

I guess HDCP is a cyber-war crime against humanity because it can make unauthorized automatic changes to end-user equipment and has no appeals process to what is basically an arbitrary system of device blacklisting. FTDI's DRM is a bad thing but it is a joke to bypass vs HDCP (2.2 more so).

You know control systems, hospitals have displays right and I don't think it is easy to disable HDCP for Nvidia graphics cards at least and that combination which could easily happen (nvidia is pretty big GPU player and for multi-displays they have that too)(intel integrated GPU also has HDCP support) I think it would be far worse for the display system showing the FTDI connection failed to fail than the FTDI connection to fail because one is a joke to fix and the other requires techs to come in and look behind the wall, into the AV distribution system to trace down what is misbehaving or what is not allowed anymore.

No factory is going to use USB as its critical communication system. Nor would a good best practices factory have critical windows machines connected directly to windows update so that at 2AM the plant can explode when the computer restarts for updates. A proper windows setup is air-gapped and tightly controlled with software white-listing and behavioral monitoring which would stop even an attempt to update a driver or anything really.

Medical devices at best would use the USB connection for debugging, dev use only, and downloading all of which are non-critical activities and would not interfere with the operation of the device. Like seriously do you think an implantable defibrillator is going to kill the person because the FTDI chip on the external RF reader stopped working at the clinic. (No its not and any even slightly competent IT person would be able to fix it easily in minutes and everything keeps on going) Now in the HDCP case if a HDTV used in a surgery theater for a digital camera on the end of a minimally invasive probe stopped working because of magic HDCP problems then it could take hardware replacement and hours to debug and trace the problem down. (HDCP problems can even occur without revocation and are different than EDID problems which can occur) HDCP is worse but similar to FTDI and could actually cause problems. HDCP is also much harder to fix, debug, detect and can cause hardware replacements. (Unlike FTDI's 0000)

A factory would be highly negligent to use a windows machine in a small business type config for something that has life safety implications. Displays on the other hand could cause life safety issues and HDCP problems could cripple a critical display or even be giving the engineer problems at his workstation in the office at the wrong time just because he was trying to watch a movie on lunch break and the display+GPU got upset and he missed a warning popup saying the world in the factory is coming to an end all hell is breaking loose (while he fiddled with the cables and was looking for another splitter).

[marshallh]

Below is a post that I put up on the FTDI blog site, which is still waiting "moderation" [and I seriously doubt that they will let it post, so I am posting here]:

Probably the best summation of this whole thing, except for the prison bit. FTDI will not post this comment as they haven't approved any others though. Still a bit of unneeded hubris.

[a210210200]

Below is a post that I put up on the FTDI blog site, which is still waiting "moderation" [and I seriously doubt that they will let it post, so I am posting here]:

Probably the best summation of this whole thing, except for the prison bit. FTDI will not post this comment as they haven't approved any others though. Still a bit of unneeded hubris.

I don't get it why not just say its a bad, mean, evil thing to do instead of saying your all going to jail or your cyber-terrorists... (The probability someone at FTDI is going to accept that post is probably 0%)

[gman4925]

IMHO, What you *should* have done, is write your driver so that it refuses to “talk” to non-FTDI chips...

I think you should re-write your driver to just “not work” with non-FTDI devices...

Sometimes these cables are used for linking critical systems. I hope that your driver does not end up killing someone [medical device or plant operations, etc.-- which can be dangerous if they suddenly stop working].

How is the driver going to detect whether it is a critical system?

As far as I can tell you are arguing that the driver should stop working (by refusing to talk) and then you are arguing that it should not stop working (because it could be connected to a critical system).

If it detects a non-FTDI chip and refuses to talk won't that have the same effect to the critical system?

If the detection is to write the PID, then check it is 0000 and then rewrite it to what it was, is that not also unauthorized modification of a users product without permission, this time twice, or many more times each time it is plugged in?
Are you promoting them to modify something that is not theirs?

[Rufus]

Again, all of this is irrelevant to the fact that FTDI may have committed a cyber-crime by making unauthorized changes to end-user's equipment.

Or actually the end-user's equipment changed itself because it didn't correctly emulate the equipment it was claiming to be. So you may as well accuse the supplier of your faulty fakes/clones of cyber-crime which of course is a bit harder because you don't even know who they are.

[Fungus]

If the detection is to write the PID, then check it is 0000 and then rewrite it to what it was, is that not also unauthorized modification of a users product without permission, this time twice, or many more times each time it is plugged in?

Don't forget that EEPROM wears out...

[Richard Crowley]

If it detects a non-FTDI chip and refuses to talk won't that have the same effect to the critical system?

No. The reasons seem obvious. But there seem to be people here arguing just for the sake of arguing without considering the facts.
There also seem to be many people arguing about how simple it is to ensure genuine parts who have never dealt with the supply-chain, acquisition, or 3-rd party manufacturing, particularly from Asia.

The reason it is NOT the same is because the equipment has been CHANGED so that it no longer performs as designed.
So you can't simply connect the gadget to a different computer with the legacy driver and restore functionality.
You can't revert the driver back to the version that worked before.
You may not even be able to connect to a different OS because it doesn't work the same as before the sabotage.

It is hard to tell whether FTDI just didn't think through the results of this debacle, or whether they intended the results, or whether they just let it slip through.
Either way it makes FTDI look like a poor candidate for future designs after demonstrating either terrible corporate judgement or lousy engineering.
Especially when they could have chosen the high-road of customer education and assistance to do the right thing rather than bomb-throwing.

[markb82]

If the detection is to write the PID, then check it is 0000 and then rewrite it to what it was, is that not also unauthorized modification of a users product without permission, this time twice, or many more times each time it is plugged in?

Don't forget that EEPROM wears out...

You will exceed the insertion spec of your USB connector before you wear out the EEPROM (provided the clone uses a real eeprom, some have suggested it could be some sort of OTP ROM by looking at the die shots? I'm no expert)

Either way, to quote my solution from page 88 (that's only like 4 pages back):

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.

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.

Wearing out the EEPROM is a herring.

[a210210200]

If it detects a non-FTDI chip and refuses to talk won't that have the same effect to the critical system?

The reason it is NOT the same is because the equipment has been CHANGED so that it no longer performs as designed.
So you can't simply connect the gadget to a different computer with the legacy driver and restore functionality.
You can't revert the driver back to the version that worked before.
You may not even be able to connect to a different OS because it doesn't work the same as before the sabotage.

You can connect it to a different or the same computer with an legacy driver with PID 0000 instead of PID xxxx this I believe is proven to work. You can either edit the .inf file, or force the driver to install in device manager, or use a GUI tool to do it, or use regedit, or use CLI tools, or use a linux tool, or... (So many things still work notice that the list is a massive list of options you have all of which are in my opinion a joke, my printer doesn't automatically install drivers and I have to use the force driver method in normal install anyways)

You can roll back the driver, you can force it to work with it even if the IDs don't match. You can as shown before connected to a different os and use completely FOSS tools to not only correct but even prevent it from being modified again afterwards.

FTDI did a bad/mean/evil DRM ala HDCP style detection and modification but the workaround/bypass is a joke.

If you need help fixing this particular issue I can help for free via remote desktop. (After I finish some work stuff of course)

[Fungus]

Wearing out the EEPROM is a herring.

 

[markb82]

If the detection is to write the PID, then check it is 0000 and then rewrite it to what it was, is that not also unauthorized modification of a users product without permission, this time twice, or many more times each time it is plugged in?
Are you promoting them to modify something that is not theirs?

Actually they are already doing 2 writes, first to address 2 to change the PID, and a second to address 62 to make the checksum correct.

I would suggest doing a write to 62, check if it succeeded by reading it back, and then do a 2nd write to address 62 to restore the original value.  Hence two writes, and the EEPROM retains its original values.  Objections?