FTDI driver kills fake FTDI FT232??

[all_repair]

......
All the FTDI chips we purchased the past year (around 17K units in total) went through their official sales network,
so the risk is almost 0. Phew...
I am still not happy.... but....whatever

Your chance is not 0, it is as good as FTDI can detect and can control.  I knew of a case that was done by an official sale channel part seller (not FTDI chip), he would replace a certain percantage with his own-printed part.  As years go by, the percentage increases.  I could not remember how was it finally detected, either the sale figure became too low, or through part failure analysis that exposed him.  He was finally removed, but the whole thing was kept secret from the public.

[MicroBoy]

As a bit of an oddity, I'll ask the folks here for a similar thing I asked of FTDI support:

Can someone create a tool to reproduce the "kill" operation of the 2.12 driver? If this is a "thing" that can happen, I'd prefer to add a few seconds of production test time to screen parts that might cause the end-user grief down the road. This is, in essence, a vulnerability without a clear way to patch it - so the easiest route I can do is attempt to brick any devices that might get a non genuine part in the lot. (I buy all my parts from Mouser and Digikey, but they're not omnipotent or flawless).

you can build such tool yourself using this joke linux patch - its replicating what the windows driver did
https://lkml.org/lkml/2014/10/23/129

I think you need far less than that. You can easily send the EEPROM writing requests using the FTDI D2XX .NET library for example. Writing a couple of lines in C#  can replicate the attack that is beeing used by FTDI.

[all_repair]

The simplest solution would be to have the driver pop up a message that says :
" This device attempted to load the wrong driver. Please contact the device manufacturer to get an updated driver."

And that's it. Then someone who has bought something with the fake part can go bombard the seller with requests for the right driver , or ask for his money back.

Why fight with the commodity chip makers? With such a brand and a large user base for their driver, they can capitalize it.  Sell some advertisement? Or sell unlock code to stop the advert?

[MicroBoy]

And why not writing an Open Source library 100% compatible for a uC? Would it be legal? Who wants some?

[alex.forencich]

And why not writing an Open Source library 100% compatible for a uC? Would it be legal? Who wants some?

I would say that it's perfectly legal for interoperability.  As long as nothing about the protocol is patented by FTDI, anyway. 

[Someone]

I think the real take-away here is that devices that rely on proprietary drivers always leave you at the mercy of the suppliers of those drivers, in sharp contrast to devices that implement open standards. Here I am specifically contrasting FTDI devices with CDC devices.

Where an open standard exists, this incident shows the value proposition of adopting it.

Yep, proprietary is the word here. Will we see an open source driver for the FTDI devices included into windows so the clones will be safe?

you think ebay is going to even LISTEN to you after 30 or perhaps 90 days?
are they going to reimburse you for the high cost of shipping back to china?

45 days minimum + YO DO NOT pay for any shipping in case of a fake

Ebay/Paypal policy changes between different countries, many of us have to pay return shipping for any problem and it has to be tracked (even when trackable services are not available to the country!).

[linux-works]

things may have changed on ebay since my laptop battery problem, but I did report it to ebay as a FAKE and yet I was told to pay for return shipping and it most certainly was not free.  I had photos and even some linux syslog dumps to show ebay (not that they'd even know what to do with such data).  they still told me to send it back via trackable mail and there was NO voucher or prepaid shipping label sent to me.

it was at least 2 years ago, though, maybe even 3.

[uski]

things may have changed on ebay since my laptop battery problem, but I did report it to ebay as a FAKE and yet I was told to pay for return shipping and it most certainly was not free.  I had photos and even some linux syslog dumps to show ebay (not that they'd even know what to do with such data).  they still told me to send it back via trackable mail and there was NO voucher or prepaid shipping label sent to me.

it was at least 2 years ago, though, maybe even 3.

It all depends what you report with eBay.
If you report an item that does not work, it's easy, you will be refunded.
If you report a counterfeit item, it's much harder to get a refund.

Years ago (5-6 years ago ?) I remember filing a claim for a fake Sandisk CompactFlash card. I got an e-mail from SanDisk confirming that I've been shipped a fake card, but PayPal wanted me to hire and pay a legal expert (!!!) and to ship the card to China back to the seller.

The worst thing is that the seller didn't even understand why I wasn't happy... "why aren't you happy, the card works no ?"
I have no problem with buying cheap stuff from China, I just want to know what I'm buying.

It's the same with FTDI here, I don't care if Chinese manufacturers make binary compatible chips, I only care about people writing FTDI on chips which are not made by FTDI, and shipping those to me. But even when that happens, I'm not responsible for it, I can't check the whole supply chain.

[linux-works]

good info to know.  sounds like they put undue burden on YOU if you report something as fake.

I know I did report the battery as fake but they didn't give me a run-around; they just said to ship it back and ship it trackable.  my mistake was not knowing that trackable != trackable (the post office gave me bad advice; if I can't ask them about their own service, how am I supposed to know any better?)

[edavid]

things may have changed on ebay since my laptop battery problem, but I did report it to ebay as a FAKE and yet I was told to pay for return shipping and it most certainly was not free.  I had photos and even some linux syslog dumps to show ebay (not that they'd even know what to do with such data).  they still told me to send it back via trackable mail and there was NO voucher or prepaid shipping label sent to me.

it was at least 2 years ago, though, maybe even 3.

That's not really relevant since eBay has changed their rules multiple times since then.  The current rule is that the seller has to pay return shipping, if any.

[Mr Smiley]

Looks like they might be changing their minds

http://www.ftdichipblog.com/?p=1053


 

[e100]

Using an unannounced automatic silent update via the 'trusted' Microsoft distribution channel was designed to brick as many fake chips as possible in a short space of time whilst hiding behind the Microsoft update curtain. Many consumers will be blaming Microsoft for the bricked chips.

In addition, using Microsoft as a distribution channel completely undermines the whole point of operating system 'trusted' updates which are supposed to increase reliability and fix security flaws.
It is not a medium for fighting a war against fake chips.
Like many others, I have now disabled automatic driver updates. As a consequence my computer is less secure and possibly less reliable than it could be, thanks to the action of one chip company, which from this point onwards cannot be trusted.

Supply chains are imperfect. No manufacturer can guarantee that every chip in every product is 100% genuine, so for a chip vendor to distribute a driver with a kill switch to end-users without any prior warning to manufacturers is just crazy.
It panics the companies that are trying to do everything right causing much wasted time and money.

It will be interesting to see if Microsoft continues to distribute future FTDI driver updates as FTDI has caused a bunch of bad publicity surrounding Windows update for no gain whatsoever for  Microsoft or their customers.
Distributing drivers via an operating system vendor is a privilege, not a right.

[rdl]

You don't have to disable Windows Update to avoid driver updates. You can stop driver downloads without losing the security updates for the system in general.

...
Like many others, I have now disabled automatic driver updates. As a consequence my computer is less secure and possibly less reliable than it could be, thanks to the action of one chip company, which from this point onwards cannot be trusted.
...

[Hardcorefs]

things may have changed on ebay since my laptop battery problem, but I did report it to ebay as a FAKE and yet I was told to pay for return shipping and it most certainly was not free.  I had photos and even some linux syslog dumps to show ebay (not that they'd even know what to do with such data).  they still told me to send it back via trackable mail and there was NO voucher or prepaid shipping label sent to me.

it was at least 2 years ago, though, maybe even 3.

It all depends what you report with eBay.
If you report an item that does not work, it's easy, you will be refunded.
If you report a counterfeit item, it's much harder to get a refund.

Years ago (5-6 years ago ?) I remember filing a claim for a fake Sandisk CompactFlash card. I got an e-mail from SanDisk confirming that I've been shipped a fake card, but PayPal wanted me to hire and pay a legal expert (!!!) and to ship the card to China back to the seller.

The worst thing is that the seller didn't even understand why I wasn't happy... "why aren't you happy, the card works no ?"
I have no problem with buying cheap stuff from China, I just want to know what I'm buying.

It's the same with FTDI here, I don't care if Chinese manufacturers make binary compatible chips, I only care about people writing FTDI on chips which are not made by FTDI, and shipping those to me. But even when that happens, I'm not responsible for it, I can't check the whole supply chain.

Not any more……
Starting from the 20 November, Paypal have a new policy.
1. Quires / refunds go from 42 to 180 days
2. Fakes are no longer required to be returned before you can claim a refund.

As regards to buying 'cheap stuff' from China , even the suppliers don't know what they are selling.
The issue I have with this whole FTDI fiasco is that the  fake chips are NOT being sold cheaper, they also under perform not reaching the full 3mbs or are generally unstable.

The main problem is  that E* scum, are  circumventing absolutely boatloads of legal requirements as regards fit for purpose, IP violations and safety requirements and E* the company are taking a massive cut of that illegal business.
Very few if any of the suppliers are even aware how to perform safety/quality checks on the products they are selling, and I have personally seen and photographed illegal business practices by E* suppliers that I have tracked down in Shenzhen, even know of at least one that is selling dangerous kit into the market.(Reporting it got MY E* account closed down, because until it is reported E* has plausible deniability…after that they are opened up to all sorts of legal problems…. SOLUTION: cannot check supplier, so trash whistle blower and word will get around)

[marcan]

Can someone create a tool to reproduce the "kill" operation of the 2.12 driver? If this is a "thing" that can happen, I'd prefer to add a few seconds of production test time to screen parts that might cause the end-user grief down the road. This is, in essence, a vulnerability without a clear way to patch it - so the easiest route I can do is attempt to brick any devices that might get a non genuine part in the lot. (I buy all my parts from Mouser and Digikey, but they're not omnipotent or flawless).

Here is some code that will non-destructively test for clones and also fix them if bricked.
https://mrcn.st/t/ftdi_clone_tool.py

It should work on a Linux system with Python2 and libftdi1 with Python bindings. I have not tested it on clones as I don't have any, but I believe it should work. AIUI libftdi also works on Mac OS X and Windows, so you should be able to get it to work on those OSes too.
It should work on a Linux system with Python2 and PyUSB. I have tested it and it accurately detects and restores clones. It should also work on Windows and Mac OS X if you have PyUSB with a working backend installed (although I guess Windows > XP might still complain about the zero PID; haven't tested that, if you do please report back).

Edit: I am dumb and forgot that I was using a patched libftdi1 to make this work. Rewrote the entire thing to use libusb instead. You need PyUSB (under Ubuntu, apt-get install python-usb).

[krater]

Okay, FTDI will now go one step back. They talked with their lawyers and they sayd, that what you do is really dumb and dangerous, and you're caught now. And now, one month after the kill-update released, rhey step back and want to sell that to us as community success.
F*** YOU FTDI !
I will never use one part of you in a new design.

They don't lerned, they just try to limit the damage. The risk that they do some thing again is not smaller than yesterday....
If they lerned, they would release a update that repairs the bricked chips....

[(*steve*)]

ere is some code that will non-destructively test for clones.
https://mrcn.st/t/detect_ftdi_clone.py

Forgive me, I'm not a python user.  I get the error:

ImportError: No module named ftdi1

I assume this means I don't have the python bindings for this.  How do I install them (I'm using Linux Mint)

[cypherpunks]

Can someone create a tool to reproduce the "kill" operation of the 2.12 driver? If this is a "thing" that can happen, I'd prefer to add a few seconds of production test time to screen parts that might cause the end-user grief down the road.

Marcan posted some reverse-engineered source earlier in this thread (variable and function names are not original):

https://marcan.st/transf/ftdi_evil.png
https://marcan.st/transf/checkbrick.png

It's quite simple:

• This is only run on chips with bcdDevice & 0xff00 == 0x0600.
• It exploits a quirk of FTDI's EEPROM: writes are 32 bits, so writes to even words are buffered until the corresponding odd word is written.  The clones allow 16-bit writes.
• It writes eeprom[2] (the PID) to 0, and eeprom[62] (unused) to a value that keeps the checksum valid.
• On a real FTDI chip, neither write actually does anything.
• On a fake, they go through and achieve the brick.  (I'm guessing they have to get the checksum right or the parts will fall back to useable default ROM settings.)

Seeing this, what they did actually makes a little bit of sense: the bricking is sort of a side-effect of the detection algorithm.  They could have done a test-write to a different word, but I can see a bloody-minded person saying "fuck it, don't bother putting the old value back, just leave it broken".

Of course, they failed to think through the consequences of shooting the horse long after it had left the barn and causing massive amounts of pain for people who were also victims of the counterfeiting.  And for whom the easiest way to ensure it never happens again is to switch to a competitor's product.

[alex.forencich]

Can someone create a tool to reproduce the "kill" operation of the 2.12 driver? If this is a "thing" that can happen, I'd prefer to add a few seconds of production test time to screen parts that might cause the end-user grief down the road.

Marcan posted some reverse-engineered source earlier in this thread (variable and function names are not original):

https://marcan.st/transf/ftdi_evil.png
https://marcan.st/transf/checkbrick.png

It's quite simple:

• This is only run on chips with bcdDevice & 0xff00 == 0x0600.
• It exploits a quirk of FTDI's EEPROM: writes are 32 bits, so writes to even words are buffered until the corresponding odd word is written.  The clones allow 16-bit writes.
• It writes eeprom[2] (the PID) to 0, and eeprom[62] (unused) to a value that keeps the checksum valid.
• On a real FTDI chip, neither write actually does anything.
• On a fake, they go through and achieve the brick.  (I'm guessing they have to get the checksum right or the parts will fall back to useable default ROM settings.)

Seeing this, what they did actually makes a little bit of sense: the bricking is sort of a side-effect of the detection algorithm.  They could have done a test-write to a different word, but I can see a bloody-minded person saying "fuck it, don't bother putting the old value back, just leave it broken".

Of course, they failed to think through the consequences of shooting the horse long after it had left the barn and causing massive amounts of pain for people who were also victims of the counterfeiting.  And for whom the easiest way to ensure it never happens again is to switch to a competitor's product.

Yeah, what I think happened is they figured out that this was a difference between the chips and they decided that they would just send the commands to all FT232RL chips so they don't explicitly discriminate against the 'counterfeit' chip.  Perhaps they figured this would legally be a sound method (hey, we send the same commands to all FT232RL chips, it just 'happens' to brick the 'counterfeit' ones).  However, with the trouble of going through and recalculating the checksum, the code cannot just be explained away and obviously has no other purpose than explicit malicious intent against alleged counterfeit chips. 

[cypherpunks]

Fluke did a much better job with the Sparkfun's yellow DMMs.

Better, but they were still assholes.  They offered to replace SparkFun's 2000 multimeters with $30K of Fluke products.  Nice, but that's not going to fill 2000 customer orders!

And needlessly destroyed 2000 fully functional, if low-quality, multimeters.

The classy thing to do would have been to simply grant SparkFun a temporary trademark license if they agreed to fix things as fast as humanly possible.

[miguelvp]

Those sparkfun meters deserved their death.

If at least they were decent meters then maybe, but there is no way to grant a license (temporary or not) because that will kind of mean endorsement, which fluke, in good conscience, just couldn't do.

I think fluke handle matters pretty well, and it's not like those meters where back ordered. Even after the fiasco, there were some left at the local microcenter.

[SeanB]

Even has made it to "main stream" tech press, or TheRegister, if you want to look.

http://www.theregister.co.uk/2014/10/24/ftdi_bricking_driver_response/

Wonder how many of the commenters are also on this thread, the comments page look remarkably similar.

[cypherpunks]

Those sparkfun meters deserved their death.

WTF?  They are sold as Digital Multimeter - Basic, i.e. "cheap but basically functional".  AFAIK, that's exactly what they are.  I have a pile of even cheaper Harbour Freight multimeters precisely because they're basically disposable.  I can stash one anywhere one might be useful.  There's one in the car with the jack and spare fuses just in case, one in the drawer with the spare batteries to ensure I don't get a dead one mixed in, and so on. 

there is no way to grant a license (temporary or not) because that will kind of mean endorsement, which fluke, in good conscience, just couldn't do.

Utter rubbish.  They are required to police their trademark or lose it.  But just like a simple defense to adverse posession of real estate is to grant permission, you can do the same with a trademark.  SparkFun had already sold thousands of the things in yellow, and was going to seel thousands more after changing the rubber.  Letting you off with a warning isn't endorsement.

[Bored@Work]

Those sparkfun meters deserved their death.

WTF?  They are sold as Digital Multimeter - Basic, i.e. "cheap but basically functional".  AFAIK, that's exactly what they are.  I have a pile of even cheaper Harbour Freight multimeters precisely because they're basically disposable.

Meters with fake safety ratings need to die. And contrary to your opinion, they are not basically functional. Safety is an essential and basic function. These crap doesn't provide it.

And seeing how SparkFun advertise the crap multimeter, SparkFun are essentially assholse here, bullshitting "starving students".

[hans]

And why not writing an Open Source library 100% compatible for a uC? Would it be legal? Who wants some?

Sure, here is a kick-off project for those who want to follow along:

http://www.microchip.com/forums/FindPost/275586

What if I would write a FTDI-emulated device and use it only on Linux. Do the Windows license terms apply? Doubtful.

As for Windows/FTDI terms:

- The licence only allows use of the Software with, and the Software will only work with Genuine FTDI Components (as defined in the Licence Terms). Use of the Software as a driver for a component that is not a Genuine FTDI Component MAY IRRETRIEVABLY DAMAGE THAT COMPONENT.
- It is your responsibility to make sure that all chips you use the Software as a driver for are Genuine FTDI Components. If in doubt then contact FTDI.

Wouldn't that make it my own risk to run non-FTDI parts with the driver? They may be damaged? Are we then cowboys (but not outlaws) for taking risks?

The FTDI protocol is not complicated. It's around in the linux kernel free to watch. Whether it's a moral thing to do; hmm.