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

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.




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

Search: