The contradiction is in your example. I adjusted the example to be more valid but you don't seem to be reading those posts and are as a result getting confused because your internal state isn't updated correctly.
The device does work vs. an engine that does not. Your example is invalid in its very premise. The device appears in windows, can be configured, is electrically still functional, ... (As in the engine which in your example which is the chip still works)
For all intensive purposes the only missing bit is the readme saying PID 0000 = counterfeit, tough luck and the user is now aware the device still works it is just a fake.
Your ignoring the fact the contradiction is with your example at which point I modified it to correct it and then you say I'm contradicting myself when it is in fact just you that are confused.
The device still works windows still detects it as (FTDI Vendor Detect, Unknown device which is true in every respect) and it does not require physical replacement of a 2 dollar bearing/component to bypass.
I don't understand how it can be classified as killed/broken/damaged in any way because it isn't.
If you're rewriting the question in order to answer it how you wish, then you're not answering the question or the issue. Yet again, you say here,QuoteThe device does work vs. an engine that does not.and only a few posts earlier,QuoteThe engine does run which is the problem with your example and where the miles apart is.so have no consistency. None. Zero.
Every single utterance you're putting to the keyboard, is attempting to evade the basic reality that the device, for all intents and purposes to the end user, is dead. You are unable to refute this. Everything else you're spewing is aimless evasion to what you've now already admitted. The device, for the end user after FTDI had their way with it, does not work. Period. That's it. It's fixable to the person who has the know-how and the tools, and for everyone else, it's no different than a brick. QED.
The driver is not the product or the chip.
The driver has nothing that says it is guaranteed to work with fake chips.
The device still works the driver doesn't want to talk to it.
The device can and shortly will work even on Linux and windows once third party drivers are written. It is just that you can no longer use windows WHQL and FTDI signed drivers automatically.
The device does work otherwise it won't enumerate with the operating system. The board can still send data to the chip and it will still send the data back upto the computer. The device works just fine.
The driver is not the product or the chip.Irrelevant. They modify the device.QuoteThe driver has nothing that says it is guaranteed to work with fake chips.Irrelevant. They modify the device.QuoteThe device still works the driver doesn't want to talk to it.But would have done so before the device was modifiedQuoteThe device can and shortly will work even on Linux and windows once third party drivers are written. It is just that you can no longer use windows WHQL and FTDI signed drivers automatically.Which doesn't change the fact that they modified a device to prevent it from functioning normally. That someone found a workaround does not remove the intent. None of this squabbling would hold up in court. You can't just modify someone elses property because you don't like what its doing, even if you handwave the modification as not a big deal because they can always fix it.
FTDI has every right to do whatever they want *within their driver*. When they start messing with the device - with they do not own, control, or have rights to - with the intent to prevent it from functioning, no matter how easy it is to circumvent, they step outside the bounds of what they are legally permitted to do.
The device does work otherwise it won't enumerate with the operating system. The board can still send data to the chip and it will still send the data back upto the computer. The device works just fine.
Oh yeah, I get it. Kind of like how I can push the gas pedal down in a car with fouled spark plugs and flood the engine with gas. It just doesn't enumerate with the crankshaft into an actual rotary motion.
That's a fair point. But the chances of an unintended FTDI fake substitution are probably higher than others. Until now - that didn't carry unnecessary additional risk that it might work fine (pass all testing) and get passed onto the customers where it could be e-firebombed without warning.
So basically what I said - your are prepared to take the risk of shipping crap built with fake parts but the risk of being found out when you do tips the balance and steers you towards parts which are less likely to be shown to be fakes.In the future I will be taking the use of FTDI parts as an indication of a supplier who cares about the quality of their products and has confidence in their supply chain.
B. To use a part with blind optimism that your supply chain can't possibly screw up is equivalent to playing Russian roulette. I'd prefer to use the products from a company who is proactive about increasing reliability through thoughtful design and part selection. You're saying I should add risk to an extremely critical system just to demonstrate my confidence in 3 or 4 layers of supply chain removed from our company? No thanks.
You mean the added risk of being found out when you ship product built with fakes. So again what I said - I will have more confidence in a company who have enough confidence in their supply chain to consider that added risk insignificant. If two companies tell me a gun is unloaded I will believe the one prepared to play Russian roulette with it.
FTDI has every right to do whatever they want *within their driver*. When they start messing with the device - with they do not own, control, or have rights to - with the intent to prevent it from functioning,
FTDI has every right to do whatever they want *within their driver*. When they start messing with the device - with they do not own, control, or have rights to - with the intent to prevent it from functioning,
Their intent and the actual result was to prevent the device indicating to the operating system that it should load FTDI drivers which are not licensed for use with that device. The device remains as functional as it ever was if you provide drivers for example by plugging it into a Linux box.
lasting but not damaging technique to prevent the clone devices from working with the software, it still works just not with the licensed software.
I just got an idea. I'm going to delid an FTDI chip right now. Hold on I'm going to play with fire.
So if you produce a clone product without reverse engineering and then either don't brand it, or, put your own brand on it everything is fine and dandy.
So if you produce a clone product without reverse engineering and then either don't brand it, or, put your own brand on it everything is fine and dandy.Has such a chip ever been found in the wild?
FTDI has every right to do whatever they want *within their driver*. When they start messing with the device - with they do not own, control, or have rights to - with the intent to prevent it from functioning,
Their intent and the actual result was to prevent the device indicating to the operating system that it should load FTDI drivers which are not licensed for use with that device. The device remains as functional as it ever was if you provide drivers for example by plugging it into a Linux box.Yep, the windows driver is provided to the user with a licence requiring it to be used with their hardware. They decided to start enforcing that requirement with a lasting but not damaging technique to prevent the clone devices from working with the software, it still works just not with the licensed software.
People taking issue with Microsoft and FTDI wanting to protect the underlying USB compatibility is hilarious, PID/VID codes match software to hardware, its not an end to end API that FTDI are providing for use.
ONE MORE TIME for those of you that are a little thick-headed:
FTDI does *NOT* "OWN" the VID/PID associated with this device. ANYONE can use the *same* VID/PID if they want to with *NO* legal repercussions. It is perfectly *legal* for a company to make a "clone" [i.e. "works alike"] device that has the same VID/PID as the FTDI device.
It is unethical, illegal, and a "tort" for FTDI to maliciously and willfully [with forethought] modify and/or damage someone else's property without their permission.
FTDI broke the law. FTDI left themselves open to a class action lawsuit. FTDI gave themselves a "black eye". FDTI decision makers that approved these actions are *IDIOTS*, and they should be FIRED. Even the CEO can be fired by the board of directors. Heads will roll. This will be remembered by every design engineer that needs a USB-serial chip for their design. This will cost FTDI dearly, and that is if the company survives at all.
IN ADDITION: Let's talk semantics. A "work alike clone" is *not* illegal unless the company making it tries to pass it off as a chip made by FTDI. There is no way for the driver to know if there is trademark infringement on the chip's package-- and so the driver just may well "brick" a legal, legitimately owned "clone" as well as a "counterfeit" part. It is illegal for FTDI to knowingly and willfully modify the PID and/or VID of a device that they don't own-- PERIOD.
So if you produce a clone product without reverse engineering and then either don't brand it, or, put your own brand on it everything is fine and dandy.Has such a chip ever been found in the wild?
Not that I have seen. I do have an unlabelled chip at home but its something entirely different and nothing to do with the discussion other than it prompted me to ask the question you have quoted above.
Simple question
I loan you my working USB to serial cable, did I receive back a cable that still works with my computer on the cable's return?
If NO, then you are responsible for the damage!
C
Of those 15 devices, a whopping 9 proved to be contain FTDI chips (all of which were FT232R).
I'm pleased to announce that each of those 9 devices has now been 'consigned to the bin', but not before I had some fun.
Of those 15 devices, a whopping 9 proved to be contain FTDI chips (all of which were FT232R).
I'm pleased to announce that each of those 9 devices has now been 'consigned to the bin', but not before I had some fun.
And how does your face look without a nose?
.
.
.
.
.
.
If you need it explaining http://en.wikipedia.org/wiki/Cutting_off_the_nose_to_spite_the_face
...
#!/usr/bin/env python2
# FTDI Clone Tool v0.2 by @marcan42
# Licensed under the terms of the 2-clause BSD license, which follow:
#
# Copyright (c) 2014 Hector Martin <hector@marcansoft.com>
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions are met:
#
# 1. Redistributions of source code must retain the above copyright notice,
# this list of conditions and the following disclaimer.
#
# 2. Redistributions in binary form must reproduce the above copyright notice,
# this list of conditions and the following disclaimer in the documentation
# and/or other materials provided with the distribution.
#
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
# DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
# SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
# CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
# OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
import sys, struct
try:
import usb
except ImportError:
print "Error: please install PyUSB. The package is called python-usb in Ubuntu."
sys.exit(1)
def find_device():
busses = usb.busses()
found = 0
for bus in busses:
devices = bus.devices
for dev in devices:
if (dev.idVendor == 0x0403
and dev.idProduct in (0x6001, 0x0000)
and dev.deviceVersion.split(".")[0] == "06"):
print "Found FTDI FT232R device (%04x:%04x)" % (dev.idVendor, dev.idProduct)
found_dev = dev
found += 1
if found == 0:
print "No devices found"
sys.exit(1)
if found > 1:
print "More than one device found. Please connect only one FTDI device."
sys.exit(1)
return found_dev
class FTDIDevice(object):
def __init__(self, usbdev):
self.handle = usbdev.open()
self.timeout = 100
def unlock_eeprom(self):
self.handle.controlMsg(requestType=0x40,
request=0x09,
value=0x77,
index=1,
buffer="",
timeout=self.timeout)
def read_eeprom(self, addr):
data = self.handle.controlMsg(requestType=0xc0,
request=0x90,
value=0,
index=addr,
buffer=2,
timeout=self.timeout)
assert len(data) == 2
return data[0] | (data[1] << 8)
def write_eeprom(self, addr, data):
self.handle.controlMsg(requestType=0x40,
request=0x91,
value=data,
index=addr,
buffer="",
timeout=self.timeout)
def calc_checksum(self, eeprom):
check = 0xaaaa
for i in eeprom[:0x3f]:
check = check ^ i
check = ((check << 1) | (check >> 15)) & 0xffff
return check
def forge_checksum(self, eeprom):
check = 0xaaaa
for i in eeprom[:0x3e]:
check = check ^ i
check = ((check << 1) | (check >> 15)) & 0xffff
check ^= ((eeprom[0x3f] >> 1) | (eeprom[0x3f] << 15)) & 0xffff
return check
def main():
print "Detecting device..."
dev = FTDIDevice(find_device())
dev.unlock_eeprom()
print "Reading EEPROM..."
eeprom = [dev.read_eeprom(i) for i in range(0x40)]
print "EEPROM contents:"
for i in range(0, 0x40, 8):
print " " + " ".join("%04x" % j for j in eeprom[i:i+8])
check = dev.calc_checksum(eeprom)
checksum_correct = check == eeprom[0x3f]
if checksum_correct:
print " EEPROM checksum: %04x (correct)" % eeprom[0x3f]
else:
print " EEPROM checksum: %04x (incorrect, expected %04x)" % (eeprom[0x3f], check)
print "Detecting clone chip..."
old_value = eeprom[0x3e]
print " Current EEPROM value at 0x3e: %04x" % old_value
new_value = (old_value + 1) & 0xffff
print " Writing value: %04x" % new_value
dev.write_eeprom(0x3e, new_value)
read_value = dev.read_eeprom(0x3e)
print " New EEPROM value at 0x3e: %04x" % read_value
if read_value != old_value:
print " Reverting value: %04x" % old_value
dev.write_eeprom(0x3e, old_value)
if read_value == old_value:
print "Chip is GENUINE or a more accurate clone. EEPROM write failed."
print "Nothing else to do."
return 0
print '===================================================================='
print 'Chip is a CLONE or not an FT232RL. EEPROM write succeeded.'
if checksum_correct:
if eeprom[2] == 0:
print '===================================================================='
print "Your device has a Product ID of 0, which likely means that it"
print "has been bricked by FTDI's malicious Windows driver."
print
print "Do you want to fix this?"
print " - Type YES (all caps) to continue."
print " - Type anything else (or just press enter) to exit."
ret = raw_input("> ")
if ret != "YES":
print "No changes made."
return 0
# Try to undo what the FTDI driver did. If it corrupted the value at
# 0x3e (if it wasn't unused), this should fix it, assuming the
# checksum at 0x3f is correct for the right value.
eeprom[0x02] = 0x6001
eeprom[0x3e] = dev.forge_checksum(eeprom)
dev.write_eeprom(0x02, eeprom[0x02])
dev.write_eeprom(0x3e, eeprom[0x3e])
if eeprom[0x3e] == 0:
print "Product ID restored to 0x6001. All changes made by FTDI's driver"
print "have been reverted."
else:
print "Product ID restored to 0x6001. However, the value at 0x3e has not"
print "been set to zero. Reasons why this may have happened:"
print " - The PID was set to 0 by other means, not FTDI's driver."
print " - The original PID was not 0x6001"
print " - The PID was set to 0 by FTDI's driver, then fixed with"
print " another tool, then set to 0 again by FTDI's driver."
print " - Your device has very long vendor/product/serial number strings,"
print " and FTDI's driver may have accidentally corrupted the last"
print " character. If this is the case, it has been restored."
print " - You or your software have used the EEPROM's free/user area and"
print " FTDI's driver has corrupted the last word. If this is the case,"
print " it has been restored."
print " - For some other reason the free area of your EEPROM was not"
print " filled with zeros."
print "This is probably harmless, but you may want to take note."
print "Press enter to continue."
raw_input()
print "===================================================================="
print "Deliberately corrupting the checksum of your device\'s EEPROM will"
print "protect it from being bricked by the malicious FTDI Windows driver,"
print "while still functioning with said driver. However, if you do this,"
print "ALL SETTINGS WILL REVERT TO DEFAULTS AND THE DEVICE SERIAL NUMBER"
print "WILL NO LONGER BE VISIBLE. Most devices that use the FT232 as a"
print "standard USB-serial converter will function with default settings,"
print "though the LEDs on some converters might be inverted. Specialty"
print "devices, devices which use bitbang mode, and devices which use"
print "GPIOs or nonstandard control signal configurations may cease to"
print "work properly. If you are NOT 100% certain that this is what you"
print "want, please do not do this. YOU HAVE BEEN WARNED. You can revert"
print "this change by using this tool again."
print
print " - Type CORRUPTME (all caps) to set an invalid EEPROM checksum."
print " - Type anything else (or just press enter) to exit."
ret = raw_input("> ")
if ret != "CORRUPTME":
print "EEPROM checksum left unchanged."
return 0
if eeprom[0x3f] == 0xdead:
# Bad luck!
dev.write_eeprom(0x3f, 0xbeef)
else:
dev.write_eeprom(0x3f, 0xdead)
print "EEPROM checksum corrupted. Run this tool again to revert the change."
print "Disconnect and reconnect your device for the changes to take effect."
print "Press enter to exit."
raw_input()
return 0
else:
print "===================================================================="
print "Your device has an incorrect EEPROM checksum, probably because you"
print "ran this tool to do so, with the intent of protecting your device"
print "from the malicious Windows driver."
print
print " - Type FIXME (all caps) to restore your EEPROM checksum."
print " - Type anything else (or just press enter) to exit."
ret = raw_input("> ")
if ret != "FIXME":
print "EEPROM checksum left unchanged."
return 0
dev.write_eeprom(0x3f, check)
print "EEPROM checksum corrected. Disconnect and reconnect your device for"
print "the changes to take effect. Press enter to exit."
raw_input()
if __name__ == "__main__":
sys.exit(main())