FTDI driver kills fake FTDI FT232??

[krater]

Y, I just heard the 'makers' over at hackaday are boycotting FTDI and now sales are down by 10, possibly 11 chips this year so they had to fire their marketing dept. Sorry Internet you will have to make do with me

T

 

[wraper]

Unless you have an xray machine you have no way of knowing if it is fake, you can just see that chip with a certain name on the top doesn't work

I think that oscilloscope on usb lines probably would do. As the fake chip might even not have a proper USB hardware, rise times might be quiet different. Also there could be a lot of jitter. Measuring current consumption would tell a lot too.

The fakes chip is probably use some kind of usb microcontroller, there will be no difference on the USB lines
Any difference in the current consumption could easily drown in what ever else is on the board, LEDs etc.

Are you so sure that there won't be difference. As I played with usb, even signal from different usb controllers within the same motherboard looked noticeably different (low an full speed). As this is not high speed USB, there shouldn't be any issue to test it. As of LEDs and else on the board. This is not about testing already made devices but screening incoming parts on the test jig/breakout board.

[Lightages]

I am sorry I reacted to this. KPR8 has joined only to comment on this thread and has posted nowhere else. Sorry for feeding him.

[linux-works]

how long before real virus writers latch onto this idea and brick REAL ftdi chips?

I am betting it will happen.  just a matter of when.

actually, I've never had a virus break hardware.  but it seems I have had legit companies brick hardware that they had no rights to..

willful destruction of other peoples' property.  really hard to believe ftdi didn't check their legal dept before pulling this boner of a stunt.

if I did own ftdi stock, I'd be selling it all now.

[uski]

Seems unlikely

Based on what ?
I only wanted to highlight that not only hobbyists are present on this forum.

I can tell you our lawyers are going to have lots of fun in court if this is to happen.

Well, they will send you a big bill anyway

Probably lower than replacing 100K devices. If what I described happens, we'll try to get FTDI pay for the devices they bricked.

I have absolutely no way to be absolutely sure I haven't been sold a fake. So I cannot take the risk.

Erm, buy from FTDI China?

http://www.dailymail.co.uk/news/article-2148527/Flood-counterfeit-parts-China-used-U-S-military-gear--compromise-national-security-raise-defence-costs.html

If the military can't protect themselves from counterfeit parts, I can't be sure I'm protected too.
I do not have any way to know where the parts come from, apart from trusting my distributors.

I can also tell you I will send an e-mail tomorrow to our FTDI distributor asking for an explanation of the situation.

Get help with the grammar

The fact that I'm not an english speaker does not remove my ability to contribute to this forum.
It is really a pity you attack me on the grammar.

Trolley

My posts adds more value than yours. Get a life.

[nitro2k01]

Unless you have an xray machine you have no way of knowing if it is fake, you can just see that chip with a certain name on the top doesn't work

I think that oscilloscope on usb lines probably would do. As the fake chip might even not have a proper USB hardware, rise times might be quiet different. Also there could be a lot of jitter. Measuring current consumption would tell a lot too.

The fakes chip is probably use some kind of usb microcontroller, there will be no difference on the USB lines
Any difference in the current consumption could easily drown in what ever else is on the board, LEDs etc.

Are you so sure that there won't be difference. As I played with usb, even signal from different usb controllers within the same motherboard looked noticeably different (low an full speed). As this is not high speed USB, there shouldn't be any issue to test it. As of LEDs and else on the board. This is not about testing already made devices but screening incoming parts on the test jig/breakout board.

If the FTDI driver can detect fake chips, then a test jig can likely use the same method and do it without going low level (electrical characteristics.)

[duncan_bayne]

I reported this to Microsoft via their security vulnerability channels (figuring that a driver that intentionally bricked hardware, and shipped through Windows Update, constituted a security vulnerability).

Anyway, after some initial shenanigans I got through to their security folks who were very helpful.  Apparently they don't consider it a security problem, but they're aware of it and are investigating already.  I hope they're going to come down on FTDI like a ton of bricks for this.  Especially as end-users will blame Microsoft: "I had a working device, then Windows Update ran, and now it's dead, and it's out of warranty ... "

[krater]

how long before real virus writers latch onto this idea and brick REAL ftdi chips?

Hey that was my idea some pages ago !! ;P

[BartManInNZ]

So has anyone actually identified the Windows Update that introduced the updated driver?
Seems to me that removing this should restore the previous driver preventing the issue- has anyone tested this?

[uski]

If the FTDI driver can detect fake chips, then a test jig can likely use the same method and do it without going low level (electrical characteristics.)

Realistically a company is not going to modify its production test jigs to check for the authenticity of the parts they use, especially because they may not know they are being shipped counterfeit parts until it's too late (= driver modification bricking the chips). You can't detect something you are not looking for.

What FTDI did is nonsense.

[linux-works]

I'm still hoping that someone has a link to the last GOOD ftdi driver.  I'd like to capture it and save it, plus blacklist the MS patch so that it won't ever happen on any other windows box I admin, ever again.

if someone who has a windows background could create a simple .bat file that will blacklist/block this particular windows update, that would be a great service to us all.

[kolonelkadat]

I wonder if this is the "revenge shot" of a dead/dieing company. I dunno. It seems like more and more companies are abandoning hardware production as theres just no money in it with chinese slave labor being what it is.

[senso]

Just seen this, I have a iTead FOCA and all it does is spitting out <0>'s in the terminal program, got me puzzled about how I was failing so bad in the UART code of the MCU, turned out to be a fake chip and recent drivers(this happened more than a month ago).

[KPR8]

Seems unlikely

Based on what ?
I only wanted to highlight that not only hobbyists are present on this forum.

Experience

I can tell you our lawyers are going to have lots of fun in court if this is to happen.

Well, they will send you a big bill anyway

Probably lower than replacing 100K devices. If what I described happens, we'll try to get FTDI pay for the devices they bricked.

And you will fail 100% not FTDI's fault

I have absolutely no way to be absolutely sure I haven't been sold a fake. So I cannot take the risk.

Erm, buy from FTDI China?

http://www.dailymail.co.uk/news/article-2148527/Flood-counterfeit-parts-China-used-U-S-military-gear--compromise-national-security-raise-defence-costs.html

If the military can't protect themselves from counterfeit parts, I can't be sure I'm protected too.
I do not have any way to know where the parts come from, apart from trusting my distributors.

FTDI China's contact details are at the end of official FTDI datasheets, pretty sure they are legit. They also do their due diligence when you apply to buy from them, they dont sell to brokers for fear of feeding the counterfeit market

I can also tell you I will send an e-mail tomorrow to our FTDI distributor asking for an explanation of the situation.

Get help with the grammar

The fact that I'm not an english speaker does not remove my ability to contribute to this forum.
It is really a pity you attack me on the grammar.

My bad

My posts adds more value than yours. Get a life.

Only in your opinion

[KPR8]

I reported this to Microsoft via their security vulnerability channels ... I got through to their security folks who were very helpful.  Apparently they don't consider it a security problem, but they're aware of it and are investigating already. 

don't consider it a security problem

I hope they're going to come down on FTDI like a ton of bricks for this. 

Y, M$ hate when ppl protect their IP

Troll

[linux-works]

what facts do you dispute or question?

today, after reading this, I uninstalled  the ftdi update on my win7 box, but it was too late.  the driver was still mem-resident and when I plugged in a test dongle that I bought from amazon, it zeroed out the pid.  I confirmed it by plugging it into a linux box and looking at /var/log/syslog.  sure enough, the pid is all 0's and was NOT all 0's before (I had used that dongle on both win and linux just recently).

none of that is opinion.  not sure what else you need, but people are not making this up..

[wraper]

If the FTDI driver can detect fake chips, then a test jig can likely use the same method and do it without going low level (electrical characteristics.)

Realistically a company is not going to modify its production test jigs to check for the authenticity of the parts they use, especially because they may not know they are being shipped counterfeit parts until it's too late (= driver modification bricking the chips). You can't detect something you are not looking for.

What FTDI did is nonsense.

If the company buys parts from shady sources and do not make proper screening they can blame only themselves.

[langwadt]

Unless you have an xray machine you have no way of knowing if it is fake, you can just see that chip with a certain name on the top doesn't work

I think that oscilloscope on usb lines probably would do. As the fake chip might even not have a proper USB hardware, rise times might be quiet different. Also there could be a lot of jitter. Measuring current consumption would tell a lot too.

The fakes chip is probably use some kind of usb microcontroller, there will be no difference on the USB lines
Any difference in the current consumption could easily drown in what ever else is on the board, LEDs etc.

Are you so sure that there won't be difference. As I played with usb, even signal from different usb controllers within the same motherboard looked noticeably different (low an full speed). As this is not high speed USB, there shouldn't be any issue to test it. As of LEDs and else on the board. This is not about testing already made devices but screening incoming parts on the test jig/breakout board.

If the FTDI driver can detect fake chips, then a test jig can likely use the same method and do it without going low level (electrical characteristics.)

The FTDI driver will be using some undocumented feature in the chip, so only FTDI could build that test

If the feature was documented the fakers would have implemented it, it's not like it is rocket science to make a usb microcontroller behave like an FTDI but you can only implement the stuff you know about
 

[KPR8]

Unless you have an xray machine you have no way of knowing if it is fake, you can just see that chip with a certain name on the top doesn't work

I think that oscilloscope on usb lines probably would do. As the fake chip might even not have a proper USB hardware, rise times might be quiet different. Also there could be a lot of jitter. Measuring current consumption would tell a lot too.

The fakes chip is probably use some kind of usb microcontroller, there will be no difference on the USB lines
Any difference in the current consumption could easily drown in what ever else is on the board, LEDs etc.

Are you so sure that there won't be difference. As I played with usb, even signal from different usb controllers within the same motherboard looked noticeably different (low an full speed). As this is not high speed USB, there shouldn't be any issue to test it. As of LEDs and else on the board. This is not about testing already made devices but screening incoming parts on the test jig/breakout board.

If the FTDI driver can detect fake chips, then a test jig can likely use the same method and do it without going low level (electrical characteristics.)

The FTDI driver will be using some undocumented feature in the chip, so only FTDI could build that test

If the feature was documented the fakers would have implemented it, it's not like it is rocket science to make a usb microcontroller behave like an FTDI but you can only implement the stuff you know about

In your dreams dofus, the cloners will do 'just enough' to make the PoS chip work. 10-1 this is the set VID/PID command and it so happens the genuine parts reject a PID of 0000 but the clones don't. The cloners never saw that cmd and so never implemented a check for it.

Dont make me get my USB analyser out...

[nctnico]

what facts do you dispute or question?

today, after reading this, I uninstalled  the ftdi update on my win7 box, but it was too late.  the driver was still mem-resident and when I plugged in a test dongle that I bought from amazon, it zeroed out the pid.  I confirmed it by plugging it into a linux box and looking at /var/log/syslog.  sure enough, the pid is all 0's and was NOT all 0's before (I had used that dongle on both win and linux just recently).

Same here:
[89593.509194] usb 2-4.2.4: new full speed USB device using ehci_hcd and address 36
[89593.979468] usb 2-4.2.4: New USB device found, idVendor=0403, idProduct=0000
[89593.979472] usb 2-4.2.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[89593.979475] usb 2-4.2.4: Product: FT232R USB UART
[89593.979477] usb 2-4.2.4: Manufacturer: FTDI
[89593.979480] usb 2-4.2.4: SerialNumber: A961PFBR

[duncan_bayne]

Y, M$ hate when ppl protect their IP

Troll

I'm a professional programmer who co-founded a company that sold a Windows-based DRM system for protecting revenue from software sales.  I'm totally okay with companies protecting their intellectual property; for a while I was making a living from doing just that.

But, to be clear, bricking third-party hardware is malicious.  This driver is malware by any reasonable definition of the term.

[KPR8]

Turns out there are sane ppl on Hackaday:

Andres R (@TheFakeAndres) says:
October 22, 2014 at 11:49 am

Buy counterfeit equipment, deal with counterfeit problems.
Didn’t know you bought a piece of equipment that was counterfeit and infringed on IP, trademark and licensing? Now you know, because FTDI just brought it to your attention by taking back their licensing right – device isn’t bricked as in unrepairable, they just removed one of the infringing portions that they could change (using the driver that you installed, gave permission). Do people want to start signing EULAs for drivers now? No. So either know what you are installing (research) or just deal with it.

Who would have thunk?

[Rufus]

Realistically a company is not going to modify its production test jigs to check for the authenticity of the parts they use, especially because they may not know they are being shipped counterfeit parts until it's too late (= driver modification bricking the chips). You can't detect something you are not looking for.

The driver did not brick anything. FTDI drivers now refuse to work with non-FTDI chips and made it retrospective.

You bought chips with no drivers, you were using the chips with stolen drivers and now you are bitching at the owner of the drivers because they took them back. FTDI will tell you that if you want to use someone else's chips then use someone else's drivers.

[nctnico]

what facts do you dispute or question?

today, after reading this, I uninstalled  the ftdi update on my win7 box, but it was too late.  the driver was still mem-resident and when I plugged in a test dongle that I bought from amazon, it zeroed out the pid.  I confirmed it by plugging it into a linux box and looking at /var/log/syslog.  sure enough, the pid is all 0's and was NOT all 0's before (I had used that dongle on both win and linux just recently).

none of that is opinion.  not sure what else you need, but people are not making this up..

I'd like to see the driver reprogramming the chip to set all 0's and/or the chip read before AND after that reveals the internal contents. Just because a driver for some as yet unknown reason fails to read the PID from the chip correctly and hence is unable to set the value in the OS control blocks from something other than the initialised 0's, doesn't leave the only remaining possibility that the chip is bricked.

I have one left (the rest of the boards I bought are still on a boat) so here it goes:
Before:
[178302.833023] usb 2-4.2.4: new full speed USB device using ehci_hcd and address 43
[178303.303679] usb 2-4.2.4: New USB device found, idVendor=0403, idProduct=6001
[178303.303683] usb 2-4.2.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[178303.303686] usb 2-4.2.4: Product: FT232R USB UART
[178303.303688] usb 2-4.2.4: Manufacturer: FTDI
[178303.303690] usb 2-4.2.4: SerialNumber: A9U5PFN7
[178303.303779] usb 2-4.2.4: configuration #1 chosen from 1 choice
[178303.350681] ftdi_sio 2-4.2.4:1.0: FTDI USB Serial Device converter detected
[178303.350702] usb 2-4.2.4: Detected FT232RL
[178303.350705] usb 2-4.2.4: Number of endpoints 2
[178303.350707] usb 2-4.2.4: Endpoint 1 MaxPacketSize 64
[178303.350710] usb 2-4.2.4: Endpoint 2 MaxPacketSize 64
[178303.350712] usb 2-4.2.4: Setting MaxPacketSize 64
[178303.351059] usb 2-4.2.4: FTDI USB Serial Device converter now attached to ttyUSB1

After:
[178453.772118] usb 2-4.2.4: reset full speed USB device using ehci_hcd and address 43
[178454.052482] usb 2-4.2.4: device firmware changed
[178454.053230] usb 2-4.2.4: USB disconnect, address 43
[178454.127953] usb 2-4.2.4: new full speed USB device using ehci_hcd and address 44
[178454.602228] usb 2-4.2.4: New USB device found, idVendor=0403, idProduct=0000
[178454.602231] usb 2-4.2.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[178454.602233] usb 2-4.2.4: Product: FT232R USB UART
[178454.602234] usb 2-4.2.4: Manufacturer: FTDI
[178454.602236] usb 2-4.2.4: SerialNumber: A9U5PFN7
[178454.602314] usb 2-4.2.4: configuration #1 chosen from 1 choice

[linux-works]

what facts do you dispute or question?

today, after reading this, I uninstalled  the ftdi update on my win7 box, but it was too late.  the driver was still mem-resident and when I plugged in a test dongle that I bought from amazon, it zeroed out the pid.  I confirmed it by plugging it into a linux box and looking at /var/log/syslog.  sure enough, the pid is all 0's and was NOT all 0's before (I had used that dongle on both win and linux just recently).

none of that is opinion.  not sure what else you need, but people are not making this up..

I'd like to see the driver reprogramming the chip to set all 0's and/or the chip read before AND after that reveals the internal contents. Just because a driver for some as yet unknown reason fails to read the PID from the chip correctly and hence is unable to set the value in the OS control blocks from something other than the initialised 0's, doesn't leave the only remaining possibility that the chip is bricked.

I have a few more ftdi 'fakes' that came from the same amazon vendor.

I guess, for those doubting thomas' out there, I could create a video of a 'clean' win7 box working with the fake chip, then doing a win update, plugging the dongle in again, viewing its properties dialog and showing the vendor/product id's.  even taking that dongle out, moving it to a linux box and capturing the /var/log/syslog.

but that's a lot of effort and honestly, I'm not sure anyone really doubts that this is what is really happening.

the moon landing, that was fake. but this chip bricking is real, mate.

(semi lol)