Author Topic: FTDI driver kills fake FTDI FT232??  (Read 946752 times)

0 Members and 3 Guests are viewing this topic.

Offline marcan

  • Regular Contributor
  • *
  • Posts: 80
  • If it ain't broke I'll fix it anyway.
    • My blog
Re: FTDI driver kills fake FTDI FT232??
« Reply #400 on: October 23, 2014, 01:38:06 pm »
1. FTDI detects that the chips are counterfeit, however the process of doing this bricks the counterfeit chips. The copy is not functional equivalent to the real FTDI chip and therefor stops working.
2. After this detection process the chip is left in a undefined state. Is it really the task of FTDI to clean this up?
This is incorrect. FTDI doesn't actually detect that the chips are counterfeit at all. The driver, instead, uncoditionally, and without feedback, issues a set of commands that have been carefully and meticulously crafted to do nothing to a real FT232RL (and only FT232RL - they'd almost certainly brick other FT*** chips!) while bricking a counterfeit chip. The driver doesn't even check if the device was bricked/modified/a clone. In fact, I believe the driver will work fine with a clone the first time it's plugged in - until the device is reset, the new EEPROM content is applied, and the brick becomes evident.

3. If they choose to do the test and restore the content of the eeprom it will also result in a massive failure of devices. Because frequently programming and erassing an eeprom will certaintly destroy it. Keep in mind that the FTDI device eeprom is not programmed using this detection circuit.
EEPROMs are usually pretty resilient (unlike Flash), and only counterfeit chips would actually be programmed, and then only once each time they are enumerated. This would not affect their customers, nor will it realistically affect the clones either, unless their EEPROM array is crap.

This is unquestionably a deliberate act by FTDI to brick clone devices. It's not a "clone detection that unfortunately bricks them". They went for the kill, going as far as reversing their own checksum routine to be able to bypass the checksum in a way that only takes effect on clones. I suspect someone at FTDI might think they're safe because "well, we issue the same commands to all chips, it's not our fault that only clones are affected!!!!", but that's not going to stand up in court when it is evident and unquestionable that the code has been designed for the sole purpose and effect of bricking clone chips.

FTDI is only preventing user from using their driver with counterfeit chips. There is nothing wrong with this.
Uh, no. FTDI's driver makes the victim device not work with *any* driver. FTDI did not write the driver that Linux uses. Plugging a clone into a Windows box running FTDI's driver will make it stop working on a Linux box which has nothing to do with their intellectual property. This is deliberate destruction (or at least damage) of property, and almost certainly illegal in most reasonable jurisdictions.

For now this works.
You mean for now this doesn't work and people's devices are now broken.

The question is also how good do these chips work and are they fully compatible.
They were until FTDI decided to latch onto implementation minutiae to destroy them. There's a difference between a functional clone and a 100% perfect bug-compatible replica.

The USB vendor id and product id are reserved for and by FTDI.
If you want to use the USB logo.

Using them results in a non working plug and play system.
No, using them results in their driver being loaded. Or someone else's driver for FTDI chips (like the one in Linux). Nothing more, nothing less. In fact, I would strongly consider using their VID and PID if I were writing USB-serial firmware for something and wanted it to work anywhere (though I'd probably end up going for CDC if that works out of the box on Windows these days). And it would be perfectly legitimate. It's a number, and FTDI have no legal protection from others using it.

The chips are sold as counterfeits and therefor they should not be used.
Agreed. This, unfortunately, has nothing to do with the unlucky manufacturers and especially end-users who unintentionally ended up with counterfeits.

This is very simple and is valid in the whole of europe.  A fake Rolex will also be destroyed and the buyer is responsible for this. Actually buying counterfeit products is a crime.
Nope. Only in France and Italy. Buying counterfeit products is legal in the rest of the world. You're even allowed to knowingly import one counterfeit item per class into the US. *Selling* counterfeit products is illegal. Buyers/end-users have no fault in any of this, and destroying their hardware because it's counterfeit is *WRONG*.
« Last Edit: October 23, 2014, 01:40:47 pm by marcan »
 

Offline amyk

  • Super Contributor
  • ***
  • Posts: 8240
Re: FTDI driver kills fake FTDI FT232??
« Reply #401 on: October 23, 2014, 01:42:50 pm »
If you can find a single clone that is not marked as FT232, then maybe. But I'm not aware of such existing, as they are mostly prolific clones. Anyway now people are yelling about bricking devices where are chips with FTDI and FT232Rx written on them indeed. I'm not big supporter of such tactics, but i think that technically it is OK to do in legal aspect.
Yes there are certainly FT232-compatible ICs with no FTDI markings on them.

I did a bit more digging on 'Supereal' and found that they also make a USB-ethernet IC.. Note that there are absolutely no markings on the IC, but the die has "SUPEREAL SR1002" on it. Following the lead that this is supposed to be an "RD9700"-compatible IC (another obscure Chinese part), I found the "SR9700" and traced that to this Chinese company, which also happens to make a USB-serial IC named the "SR6866" (or SR6865, depending on which page of the site you trust...) and another curiously-named SR2303HX - a Prolific clone. I think we have a match.

tl;dr: These "fake" FT232-compatible ICs are produced by a Chinese company named CoreChips, with their own part numbers, and they are almost certainly not selling them with FTDI markings - as this image of the Prolific clone shows. It's legal to create a competing and compatible product through reverse-engineering. It's not legal to put FTDI's name on it, which is probably being done by someone else downstream.

Quote
Comparing INTEL vs AMD is not a good comparising in this case, because they have cross licensing deals. AMD did not reverse engineer the chips, but had a license to produce the design from INTEL for INTEL. AMD manufactored copyright by INTEL and so on
They now have cross-licensing, but AMD reverse-engineered and cloned the 386.
 

Online wraper

  • Supporter
  • ****
  • Posts: 16794
  • Country: lv
Re: FTDI driver kills fake FTDI FT232??
« Reply #402 on: October 23, 2014, 02:01:24 pm »
Oh, I remembered about one more clone with Belarus origin. Stumbled on it more than a year ago but completely forgot about it. Seems to ship only in the die form, yay  ;D
Datasheet: http://www.bms.by/eng/spec/PDF/IZ232e-ts.pdf
« Last Edit: October 23, 2014, 02:10:31 pm by wraper »
 

Offline FPGAcrazy

  • Contributor
  • Posts: 17
Re: FTDI driver kills fake FTDI FT232??
« Reply #403 on: October 23, 2014, 02:10:43 pm »
This is incorrect. FTDI doesn't actually detect that the chips are counterfeit at all. The driver, instead, uncoditionally, and without feedback, issues a set of commands that have been carefully and meticulously crafted to do nothing to a real FT232RL (and only FT232RL - they'd almost certainly brick other FT*** chips!) while bricking a counterfeit chip. The driver doesn't even check if the device was bricked/modified/a clone. In fact, I believe the driver will work fine with a clone the first time it's plugged in - until the device is reset, the new EEPROM content is applied, and the brick becomes evident.

The question here is, is it possible for FTDI to detect if the chip is counterfeit in another way?
I do not think so! They probably spend a lot of time figuring this method out.
Also configuration data will only be read once, hence the one time run.
From my experience eeproms do not last that long. I have seen device which where guaranteed for 250 write/read cycles which only survived a few read/write cycles.

This is unquestionably a deliberate act by FTDI to brick clone devices. It's not a "clone detection that unfortunately bricks them". They went for the kill, going as far as reversing their own checksum routine to be able to bypass the checksum in a way that only takes effect on clones. I suspect someone at FTDI might think they're safe because "well, we issue the same commands to all chips, it's not our fault that only clones are affected!!!!", but that's not going to stand up in court when it is evident and unquestionable that the code has been designed for the sole purpose and effect of bricking clone chips.
FTDI doesn't have to guarantee that there code works with chips of someone else. Many manufactors warn for non-functioning equipment when their drivers are used with products, which are not produced by them. 


Uh, no. FTDI's driver makes the victim device not work with *any* driver. FTDI did not write the driver that Linux uses. Plugging a clone into a Windows box running FTDI's driver will make it stop working on a Linux box which has nothing to do with their intellectual property. This is deliberate destruction (or at least damage) of property, and almost certainly illegal in most reasonable jurisdictions.
Actually they just erase the product id. That is all you can easy reprogram it.

You mean for now this doesn't work and people's devices are now broken.
I mean that counterfeit IC cann't be used for now with the new drivers.

They were until FTDI decided to latch onto implementation minutiae to destroy them. There's a difference between a functional clone and a 100% perfect bug-compatible replica.
No, they are not. They do not pass the new test system to detect if they are a clone. Therefor they are not compatible. Many PC compatibles in the 80 where also not  compatible.

If you want to use the USB logo.
No, these ID's are used to assign a driver to the chip through the INF file. For instance in the PCI system if you chose to use 8086 as vendor id and 8259 as product ID I am sure you end up with a non functioning PC.
The same applies also for the USB. This is the only way for the OS/BIOS/EFI to detect new hardware and assign the right driver. They should be unique ID's. You pay $5000 so that you are ensured they are unique.

No, using them results in their driver being loaded. Or someone else's driver for FTDI chips (like the one in Linux). Nothing more, nothing less. In fact, I would strongly consider using their VID and PID if I were writing USB-serial firmware for something and wanted it to work anywhere (though I'd probably end up going for CDC if that works out of the box on Windows these days). And it would be perfectly legitimate. It's a number, and FTDI have no legal protection from others using it.
Try assigning some random numbers to your USB devices and see what happens on Linux also. You need a VID and PID and the system works by uniqueness of these numbers.

Agreed. This, unfortunately, has nothing to do with the unlucky manufacturers and especially end-users who unintentionally ended up with counterfeits.
It is the responsibility from the manufactor to check their sources.

Nope. Only in France and Italy. Buying counterfeit products is legal in the rest of the world. You're even allowed to knowingly import one counterfeit item per class into the US. *Selling* counterfeit products is illegal. Buyers/end-users have no fault in any of this, and destroying their hardware because it's counterfeit is *WRONG*.
I think here in the Netherlands you can leave it behind on the airport and may be lucky when you do not get a fine.

P.s. How many non-functioning devices you got?

 

Offline XFDDesign

  • Frequent Contributor
  • **
  • Posts: 442
  • Country: us
Re: FTDI driver kills fake FTDI FT232??
« Reply #404 on: October 23, 2014, 02:16:49 pm »
Quote
FTDI doesn't have to guarantee that there code works with chips of someone else. Many manufactors warn for non-functioning equipment when their drivers are used with products, which are not produced by them. 

If I wrote a virus which was piggybacked along with another piece of software, and it completely takes out your computer; wipes your bios (attempting to flash and re-flash it to the point of exhausting the write-life), knocks out your boot sector, and deletes your windows folder, then claim "if you didn't want that to happen, you shouldn't have run my software on any machine but ones I sell" would you say that's just fine and legal?
 

Offline nctnicoTopic starter

  • Super Contributor
  • ***
  • Posts: 26751
  • Country: nl
    • NCT Developments
Re: FTDI driver kills fake FTDI FT232??
« Reply #405 on: October 23, 2014, 02:18:29 pm »
I understand there are a lot of angry people out there. But I have some remarks to think about.

1. FTDI detects that the chips are counterfeit, however the process of doing this bricks the counterfeit chips. The copy is not functional equivalent to the real FTDI chip and therefor stops working.
This is where you are wrong already. The 'counterfeit' chip isn't a copy. It is a functional equivalent. Just like you can buy PC processors from AMD.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline andersm

  • Super Contributor
  • ***
  • Posts: 1198
  • Country: fi
Re: FTDI driver kills fake FTDI FT232??
« Reply #406 on: October 23, 2014, 02:19:01 pm »
And would you like a tin hat to go with that ? I've never had problems and use paper bags
I've bought some ATtinys off of eBay, and they arrived stuck in a piece of styrofoam packaged in a ziploc bag. They seem to work, but I would not use them for anything I would sell, or was in any way safety-related.

Offline Simon

  • Global Moderator
  • *****
  • Posts: 17728
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: FTDI driver kills fake FTDI FT232??
« Reply #407 on: October 23, 2014, 02:19:55 pm »
Franky i don't understand why the counterfeiters don't just release their own driver and separately Id the chip, i mean having to accept "non signed" windows drivers is not something that has stopped major manufacturers and software houses. If they choose to imitate someone else's ID in order to appropriate their driver they can't complain if they have not made their chips compatible with the driver. It's not like serial to USB converter chips are bleeding edge technology that only comes from one manufacturer.

Yes it's not a problem with a short term solution so arguing about one is pointless. What is needed is to track down the counterfeiter and sue them, ah but then cross continent lawsuits are probably a minefield.
 

Offline XFDDesign

  • Frequent Contributor
  • **
  • Posts: 442
  • Country: us
Re: FTDI driver kills fake FTDI FT232??
« Reply #408 on: October 23, 2014, 02:20:29 pm »
By the way, that is the SILabs competing part? I may as well start looking at them while I wait to hear back from FTDI on something (In spite of KRP8's claim, I have a product which has shipped a few thousand of these parts this year alone, with the major release tentatively coming up Q1-15. :|
 

Offline Simon

  • Global Moderator
  • *****
  • Posts: 17728
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: FTDI driver kills fake FTDI FT232??
« Reply #409 on: October 23, 2014, 02:21:46 pm »
And would you like a tin hat to go with that ? I've never had problems and use paper bags
I've bought some ATtinys off of eBay, and they arrived stuck in a piece of styrofoam packaged in a ziploc bag. They seem to work, but I would not use them for anything I would sell, or was in any way safety-related.

Of course that is an extremely stupid way to package them, there are small time sellers and "ebay monkeys".
 

Offline XFDDesign

  • Frequent Contributor
  • **
  • Posts: 442
  • Country: us
Re: FTDI driver kills fake FTDI FT232??
« Reply #410 on: October 23, 2014, 02:27:51 pm »
Franky i don't understand why the counterfeiters don't just release their own driver and separately Id the chip,.........

Frankly speaking, and call me a bigot if you need, but many Chinese manufacturers operate on cloning for cost reduction and not innovation. They're essentially not setup or tooled for that kind of software dev, they look for easy ways to make money with surprisingly old tech. A few state-funded reverse engineering labs are setup to break down "important" parts (which is why the US has such a raging hard-on for ITAR) and then passes along "State interest" parts for production. In the mean time of lulls, different operations use these facilities to reverse engineer various other devices from TI, LTC, ADI, etc. The key, for them, is to get "good enough" to copy-cat higher dollar devices, and then the gap is pure profit with essentially zero R&D costs (again, the state RE labs are usually a different bucket).

What I expect to see, honestly, is a slight change to the clones which inhibit the write, and then FTDI is back to square one, with a large consumer base that is FTDI phobic. Any man can create a lock which he himself cannot pick.
 

Offline FPGAcrazy

  • Contributor
  • Posts: 17
Re: FTDI driver kills fake FTDI FT232??
« Reply #411 on: October 23, 2014, 02:31:32 pm »
Quote
FTDI doesn't have to guarantee that there code works with chips of someone else. Many manufactors warn for non-functioning equipment when their drivers are used with products, which are not produced by them. 

If I wrote a virus which was piggybacked along with another piece of software, and it completely takes out your computer; wipes your bios (attempting to flash and re-flash it to the point of exhausting the write-life), knocks out your boot sector, and deletes your windows folder, then claim "if you didn't want that to happen, you shouldn't have run my software on any machine but ones I sell" would you say that's just fine and legal?

How would you detect that I am using the machine you sell?

The problem is that FTDI is writting and maintaining the driver, while other manufactors use it without paying them.  So they search for a ways of preventing you to use it with the cheap rip off. Because the persons making the rip off are too lazy to:
1. Write the code themself or not capable
2. To pay the costs involved with validation of the USB device.

So FTDI comes up with a method of detecting that it is counterfeit, However, this damages the fake product.
Keep in mind that this is not a virus. It does not go out and find all fake FTDI chips and destroys them.
Your product does that. Why should I use your software with another PC.

Also another importanted question is always how to pay the rent. FTDI needs to pay it employees and it can only do that when other people do not sell reproductions/copies of there product.

I understand you feel  very strongly about this. But in the end a company must make a profit to stay alive.
Which it only can when it is selling product.


 

Offline Simon

  • Global Moderator
  • *****
  • Posts: 17728
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: FTDI driver kills fake FTDI FT232??
« Reply #412 on: October 23, 2014, 02:34:26 pm »
err surely they had to spend time reverse engineering an FTDI then making something to "look" like it. They could have done what the arduino did and just programmed an MCU with a usb and serial port to work as a converter or made their own ASIC

Yes china is essentially the photocopier of the world, and before people get indignant about that statement, i used to work for a guy that wanted to import clothes from china, we kept asking for catalogs and all we got back was: you send us a sample, we copy it and send it to you if your happy you tell us how many you want. They openly declared to not have any clothes of their own design.
 

Offline XFDDesign

  • Frequent Contributor
  • **
  • Posts: 442
  • Country: us
Re: FTDI driver kills fake FTDI FT232??
« Reply #413 on: October 23, 2014, 02:38:37 pm »
Quote
FTDI doesn't have to guarantee that there code works with chips of someone else. Many manufactors warn for non-functioning equipment when their drivers are used with products, which are not produced by them. 

If I wrote a virus which was piggybacked along with another piece of software, and it completely takes out your computer; wipes your bios (attempting to flash and re-flash it to the point of exhausting the write-life), knocks out your boot sector, and deletes your windows folder, then claim "if you didn't want that to happen, you shouldn't have run my software on any machine but ones I sell" would you say that's just fine and legal?

How would you detect that I am using the machine you sell?


In this case, I don't have to on the grounds that my machine is not subject to "suffering" from my code's actions. So, again, would you say this is just fine and legal?
 

Offline XFDDesign

  • Frequent Contributor
  • **
  • Posts: 442
  • Country: us
Re: FTDI driver kills fake FTDI FT232??
« Reply #414 on: October 23, 2014, 02:41:56 pm »
err surely they had to spend time reverse engineering an FTDI then making something to "look" like it. They could have done what the arduino did and just programmed an MCU with a usb and serial port to work as a converter or made their own ASIC

From my limited understanding, this is exactly what the SupeReal device is, only it hooks into the FTDI interface on Windows PCs.

I wonder if the AVR CDC implementations can be sufficient substitutes for the FTDI devices....?
 

Offline Simon

  • Global Moderator
  • *****
  • Posts: 17728
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: FTDI driver kills fake FTDI FT232??
« Reply #415 on: October 23, 2014, 02:44:14 pm »
I don't understand all the protocol business but if the chip works and has a driver and conforms to the standards who cares how it is achieved.

I'm assuming the cheapest methos for mass production is an ASIC or maybe programming an existing uC is cheaper.
 

Offline Richard Crowley

  • Super Contributor
  • ***
  • Posts: 4317
  • Country: us
  • KJ7YLK
Re: FTDI driver kills fake FTDI FT232??
« Reply #416 on: October 23, 2014, 02:45:22 pm »
So FTDI comes up with a method of detecting that it is counterfeit, However, this damages the fake product.
Keep in mind that this is not a virus. It does not go out and find all fake FTDI chips and destroys them.
This seems like that old favorite: "plausible deniability".
 

Offline krater

  • Regular Contributor
  • *
  • Posts: 60
  • Country: de
Re: FTDI driver kills fake FTDI FT232??
« Reply #417 on: October 23, 2014, 02:46:10 pm »
Franky i don't understand why the counterfeiters don't just release their own driver and separately Id the chip, i mean having to accept "non signed" windows drivers is not something that has stopped major manufacturers and software houses.

Do you tried that on a Win7 x64 system ? Good Luck...
"it was working yesterday.  hmmm.  maybe the vendor FTDI'd me via a windows update..."
 

Offline FPGAcrazy

  • Contributor
  • Posts: 17
Re: FTDI driver kills fake FTDI FT232??
« Reply #418 on: October 23, 2014, 02:46:32 pm »
Quote
FTDI doesn't have to guarantee that there code works with chips of someone else. Many manufactors warn for non-functioning equipment when their drivers are used with products, which are not produced by them. 

If I wrote a virus which was piggybacked along with another piece of software, and it completely takes out your computer; wipes your bios (attempting to flash and re-flash it to the point of exhausting the write-life), knocks out your boot sector, and deletes your windows folder, then claim "if you didn't want that to happen, you shouldn't have run my software on any machine but ones I sell" would you say that's just fine and legal?

How would you detect that I am using the machine you sell?


In this case, I don't have to on the grounds that my machine is not subject to "suffering" from my code's actions. So, again, would you say this is just fine and legal?

Using a virus is never legal. That is very clear. Have to admit that I still do not understand what you try to prove/say here, sorry! Not a native english speaker.
However, if I made a PC which was similar in all functions to yours and adviced people to use a copy of your software. A copy of your software is provided on your webside for people who use your PC. What would you think of this? This is basically what happens to FTDI!
 

Offline Simon

  • Global Moderator
  • *****
  • Posts: 17728
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: FTDI driver kills fake FTDI FT232??
« Reply #419 on: October 23, 2014, 02:47:28 pm »
Franky i don't understand why the counterfeiters don't just release their own driver and separately Id the chip, i mean having to accept "non signed" windows drivers is not something that has stopped major manufacturers and software houses.

Do you tried that on a Win7 x64 system ? Good Luck...

I have windows 7 64bit, any cheap peice of hardware generally comes with a non signed driver that i have to accept.
 

Offline FPGAcrazy

  • Contributor
  • Posts: 17
Re: FTDI driver kills fake FTDI FT232??
« Reply #420 on: October 23, 2014, 02:55:23 pm »
So FTDI comes up with a method of detecting that it is counterfeit, However, this damages the fake product.
Keep in mind that this is not a virus. It does not go out and find all fake FTDI chips and destroys them.
This seems like that old favorite: "plausible deniability".
Yes, that is true.

But I asked this question before. I do not know if FTDI had an another method of detecting the clone.
Because they are basically very good. I understand from this forum that many people use them without knowing. And printing FTDI on a counterfeit IC makes it even harder. FTDI did not make an open standard with a fixed VID and PID that can be used by a default driver. They do not maintain a driver for a product type, but only for their own device. P.s. I beleive it is a little bit more complex than only the VID/PID for selecting a device group like a keyboard etc.
 

Offline uski

  • Frequent Contributor
  • **
  • Posts: 295
  • Country: us
Re: FTDI driver kills fake FTDI FT232??
« Reply #421 on: October 23, 2014, 03:02:26 pm »
But I asked this question before. I do not know if FTDI had an another method of detecting the clone.
Because they are basically very good. I understand from this forum that many people use them without knowing. And printing FTDI on a counterfeit IC makes it even harder. FTDI did not make an open standard with a fixed VID and PID that can be used by a default driver. They do not maintain a driver for a product type, but only for their own device. P.s. I beleive it is a little bit more complex than only the VID/PID for selecting a device group like a keyboard etc.

They could have shown a messagebox to the end-user (or refuse to start the driver) and revert the PID back to what it was instead of leaving it zeroed out. It's easy, they could just have checked if the write has worked by reading the EEPROM back and if yes, refuse to start the driver and rewrite the original PID. It's probably only 10 more lines of code in the driver.

They intentionally break the clones and they could have done it another way. This is reckless.
 

Offline krater

  • Regular Contributor
  • *
  • Posts: 60
  • Country: de
Re: FTDI driver kills fake FTDI FT232??
« Reply #422 on: October 23, 2014, 03:04:33 pm »
Franky i don't understand why the counterfeiters don't just release their own driver and separately Id the chip, i mean having to accept "non signed" windows drivers is not something that has stopped major manufacturers and software houses.

Do you tried that on a Win7 x64 system ? Good Luck...

I have windows 7 64bit, any cheap peice of hardware generally comes with a non signed driver that i have to accept.

Aeehm, my computer runs in the testsigning mode, so I can run my self compiled (and self signed) driver. A driver without signature will not run even there. Maybee you accept the "not microsoft compliant" message. But not signed drivers will not run anymore in win7 64.

see here for more info:https://www.raymond.cc/blog/loading-unsigned-drivers-in-windows-7-and-vista-64-bit-x64/
"it was working yesterday.  hmmm.  maybe the vendor FTDI'd me via a windows update..."
 

Offline Simon

  • Global Moderator
  • *****
  • Posts: 17728
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: FTDI driver kills fake FTDI FT232??
« Reply #423 on: October 23, 2014, 03:05:31 pm »
But I asked this question before. I do not know if FTDI had an another method of detecting the clone.
Because they are basically very good. I understand from this forum that many people use them without knowing. And printing FTDI on a counterfeit IC makes it even harder. FTDI did not make an open standard with a fixed VID and PID that can be used by a default driver. They do not maintain a driver for a product type, but only for their own device. P.s. I beleive it is a little bit more complex than only the VID/PID for selecting a device group like a keyboard etc.

They could have shown a messagebox to the end-user (or refuse to start the driver) and revert the PID back to what it was instead of leaving it zeroed out. It's easy, they could just have checked if the write has worked by reading the EEPROM back and if yes, refuse to start the driver and rewrite the original PID. It's probably only 10 more lines of code in the driver.

They intentionally break the clones and they could have done it another way. This is reckless.

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.
 

Offline marcan

  • Regular Contributor
  • *
  • Posts: 80
  • If it ain't broke I'll fix it anyway.
    • My blog
Re: FTDI driver kills fake FTDI FT232??
« Reply #424 on: October 23, 2014, 03:08:33 pm »
The question here is, is it possible for FTDI to detect if the chip is counterfeit in another way?
I do not think so! They probably spend a lot of time figuring this method out.
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.

FTDI doesn't have to guarantee that there code works with chips of someone else. Many manufactors warn for non-functioning equipment when their drivers are used with products, which are not produced by them.
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.

Actually they just erase the product id. That is all you can easy reprogram it.
Linux still won't load the driver. That's still causing deliberate damage, even if it's reversible.

I mean that counterfeit IC cann't be used for now with the new drivers.
Hence, don't work. It's a negative state of affairs, particularly for the owners of said devices.

No, they are not. They do not pass the new test system to detect if they are a clone. Therefor they are not compatible. Many PC compatibles in the 80 where also not  compatible.
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.

No, these ID's are used to assign a driver to the chip through the INF file. For instance in the PCI system if you chose to use 8086 as vendor id and 8259 as product ID I am sure you end up with a non functioning PC.
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.

The same applies also for the USB. This is the only way for the OS/BIOS/EFI to detect new hardware and assign the right driver. They should be unique ID's. You pay $5000 so that you are ensured they are unique.
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.

Try assigning some random numbers to your USB devices and see what happens on Linux also. You need a VID and PID and the system works by uniqueness of these numbers.
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.

It is the responsibility from the manufactor to check their sources.
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.

I think here in the Netherlands you can leave it behind on the airport and may be lucky when you do not get a fine.
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...

P.s. How many non-functioning devices you got?
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.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf