Earlier quoted context omitted.
FTDI is almost certainly trying to exercise IP rights that don't actually exist, because breaking other people's stuff is not an authorized method for dealing with trademark infringement.
> because breaking other people's stuff is not an authorized method for dealing with trademark infringement. The device violates the USB specification by using a protected VID; it is already to be considered as broken regarding the USB specification.
FTDI driver kills fake FTDI FT232s
261–270 of 315 posts
Re: FTDI driver kills fake FTDI FT232s
#262Microsoft 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…
marcan: "In case anyone was still wondering if this is intentional and malicious... Straight out of their driver. Function/variable naming and comments mine.
https://marcan.st/transf/ftdi_evil.png
I figured out what's going on with the real chips: turns out their EEPROM is written in 32bit units. Writing to even addresses is ignored; the value is buffered and the address discarded. Writing to odd addresses writes the entire 32bits, using whatever value was last buffered for the other half. So both the PID write and the checksum write are ignored on real FTDI chips, as they are both written to even addresses. I still don't know why it works on clone chips though, since the checksum is written to the wrong place (it should normally be on an odd address); presumably they don't check it."
Basically driver is fuzzing 'chips claiming to be FTDI' with illegal instructions. Want to play clone games? better emulate me completely, otherwise tough titties. I like it. Might not work to well for FTDI in the end due to PR nightmare, but from engineering standpoint its quite brilliant.
Re: FTDI driver kills fake FTDI FT232s
#263I'm designing an Arduino-compatible board[1] that supposed to have an FTDI chip for ease of design. This whole thing makes me reconsider it, what would be the best way to replace it some other solution? Do I have any real option if I want to stay within the Open Parts Library[2]? [1]: https://www.hwtrek.com/product_preview/VTZUZV9k [2]: http://www.seeedstudio.com/wiki/Open_parts_library
I've never used it, but Microchip's IDE for their C compiler and debugger is cross-platform and will work on Linux/Mac/Windows. I prefer to program them in JAL, a Pascal-like language that is easy to learn that has a large library of functions available. There's syntax highlighting available for it in Vim :-) .
If you're committed to Arduino, there's an open-source project (http:www.pinguino.cc) that has its own Python-based IDE that will take Arduino code, convert it to SDCC C code, compile it to assembly, then flash a Microchip chip.
Re: FTDI driver kills fake FTDI FT232s
#264Re: FTDI driver kills fake FTDI FT232s
#265Earlier quoted context omitted.
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…
http://www.eevblog.com/forum/reviews/ftdi-driver-kills-fake-... marcan: "In case anyone was still wondering if this is intentional and malicious... Straight out of their driver. Function/variable naming and comments mine. https://marcan.st/transf/ftdi_evil.png I figured out what's going on with the real chips: turns out their EEPROM is written in 32bit units. Writing to even addresses is ignored; the value is buffere…
Re: FTDI driver kills fake FTDI FT232s
#266Re: FTDI driver kills fake FTDI FT232s
#267Does this qualify as a CFAA violation? I think so and for monetary gain, no less. I would like to hear why wouldn't the DA that leaned so hard on Swartz wouldn't do the same FTDI's CEO.
Technically the counterfeit devices should have never been allowed into the country. So it should be interesting how this plays out.
Legally, I'd be surprised. They are re-implementing the FTDI protocol, which is completely legal. They are reusing FTDI's PID/VID, which might or might not be a violation of the USB specs or USB recommendations -- I'm not sure about that -- but I'd be really surprised if that matches the legal definition of "counterfeit" for which customs has the right (and duty) to stop imports.
Re: FTDI driver kills fake FTDI FT232s
#268Earlier quoted context omitted.
They change the PID to zero, which means Windows won't associate it with FTDI or any other driver. You have to jump through some manual hoops to undo it, which is something most people can't do. So for all intents and purposes it is bricked, a.k.a "locked out".
Most HN'ers seem to agree it is OK for FTDI to prevent their own drivers from working with the fakes, right? The fact that there are no OTHER drivers that are compatible (no matter what the pid is) with the fakes isn't their problem, is it?
It is NOT OK to modify the HARDWARE in ANY WAY, including changing the PID.
That is the issue.
Further Most people defending FTDI assume this code will be 100% pure and never incorrectly identify a real chip as fake, I find that claim to be suspect.
Lastly I would find it very hard to support vendors that take these aggressive risks and stances, I certainly would never incorporate a device from a manufacturer that uses these types of tactics into a mass produced product.
Re: FTDI driver kills fake FTDI FT232s
#269Earlier quoted context omitted.
Yes, I can. I can picture a product vendor using a modified Linux kernel with that code in a driver, or at least a moral equivalent. Eg, a NAS box which is "only compatible with brand X drives". Just because the code is available doesn't mean it does no damage. Only that you have the ability to find and fix the code.
A NAS box "only compatible with brand X drives" is nowhere near a NAS box that intentionally bricks non-brand X drives when attached. As a side note, are there any known cases where a vendor has released open source code that intentionally bricks a device? I'd be surprised if they were not found legally liable if the intent was spelled out so clearly.
Perhaps you'll like this example better? https://www.google.com/patents/US4577289 "Hardware key-on-disk system for copy-protecting magnetic storage media"
There are physical holes on the disk. "The test program writes the sections with a test pattern which generates a change in the pattern of magnetic domains of the medium, a subsection at a time, with a subsection responding to the test pattern only in the absence of indicia thereon, to form a stored pattern on the given section. An expected pattern and the stored pattern are compared at least a subsection at a time to determine if corresponding subsections have a predetermined pattern of magnetic domains."
If you have "insert key disk now", followed by a write to the disk, and then a verification, then a standard disk/non-key disk will get corrupted.
That 'bricks' non-brand floppies by design, under the aegis of copy protection.
There's been open source with back doors in it. Eg, Firebird had one that took about 6 months to detect, after source code release.
In listening to the various accounts of GPL enforcement, it isn't always easy to track down the actual vendor. Quoting from http://www.infoworld.com/article/2617579/open-source-softwar...:
> Always keen to shave the last few cents from their bill of materials, these manufacturers tend to procure their firmware from low-cost suppliers that have in turn delivered open source software without passing on its licensing terms. It can come as a surprise to the hardware manufacturer to discover a violation of the license terms.
While that's about incorrect use of licensing terms, it shows there's no reason why the manufacturers are aware of all of the code in the software they sell.
Re: FTDI driver kills fake FTDI FT232s
#270Earlier quoted context omitted.
Yes, I can. I can picture a product vendor using a modified Linux kernel with that code in a driver, or at least a moral equivalent. Eg, a NAS box which is "only compatible with brand X drives". Just because the code is available doesn't mean it does no damage. Only that you have the ability to find and fix the code.
> Just because the code is available doesn't mean it does no damage. Only that you have the ability to find and fix the code. Also your shenanigans become visible. You'd have to code extremely carefully to break the fake with plausible deniability, and even then your name as a developer would forever be mud.