Hacker News new | past | comments | ask | show | jobs | submit login

I don't think that is very straight forward. It's easy to know how your device will operate in various conditions. counterfeits can fail in a million unpredictable ways.



FTDI have code which can tell with some high degree of certainty (at least enough that they trusted it to brick devices!) that a chip is fake.

They've used this code to make counterfeits intentionally unpredictable in the last few versions of their driver, rather than simply stopping the device with an error code (like Prolific do) or notifying the user or client library (like all of these vendors should be doing).

So, for FTDI at least, it should be very straightforward to do something other than intentionally making fakes of their devices behave unpredictably.


Someone at the eevblog analyzed the file. It's setting the PID to 0 in a way that on genuine chips it will only buffer the change, and not actually apply it. If it wasn't a manufacturer with signed drivers pushing this on windows update but a guy at DEFCON explaining his trick I would find it very cool.


They might not have the ability to do that - I could quite easily see the bit of code that can tell if its fake being the same code that bricks the device. Maybe all the real ftdi chips will reject a PID of 0 (as it's invalid), while the fake ones accept it.


Their drivers prior to the bricking drivers (everything after 2.08.14) caused the fake devices to fail, where previously they hadn't.

Whether or not that behavior was intentional, there is clearly an exploitable property of the fake devices which can determine that they are fake without bricking the device.

FTDI should use it rather than playing these games. Their reaction to the discovery of the bricking issue on Twitter and elsewhere yesterday strongly suggests that it was anything but an "oh shit, our driver bricks some of those crappy fakes" moment.


FTDI was asked to return a string like "COUNTERFEITCHIP" or something similar instead of returning zeros, so they instead did a PID reset or some such to disable instead.

A bunch of chips failing with COUNTERFEITCHIP may have been pretty obvious




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: