FTDI driver kills fake FTDI FT232??

[MicroBoy]

oh I should mention that zip is just a re-signed windows7/8.0/8.1 driver that has PID 0000 in the inf file.  simple workaround.. bet FTDI didn't see that one coming.

I've done that a couple of weeks ago. I think it could be good to even change the driver version line with a bigger one in the .inf files. It may discourage OS to update with undesirable new versions

[uski]

oh I should mention that zip is just a re-signed windows7/8.0/8.1 driver that has PID 0000 in the inf file.  simple workaround.. bet FTDI didn't see that one coming.

I've done that a couple of weeks ago. I think it could be good to even change the driver version line with a bigger one in the .inf files. It may discourage OS to update with undesirable new versions

Unless I'm mistaken the problem with that approach is that the driver is going to rewrite the PID over and over again.
Depending of the quality of the EEPROM it may wear it out and break the EEPROM in the longterm.

[Someone]

Except in this case FTDI didn't irreversibly damage the problem devices. Its FTDI's software driver, if some other product decides it wants to use the driver without co-ordinating or licensing with FTDI then they have no control over what will happen to their device. FTDI didn't publish or offer their interface for free, there is no standard involved, they can do what they like when a device identifies to use their software.

A lot of people are using the "but it's FTDI's driver" argument. This is nonsense. Computer malware is the "the malware author's software" too, and sometimes even comes with an EULA that claims to allow them to do whatever they want. Doesn't mean it isn't malware and isn't illegal. FTDI are not responsible for the unintentional side-effects of their software on products that masquerade as their own, but the moment they explicitly target them with an intent to disable them, that defense flies out the window, both legally and morally. There is no legal and no moral right for FTDI to go vigilante on its users just because they own a counterfeit device (and that's assuming that all clones are counterfeits). Just because someone broke the law doesn't mean the law doesn't apply to you if you attack them. Just because someone did something immoral doesn't mean morality ceases to apply to your actions on them. If the world worked like this it and people/corporations were allowed to respond to evil with evil, it would be chaos.

The clone devices presented themselves with the PID/VID to use the driver, they didnt break the law by doing that alone. But they chose to connect to the FTDI driver on windows systems where they have no contract or law protecting them or ensuring any level of protection/service/support. Pushing the clone device off the PID/VID combination seems like a soft way to address the issue as it hasn't destroyed or damaged anything.

[Rufus]

Is it wrong for FTDI to intentionally break clones?  I'm not interested in legality, I'm interested in people's opinions on ethics.

Wrong question. The question should be is it wrong for FTDI to detect clones and prevent unlicensed use of their driver.

Under windows there are no other drivers so the only reason your clone ever worked was because you were illegally using FTDI drivers.

[Rufus]

So FTDI could just have used their knowledge to detect the counterfeit in their driver and restore it to the original counterfeit configuration right before disallowing the use of their drivers without giving feedback on why it wouldn't work.

Because it would wear out the clone EEPROM and really brick it eventually.

[MicroBoy]

oh I should mention that zip is just a re-signed windows7/8.0/8.1 driver that has PID 0000 in the inf file.  simple workaround.. bet FTDI didn't see that one coming.

I've done that a couple of weeks ago. I think it could be good to even change the driver version line with a bigger one in the .inf files. It may discourage OS to update with undesirable new versions

Unless I'm mistaken the problem with that approach is that the driver is going to rewrite the PID over and over again.
Depending of the quality of the EEPROM it may wear it out and break the EEPROM in the longterm.

It could even be worst. Counterfeiters may've used uC ROM Flash to emulate the original EEPROM and save some cents. That could turn down the number of writes to only ~1k. against ~1m-10m writes for an EEPROM.

This could be seen in the decapping images. If an EEPROM is present in the counterfeit chip or not.

[Someone]

Is it wrong for FTDI to intentionally break clones?  I'm not interested in legality, I'm interested in people's opinions on ethics.

Wrong question. The question should be is it wrong for FTDI to detect clones and prevent unlicensed use of their driver.

Under windows there are no other drivers so the only reason your clone ever worked was because you were illegally using FTDI drivers.

Yes, the only dodgy bit of all of this is the windows update system pushing out the driver without users having to see/read/agree to the licence.

[Rufus]

If you advertise your own Brand X product, and make it completely compatible with the FT232RL, nobody will have a problem with it. FTDI won't have a problem with it,

Yes they will because it will request FTDI drivers to be loaded and they belong to FTDI and are only licensed for use with genuine FTDI products

The test writes to EEPROM on non-genuine chips which would eventually wear them out and really brick them.

But surely you only have to run the test (testing an EEPROM write, the same way the FTDI driver code does it) once. You don't need to run it thousands and thousands of times and wear out the EEPROM.

The test would be done every time the driver loads, every device plug in and power up. How is FTDI (or anyone else for that matter) supposed to know the EEPROM endurance of an unknown clone chip from an unknown source?

[uski]

The test would be done every time the driver loads, every device plug in and power up. How is FTDI (or anyone else for that matter) supposed to know the EEPROM endurance of an unknown clone chip from an unknown source?

It would have been much cleaner to do that, including risking wearing the EEPROM out, AND showing a message informing the user of what is happening, rather than bricking the clone.

A message like this would be fine : "Warning : you are using a counterfeit chip not manufactured by FTDI with FTDI driver. The device will not start. Continuing using this peripheral with this driver might damage it.".

[MicroBoy]

Looking at http://zeptobars.ru/en/read/FTDI-FT232RL-real-vs-fake-supereal images, i'm not seeing any EEPROM at all in the counterfeit chip. This might mean that they're really using ROM to emulate the original EEPROM. That would surely cut down the number of times of writings before that zone of memory starts to fail.

[Rufus]

A message like this would be fine : "Warning : you are using a counterfeit chip not manufactured by FTDI with FTDI driver. The device will not start. Continuing using this peripheral with this driver might damage it.".

As I understand it there is no facility for drivers to show any kind of message under windows. An error code in the event logs and device manager is probably as much as they could do.

[MicroBoy]

A message like this would be fine : "Warning : you are using a counterfeit chip not manufactured by FTDI with FTDI driver. The device will not start. Continuing using this peripheral with this driver might damage it.".

As I understand it there is no facility for drivers to show any kind of message under windows. An error code in the event logs and device manager is probably as much as they could do.

?? FTDI relies on a DLL file for it's driver. They can surely show a popup or whatever they want. A .dll can execute any code it wants to. I'm not seeing any limitation there. I've showned popups in the past writing my own .dlls. without needing nothing more than a OS .dll function call.

[zapta]

Yes they will because it will request FTDI drivers to be loaded and they belong to FTDI and are only licensed for use with genuine FTDI products

Devices don't request anything, you are making things up. It's the OS (Microsoft) and the driver (FTDI) that decide what to do with a given device.

[(*steve*)]

the clone detector tool that I linked before relied on a patched libftdi (which I hacked up when this saga started and then forgot about...)

*THANKS*  I was sure I was doing something wrong.

Now to locate the devices I suspect of having FTDI chips in them...

[(*steve*)]

big lawyer buffett.

Interesting idea.  How do they taste?

Like week old briefs

[Rufus]

Yes they will because it will request FTDI drivers to be loaded and they belong to FTDI and are only licensed for use with genuine FTDI products

Devices don't request anything, you are making things up. It's the OS (Microsoft) and the driver (FTDI) that decide what to do with a given device.

FFS the device provides the VID and PID which tells the OS what drivers it needs.

[MicroBoy]

Yes they will because it will request FTDI drivers to be loaded and they belong to FTDI and are only licensed for use with genuine FTDI products

Devices don't request anything, you are making things up. It's the OS (Microsoft) and the driver (FTDI) that decide what to do with a given device.

FFS the device provides the VID and PID which tells the OS what drivers it needs.

But isn't the provide verb just in the opossite side of the request verb in terms of client-server communications?

The main difference is that, really, the device isn't in position of ask (request) for nothing. The Host (PC in this case) is the one deciding the whole thing. Even if the device provides a specific VID/PID, the Host can simply deny loading the driver, load an alternative one or open a new instance of Paint app.

First rule of USB communications: ALL REQUESTS ARE INITIATED BY THE HOST. Once you deeply understand the true meaning of that law, you may start programming USB related stuff.

[MicroBoy]

And as i said a couple of posts before, english isn't my native tongue, so my words may sound harder than what i really meant to. So, excuse me, please, about not always beeing able to choose the best words for what i want to say...

[zapta]

FFS the device provides the VID and PID which tells the OS what drivers it needs.

Well, if the FTDI's driver falsely represents to the OS that it can handle that devices but in reality it is not licensed to do so it's FTDI fault. The device is passive, it does not perform driver selection.

[zapta]

The test would be done every time the driver loads, every device plug in and power up. How is FTDI (or anyone else for that matter) supposed to know the EEPROM endurance of an unknown clone chip from an unknown source?

It's not our job to solve FTDI chip authentication issues.  It's up to them to do it in a non destructive way or not do it at all.

[nitro2k01]

But isn't the provide verb just in the opossite side of the request verb in terms of client-server communications?

The main difference is that, really, the device isn't in position of ask (request) for nothing. The Host (PC in this case) is the one deciding the whole thing. Even if the device provides a specific VID/PID, the Host can simply deny loading the driver, load an alternative one or open a new instance of Paint app.

First rule of USB communications: ALL REQUESTS ARE INITIATED BY THE HOST. Once you deeply understand the true meaning of that law, you may start programming USB related stuff.

I don't see the "deeper philosophical relevance" of what you're saying. It is true that in the lower layers of communication, the host always initiates contact, but this is really no different than an SPI master vs an SPI slave. All this means is that the USB device can't modify system memory on the host. (Firewire, I'm looking in your direction.) However, there's still a norm for what the OS should do when it finds a device with a certain VID and PID, and it's usually not launching MS Paint. You could also likewise say that the host isn't in a position to request anything from the device. The device may choose to randomize its VID/PID on each startup, ignore any USB commands, and disconnect, erase its memories, blink a LED or catch fire.

[nitro2k01]

FFS the device provides the VID and PID which tells the OS what drivers it needs.

Well, if the FTDI's driver falsely represents to the OS that it can handle that devices but in reality it is not licensed to do so it's FTDI fault. The device is passive, it does not perform driver selection.

The FTDI driver reports through its INF file which devices it supports based on the PID/VID combination. If the device falsely represents a VID, it has broken its part of the contract and is not a USB device but an almost-sorta-kinda-USB device, and it's up to the host what it wants to do on its side.

[zapta]

The FTDI driver reports through its INF file which devices it supports based on the PID/VID combination. If the device falsely represents a VID, it has broken its part of the contract and is not a USB device but an almost-sorta-kinda-USB device, and it's up to the host what it wants to do on its side.

That's correct, the host can decide what to do on its side, e.g. ignoring the device, but in the FTDI case it does it on the device's side, intentionally modifying it so other drivers and OS's will not recognize it.  No surprise Microsoft slapped them. Any serious OS vendor would do the same.

[Simon]

Documents telling the origin can be forged BTW. So even in an ISO9001 supply chain you never can be 100% sure. In the heavily controlled food industry they manage to mix in cheap horse meat with beef which ends up at Ikea. And trust me: ISO9001 is a complete joke compared to the quality control systems they have to use in the food industry.

Could not have put it better myself - working for an ISO9001 company, the base guidelines are actually not much, your local grocery store could declare themselves ISO9001 without having to change anything in how they work, just write down how they do stuff in a "quality manual". And yes forgery is rife, I came across a company in my time in quality that had an ISO9001 certificate that lasts 10 years, errrrrr, you have to be checked and re-certified every 3 years at most, that's the ISO9001 rule! We just have the audit every year but I think every 3 it's a bit bigger.

Our system is actually over ISO9001 but not good enough to be TS2

[nitro2k01]

The FTDI driver reports through its INF file which devices it supports based on the PID/VID combination. If the device falsely represents a VID, it has broken its part of the contract and is not a USB device but an almost-sorta-kinda-USB device, and it's up to the host what it wants to do on its side.

That's correct, the host can decide what to do on its side, e.g. ignoring the device, but in the FTDI case it does it on the device's side, intentionally modifying it so other drivers and OS's will not recognize it. 

Yes, but the question here was about driver selection based on what the device and your point about "[whether] it can handle that devices but in reality it is not licensed to" and so on. Yes, from a moral point of view, it's evil, but from a strict USB protocol point of view, nothing wrong was done by the driver. It attaches to a device that has given its permission to do so, and then it edits EEPROM values. A genuine FTDI chip could also be bricked in a similar way (manually by the user) by setting the VID/PID to anything that doesn't load the driver.

No surprise Microsoft slapped them. Any serious OS vendor would do the same.

Did they? As far as I gathered, FTDI backed down voluntarily due to concerns from their customers. Is there any evidence Microsoft had any part in their decision?