FTDI driver kills fake FTDI FT232??

[duncan_bayne]

Hacker News is sending traffic here too.

And lobste.rs.

[mgaffigan]

I think the missed opportunity here is a license available for the low, low cost of $5 to continue using a counterfeit device...

Perhaps it's a break, then fix sort of thing.

how would that work on linux?  linux has source-based code and you can't force a binary blob down (usually) and get away with it once the source is already out there.

you could stop the mac and windows users but linux lets users see and modify source code.  the vendor can't threaten linux users.  they probably knew this and so they (apparently) decided there was ONE 'fix' for all os's.  and I use the word 'fix' in the most non-literal sense.

then again, a linux driver update to ftdi_sio.[ch] may be coming soon that allows the 0000 pid.

As you pointed out, the problem isn't on Linux.  I am sure the dev community will catch up to handle the new PID.  The most vocal set of users are those who bought an arduino or some other product which no longer works, and the current bitterness is that the device is not working.  It may be an unpopular opinion, but I do understand their issue with enforcement.  A popup box saying "Your product is counterfeit" doesn't accomplish anything but give the user some search terms to find a non-detecting version of the driver. 

Imagine instead of just bricking the device, you received a popup saying "Your product is counterfeit, please contact the manufacturer for RMA or purchase a license from FTDIStore.com."  You'd still be annoyed, but you'd probably pay the $5 so that you can continue using the $30 device.

That way, the OEM still is forced to purchase genuine parts, the user can continue using their device, and FTDI still gets revenue from a missed sale.

[nitro2k01]

In which case it would be an easy matter to do a search in the driver for that serial number and  mask it out.

The driver is signed, if you change anything it will not work again.

That's easy to bypass pretty easily if you're willing. (Assuming you're talking about Windows' signing and not some extra, homebrew signing by FTDI.)

[amyk]

In which case it would be an easy matter to do a search in the driver for that serial number and  mask it out.

The driver is signed, if you change anything it will not work again.

Quite naturally, there's a patch to disable that too, or resign with your own certificate (which you've installed as a trusted root.)

[linux-works]

Imagine instead of just bricking the device, you received a popup saying "Your product is counterfeit, please contact the manufacturer for RMA or purchase a license from FTDIStore.com."  You'd still be annoyed, but you'd probably pay the $5 so that you can continue using the $30 device.

That way, the OEM still is forced to purchase genuine parts, the user can continue using their device, and FTDI still gets revenue from a missed sale.

that would be the proper and ethical thing to do.

sadly, ftdi jumped before they thought it all out and we're now left with a meltdown.  will they double-down on their derp or will they change their stance and pull the damaging driver back and use a popup, like you (and others) have suggested?  my bet is that they will not budge and only if they are sued will they change their tune.  companies are like that, these days; they never want to admit that a decision they made was horribly wrong ;(

[Vgkid]

This was only a couple of pages yesterday, now it is 20+ with over 1K visitors.

[Knuckx]

In which case it would be an easy matter to do a search in the driver for that serial number and  mask it out.

The driver is signed, if you change anything it will not work again.

Quite naturally, there's a patch to disable that too, or resign with your own certificate (which you've installed as a trusted root.)

A Kernel Boot Configuration Option exists to disable signature checking, called TESTSIGNING.
You can't resign *that* easily though, as the system trusted root doesn't cover kernelmode, only things with a Microsoft cert somewhere in the certs chain of trust are trusted in kernelmode.

As for what FTDI should have done, I would have been happy enough if the driver just refused to start on a fake device with a Code 10 in device manager: "The device cannot start".

[Zeta]

I'm wondering are these fools blaming FTDI are actually real users? or are they just trols paid by fake ICs manufacturers? it was entertaining to read the posts but come on they can't be real.

Why would you blame FTDI if you are an legit user who unknowingly bought a device containing a counterfeit IC, contact your vendor (he is the one to blame) and ask for a refund or a product change. If they knew those where cointerfeit ICs its their fault if they didn't know they will sue their providers and will make sure they buy the real thing next time it is still their fault.

Just a reminder: buying or selling counterfeit products is illegal and ipholder has the right and duty to make the counterfeit product destroyed (remember when sparkfun cried when they had to pay to have their fake flukes destroyed?)

[nsayer]

I'm wondering are these fools blaming FTDI are actually real users? or are they just trols paid by fake ICs manufacturers? it was entertaining to read the posts but come on they can't be real.

I'm wondering are these fools defending FTDI are actually real users? or are they just trols paid by FTDI? It was entertaining to read the posts but come on they can't be real.


God, it was actually physically painful to type with such bad grammar.

[akshaykirti]

Oh crap. I bought a rs232 TTL converter from adafruit and it had the same exact issue. The PID used to reset to 0000.

I had to modify the windows ftdi inf files to include 0000 and then boot in unsigned mode to Install the driver. Now it works fine on the normal windows mode.. We were on a tight timeline so couldn't really get a new one.

However if I change the PID to anything via their ftdi eeprom utility it changes it back to 0000 the next time it is plugged in. Had a long forum conversation with adafruit and they didn't want to believe me. Finally they refunded me the money on good faith I guess.

Link to the adafruit forum post. https://forums.adafruit.com/viewtopic.php?f=19&t=60807

p.S Typing on a tablet: please forgive any errors.

[marcan]

In case anyone was still wondering if this is intentional and malicious...



Straight out of their driver. Function/variable naming and comments mine.

Edit: Ooooh this is cleverer than I thought. So what's going on is that on real FT232RLs, the EEPROM is written in 32-bit units: writes to even addresses are buffered, and writes to odd addresses write 32 bits at once: the buffered 16 bits, and the supplied 16 bits. So, on a real FT232RL, this code does nothing; it just buffers 16 bits then buffers another 16 bits and no writes are issued. On a clone FT232RL, this writes the PID to 0 (breaking the checksum) and writes not the checksum, but the value required to make the existing checksum match to address 62. In combination, these two writes make the checksum at address 63 valid again (without modifying it). I've updated the image above with the new analysis.

Edit 2: Note that the EEPROM write commands are legitimate (and necessary - but not sufficient - when writing the full EEPROM of an original FT232RL), and indeed I think they would work on (i.e. also brick) other FTDI devices with external EEPROMs (the code that calls this function is very careful to only do so after detecting an FT232RL, legit or not). What seems to have happened here is that, when FTDI switched to an internal EEPROM on the FT232RL, they decided to switch to a 32-bit EEPROM (you can actually see the 32×40 bit array in this die shot by Zeptobars). However, they kept the existing 16-bit-at-a-time commands, but instead decided to buffer one and write only when the chip has accumulated a full 32 bits. This keeps the PC side the same across their entire chip range. The clones just emulate the established interface in the logical and obvious way, issuing 16-bit writes, since presumably nobody checked that a real device doesn't respond like that since usually the entire EEPROM is written at once. FTDI realized that this difference of implementation existed, and is exploiting it here by carefully crafting a routine that has no effect on the original device, but bricks clones (and would likely brick legitimate non-232RL FTDI chips too!).

In a way, the clones actually implement FTDI's command interface better than FTDI themselves - and FTDI is exploiting this to brick them.

[Rasz]

what wrong did I do by buying a device on amazon, fully believing that the items there won't be ebay-style fakes?
how is it right, in your view, to punish ME for this?

I heard that one before, from a guy trying to smuggle elephant ivory

At least if I design a .. Prolific...  part into my product, it's less likely to get wrecked by malware.

you seem to missed the memo on prolific driver bsoding on purpose when it detects fake chip

[kwallen]

Oh crap. I bought a rs232 TTL converter from adafruit and it had the same exact issue. The PID used to reset to 0000.

Might want to contact them about that, they have a statement on their website at the moment saying all of theirs are genuine.

Hackaday and EEVblog are reporting that the latest Windows update that include FTDI drivers brick any counterfeit FTDI chips. Adafruit requires it suppliers to only use genuine FTDI chips. However, no matter what it’s always possible counterfeit chips could be used when you purchase products from anyone, anywhere. We’re double and triple checking all our products and suppliers as an added precaution.

[Knuckx]

In case anyone was still wondering if this is intentional and malicious...



Straight out of their driver. Function/variable naming and comments mine.

So it relies on a quirk of the EEPROM handling of the fakes. I suspect this will turn into a game of cat and mouse if FTDI continue...

what wrong did I do by buying a device on amazon, fully believing that the items there won't be ebay-style fakes?
how is it right, in your view, to punish ME for this?

I heard that one before, from a guy trying to smuggle elephant ivory

At least if I design a .. Prolific...  part into my product, it's less likely to get wrecked by malware.

you seem to missed the memo on prolific driver bsoding on purpose when it detects fake chip

True, but it still doesn't semi-brick your device when it does this...

USB-CDC should be standard by now; surely some cheap chinese chip consortium could spend some time rolling a cheap CDC chip for the masses?

[nsayer]

Arduino switched to using a USB equipped ATMega for their USB-to-serial needs.

I think the best response from the outraged community would be an open-sourced FT232RL emulator sketch for ATMel (or similar) micro controllers. It should, of course, be complete with an "#ifdef PROTECT_PID" code block that works around this nonsense.

[akshaykirti]

Oh crap. I bought a rs232 TTL converter from adafruit and it had the same exact issue. The PID used to reset to 0000.

Might want to contact them about that, they have a statement on their website at the moment saying all of theirs are genuine.

Hackaday and EEVblog are reporting that the latest Windows update that include FTDI drivers brick any counterfeit FTDI chips. Adafruit requires it suppliers to only use genuine FTDI chips. However, no matter what it’s always possible counterfeit chips could be used when you purchase products from anyone, anywhere. We’re double and triple checking all our products and suppliers as an added precaution.

Just did. Linked them to hackaday. Wow, I wasted almost 2 hrs that day fixing this stupid issue.

[akshaykirti]

Looks like adafruit removed the product I bought with the fake chip. Great!

https://forums.adafruit.com/viewtopic.php?f=19&t=60807

[zapta]

what wrong did I do by buying a device on amazon, fully believing that the items there won't be ebay-style fakes?
how is it right, in your view, to punish ME for this?

I heard that one before, from a guy trying to smuggle elephant ivory

What did he use the FTDI IC for?

[(*steve*)]

What did he use the FTDI IC for?

That's the whole point.  He used a fake chip... or a fake elephant.  Or something.  Or the real elephant came back and trampled the fake ivory because it wasn't real.

You see?

[LabSpokane]

I really like FTDI. It sure beats the hell out of Prolific.  I have chosen FTDI over the years because the drivers worked well.  FTDI didn't do this casually I'm sure.  I'm actually sympathetic to them because how the hell are they supposed to develop new products if everyone gets to steal their IP? I really have as much sympathy for people's fake eBay crap getting bricked as I do for those who brick their scopes when they try to steal software upgrades.

If you want your clone FTDI chip to work, consider LICENSING their driver instead of just stealing it.  If you want your USB device to work, buy FTDI ICs through legitimate distribution channels. Any purchasing agent who doesn't know they're buying gray or black market components is a liar or incompetent twit. 

That said, FTDI should at least flag end users for why their fake device is now defunct. Otherwise their is no mechanism for a user to demand what they paid for: a legitimate FTDI-based device.

[Rasz]

What did he use the FTDI IC for?

That's the whole point.  He used a fake chip... or a fake elephant.  Or something.  Or the real elephant came back and trampled the fake ivory because it wasn't real.

You see?

ahahaha
thank you, couldnt make a better argument myself
hahahah
Im laughing so hard I started crying haha

In case anyone was still wondering if this is intentional and malicious...
Straight out of their driver. Function/variable naming and comments mine.

Nice. You cant even blame them for doing something specific to fakes, they do very same procedure to all chips presenting proper ftdi vid/pid.
I like it. If I worked for FTDI I would call this "eprom_test" and claim its essential for quality assurance 

[zapta]

How long does Windows updates include this clone bricking driver?

I wonder if Microsoft was aware of this practice and will they let it go on.

[LabSpokane]

I wonder if Microsoft was aware of this practice and will they let it go on.

Do you honestly think the company that will brick a pirated OS will stop a hardware vendor from bricking its stolen IP?

[marcan]

FWIW, I think FTDI is clearly in the wrong here. While I have no objection to them protecting their IP, the correct approach is not to damage end-user products. They should've just made the driver refuse to work on clone chips.

My personal philosophy is that there is no excuse for intentionally or through negligence damaging users' hardware (and I write my code according to it). For example, when I was doing something similar while writing The Homebrew Channel for the Nintendo Wii (anti-scam code), the behavior when an inconsistency is detected is to show a scam warning screen for 60 minutes - on the very slim off-chance that the user screwed up their hardware such that using The Homebrew Channel as currently installed was their last hope of recovery, they can still save themselves (after waiting). I don't know of any cases where this has happened or where it would happen, but I didn't want to be responsible for disabling a user's last hope of recovery, even if remote. Deliberately bricking devices is just incomprehensible (and reprehensible) to me. With HBC, we tried *very* hard to maximally inconvenience scammers who were selling our free (as in beer) software (and their users), but always with a very hard, clear line between inconveniencing and actively damaging. I'm proud to say that I've never heard of a user directly or indirectly bricking their hardware with my code (as released to end-users - and we have over 5 million users of our hacks).

[uski]

In case anyone was still wondering if this is intentional and malicious...

(disassembled code)

Straight out of their driver. Function/variable naming and comments mine.

Thank you for the analysis. Now they are in trouble and can't just pretend it's the clones "malfunctioning" with the new driver...
Maybe they didn't expect someone to dig into the code...