4 ms·

What I don't understand is why they don't make the messaging more clear. In their pre-bricking drivers, FDTI caused the counterfeits to fail in confusing and co

by bri3d 12y ago

What I don't understand is why they don't make the messaging more clear. In their pre-bricking drivers, FDTI caused the counterfeits to fail in confusing and counterintuitive ways, rather than just telling the user that the chip is fake. As a user, if my device stops working randomly, my first thought is certainly not "there was a counterfeit chip in the supply chain for this hardware and the drivers must be rejecting it!" A little bit more user notification around "you have a counterfeit FTDI" or, even better, a tool to find out if your FTDI is fake would be a lot better than "oh, you can tell if the chip is fake because it will only work properly with drivers before 2.08.14, otherwise it will randomly crash!" Prolific do the same thing, but their drivers at least fail to start with a common error code which is easy to Google.

fixermark 12y ago
""" As a user, if my device stops working randomly, my first thought is certainly not "there was a counterfeit chip in the supply chain for this hardware and the drivers must be rejecting it!" """ Yep. Believing the consumer cares about your product as much as you do is a line of thinking that's easy for engineers to fall into when their lives and livelihoods depend on the product. It's why smart companies employ someone with the capacity to sit in a more objective position to evaluate the market and public perception.
DigitalJack 12y ago
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.
- bri3d 12y ago
  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.
  - robostac 12y ago
    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.
    - bri3d 12y ago
      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.
  - elsjaako 12y ago
    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.
- serf 12y ago
  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
raverbashing 12y ago
" In their pre-bricking drivers, FDTI caused the counterfeits to fail in confusing and counterintuitive ways, rather than just telling the user that the chip is fake." Or maybe because the fake chip is not working in some corner case exactly as the original chip? It's probably not something deliberate. Edit: Do you really think the manufacturer should test their driver agains all fake chips and see how they behave? Really? They test their chips and their software first and foremost. What happens outside of that is not their responsibility.
- seanp2k2 12y ago
  I don't think the argument here is to test their drivers against fakes. I think the argument is against /intentionally harming/ fakes vs. throwing an error. I'm also against the "random malfunctions" feature, if that was also intentional, which it sounds like it was.
  - raverbashing 12y ago
    Sure, but see: I don't think manufacturers would go after fakes and deliberately test their drivers against it. Why? How many fakes are there? How do you make sure that's the "most popular" fake? It's possible they do it? Sure! That, or they add features to their silicon and drivers and don't care what happens to other chips. Yes, I'm against bricking fakes or causing random malfunctions.
sliverstorm 12y ago
Do we have evidence FTDI was in fact making the counterfeits randomly fail on purpose, separate from this bricking thing? Hanlon's Razor is still worth thinking about. For example I have a Prolific chip that is almost certainly a fake that only works with driver X.Y.Z, I always assumed that was because the fakers targeted that driver and made an imperfect spoof.
- bri3d 12y ago
  The Prolific counterfeit protection is documented as being explicit (and not the result of an accidental incompatibility): Prolific introduced a check in later drivers which requires a specific response the fakes didn't implement. http://dreamlayers.blogspot.com/2011/10/pl-2303-code-10-error.html http://dreamlayers.blogspot.com/2011/10/pl-2303-code-10-erro... Thankfully, Prolific chose to simply prevent their drivers from starting with an easy-to-Google code, rather than causing frustrating failures or bricks. I would assume but honestly don't know that the FTDI random failure code was also intentional. All signs point to intentionality: it appeared in all drivers after a specific version, was accompanied by a change to the EULA indicating that counterfeit chips wouldn't work, and accompanied a lot of messaging from FTDI about avoiding counterfeits. I suppose someone should break out a disassembler and some USB snooping tools to check for sure.
  - sliverstorm 12y ago
    Fairly damning, thank you. Coincidentally, PL-2303 sounds like chip model I have from Prolific.
aftbit 12y ago
Part of the way that manufacturers convince customers that counterfeit chips are unacceptable is by pointing to a higher rate of glitches and failures. Perhaps FDTI wanted counterfeit chips to get an (at least partially undeserved) reputation for shoddiness rather than be seen as artificially refusing to work with counterfeits. I have no idea about the bricking though.
- tw04 12y ago
  Right, except most consumers would write it off as shitty drivers. Not "this must not be working because it's a really good knockoff".

by bri3d 12y ago

fixermark 12y ago

""" As a user, if my device stops working randomly, my first thought is certainly not "there was a counterfeit chip in the supply chain for this hardware and the drivers must be rejecting it!" """ Yep. Believing the consumer cares about your product as much as you do is a line of thinking that's easy for engineers to fall into when their lives and livelihoods depend on the product. It's why smart companies employ someone with the capacity to sit in a more objective position to evaluate the market and public perception.

DigitalJack 12y ago

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.

bri3d 12y ago
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.
- robostac 12y ago
  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.
  - bri3d 12y ago
    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.
- elsjaako 12y ago
  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.
serf 12y ago
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

raverbashing 12y ago

" In their pre-bricking drivers, FDTI caused the counterfeits to fail in confusing and counterintuitive ways, rather than just telling the user that the chip is fake." Or maybe because the fake chip is not working in some corner case exactly as the original chip? It's probably not something deliberate. Edit: Do you really think the manufacturer should test their driver agains all fake chips and see how they behave? Really? They test their chips and their software first and foremost. What happens outside of that is not their responsibility.

seanp2k2 12y ago
I don't think the argument here is to test their drivers against fakes. I think the argument is against /intentionally harming/ fakes vs. throwing an error. I'm also against the "random malfunctions" feature, if that was also intentional, which it sounds like it was.
- raverbashing 12y ago
  Sure, but see: I don't think manufacturers would go after fakes and deliberately test their drivers against it. Why? How many fakes are there? How do you make sure that's the "most popular" fake? It's possible they do it? Sure! That, or they add features to their silicon and drivers and don't care what happens to other chips. Yes, I'm against bricking fakes or causing random malfunctions.

sliverstorm 12y ago

Do we have evidence FTDI was in fact making the counterfeits randomly fail on purpose, separate from this bricking thing? Hanlon's Razor is still worth thinking about. For example I have a Prolific chip that is almost certainly a fake that only works with driver X.Y.Z, I always assumed that was because the fakers targeted that driver and made an imperfect spoof.

bri3d 12y ago
The Prolific counterfeit protection is documented as being explicit (and not the result of an accidental incompatibility): Prolific introduced a check in later drivers which requires a specific response the fakes didn't implement. http://dreamlayers.blogspot.com/2011/10/pl-2303-code-10-error.html http://dreamlayers.blogspot.com/2011/10/pl-2303-code-10-erro... Thankfully, Prolific chose to simply prevent their drivers from starting with an easy-to-Google code, rather than causing frustrating failures or bricks. I would assume but honestly don't know that the FTDI random failure code was also intentional. All signs point to intentionality: it appeared in all drivers after a specific version, was accompanied by a change to the EULA indicating that counterfeit chips wouldn't work, and accompanied a lot of messaging from FTDI about avoiding counterfeits. I suppose someone should break out a disassembler and some USB snooping tools to check for sure.
- sliverstorm 12y ago
  Fairly damning, thank you. Coincidentally, PL-2303 sounds like chip model I have from Prolific.

aftbit 12y ago

Part of the way that manufacturers convince customers that counterfeit chips are unacceptable is by pointing to a higher rate of glitches and failures. Perhaps FDTI wanted counterfeit chips to get an (at least partially undeserved) reputation for shoddiness rather than be seen as artificially refusing to work with counterfeits. I have no idea about the bricking though.

tw04 12y ago
Right, except most consumers would write it off as shitty drivers. Not "this must not be working because it's a really good knockoff".