FTDI driver kills fake FTDI FT232??

[uski]

It's unfortunate that this hits the end user and it's too late for the money lost to the cloners. I suppose lots of angry customers going up the supply chain demainding answers might weed out bad supply chains and make major suppliers very aware that they much buy from genuine sources.

As a FTDI customer, I have absolutely no way of checking if I have a genuine FTDI part or not.
FTDI in their EULA asks people to check if the components are genuine before using the driver, but they give absolutely no way of doing so.

As I said, even the military has been sold counterfeit items in the past. It can happen to anyone.
So as a customer it feels safer just to avoid FTDI parts altogether (there are alternatives) than risking my device bricked some day.

[uski]

(lots of comments)

You are my hero.

[Rufus]

There's a difference between code that happens not to work on another device, and code whose sole purpose is to destroy another device.

But the device was not destroyed. An invalid PID was corrected and the device was actually improved.

[uski]

There's a difference between code that happens not to work on another device, and code whose sole purpose is to destroy another device.

But the device was not destroyed. An invalid PID was corrected and the device was actually improved.

You work for FTDI right ?

[XFDDesign]

As a FTDI customer, I have absolutely no way of checking if I have a genuine FTDI part or not.
FTDI in their EULA asks people to check if the components are genuine before using the driver, but they give absolutely no way of doing so.

I've submitted a support request to FTDI (Huzzah for being from a large Semi manufacturer who uses their parts on eval boards) to get an EOL software test. If parts fry, at least kill them before they hit the end customer. I'll post if I hear anything back.

[XFDDesign]

Given all the ruckus about "it doesn't destroy anything, it just..." how about some dictionary definition straight from Merriam Webster:

de·stroy verb \di-?stro?i, d?-\
: to cause (something) to end or no longer exist
: to cause the destruction of (something)
: to damage (something) so badly that it cannot be repaired

I'd say that for the majority-use-case, #3 is the cake that FTDI takes.

[krater]

There's a difference between code that happens not to work on another device, and code whose sole purpose is to destroy another device.

But the device was not destroyed. An invalid PID was corrected and the device was actually improved.

No your motherboard is not destroyed, just your BIOS is wiped....
Oh, your car is not destroyed, we can bend it to that it just looks as new....

can you say me where's the difference ?

[zapta]

But the device was not destroyed. An invalid PID was corrected and the device was actually improved.

No your motherboard is not destroyed, just your BIOS is wiped....
Oh, your car is not destroyed, we can bend it to that it just looks as new....

can you say me where's the difference ?
[/quote]

Don't fall for the trolls.

[mikeselectricstuff]

Given all the ruckus about "it doesn't destroy anything, it just..." how about some dictionary definition straight from Merriam Webster:

de·stroy verb \di-?stro?i, d?-\
: to cause (something) to end or no longer exist
: to cause the destruction of (something)
: to damage (something) so badly that it cannot be repaired

I'd say that for the majority-use-case, #3 is the cake that FTDI takes.

Talking of definitions, in UK law, damage does not need to be permanent to still count as criminal damage. e.g. letting car tyres down.

[Xpendable]

First time poster here.  I consider myself a hobbyist when it comes to electronics.  I have a VERY small side business where I make a controller used primarily in the Halloween industry for pneumatic prop animation control.  For the past few months I have been working on a new design, and I had originally planned on using an FTDI232RL chip to handle host communications - an important component to my product.  After seeing this, I think a better move for me would be to move to the ATmega32u4 instead of using an FTDI chip.  I of course would only have wanted to use genuine FTDI chips.  I have only ever bought parts from DigiKey, Mouser, or element14.  My bare boards are made in China.  Right now I hand assemble every product myself with a hot air reflow station.  I'm small potatoes... I sell less than 100 controllers a year but.  But this thing with FTDI scares the crap out of me.  I'm left wondering if a bunch of devices I have from other companies are now going to be "bricked".  Just my 2 cents.

[tggzzz]

For the FTDI programmer's sake, I hope bricking of equipment connected to government computers isn't interpreted as a cyber attack on national security!

http://slashdot.org/story/14/10/23/1235205/proposed-penalty-for-uk-hackers-who-damage-national-security-life

[Kjelt]

A good analogy with the VID for USB would be the MAC address for IPv6.
My company identifies their products through the IPv6 address which is directly related to the MAC address, so if another company wants to clone our devices it should use the same range of MAC addresses. BUT since anybody can change his MAC address ( on a pc for instance) this can never be the sole way to identify that product. So there should always be some kind of cryptographic handshake performed to uniquely identify that product and if t is not genuine the communication ends.
That is where FTDI misses the ball, they think that no other chip is allowed to use their VID so they can do whatever they want with those chips. No company has the right to do that based on some unprotected number. They should just id the chip and if it is not theirs stop the driver thats all they should ever do.

[XFDDesign]

Given all the ruckus about "it doesn't destroy anything, it just..." how about some dictionary definition straight from Merriam Webster:

de·stroy verb \di-?stro?i, d?-\
: to cause (something) to end or no longer exist
: to cause the destruction of (something)
: to damage (something) so badly that it cannot be repaired

I'd say that for the majority-use-case, #3 is the cake that FTDI takes.

Talking of definitions, in UK law, damage does not need to be permanent to still count as criminal damage. e.g. letting car tyres down.

I totally agree. The whole point is that people are throwing around "it's not destroyed" in a way that tries to evade the very meaning of "destroy." Even by the definition, they're doing just that.

[_Sin]

Anyone remember MOS? They made 6800 compatible processors for a fraction of the price that Motorola were selling them. Was MOS leeching off Motorola, making use of their compilers, software written for their ICs, their development systems, their emulators? There is a fine line between cloning and just making compatible hardware, and that line is etching an FTDI logo onto the chip.

The made a chip which was pin compatible, but not software compatible...

[weilawei]

Given all the ruckus about "it doesn't destroy anything, it just..." how about some dictionary definition straight from Merriam Webster:

de·stroy verb \di-?stro?i, d?-\
: to cause (something) to end or no longer exist
: to cause the destruction of (something)
: to damage (something) so badly that it cannot be repaired

I'd say that for the majority-use-case, #3 is the cake that FTDI takes.

Talking of definitions, in UK law, damage does not need to be permanent to still count as criminal damage. e.g. letting car tyres down.

Not only that, but in most jurisdictions, unwanted alteration falls under "harm" or "destruction of property". You don't need to take a hammer to something--just modifying it without the consent of the owner is enough to constitute destruction of property.

Disclaimer: I am not a lawyer. This is not legal advice.

[_Sin]

I do wonder if FTDI actually got much legal advice before doing this. I especially wonder if right now they're frantically getting a lot *more* legal advice...

I can see the logic - "oh, we we're not detecting anything, it's just our driver happens to do something that on a buggy knock-off does something bad, it's not our fault that someone copied our chips badly but used our driver..." - while completely glossing over the fact that the *only* purpose to that code is to break those chips, and it's otherwise a completely unnecessary null operation on their own ones. i.e. obviously and demonstrably a deliberate act with a single purpose - to disable chips they didn't sell. I think they'll be lucky if there's not *some* market in which that won't turn out to be an expensive misjudgement.

[rolycat]

I think they'll be lucky if there's not *some* market in which that won't turn out to be an expensive misjudgement.

I think they'll be lucky if there's *any* market in which this won't turn out to be an expensive misjudgement.

[tggzzz]

Anyone remember MOS? They made 6800 compatible processors for a fraction of the price that Motorola were selling them.

And exactly what was the part number of that MOS Technology chip? Hint: it wasn't the 650x series.

The 650x series had essentially the same functional pinout as the 6800, but a radically different instruction set.

[leo_r]

I have an Arduino compatible board purchased from Farnell which was built by a fairly reputable manufacturer.  It seems that it's detected as being a counterfeit by the FTDI driver.

Either this means that the chip is a counterfeit or that the driver is detecting it wrong. Either way it is *absolutely* NOT MY FAULT! I'd understand (to some degree) if I'd bought a $3 board off ebay, but in this case I didn't. There's evidently been some dishonesty at some point in the supply chain that has lead to this.

If I'm left with a dead device which I bought in good faith from a reputable supplier and manufacturer, how many others are? Supply chains are clearly not impervious to fake chips. I can't imagine how much pain a silent Windows update is going to cause people trying to debug this.

[bingo600]

Just found this link on AvrFreaks

http://www.reddit.com/r/arduino/comments/2k0i7x/watch_that_windows_update_ftdi_drivers_are/clgviyl
Seems line debricking is easy on linux.

But that still leaves around 95% of those people i know , in the dark.

/Bingo

[FPGAcrazy]

I bet there are other ways of detecting them. I don't have any clones myself, so I can't test, but it's extremely unlikely that the cloners nailed everything else but this. And even if they did, it would still be way better to read-modify-write-restore the EEPROM as a detection mechanism, rather than, again, going for damage.

It was more a question. And something to think about.
I am not sure but it is very likely that the configuration data is only read once. Need to read the standard for that.

There's a difference between code that happens not to work on another device, and code whose sole purpose is to destroy another device. "Only use manufacturer-approved equipment" is not a valid legal veil to hide behind while you explicitly set out to destroy non-compliant equipment. It's (usually) legal to detect and refuse to work with knockoffs (not always - antitrust laws come into play here, and sometimes even that can be illegal). Deliberately causing damage is crossing the line.

I think this is more law stuff which you showed I do not know anything about.

Linux still won't load the driver. That's still causing deliberate damage, even if it's reversible.

Problem with linux that devices with ID zero cann't be used?

Hence, don't work. It's a negative state of affairs, particularly for the owners of said devices.

I personally think this method is bad practice, but I can image that they do it.

You seem to be confusing compatibility with 100% identical behavior. Intel and AMD CPUs are largely compatible. They're also trivial to tell apart. Even AMD's original (much simpler, compared to modern chips) Am486 was completely compatible with the 80486, but dedicated code designed to tell it apart could still do so.

You can buy Philips screwdrivers from two manufacturers. They are compatible. Doesn't mean they have to be the same color, material, or have all the atoms in exactly the same place. Just because I can look at them and tell them apart doesn't mean they aren't compatible.

Read again. License vs copy is going on in all this text. AMD has a license and for the philips screwdriver you needed a license blablabla.
If AMD vs INTEL is so easy why does not NVIDIA make x86 CPU. Something to thing about.

Actually, that product ID is unused by Intel right now, so absolutely nothing bad would happen, and if your device is of a standard device class, it'll even work fine with generic drivers. For example, I could build a PCI SD Host Controller interface with those IDs, and it would work fine. Intel might not be amused, and it would be a silly idea, but harmless. If Intel ever releases a device with that ID, then indeed it would cause a conflict. However, if I designed a device register-compatible with an Intel device and used its same ID, again, practically speaking, nothing bad would happen. In fact, that is exactly what all virtualization solutions like VMWare, VirtualBox, and QEMU do, all the time. I have myself written a virtual USB xHCI controller for QEMU, and yes, it could emulate one of two different chips, and yes, it used their VID/PID, and yes, it even had to deal with some retarded "anti-clone" vendor-specific commands, and no, it wasn't 100% bug-for-bug compatible, but it was close enough to work.

Sorry, I did not check this ID, but you get my drift.
Emulating some one else device in software is a bit different than sellling a cloned chip  of it.
I tried to explain if you do not implement exactly the same register set then using some one else VID and PID maybe a mistake.

You pay $5000 for the right to use the USB logo. Yes, the IDs should be unique. No, there is no legal protection nor guarantee that they are, unless you use the USB logo. The world doesn't end if you use someone else's ID, especially if you do it in a compatible way.

No, there is no legal protection, but there is one organization for it.
No, the world doesn't end when you do this is your own hobby environment, but it will when you do in the real world. Modern PC work by a lot of standards which need to be implemented very carefully.

Actually, the vast majority of the USB devices that people use every day are identified by class codes, not VID/PID - mass storage, HID, CDC, even the PCI controllers (UHCI, OHCI, xHCI). VID/PID only have to be unique for a particular proprietary device interface. Nobody cares about what VID/PID you use for a standard device (as long as they don't conflict with a proprietary one, which might result in their driver being assigned), and again, there's nothing wrong with masquerading as another device if you intend to be compatible with it. You're taking a risk, but that's a compatibility risk, and it's not reasonable to expect direct gunfire from the other side in return.

Yes, I know see also another post from me good Google search though 
Again you confuse an open standard Keyboard controllers mice, HD and so on.
They can use a standard drivers. But standard hardware still will have their own VID/PID,but use a generic driver.  Specialized hardware uses a unique VID/PID pair.
Masquerading the chip and providing your own drivers is no problem.

Sure, and everyone demands a paper trail and armed guards across the entire chain of custody, to make sure no counterfeits slip in, right?

It sucks when these things happen, but placing all the blame on the final assembler/manufacturer is grossly oversimplifying things. You have no idea what happened that led to counterfeits being used in an end product.

Yes, very much. It also sucks when you get counterfeit money too. Live sucks.

Funny, the first Google result for "netherlands counterfeit goods" proves you wrong. There's an exception for personal use, within reasonable limits. Seriously, before you argue with someone on the Internet about your own country's laws, you might want to at least do a cursory check...

I am sorry, for you that you need to get personal.
By the way read it very careful it states that in principle it is FORBIDDEN.
But as everything in the Netherlands it will be "Gedoogd". I would advice you to google for this word. 

None, but I've developed a rather strong disgust for people who destroy end-user hardware through gross negligence or deliberate action, over the past 8 years or so, due to certain communities I've been involved in, and I've done my best to make sure that my software never does that, not even in the least likely of circumstances. I have a very strong respect for people's hardware.

Yes, you have a very strong respect for some one else hardware, but none for their software, which I always find very strange. People pay without problems 1000 of euros for hardware, but do not want to pay for software.
I am always puzzled that all the world things that software comes for free. Most of the time it is, however one of the biggest challenges in a design to get the software correct.
So copying it is simple.

[mikeselectricstuff]

I do wonder if FTDI actually got much legal advice before doing this. I especially wonder if right now they're frantically getting a lot *more* legal advice...

I can see the logic - "oh, we we're not detecting anything, it's just our driver happens to do something that on a buggy knock-off does something bad, it's not our fault that someone copied our chips badly but used our driver..." - while completely glossing over the fact that the *only* purpose to that code is to break those chips, and it's otherwise a completely unnecessary null operation on their own ones. i.e. obviously and demonstrably a deliberate act with a single purpose - to disable chips they didn't sell. I think they'll be lucky if there's not *some* market in which that won't turn out to be an expensive misjudgement.

However for the vast majority of victims, the loss involved isn't enough to bother with.
The apportion of blame between FTDI & Microsoft may also be tricky to determine. 
I would _really_ like to know if MS knew about it though.

[daveshah]

I wonder if FTDI have pulled the update. http://www.ftdichip.com/Drivers/CDM/CDM%20v2.12.00%20WHQL%20Certified.zip (the latest version on their site) redirects to the v2.10 download - not sure if it always has done this or not?

[FPGAcrazy]

A good analogy with the VID for USB would be the MAC address for IPv6.
My company identifies their products through the IPv6 address which is directly related to the MAC address, so if another company wants to clone our devices it should use the same range of MAC addresses. BUT since anybody can change his MAC address ( on a pc for instance) this can never be the sole way to identify that product. So there should always be some kind of cryptographic handshake performed to uniquely identify that product and if t is not genuine the communication ends.
That is where FTDI misses the ball, they think that no other chip is allowed to use their VID so they can do whatever they want with those chips. No company has the right to do that based on some unprotected number. They should just id the chip and if it is not theirs stop the driver thats all they should ever do.

A MAC address is in its nature not unique nor does it needs to be. As long as you have one MAC address on a segment it works correctly. The IPV6 address needs to be unique if some one clones them you get a lot of problems. Depending on routing packets may get lost and not arrive in the correct location.
Actually the VID/PID should be unique for every vendor, which registers itselfs by the USBsig and get one VID and I think that they can chopse the PID themselfs. This makes me wonder they can only support up to 65535 vendors.

To make things clear I think that FTDI made a big mess of this whole affair.
But I do understand why they do it.

[limbo]