Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FTDI driver kills fake FTDI FT232s

eevblog.com

Post reply on HN
Print view View original

241–250 of 315 posts

Re: FTDI driver kills fake FTDI FT232s

#241

Post by deelowe »

anigbrowl wrote: post #137
0x0 wrote: post #119

Earlier quoted context omitted.

As mentioned elsewhere, it's almost impossible to make sure parts like these aren't counterfeit. And the parts aren't "junk", they're just unlicensed.

Not any more. Now you can just test the prototype to see if it runs the FDTI driver correctly. If it fails, your supplier doesn't get paid.

Um... how exactly do you think the electronics business works, because it's nothing like what you just described. The vendor is often 3 to 5 times (or more) removed from the sourcing of individual components.

Re: FTDI driver kills fake FTDI FT232s

#242

Post by deelowe »

rasz_pl wrote: post #231

Those devices are NOT bricked/broken! They are ABSOLUTELY FINE. You just need to use proper driver straight from the _real_ manufacturer - Supereal Microelectronics (or whatever). Feel free to ask "Suzhou Supereal Microelectronics" for a working driver for your counterfeit device.

You realize reverse engineering is legal and actually protected by law right? Tampering with other vendors' computer systems is not (in the software world that's called maleware).

The "counterfeiting" issue is a trademark problem only. In other words, the only thing wrong here is that the Chinese manufacturer stamped FTDI on their chips. There's nothing in trademark law that says it's OK to use these tactics to combat the issue. Why would there be? The two are completely orthogonal to each other. If there are chips out there that emulate FTDI and do not have the logo, FTDI has most certainly broken the law. As others have pointed out, this would be like Intel damaging AMD chips simply because they identify themselves in a similar manner. (again, minus the bit about trademark which is again, orthogonal to what FTDI has done here).

Re: FTDI driver kills fake FTDI FT232s

#243

Post by cnvogel »

Here's someone claiming to have found the responsible function in a driver.

PLEASE NOTE: ALL NAMES HAVE BEEN CHOSEN FREELY BY THE PERSON WHO MADE THE SCREENSHOT! So there's no name "BrickCLoneDevices()", it's probably called UpdateEEPromChksum or something like that in the original code, because it looks like that's what it does.

http://www.eevblog.com/forum/reviews/ftdi-driver-kills-fake-...

Assuming that this disassembly/decompiled code indeed is genuine, the interesting thing is explained in the 2nd comment block: A genuine FTDI device seems to be designed such that a write only to the offset that stores the PID is ignored, hence for a genuine part this code will only update the word at offset 62, and that would be matching the functionality to just update the eeprom checksum.

For comparison, here's a random mainling-list post which includes a dump of the 232 eeprom. The VID/PID is stored at word 1 and 2 of the eeprom, something that could be a checksum is down at the word with offset 0x7f (word 0x3f = 63? There's probably a off-by-one here).

http://developer.intra2net.com/mailarchive/html/libftdi/2009...

Re: FTDI driver kills fake FTDI FT232s

#244

Post by _pmf_ »

wtallis wrote: post #100
lotu wrote: post #94

Earlier quoted context omitted.

I'm sure you realize that the counterfeiters operate in such a fashion and in regions of the world that make sueing them impossible. Which suck because it means FTDI really has no options to enforce their IP rights that don't hurt consumers.

FTDI is almost certainly trying to exercise IP rights that don't actually exist, because breaking other people's stuff is not an authorized method for dealing with trademark infringement.

> because breaking other people's stuff is not an authorized method for dealing with trademark infringement.

The device violates the USB specification by using a protected VID; it is already to be considered as broken regarding the USB specification.

Re: FTDI driver kills fake FTDI FT232s

#245

Post by jrockway »

beagle3 wrote: post #88

Does this qualify as a CFAA violation? I think so and for monetary gain, no less. I would like to hear why wouldn't the DA that leaned so hard on Swartz wouldn't do the same FTDI's CEO.

Technically the counterfeit devices should have never been allowed into the country. So it should be interesting how this plays out.

Re: FTDI driver kills fake FTDI FT232s

#247

Post by azernik »

duncan_bayne wrote: post #164
duncan_bayne wrote: post #158

I tried reporting this to Microsoft; their handling of calls to report security vulnerabilities was just horrendous. ===== Hi, I've been advised to email this address by 'XXXX' at Microsoft Support. FTDI is shipping a malware driver for Windows; if it detects what it thinks is a counterfeit device plugged in by USB, it bricks it. Details here: http://www.eevblog.com/forum/reviews/ftdi-driver-kills-fake-... I've also…

An update to this: the security folks have told me it’s not a security issue, but they’re forwarding it to the appropriate team. Perhaps I’m biased, but I’d have thought that a Windows Update that ships malware that bricks thousands of consumer devices without warning would constitute a security issue. But hey … at least they’re actioning it, and they responded so quickly. So, FYI: if you have a security issue to rep…

Bureaucratically, it probably isn't a security issue for Microsoft; they have a separate department (probably legal, although maybe a separate hardware vendor relations group) that is much better at dealing with a named, legal organization like FTDI.

Re: FTDI driver kills fake FTDI FT232s

#248

Post by sigterm »

0x0 wrote: post #119
anigbrowl wrote: post #117

Earlier quoted context omitted.

Then the manufacturer is responsible for using junk parts to save money.

As mentioned elsewhere, it's almost impossible to make sure parts like these aren't counterfeit. And the parts aren't "junk", they're just unlicensed.

Whoever is in charge of sourcing for life-critical application and let the sketchy part slip in should be held responsible for it.

>the parts aren't "junk"

You don't know for sure. How likely is it that the manufacturer of the knock-off part performed full characterization of their chip to ensure they are within spec limits of the original manufacturer? What if the chip starts sending wrong bits when the temperature gets a bit high or voltage supply fluctuates somewhat? Don't you think getting disabled by driver might even be a less disastrous failure mode in this case?

Re: FTDI driver kills fake FTDI FT232s

#249

Post by Kliment »

yuhong wrote: post #101
npsimons wrote: post #91

Earlier quoted context omitted.

I hope this causes a major and publicly visible malfunction in some important device/installation/machinery, of course with no harm done to any persons I actually hope that this does cause an event drastic enough so that FTDI will have blood on its hands that ends in jail time for management and engineers. I don't want to see anyone hurt, especially not innocent third parties, but fuck FTDI, fuck the management who o…

I think standardizing the interface would be more important.

Well, the core issue is that there isn't a standard vendor-independent device class driver for CDC devices in Windows like there is for say HID. This is a solved problem on pretty much every other OS. The only reason a manufacturer would make devices that use the same vid as an FT232R as opposed to a functionally-identical pin-compatible device with a different vid is because the drivers included in Windows are vendor-tied. You don't see this kind of issues with no-name mice or keyboards for example because they don't need a vendor-specific driver.

Re: FTDI driver kills fake FTDI FT232s

#250

Post by cnvogel »

wolfgke wrote: post #154
tptacek wrote: post #111

Earlier quoted context omitted.

Tangentially: people totally would fault FTDI for releasing drivers that don't work with counterfeit parts. See: Apple detecting and rejecting counterfeit iPhone cables.

The correct way is to detect counterfeit parts, display a huge warning and let the customer continue on their own risk. A similar process is used by the Linux kernel developers for non-opensource kernel modules: If you load them, the kernel becomes "tainted" and you won't get any support from the kernel developers if something goes wrong.

Yes, this would be smart.

Probably just putting a message with priority "Error" in the windows event log would be enough to warn computer-literate users.

Post reply on HN