Author Topic: FTDIgate 2.0?  (Read 229722 times)

0 Members and 1 Guest are viewing this topic.

Offline Karel

  • Super Contributor
  • ***
  • Posts: 1280
  • Country: 00
Re: FTDIgate 2.0?
« Reply #825 on: March 01, 2016, 05:59:06 am »
Who cares how clear they made it? If they put the software on my computer I'm going to use it however the hell I want. At no point did I ever agree to only do things FTDI likes.

You do whatever you like. Just as FTDI does.
You can stamp your feet as much as you want but I don't think it's going to help you.

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 Gyro

  • Super Contributor
  • ***
  • Posts: 3779
  • Country: gb
Re: FTDIgate 2.0?
« Reply #826 on: March 01, 2016, 07:19:15 am »
I'm really curious, 34 pages on, what excuse do the rest of you have to keep feeding this guy?  :-// You can't really be enjoying or getting any benefit from it by now, surely? Life just seems too short.
"Victor Meldrew, the Crimson Avenger!"
 

Offline timb

  • Super Contributor
  • ***
  • Posts: 2528
  • Country: us
  • Pretentiously Posting Polysyllabic Prose
    • timb.us
Re: FTDIgate 2.0?
« Reply #827 on: March 01, 2016, 08:59:05 am »

Regarding PC clones, they did have to write their own compatible BIOS. It's not like they did the clone and tell people to use unmodified IBM ROMs.

Edit: I do recall some IBM software that actually checked the BIOS to make sure it was running on IBM hardware. It was a paint program but I bet that BIOS check was in some of their offerings.

These so called "counterfeit" and "clone" chips aren't actually mask copies of FTDI's die. In most cases, they're small MCU's that have been programmed to emulate the FTDI command set. So, the only difference between this and Compaq cloning IBM's bios is that *some* of these chips are being remarked as FTDI chips, which is wrong.

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.
Any sufficiently advanced technology is indistinguishable from magic; e.g., Cheez Whiz, Hot Dogs and RF.
 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7805
  • Country: us
  • adieu
Re: FTDIgate 2.0?
« Reply #828 on: March 01, 2016, 09:04:39 am »
You do whatever you like. Just as FTDI does.

Yup, and I get to have an opinion on what they've done, just like they do on what I've done...

I'm really curious, 34 pages on, what excuse do the rest of you have to keep feeding this guy?  :-// You can't really be enjoying or getting any benefit from it by now, surely? Life just seems too short.

Because I'm an idiot and this godforsaken thread isn't in one of the boards I was smart enough to block...
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline CatalinaWOW

  • Super Contributor
  • ***
  • Posts: 2895
  • Country: us
Re: FTDIgate 2.0?
« Reply #829 on: March 01, 2016, 09:14:34 am »
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: 3779
  • Country: gb
Re: FTDIgate 2.0?
« Reply #830 on: March 01, 2016, 09:36:15 am »
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.
"Victor Meldrew, the Crimson Avenger!"
 

Offline miguelvp

  • Super Contributor
  • ***
  • Posts: 5549
  • Country: us
Re: FTDIgate 2.0?
« Reply #831 on: March 01, 2016, 11: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: 1455
  • Country: us
Re: FTDIgate 2.0?
« Reply #832 on: March 01, 2016, 11: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, 12:00:49 pm by suicidaleggroll »
 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7805
  • Country: us
  • adieu
Re: FTDIgate 2.0?
« Reply #833 on: March 01, 2016, 12:56:26 pm »
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: 1455
  • Country: us
Re: FTDIgate 2.0?
« Reply #834 on: March 01, 2016, 01:18:55 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.
 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7805
  • Country: us
  • adieu
Re: FTDIgate 2.0?
« Reply #835 on: March 01, 2016, 01:33:10 pm »
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: 6004
  • Country: us
Re: FTDIgate 2.0?
« Reply #836 on: March 01, 2016, 04:34:02 pm »
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

Drain the swamp.
 

Online blueskull

  • Supporter
  • ****
  • Posts: 10699
  • Country: cn
  • Power Electronics Guy
Re: FTDIgate 2.0?
« Reply #837 on: March 01, 2016, 06:07:53 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.

Xilinx driver happily supports clone JTAG pods. Also, even when using with an Altera device, it will just fail loop test, not actually sending garbage or brick the Altera device.
 

Offline timb

  • Super Contributor
  • ***
  • Posts: 2528
  • Country: us
  • Pretentiously Posting Polysyllabic Prose
    • timb.us
Re: FTDIgate 2.0?
« Reply #838 on: March 01, 2016, 07:35: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.

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: 1280
  • Country: 00
Re: FTDIgate 2.0?
« Reply #839 on: March 01, 2016, 08:08:53 pm »
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?

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 nctnico

  • Super Contributor
  • ***
  • Posts: 15992
  • Country: nl
    • NCT Developments
Re: FTDIgate 2.0?
« Reply #840 on: March 01, 2016, 09:38:30 pm »
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: 1280
  • Country: 00
Re: FTDIgate 2.0?
« Reply #841 on: March 02, 2016, 12:06:10 am »
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.

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 nctnico

  • Super Contributor
  • ***
  • Posts: 15992
  • Country: nl
    • NCT Developments
Re: FTDIgate 2.0?
« Reply #842 on: March 02, 2016, 12:22:32 am »
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: 1455
  • Country: us
Re: FTDIgate 2.0?
« Reply #843 on: March 02, 2016, 02:43: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.
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 02, 2016, 02:50:47 am by suicidaleggroll »
 

Offline CatalinaWOW

  • Super Contributor
  • ***
  • Posts: 2895
  • Country: us
Re: FTDIgate 2.0?
« Reply #844 on: March 02, 2016, 03:39:34 am »
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: 15992
  • Country: nl
    • NCT Developments
Re: FTDIgate 2.0?
« Reply #845 on: March 02, 2016, 03:44:39 am »
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: 1280
  • Country: 00
Re: FTDIgate 2.0?
« Reply #846 on: March 02, 2016, 03:47:39 am »
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.
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: 1280
  • Country: 00
Re: FTDIgate 2.0?
« Reply #847 on: March 02, 2016, 03:50:03 am »
... 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".
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 nctnico

  • Super Contributor
  • ***
  • Posts: 15992
  • Country: nl
    • NCT Developments
Re: FTDIgate 2.0?
« Reply #848 on: March 02, 2016, 03:55:11 am »
... 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: 1280
  • Country: 00
Re: FTDIgate 2.0?
« Reply #849 on: March 02, 2016, 04:01:52 am »
... 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.

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.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf