FTDI driver kills fake FTDI FT232??

[dannyf]

They indirectly admit that fakes/clones of all kinds/incompliant devices were damaged on purpose

It shows that any sentence can be read to mean anything its reader intends it to mean,

[zapta]

I just got a product change notification email from Mouser, about the FT232, linked PDF: http://www.mouser.com/PCN/FTDI_122757PM11062014.pdf

It's very interesting.

He tries to create the impression that the bricking 'just happened'.  What a weasel.  They found a minute difference between their and competitors' products and exploited it.  At least be honest about it.

[nctnico]

They indirectly admit that fakes/clones of all kinds/incompliant devices were damaged on purpose

It shows that any sentence can be read to mean anything its reader intends it to mean,

True but the part which says that the functional equivalent are not damaged on purpose is an outright lie. The dissassembly of the driver clearly shows that every FT232 is programmed to Pid zero. There is no way to explain such an action otherwise than to disable functional equivalents.

[classicalQbit]

I just got a product change notification email from Mouser, about the FT232, linked PDF: http://www.mouser.com/PCN/FTDI_122757PM11062014.pdf

It's very interesting.

Thanks for the link 8086

It contains this gem

Distributor Update Regarding Perceived Issues with recent FTDI Driver Updates

as its headline.
When it have been thoroughly documented that peoples equipment have been bricked. Even in the first post, in this thread, on this blog, which he himself answered.

and this

Some counterfeit devices simply failed to handle certain commands correctly

This is utterly untrue. As have been proved both by those that have disassembled the driver, and those that have checked what happens with a protocol analyzer. The "certain commands" deliberately harms reverse engineered chips, and does not only not do anything useful with FTDIs chips, it doesn't do anything at all with FTDIs chips.

and this

To date, this whole episode has not affected our large or medium customers at all. They haven’t been hindered in any way as they source chips either directly from us or via our global distribution partners like yourselves. Even the vast majority of smaller customers have not been impacted

So FTDI just disables reverse engineered chips on pure spite? If it is true that all large, all medium, and the vast majority of smaller customers bought FTDI chips anyway.

[dannyf]

This is utterly untrue.

It probably helps with better reading comprehension,

The "certain commands" deliberately harms reverse engineered chips,

To prove "harm", let alone "deliberately harm", you need intent. How are you going to get that out of someone's head?

and does not only not do anything useful with FTDIs chips, it doesn't do anything at all with FTDIs chips.

Just how do you know that? It seems to me that unless you have intimate knowledge of the chip's design / functioning, you would have no way of knowing that.

It is understandable that you are trying to substantiate your points but it helps greatly if you do so on solid base.

[miguelvp]

No matter what, it doesn't belong on this thread, since the thread not related to that driver at all.
Someone dig up the other one.

[zapta]

To prove "harm", let alone "deliberately harm", you need intent. How are you going to get that out of someone's head?

Use objective common sense. It's that simple.

Your efforts to justify FTDI actions seems very biased to me.

[classicalQbit]

This is utterly untrue.

It probably helps with better reading comprehension,

Please refrain from slurs dannyf. I welcome if you have actual specific information about something I have misunderstood.

The "certain commands" deliberately harms reverse engineered chips,

To prove "harm", let alone "deliberately harm", you need intent.

To prove harm by someone, you need to prove a link between something someone did (or did not do in the case of neglect) and the harmful consequence for someone (or something). It may even be an accident. Though for deliberate harm we need something that shows intent (down to and including acts done in affect). FTDIs code proves something beyond that, as the preimage-attack shows premeditated intent.

Code: [Select]

...There are different types of harm like accidental harm-where the injury or damage is not caused by a...

 

How are you going to get that out of someone's head?

It is already out of their head. It is codified in the code. I follow the trail of evidence.
 

and does not only not do anything useful with FTDIs chips, it doesn't do anything at all with FTDIs chips.

Just how do you know that? It seems to me that unless you have intimate knowledge of the chip's design / functioning, you would have no way of knowing that.

It is understandable that you are trying to substantiate your points but it helps greatly if you do so on solid base.

I concur. This thread has been thorough but it is not given that any individual have seen the evidence of how we know it were on purpose. I should have referred to some of this evidence in the previous post. I'm sorry you had to request this information.

The FTDI FT232RL EEPROM is written 32 bits at once on the condition that a write to an odd address occurs, while a write to a even address is just buffered while it waits for a write to an odd address. This makes it possible for FTDI to attack the 16bits chips by writing to the even addresses and not follow up with a write to an odd address.

It is trivially easy to check that the writes doesn't update the FTDI produced chips. This means that it doesn't do anything at all with FTDIs chips. Just like I wrote.

It is doubly proved as it writes PID=0 to the chips, that would have bricked the FTDI produced chips as it would not be linked to the driver any more, nor would any windows version newer than XP work with it. Just like the attack against the reverse engineered chips now.

It is triply proved as the protocol analyzer shows that PID=0 is written to the chips, that would brick any FTDI chip, just like it does for the reversed engineered chips. If it were not for the fact that the FTDI driver writes just to the even addresses for the PID=0 sabotage - also proved by the protocol analyzer.

marcan proved that it is intentional and malicious, and disassembled the driver, and commented the code, and posted it for everybody to see and to verify, weeks ago, in this very thread:

In case anyone was still wondering if this is intentional and malicious...



Straight out of their driver. Function/variable naming and comments mine.

I recommend that anyone that have any doubt of FTDIs intention read the actual code, and his post in full.

Before the actual attack, the FTDI driver does a preimage-attack on the checksum function as a preparation. This shows that it is a premeditated and willful act, not just a mistake.

[HackedFridgeMagnet]

Straight out of their driver. Function/variable naming and comments mine.

Be aware that that code is not actually FTDI's.
It is something that should compile into the same as the code in FTDI's driver.
I noticed at the top Marcans comment says "there is no explicit detection". Which seems to go along with what Fred says.

To mitigate some of the risks such as FTDI gate:

1) No microsoft equipment or software may connect to any manufacturing equipment. This will probably be a permanent ban.

2) FTDI chips in equipment will be considered a risk. It will be among the factors that will be considered when a supplier wins or looses a tender.

3) All employees have been informed of the risk Microsoft and FTDI forced on us. And that their private equipment also may be at risk.

Surely you just made up this nonsense.

[dannyf]

It is triply proved as the protocol analyzer shows that PID=0 is written to the chips, that would brick any FTDI chip, just like it does for the reversed engineered chips. If it were not for the fact that the FTDI driver writes just to the even addresses for the PID=0 sabotage - also proved by the protocol analyzer.

What a confusing sentence. So you have logic analyzer showing that PID=0 was written the chips (whose chips?)? Is it a crime that FTDI's drivers writing PID=0 to FTDI's chips?

marcan proved that it is intentional and malicious, and disassembled the driver, and commented the code, and posted it for everybody to see and to verify, weeks ago, in this very thread:

A little bit logic may be required here.

So this marcan person disassembled the driver code below and his comments on the code proved FTDI's malicious intent?

So if I took your write-up above and commented to the effect that you were a malicious killer, the authorities should execute you on the spot?

I am sure you can do better than that. Try harder, please.

[dannyf]

Let me just help you a little bit more - as I am feeling good today,

1) disassemble the code yourself: you cannot trust everything the internet says;
2) if you have any experience disassembling code, you will know that the disassembled code may not always reflect the actual execution of the code.
3) even if the disassembled code follows the actual execution, all you have proven is that their driver does that to their chip. Last time I checked, there is nothing wrong with a company (or anyone) writing a piece of code that interfaces with their chips.

If you used their code on your chips, and suffered losses, none of their problem, legally.

[Macbeth]

All the FTDI trolls, shills and apologists - we don't care - Fred has been caught "doing a Ratner". The market will decide, not your pathetic interpretations of what is or isn't deliberate malicious code that has been reverse engineered.

[all_repair]

I just got a product change notification email from Mouser, about the FT232, linked PDF: http://www.mouser.com/PCN/FTDI_122757PM11062014.pdf

It's very interesting.

Guess he is trying to convince Mouser and alike to carry more stock.  I do not think he cannot see that FTDI are being designed OUT, the best option is to dump as much FTDI inventory on the distribution channels as possible.  The words used are to confuse and to convince the people that trade and shift FTDI. 

He is burning more bridges. 

[nitro2k01]

It is triply proved as the protocol analyzer shows that PID=0 is written to the chips, that would brick any FTDI chip, just like it does for the reversed engineered chips. If it were not for the fact that the FTDI driver writes just to the even addresses for the PID=0 sabotage - also proved by the protocol analyzer.

What a confusing sentence. So you have logic analyzer showing that PID=0 was written the chips (whose chips?)? Is it a crime that FTDI's drivers writing PID=0 to FTDI's chips?

The key point here is that on a genuine chip, writes to even EEPROM addresses are ignored, and writes to odd addresses go through. On counterfeit chips, writes to both odd and even addresses go through. This can and has been tested independently of the disassembled FTDI code, if you look at the detection script that someone made and linked earlier in the thread.
Edit: Here: https://marcan.st/transf/detect_ftdi_clone.py

Now, you tell me what the purpose is to write to the PID value, and then the checksum value, using write calls that would do nothing on a genuine chip. Of course, you can still claim that we can't deduce aaaaanything about what this code is supposed to do.

[tszaboo]

I had a talk with FTDI representatives in Münich. It is impressive, how much ignorance they can provide. They were well aware the situation, so I went to their empty booth (seriously, no-one was there, and no-one else came there for the ten minutes I've spent there). I've asked them about FTDIGATE. So here is what they basically said:
If you are an individual that makes a product, you should buy directly from them.
Supply chains are inprenetable, there is no chance that a mistake will ever happen.
The products bricked by their stupid actions is the problem of the company selling the product. They are not legally responsible.
Here is the good part: People making the comments here are the "Noisy but small part of the engineering community" and the majority will continue to use their products, because big companies were not affected by this. I had the feeling they did not give a rat's ass about what happens here. For the reference, when they said this, that is were they lost my sympathy. BTW we did not post on their forums, that is why they dont feel like answering the questions.
They stated multiple times, that counterfeit chips are hurting the industry. One of them even mentioned the music industry (wtf moment).
I've explained to them, that actual engineers bricked their dev boards, which has nothing to do with FTDI. Of course that is the dev board's manufacturer's problem.
I think I should have made a recording of the conversation. I dont think I'll ever use FTDI product anymore. Welcome to the maxim bag.

[madires]

Quote from that PCN:
'Although in certain parts of the media it has been implied that there was some form of counterfeit detection algorithm
in FTDI’s latest driver, this is in fact absolutely untrue. There was no mechanism of that description in place and hence
no flagging up of a counterfeit device ever occurred. Exactly the same commands and sequence are sent to a genuine
chip as to a counterfeit chip. Some counterfeit devices simply failed to handle certain commands correctly (again
something that’s shows their lack of suitability for use in serious electronic system design) and they simply end up
quarantining themselves out of harm’s way.'

Now they're running in deny-everything-unless-proven-in-court mode and make it more worse. EEs don't buy that PR nonsense, they'll buy a chip from another vendor.

[madires]

I had a talk with FTDI representatives in Münich. It is impressive, how much ignorance they can provide. They were well aware the situation, so I went to their empty booth (seriously, no-one was there, and no-one else came there for the ten minutes I've spent there). I've asked them about FTDIGATE. So here is what they basically said:

Have you expected an honest answer? I wouldn't be surprised if FTDI's booth is the most deserted one.

[German_EE]

"Supply chains are impenetrable, there is no chance that a mistake will ever happen."

[tszaboo]

I had a talk with FTDI representatives in Münich. It is impressive, how much ignorance they can provide. They were well aware the situation, so I went to their empty booth (seriously, no-one was there, and no-one else came there for the ten minutes I've spent there). I've asked them about FTDIGATE. So here is what they basically said:

Have you expected an honest answer? I wouldn't be surprised if FTDI's booth is the most deserted one.

I dont know. Usually CEOs dont give the "be an a$$ehole, like me" command for their sales people. But I must say, I've noticed that companies tend to collect people with the same mentalities in the senior management. If I would have seen any remorse in their eyes, a facepalm or anything human, instead of the "copying is bad for the industry", I wouldn't have written what I wrote.

[Rufus]

I've explained to them, that actual engineers bricked their dev boards, which has nothing to do with FTDI. Of course that is the dev board's manufacturer's problem.

So which dev boards have been bricked and what did their manufacturer say about it?

Or did you really mean piece of shit bought from ebay manufactured by someone unknown in China?

[madires]

Have you expected an honest answer? I wouldn't be surprised if FTDI's booth is the most deserted one.

I dont know. Usually CEOs dont give the "be an a$$ehole, like me" command for their sales people. But I must say, I've noticed that companies tend to collect people with the same mentalities in the senior management. If I would have seen any remorse in their eyes, a facepalm or anything human, instead of the "copying is bad for the industry", I wouldn't have written what I wrote.

The lack of conscience and empathy seems to be a beneficial soft skill for senior management It makes some tasks more easy to cope with, like firing 1000 employees or shutting down a business division. The sales people at the booth are paid to sell stuff and they want to keep their jobs. Of course they got some instructions on dealing with questions regarding FTDIgate and I'd also assume most of them don't fully understand FTDIgate. It's just some driver issue for them. I've done a lot of pre/post-sales support and have been member of booth teams a few times being the engineer. Only a few sales people really know about the product they're selling, because their job is to sell and not to know how some product/service works. For technical questions there are technical account managers or an engineer in case of a small company. If I would work for FDTI I would say something like "Sorry, but I can't tell you much because I'm not involved in the driver developement. Please ask the sales guy over there." to end the conversation. Since I would know the whole story, I'd would be embarrassed and try to avoid the topic. The sales guy will happily talk to you until you become dizzy

[zapta]

Or did you really mean piece of shit bought from ebay manufactured by someone unknown in China?

The chips are fine. It's FTDI that reprogrammed them with the intention to brick them (notice how they are very careful not to deny it).

Your subjective negative labels do no change the facts.

[Rufus]

Or did you really mean piece of shit bought from ebay manufactured by someone unknown in China?

The chips are fine. It's FTDI that reprogrammed them with the intention to brick them (notice how they are very careful not to deny it).

The chips are as 'fine' as they ever were. They were 'programmed' to no longer load drivers they were not licensed to use.

I'll ask again which dev boards have been bricked and what did their manufacturer say about it? If you can't answer that is it probably because they are shit bought from ebay and you don't even know who the manufacturer is.

[nctnico]

"Supply chains are impenetrable, there is no chance that a mistake will ever happen."

Especially with FTDI's plant being located in Indonesia. If there is one country where money talks... 

[dannyf]

FTDI wrote their drivers to work with their chips - no one has complained that FTDI drivers don't work with FTDI chips.

If you used FTDI drivers with non-FTDI chips, the responsibility for any damage is on you.

Cannot be simpler than that. FTDI never said that it is OK to use their software with fake chips, nor did they ever represent that their software will work with fake chips.

What else do you want from FTDI? After all, they didn't mate your fake chips with their drivers. You did. Why should they be responsible for your doing it?