Author Topic: FTDIgate 2.0?  (Read 244495 times)

0 Members and 1 Guest are viewing this topic.

Offline CatalinaWOW

  • Super Contributor
  • ***
  • Posts: 3242
  • Country: us
Re: FTDIgate 2.0?
« Reply #850 on: March 01, 2016, 05:06:00 pm »
It would have been relatively easy for FTDI to make a chip test tool and distribute it to vendors and distributors. This would allow them to test for genuine parts before incorporating them in their sales stream.  Even a lot sample test of this sort would have been highly effective.

FTDI apparently did not think of this, or had some motive for not doing it.  At this point in time people can use the driver to perform this test, but do not have the manufacturers assurance that passing this test will be good enough in the future.

Still seems to me that FTDI is either not handling this well, or is motivated by something not identified on this forum.

The problem with such a tool is, what do you want it to do.

1. Do you want it to check only for the actual way of checking for counterfeit chips, than you can simply use the latest driver. No need for a tool.

2. If you want a tool that checks for all possible ways to check for counterfeit chips, also methods of detecting which FTDI hasn't been used yet but keep them for future use,
well, then they should be stupid if they provide such a tool because that tool will be used by counterfeiters to check and circumvent all present and future methods of FTDI to check for counterfeit chips.

You have missed the whole point.  You have often expressed that manufacturers should do due diligence in getting genuine FTDI chips.  Nowhere is due diligence defined.  By your own definition using the current driver is inadequate, because FTDI either does or may have withheld future clone detection techniques.  So you are saying that legitimate vendors must assume all of the risk of being stuck with a clone chip while FTDI assumes none.

There are demonstrated cases where buying direct from the vendor does not assure genuine chips.  Employees of the vendor were making money on the side by buying clones and selling them, or in other cases selling non-spec parts from the scrap bin.  Due diligence in the supply chain cannot go further than buying direct from the manufacturer.  While I am not aware of this occurring at FTDI, I see no reason they are immune from this problem.

Issuing a certified test program is a way of sharing risk.  If FTDI is concerned enough about the problem there are encryption techniques (which would involve both the parts and the test program) which could make the approach difficult to use the test as a design tool for getting around the test program.
 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7805
  • Country: us
  • adieu
Re: FTDIgate 2.0?
« Reply #851 on: March 01, 2016, 05:07:58 pm »
Yes, I am. Apparently you aren't otherwise you should know that a safety critical device that can cause seriouse injury because of a glitch on a serial port,
should be taken out of service immediately. There's simply no excuse for that.

Yes, it should. That is a dangerous machine. But how does that mean that it's okay to screw around with it?

I'm starting to think you just have a problem with logic. You make an awful lot of non sequitur arguments. "This machine is too dangerous and shouldn't be used, therefore FTDI should fuck with it" makes about as much sense as "the sky is blue, therefore broccoli tastes bad"... |O
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline madires

  • Super Contributor
  • ***
  • Posts: 4733
  • Country: de
  • A qualified hobbyist ;)
Re: FTDIgate 2.0?
« Reply #852 on: March 01, 2016, 05:09:43 pm »
You are a real engineer aren't you? If you are a real engineer then you should know it is very bad to send random data to a device. I have come across several devices which lock up when confronted with data the device didn't expect. One of those was actually performing a safety critical function so yes, it is very bad to send random data to a device. I also start to doubt you can read because this has been discusses at length in this same thread so you are trying to create a new infinite loop here so lets leave this subject alone right here. You can read all about it in the previous pages.

Yes, I am. Apparently you aren't otherwise you should know that a safety critical device that can cause seriouse injury because of a glitch on a serial port,
should be taken out of service immediately. There's simply no excuse for that.

In a perfect world :) But if there's no budget for that, the poorly designed device has to stay. Mr. Manager will tell you that.
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 1376
  • Country: 00
Re: FTDIgate 2.0?
« Reply #853 on: March 01, 2016, 05:11:50 pm »
So you are saying that legitimate vendors must assume all of the risk of being stuck with a clone chip while FTDI assumes none.

No, I'm not saying that. In the rare case that they are affected by this problem, they can put a claim at the seller of the counterfeit chips.


The difference between theory and practice is less in theory than
the difference between theory and practice in practice.
Expensive tools cannot compensate for lack of experience.
 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7805
  • Country: us
  • adieu
Re: FTDIgate 2.0?
« Reply #854 on: March 01, 2016, 05:12:55 pm »
So you're okay with causing harm as long as the people affected can blame someone else? WTF dude?
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 1376
  • Country: 00
Re: FTDIgate 2.0?
« Reply #855 on: March 01, 2016, 05:13:10 pm »
You are a real engineer aren't you? If you are a real engineer then you should know it is very bad to send random data to a device. I have come across several devices which lock up when confronted with data the device didn't expect. One of those was actually performing a safety critical function so yes, it is very bad to send random data to a device. I also start to doubt you can read because this has been discusses at length in this same thread so you are trying to create a new infinite loop here so lets leave this subject alone right here. You can read all about it in the previous pages.

Yes, I am. Apparently you aren't otherwise you should know that a safety critical device that can cause seriouse injury because of a glitch on a serial port,
should be taken out of service immediately. There's simply no excuse for that.

In a perfect world :) But if there's no budget for that, the poorly designed device has to stay. Mr. Manager will tell you that.

So, aim your anger to Mr. Manager. Not to FTDI.
The difference between theory and practice is less in theory than
the difference between theory and practice in practice.
Expensive tools cannot compensate for lack of experience.
 

Online Bud

  • Super Contributor
  • ***
  • Posts: 3471
  • Country: ca
Re: FTDIgate 2.0?
« Reply #856 on: March 01, 2016, 05:14:08 pm »
Not that it is wrong but it is useless and will do no job in many use cases where devices use proprietary application level protocols. This message will simply be ignored as noise. FTDI what, thinks that every single use case involves someone stairing at the display and reading the bytestream?
Facebook-free life and Rigol-free shack.
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 1376
  • Country: 00
Re: FTDIgate 2.0?
« Reply #857 on: March 01, 2016, 05:15:13 pm »
So you're okay with causing harm as long as the people affected can blame someone else? WTF dude?

Show me a documented example where the behaviour of FTDI's driver caused serious injury.
The difference between theory and practice is less in theory than
the difference between theory and practice in practice.
Expensive tools cannot compensate for lack of experience.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 17684
  • Country: nl
    • NCT Developments
Re: FTDIgate 2.0?
« Reply #858 on: March 01, 2016, 05:20:59 pm »
So you're okay with causing harm as long as the people affected can blame someone else? WTF dude?
Show me a documented example where the behaviour of FTDI's driver caused serious injury.
So people should get hurt or killed before you are convinced?  :wtf:
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7805
  • Country: us
  • adieu
Re: FTDIgate 2.0?
« Reply #859 on: March 01, 2016, 05:31:47 pm »
Probably a good idea to just stop now. We're clearly at the "I'll say anything that sounds like it proves my point" stage of the argument.
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 1376
  • Country: 00
Re: FTDIgate 2.0?
« Reply #860 on: March 01, 2016, 06:11:53 pm »
So you're okay with causing harm as long as the people affected can blame someone else? WTF dude?
Show me a documented example where the behaviour of FTDI's driver caused serious injury.
So people should get hurt or killed before you are convinced?  :wtf:

No, people shouldn't get hurt, those are your words.

If you really know about a safety critical device that can cause serious injury because of a glitch on the serial port,
than I assume you took the device out of service or at least reported it to the authorities and made sure that they
took it out of service. No risk anymore that something goes wrong.

If not, then you are a hypocrite that wines about FTDI but don't really care about safety.


The difference between theory and practice is less in theory than
the difference between theory and practice in practice.
Expensive tools cannot compensate for lack of experience.
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 1376
  • Country: 00
Re: FTDIgate 2.0?
« Reply #861 on: March 01, 2016, 06:14:19 pm »
FTDI what, thinks that every single use case involves someone stairing at the display and reading the bytestream?

The engineer that is investigating the defect device will.
The difference between theory and practice is less in theory than
the difference between theory and practice in practice.
Expensive tools cannot compensate for lack of experience.
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 1376
  • Country: 00
Re: FTDIgate 2.0?
« Reply #862 on: March 01, 2016, 06:18:24 pm »
Yes, I am. Apparently you aren't otherwise you should know that a safety critical device that can cause seriouse injury because of a glitch on a serial port,
should be taken out of service immediately. There's simply no excuse for that.

Yes, it should. That is a dangerous machine. But how does that mean that it's okay to screw around with it?

How many dangerous machines have stopped working because of FTDI's driver?

The difference between theory and practice is less in theory than
the difference between theory and practice in practice.
Expensive tools cannot compensate for lack of experience.
 

Offline timb

  • Super Contributor
  • ***
  • Posts: 2528
  • Country: us
  • Pretentiously Posting Polysyllabic Prose
    • timb.us
Re: FTDIgate 2.0?
« Reply #863 on: March 01, 2016, 08:03:27 pm »

Yes, I am. Apparently you aren't otherwise you should know that a safety critical device that can cause seriouse injury because of a glitch on a serial port,
should be taken out of service immediately. There's simply no excuse for that.

Yes, it should. That is a dangerous machine. But how does that mean that it's okay to screw around with it?

How many dangerous machines have stopped working because of FTDI's driver?

Wow. Just wow.

Stop the train. This is where I get off.
Any sufficiently advanced technology is indistinguishable from magic; e.g., Cheez Whiz, Hot Dogs and RF.
 

Offline Koen

  • Frequent Contributor
  • **
  • Posts: 446
Re: FTDIgate 2.0?
« Reply #864 on: March 01, 2016, 11:54:19 pm »
So far over 35 pages we've had "what ifs", unsubstantiated claims about counterfeit FTDI chips in regular distribution, unsubstantiated claims about major corporations discontinuing their use of FTDI chips and unsubstantiated claims about safety-critical systems compromised by random serial strings. Should people take your word for it ? Is linking to the related press releases impossible ? Or is it so obscure you can't name the distributor/company/product impacted without being found out ?

How can you try to prove your point without providing any evidence for your claims. This is debating 101.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 17684
  • Country: nl
    • NCT Developments
Re: FTDIgate 2.0?
« Reply #865 on: March 02, 2016, 12:50:05 am »
So far over 35 pages we've had "what ifs", unsubstantiated claims about counterfeit FTDI chips in regular distribution, unsubstantiated claims about major corporations discontinuing their use of FTDI chips and unsubstantiated claims about safety-critical systems compromised by random serial strings. Should people take your word for it ? Is linking to the related press releases impossible ? Or is it so obscure you can't name the distributor/company/product impacted without being found out ?

How can you try to prove your point without providing any evidence for your claims. This is debating 101.
There are documented cases that counterfeit components found their way into military devices. Google that. Also a simple data conversion problem can cause a rocket intended for launching satellites into space to fail ( http://sunnyday.mit.edu/accidents/Ariane5accidentreport.html ) due to feeding random data into a system which doesn't suspect it. It shouldn't need much thinking to understand that it is a bad idea in general to feed random data into any system.

Quote from the report:
Part of these data at that time did not contain proper flight data, but showed a diagnostic bit pattern of the computer of the SRI 2, which was interpreted as flight data.

IOW: The 'what ifs' aren't about pinpointing existing cases but doing solid engineering and the steps to take / processes to follow in order to minimize the risk on designing a (potential) problem into a product which can cause a customer problems at some point. I have been dealing with customers for over 25 years already and I have learned that a simple problem from an engineering perspective can be perceived as a huge problem by a customer. So by all means: get rid of any potential source of problems!
« Last Edit: March 02, 2016, 12:58:37 am by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 1376
  • Country: 00
Re: FTDIgate 2.0?
« Reply #866 on: March 02, 2016, 07:33:10 am »
There are documented cases that counterfeit components found their way into military devices.

Lets say, it's better that a (militairy) device doesn't want to start because of a driver update,
than starting fine and during it's service it malfunctions unexpectedly because the counterfeit chip is a bit out of spec.

The difference between theory and practice is less in theory than
the difference between theory and practice in practice.
Expensive tools cannot compensate for lack of experience.
 

Offline f4eru

  • Frequent Contributor
  • **
  • Posts: 550
Re: FTDIgate 2.0?
« Reply #867 on: March 02, 2016, 09:32:25 pm »
So far, in this whole thread, nobody has made a valid point why it's wrong to send a string that contains "not a genuine chip".
Bullshit. It's injecting corrupt data in a data stream you know nothing about.

Tampering for any reason a random data stream is  simply dangerous. it's not acceptable from every point of view.
it's Malware.
« Last Edit: March 02, 2016, 09:38:43 pm by f4eru »
 

Offline Koen

  • Frequent Contributor
  • **
  • Posts: 446
Re: FTDIgate 2.0?
« Reply #868 on: March 02, 2016, 10:30:05 pm »
I'll take your point about Ariane 5 first launch but for future readers, I'll add this quote from the report :

Quote
f) Approx. 0.05 seconds later the active inertial reference system, identical to the back-up system in hardware and software, failed for the same reason. Since the back-up inertial system was already inoperative, correct guidance and attitude information could no longer be obtained and loss of the mission was inevitable.

It isn't solely unexpected data but irrecoverable instruments.
 

Offline dadler

  • Supporter
  • ****
  • Posts: 851
  • Country: us
Re: FTDIgate 2.0?
« Reply #869 on: March 02, 2016, 11:43:57 pm »
My favorite (uh, wrong word here) story like this is the Therac-25:

https://en.m.wikipedia.org/wiki/Therac-25
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 1376
  • Country: 00
Re: FTDIgate 2.0?
« Reply #870 on: March 03, 2016, 07:36:37 am »
It's injecting corrupt data in a data stream you know nothing about.

As far as I know, it isn't. The original data never arrives. The host will only receive the string "not a genuine chip".
The difference between theory and practice is less in theory than
the difference between theory and practice in practice.
Expensive tools cannot compensate for lack of experience.
 

Offline cdev

  • Super Contributor
  • ***
  • Posts: 5082
  • Country: 00
Re: FTDIgate 2.0?
« Reply #871 on: March 18, 2016, 02:52:44 pm »
there should be a generic fallback mode where all usb-uart or usb-serial converters maintain basic functionality, using some generic fallback code thats community developed.
"What the large print giveth, the small print taketh away."
 

Offline bingo600

  • Super Contributor
  • ***
  • Posts: 1360
  • Country: dk
Re: FTDIgate 2.0?
« Reply #872 on: March 18, 2016, 03:03:21 pm »
Just use Linux  :-+
FTDI got the finger  :-- when trying to implement their "changes" to the linux ftdi driver.

And ear/eye plugs against Mr. K
We should be able to select a "hide posts" from  , in our settings.

/Bingo
 

Online edavid

  • Super Contributor
  • ***
  • Posts: 2818
  • Country: us
Re: FTDIgate 2.0?
« Reply #873 on: March 18, 2016, 03:28:19 pm »
And ear/eye plugs against Mr. K
We should be able to select a "hide posts" from  , in our settings.

The forum does have an ignore list feature:

https://www.eevblog.com/forum/profile/?area=lists;sa=ignore;
 

Offline CJay

  • Super Contributor
  • ***
  • Posts: 3322
  • Country: gb
  • M0UAW
Re: FTDIgate 2.0?
« Reply #874 on: March 18, 2016, 04:33:34 pm »
Out of all the unsubstantiated what if scenarios and other such in this thread, I take the following:

1. Good system design should preclude malfunction from 'random' or corrupted (intentionally or not) data.

I agree wholeheartedly, a no brainer, but we all know there's that one in a million, billion, whatever, combination of input that can cause an issue. Sadly software is rarely 100% verifiably bug free.

2. No system can be entirely fault free unless it's so simple it's possible to prove operation for every single possible instance of presented data along with every possible environmental influence.

My take on this:

The nature of my job means that I can be many miles from home at stupid times of day and night, thus I have been in situations many times where I've needed to buy random pieces of computer hardware from vendors I would not normally use to perform job function, on at least a couple of occasions I've had to buy USB-Serial adapters (things go faulty, get mechanically damaged, lost, etc.).

When I'm two hundred miles from home at three AM in the morning with people in positions of genuine, government mandated, authority asking me how long something is going to take to repair, I do not want to explain that my serial dongle doesn't work because of someone acting like a 2 year old and having a hissy fit which may or may not render the USB dongle bought from their local 24 hour supermarket unusable.

So, I avoid FTDI unless it's absolutely unavoidable (I.E. built in to a larger product).

Not a huge loss for FTDI, not even the price of a sandwich at lunch time but the tiny drip drip of water erodes much larger mountains than FTDI.

Shortsighted and childish of them.
M0UAW
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf