Live data from Hacker News

FTDI driver kills fake FTDI FT232s

eevblog.com

271–280 of 315 posts

Re: FTDI driver kills fake FTDI FT232s

#271

Earlier quoted context omitted.

> Most users didn't choose the chip just because it's compatible and cheaper. They bought it thinking it's the legitimate FTDI chips with (very specific) guarantees from its manufacturer's datasheet. Eh....... Lots of people knew/know they are/were getting counterfeit chips. It's certainly shady, but if I were a chinese company making these, I'd simply not use the logo anymore and then sue the pants off FTDI.

Really? I can understand people might want to cheap out for personal projects. But there's no way I'll use it knowingly at work.

Ohh, I agree. I meant that a lot of the makers kind of knew about it. I doubt anyone would spec it in a BOM.

Re: FTDI driver kills fake FTDI FT232s

#272

Earlier quoted context omitted.

Seems like there's a few people who don't seem to understand the difference between copyright, trademark, criminal and civil law (op above you included). The only law broken by the counterfeiters is trademark violation for printing the FTDI logo on their chips. That's it! Everything else they did was legal. Otherwise, Intel and AMD would be bricking CPUs right now. Reverse engineering is legal. Emulation is legal. Cr…

Going with your example, if AMD uses "Core" or "Xeon" in the name of their chip, it is most likely infringing the trademark of Intel. But in this case, it's more like AMD is simply branding their chip with exact Intel product name and sold as if it's from Intel. I don't think this is a trademark issue any more, it's more like fraud. Does anyone even know what entity designed and made the fake FTDI chip? I find many p…

No, it's trademark and trademark only. Generic medicine puts on the label of their products "compare to brand name XXX." There's nothing wrong with this. As long as you don't impersonate another companies mark. Is it a flagrant violation? Sure. Doesn't change that this is still (only) a civil matter.

Re: FTDI driver kills fake FTDI FT232s

#273

Earlier quoted context omitted.

hah... Assuming the prototype is actually identical to the delivered product. People who want to skim money off the top aren't stupid, the prototype will probably contain the specified part and so will the first few lots. To insure validity of every part you need to test every part.

I don't think testing every single unit is reasonable. Luckily we have Random Sampling which typically works quite well. :) https://en.wikipedia.org/wiki/Random_sample

OK, let's run with this a bit. Seems simple enough if you make a single pcba, but what if you're a company like sony and your product has 8 different pcbas in it, some source from other companies and some designed an manufactured in house. Whose testing process should screen the counterfeit chips? If a violation is found, who is liable? Someone has to be, because there will be a cost to the end user when the things go belly up. Also, why the hell would anyone have thought to do this in the past? I work in testing and no one creates a QC process to check for fakes during the PCBA process. You don't test the chips when you're manufacturing the board, you test the integration. Doing a full functional verification of every component during PCBA is really dumb.

No matter how you slice it, this is lunacy. FTDI was extremely short sighted here and any competent engineer or product manager will see this as a sign to be weary of incorporating FTDI into future designs. You don't want your component manufacturers playing shady stuff like this. Supply chain management is complicated enough without having to worry about devices getting bricked weeks, months, or years after you've done the engineering work.

Re: FTDI driver kills fake FTDI FT232s

#274

Here's someone claiming to have found the responsible function in a driver. PLEASE NOTE: ALL NAMES HAVE BEEN CHOSEN FREELY BY THE PERSON WHO MADE THE SCREENSHOT! So there's no name "BrickCLoneDevices()", it's probably called UpdateEEPromChksum or something like that in the original code, because it looks like that's what it does. http://www.eevblog.com/forum/reviews/ftdi-driver-kills-fake-... Assuming that this disas…

Neither write has any effect on a genuine FTDI chip because both writes are to even addresses. That's also why they write to word 62 even though the checksum is in word 63 - they can't modify the checksum directly because that'd affect genuine devices, so instead they modify word 62 so that the data has the same checksum as before their changes. The entire thing has no purpose other than bricking clones.

Re: FTDI driver kills fake FTDI FT232s

#275
post #226

Earlier quoted context omitted.

People are allowed to choose the parts they want to use. I call it voting with your wallet. Maybe FTDI will realize that people don't want to use their products when they pull stunts like this.

So basically "we will show FTDI by CONTINUING to not use their parts at all". People affected didnt want to use FTDI parts in the first place, they wanted fly by night $2 with free shipping special.

No, it's more "I could use FTDI parts(and I bet someplace like seeed would use the real thing), but if they are going to release drivers that have a kill command baked in(and we've seen that it's on purpose), I'm not gonna use them"

Re: FTDI driver kills fake FTDI FT232s

#276

Microsoft should revoke the driver's signature via their next CRL update, so that it refuses to install (effectively making the drivers unsigned). It is acting maliciously and will break consumer's hardware, even hardware which doesn't contain any FTDI chips. If FTDI have an issue with a company ripping off their IP then go sue that company. But what they're doing is catching consumers in the firing line, who will wi…

Can we be sure that FTDI has programmed their driver with malicious intent? It may be that this an accidental side-effect of using counterfeit hardware with a genuine driver. Without access to the source code or a well-reversed disassembly of the FTDI driver, and a good grasp of the logic used in the counterfeit chip, one cannot be certain about this. And surely not to the extent of urging Microsoft to revoke driver…

Intent doesn't matter if the patch is causing damage.

There are legal routes available to FTDI that don't involve bricking devices. I'm guessing that FTDI didn't talk to internal counsel before making this change.

I'll be quite surprised if Microsoft doesn't pull this patch.

Re: FTDI driver kills fake FTDI FT232s

#277
post #226

Earlier quoted context omitted.

People are allowed to choose the parts they want to use. I call it voting with your wallet. Maybe FTDI will realize that people don't want to use their products when they pull stunts like this.

So basically "we will show FTDI by CONTINUING to not use their parts at all". People affected didnt want to use FTDI parts in the first place, they wanted fly by night $2 with free shipping special.

No; people affected are people who bought some devices from someone who bought some devices from someone who wanted to use FTDI parts, who bought their parts from someone who bought their parts from someone who didn't want to use FTDI parts.

FTDI action hurts everyone except the ones they were targetting.

Re: FTDI driver kills fake FTDI FT232s

#278

Earlier quoted context omitted.

This isn't a misconfiguration issue, or that Linux bug that bricked certain SCSI devices. No, they are explicitly asking the counterfeit chip to rewrite its USB PID to 0, which renders it unusable. That's intentional and clearly malicious.

Has this been proven by a corresponding packet dump listing "Write EEPROM, offset 0, 4 bytes: [0,0,0,0]? Or are they -sneakily- bricking the device by evoking an unintended reaction to a seemingly innocuous command? The former will be easy to prove, the latter.. probably not so much.

It's been proved by reverse engineering the FTDI drivers and annotating the code. It exploits some edge case in which the counterfeit device does not behave exactly like the original. https://marcan.st/transf/ftdi_evil.png

Re: FTDI driver kills fake FTDI FT232s

#279
post #143
post #132

Earlier quoted context omitted.

One could argue that using the official driver with counterfeit chips is outside intended purpose of the official driver, at which point the user is proceeding at his or her own risk.

I think the counterargument (elsewhere in this thread) is pretty persuasive -- that this defense won't help much if you intentionally set out to damage counterfeit chips. Think about it this way. Suppose the driver works like this: ``` if(counterfeit()){ // do something harmful to the identified device } ``` If you have a counterfeit chip, and you run the driver, and the driver breaks your chip, then you are in fact…

In this case the driver is executing two writes which a legitimate chip would ignore, but which the counterfeit responds to and actions. Those writes just happen to be the position in the counterfeit's EPROM where the USB PID is stored, and just before where the checksum is stored.
Post reply on HN