FTDI driver kills fake FTDI FT232??

[free_electron]

maybe then the question should be ....why can they make a better cheaper product in 3 months what it took you  guys 3 years to develop???

because a western world has enough money to put 5 engineers on it and it then takes for 3 years.  they cant put more on because they can't employ more ( costs too much )

the chinese just open 5 containers of students in government sponsored universities, they slap on some ip they 'found' on the internet and shove it out the door.

So yeah, they can do it dirt cheap. old joke about the chinese : how do you solve the pollution in large cities ? simply send in 1 billion people , give the command : everybody breathe in deeply. all the bad air is gone and the vacuum replaced by an inrush of clean air.

[1xrtt]

So, it seems that FTDI tried to push this new driver into Linux as well, but it got rebuffed:
https://lkml.org/lkml/2014/10/23/151
The original post, with the diff for the patch:
https://lkml.org/lkml/2014/10/23/129
You can see where they are trying to change the vendor ID...

[Chasm]

No, the Linux patch was an attempt to troll Linus Torvalds into a rant.

Did not work out as intended. =) Instead a different patch got accepted, it also treats FTDI devices with PID 0 as FT232. "Because the windows driver bricked them."

[nitro2k01]

Is there any inherent reason why a USB to serial chip needs to have firmware that can be modified via USB connection?

It's not a firmware, it's simply configuration bits. Those are used, as mentioned, to be able to change the VID and PID to a custom value, as well as change various options. You can make it output an auxiliary clock, invert any of the RS232 signals, and output control signals for driving an activity status LED. All in all useful options.

As for the clone chips, they are using a mask ROM for the firmware (which is an actual firmware in that case) so that could not be updated.

[CRCasey]

Here is what I am wondering...

In the EULA that FTDI bundled with this Microsoft approved silent update is the following language:

1.5 The Software will not function properly on or with a component that is not a Genuine FTDI Component. Use of the Software as a driver for, or installation of the Software onto, a component that is not a Genuine FTDI Component, including without limitation counterfeit components, MAY IRRETRIEVABLY DAMAGE THAT COMPONENT.

So Microsoft knowingly released this update after having read that EULA.

How does MS get out of the liability for all the customer's devices that have been destroyed?

Do they play the 'Oh, no one ever reads those things anyway.  And we didn't read it before we approved it.' card?  I seem to remember them being a big advocate of the Shrink Wrap EULA crowd.

Or is their credibility so screwed up over this that they finally have to admit that EULA's have no legal standing?


Anyway how does MS get out of sharing the blame (and the financial damages) for all the hardware that has been damaged?

-------

Cecil

[Mr.B]

@CRCasey
I agree, MS must stand up and face the music as well.

[alex.forencich]

@CRCasey
I agree, MS must stand up and face the music as well.

Well, I don't know about this one.  I think there is a good chance that they are very pissed off with FTDI for using their update distribution infrastructure as a weapon against the cloned chips.  It's quite likely they either pulled the drivers themselves or gave FTDI an ultimatum (we will give you x amount of time to pull the drivers yourselves and save face, otherwise we pull them for you).  The issue of whether they are responsible or not is a completely different issue.  I think they do some testing internally, but they can't verify every single line of code.  And the issue of driver sourcing is another issue - how do you ensure the driver you're using came from a reputable source and is not malicious?  Microsoft's update infrastructure should help with ensuring the driver is signed and from a reputable source, but it's not clear how much testing they do on the functionality of the driver itself. 

[Fungus]

Is there a nice easy way for me to find out if my USB to Serial adapters are "fake" or not?

(You know, the sort of tools FTDI should be providing people with instead of just bricking everything in sight...)

[Rufus]

1.5 The Software will not function properly on or with a component that is not a Genuine FTDI Component. Use of the Software as a driver for, or installation of the Software onto, a component that is not a Genuine FTDI Component, including without limitation counterfeit components, MAY IRRETRIEVABLY DAMAGE THAT COMPONENT.

So Microsoft knowingly released this update after having read that EULA.

How does MS get out of the liability for all the customer's devices that have been destroyed?

What liability? How can anyone guarantee that a driver sending commands to an unknown USB device over which they have no control will not damage that device?

I could manufacture a USB device which looks enough like an FTDI part to get FTDI drivers to load but physically explodes when you set the baud rate. How could FTDI be held liable for that explosion because they wrote the drivers or MS because they distributed them?

See what www.MSandFTDIbrickedthepieceofshitIboughtfromebaylawyers4u.com have to say.


Moving on it looks like flaky fakes have been causing problems with FTDI drivers long before they tried to detect them.

http://www.adafruit.com/blog/2014/02/18/ftdi-ft232rl-real-vs-fake/

http://www.gearhead-efi.com/Fuel-Injection/showthread.php?2150-New-cable-no-workie&p=26855&viewfull=1#post26855

Olimex seem to have been caught out without actually admitting they shipped fake parts.

https://www.olimex.com/forum/index.php?topic=2031.0

All chips with the same 1213-C date code - not that it means much stamped on a fake. Who is to say a batch of this year's fakes won't be as bad or that fake Silicon image or Prolific parts will be any safer?

Well, I don't know about this one.  I think there is a good chance that they are very pissed off with FTDI for using their update distribution infrastructure as a weapon against the cloned chips.

They had no problem using it to distribute critical updates as a weapon against Windows activation hacks and cracks to 'brick' counterfeit copies of Windows.

Microsoft's update infrastructure should help with ensuring the driver is signed and from a reputable source, but it's not clear how much testing they do on the functionality of the driver itself.

I think WHQL driver certification is very clear about how much testing is done. It won't include the client having to submit and pay for an unknown number of different fake and clone hardware devices to be tested with their drivers.

[Fungus]

How can anyone guarantee that a driver sending commands to an unknown USB device over which they have no control will not damage that device?

You can't...

...but we have their source code and tweets saying they did it deliberately.

The liability is in their intent. They knowingly hacked/damaged people's computers.

[Lightages]

Rufus:

I sincerely admire your stamina in defending your viewpoint. It is commendable. I also think it is pointless. If I were to agree with you 100%, and if I conceded that FTDI was doing the right thing and the only thing they could do, it still is a stupid move.

We, the members of this forum, are the "one percenters", or even less. What I mean is that we are the educated, well versed, and experienced few. The rest of the world, the uneducated and inexperienced, will just view this as FTDI broke their gadget. That is all they will know, care to know, and want to know. These "unwashed masses" are the main money flow for FTDI.

Instead of showing the world how bad FTDI has it with counterfeiters, all they have managed to do is piss off their biggest customer base who basically didn't even know that FTDI existed. Well they do now! And how do they know FTDI? They know them as the ones who broke their gadgets. This is what would not call a great PR success.

So the moral high ground goes to FTDI as they sink to the bottom of the ocean. They made themselves famous by breaking things that people own. The sheeple will give not one flying fuck what a company is facing when that company broke their gadget. That is all they know. FTDI loses because they didn't play the social game correctly, morally and legally right or not.

I empathize with anyone fighting against IP and copyright thieves. I am a multimedia producer myself. But as a person dealing with PR and making people feel all warm and fuzzy I can tell that this move was the equivalent of stomping a dog (possibly rabid) to death in a theater whilst wearing my company logo. It was a stupid move, right or wrong.

[marcan]

How does MS get out of the liability for all the customer's devices that have been destroyed?

We don't really know how the relationship between MS and driver vendors works. Their contract might specify that all liability is borne by the driver writer, or something along those lines. MS obviously isn't disassembling drivers that are sent in for certification to look for malicious code, so they can point the finger at FTDI if someone asks them why the auto update broke things. At this point, it becomes something for corporate lawyers to figure out. As a user, you can probably sue MS for this, but they might have arrangements in place such that FTDI ends up with all the financial liability either way. MS certainly didn't have any knowledge of this or malicious intent, which is a very important point in civil law.

[Richard Crowley]

Perhaps we are seeing the pre-trial testing of the expert witness's arguments in support of the Defendant.

[Rufus]

I sincerely admire your stamina in defending your viewpoint. It is commendable. I also think it is pointless. If I were to agree with you 100%, and if I conceded that FTDI was doing the right thing and the only thing they could do, it still is a stupid move.

I don't that much care if it hurts or helps FTDI. It is the half assed backwards logic, false sense of entitlement and mis-direction of blame in this thread that has annoyed me especially when there are real scum of the earth bad guys in this story. They get no blame at all because no one knows who they are and people whine that they are difficult to find and would rather pretend they don't exist and the fakes they churn out are real.

What FTDI have done has raised awareness of fakes and has caused people to look more closely at their supply chains which in my book is a good thing. If FTDI end up taking one for the team over it then so be it. I thank them anyway.

[TheRevva]

Sooooooooo...
It's glaringly apparent that you can 'reprogram' the PID of a FTDI chip.
It's equally apparent (from the datasheets) that you can also reprogram the VID too.

Perhaps it's time to start writing a 'custom' driver that will 'brick' any device that has a GENUINE FTDI chip in it.  (And along the way will also 'unbrick' any device with a fake chip just to be nice)
The only remaining question...  Should the 'new' device with the 'GENUINE' FTDI chip be switched to a VID / PID of 0000:0000, or should it be morphed into thinking that it's suddenly become some other, totally unrelated device?
If it's to be the latter, then it would logically have to be morphed into a VID of 0x045E since we already EXPECT any such devices to be 'faulty by design'.

[Bud]

What FTDI have done has raised awareness of fakes

What the heck you are talking about? What awareness? They acted silently, didn't they. If there is awareness now it is a  byproduct of public outrage after FTDI was caught with their pants down.

[Fungus]

How does MS get out of the liability for all the customer's devices that have been destroyed?

We don't really know how the relationship between MS and driver vendors works.

I could be wrong (it's happened before) but I thought part of the WHQL process was that your drivers have to undergo a code review at Microsoft. That's why WHQL certification costs so much money.

So either:
a) FTDI hid this new feature from Microsoft
or
b) Microsoft approved of it.

[Fungus]

Moving on it looks like flaky fakes have been causing problems with FTDI drivers long before they tried to detect them.

http://www.adafruit.com/blog/2014/02/18/ftdi-ft232rl-real-vs-fake/

You got that ass-backward.

According to your linked article FTDI drivers have deliberately been causing problems for users before when they detected fake chips.

Their drivers corrupted the data being transmitted so it looked like the chips weren't working properly. The chips were working fine, it was the driver deliberately altering the data so it looked like they weren't. I wonder how much money and debugging headaches that little trick cost the world?

Why the sneakiness? Why can't their drivers just come out and say "Your chip is fake!"...?

[orin]

How does MS get out of the liability for all the customer's devices that have been destroyed?

We don't really know how the relationship between MS and driver vendors works.

I could be wrong (it's happened before) but I thought part of the WHQL process was that your drivers have to undergo a code review at Microsoft. That's why WHQL certification costs so much money.

So either:
a) FTDI hid this new feature from Microsoft
or
b) Microsoft approved of it.

For the USB drivers I've had WHQL certified, you create the driver, sign it with your own certificate and run the WHQL test suite on it on your own computers.  The results get wrapped up along with the signed driver and sent to Microsoft.  Assuming the driver passed the test suite, your driver then gets signed by Microsoft with the WHQL certificate and you download it.  That's it.

The WHQL test suite makes sure that your driver installs and uninstalls without causing a BSOD.  It also makes sure you don't leave anything behind on uninstall.  It tests that your driver responds correctly to certain USB standard requests (power management, device arrival, removal etc.).  Depending on the class of the device, there may be other tests.

What the WHQL test suite did not and cannot do is test the effect of vendor control transfers.  The whole point of the vendor specified control transfers is that the vendor specifies what they do, not the USB standards.  The vendor is responsible for testing that they work correctly.

So, if a vendor makes vendor transfers that 'brick' a device, it is entirely the vendor's responsibility, whether it was done deliberately or not.

I am no fan of Microsoft and the next time I have to do a WHQL test will be too soon, but I really don't see Microsoft being at fault here.

[Fungus]

I could be wrong (it's happened before) but I thought part of the WHQL process was that your drivers have to undergo a code review at Microsoft. That's why WHQL certification costs so much money.

For the USB drivers I've had WHQL certified, you create the driver, sign it with your own certificate and run the WHQL test suite on it on your own computers.  The results get wrapped up along with the signed driver and sent to Microsoft.  Assuming the driver passed the test suite, your driver then gets signed by Microsoft with the WHQL certificate and you download it.  That's it.

OK ... maybe USB is different because it can't really destabilize Windows (it's just a data transfer device).

[joshhunsaker]

One thing people need to remember about shrink-wrap/click-wrap EULA's is that they are often written by totally overjealous marketing and business executives who feel an overwhelming need to include language that doesn't stand a chance in hell of being legally binding.  A lot of contractual writing includes phrasing which sounds official enough to feel like "law" but all too often just amounts to an incredible amount of bullshit meant to scare someone from taking action or recourse.  Patent claims are often similarly ridiculous on this level.

The person who wrote half of that probably understands less about the law of the jurisdictions where it has a chance of coming under the microscope than the arbitrary next person down the chain the software is handed to.  Attorneys typically only audit those documents (often loosely); profit motivation and CYA is what pens them.

http://www.regent.edu/acad/schlaw/student_life/studentorgs/lawreview/docs/issues/v16n2/Vol.%2016,%20No.%202,%207%20Condon.pdf
https://digital.law.washington.edu/dspace-law/bitstream/handle/1773.1/395/vol3_no3_art11.pdf?sequence=1

[a210210200]

I don't understand what the fuss about this is other than their obviously poor/abysmal PR spin control.

Simple facts are that from now on its technically not very legal to use counterfeit chips with FTDI drivers (even old drivers). So any counterfeit product that relies on FTDI's default driver is doing so illegally and if using a modern driver will always not work. So end result they are all bricks, Linux/Windows/Mac's driver repositories would either not include the driver at all or would be crossing some legal lines by keeping the older driver around.

Plenty of drivers, software, printers, photocopiers, have literal anti-counterfeiting traps built in (Its all in the EULA thing), even windows has it now as well, intel too, and so on. Attempting to photocopy monetary instruments (a form of counterfeiting which we can all say is very illegal) can and will cause certain photocopiers to brick themselves and lock in a special (call the FBI code) which will probably land someone in jail if they don't realize what the error means (The photocopier will also mangle the output physically and digitally and leave a lot of trace). (Conceivably networked/fax connected ones will literally call the cops) At least FTDI is nice enough not to abuse the driver to rootkit your computer and call the cops if you connect more than x number of fake FTDI chips. (Photoshop also has detections for many types of money as well I think, I believe there is even a standard for currency so devs can design the software to easily detect counterfeiting attempts)


Changing the PID to the "get your own driver" value of 0 is not destructive, changing the clock config and committing that to NV would be very destructive in many cases and would physically/electrically brick the chip/product in a very non-reversible manner. (Just look at the manual there are ways to reprogram the PID even after you mess up but there are far more dire warnings about setting things like external clock enable when you don't have an external clock as fixing this would require physical re-work/modification which for a BGA type one would be basically impossible if the pins are not broken out)


The proper way to phrase their new approach is that FTDI drivers assign unknown chips with an default unknown PID to allow a person to set their own driver up on a different ID. And add on the use of older drivers to circumvent this is a breach of terms. In any case a counterfeit chip even in a 99.9% genuine product is still trash/rework needed.

Write your own driver basically if your going to counterfeit (for the mfg), as the product still works electrically it is just that FTDI is not going to let you use their driver to make it work plug-in play with a signed FTDI driver.  (If they are too lazy then the user is going to have a brick.)

[joshhunsaker]

Plenty of drivers, software, printers, photocopiers, have literal anti-counterfeiting traps built in (Its all in the EULA thing), even windows has it now as well, intel too, and so on.

Again, anyone can write an arbitrary one-sided agreement with whatever amount of utter nonsense penned in there they would like.

Contract validity is altogether something different.  Don't assume one simply equates to the other.

As an example... I signed a non-compete with the company I work for when I returned back on with them a few years ago.  Except funny how in Oregon it's completely unenforceable because I don't make $69k a year (the median income for a 4-person family).  Simple as that, the entire non-compete (with any other clauses they rolled into that specific agreement) nullified.  I was kind enough to let them know so they didn't have to hand out any more useless forms to non-execs... 

[a210210200]

Plenty of drivers, software, printers, photocopiers, have literal anti-counterfeiting traps built in (Its all in the EULA thing), even windows has it now as well, intel too, and so on.

Again, anyone can write an arbitrary one-sided agreement with whatever amount of utter nonsense penned in there they would like.

Contract validity is altogether something different.  Don't assume one simply equates to the other.

As an example... I signed a non-compete with the company I work for when I returned back on with them a few years ago.  Except funny how in Oregon it's completely unenforceable because I don't make $69k a year (the median income for a 4-person family).  Simple as that, the entire non-compete (with any other clauses they rolled into that specific agreement) nullified.

No you don't understand photocopiers will literally brick themselves (only certain models that are a "threat") and if any official tech ever sees the error code (the machine locks out as well and requires service to be unlocked) the legal hammer would come shortly. (Counterfeiting is illegal, no contract is required)

FTDI would be classified as "bricking" the counterfeit chips if they went and messed around with the clock configs to either overclock/source a non-existent clock or just corrupt the entire NV memory. Changing the PID to 0 is not damaging anything. The device won't ever work with the stock FTDI drivers and requires a 3rd party driver to work.

A breaking a non-compete isn't criminal nor uniform, counterfeiting of physical goods is typically very illegal in most of the world.

[a210210200]

Moving on it looks like flaky fakes have been causing problems with FTDI drivers long before they tried to detect them.

http://www.adafruit.com/blog/2014/02/18/ftdi-ft232rl-real-vs-fake/

You got that ass-backward.

According to your linked article FTDI drivers have deliberately been causing problems for users before when they detected fake chips.

Their drivers corrupted the data being transmitted so it looked like the chips weren't working properly. The chips were working fine, it was the driver deliberately altering the data so it looked like they weren't. I wonder how much money and debugging headaches that little trick cost the world?

Why the sneakiness? Why can't their drivers just come out and say "Your chip is fake!"...?

Making debugging tricking is actually part of the cat/mouse game. Making your special fake chip detection result in a constant stream of "Your chip is fake!" will literally make finding the code that does the detection trivial in reverse engineering the driver binaries as simple as looking for a constant of that very string.

But if the driver sticks in random bad data for detecting a fake chip and uses clever obfuscation techniques it can require extensive reverse engineering to find it if ever. (This along with any in text stream isn't very nice and is potentially dangerous)

The best option in my opinion (for safety/detection) would probably to just immediately BSOD the machine on enumeration (plugging it in) and give a cryptic error code with debug data so that if someone reports it in they can figure out what types of fakes are out there. Having the driver bring up a msgbox would be an even more dead giveaway for the critical code as it wouldn't really blend in with the background. (I've seen tons of USB devices BSOD my computer or even stall the boot process so most people wouldn't suspect a thing, other than thinking its broken/incompatible)

In the end I think the enterprising counterfeiters will figure out how they are detecting the fakes and you should eventually be able to buy cheap/fake FTDI chips that work with the current driver soon in all likelihood. They already gave away the code by doing something simple like setting the PID to 0 so that too isn't very good implementation on FTDIs part. (Changing the user facing behavior is just going to make it even easier to find)