FTDI driver kills fake FTDI FT232??

[Macbeth]

From the perspective of a designer, FTDI has just introduced considerable risk in using their product.  That's all that matters to a designer.  "I might get burned if I use this part - even if I specify genuine parts."

You might get burned by fakes of unknown quality and origin regardless of which manufacturer they are faking.

You are saying that you will choose a part which is more likely to let you get away with shipping low quality shit - nice one, care to let us know what products we should be avoiding?

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.

LMFAO  Rufus, you really are a card. A Trollington McTroll with his very own Troll Bridge. But the joke is wearing thin now...

[a210210200]

The device is still working to the end user and does still enumerate in windows as an unknown device which is technically true. An inoperable engine physically will not work and you cannot just visit a website and press fix to make it work. There are miles apart in differences.

If FTDI did the re-config to never work actually again config then your example works. The fix is "simple" you just de-solder the chip and attach an external crystal to it. (That would be the situation where your example applies since it is now physically non-functional and in some cases may actually electrically fail)

So a car that does not run, is miles apart from a device which does not work? How is this, when neither perform as expected?

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.

The "engine"/device isn't broken if you want a car example your counterfeit ECU gets rejected and the engine is disabled and the car says unknown ecu installed. (You can bypass it easily with a software mod to trick the controller/drivers that do the detection but I doubt you would risk that when an ECU is basically like a FADEC just for the ICE instead of a gas turbine and you don't want to mess around with that)(I'm sure medical devices with FTDI chips know with 100% certainty that they have real chips)

The physically kill on detection of counterfeit example for the car would be upon detecting a fake ECU the car demands a damaging load to the engine and destroys the engine instantly. At which point you will need a lot of guides on rebuilding the engine and no amount of software is going to help you.

In one case the device is refused access while the other the devices dies in a fire. (One is truely easy to fix with software and the other is "simple" to fix by replacing the bearing(s), human(s)... or the component(s))

[Rufus]

If I am supposed to be the other guy I am not arguing that at all. Say X and Y make voltmeters and fakes of both are being manufactured in China. You have reason to doubt both of them because they might be fakes of unknown quality, specification and origin. Now company X says we can identify these fakes and instruct calibration labs to refuse calibration of them effectively turning them into bricks. The 'other' guy is arguing that he should buy Y in the future because if he did buy something that ought to be a brick he would prefer not to know about it.

I argue that preferring not to know something is a fake of unknown quality and origin is not an acceptable stance for a supplier of quality equipment and because X can and will brick fakes you are more likely to end up with a fake Y than a fake X.

In no part of this claim does it fit with the earlier premises of your post.

This is what I said in the post I think you are referring to.

You might get burned by fakes of unknown quality and origin regardless of which manufacturer they are faking.

You are saying that you will choose a part which is more likely to let you get away with shipping low quality shit - nice one, care to let us know what products we should be avoiding?

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.

I see no conflict between the things I said.

[XFDDesign]

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.

If the end user plugs in the device, does it operate as they expect or as intended? Yes, or no?

[XFDDesign]

I see no conflict between the things I said.

You're very welcome to answer to things other than the topic at hand, but for a discussion perhaps you wish to answer the questions presented to you?

[sunnyhighway]

I don't think windows likes unsigned drivers so it would be uprising if that was actually pushed out without a cryptographic signature.

Just look at this screenshot and look for the missing "Digital Signatures" tab.

[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.

If the end user plugs in the device, does it operate as they expect or as intended? Yes, or no?

No, it does not operate as the user expects and they should demand a refund and report the product.
Yes, it operates as intended fake products shouldn't work/be used/exist.

(Expectations of a real product means you should go after the seller and they too if they expected a real product should go after the next level) Its like saying did a fake ECU operate as intended the mfg would say yes it operates fine as it doesn't do anything when we detect it.

(If the buyer expects the real thing then they have been duped and so on until you get the counterfeiter or people who knew)


Throw it in the trash that is why I'd do upon finding that out or I'd rework in a real chip.

Heck I open non-openable power supplies to see the internal quality and parts if its fake then its into the garbage.

If cellphones could detect fake/bad power supplies and disable the USB charging that would be good as in the case of mains/line voltage stuff there is no messing around especially at 240V a fake product shouldn't work and should be disabled in software when possible. ( http://www.gizmodo.com.au/2014/06/please-dont-buy-cheap-phone-chargers-and-cables/ ) Low voltage USB cables don't really for safety but the mixed voltage mains adapter does.

Also your ignoring the whole die in a fire on fake detect vs. refusing to talk to a fake device.

[XFDDesign]

No, ...

But you just said that unlike the engine which does not run, this was "miles apart." So which is it?

[a210210200]

I don't think windows likes unsigned drivers so it would be uprising if that was actually pushed out without a cryptographic signature.

Just look at this screenshot and look for the missing "Digital Signatures" tab.

Strange indeed. I guess for WHQL only the package needs to be signed (the .cat file) which contains the hashes for the files. But since the older drivers have the .dll signed its unusual that the latest one isn't.

[a210210200]

No, ...

But you just said that unlike the engine which does not run, this was "miles apart." So which is it?

The engine does run which is the problem with your example and where the miles apart is. The fact the driver does not work with the fake is as intended and expected.

The consumer with their broken presumption of a real product should go after the producer and so on.

I don't presume anything I take it apart to find out so I would not be caught off guard, seriously fake garbage is garbage.

I said specifically that the device is electrically, physical, and even in firmware software working. The driver just refuses to talk to it and brands it with a "IT'S A FAAAKE" PID of 0000. Bypassing this is simple and it is not damaging the chip in any way.

[XFDDesign]

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

With a damaged bearing, it does not. It's blown. Non operational, which is consistent with everything else I've stated. You've now had to alter your original position "The engine does not run, the device does," to "The engine runs, the device does not." You're contradicting yourself, so again, which is it?

[f4eru]

Dave, I like your double facepalm, but here's a more appropriate one :

http://ptrace.fefe.de/fpalm30c3.jpg

( at the 30C3, fefe did this to dedicate to the worst thing this year)
Too bad it's alredy dedicated to apple for not giving the new HW to their SW developers berfore release : http://blog.fefe.de/?ts=aadb7a77

[a210210200]

No, ...

But you just said that unlike the engine which does not run, this was "miles apart." So which is it?

Your attempts at oversimplifying the example is crude at best.

An engine can be defined as a discrete physical part that can be defined as functional if when attached to a car it runs. Should you attempt to substitute fake parts that somehow the car as a whole can detect and reject the engine still "works" but is disabled and a simple software bypass or using a real part will enable operation.

Inversely an evil malicious act would be on detection to cause either unintended acceleration to kill the driver or various other mechanically contradictory actions that result in the physical destruction of the car/engine/humans. (Evil, Mean, Not Nice, Nice, Not Evil)(It isn't a black and white world its a black to white world, yes/no type situation as those are extremely rare)

Refusing to work with fake parts in cars/airplanes/medical devices where possible to detect is actually a very good thing to do. (In addition to branding it as codes of "It's a fake") I would rather a automatic defibrillator for example say nope I can't zap this person because those electrodes are fake and you might end up killing the person instead because they don't match spec or the expiry cannot be verified.

FTDI is just horrible at spinning things the right way around. They should have started by telling the community that there is a problem with fakes and that newer drivers will give them a PID of 0000 and if people find that their stuff has PID0000 it's a fake and they should report it. Then they should just reference in the FT_PROG guide on how to change the PID and even just have a one click reset PID tool (With a note that a fake will just get pid 0000 again).

[a210210200]

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

With a damaged bearing, it does not. It's blown. Non operational, which is consistent with everything else I've stated. You've now had to alter your original position "The engine does not run, the device does," to "The engine runs, the device does not." You're contradicting yourself, so again, which is it?

I think your confused the engine in my statement is the fake chip (As in your example is wrong because the "engine"/chip still works vs. your example where your saying the "engine"/chip don't work) it does run (it is electrically still operational, the firmware is valid, the mechanical state of the chip is good probably, and so on) the only thing that doesn't work is the driver which refuses to talk to the "engine" so to speak which is to be expected upon detecting a fake part.

Your example specifically says the engine does not work but the fake chip still does work which is the contradiction. If a python script can both detect, reprogram, communicate, bypass the FTDI driver the chip definitely is still working. But if FTDI messed up the clock config then no software could repair it and it would not enumerate at all and would be bricked.

[XFDDesign]

Your attempts at oversimplifying the example is crude at best.

Your attempts to evade the contradictions of your position are not masked with such remedial dismissals.

You have, at this point admitted that for all intents and purposes to the end user, there is no distinguishable difference between a blown engine which fails to perform, and a dead device which fails to perform. Once you were cornered into the "simple example" where your logic failed, you began contradicting yourself and throwing up irrelevant distractions to try and rationalize your belief. 

Also you still not accepting that to kill a chip you have to literally disable it which is certainly possible via the clock config as one example.

The underlying requirement of your premises, is that every end user has the equivalent of the mechanic's knowledge on rebuilding the engine, for recovering the functionality of the end device. This is self-evidently false. Thus for all intents and purposes, to the general public, there is zero difference between the blown engine and the 'dead' device, as both can be "easily" fixed when one possesses the essential knowledge and the right tools but the average user does not possess either.

[Rufus]

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.

[Nerull]

Please stop declaring things illegal which are not illegal. Doing so is illegal and you'll be arrested. It says so right here in the EULA I didn't show you but you agreed to by reading this post.

Using a fake chip is not illegal, buying a fake chip is not illegal. Using a driver with a device you bought from amazon without the slightest idea in the world what chips are in it - because no one does, not even you - is not illegal.

Intentionally rendering a users device inoperable is often illegal, though. Even if its easy to fix.

[a210210200]

Your attempts at oversimplifying the example is crude at best.

Your attempts to evade the contradictions of your position are not masked with such remedial dismissals.

You have, at this point admitted that for all intents and purposes to the end user, there is no distinguishable difference between a blown engine which fails to perform, and a dead device which fails to perform. Once you were cornered into the "simple example" where your logic failed, you began contradicting yourself and throwing up irrelevant distractions to try and rationalize your belief. 

Also you still not accepting that to kill a chip you have to literally disable it which is certainly possible via the clock config as one example.

The underlying requirement of your premises, is that every end user has the equivalent of the mechanic's knowledge on rebuilding the engine, for recovering the functionality of the end device. This is self-evidently false. Thus for all intents and purposes, to the general public, there is zero difference between the blown engine and the 'dead' device, as both can be "easily" fixed when one possesses the essential knowledge and the right tools but the average user does not possess either.

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.

[Nerull]

Your attempts at oversimplifying the example is crude at best.

Your attempts to evade the contradictions of your position are not masked with such remedial dismissals.

You have, at this point admitted that for all intents and purposes to the end user, there is no distinguishable difference between a blown engine which fails to perform, and a dead device which fails to perform. Once you were cornered into the "simple example" where your logic failed, you began contradicting yourself and throwing up irrelevant distractions to try and rationalize your belief. 

Also you still not accepting that to kill a chip you have to literally disable it which is certainly possible via the clock config as one example.

The underlying requirement of your premises, is that every end user has the equivalent of the mechanic's knowledge on rebuilding the engine, for recovering the functionality of the end device. This is self-evidently false. Thus for all intents and purposes, to the general public, there is zero difference between the blown engine and the 'dead' device, as both can be "easily" fixed when one possesses the essential knowledge and the right tools but the average user does not possess either.

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.

Before said driver was installed, the device performed its intended function. After the driver was installed, the device stopped performing its intended function because the device was intentionally modified to stop it from functioning as it did before, by an entity without right or permission to do so.

That is the only test that actually matters, so please stop with the tortured analogies.

[XFDDesign]

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.

[a210210200]

Please stop declaring things illegal which are not illegal. Doing so is illegal and you'll be arrested. It says so right here in the EULA I didn't show you but you agreed to by reading this post.

Using a fake chip is not illegal, buying a fake chip is not illegal. Using a driver with a device you bought from amazon without the slightest idea in the world what chips are in it - because no one does, not even you - is not illegal.

Intentionally rendering a users device inoperable is often illegal, though. Even if its easy to fix.

It is not illegal to possess counterfeit goods but the resale, marketing, distribution of said goods is illegal. Holding large amounts of the fake goods even in part is subject to seizure. So technically using a fake chip can be illegal it is just if its on a commercial scale. End users that get caught up in the mess should case after the mfg/seller and so on until the counterfeiters are found out.

Breaking digital lock can be illegal (in the US for example) and the devices will not be operable form this point onwards since FTDI is under no obligation to work with a fake part. (PID 0000 or not Linux/FOSS OSes will just pull the drivers or write their own bypasses and windows will not ever work plug-in play WHQL style)

The crux of the matter is that the fake chip is still operable in every respect it is just the driver that won't talk to it, the chip works fine you can bypass the software driver detection easily just wait for updated Linux drivers or use a third party windows one. Nothing is broken with the chip.

The chip is not an FTDI official chip so it makes sense that you should use a non-FTDI driver it is not an issue to detect a PID 0000 value.

[a210210200]

Your attempts at oversimplifying the example is crude at best.

Your attempts to evade the contradictions of your position are not masked with such remedial dismissals.

You have, at this point admitted that for all intents and purposes to the end user, there is no distinguishable difference between a blown engine which fails to perform, and a dead device which fails to perform. Once you were cornered into the "simple example" where your logic failed, you began contradicting yourself and throwing up irrelevant distractions to try and rationalize your belief. 

Also you still not accepting that to kill a chip you have to literally disable it which is certainly possible via the clock config as one example.

The underlying requirement of your premises, is that every end user has the equivalent of the mechanic's knowledge on rebuilding the engine, for recovering the functionality of the end device. This is self-evidently false. Thus for all intents and purposes, to the general public, there is zero difference between the blown engine and the 'dead' device, as both can be "easily" fixed when one possesses the essential knowledge and the right tools but the average user does not possess either.

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.

Before said driver was installed, the device performed its intended function. After the driver was installed, the device stopped performing its intended function because the device was intentionally modified to stop it from functioning as it did before, by an entity without right or permission to do so.

That is the only test that actually matters, so please stop with the tortured analogies.

The driver is not the product or the chip. The driver has nothing that says it is guaranteed to work with fake chips. The device still works the driver doesn't want to talk to it. 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.

[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.