FTDI driver kills fake FTDI FT232??

[a210210200]

The contradiction is in your example. I adjusted the example to be more valid but you don't seem to be reading those posts and are as a result getting confused because your internal state isn't updated correctly.

The device does work vs. an engine that does not. Your example is invalid in its very premise. The device appears in windows, can be configured, is electrically still functional, ... (As in the engine which in your example which is the chip still works)

For all intensive purposes the only missing bit is the readme saying PID 0000 = counterfeit, tough luck and the user is now aware the device still works it is just a fake.

Your ignoring the fact the contradiction is with your example at which point I modified it to correct it and then you say I'm contradicting myself when it is in fact just you that are confused.

The device still works windows still detects it as (FTDI Vendor Detect, Unknown device which is true in every respect) and it does not require physical replacement of a 2 dollar bearing/component to bypass.

I don't understand how it can be classified as killed/broken/damaged in any way because it isn't.

If you're rewriting the question in order to answer it how you wish, then you're not answering the question or the issue. Yet again, you say here,

The device does work vs. an engine that does not.

and only a few posts earlier,

The engine does run which is the problem with your example and where the miles apart is.

so have no consistency. None. Zero.

Every single utterance you're putting to the keyboard, is attempting to evade the basic reality that the device, for all intents and purposes to the end user, is dead. You are unable to refute this. Everything else you're spewing is aimless evasion to what you've now already admitted. The device, for the end user after FTDI had their way with it, does not work. Period. That's it. It's fixable to the person who has the know-how and the tools, and for everyone else, it's no different than a brick. QED.

If a question is flawed like asking if the users expectations are the same thing as what the intention of the driver is then yes I will automatically correct it.

Device does work vs. the engine in your example doesn't that is the contradiction that is automatically fixed as well.

Your example states that the engine which is the chip doesn't work (it is physically broken) which is completely factually incorrect.

So there it is spelled out for you. The fake chip is undamaged, still functions, and when linux updates the drivers and people here write a workaround you can use fake chips all you like. It is just not going to be automatic and plug-in play install but that isn't a legal obligation FTDI has to a fake chip. PID 0000 is a non-issue and does no damage.

The basic reality is the device works but the driver does not want to talk to it and that is intended. The user may not expect that to happen and should go after the seller and so on so that the fake chips can be rooted out.

The device works and your just trying to use words to get around that fact when I in fact just forced a PID of 0000 onto a real FTDI chip and it works fine. (not with the VCP driver of course but there are countless other ways of using the product) The fake chip works fine as well with a 0000 PID and drivers/3rd party workarounds are already out there and that is it. It still works just FTDI doesn't want you using their driver but with a third party bypass you can do that as well.

It isn't physically broken or even non-functional that is the core problem with your engine example.

[Nerull]

The driver is not the product or the chip.

Irrelevant. They modify the device.

The driver has nothing that says it is guaranteed to work with fake chips.

Irrelevant. They modify the device.

The device still works the driver doesn't want to talk to it.

But would have done so before the device was modified

The device can and shortly will work even on Linux and windows once third party drivers are written. It is just that you can no longer use windows WHQL and FTDI signed drivers automatically.

Which doesn't change the fact that they modified a device to prevent it from functioning normally. That someone found a workaround does not remove the intent. None of this squabbling would hold up in court. You can't just modify someone elses property because you don't like what its doing, even if you handwave the modification as not a big deal because they can always fix it.

FTDI has every right to do whatever they want *within their driver*. When they start messing with the device - with they do not own, control, or have rights to - with the intent to prevent it from functioning, no matter how easy it is to circumvent, they step outside the bounds of what they are legally permitted to do.

[joshhunsaker]

The device does work otherwise it won't enumerate with the operating system. The board can still send data to the chip and it will still send the data back upto the computer. The device works just fine.

Oh yeah, I get it.  Kind of like how I can push the gas pedal down in a car with fouled spark plugs and flood the engine with gas.  It just doesn't enumerate with the crankshaft into an actual rotary motion.

[a210210200]

The driver is not the product or the chip.

Irrelevant. They modify the device.

The driver has nothing that says it is guaranteed to work with fake chips.

Irrelevant. They modify the device.

The device still works the driver doesn't want to talk to it.

But would have done so before the device was modified

The device can and shortly will work even on Linux and windows once third party drivers are written. It is just that you can no longer use windows WHQL and FTDI signed drivers automatically.

Which doesn't change the fact that they modified a device to prevent it from functioning normally. That someone found a workaround does not remove the intent. None of this squabbling would hold up in court. You can't just modify someone elses property because you don't like what its doing, even if you handwave the modification as not a big deal because they can always fix it.

FTDI has every right to do whatever they want *within their driver*. When they start messing with the device - with they do not own, control, or have rights to - with the intent to prevent it from functioning, no matter how easy it is to circumvent, they step outside the bounds of what they are legally permitted to do.

The driver is what is not working is the issue. So highly relevant.

A driver in the course of normal operation modify the device on enumeration if some IP protection measure is part of the routine even if new then that is also normal/intended. (FTDI is just horrible PR) I'm sure HASP does this as well and probably will physically try to render a chip actually inoperable if it detects counterfeit license keys. (emulation is joke though and you can't damage a virtual key).

Modifying the device is part of the API and a PID 0000 is an accurate description of the fake device. (A change list could say, Fake/counterfeit chips will be updated to a PID of 0000 to match the unknown device)

The past drivers are not using the latest code so may allow fake chips to operate and modifying the PID ensures backwards (in)compatibility with the latest intended functionality of the driver.

The simple fact is that this is all really just about the driver not any damage being done to the fake chips. There is no obligation for the windows FTDI driver to ever work with fake chips if FTDI got tricky they could even get Microsoft to blacklist the old keys so you get very dire warnings above even unsigned driver ones if you try to install old drivers which is probably completely legal. Linux will probably automatically enumerate PID 0000 chips when they update and counterfeiters will just hard code the bypass into updated chips.

The driver is the hardware interface control layer so certainly manipulation of the hardware is exactly what it is supposed to be doing. Automatic re-programming is just a new "feature" which works as intended so to speak and is there poor way of telling people that the chip is fake since it should be in big bold letters in the readme, download link, and the driver should be an installer instead of a compact silent one so the warning is abundantly clear.

I think FTDI could have communicated it far better than what they did but in no way is the device killed. If they re-programmed the chip to make it actually die then I would agree with you because that would be unauthorized damage which would be intentional on FTDI's part. The PID/VID values are mutable and are supposed to be hardware descriptors and a PID of 0000 is technically correct since the product is unknown and nothing is broken. (The old drivers are working as intended just as the new driver is working as intended one just as a IP protection "feature")

[a210210200]

The device does work otherwise it won't enumerate with the operating system. The board can still send data to the chip and it will still send the data back upto the computer. The device works just fine.

Oh yeah, I get it.  Kind of like how I can push the gas pedal down in a car with fouled spark plugs and flood the engine with gas.  It just doesn't enumerate with the crankshaft into an actual rotary motion.

If your engine did not enumerate the crankshaft then there would be no motion possible as it wouldn't "exist". The device does still enumerate and is electrically/physically/software still working.

Also cars use ECUs now and I'm sure if you tried messing around with that poorly the car could very well say nope check engine light and the ECU is faulty/defective/fake. (Or it could explode but that would be mean/illegal/deadly/bad design)

The fake chips work properly and is just no longer plug and play and have a correct PID of unknown. Bypassing this is simple and on Linux probably possible to be automatic, a broken spark plug requires physical replacement and if you have direct injection fouled cylinders are even worse.

[a210210200]

That's a fair point.  But the chances of an unintended FTDI fake substitution are probably higher than others.  Until now - that didn't carry unnecessary additional risk that it might work fine (pass all testing) and get passed onto the customers where it could be e-firebombed without warning.

So basically what I said - your are prepared to take the risk of shipping crap built with fake parts but the risk of being found out when you do tips the balance and steers you towards parts which are less likely to be shown to be fakes.

In the future I will be taking the use of FTDI parts as an indication of a supplier who cares about the quality of their products and has confidence in their supply chain.

B. To use a part with blind optimism that your supply chain can't possibly screw up is equivalent to playing Russian roulette.  I'd prefer to use the products from a company who is proactive about increasing reliability through thoughtful design and part selection.  You're saying I should add risk to an extremely critical system just to demonstrate my confidence in 3 or 4 layers of supply chain removed from our company?  No thanks.

You mean the added risk of being found out when you ship product built with fakes. So again what I said - I will have more confidence in a company who have enough confidence in their supply chain to consider that added risk insignificant. If two companies tell me a gun is unloaded I will believe the one prepared to play Russian roulette with it.

Also if a shoe string university lab can do basic QC/QA on chips students get for random projects I would not trust a company that doesn't at least periodically check their stock for fakes by sending samples to a lab. It is probably true a product that used to ship with FTDI chips suddenly switching to another brand may be an indication that they don't actually have much confidence and definitely don't do direct verification. A site like Sparkfun says they check their own stuff and it all works fine no fakes (they did catch a fake micro before though) and they are going over third party products as well. Making a perfect physical clone is difficult small minor differences in the finish, metal, color, markings can be a dead giveaway if you compare the chips with other sources (I do have a microscope but even with a magnifying glass you can look closely). Checking the erratum for accuracy can even be automated to make sure it matches the rev you expect. And if for some reason the erratum is different or many don't apply for some reason that would be automatically suspicious.

I actually found out that you can delid things safely and rapidly with a small creme brulee torch (~less than 20$) so its easy/cheap to verify chips visually at least even without the "proper" acid method. I took the dies out of a old broken OCZ flash drive to go image on a microscope using such a method. (Just do it outside as the fumes are that magic smoke which is the encapsulate as your going to burn off the entire package basically) Also make sure your holding the torch parallel/at a non-direct face manner to the die to drive the residue off as it burns.

With that said you can collect die images and use it as a method to detect fakes directly or at least make it so that they have to be basically identical.

[Rufus]

FTDI has every right to do whatever they want *within their driver*. When they start messing with the device - with they do not own, control, or have rights to - with the intent to prevent it from functioning,

Their intent and the actual result was to prevent the device indicating to the operating system that it should load FTDI drivers which are not licensed for use with that device. The device remains as functional as it ever was if you provide drivers for example by plugging it into a Linux box.

[a210210200]

I just got an idea. I'm going to delid an FTDI chip right now. Hold on I'm going to play with fire.

[Someone]

FTDI has every right to do whatever they want *within their driver*. When they start messing with the device - with they do not own, control, or have rights to - with the intent to prevent it from functioning,

Their intent and the actual result was to prevent the device indicating to the operating system that it should load FTDI drivers which are not licensed for use with that device. The device remains as functional as it ever was if you provide drivers for example by plugging it into a Linux box.

Yep, the windows driver is provided to the user with a licence requiring it to be used with their hardware. They decided to start enforcing that requirement with a lasting but not damaging technique to prevent the clone devices from working with the software, it still works just not with the licensed software.

People taking issue with Microsoft and FTDI wanting to protect the underlying USB compatibility is hilarious, PID/VID codes match software to hardware, its not an end to end API that FTDI are providing for use.

[Rufus]

lasting but not damaging technique to prevent the clone devices from working with the software, it still works just not with the licensed software.

It is slightly worse than that because I believe Win 7 and 8 somehow don't like devices with zero PIDs. Maybe Win 7/8 knows there will be no drivers for a zero PID without even bothering to check. Not that it makes any practical difference because there are no other drivers for Windows.

[a210210200]

I just got an idea. I'm going to delid an FTDI chip right now. Hold on I'm going to play with fire.

Done, not at work right now so I just used an ancient HP scanjet which I really doubt actually has 2400DPI of actual resolution. Also the scan plate glass is a bit cloudy and so is the sensor I think not sure why its really old. It also appears to be out of focus for some reason (I may or may not have dropped it in the past).



Note that I burnt it a bit too long (overcooked) as I didn't realize the die was so thick and their package is much more flame resistant than OCZs.

[all_repair]

Now FTDI is sending in trolls to kill this thread.  Way to go FTDI.  They can't be that stupid !!!! 
 @Dave, they likely to hack your server and they can print their license to kill as they want.

[pickle9000]

So I wonder how many young (pre-engineers) will remember this in 5 years. Next year or month when a product is up for redesign will the designer think twice about using any FTDI product. Will it become a topic that has staying power in the lab? There are always other choices when it comes to 99.9 percent of the chips out there.

I'm thinking about the FTDI brand in particular not this particular chip, their legal right, and so on. The brand will suffer but how much is the question. 

[CaptCrash]

edit: Post above says basically the same thing.  Posted whilst I was typing.

For all of the people claiming that the cloned chips are illegal, how do you know that all of the chips affected are actually counterfeit and not legitimate clones?

Dealing with clones
From the information presented so far in this thread, the cloning of chips is legal.
So if you produce a clone product without reverse engineering and then either don't brand it, or, put your own brand on it everything is fine and dandy.
FTDI has no right to damage this chip, as doing so is anti-competitive and is illegal in various parts of the world.

The problem is that the FTDI driver cannot determine if the chip has a fake logo on it before it affects its operation.  Therefor FTDI have taken the position that clone products are fair game and FTDI are causing damage to someone else's product (the cloned chip).  This then causes damage to the end users legitimately purchased product (FTDI have not proved that its a counterfeit) and must be held to account for the costs of repairing the now damaged equipment.  Finally FTDI have not notified the end user of an issue, but rather just damaged the operation of the device.

As for the cloners using the FTDI VID/PID, this also is not illegal.
Its against the rules of an industry body, if your product has a USB certified logo on it or the documentation/packaging or makes various claims.
But if the product does not, then the cloners are not even breaking the rules.  They are simply making a clone device.

Dealing with counterfeits
Taking a clone chip and putting a fake FTDI logo on the chip makes it a counterfeit.
FTDI and the appropriate authorities should take action against this.
The vendors of the products, their suppliers etc should all be investigated and the appropriate punishments delivered.

Organisations like eBay, PayPal, Amazon and their various vendors should also be informed and refunds/replacements of the products delivered.  As the sale to the customer has involved a counterfeit product and a fraud has been perpetrated, the product warranty conditions and/or vendor returns rules would be difficult to enforce by the vendor in this situation.
Similarly the vendor needs to make a claim on their supplier and so on.

Given the current level of interest in this topic, it would be sensible for everyone people/companies affected to mass return these items and force the distribution channels for these counterfeit products to be held accountable.

Note: The only examples that I have personally seen did have the FTDI logo printed on them and therefor are counterfeit.  In both cases I have approached the vendors involved for a refund or replacement.  PayPal has been notified of the issue as well.  Neither has responded at this stage.

[nitro2k01]

So if you produce a clone product without reverse engineering and then either don't brand it, or, put your own brand on it everything is fine and dandy.

Has such a chip ever been found in the wild?

[CaptCrash]

So if you produce a clone product without reverse engineering and then either don't brand it, or, put your own brand on it everything is fine and dandy.

Has such a chip ever been found in the wild?

Not that I have seen.  I do have an unlabelled chip at home but its something entirely different and nothing to do with the discussion other than it prompted me to ask the question you have quoted above.

[C]

Simple question
I loan you my working USB to serial cable, did I receive back a cable that still works with my computer on the cable's return?
If NO, then you are responsible for the damage!

C 

[TheRevva]

I've finally finished working through all my devices that could possibly have included a USB->Serial convertor inside them.
I managed to find 28 of them of which 15 had FTDI convertors in them.  (The rest were predominantly Arduino Mega2560 with the Atmel USB device)
Of those 15 devices, a whopping 9 proved to be contain FTDI chips (all of which were FT232R).

I'm pleased to announce that each of those 9 devices has now been 'consigned to the bin', but not before I had some fun.
First step was to reprogram the VID/PID such that they enumerated as a Micro$oft keyboard.  For some weird reason, I was unable to find the 'ANY' key?
Second step was to switch them over to use the (non-existent) external oscillator.

I've chosen to apply a 'collective name' to all 9 devices... "PHIL"...  (As in 'Land-Phil')

Needless to say, I will never again knowingly use a device with a genune FTDI chip in it.

Rest-In-Pieces FTDI (aka F**k The Devices Internally)

[a210210200]

FTDI has every right to do whatever they want *within their driver*. When they start messing with the device - with they do not own, control, or have rights to - with the intent to prevent it from functioning,

Their intent and the actual result was to prevent the device indicating to the operating system that it should load FTDI drivers which are not licensed for use with that device. The device remains as functional as it ever was if you provide drivers for example by plugging it into a Linux box.

Yep, the windows driver is provided to the user with a licence requiring it to be used with their hardware. They decided to start enforcing that requirement with a lasting but not damaging technique to prevent the clone devices from working with the software, it still works just not with the licensed software.

People taking issue with Microsoft and FTDI wanting to protect the underlying USB compatibility is hilarious, PID/VID codes match software to hardware, its not an end to end API that FTDI are providing for use.

ONE MORE TIME for those of you that are a little thick-headed:

FTDI does *NOT* "OWN" the VID/PID associated with this device.  ANYONE can use the *same* VID/PID if they want to with *NO* legal repercussions.  It is perfectly *legal* for a company to make a "clone" [i.e. "works alike"] device that has the same VID/PID as the FTDI device.

It is unethical, illegal, and a "tort" for FTDI to maliciously and willfully [with forethought] modify and/or damage someone else's property without their permission.

FTDI broke the law.  FTDI left themselves open to a class action lawsuit.  FTDI gave themselves a "black eye".  FDTI decision makers that approved these actions are *IDIOTS*, and they should be FIRED.  Even the CEO can be fired by the board of directors.  Heads will roll.  This will be remembered by every design engineer that needs a USB-serial chip for their design.  This will cost FTDI dearly, and that is if the company survives at all.

IN ADDITION:  Let's talk semantics.  A "work alike clone" is *not* illegal unless the company making it tries to pass it off as a chip made by FTDI.  There is no way for the driver to know if there is trademark infringement on the chip's package-- and so the driver just may well "brick" a legal, legitimately owned "clone" as well as a "counterfeit" part.  It is illegal for FTDI to knowingly and willfully modify the PID and/or VID of a device that they don't own-- PERIOD.

Technically if someone managed to get a WHQL driver through or trick people into installing a conflict works with everything "driver" that would be quite damaging for everyone. For the sake of continued usability of USB devices in general abusing the VID/PID system is a very bad idea the next thing you'll get is the requirement to get a private key signed by USB-IF to stop such abuse and they will call it "secure USB". In light of that honor system to VID/PIDs people should not write fake values for devices as this can easily cause everyone problems.

The driver has FTDI's trademark on it and even is for the most part signed with their own digital signature so you know for a fact it is FTDI's official driver which by faking the VID/PID number the counterfeiter essential even if physically unmarked on the chip have branded your device as an FTDI original. Courts look at the simple matter at hand FTDI's driver is for real FTDI chips, faking that means breaking trademarks. For copyright law it just matters how it visually appears to users and if they can't see the chip label visually the official signed driver saying this is a FTDI FT23XX chip is as good as any label. Now if you use that latest driver FTDI's driver it correctly identifies a non-FTDI chip and gives it a correct label of an unknown device that claims to be an FTDI chip.

It would be like AMD faking IDs to trick intel's tools into identifying it as an Intel chip which would be a breach of trademark (digitally) even if AMD has a x86 compatible, supports all the extensions, in software it works properly just on board its an AMD branded or unbraded chip. I'm sure Intel has a ton of anti-counterfeiting stuff going on so doing so won't be as simple as faking a VID/PID combo but courts don't really care about that bit.

Your case would be more valid if FTDI went looking for knockoffs regardless of their VID/PID combination.

"When the alleged infringer and the trademark owner deal in competing goods or services, the court rarely needs to look beyond the mark itself; infringement will usually be found if the two marks at issue are sufficiently similar that consumer confusion can be expected."

Consumers are confused the fake FTDI chips act as if they are real ones to the driver in windows the mfg label says (FTDI) and the driver says it is a real FT chip. The user has committed no crime but the counterfeiter has. A pin compatible clone like other have mentioned from real legitimate companies do not advertise that they work with FTDI signed VCP drivers and one listed in this very thread doesn't seem to even come with any software and other similar ones come with their own VCP drivers. Emulating the physical chip is fine but faking information to trick the driver into running with it and displaying FTDI's trademarked stuff isn't.

Simple fact is that the chips are fake and should get their own driver. This obviously will make devices not work with FTDI's drivers but this isn't illegal in any sense, changing the PID to 0000 is the first step in allowing a 3rd party driver to pick up the pieces as having a conflict VID/PID driver is a very bad idea even if not illegal so them having a different PID is expected.

[a210210200]

So if you produce a clone product without reverse engineering and then either don't brand it, or, put your own brand on it everything is fine and dandy.

Has such a chip ever been found in the wild?

Not that I have seen.  I do have an unlabelled chip at home but its something entirely different and nothing to do with the discussion other than it prompted me to ask the question you have quoted above.

To remain unbranded you also have to use unbranded software. Faking information to make it show up as an official FTDI chip is going to appear visually that it is official FTDI FT series chips. I don't see any problem with a pin compatible, API emulating chip that has no FTDI branding and doesn't use their driver clone the function but don't rip off the entire thing. (Copying the actual die exactly would also be illegal as would "re-branding" the official driver)

Lets put it this way Google emulated Oracle IP very well but did it cleanroom style so very little meaningful infringement. FTDI's competitors are perfectly allowed to do the same thing functionally speaking just with their own work.

[a210210200]

Simple question
I loan you my working USB to serial cable, did I receive back a cable that still works with my computer on the cable's return?
If NO, then you are responsible for the damage!

C

Your cable works fine. The official driver just is upset with the fake chip. Use a third party driver and your good to go. FTDI trademark is all over their driver so 3rd party would  be the legit way to do it.

I'd personally just say you have a fake cable and I replaced the chip/cable with a real one (i have a mountain of chips for students) for you and ask you where you bought it from and report them for you. You get value add if you loan me stuff, quality control inspection, free rework, debug, I really like opening/inspecting hardware even if it costs thousands/millions (even more so). My own stuff I don't treat so nicely, failed OCZ drive mangled some of my documents (set it on fire) test results indicate the chips are not UL94-V0 type packages. Drive was later subjected to corrosion testing in concentrated household bleach, maybe I'll throw it in the acid waste for good measure at work after triple rinsing of course. (Also securely erased, digitally and physically)

[Rufus]

Of those 15 devices, a whopping 9 proved to be contain FTDI chips (all of which were FT232R).

I'm pleased to announce that each of those 9 devices has now been 'consigned to the bin', but not before I had some fun.

And how does your face look without a nose?

.
.
.
.
.
.
If you need it explaining  http://en.wikipedia.org/wiki/Cutting_off_the_nose_to_spite_the_face

[a210210200]

Of those 15 devices, a whopping 9 proved to be contain FTDI chips (all of which were FT232R).

I'm pleased to announce that each of those 9 devices has now been 'consigned to the bin', but not before I had some fun.

And how does your face look without a nose?

.
.
.
.
.
.
If you need it explaining  http://en.wikipedia.org/wiki/Cutting_off_the_nose_to_spite_the_face

Adding onto that,

Why not just put a pin compatible FTDI chip into them and give FTDI the finger twice over considering some of the equipment I have is so old there is no replacement and some of it is so expensive an unique that trashing them because you don't like the mfg is like saying eew not a San Ace fan and trashing a perfectly good power supply which is trivial to replace the fan with your own. Or if you want to really say screw you FTDI go use obviously fake FTDI chips exclusively and apply the driver detection bypass on your hardware so they all still work with FTDI's latest driver even with their detection.

In any case I hope your recycling those electronics properly.

[f4eru]

Just Boycott FTDI.

[a210210200]

...

Hey now you are free to do whatever you want with your designs. I have no employment or affiliation with FTDI other than using their chips as you have in previous designs. Keep it nice and friendly please accusing people of being a plant is baseless and "yelling" isn't helping your statements.

The driver is copyrighted and trademarked and abusing the not illegal to abuse PID/VID system to trick a driver is the same kind of argument that Google tried with but the people's wifi's were not encrypted so I copied their data because that was so easy it doesn't count an invasion of privacy. To a user the fake chip appears branded as an FTDI official device as the driver reports it which then infringes on the trademark.

Other mfg with competing chips and even pin compatible ones do not use FTDI's drivers simple fact of the matter. See Google copied Oracles API but they did it themselves and used something called cleanroom development so very little meaningful copying happened in that case (which is legal, in my opinion) but if Google just copied directly then thats worse. Even worse would be if AMD tricked intel's tools into saying a physically marked AMD chip is an genuine intel chip because they found out that intel just uses a trivial id check that is definitely not going to be legal.

(Edit: Here is an explanation of legal copyright/trademark evasion via clean room development, https://en.wikipedia.org/wiki/Clean_room_design , it of course doesn't work on patents, heck even more direct reverse engineering is still legal but directly copying/re-purposing software in its entirety is not a best practice)

Fake chips can use their own third party drivers or user performed bypasses its pretty simple really. (Also these fake chips are they or are they not also physically branded FT parts which they probably are so what your talking about is a hypothetical while the reality is probably very different)(So trademark infringement is probably both digital and physical otherwise people would know its a fake and demand a very low price)

For an official FTDI tool to reprogram the PID use FT_PROG (http://www.minipwner.com/index.php/unbrickftdi000)
For a bypass use (not made by me)

Code: [Select]

#!/usr/bin/env python2
# FTDI Clone Tool v0.2 by @marcan42
# Licensed under the terms of the 2-clause BSD license, which follow:
#
# Copyright (c) 2014 Hector Martin <hector@marcansoft.com>
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions are met:
#
# 1. Redistributions of source code must retain the above copyright notice,
#    this list of conditions and the following disclaimer.
#
# 2. Redistributions in binary form must reproduce the above copyright notice,
#    this list of conditions and the following disclaimer in the documentation
#    and/or other materials provided with the distribution.
#
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
# DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
# SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
# CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
# OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

import sys, struct
try:
    import usb
except ImportError:
    print "Error: please install PyUSB. The package is called python-usb in Ubuntu."
    sys.exit(1)

def find_device():
    busses = usb.busses()
    found = 0
    for bus in busses:
        devices = bus.devices
        for dev in devices:
            if (dev.idVendor == 0x0403
                and dev.idProduct in (0x6001, 0x0000)
                and dev.deviceVersion.split(".")[0] == "06"):
                print "Found FTDI FT232R device (%04x:%04x)" % (dev.idVendor, dev.idProduct)
                found_dev = dev
                found += 1

    if found == 0:
        print "No devices found"
        sys.exit(1)
    if found > 1:
        print "More than one device found. Please connect only one FTDI device."
        sys.exit(1)
    return found_dev

class FTDIDevice(object):
    def __init__(self, usbdev):
        self.handle = usbdev.open()
        self.timeout = 100

    def unlock_eeprom(self):
        self.handle.controlMsg(requestType=0x40,
                               request=0x09,
                               value=0x77,
                               index=1,
                               buffer="",
                               timeout=self.timeout)

    def read_eeprom(self, addr):
        data = self.handle.controlMsg(requestType=0xc0,
                                      request=0x90,
                                      value=0,
                                      index=addr,
                                      buffer=2,
                                      timeout=self.timeout)
        assert len(data) == 2
        return data[0] | (data[1] << 8)

    def write_eeprom(self, addr, data):
        self.handle.controlMsg(requestType=0x40,
                               request=0x91,
                               value=data,
                               index=addr,
                               buffer="",
                               timeout=self.timeout)

    def calc_checksum(self, eeprom):
        check = 0xaaaa
        for i in eeprom[:0x3f]:
            check = check ^ i
            check = ((check << 1) | (check >> 15)) & 0xffff
        return check

    def forge_checksum(self, eeprom):
        check = 0xaaaa
        for i in eeprom[:0x3e]:
            check = check ^ i
            check = ((check << 1) | (check >> 15)) & 0xffff
        check ^= ((eeprom[0x3f] >> 1) | (eeprom[0x3f] << 15)) & 0xffff
        return check

def main():
    print "Detecting device..."
    dev = FTDIDevice(find_device())
    dev.unlock_eeprom()
    print "Reading EEPROM..."
    eeprom = [dev.read_eeprom(i) for i in range(0x40)]
    print "EEPROM contents:"
    for i in range(0, 0x40, 8):
        print "  " + " ".join("%04x" % j for j in eeprom[i:i+8])
    check = dev.calc_checksum(eeprom)
    checksum_correct = check == eeprom[0x3f]
    if checksum_correct:
        print "  EEPROM checksum: %04x (correct)" % eeprom[0x3f]
    else:
        print "  EEPROM checksum: %04x (incorrect, expected %04x)" % (eeprom[0x3f], check)

    print "Detecting clone chip..."
    old_value = eeprom[0x3e]
    print "  Current EEPROM value at 0x3e: %04x" % old_value
    new_value = (old_value + 1) & 0xffff
    print "  Writing value: %04x" % new_value
    dev.write_eeprom(0x3e, new_value)
    read_value = dev.read_eeprom(0x3e)
    print "  New EEPROM value at 0x3e: %04x" % read_value
    if read_value != old_value:
        print "  Reverting value: %04x" % old_value
        dev.write_eeprom(0x3e, old_value)

    if read_value == old_value:
        print "Chip is GENUINE or a more accurate clone. EEPROM write failed."
        print "Nothing else to do."
        return 0

    print '===================================================================='
    print 'Chip is a CLONE or not an FT232RL. EEPROM write succeeded.'

    if checksum_correct:
        if eeprom[2] == 0:
            print '===================================================================='
            print "Your device has a Product ID of 0, which likely means that it"
            print "has been bricked by FTDI's malicious Windows driver."
            print
            print "Do you want to fix this?"
            print " - Type YES (all caps) to continue."
            print " - Type anything else (or just press enter) to exit."
            ret = raw_input("> ")
            if ret != "YES":
                print "No changes made."
                return 0
            # Try to undo what the FTDI driver did. If it corrupted the value at
            # 0x3e (if it wasn't unused), this should fix it, assuming the
            # checksum at 0x3f is correct for the right value.
            eeprom[0x02] = 0x6001
            eeprom[0x3e] = dev.forge_checksum(eeprom)
            dev.write_eeprom(0x02, eeprom[0x02])
            dev.write_eeprom(0x3e, eeprom[0x3e])

            if eeprom[0x3e] == 0:
                print "Product ID restored to 0x6001. All changes made by FTDI's driver"
                print "have been reverted."
            else:
                print "Product ID restored to 0x6001. However, the value at 0x3e has not"
                print "been set to zero. Reasons why this may have happened:"
                print " - The PID was set to 0 by other means, not FTDI's driver."
                print " - The original PID was not 0x6001"
                print " - The PID was set to 0 by FTDI's driver, then fixed with"
                print "   another tool, then set to 0 again by FTDI's driver."
                print " - Your device has very long vendor/product/serial number strings,"
                print "   and FTDI's driver may have accidentally corrupted the last"
                print "   character. If this is the case, it has been restored."
                print " - You or your software have used the EEPROM's free/user area and"
                print "   FTDI's driver has corrupted the last word. If this is the case,"
                print "   it has been restored."
                print " - For some other reason the free area of your EEPROM was not"
                print "   filled with zeros."
                print "This is probably harmless, but you may want to take note."

            print "Press enter to continue."
            raw_input()

        print "===================================================================="
        print "Deliberately corrupting the checksum of your device\'s EEPROM will"
        print "protect it from being bricked by the malicious FTDI Windows driver,"
        print "while still functioning with said driver. However, if you do this,"
        print "ALL SETTINGS WILL REVERT TO DEFAULTS AND THE DEVICE SERIAL NUMBER"
        print "WILL NO LONGER BE VISIBLE. Most devices that use the FT232 as a"
        print "standard USB-serial converter will function with default settings,"
        print "though the LEDs on some converters might be inverted. Specialty"
        print "devices, devices which use bitbang mode, and devices which use"
        print "GPIOs or nonstandard control signal configurations may cease to"
        print "work properly. If you are NOT 100% certain that this is what you"
        print "want, please do not do this. YOU HAVE BEEN WARNED. You can revert"
        print "this change by using this tool again."
        print
        print " - Type CORRUPTME (all caps) to set an invalid EEPROM checksum."
        print " - Type anything else (or just press enter) to exit."
        ret = raw_input("> ")
        if ret != "CORRUPTME":
            print "EEPROM checksum left unchanged."
            return 0

        if eeprom[0x3f] == 0xdead:
            # Bad luck!
            dev.write_eeprom(0x3f, 0xbeef)
        else:
            dev.write_eeprom(0x3f, 0xdead)

        print "EEPROM checksum corrupted. Run this tool again to revert the change."
        print "Disconnect and reconnect your device for the changes to take effect."
        print "Press enter to exit."
        raw_input()
        return 0
    else:
        print "===================================================================="
        print "Your device has an incorrect EEPROM checksum, probably because you"
        print "ran this tool to do so, with the intent of protecting your device"
        print "from the malicious Windows driver."
        print
        print " - Type FIXME (all caps) to restore your EEPROM checksum."
        print " - Type anything else (or just press enter) to exit."
        ret = raw_input("> ")
        if ret != "FIXME":
            print "EEPROM checksum left unchanged."
            return 0

        dev.write_eeprom(0x3f, check)
        print "EEPROM checksum corrected. Disconnect and reconnect your device for"
        print "the changes to take effect. Press enter to exit."
        raw_input()

if __name__ == "__main__":
    sys.exit(main())