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 wind up with multiple dead USB devices. There's no reasonable way a consumer can know they are buying something with a fake chip and this could kill devices years old, which will be outside of warranty.
I am totally serious that Microsoft should step in. FTDI's driver is so defective that it is literally killing hardware, if they won't step in for this then what will they step in for?
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 signatures.
"What's the economic reason of making software fake of well-known chip instead of making new one under your own name? This way they don't need to buy USB VID, sign drivers in Microsoft, no expenses on advertisement. This fake chip will be used right away in numerous mass-manufactured products. New chip will require designing new products (or revisions) - so sales ramp up will happen only 2-3 years later. Die manufacturing cost is roughly the same for both dies (~10-15 cents)."
I've seen that one before but what caught my attention this time was the "(M)FTDI FEB 2005" line - the design is approaching 10 years old, and the significance of that is the fact that IC layouts ("mask work") are only protected for 10 years by copyright law:
It's also completely legal to reverse-engineer an existing IC to duplicate its functionality in a different manner, which the cloners have definitely done in this case - they are completely different.
So it appears that the only thing the fake FTDI chip is violating is the trademark "FTDI", which might not even have been put there by the fab that produced the die, since they're branded 'Supereal'.
I hope this causes a major and publicly visible malfunction in some important device/installation/machinery, of course with no harm done to any persons, but enough of an embarrasment to really set an example, so no vendor will think of pulling tricks like these in the future.
Takeaway lesson: End users should never touch anything remotely FTDI-like, since it's probably impossible to verify if the device is genuine or not. Wonder if FTDI thought this through.
I hope this causes a major and publicly visible malfunction in some important device/installation/machinery, of course with no harm done to any persons
I actually hope that this does cause an event drastic enough so that FTDI will have blood on its hands that ends in jail time for management and engineers. I don't want to see anyone hurt, especially not innocent third parties, but fuck FTDI, fuck the management who ordered this, and fuck the engineer(s) who didn't quit in protest. I'm not easily offended, but as a programmer who has been responsible for code that would result in loss of life if I made it defective by design, I have no sympathy for this sort of thing. One other thing that I could hope for is that this teaches everyone the true cost of closed source, especially drivers. Don't put up with it.
Well, that didn't take long! Arduino Nano's on Ebay are already starting to ship with the CH340G instead of the FTDI clone. Way to go FTDI - pissed off your end users and caused manufacturers to move to a completely different chipset. That worked out well for you didn't it?
http://www.ebay.co.uk/itm/Nano-V3-0-ATmega328-16M-Micro-cont...
Basically all vendors outsource production. Very few vendors will knowingly put a fake chip in their product, the trick is pulled by someone closer to manufacturing, either to cut costs or to try and ship earlier in case the original chip is hard to get right now.
I doubt very few vendors will realize if a fake FTDI chip is part off their manufactured product even after rigorous testing since the functionality is correct (until you get this driver).
EDIT: I doubt FTDI have thought this through. I will share this with the hardware designers I know and most will probably react like on the linked thread, and just switch to another chip to avoid any possible hassle.
It's interesting to consider from a legal perspective exactly why this isn't something a company is allowed to do. (Assuming the company did in fact intentionally damage people's chips, reversibly or not -- sounds like we don't know for sure yet?)
- Intentionally sabotaging someone's stuff, legally, is more or less the same as intentionally taking it. Keying a car and driving it away might have different names but are on the same scale.
- There ain't no self help. If you think someone else's stuff should actually be your stuff, your path is through a court.
- We don't fix things with injunctive relief that can be fixed with money. When Apple proves that Samsung violated a patent or vice versa, we don't collect and burn all the infringing phones, we just make someone cut a check. Because we are not idiots.
- The "someone" who cuts the check is Samsung or Apple, not their customers. As far as I know no one's managed to go after end users, even in extreme cases like a $10 designer handbag where the buyer obviously knows it's not real. (And it's at best unclear whether going after the buyers would make any sense, even in those extreme cases -- if someone pays knockoff prices for a knockoff product, it's the seller and not the buyer who has ill-gotten gains. There might be some additional reputation damage and lost profits that the buyer is complicit in, but it makes a lot more sense to me -- and apparently everyone else -- to make the seller pay for those as well.)
- When you do go after the seller of trademarked goods and want to seize those goods, we actually have a procedure for that -- Section 34 of the Lanham Act.[1] Which includes a whole bunch of protections like swearing out an affidavit, getting permission from a judge, informing the attorney general, posting a bond to cover damages, conducting the seizure through government agents, and keeping the seized items in the custody of the court. It's very much unlike showing up at someone's house and breaking their stuff.
(I am a lawyer; I am not a trademark lawyer; I just googled some stuff based on vague memories from law school to write this.)
* we don't collect and burn all the infringing phones, we just make someone cut a check. *
Destruction of trademark-infringing goods and copied media is quite common, though.
In the UK, deliberately sabotaging hardware with drivers could be counted as a violation of the Computer Misuse Act, but there are hardly ever any prosecutions under that law.
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.
Regarding going after buyers, if potential buyers know that buying a counterfeit item puts them at legal risk, I think the market for said counterfeit items will shrink substantially. I think that could be a potentially convincing argument in the case of items where the buyer clearly knows (or should know) that the item they are buying is counterfeit. Is it really all that different from receiving stolen property, which IS illegal?
I think in the FTDI case, though, it would be really hard to argue that the end users should (or even could) know that the chip they have is counterfeit.
FTDI have been anti-consumer for years - their last several drivers have introduced intentional instability and Code 10 errors for suspected counterfeit devices.
I think this is totally crappy. I see what they're trying to do (create market incentive for consumers to insist on real FTDI chips) but the reality is that it's just screwing over innocent consumers who buy a device.
It's similar to black market goods. A consumer wants the lowest possible price. It turns out the goods he bought are stolen property. He didn't know, but he is not waived of responsibility. If he was truly unwitting he will not be prosecuted, but the goods will still be repossessed, etc.
Basically, it is the consumer's drive for the lowest price that creates the market for these illicit goods, so they are not blameless. Additionally, illicit supply chains are hard to attack and often times the consumer "really should have known better", so one of the ways to attack that supply chain is by slapping the hand of the consumer who patronized it, whether or not they actually meant to buy stolen goods.
It's hard to deal with the "Well it was cheap and he was shady but I just didn't ask too many questions" purchases; responsibility is very diffuse, with everyone doing their best to avoid responsibility.
The FTDI OSX drivers will still randomly cause kernel panics when the device is unplugged and a program still holds an open file descriptor for the serial port. While working with a company which was developing and selling products with FTDI chips in them, we made FTDI aware of this issue and attached many panic logs.
It's been about 5 years and they've still yet to actually fix it.
It's not a great situation, but where does FTDI responsibility for supporting counterfeit devices start and end?
If they let it continue more devices may hijack their USB VID, perhaps with bugs and glitches. Should they patch their driver to protect their reputation?
I've also attempted to report this by phone as suggested by XXXX. I've never experienced such difficulty trying to report a security issue; I'd have expected that you'd have processes in place, but apparently not.
My first attempt was met by a CSR who informed me that he knew of no protocol for reporting security issues, and that he couldn't help me because it wasn't directly effecting my computer. He then hung up on me when I asked to speak to a supervisor.
Second call got me a much more helpful chap, who after conferring with a supervisor, transferred me to professional services. The person I spoke with there said they also didn't have any security reporting protocol, or if they did, he didn't know about it. When I said the issue could effect thousands of devices, he transferred me through to 'corporate'.
I ended up going through an IVR system to an operator, who was no help whatsoever. She was entirely the wrong person to speak to; she was also completely ignorant of any security reporting process, and didn't know who to transfer me to.
Could you please call me on +61 XXX XXX XXX to acknowledge receipt of this report, and to discuss it? Thanks.
An update to this: the security folks have told me it’s not a security issue, but they’re forwarding it to the appropriate team.
Perhaps I’m biased, but I’d have thought that a Windows Update that ships malware that bricks thousands of consumer devices without warning would constitute a security issue.
But hey … at least they’re actioning it, and they responded so quickly. So, FYI: if you have a security issue to report to Microsoft, do it by email. Phone staff are utterly, completely useless for this.
Another update: Microsoft had already been made aware of the issue, and were investigating. I've lodged a formal compliment over the way their security team responded to my report (once I found them). Prompt, helpful, efficient and reassuring.
This is so incredibly tone-deaf and borderline childish, its shocking how badly FTDI as a company is run. It sounds like its run by a handful of pissed off neckbeards who don't know how bad publicity and a class action suit could destroy their company.
From that page: "FTDI is definitely not targeting end users - if you're unsure if ICs are genuine then please don't use the drivers."
This is where I think they are mistaken, because end users may be downloading and installing the drivers themselves. I have done this on more than one occasion: Some gadget has a USB port and I find that it uses the FTDI chip, so I go to the web page and download the FTDI drivers for it. This may happen quite frequently, for instance when an end user moves a gadget from one PC to another, and (mistakenly assumes that) they want the latest driver.
I'm disappointed because I was a big fan of FTDI and use them in a lot of my projects. I won't just go and burn all of my FTDI chips, but I am sufficiently motivated to look for an alternative. Looks like SparkFun has a couple of breakout boards for the Silicon Labs chips.
Ouch, something tells me the Arduino, Raspberry Pi, etc. forums are going to be full of people that are confused why they can't talk to their device anymore. IMHO it's pretty bad to target the consumers who probably don't even know or care that there's an FTDI chip in their device. Certainly am not condoning piracy of the chips, but wonder if there's a better way of handling the situation than breaking everyone.
I'd never even heard of FTDI before but they can rest assured that if I ever need a USB-to-UART chip that FTDI won't be the company I choose to buy. FTDI's drivers refusing to work with the fake parts is understandable, purposely reprogramming them to make them non-functional isn't.
Does 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.
Let's hope that all the manufacturers are 100% certain of their supply chains, from top to bottom. And that there are no bugs in the driver that might cause inadvertent bricking.
I'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]?
They're not in the OPL, but Microchip makes several chips that support full-speed USB, and they provide a CDC driver, too. I prefer them to using an Arduino because almost all of them are available in a DIP form factor, making them great for prototyping projects; available with different number of pins and features (10 vs 12-bit ADC, etc); and cost less than an ATMEGA328 +FTDI. Some of the chips are fully USB compliant without a crystal.
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.
not sure, but shouldn't you be able to use the ATMEGA32U4-AU as the microcontroller and get usb for free? Here's a good place to start for a bootloader that'll do your usb setup for you... http://forum.arduino.cc/index.php?topic=124459.15
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.
Assuming that this disassembly/decompiled code indeed is genuine, the interesting thing is explained in the 2nd comment block: A genuine FTDI device seems to be designed such that a write only to the offset that stores the PID is ignored, hence for a genuine part this code will only update the word at offset 62, and that would be matching the functionality to just update the eeprom checksum.
For comparison, here's a random mainling-list post which includes a dump of the 232 eeprom. The VID/PID is stored at word 1 and 2 of the eeprom, something that could be a checksum is down at the word with offset 0x7f (word 0x3f = 63? There's probably a off-by-one here).
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.
Does anyone know of good FTDI alternatives? Are there any clone makers that are relatively legit (i.e. they put their actual brand name on the chip, they support drivers, etc)? At $4.50 a pop for bog-standard bit-banging in a day and age where you can get ARM M4 SoCs for $2.75 a pop (n=1 prices) I would think FTDI would have more above-the-table competition than they do.
Is the subterfuge required for illegitimate cloning really that much easier than getting a website, writing docs, and supporting drivers?!
So they are rewriting the USB Product ID in EEPROM, only on "fake" chips, hence the Windows USB driver doesn't recognize the device anymore. It should be reprogrammable using the right tools. (https://twitter.com/marcan42/status/525134266112303104)
What allows them to do things differently on different chips: "Figured out the real/clone FTDI difference: EEPROM is written in 32bit units. Even writes are ignored (buffered), odds write both halves." https://twitter.com/marcan42/status/525194603746426881
[+] [-] Someone1234|11 years ago|reply
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 wind up with multiple dead USB devices. There's no reasonable way a consumer can know they are buying something with a fake chip and this could kill devices years old, which will be outside of warranty.
I am totally serious that Microsoft should step in. FTDI's driver is so defective that it is literally killing hardware, if they won't step in for this then what will they step in for?
[+] [-] geographomics|11 years ago|reply
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 signatures.
[+] [-] 0x0|11 years ago|reply
[+] [-] lotu|11 years ago|reply
[deleted]
[+] [-] amckenna|11 years ago|reply
http://zeptobars.ru/en/read/FTDI-FT232RL-real-vs-fake-supere...
Exerpt:
"What's the economic reason of making software fake of well-known chip instead of making new one under your own name? This way they don't need to buy USB VID, sign drivers in Microsoft, no expenses on advertisement. This fake chip will be used right away in numerous mass-manufactured products. New chip will require designing new products (or revisions) - so sales ramp up will happen only 2-3 years later. Die manufacturing cost is roughly the same for both dies (~10-15 cents)."
[+] [-] userbinator|11 years ago|reply
http://en.wikipedia.org/wiki/Semiconductor_Chip_Protection_A...
It's also completely legal to reverse-engineer an existing IC to duplicate its functionality in a different manner, which the cloners have definitely done in this case - they are completely different.
So it appears that the only thing the fake FTDI chip is violating is the trademark "FTDI", which might not even have been put there by the fab that produced the die, since they're branded 'Supereal'.
[+] [-] danesparza|11 years ago|reply
[+] [-] tmp26|11 years ago|reply
[+] [-] 0x0|11 years ago|reply
Takeaway lesson: End users should never touch anything remotely FTDI-like, since it's probably impossible to verify if the device is genuine or not. Wonder if FTDI thought this through.
[+] [-] npsimons|11 years ago|reply
I actually hope that this does cause an event drastic enough so that FTDI will have blood on its hands that ends in jail time for management and engineers. I don't want to see anyone hurt, especially not innocent third parties, but fuck FTDI, fuck the management who ordered this, and fuck the engineer(s) who didn't quit in protest. I'm not easily offended, but as a programmer who has been responsible for code that would result in loss of life if I made it defective by design, I have no sympathy for this sort of thing. One other thing that I could hope for is that this teaches everyone the true cost of closed source, especially drivers. Don't put up with it.
[+] [-] gioele|11 years ago|reply
Can you picture a Linux or *BSD driver in which there is an intentional
[+] [-] mhandley|11 years ago|reply
[+] [-] osivertsson|11 years ago|reply
I doubt very few vendors will realize if a fake FTDI chip is part off their manufactured product even after rigorous testing since the functionality is correct (until you get this driver).
EDIT: I doubt FTDI have thought this through. I will share this with the hardware designers I know and most will probably react like on the linked thread, and just switch to another chip to avoid any possible hassle.
[+] [-] JackC|11 years ago|reply
- Intentionally sabotaging someone's stuff, legally, is more or less the same as intentionally taking it. Keying a car and driving it away might have different names but are on the same scale.
- There ain't no self help. If you think someone else's stuff should actually be your stuff, your path is through a court.
- We don't fix things with injunctive relief that can be fixed with money. When Apple proves that Samsung violated a patent or vice versa, we don't collect and burn all the infringing phones, we just make someone cut a check. Because we are not idiots.
- The "someone" who cuts the check is Samsung or Apple, not their customers. As far as I know no one's managed to go after end users, even in extreme cases like a $10 designer handbag where the buyer obviously knows it's not real. (And it's at best unclear whether going after the buyers would make any sense, even in those extreme cases -- if someone pays knockoff prices for a knockoff product, it's the seller and not the buyer who has ill-gotten gains. There might be some additional reputation damage and lost profits that the buyer is complicit in, but it makes a lot more sense to me -- and apparently everyone else -- to make the seller pay for those as well.)
- When you do go after the seller of trademarked goods and want to seize those goods, we actually have a procedure for that -- Section 34 of the Lanham Act.[1] Which includes a whole bunch of protections like swearing out an affidavit, getting permission from a judge, informing the attorney general, posting a bond to cover damages, conducting the seizure through government agents, and keeping the seized items in the custody of the court. It's very much unlike showing up at someone's house and breaking their stuff.
(I am a lawyer; I am not a trademark lawyer; I just googled some stuff based on vague memories from law school to write this.)
[1] http://www.bitlaw.com/source/15usc/1116.html
[+] [-] pjc50|11 years ago|reply
Destruction of trademark-infringing goods and copied media is quite common, though.
In the UK, deliberately sabotaging hardware with drivers could be counted as a violation of the Computer Misuse Act, but there are hardly ever any prosecutions under that law.
[+] [-] AlyssaRowan|11 years ago|reply
They aren't the first to do malicious copy-protection. It did not go well for the previous contenders. At all.
[+] [-] JackFr|11 years ago|reply
[+] [-] zippergz|11 years ago|reply
I think in the FTDI case, though, it would be really hard to argue that the end users should (or even could) know that the chip they have is counterfeit.
[+] [-] bri3d|11 years ago|reply
I think this is totally crappy. I see what they're trying to do (create market incentive for consumers to insist on real FTDI chips) but the reality is that it's just screwing over innocent consumers who buy a device.
[+] [-] sliverstorm|11 years ago|reply
The consumer isn't exactly innocent.
Hold on, hear me out.
It's similar to black market goods. A consumer wants the lowest possible price. It turns out the goods he bought are stolen property. He didn't know, but he is not waived of responsibility. If he was truly unwitting he will not be prosecuted, but the goods will still be repossessed, etc.
Basically, it is the consumer's drive for the lowest price that creates the market for these illicit goods, so they are not blameless. Additionally, illicit supply chains are hard to attack and often times the consumer "really should have known better", so one of the ways to attack that supply chain is by slapping the hand of the consumer who patronized it, whether or not they actually meant to buy stolen goods.
It's hard to deal with the "Well it was cheap and he was shady but I just didn't ask too many questions" purchases; responsibility is very diffuse, with everyone doing their best to avoid responsibility.
[+] [-] wrl|11 years ago|reply
It's been about 5 years and they've still yet to actually fix it.
[+] [-] lttlrck|11 years ago|reply
If they let it continue more devices may hijack their USB VID, perhaps with bugs and glitches. Should they patch their driver to protect their reputation?
[+] [-] duncan_bayne|11 years ago|reply
=====
Hi,
I've been advised to email this address by 'XXXX' at Microsoft Support.
FTDI is shipping a malware driver for Windows; if it detects what it thinks is a counterfeit device plugged in by USB, it bricks it. Details here:
http://www.eevblog.com/forum/reviews/ftdi-driver-kills-fake-...
I've also attempted to report this by phone as suggested by XXXX. I've never experienced such difficulty trying to report a security issue; I'd have expected that you'd have processes in place, but apparently not.
My first attempt was met by a CSR who informed me that he knew of no protocol for reporting security issues, and that he couldn't help me because it wasn't directly effecting my computer. He then hung up on me when I asked to speak to a supervisor.
Second call got me a much more helpful chap, who after conferring with a supervisor, transferred me to professional services. The person I spoke with there said they also didn't have any security reporting protocol, or if they did, he didn't know about it. When I said the issue could effect thousands of devices, he transferred me through to 'corporate'.
I ended up going through an IVR system to an operator, who was no help whatsoever. She was entirely the wrong person to speak to; she was also completely ignorant of any security reporting process, and didn't know who to transfer me to.
Could you please call me on +61 XXX XXX XXX to acknowledge receipt of this report, and to discuss it? Thanks.
=====
[+] [-] duncan_bayne|11 years ago|reply
Perhaps I’m biased, but I’d have thought that a Windows Update that ships malware that bricks thousands of consumer devices without warning would constitute a security issue.
But hey … at least they’re actioning it, and they responded so quickly. So, FYI: if you have a security issue to report to Microsoft, do it by email. Phone staff are utterly, completely useless for this.
[+] [-] duncan_bayne|11 years ago|reply
[+] [-] yuhong|11 years ago|reply
[+] [-] SunboX|11 years ago|reply
[+] [-] drzaiusapelord|11 years ago|reply
[+] [-] analog31|11 years ago|reply
This is where I think they are mistaken, because end users may be downloading and installing the drivers themselves. I have done this on more than one occasion: Some gadget has a USB port and I find that it uses the FTDI chip, so I go to the web page and download the FTDI drivers for it. This may happen quite frequently, for instance when an end user moves a gadget from one PC to another, and (mistakenly assumes that) they want the latest driver.
I'm disappointed because I was a big fan of FTDI and use them in a lot of my projects. I won't just go and burn all of my FTDI chips, but I am sufficiently motivated to look for an alternative. Looks like SparkFun has a couple of breakout boards for the Silicon Labs chips.
[+] [-] nishonia|11 years ago|reply
[+] [-] guyzero|11 years ago|reply
[+] [-] swamp40|11 years ago|reply
Plugging in a USB is messy, and you will sometimes get an "Unrecognized Device" error, which you simply fix by unplugging and replugging.
I could see a similar hiccup causing their driver to sometimes "brick" a legitimate device.
Then this false positive ripples back to a manufacturer who bought 50,000 of those chips on the last run, and thinks they might all be fake...
It turns everything into a huge mess.
Very poor management decision, and shame on the engineers for implementing it.
[+] [-] tdicola|11 years ago|reply
[+] [-] alyandon|11 years ago|reply
I'd never even heard of FTDI before but they can rest assured that if I ever need a USB-to-UART chip that FTDI won't be the company I choose to buy. FTDI's drivers refusing to work with the fake parts is understandable, purposely reprogramming them to make them non-functional isn't.
[+] [-] dogecoinbase|11 years ago|reply
[+] [-] chrissnell|11 years ago|reply
http://en.wikipedia.org/wiki/Sony_BMG_copy_protection_rootki...
There were lawsuits and Sony ended up having to distribute a removal tool.
[+] [-] noonespecial|11 years ago|reply
They didn't preserve their brand with this action, they just destroyed it.
[+] [-] beagle3|11 years ago|reply
[+] [-] jrockway|11 years ago|reply
[+] [-] duncan_bayne|11 years ago|reply
https://twitter.com/JohnnySoftware/status/525092883125506048
Let's hope that all the manufacturers are 100% certain of their supply chains, from top to bottom. And that there are no bugs in the driver that might cause inadvertent bricking.
Way to go, FTDI.
[+] [-] dmitrygr|11 years ago|reply
[+] [-] imrehg|11 years ago|reply
[1]: https://www.hwtrek.com/product_preview/VTZUZV9k [2]: http://www.seeedstudio.com/wiki/Open_parts_library
[+] [-] watchdogtimer|11 years ago|reply
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.
[+] [-] Vendan|11 years ago|reply
[+] [-] rasz_pl|11 years ago|reply
[+] [-] cnvogel|11 years ago|reply
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 disassembly/decompiled code indeed is genuine, the interesting thing is explained in the 2nd comment block: A genuine FTDI device seems to be designed such that a write only to the offset that stores the PID is ignored, hence for a genuine part this code will only update the word at offset 62, and that would be matching the functionality to just update the eeprom checksum.
For comparison, here's a random mainling-list post which includes a dump of the 232 eeprom. The VID/PID is stored at word 1 and 2 of the eeprom, something that could be a checksum is down at the word with offset 0x7f (word 0x3f = 63? There's probably a off-by-one here).
http://developer.intra2net.com/mailarchive/html/libftdi/2009...
[+] [-] makomk|11 years ago|reply
[+] [-] jjoonathan|11 years ago|reply
Is the subterfuge required for illegitimate cloning really that much easier than getting a website, writing docs, and supporting drivers?!
[+] [-] orik|11 years ago|reply
The workaround once your chip has been flashed by the new driver is modifying the driver to communicate with devices that have a PID of 0.
[+] [-] Aissen|11 years ago|reply
Commented reverse engineering assembly: https://twitter.com/marcan42/status/525126731431038977
So they are rewriting the USB Product ID in EEPROM, only on "fake" chips, hence the Windows USB driver doesn't recognize the device anymore. It should be reprogrammable using the right tools. (https://twitter.com/marcan42/status/525134266112303104)
What allows them to do things differently on different chips: "Figured out the real/clone FTDI difference: EEPROM is written in 32bit units. Even writes are ignored (buffered), odds write both halves." https://twitter.com/marcan42/status/525194603746426881
And some wisdom:
"For those unfamiliar with embedded engineering: most USB (and other) devices can be bricked if maliciously attacked." "Assume ALL devices are brickable by evil code unless proven otherwise. This isn't news. Most devices make no attempt to protect themselves." (https://twitter.com/marcan42/status/525137221431463937 https://twitter.com/marcan42/status/525137463107272704)