Author Topic: FTDIgate 2.0?  (Read 382583 times)

0 Members and 4 Guests are viewing this topic.

Offline Gabri74

  • Regular Contributor
  • *
  • Posts: 105
  • Country: it
Re: FTDIgate 2.0?
« Reply #250 on: February 02, 2016, 10:56:20 am »
Talking about counterfeiting.... I've already seen this type of uniforms... and
the slogan kinda remembers me of something... but I just can't recall....    :-DD

 

Offline rasmithuk

  • Newbie
  • Posts: 3
  • Country: gb
Re: FTDIgate 2.0?
« Reply #251 on: February 02, 2016, 11:39:21 am »
I'm not a Windows expert, but I believe those are translation/textual string resources used for the system event log. Messages are logged by code, so there wouldn't be a direct xref there, instead that's a table that maps codes to strings and something inside Windows itself does the mapping - so yeah, they can't use sprintf, this is Windows' dumb design I think? (someone with more Windows knowledge might be able to correct me here). I did find the logging code earlier, and what triggers it, but didn't check if it is indeed logged on my windows box. I just did and yeah, it's there:

The windows event log takes a few fixed parameters, to make sorting/filtering easier, and then a raw string.
Apart from a list of standard error codes on the fixed fields you can put whatever you want into the raw section, which is assumed to be human readable text.
 

Offline FrankBuss

  • Supporter
  • ****
  • Posts: 2365
  • Country: de
    • Frank Buss
Re: FTDIgate 2.0?
« Reply #252 on: February 02, 2016, 11:57:25 am »
The linux drivers are not made by FTDI. They are made by the linux community. That's why they've never had any issues with bricking clones, and will even undo the bricking done by the FTDI drivers.

... and I assume most of the frustration is rooted in the fact that Microsoft never managed to provide a generic USB-Serial device driver.
Starting with Windows 10 you don't need a custom driver or INF file anymore. Still required for Windows 8.1 and older, see here. Maybe in 10 more years, USB will be fully plug-and-play, as promised 20 years ago :)
So Long, and Thanks for All the Fish
Electronics, hiking, retro-computing, electronic music etc.: https://www.youtube.com/c/FrankBussProgrammer
 

Offline elgonzo

  • Supporter
  • ****
  • Posts: 688
  • Country: 00
Re: FTDIgate 2.0?
« Reply #253 on: February 02, 2016, 01:24:27 pm »
I have seen some (safety related!) devices get upset when they receive data which they don't expect so yes: sending random data to a device can lead to damage, injuries and even death.
In that case the designer was incompetent. If a device can cause injuries or death, it should have at least some crc check over the
It is not only about a CRC check but also about buffer overflows. I totally agree about the incompetent designer remark but the fact is those kind of designers are out there and put their software in products which are on the market. We don't live in an ideal world so it is better to be cautious and not send random data to a device.

(EDIT: I forgot to mention that i agree with nctnico. I am rather ranting about the silly implied notion permeating this thread that with this updated FTDI driver a machine like a CNC would become unsafe, and not using this particular FTDI driver would make the same machine safe again.  Without stating this explicitly, my somewhat coffein-induced rant might be seen as in disagreement with nctnico, which it is not. I hope ;) )


Look, there is no new kind of dangerous situation posed to CNC machines or their operators.
Since their inception, CNC machines had to be designed with safety-relevant problem scenarios in mind. These include, but are not limited to the machine receiving improper parameters exceeding its operating envelope, or plain data garbage. The scenario of a (FTDI) driver sending nonsensical data to the CNC machine is just another flavor of that old scenario.

If a CNC machine cannot deal with such a problem scenario, then it has been designed by idiots. That doesn't mean that i think such machines don't exist. I tend to agree with you that this is not an ideal world. Unscrupulous people/entities are able to peddle their questionable products/services as long as it is dirt-cheap (which nicely leads back to bargain-price counterfeit chips ;) )

Of course, not all improper parameters sent to a CNC machine do exceed its operating envelope. Improper parameters could simply be such that damage/destroy the workpiece or even damage/destroy the tool bit. Obviously, one can imagine a scenario where malevolent software sends the wrong parameters to the machine. But equally, one can imagine a scenario where wrong parameters would be send to the machine simply due to operator error or a bug/glitch in some software module. In terms of safety, there is really no new problem scenario introduced by some FTDI driver sending some bad/garbage data.

With regard to danger to health and life, any CNC machine should have appropriate safety in place. A housing or curtain to protect against flying bits and pieces, guard fences, safety mats, etc... Someone (person/entity) who operates a CNC which is missing critical safety systems (appropriate to the "size" of the machine) is a reckless idiot and there really is no reason or excuse to shift the blame on to a malfunctioning or misbehaving PC (in the broadest sense, including the software and drivers running on it, and also including a communications channel which cannot ensure data integrity by itself) if somebody gets injured...

In my opinion the view that FTDI's driver behavior creates a new safety risk to health and life is quite some hyperbole.

I mean, let's assume for a moment that you have such a machine which reacts allergic and kills everyone in the room if it receives incorrect data.
What if you have a com bridge chip which is not from FTDI in your machine?
What if that chip and the related driver work properly and do not (willfully or accidentally) produce garbage data?
What if the firmware in the machine, or the software running on the controlling PC occasionally produces buggy, glitchy, wrong data that is being sent properly to the machine?
What if there are bit-flips occurring during transfer of data from the PC to the machine, which are not detected via parity bit?
What if the PC crashes or dies mid-transmission?
Will you sleep well in the knowledge that you don't have the abysmal FTDI driver running on the system, and thus health and life are not in danger?


Don't get me wrong. I am not an apologist, and i do not like what FTDI are doing. With regard to economic losses, i would completely understand someone who worries that the behavior of the FTDI driver could lead to unexpected and substantial losses when devices with undiscovered fake FTDI chips are involved in production. This is a by all means a valid and serious concern.

But i don't get why people think that FTDI's driver behavior suddenly creates a new safety hazard that has not been there before. It simply doesn't. It only can trigger a safety hazard that already exists outside of the FTDI driver and (fake) FTDI chip.. Shoot the messenger, i guess...
« Last Edit: February 02, 2016, 02:30:10 pm by elgonzo »
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26754
  • Country: nl
    • NCT Developments
Re: FTDIgate 2.0?
« Reply #254 on: February 02, 2016, 02:23:58 pm »
I also agree that the safety hazzard exists with or without the FTDI driver sending out garbage but still it is better to avoid triggering these safety hazzards. BTW it is not just CNC machines which could cause saftey issues! There are many other scenarios; think along the lines of -for example- a controller for a elevator which is prone to a buffer overflow when it receives bogus data on a diagnostics interface. A while ago a lady walked/fell into an elevator shaft because the doors opened while the elevator wasn't there.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline RFZTopic starter

  • Regular Contributor
  • *
  • Posts: 52
  • Country: de
Re: FTDIgate 2.0?
« Reply #255 on: February 02, 2016, 02:44:06 pm »
But i don't get why people think that FTDI's driver behavior suddenly creates a new safety hazard that has not been there before. It simply doesn't. It only can trigger a safety hazard that already exists outside of the FTDI driver and (fake) FTDI chip.. Shoot the messenger, i guess...

You're right, it doesn't. But it makes this safety hazard more likely.

Just imagine a device (created by an idiot) where a unknown symbol/command actually causes a malfunction. The chance that a faulty USB to Serial Converter might unintentionally generate a wrong Symbol or a wrong Symbol is read due to a glitch is still pretty low and stays the same throughout its lifetime. With connecting a fake FTDI to it, the chance of causing this device to malfunction actually rises to 100%.

If just 0.0001% of all devices are susceptible to such fault, it's still better if their chance to fail remains 0.001% each instead of 100% ;)

But, don't get me wrong... The main reason I think FTDI does the wrong thing is not because I think they will actually break lots of devices. The main reason because I think it is the wrong way is because most of the users just will have trouble using their device, get frustrated and may never realize what really caused it to fail because there is just no end-user friendly notification...
 

Offline elgonzo

  • Supporter
  • ****
  • Posts: 688
  • Country: 00
Re: FTDIgate 2.0?
« Reply #256 on: February 02, 2016, 02:52:00 pm »
I also agree that the safety hazzard exists with or without the FTDI driver sending out garbage but still it is better to avoid triggering these safety hazzards. BTW it is not just CNC machines which could cause saftey issues! There are many other scenarios; think along the lines of -for example- a controller for a elevator which is prone to a buffer overflow when it receives bogus data on a diagnostics interface. A while ago a lady walked/fell into an elevator shaft because the doors opened while the elevator wasn't there.
Of course, i fully agree to avoid possible trigger conditions. Just being curious about what kind of elevator was involved in that accident? Do you have information or a link i can follow? Usually, elevators should have electrical/mechanical door interlocks (operating independently from the elevator control) which prevent the door from opening when the car is not there (and prevent the car from moving again as long as the doors are open). It seems unusual to me that door interlocks would have a digital controller. Then again, i don't really know since i am not in the elevator business and i don't know what cutting-edge modern-day elevators are made of...
 

Offline elgonzo

  • Supporter
  • ****
  • Posts: 688
  • Country: 00
Re: FTDIgate 2.0?
« Reply #257 on: February 02, 2016, 02:54:07 pm »
But i don't get why people think that FTDI's driver behavior suddenly creates a new safety hazard that has not been there before. It simply doesn't. It only can trigger a safety hazard that already exists outside of the FTDI driver and (fake) FTDI chip.. Shoot the messenger, i guess...

You're right, it doesn't. But it makes this safety hazard more likely.
I have to agree. Although it worries me a bit thinking about people/entities building, certifying or using safety-critical or safety risk-imposing devices without considering and testing about such possible problem scenarios...

Quote
But, don't get me wrong... The main reason I think FTDI does the wrong thing is not because I think they will actually break lots of devices. The main reason because I think it is the wrong way is because most of the users just will have trouble using their device, get frustrated and may never realize what really caused it to fail because there is just no end-user friendly notification...
Well, i have to agree again.  ;D
« Last Edit: February 02, 2016, 03:00:50 pm by elgonzo »
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26754
  • Country: nl
    • NCT Developments
Re: FTDIgate 2.0?
« Reply #258 on: February 02, 2016, 03:04:39 pm »
I also agree that the safety hazzard exists with or without the FTDI driver sending out garbage but still it is better to avoid triggering these safety hazzards. BTW it is not just CNC machines which could cause saftey issues! There are many other scenarios; think along the lines of -for example- a controller for a elevator which is prone to a buffer overflow when it receives bogus data on a diagnostics interface. A while ago a lady walked/fell into an elevator shaft because the doors opened while the elevator wasn't there.
Of course, i fully agree to avoid possible trigger conditions. Just being curious about what kind of elevator was involved in that accident? Do you have information or a link i can follow?
If you search for 'woman falls in elevator shaft' you'll notice it -shockingly- happens very often! The case I was referring to happened in Germany.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline elgonzo

  • Supporter
  • ****
  • Posts: 688
  • Country: 00
Re: FTDIgate 2.0?
« Reply #259 on: February 02, 2016, 03:31:31 pm »
If you search for 'woman falls in elevator shaft' you'll notice it -shockingly- happens very often! The case I was referring to happened in Germany.
Certainly elevator doors fail sometimes, because door interlocks fail sometimes.
But i am curious about that specific case you mentioned where a digital controller would be able to open the door although no car was there. I believe that a door interlock is wired directly to the respective elevator door operator (not the elevator controller) and does not rely on digital components (which would also mean that door interlocks would not offer a digital debug interface susceptible to buffer overflows). Either i am wrong in my belief, or the case you mentioned required the cooperation of a failed door interlock or personnel having the key to override/unlock the door interlocks. However, that's going off-topic and something where i can apply my Google-Fu to the usual suspects (Honeywell, Unitec, ThyssenKrupp, Otis, etc...) when i have some more idle time. Anyway, thanks for the feedback.
« Last Edit: February 02, 2016, 03:33:51 pm by elgonzo »
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26754
  • Country: nl
    • NCT Developments
Re: FTDIgate 2.0?
« Reply #260 on: February 02, 2016, 03:38:34 pm »
If you search for 'woman falls in elevator shaft' you'll notice it -shockingly- happens very often! The case I was referring to happened in Germany.
Certainly elevator doors fail sometimes, because door interlocks fail sometimes.
But i am curious about that specific case you mentioned where a digital controller would be able to open the door although no car was there.
My example was just a purely hypothetical one extrapolated from my experience with how bad some firmware is written. I just can't divulge too much about those experiences for obvious reasons.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Online Monkeh

  • Super Contributor
  • ***
  • Posts: 7990
  • Country: gb
Re: FTDIgate 2.0?
« Reply #261 on: February 02, 2016, 03:40:11 pm »
Can someone please confirm the Windows KB update...

There isn't one.
 

Offline suicidaleggroll

  • Super Contributor
  • ***
  • Posts: 1453
  • Country: us
Re: FTDIgate 2.0?
« Reply #262 on: February 02, 2016, 03:59:27 pm »
My example was just a purely hypothetical one extrapolated from my experience with how bad some firmware is written. I just can't divulge too much about those experiences for obvious reasons.

And what if somebody plugged a laptop into a rocket on the launchpad to run some diagnostics, and this bogus message caused it to ignite and kill everyone in the vicinity!!!  Boycott FTDI!!!

Would we all please stop with these nonsense hypotheticals and discuss the actual facts?  So far there is zero proof that there are any counterfeit devices in legitimate supply chains anymore.  All we have are a handful of people buying known Chinese knockoff products on eBay/Ali, big woop.  Also, if any product could kill somebody because it received the wrong byte over a UART line when plugged into a Windows computer, it was a shit product and was going to kill somebody at some point anyway.  Sure you'd be better off not trying to trigger a problem, but you'd also be better off not using a cheap Chinese knockoff converter to run the interface in the first place.  These ridiculous hypothetical scenarios don't help either side of the discussion.
 

Offline Russ.Dill@gmail.com

  • Contributor
  • Posts: 19
Re: FTDIgate 2.0?
« Reply #263 on: February 02, 2016, 04:20:03 pm »
Of course, now I can't do cool things like make my Arduino act like an FTDI directly via v-usb to make integration for windows users easier.

Why would you need to?

And why would you think it reasonable to make your Arduino behave like a piece of hardware with very specific capabilities when it is nothing of the sort?

It's actually quite straightforward to emulate all of the functions of the FT232RL. I'm not sure if you think that FTDI chips are some kind of black magic, especially the low end ones.
 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7799
  • Country: us
  • adieu
Re: FTDIgate 2.0?
« Reply #264 on: February 02, 2016, 04:34:52 pm »
Sure you'd be better off not trying to trigger a problem

My favorite part is where you admit you're wrong and still keep going :-+
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline suicidaleggroll

  • Super Contributor
  • ***
  • Posts: 1453
  • Country: us
Re: FTDIgate 2.0?
« Reply #265 on: February 02, 2016, 04:40:38 pm »
Sure you'd be better off not trying to trigger a problem

My favorite part is where you admit you're wrong and still keep going :-+

Wrong about what?  About how hypotheticals involving non-existent devices with non-existent counterfeit FTDI chips in legitimate supply chains, killing non-existent people in fantastical ways, are a waste of time and a distraction from the issue at hand?  That's what the entire post was about.

If there was a device out there that could kill somebody because it received an 'N' instead of a '2' over a UART line plugged into a Windows machine (a Windows machine that's connected to the internet, receiving untested updates, with nobody's knowledge), it would have ALREADY KILLED plenty of people before FTDI ever started screwing with counterfeits.  It simply doesn't exist, and fantasizing about "what if a device like that DID exist, how bad would that be???" is pointless.
« Last Edit: February 02, 2016, 04:44:51 pm by suicidaleggroll »
 

Offline LoyalServant

  • Regular Contributor
  • *
  • Posts: 65
  • Country: us
Re: FTDIgate 2.0?
« Reply #266 on: February 02, 2016, 04:41:37 pm »
My example was just a purely hypothetical one extrapolated from my experience with how bad some firmware is written. I just can't divulge too much about those experiences for obvious reasons.

Would we all please stop with these nonsense hypotheticals and discuss the actual facts?  So far there is zero proof that there are any counterfeit devices in legitimate supply chains anymore. 

Agree on the hypothetical situations.

While we have not heard of any major blunders in the supply chain like the Newegg and Intel issue a few years back that comes to mind I am sure we can all agree that bad players are constantly trying to infiltrate the supply chain.
I think everyone in the industry shares some responsibility in maintaining the integrity of the supply chain.

 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26754
  • Country: nl
    • NCT Developments
Re: FTDIgate 2.0?
« Reply #267 on: February 02, 2016, 04:46:58 pm »
Sure you'd be better off not trying to trigger a problem

My favorite part is where you admit you're wrong and still keep going :-+

Wrong about what?  About how hypotheticals involving non-existent devices with non-existent counterfeit FTDI chips in legitimate supply chains, killing non-existent people in fantastical ways, are a waste of time and a distraction from the issue at hand?  That's what the entire post was about.

If there was a device out there that could kill somebody because it received an 'N' instead of a '2' over a UART line plugged into a Windows machine (a Windows machine that's connected to the internet, receiving untested updates, with nobody's knowledge), it would have ALREADY KILLED plenty of people.  It simply doesn't exist, and fantasizing about "what if a device like that DID exist, how bad would that be???" is pointless.
As I wrote before: I have come across firmware doing safety critical tasks and it got upset from receiving data it didn't expect. There is nothing hypothetical about that! Also the assumption FTDI present and future detection algorithms will never be wrong is a false one. So even with a real chip there is a probability things can go wrong (Murphy's law).
« Last Edit: February 02, 2016, 04:48:52 pm by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7799
  • Country: us
  • adieu
Re: FTDIgate 2.0?
« Reply #268 on: February 02, 2016, 04:47:41 pm »
Sure you'd be better off not trying to trigger a problem

My favorite part is where you admit you're wrong and still keep going :-+

Wrong about what?  About how hypotheticals involving non-existent devices with non-existent counterfeit FTDI chips in legitimate supply chains, killing non-existent people in fantastical ways, are a waste of time and a distraction from the issue at hand?  That's what the entire post was about.

If there was a device out there that could kill somebody because it received an 'N' instead of a '2' over a UART line plugged into a Windows machine (a Windows machine that's connected to the internet, receiving untested updates, with nobody's knowledge), it would have ALREADY KILLED plenty of people before FTDI ever started screwing with counterfeits.  It simply doesn't exist, and fantasizing about "what if a device like that DID exist, how bad would that be???" is pointless.

You don't get to cause damage just because it would've happened anyway...

You said it yourself, read my quote from you!
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline suicidaleggroll

  • Super Contributor
  • ***
  • Posts: 1453
  • Country: us
Re: FTDIgate 2.0?
« Reply #269 on: February 02, 2016, 04:49:09 pm »
While we have not heard of any major blunders in the supply chain like the Newegg and Intel issue a few years back that comes to mind I am sure we can all agree that bad players are constantly trying to infiltrate the supply chain.
I think everyone in the industry shares some responsibility in maintaining the integrity of the supply chain.

Absolutely, and I do believe FTDI should be doing as much as they can to help with this.  I am not a distributor, so I don't have any information about what FTDI is or is not doing to ensure either 1) counterfeits don't enter the supply chain, and/or 2) counterfeits are identified before they're sold to customers.  Does anybody else here have any information on this topic?
 

Offline suicidaleggroll

  • Super Contributor
  • ***
  • Posts: 1453
  • Country: us
Re: FTDIgate 2.0?
« Reply #270 on: February 02, 2016, 04:51:51 pm »
As I wrote before: I have come across firmware doing safety critical tasks and it got upset from receiving data it didn't expect. There is nothing hypothetical about that!

And how many people have those devices killed?  Or were there other checks in place to ensure that even if the processor did get upset, it still didn't go on a murdering rampage?

So even with a real chip there is a probability things can go wrong (Murphy's law).
So it's a probability now?  With zero evidence that FTDI's counterfeit detection algorithm has ever given a false positive, it's now a probability that it's going to happen.  More hypotheticals...
« Last Edit: February 02, 2016, 04:57:23 pm by suicidaleggroll »
 

Offline suicidaleggroll

  • Super Contributor
  • ***
  • Posts: 1453
  • Country: us
Re: FTDIgate 2.0?
« Reply #271 on: February 02, 2016, 04:55:07 pm »
You don't get to cause damage just because it would've happened anyway...

You said it yourself, read my quote from you!

It wouldn't have happened anyway, because those devices don't exist.
 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7799
  • Country: us
  • adieu
Re: FTDIgate 2.0?
« Reply #272 on: February 02, 2016, 04:58:30 pm »
You said it yourself.

Sure you'd be better off not trying to trigger a problem
No longer active here - try the IRC channel if you just can't be without me :)
 

Online Monkeh

  • Super Contributor
  • ***
  • Posts: 7990
  • Country: gb
Re: FTDIgate 2.0?
« Reply #273 on: February 02, 2016, 05:12:12 pm »
Of course, now I can't do cool things like make my Arduino act like an FTDI directly via v-usb to make integration for windows users easier.

Why would you need to?

And why would you think it reasonable to make your Arduino behave like a piece of hardware with very specific capabilities when it is nothing of the sort?

It's actually quite straightforward to emulate all of the functions of the FT232RL.

So how are you implementing the variable drive current? Do you support both VCP and D2XX drivers? Do you actually emulate the device properly, and if so, why is this even an issue, as surely you'd appear to be a normal FTDI device and they'd be unable to tell the difference?

Don't pretend to be what you're not - use a generic driver or write your own.

Quote
I'm not sure if you think that FTDI chips are some kind of black magic, especially the low end ones.

 ::)
 

Offline all_repair

  • Frequent Contributor
  • **
  • Posts: 716
Re: FTDIgate 2.0?
« Reply #274 on: February 02, 2016, 05:17:08 pm »
My example was just a purely hypothetical one extrapolated from my experience with how bad some firmware is written. I just can't divulge too much about those experiences for obvious reasons.

Would we all please stop with these nonsense hypotheticals and discuss the actual facts?  So far there is zero proof that there are any counterfeit devices in legitimate supply chains anymore. 

Agree on the hypothetical situations.

While we have not heard of any major blunders in the supply chain like the Newegg and Intel issue a few years back that comes to mind I am sure we can all agree that bad players are constantly trying to infiltrate the supply chain.
I think everyone in the industry shares some responsibility in maintaining the integrity of the supply chain.
There are some kids shouting and keep shouting and defining the supply chain as they wish and imagine.  Any supply chain is as clean as the dirtiest point in the chain.  There were cases and people I knew that were the authorised "CLEAN" channel selling big time to factories, injecting their compatible into the chain.  It took many years for the OEM to find out, because these guys got too greedy and prompted the OEM to investigate.  But the factories were kept in the dark even until now.  It happened, I am sure it is still happening and will never stop happening as long as there are some quick money to be made somewhere.  It is a  forever cat and mouse game.  FTDI is spraying bullets as they like. 
BTW those guys walked off almost trouble-free.  They lost the distributorship but kept the millions (today value should be billions) they had made, because the OEM dared not sue them and had the most to hide, the most to loose.
« Last Edit: February 02, 2016, 05:27:25 pm by all_repair »
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf