Hacker News new | ask | show | jobs
by tmp26 4256 days ago
"bricking" doesn't seem to be the right word. FTDI is making it so that the counterfeit chips don't work with any FTDI drivers, old or new. (Per the thread, all that happens is the PID is changed to a PID that no FTDI driver will recognize)
2 comments

It's not that they just won't work with their drivers, it's that it disables the device so that it's not operable without special (and costly, if they're widely deployed) intervention.

  The new Windows driver changes the PID to 0, and then the driver won't 
  recognize the device (even if you edit the INF file), and you can't use 
  the config tool. The workaround is to use a Windows XP or Linux system to 
  change the PID back, and then don't use the new driver.
Seems an awful lot like bricking to me.

This is really skirting the ethical line and I'm not sure I can agree with their methods. I'm fine with them writing a driver that fails to work with counterfeit chips, but not actively disabling the chip. What if the device is attached to more expensive equipment that will also fail? We can't ensure that these chips are knowingly purchased after all.

This motivation reminds me of when the U.S. and Syrian governments disseminated sabotaged munitions that explode in the weapon, killing/maiming the operator, among their opponents. The danger is that they will find their way back to friendlies.

Or any other drivers, because it breaks it at the USB level, doesn't it?
I don't think so. There was at least one guy in the thread who reprogrammed the PID back, and the chip worked with the old FTDI drivers again, which means the USB interface was working just fine (or else how could he access it to change it back).
Having to write custom driver-level code to repair something falls pretty well inside the accepted usage of "bricked". It's only marginally easier than just hooking up a JTAG interface.
They change the PID to zero, which means Windows won't associate it with FTDI or any other driver. You have to jump through some manual hoops to undo it, which is something most people can't do. So for all intents and purposes it is bricked, a.k.a "locked out".
Most HN'ers seem to agree it is OK for FTDI to prevent their own drivers from working with the fakes, right? The fact that there are no OTHER drivers that are compatible (no matter what the pid is) with the fakes isn't their problem, is it?
It is ok to have SOFTWARE that refuses to work

It is NOT OK to modify the HARDWARE in ANY WAY, including changing the PID.

That is the issue.

Further Most people defending FTDI assume this code will be 100% pure and never incorrectly identify a real chip as fake, I find that claim to be suspect.

Lastly I would find it very hard to support vendors that take these aggressive risks and stances, I certainly would never incorporate a device from a manufacturer that uses these types of tactics into a mass produced product.

Honest question: are you participating in this thread as a greenbean because you want to hide your identity from harassment from those who disagree with your unpopular opinion, or because you want to hide the fact that you are affiliated with FTDI?
Honestly? I rotate accounts on most major sites periodically. It is a tinfoil-hat foible, a way to distance myself from the exceedingly dumb things I have almost certainly said in years past.

Unfortunately for me, I chose today to rotate.

I don't work for FTDI; I'm not even British. But I did build that Adafruit altoid tin MP3 player eight years ago, which used a FT232.

Why am I wasting my time on this argument? I don't really know, aside from I hate the "internet dogpile" effect.

My credibility as a greenbean is nil of course, but oh well.

Edit: obviously folks do not believe me. Serves me right for trying to answer. jessaustin, I hope you at least feel like you got your answer. I get the feeling it doesn't actually matter what I say or even who I really work for- I'm branded.

It's asshole behavior to put code in their drivers specifically to detect and abort even trying to work with fakes, but they are fully entitled to do so.

They are not entitled to break the hardware by changing the PID so it doesn't work with any drivers.

There are other drivers that work when the PID is left intact.

Well, FTDI is leaving their vendor ID intact, and given their behavior so far it wouldn't surprise anyone if they tried to interfere with third-party drivers that enabled using non-FTDI hardware identifying itself with FTDI's vendor ID.
According to the thread the VID is RO?
There are other drivers, on other operating systems that are NOT written by FTDI.