FTDI driver kills fake FTDI FT232??

[Someone]

We can and do because we use franchised distributors, source all components ourselves and outsource build-only to a trusted, reliable assembler. Every manufacturer could do the same (or in-house build) but if you want to save cost by outsourcing to China, then yes, forget it. It is cost saving and profit greed that allows counterfeiting.

In your naive world there would be no counterfeit money either  There is money to be made so somehow somewhere there is always someone who manages to slip in counterfeit items and make a profit.

Can we stop the fake money analogy?

Ok how about the bus lane analogy.

Bus company builds bus lanes and busses to run on them.
The bus lanes were being used by lots of other vehicles.
Bus company installs (without telling anyone) control devices: http://en.wikipedia.org/wiki/Sump_buster
Hilarity ensues as they didn't provide enough warning signs.

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.

[nctnico]

We can and do because we use franchised distributors, source all components ourselves and outsource build-only to a trusted, reliable assembler. Every manufacturer could do the same (or in-house build) but if you want to save cost by outsourcing to China, then yes, forget it. It is cost saving and profit greed that allows counterfeiting.

In your naive world there would be no counterfeit money either  There is money to be made so somehow somewhere there is always someone who manages to slip in counterfeit items and make a profit.

Can we stop the fake money analogy? Handing over money in the form of notes and coins in a shop carries with it no provenance; you have not thought your analogy through. Once in circulation no records are kept of its movement and there is no traceability as no provenance is expected. A respectable manufacturer does not source components from the back of a van or on ebay.

Until parts become unavailable due to shortage and management tells procurement to get the chips from any source they can. 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.

[Rufus]

It is obvious that there was intent to trash fake chips - the code can serve no other purpose. There is no reason for it to be there on genuine chips.

It is there to test for non-genuine chips. The test writes to EEPROM on non-genuine chips which would eventually wear them out and really brick them. Changing the PID so FTDI drivers are not loaded in the future is a good idea.

I expect if they do change the current drivers they will graciously reserve one of their PIDs for known fake parts and write that to it instead so windows will at least detect them and try to find drivers.

[Kjelt]

I can't believe it! I have what it seems to be an original FT245RL! It passes the FTDI new driver attack.

AFAIK the attack only affects the FT232RL. You still know nothing. 

[MicroBoy]

I can't believe it! I have what it seems to be an original FT245RL! It passes the FTDI new driver attack.

AFAIK the attack only affects the FT232RL. You still know nothing. 

Hmm.. Let me check that for you...

[Kjelt]

It is there to test for non-genuine chips. The test writes to EEPROM on non-genuine chips which would eventually wear them out and really brick them. Changing the PID so FTDI drivers are not loaded in the future is a good idea.

Sure till HungLo Enterprises creates a driver for their chip that looks if there is a HungLo chip attached, if not and it is any other chip such as a FTDI then just set the PID to 0 so the HungLo drivers are not loaded in the future.    You are thinking from a single manufacturer with a single chip. This is an open protocol, any chip from any manufacturer could be there and it should not interfere.
As said many times before in this topic, the only right way to do this is that the driver should do a handshake with the chip to determine for sure if it is a correct chip and it should do this in a non destructive way. For my part are they checking online with the manufacturer a unique Identifier pair or whatever, so the forged chips are identified but no way are you changing data on a chip that is not your creation in the beginning.

[zapta]

It's not coded like "oh we found a counterfeit device, go and let's brick it".
No, its much more clever: They write to the EEPROM in a way that is ignored by the original but that makes a fake one unusable.
So they would get away with a lawsuit. It's can't be proved that they deliberately sabotaged "compatible" devices.
The same code is executed for a genuine and a counterfeit device. It "just" happens that a counterfeit dies from it.
Sure we all know that this was the purpose. But that no lawsuit proof evidence.

The legal system is not that stupid. Employees will be deposed under oath and will have to explain what is behind that code, what were the internal discussion at that time, emails will be subpoenaed and nobody will want to go to jail for the company.

Looking how obvious the code is, I doubt the depth of the legal counseling they got, if at all.

[MicroBoy]

I can't believe it! I have what it seems to be an original FT245RL! It passes the FTDI new driver attack.

AFAIK the attack only affects the FT232RL. You still know nothing. 

Hmm.. Let me check that for you...

Confirmed. FT245RL (USB to Parallel Port) is attacked by the new driver too. You can now add FT245 to the Topic title. I'm attaching the USB transactions and the part were it's trying to do exactly the same as with the FT232RL. No surprise for me, beeing that FTDI used exactly the same die for the FT232RL and their behaviour is 99% similar. Just a couple of things more here and less there in the firmware, and a FT232RL can be easily converted to a FT245RL and viceversa (that was the same thing the counterfeiters must thought too).

I'm attaching an image of the attack in one of my FT245RL (this ones seems to be authentics) (in this request, it's asking to write 0x0000 @ EEPROM address 0x0002 (PID value).
Update: Attached the other part of the attack ( attempt to write 0x1600 @ EEPROM address 0x003E (CHEKCSUM)).

[alex.forencich]

For my part are they checking online with the manufacturer a unique Identifier pair or whatever, so the forged chips are identified but no way are you changing data on a chip that is not your creation in the beginning.

So it's impossible to use your device without an internet connection simply due to the verification process?

Reading out any sort of constant identifier is as trivial to fake as the VID/PID.  And adding any sort of cryptographic verification would likely require a very significant area overhead. 

[Kjelt]

Confirmed. FT245RL is attacked by the new driver too.

Thanks, good to know.

So it's impossible to use your device without an internet connection simply due to the verification process?

Yeah I know not preferred but still better than messing up another manufacturers device.

Reading out any sort of constant identifier is as trivial to fake as the VID/PID.

Not necessarily. A first thought and suggestion could be to have a (rather large) formatted identifier concatenated with a serial number and with a cryptographic hash (aka Message Authentication Code or short MAC) over this total string attached.
The manufacturer can check online the identifier with the MAC and keep a blacklist of copied identifiers.
So yeah the cloners could clone some devices but they would be fast detected (lot of hits in short period of time) and blacklisted. The cloners would not be able to generate their own serialnumbers and MAC unless they have used a weak cipher or too short key to generate the MAC.

And adding any sort of cryptographic verification would likely require a very significant area overhead. 

see above the chip just stores the identifier and MAC and does not have to do anything it self.
The easiest hack would be to attack the driver but there is where MS steps in with its updating service and if the cloners are able to hack a driver why would they not hack the current driver to work with their devices and that problem would also be solved.
In any case the biggest problem for FTDI is that they have done nothing to prevent cloning of their devices and now they are pulling bad tricks out of their hats to try to do something. But these things have to be thought of from the start of the design of the device and not afterwards.

[alex.forencich]

So it's impossible to use your device without an internet connection simply due to the verification process?

Yeah I know not preferred but still better than messing up another manufacturers device.

That's basically an instant deal-breaker for me if it requires internet-based authentication inside the driver every time the device is connected.  It's right up there next to Adobe Creative Cloud (did you hear about their activation servers going down, preventing whole companies from getting work done with no recourse and no compensation for the downtime?).  It makes it impossible to use the device without a reliable internet connection.  It's a huge reliability issue because now it requires your authentication severs to be accessible.  What if the server goes down or you go out of business in so many years and shut the sever down?  It also allows the equivalent of remote bricking.  What if something gets stuck in a reboot loop or a flakey cable causes a large number of requests, triggering a false positive in your system and denies an authentication?  What if the intent is to use the device inside a non-internet connected (e.g. airgapped) network?  Far too much risk for me, personally. 

Are you not familiar with what happened with the latest Sim City game?  It's basically a single-player game, but the software is written in such a way that you must be continuously connected to a server (a la a massively multiplayer game) otherwise it doesn't work.  The intent was to prevent piracy, but it was not long at all before people figured out how to patch the game so that it could run without contacting the sever.  And it ended up doing little to prevent piracy while also generating a lot of bad press and driving away a large number of users. 

[nitro2k01]

There exists an open source implementation for FTDI devices using libusb. You could theoretically adapt this driver quite easily to run on Windows. With a little financial help, you could even have this driver signed. This altogether could leave you with a generally useful open source driver that will not brick or block any compatible devices, and will work as a drop-in replacement. That is pretty much within arm's reach.

[sebmadgwick]

Ok how about the bus lane analogy.

Bus company builds bus lanes and busses to run on them.
The bus lanes were being used by lots of other vehicles.
Bus company installs (without telling anyone) control devices: http://en.wikipedia.org/wiki/Sump_buster
Hilarity ensues as they didn't provide enough warning signs.

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.

I'm struggling to see if there is a consensus of option.  Is it wrong for FTDI to intentionally break clones?  I'm not interested in legality, I'm interested in people's opinions on ethics.

This bus lane analogy suggests that FTDI should be able to intentionally break clones provided that they let people know that this is what they are doing.  Is that fair enough?

I like analogies, so here's my contribution:
I once went to a wrist watch shop to have a counterfeit watch repaired.  Upon inspecting the watch, the shop keeper declared that "normally" he would have to cease and destroy such a counterfeit product, but that he would let me off this time.  I didn't say anything at the time but I was certain he was wrong.  No individual or company should have the right to destroy other people's possessions simply because the possession imitates something else.  Only the legal authorities should be able to do this and only when the possession is intended for criminal activity;  I only had one counterfeit watch, I had no intention of selling it, and so no one should be able to take it away from me.

[marcan]

Confirmed. FT245RL (USB to Parallel Port) is attacked by the new driver too. You can now add FT245 to the Topic title. I'm attaching the USB transactions and the part were it's trying to do exactly the same as with the FT232RL. No surprise for me, beeing that FTDI used exactly the same die for the FT232RL and their behaviour is 99% similar. Just a couple of things more here and less there in the firmware, and a FT232RL can be easily converted to a FT245RL and viceversa (that was the same thing the counterfeiters must thought too).

The FT245RL also has bcdDevice = 0x600, so this is no surprise. The driver attacks all devices with bcdDevice == 0x6xx that have a valid EEPROM checksum. In fact, I don't even think you can tell those two chips apart - at least the Linux driver considers them the same.

[alex.forencich]

Ok how about the bus lane analogy.

Bus company builds bus lanes and busses to run on them.
The bus lanes were being used by lots of other vehicles.
Bus company installs (without telling anyone) control devices: http://en.wikipedia.org/wiki/Sump_buster
Hilarity ensues as they didn't provide enough warning signs.

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.

I'm struggling to see if there is a consensus of option.  Is it wrong for FTDI to intentionally break clones?  I'm not interested in legality, I'm interested in people's opinions on ethics.

This bus lane analogy suggests that FTDI should be able to intentionally break clones provided that they let people know that this is what they are doing.  Is that fair enough?

I like analogies, so here's my contribution:
I once went to a wrist watch shop to have a counterfeit watch repaired.  Upon inspecting the watch, the shop keeper declared that "normally" he would have to cease and destroy such a counterfeit product, but that he would let me off this time.  I didn't say anything at the time but I was certain he was wrong.  No individual or company should have the right to destroy other people's possessions simply because the possession imitates something else.  Only the legal authorities should be able to do this and only when the possession is intended for criminal activity;  I only had one counterfeit watch, I had no intention of selling it, and so no one should be able to take it away from me.

Well, there is a difference between a clone and a counterfeit.  A clone is not advertised as being an FTDI chip, only FTDI compatible.  It speaks the same protocol and necessarily has the same VID and PID (they are an aspect of the protocol) but it is not physically marked as an FTDI chip.  A counterfeit is a clone that has been re-marked as an FTDI chip.  It is not legal for them to intentionally brick clones.  It is also likely not legal for them to brick counterfeits.  And since it is not possible for the software to make a determination between clone and counterfeit because it cannot read the package marking. 

As for wrong, yes, I personally think it is wrong.  It also makes their software less reliable because it is possible that it will kill a legitimate chip.  The commands the driver send the chip serve no purpose other than to try to brick it if it is a cloned chip.  However, they can also brick legitimate FTDI chips (non-FT232RL).  So if a real FTDI chip is misidentified for some reason (e.g. interference changes the chip ID as read by the driver), it is possible that the driver will disable it by mistake.  It only has to happen once to cause a major problem since the change is written to nonvolatile memory. 

[miguelvp]

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.

That would have trumped the clones and wouldn't have attracted as much attention to them as the path they decided to follow. Right/Wrong, my gut feeling is they are in the right to prevent other manufacturers to cash in, into their efforts by allowing their software to work with competing products. Bricking those devices, well that's unfortunate.

I remember software for the original IBM PC that will only run on original IBM BIOS and this was in the 80s. It was Paint I think. People will purchase the software just to discover that it wouldn't run on their clones. I know this because someone that I knew bought that piece of software and I went with the DOS debug to see what it was going on and changed the fail assembler instruction to do the opposite compare so that he could use the program and it would only run on clones
 

[marcan]

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.

[MicroBoy]

Confirmed. FT245RL (USB to Parallel Port) is attacked by the new driver too. You can now add FT245 to the Topic title. I'm attaching the USB transactions and the part were it's trying to do exactly the same as with the FT232RL. No surprise for me, beeing that FTDI used exactly the same die for the FT232RL and their behaviour is 99% similar. Just a couple of things more here and less there in the firmware, and a FT232RL can be easily converted to a FT245RL and viceversa (that was the same thing the counterfeiters must thought too).

The FT245RL also has bcdDevice = 0x600, so this is no surprise. The driver attacks all devices with bcdDevice == 0x6xx that have a valid EEPROM checksum. In fact, I don't even think you can tell those two chips apart - at least the Linux driver considers them the same.

I think you meant 0x6001 and 0x600x. Sorry. I didn't read that you talked about bcdDevice, not PID. Yes. 6.00 (0x600) is the revision of this version. Still:

You can differentiate them by reading a couple of EEPROM bytes. That's how FTProg does it. I know this chips upside down.
 

[LukeW]

I'm not saying that what FTDI did was completely right... but there would have been absolutely no problem for anybody if the "fake" chip designer had simply advertised and sold their own WunHungLo USB-UART Bridge which is completely compatible with the FT232RL, labelled and sold under their own brand.

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, and if you offer the same functionality at a cheaper price I'm sure lots of customers will buy it.

It's the same as the "fake" Arduino boards, to name another common example of a Chinese cottage industry. If you say we are Brand X, we're selling Brand X AVR dev boards, completely Arduino Uno compatible, but ours are half the price, then lots of people will still happily buy them. They're not "fake" or "counterfeit", the product is still exactly the same product at the same price, without the controversy.

But they don't do that - they have to be dishonest about it, and label/market the chip as being an actual FTDI FT232RL, or whatever, and that's where people understandably start getting annoyed.

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.

[all_repair]

The ethical part is clear if you push the FTDI logic to the extreme.  If someone robbed  FTDI at gun point and in the open day light of their real chips, and resold these chips.  If FTDI later found a way to identify these chips, there are a lot of correct ways to identify the someone who did the damage.  NO, FTDI went after the END USERS.  "FTDI supporters" follow-on logic on pushing the blame and the responsibilities to the end users is even worse, and pain childish.

Cloning is legal and ethical in a free exonomy.  They can break their driver to stop working with clone.  But they cannot break the clone to stop working with their driver.

They were not going after counterfriets, they went after the clones, and broke them intentionally.  REAL people here must know the difference between "Read" and "Write". 

[Someone]

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.

Thats almost what they did, in so far as they only changed a small part of the clone devices configuration and didnt blank the whole thing (which would have been evil).

There is an interesting difference between the open source linux drivers where no one cares who supplied/manufacturers/programs the device, and the windows driver which is the effort and property of FTDI where they do care if other products are using their work. Just because there is an open source implementation of a driver doesn't mean FTDI have to let anyone use theirs. If a user complains that they can use a clone device fine on linux but it is attacked by a windows driver, then use your choice and don't use the windows driver which is incompatible with your device.

[MicroBoy]

Confirmed. FT245RL (USB to Parallel Port) is attacked by the new driver too. You can now add FT245 to the Topic title. I'm attaching the USB transactions and the part were it's trying to do exactly the same as with the FT232RL. No surprise for me, beeing that FTDI used exactly the same die for the FT232RL and their behaviour is 99% similar. Just a couple of things more here and less there in the firmware, and a FT232RL can be easily converted to a FT245RL and viceversa (that was the same thing the counterfeiters must thought too).

The FT245RL also has bcdDevice = 0x600, so this is no surprise. The driver attacks all devices with bcdDevice == 0x6xx that have a valid EEPROM checksum. In fact, I don't even think you can tell those two chips apart - at least the Linux driver considers them the same.

I think you meant 0x6001 and 0x600x. Sorry. I didn't read that you talked about bcdDevice, not PID. Yes. 6.00 (0x600) is the revision of this version. Still:

You can differentiate them by reading a couple of EEPROM bytes. That's how FTProg does it. I know this chips upside down.

For FT232RL, first two bytes of EEPROM are: 0x03, 0x04
For FT245RL, first two bytes of EEPROM are: 0x01, 0x40

I wonder if, for example, modifying a little your .py code, what would happen if you rewrite a FT232 with the ID word of a FT245 and viceversa. FTProg doesn't allow to write that addresses, of course. But what if FTDI only use one program to rule them both and that EEPROM word decide it all? Could we expect the device to change behaviours? Who knows...

[dev1010]

yep it worked for me. simple. *thumbsup* 
5 seconds and my cable was back up and running again.

go to device manager click update driver and browse to the files in your zip, do the same for the virtual comport driver.

https://onedrive.live.com/redir?resid=86EF72597602DD78!271164&authkey=!AIWwL-755E4FbwU&ithint=file%2czip

[dev1010]

yep it worked for me. simple. *thumbsup* 
5 seconds and my cable was back up and running again.

go to device manager click update driver and browse to the files in your zip, do the same for the virtual comport driver.

https://onedrive.live.com/redir?resid=86EF72597602DD78!271164&authkey=!AIWwL-755E4FbwU&ithint=file%2czip

[dev1010]

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.