Author Topic: FTDIgate 2.0?  (Read 382808 times)

0 Members and 7 Guests are viewing this topic.

Offline CatalinaWOW

  • Super Contributor
  • ***
  • Posts: 5173
  • Country: us
Re: FTDIgate 2.0?
« Reply #800 on: February 29, 2016, 10:14:34 pm »
I support Karel's efforts to support his own interests.  He (or she) is only doing what every one else here is doing.  I can't tell whether those interests are employment or maintaining a viable supplier for the designs he has implemented and supports, or perhaps a future bricking effort on some other unrelated product line, or something else but as a point of view they all are as good as any expressed here. 

Despite his dismissive comments about "hobbiests and semi-professionals" he feels their comments are worth the effort of debating.  That is validation of sorts for those involved.
 

Offline Gyro

  • Super Contributor
  • ***
  • Posts: 9410
  • Country: gb
Re: FTDIgate 2.0?
« Reply #801 on: February 29, 2016, 10:36:15 pm »
Well that's a couple of good takes on the 'Why' at least :)

I just wanted to try to insert a sanity breakpoint in case you were truly trapped in an infinite loop from which you were now incapable of escaping (still not entirely convinced on that one though!).

I shall try very much harder to avoid noticing this thread in future and worse still, opening it. It's just a bit like fingernails scratching down a blackboard every time I do.  :D

Good luck with it.
Best Regards, Chris
 

Offline miguelvp

  • Super Contributor
  • ***
  • Posts: 5550
  • Country: us
Re: FTDIgate 2.0?
« Reply #802 on: March 01, 2016, 12:02:34 am »
Intel does the same thing with their compiler, when caught they didn't change the compiler but they offered the following statement regarding using the C++ Intel compiler on non-Intel chips:

https://software.intel.com/en-us/articles/optimization-notice

As far as I know, the code generated still runs slower on AMD processors even if they support SSE2 or SSE3. Pretty much they look at the CPU ID and if it says GenuineIntel then the optimized code path runs, otherwise optimization flags are totally ignored.

Not clear if this is a runtime or compile time issue, but Intel doesn't want to support non-Intel architectures on their compiler.
 

Offline suicidaleggroll

  • Super Contributor
  • ***
  • Posts: 1453
  • Country: us
Re: FTDIgate 2.0?
« Reply #803 on: March 01, 2016, 12:53:14 am »
The fact that a non-FTDI chip uses FTDI's driver is fine in my book. There is a long history of third parties making hardware that works with an existing driver. Take the Sound Blaster 16 for example.

And the next time you develop a driver, you are welcome to let everybody under the sun, including your competition, use it for free.  But this is not your driver, this is FTDI's driver, and they've made it abundantly clear that they don't want other manufacturers using it.  It's their call to make, and they made it.

These "legitimate" manufacturers of compatible devices are welcome to distribute a tool to allow their end-users to change the VID/PID to their own, and then write, sign, distribute, and maintain their own driver to interface with it.
« Last Edit: March 01, 2016, 01:00:49 am by suicidaleggroll »
 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7799
  • Country: us
  • adieu
Re: FTDIgate 2.0?
« Reply #804 on: March 01, 2016, 01:56:26 am »
Why does FTDI get to say who can use their driver, once it's on someone else's computer? I don't understand why some of you just assume that.
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 #805 on: March 01, 2016, 02:18:55 am »
It's their driver, of course they get to decide which devices it can talk to.  Just like Xilinx can decide whether or not their tools will program Altera FPGAs.  Even if the protocol was the same and technically it could, it's perfectly within their rights to design it so that it doesn't.
 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7799
  • Country: us
  • adieu
Re: FTDIgate 2.0?
« Reply #806 on: March 01, 2016, 02:33:10 am »
That's not what I meant.
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline zapta

  • Super Contributor
  • ***
  • Posts: 6189
  • Country: us
Re: FTDIgate 2.0?
« Reply #807 on: March 01, 2016, 05:34:02 am »
I just wanted to try to insert a sanity breakpoint in case you were truly trapped in an infinite loop from which you were now incapable of escaping (still not entirely convinced on that one though!).

Here is a visualization of this thread

 

Offline timb

  • Super Contributor
  • ***
  • Posts: 2536
  • Country: us
  • Pretentiously Posting Polysyllabic Prose
    • timb.us
Re: FTDIgate 2.0?
« Reply #808 on: March 01, 2016, 08:35:33 am »

It's their driver, of course they get to decide which devices it can talk to.  Just like Xilinx can decide whether or not their tools will program Altera FPGAs.  Even if the protocol was the same and technically it could, it's perfectly within their rights to design it so that it doesn't.

Apples to oranges, and you know it.

Actually, this brings up a good point. I want you to explain to me exactly what you think FTDI is accomplishing by making their driver not work with/brick/spit bad data out in the first place. 

The way I see it, the only thing FTDI is accomplishing here (besides alienating their customers) is making better clones.

Why? Well, the clone maker fixed the original vulnerability that allowed FTDI to tell the difference. So, FTDI wasn't really stopping future clones. Instead, they just annoyed everyone with a product that happened to have a clone chip in it. But, it's not like those customers can't just roll back to the older version of the driver and still use the clones.

So, aside from ending up with better clones and egg on their face, what was the point? Now, if these were *actual* counterfeit (mask copies) FTDI's driver wouldn't be able to tell the difference anyway.

This is no different than IBM vs Compaq. You're right, FTDI has every right to do whatever they want with their driver. However, just like with DRM, they will never win; in fact they've already lost. All it does is serve to inconvenience end users.

If it were *my* driver, I would see the writing on the wall and move on, instead of doubling down on a losing strategy. (In this case, both their driver *and* production of basic USB-UART chips is that losing strategy.)
Any sufficiently advanced technology is indistinguishable from magic; e.g., Cheez Whiz, Hot Dogs and RF.
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2214
  • Country: 00
Re: FTDIgate 2.0?
« Reply #809 on: March 01, 2016, 09:08:53 am »
I want you to explain to me exactly what you think FTDI is accomplishing by making their driver not work with/brick/spit bad data out in the first place. 

To encourage cheap-ass companies not to use counterfeit products?

Well, the clone maker fixed the original vulnerability that allowed FTDI to tell the difference. So, FTDI wasn't really stopping future clones.

FTDI was stopping present counterfeit chips. It could be very well that FTDI has more ways to check for counterfeit chips. Ways that could be used in future driver updates
when new counterfeit chips have been found that have circumvented the old way of detection.

So, aside from ending up with better clones and egg on their face, what was the point?
This is no different than IBM vs Compaq. You're right, FTDI has every right to do whatever they want with their driver. However, just like with DRM, they will never win; in fact they've already lost. All it does is serve to inconvenience end users.

Probably FTDI believes that they will loose more money with other approaches. It's their choice, not yours.

If it were *my* driver, ...

But it isn't, is it?

 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26755
  • Country: nl
    • NCT Developments
Re: FTDIgate 2.0?
« Reply #810 on: March 01, 2016, 10:38:30 am »
If it were *my* driver, I would see the writing on the wall and move on, instead of doubling down on a losing strategy. (In this case, both their driver *and* production of basic USB-UART chips is that losing strategy.)
If think this touches the core of the problem. In order to stay ahead you have to create new products and get into new markets all the time. IBM has been mentioned and even though IBM was forced out of the PC market they still exist today. Or look at Dyson. Dyson succesfully hyped bag-less vacuum cleaners and soon after that others followed with similar products. No problem for Dyson because they have a whole line of products and they even succesfully entered the hand-dryer market.

Now look at FTDI: the only products they are really known for are their USB-UART bridge chips and in a lesser extend their USB FIFO chips.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2214
  • Country: 00
Re: FTDIgate 2.0?
« Reply #811 on: March 01, 2016, 01:06:10 pm »
In order to stay ahead you have to create new products and get into new markets all the time. IBM has been mentioned and even though IBM was forced out of the PC market they still exist today. Or look at Dyson. Dyson succesfully hyped bag-less vacuum cleaners and soon after that others followed with similar products. No problem for Dyson because they have a whole line of products and they even succesfully entered the hand-dryer market.

Now look at FTDI: the only products they are really known for are their USB-UART bridge chips and in a lesser extend their USB FIFO chips.

Ok, let's assume for a moment that FTDI isn't  innovative anymore and maybe, because of that, they will vanish in 5 to 10 years.
If they can extend that period with a couple of years by protecting their IP, why not? They have the right to use their IP as a cash cow as long as possible.
Ethically, there's nothing wrong with that.

 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26755
  • Country: nl
    • NCT Developments
Re: FTDIgate 2.0?
« Reply #812 on: March 01, 2016, 01:22:32 pm »
In theory yes but what FTDI did to protect their IP is borderline criminal so they must be very desperate to milk their existing IP any way they can for as long as they can. Appearantly plan B isn't working for FTDI otherwise they would have moved on a long time ago. Another good reason to not use FTDI parts: they may be gone in a few years!
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline suicidaleggroll

  • Super Contributor
  • ***
  • Posts: 1453
  • Country: us
Re: FTDIgate 2.0?
« Reply #813 on: March 01, 2016, 03:43:33 pm »

It's their driver, of course they get to decide which devices it can talk to.  Just like Xilinx can decide whether or not their tools will program Altera FPGAs.  Even if the protocol was the same and technically it could, it's perfectly within their rights to design it so that it doesn't.

Apples to oranges, and you know it.
You're right, it's not a good comparison, because in my example the Altera device just happened to be compatible.  A better comparison would be if Altera intentionally designed their products to impersonate Xilinx devices, so they could piggy-back off of Xilinx's toolchain and not have to develop or maintain one of their own.  You can bet your ass if they tried to pull something like that, Xilinx would try to find a way to block it, and nobody would be surprised (well, I would think so, but after reading this thread I'm not so sure there wouldn't be a group of people asking for the Xilinx CEO's head on a platter).

Actually, this brings up a good point. I want you to explain to me exactly what you think FTDI is accomplishing by making their driver not work with/brick/spit bad data out in the first place.
Easy, and I've already said it many times before.
Q: Why are they trying to make their driver not work with counterfeit chips?
A: To discourage cheap manufacturers from using counterfeit chips, and ultimately, to discourage the counterfeiters.  Do you really think the counterfeiters are going to just keep up this cat and mouse game?  Why on earth would they do that when they can just start counterfeiting a different manufacturer who doesn't try to restrict the use of their driver?  As you and others have said many times, FTDI USB-UART bridges are nothing special these days, so why are you so insistent that the counterfeiters would keep dumping time and money into running around driver restrictions when they could just move to somebody else?  That's FTDI's goal, discourage counterfeiters enough that they move to another target.

Q: Why are they throwing out "bad" or "garbage" data?
A: First, it's not "bad data", "bad data" would be if they made random changes and spit out nonsense.  It's not bad data, it's a message, a very clear message explaining why it's not working.  The alternative would be to send nothing and bury an error code or message deep in the bowels of the system logs where it will never see the light of day.  It's a valid alternative, but FTDI must have weighed the options and made the decision that it's better to send out a very clear message where anybody using the device will see, risking the fallout from a few devices that might misbehave when it receives data it doesn't expect, but significantly reducing debugging time by affected manufacturers.  They probably made the assumption that affected manufacturers WANT TO KNOW that they have a counterfeit device in their product, and the easier they can make that discovery the better.  It doesn't really matter for the end-user, because the device has to go back to the manufacturer anyway.
« Last Edit: March 01, 2016, 03:50:47 pm by suicidaleggroll »
 

Offline CatalinaWOW

  • Super Contributor
  • ***
  • Posts: 5173
  • Country: us
Re: FTDIgate 2.0?
« Reply #814 on: March 01, 2016, 04:39:34 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.
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26755
  • Country: nl
    • NCT Developments
Re: FTDIgate 2.0?
« Reply #815 on: March 01, 2016, 04:44:39 pm »
Q: Why are they throwing out "bad" or "garbage" data?
A: First, it's not "bad data", "bad data" would be if they made random changes and spit out nonsense.  It's not bad data, it's a message, a very clear message explaining why it's not working.  The alternative would be to send nothing and bury an error code or message deep in the bowels of the system logs where it will never see the light of day.
Sorry but that is just plain wrong! Windows will show a message when an USB device cannot load it's driver properly. Also the device manager will show a device was attached for which the driver isn't working. From there it is a small step to look into the log files. Either way there are enough ways to show the user something is wrong without bricking devices or sending random data (from the perspective of any device attached).
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2214
  • Country: 00
Re: FTDIgate 2.0?
« Reply #816 on: March 01, 2016, 04:47:39 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.
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2214
  • Country: 00
Re: FTDIgate 2.0?
« Reply #817 on: March 01, 2016, 04:50:03 pm »
... or sending random data (from the perspective of any device attached).

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

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26755
  • Country: nl
    • NCT Developments
Re: FTDIgate 2.0?
« Reply #818 on: March 01, 2016, 04:55:11 pm »
... or sending random data (from the perspective of any device attached).
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".
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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2214
  • Country: 00
Re: FTDIgate 2.0?
« Reply #819 on: March 01, 2016, 05:01:52 pm »
... or sending random data (from the perspective of any device attached).
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".
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.

 

Offline CatalinaWOW

  • Super Contributor
  • ***
  • Posts: 5173
  • Country: us
Re: FTDIgate 2.0?
« Reply #820 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: 7799
  • Country: us
  • adieu
Re: FTDIgate 2.0?
« Reply #821 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: 7695
  • Country: de
  • A qualified hobbyist ;)
Re: FTDIgate 2.0?
« Reply #822 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: 2214
  • Country: 00
Re: FTDIgate 2.0?
« Reply #823 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.


 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7799
  • Country: us
  • adieu
Re: FTDIgate 2.0?
« Reply #824 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 :)
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf