FTDI driver kills fake FTDI FT232??

[markb82]

A local cache isn't really going to do much good if they actually want them to not work with their software (old/new) as HDCP can do. There is no local cache in HDCP once the revocation is updated it sticks and removing it isn't possible (probably is). The PID change effectively does the same thing.

A local cache would not help with past drivers, this is true, but I think that is something FTDI has to accept, and move forward.  Innovate their chips, improve their IP, and add some sort of SHA based authentication into their chips at a bare minimum.

Changing the PID is not effectively the same, because it also kills legal clone interoperation with 3rd party drivers which would need to be updated on every BSD and Linux system.  This is the big liability FTDI sees, and why the driver had to be pulled, and why FTDI is denying the PID change was intentional.  Changing the PID also causes the clone to silently fail with old FTDI drivers, so again not a very good solution.

There is no best solution: one is more destructive and opens you to liability, the other is less destructive but will not prevent people from using older drivers.  I thought I read in the previous posts that someone has changed the INF file on the older driver to accept PID 0000, which means people will be able to use a modified old driver anyway.

Something like Error 43, Windows has stopped this device because it has reported problems.
Or not sure if FTDI can call this error but Error 48, The software for this device has been blocked from starting because it is known to have problems with Windows. Contact the hardware vendor for a new driver. (That is probably an avenue to block older driver versions)

Yes a proper error code, or a notification pop-up, would have to be a part of any solution, there we agree.

[markb82]

Goodwill and trust takes years to build up and one mistake to tear down in an instant.

But in any case I think higher levels of integration are more a threat to FTDI you can get micro's with built in USB support, Ethernet, RF, ... and the market moves fast and getting the entire thing on one SoC is quite appealing. I'm looking into getting our 1st year boards down to a single chip solution and I'm pretty sure if spent the time it would be easy to build what we need as most of our stuff is old designs passed down from years ago.

Bottom line is FTDI screwed up their response, started a massive burn goodwill bonfire, and I think is still stoking it. (Regardless of if they are allowed to do it or not) I think that is something that is very clear.

Seriously is probably going to be a good example of failed PR I should recommend it to APSC prof that does a course on that kind of stuff (Business case studies)

I think you hit the nail on the head, or even nailed it into FTDI's coffin.  When I started using FTDI the AT90S8515 was still a mainstream part, ATMEGAs were just starting to come out from Atmel, although many were vapourware, and certainly none had integrated USB.  That was over a decade ago, and now it's a different ballgame.  About a decade ago I had the chance to use the LPC2146 when it first came out, and wrote both the firmware (with heavy help from app notes) and the windows side drivers (with heavy help of libusb).  The chip was still fairly expensive back then, now you can get ARM Cortex-M3s with USB for less than an FT232.

Not only did FTDI screw-up their response, they did the wrong thing in the first place.

[a210210200]

A local cache isn't really going to do much good if they actually want them to not work with their software (old/new) as HDCP can do. There is no local cache in HDCP once the revocation is updated it sticks and removing it isn't possible (probably is). The PID change effectively does the same thing.

A local cache would not help with past drivers, this is true, but I think that is something FTDI has to accept, and move forward.  Innovate their chips, improve their IP, and add some sort of SHA based authentication into their chips at a bare minimum.

Changing the PID is not effectively the same, because it also kills legal clone interoperation with 3rd party drivers which would need to be updated on every BSD and Linux system.  This is the big liability FTDI sees, and why the driver had to be pulled, and why FTDI is denying the PID change was intentional.  Changing the PID also causes the clone to silently fail with old FTDI drivers, so again not a very good solution.

There is no best solution: one is more destructive and opens you to liability, the other is less destructive but will not prevent people from using older drivers.  I thought I read in the previous posts that someone has changed the INF file on the older driver to accept PID 0000, which means people will be able to use a modified old driver anyway.

Something like Error 43, Windows has stopped this device because it has reported problems.
Or not sure if FTDI can call this error but Error 48, The software for this device has been blocked from starting because it is known to have problems with Windows. Contact the hardware vendor for a new driver. (That is probably an avenue to block older driver versions)

Yes a proper error code, or a notification pop-up, would have to be a part of any solution, there we agree.

Wonder what are the chances they are going to go on a rampage and try to wipe out of existence their older drivers... (That would be futile but given how they have responded it wouldn't be surprising)

Legal clones shouldn't be using FTDI's VCP driver by default so they would have a different VID/CID to be very clean room style developed legal clones with their own VCP driver for proper interoperability. Which may or may not be so close or functionally identical to FTDI's interface that if you did change the VID/CID to match it would have worked with old FTDI drivers but devs have to test that themselves and they would in the new FTDI drivers realize it doesn't work properly and revert to using their proper clone VID/PID and tell users FTDI isn't being nice. FTDI probably sees more a giant backlash of the online community than legal issues including their continued poor handling of the situation. (Bottom line is that the bad PR is more damaging than any legal case would likely ever be if ever)

The bypass is trivial for FTDI PID 0000 mess just like how the master HDCP key is also in the wild making the revocation system pretty ineffective from a technical standpoint. Its just a poor mean method of revoking use that both FTDI and HDCP do.

But yes I think we mostly agree FTDI screwed up big time and the proper nice thing to do is use less invasive methods to inform users that they have been scammed. Microsoft learned that restricting access is not a nice thing to do and logging people out after a timer is also pretty mean, now it just makes your desktop black and has a nag watermark. HDCP did not learn however and HDCP 2.2 is just going to be worse. (Even worse is that it is going to affect basically every media interface out there, key revocation may actually brick things people would never expect)

We will see what their next driver does and it will be super face palm if they just keep on digging. (Their PR is also abysmal and needs a critical human update)

[a210210200]

Goodwill and trust takes years to build up and one mistake to tear down in an instant.

But in any case I think higher levels of integration are more a threat to FTDI you can get micro's with built in USB support, Ethernet, RF, ... and the market moves fast and getting the entire thing on one SoC is quite appealing. I'm looking into getting our 1st year boards down to a single chip solution and I'm pretty sure if spent the time it would be easy to build what we need as most of our stuff is old designs passed down from years ago.

Bottom line is FTDI screwed up their response, started a massive burn goodwill bonfire, and I think is still stoking it. (Regardless of if they are allowed to do it or not) I think that is something that is very clear.

Seriously is probably going to be a good example of failed PR I should recommend it to APSC prof that does a course on that kind of stuff (Business case studies)

I think you hit the nail on the head, or even nailed it into FTDI's coffin.  When I started using FTDI the AT90S8515 was still a mainstream part, ATMEGAs were just starting to come out from Atmel, although many were vapourware, and certainly none had integrated USB.  That was over a decade ago, and now it's a different ballgame.  About a decade ago I had the chance to use the LPC2146 when it first came out, and wrote both the firmware (with heavy help from app notes) and the windows side drivers (with heavy help of libusb).  The chip was still fairly expensive back then, now you can get ARM Cortex-M3s with USB for less than an FT232.

Not only did FTDI screw-up their response, they did the wrong thing in the first place.

I can agree they did a very bad, wrong, mean thing to PID 0000 people's stuff into what I call reduced functionality mode and what others considered killed (I'm very optimistic and know enough that it isn't actually dead). The bottom line is the same. Well within their rights to do random ass stuff as its their driver but it doesn't feel very nice like how I hate HDCP with a passion and it works basically the same way in meddling with your hardware. (So me associating FTDI's actions with HDCP's system is not exactly a glowing endorsement)(HDCP is worse because it messes up everything if you even look at it the wrong way)

And then FTDI followed up with a horrible PR response that is still going.

I can help people if they need assistance in bypassing or customizing the old driver to work with PID 0000. (No time frame is guaranteed though) and its no charge, no response expected time frame type support.

[f4eru]

It does still work to stop working it would be impossible to talk to it or use it which if you can run the command at the bottom you certainly are using it.

No. A device with a PID of 0 is not respecting USB specification.
The modification to PID 0 is in fact bricking the device. it's sheer luck that linux does not enforce PID !=0
Yeah, you can repair it to the previous state, but this needs effort, time and tools -> this costs to the user.
Anyway, a lot of the HW will be thrown awy, because the user does not know why it suddently fails ! That's bricking.

[a210210200]

>> It does still work to stop working it would be impossible to talk to it or use it which if you can run the command at the bottom you certainly are using it.

No. A device with a PID of 0 is not respecting USB specification.
The modification to PID 0 is in fact bricking the device. it's sheer luck that linux does not enforce PID !=0
Yeah, you can repair it to the previous state, but this needs effort, time and tools -> this costs to the user.
Anyway, a lot of the HW will be thrown awy, because the user does not know why it suddently fails ! That's bricking.

I don't have a fake device but FT_PROG and the such will reprogram it and detects them. You just have to modify the inf files first. I've tested the install part myself windows does not complain about a bunch of PID 0000 strings and the driver installs with a warning of modification.

Very little stuff is USB compliant.

[f4eru]

I've tested the install part myself windows does not complain about a bunch of PID 0000 strings

Yep, you kinda can repair it. But not on new versions of windows, which do not accept PID0.
And as i said, the repair of the FTDI damage costs the users and the serious device manufacturers, not the chinese clones and counterfeit chip makers, and not the cheap device manufacturers.

[markb82]

Wonder what are the chances they are going to go on a rampage and try to wipe out of existence their older drivers... (That would be futile but given how they have responded it wouldn't be surprising)

Yep, indeed very futile.

Legal clones shouldn't be using FTDI's VCP driver by default so they would have a different VID/CID to be very clean room style developed legal clones with their own VCP driver for proper interoperability. Which may or may not be so close or functionally identical to FTDI's interface that if you did change the VID/CID to match it would have worked with old FTDI drivers but devs have to test that themselves and they would in the new FTDI drivers realize it doesn't work properly and revert to using their proper clone VID/PID and tell users FTDI isn't being nice. FTDI probably sees more a giant backlash of the online community than legal issues including their continued poor handling of the situation.

Really depends on if you consider VID/PID property of FTDI, which I do not.  Several posts have discussed VID and PID ownership. Clones were using the VID/PID, however the clones did not contain any FTDI IP themselves, and if used with Linux or BSD are perfectly legal.  If used with FTDI's Windows driver, they would be considered in violation of the EULA (if that's really worth the paper its written on) however two wrongs don't make a right, so I don't believe you can just wipe their PID, and in doing so prevent legitimate uses of the clones with 3rd party drivers. (yes new drivers can be written, but any old BSD or Linux drivers need modification)

(Bottom line is that the bad PR is more damaging than any legal case would likely ever be if ever)

Couldn't agree more, sad, but yes that will likely be the case.

I'll need to read up on HDCP, so I can't comment.

[a210210200]

I've tested the install part myself windows does not complain about a bunch of PID 0000 strings

Yep, you kinda can repair it. But not on new versions of windows, which do not accept PID0.
And as i said, the repair of the FTDI damage costs the users and the serious device manufacturers, not the chinese clones and counterfeit chip makers, and not the cheap device manufacturers.

If your talking about windows 8/8.1 then use a VM or just a live USB key (those live linux tools are a lifesaver) (i'll test that too at some point I'm on win 7 right now). I can help with that as well. (I'm waiting for windows 10, what happened to Windows 9 Microsoft...) The "repair" if you can even call it that is a joke but I guess I'm in the minority on that but it still is a joke trivial fix. (Windows 8/8.1 is a joke too, sorry I guess I'm starting to see why companies are so slow at updating software it always takes a few tries to get it right) To be fair I'm used to having a USB floppy drive handy with discs just in case windows xp needs a disc during install (Slipstreaming neater but sometimes I'm lazy)...

Many updaters need dos, linux to work anyways so that is pretty normal.

[nitro2k01]

No. A device with a PID of 0 is not respecting USB specification.
The modification to PID 0 is in fact bricking the device. it's sheer luck that linux does not enforce PID !=0
Yeah, you can repair it to the previous state, but this needs effort, time and tools -> this costs to the user.
Anyway, a lot of the HW will be thrown awy, because the user does not know why it suddently fails ! That's bricking.

I don't have a fake device but FT_PROG and the such will reprogram it and detects them. You just have to modify the inf files first. I've tested the install part myself windows does not complain about a bunch of PID 0000 strings and the driver installs with a warning of modification.

I tried this too on a scrap device with an FTDI chip. I programmed the PID to 0000 but left the VID intact. The device first showed up as unknown in the device manager, but I could make the VCP driver into attaching to it using the update driver guide and selecting the driver manually, without even editing the INF file. This is with an older version of the VCP driver and in Windows 7 though. I'll get the scope out later and check the serial communication still works, but I would assume it does.

Would be interesting to find out if this method of coaxing the driver into attaching to the chip, even the older version, works with a fake chip with its PID set to 0000.

Speaking of which, does anyone know where to reliably get a fake chip, or a product with a fake chip? (I don't want to gamble and risk getting a genuine one for experiments.  )

[a210210200]

Wonder what are the chances they are going to go on a rampage and try to wipe out of existence their older drivers... (That would be futile but given how they have responded it wouldn't be surprising)

Yep, indeed very futile.

Legal clones shouldn't be using FTDI's VCP driver by default so they would have a different VID/CID to be very clean room style developed legal clones with their own VCP driver for proper interoperability. Which may or may not be so close or functionally identical to FTDI's interface that if you did change the VID/CID to match it would have worked with old FTDI drivers but devs have to test that themselves and they would in the new FTDI drivers realize it doesn't work properly and revert to using their proper clone VID/PID and tell users FTDI isn't being nice. FTDI probably sees more a giant backlash of the online community than legal issues including their continued poor handling of the situation.

Really depends on if you consider VID/PID property of FTDI, which I do not.  Several posts have discussed VID and PID ownership. Clones were using the VID/PID, however the clones did not contain any FTDI IP themselves, and if used with Linux or BSD are perfectly legal.  If used with FTDI's Windows driver, they would be considered in violation of the EULA (if that's really worth the paper its written on) however two wrongs don't make a right, so I don't believe you can just wipe their PID, and in doing so prevent legitimate uses of the clones with 3rd party drivers. (yes new drivers can be written, but any old BSD or Linux drivers need modification)

(Bottom line is that the bad PR is more damaging than any legal case would likely ever be if ever)

Couldn't agree more, sad, but yes that will likely be the case.

I'll need to read up on HDCP, so I can't comment.

On the futile part I've actually seen a handful of pretty successful attempts to remove programs from the internet at least from a quick google search perspective. But getting rid of the old driver would be doomed to fail because so many more copies exist. (The Streisand effect would be in 1000%+ effect as well, the successful ones did it without being noticed or no one really cared)

I think on the PID/VID thing we just have a difference in opinion which doesn't affect the bottom line of its not nice regardless of their right to or not to mess around with it.

HDCP the first time I heard of it was back in 2005, just search Google for "HDCP evil". In the end the good prevailed with the master key being reverse engineered. But the challenge will continue with HDCP 2.2 which is coming to your devices about right now and eventually will block new content from working with older non HDCP 2.2 equipment making real expensive stuff I bought a year ago an is in a reduced functionality mode by default where the latest content/heck even latest resolutions just won't work (and my equipment isn't even fake and there is no good reason why it should be blocked...) I'm into home theater stuff (made my own custom 3d systems for fun) and HDCP is a pain for even perfectly legal/official uses.

HDCP2.0,2.1 were broken very quickly but I haven't heard of anything about HDCP 2.2 (Its going to be retroactive too and will be required on HDMI/DVI/Displayport/... links depending on what they flag as needing it)

[markb82]

Speaking of which, does anyone know where to reliably get a fake chip, or a product with a fake chip? (I don't want to gamble and risk getting a genuine one for experiments.  )

I believe some people earlier in the thread suggested cheapest ones on Amazon.  I would personally go onto eBay and get any of the ones shipped direct from China.  Would be fun to get the die out of those chips and inspect them under the SEM, see if there are any markings, just generally learn about the clones.  Unfortunately I lost my SEM access when I left UBC.

Also anyone feel like writing an FTDI compatible implementation based on a microcontroller with USB?  Could be fun

[nitro2k01]

Would be fun to get the die out of those chips and inspect them under the SEM, see if there are any markings, just generally learn about the clones.  Unfortunately I lost my SEM access when I left UBC.

http://zeptobars.ru/en/read/FTDI-FT232RL-real-vs-fake-supereal

[a210210200]

No. A device with a PID of 0 is not respecting USB specification.
The modification to PID 0 is in fact bricking the device. it's sheer luck that linux does not enforce PID !=0
Yeah, you can repair it to the previous state, but this needs effort, time and tools -> this costs to the user.
Anyway, a lot of the HW will be thrown awy, because the user does not know why it suddently fails ! That's bricking.

I don't have a fake device but FT_PROG and the such will reprogram it and detects them. You just have to modify the inf files first. I've tested the install part myself windows does not complain about a bunch of PID 0000 strings and the driver installs with a warning of modification.

I tried this too on a scrap device with an FTDI chip. I programmed the PID to 0000 but left the VID intact. The device first showed up as unknown in the device manager, but I could make the VCP driver into attaching to it using the update driver guide and selecting the driver manually, without even editing the INF file. This is with an older version of the VCP driver and in Windows 7 though. I'll get the scope out later and check the serial communication still works, but I would assume it does.

Would be interesting to find out if this method of coaxing the driver into attaching to the chip, even the older version, works with a fake chip with its PID set to 0000.

Speaking of which, does anyone know where to reliably get a fake chip, or a product with a fake chip? (I don't want to gamble and risk getting a genuine one for experiments.  )

I just ordered some direct from china from a bunch of as fake looking as possible chips. (other than one that listed FT chip but had a completely different chip in the picture as I don't want a bunch of lamp sockets like I got with one order I made for LEDs, the seller had the gall to say pay for return shipping (3x the value of the goods they shipped wrongly) and wait 30-50 days for a refund, I am still going to return it to them by ultra-snail mail in getting anyone I know who is visiting china in the next whenever to mail it locally)

Fake chips (if you can trust a listing to actually show the fake chip) have a different outer packaging and are not exactly the same as the real one I think and if they make it low resolution enough (or just lie and put a real one in the image) its hard to tell. (A product can have real ones mixed in with fake ones they might not even be aware or care themselves)

Since I can easily deal/ID fake chips and I do actually want try a DIY 10 minute to capture die shot at home with no special equipment or chemicals, like I did a few pages ago to a real FT chip. Only problem is shipping is super slow so and paying to ship quickly is like 100x the value of the products total since I'm ordering from a bunch of different sellers.

If I get enough fake ones I can send you one for purely academic purposes of course. (The ETA to arrive is probably 30-60 days given how things have come in the past, sometimes they don't even ship though so I'll see)

[eneuro]

No. A device with a PID of 0 is not respecting USB specification.
The modification to PID 0 is in fact bricking the device. it's sheer luck that linux does not enforce PID !=0

I don't have a fake device but FT_PROG and the such will reprogram it and detects them. You just have to modify the inf files first. I've tested the install part myself windows does not complain about a bunch of PID 0000 strings and the driver installs with a warning of modification.

Just wrote sample ftdi_fake.c Linux 2.6.x kernel module to invetsigate this if is it possible to attach USB device with unchanged FTDI_VID= 0x403 (hex) and PID= 0x0 (0) 

Code: [Select]

#include <linux/module.h>    // included for all kernel modules
#include <linux/kernel.h>    // included for KERN_INFO
#include <linux/init.h>      // included for __init and __exit macros
#include <linux/errno.h>
#include <linux/slab.h>

#include <linux/tty.h>
#include <linux/tty_driver.h>
#include <linux/tty_flip.h>
#include <linux/module.h>
#include <linux/spinlock.h>
#include <asm/uaccess.h>
#include <linux/usb.h>
#include <linux/serial.h>
#include <linux/usb/serial.h>

/*
 *  * Version Information
 *   */
#define DRIVER_VERSION "v0.0.1"
#define DRIVER_AUTHOR "Eneuro"
#define DRIVER_DESC "A Simple walk around FTDI fake PID "

#define FTDI_VID 0x0403 /* FTDI vendor Id */
///#define FTDI_232RL_PID 0xFBFA  /* FTDI 232RL PID 0xFBFA or 0x6001 */ 
#define FTDI_FAKE_PID 0x0    /* FTDI fake PID */

static int debug;
static __u16 vendor = FTDI_VID;
static __u16 product= FTDI_FAKE_PID;

static struct usb_device_id id_table [] = { { USB_DEVICE(FTDI_VID, FTDI_FAKE_PID) }, { }, };

MODULE_DEVICE_TABLE(usb, id_table);

static int __init ftdi_fake_init(void)
{

dbg("%s", __FUNCTION__);
if(vendor > 0 && product >= 0) {
    printk(KERN_INFO "The key is to set to default product ID in Linux FTDI driver to 0x0 and add it to FTDI usb device id's table !!!" );
        }

    printk(KERN_INFO KBUILD_MODNAME ": " DRIVER_VERSION ": "
DRIVER_DESC "\n");
 /*   printk(KERN_INFO "\n" ); */
    printk(KERN_INFO "vid: 0x%x\n", vendor );
    printk(KERN_INFO "pid: 0x%x\n", product );

    return 0;    // Non-zero return means that the module couldn't be loaded.
}

static void __exit hello_cleanup(void)
{
    printk(KERN_INFO "Cleaning up module.\n");
}

module_init(ftdi_fake_init);
module_exit(hello_cleanup);

MODULE_LICENSE("GPL");
MODULE_AUTHOR(DRIVER_AUTHOR);
MODULE_DESCRIPTION(DRIVER_DESC);

module_param(debug, bool, S_IRUGO | S_IWUSR);
MODULE_PARM_DESC(debug, "Debug enabled or not");
module_param(vendor, ushort, 0);
MODULE_PARM_DESC(vendor, "User specified FTDI vendor ID (default="
                __MODULE_STRING(FTDI_VID)")");
module_param(product, ushort, 0);
MODULE_PARM_DESC(product, "User specified FTDI product ID (default="
__MODULE_STRING(FTDI_FAKE_PID)")" );

This module does nothing for the moment, only print kernel messages when successfully loaded and outputs detected USB device vid and pid visible in $ dmesg  output, added usb aliases for this fake pid,
As you can notice changed also main module init condition to accept this fake PID=0
Than change this code module init code to accept this FTDI fake PID 0 :

static int __init ftdi_fake_init(void)
{

   dbg("%s", __FUNCTION__);
   if(vendor > 0 && product >= 0) {

The key is to add this fake PID to this table I guess too

Code: [Select]

static struct usb_device_id id_table [] = { { USB_DEVICE(FTDI_VID, FTDI_FAKE_PID) }, { }, };
so, this will create alias for 0x403, 0x0 usb device to be able to attach it to our driver 

"usb:v0403p0000d*dc*dsc*dp*ic*isc*ip*"

Additionaly, we probably want in module init, after detecting we have bricked FTDI with PID==0,
overwrite it to proper product (PID) value, while probably there is another stuff which connects to device so it needs proper PID in variable product later.
But for the moment, one need to ensure that Linux will be able to attach bricked usb chip to this ftdi_fake module I've wrote,
so after recompiling, installing (copying it)  in /lib/modules/...../ (where ftdi_sio sits )  we need also recreate those aliases with:

Code: [Select]

# depmod -a

Than we should be able see in module info this alias for our fake module, by typing:

Code: [Select]

$ modinfo ftdi_fake
alias:          usb:v0403p0000d*dc*dsc*dp*ic*isc*ip*
depends:        usbserial
vermagic:       2.6.30.10-105.2.23.fc11.x86_64 SMP mod_unload
parm:           debug:Debug enabled or not (bool)
parm:           vendor:User specified vendor ID (default=0x0403) (ushort)
parm:           product:User specified product ID (ushort)
If this attaching worked, than overriding product variable in module init to PID of 232RL which I'm not sure but based on oryginal header files is 0xFBFA, maybe could allow use this bricked device under Linux without any problems, if it is possible to attach usb device with PID 0 as I wrote earlier 

Code: [Select]

#define FTDI_232RL_PID 0xFBFA
product= FTDI_232RL_PID;

Unfortunate, I have no bricked FTDI stuff, so can not test it, but if you want take this ftdi_fake.c source code and recompile on 2.6.x Linux machine with oryginal FTDI  Makefile but change names inside from ftdi_sio to ftdi_fake 

They changed this PID to 0 while they know from Linux source that they make this devices also useless under Linux without extra work, while in their Linux manuals they suggest using standard Linux ftdi_sio kernel module, and those modules has condition of vendor and product to be >0 before any other initializations in 2.6.x kernels 

More details there https://www.eevblog.com/forum/reviews/what-should-ftdi%27s-next-driver-update-look-like/msg540077/#msg540077, while this thread is spammed by a210210200 .

[a210210200]

Speaking of which, does anyone know where to reliably get a fake chip, or a product with a fake chip? (I don't want to gamble and risk getting a genuine one for experiments.  )

I believe some people earlier in the thread suggested cheapest ones on Amazon.  I would personally go onto eBay and get any of the ones shipped direct from China.  Would be fun to get the die out of those chips and inspect them under the SEM, see if there are any markings, just generally learn about the clones.  Unfortunately I lost my SEM access when I left UBC.

Also anyone feel like writing an FTDI compatible implementation based on a microcontroller with USB?  Could be fun

I have cleanroom access, wetbench training. Not sure if the SEM still works well as everything from the mask aligner to the wet bench shield has problems last time I went in (all expensive second hand ebay stuff). But I don't think at the process scale the fake and real ones are you even need an SEM. An optical microscope should work just fine which I too have access to as well. I actually have a list of things I want to scan on a microscope like an credit card EMV chip of mines (wonder if the confocal can scan through the card plastic)

I don't really like cleanroom work more into the computer side of things since the chemicals are really really nasty stuff. (HF is horrible, antidote is on the benches directly for instant access, other solutions can eat through the bench, and others eat glass, and some eat any plastic (it took four washes to clean up I tiny drop used in training to show how strong the stuff is), and mix the two and you'll cause an explosion even with trace amounts)(And the one story the main lab tech told us is that a year or so ago someone put the wrong cap on the wrong bottle and it instantly blew the bottle apart, fortunately the person was wearing proper PPE and it was on the floor so it didn't kill/mame anyone.)

Direct from China is probably the best bet. I wonder if there is more than one die for the clones floating around. (Clones of clones?, Clone competition?)

[a210210200]

No. A device with a PID of 0 is not respecting USB specification.
The modification to PID 0 is in fact bricking the device. it's sheer luck that linux does not enforce PID !=0

I don't have a fake device but FT_PROG and the such will reprogram it and detects them. You just have to modify the inf files first. I've tested the install part myself windows does not complain about a bunch of PID 0000 strings and the driver installs with a warning of modification.

Just wrote sample ftdi_fake.c Linux 2.6.x kernel module to invetsigate this if is it possible to attach USB device with unchanged FTDI_VID= 0x403 (hex) and PID= 0x0 (0) 

Code: [Select]

#include <linux/module.h>    // included for all kernel modules
#include <linux/kernel.h>    // included for KERN_INFO
#include <linux/init.h>      // included for __init and __exit macros
#include <linux/errno.h>
#include <linux/slab.h>

#include <linux/tty.h>
#include <linux/tty_driver.h>
#include <linux/tty_flip.h>
#include <linux/module.h>
#include <linux/spinlock.h>
#include <asm/uaccess.h>
#include <linux/usb.h>
#include <linux/serial.h>
#include <linux/usb/serial.h>

/*
 *  * Version Information
 *   */
#define DRIVER_VERSION "v0.0.1"
#define DRIVER_AUTHOR "Eneuro"
#define DRIVER_DESC "A Simple walk around FTDI fake PID "

#define FTDI_VID 0x0403 /* FTDI vendor Id */
///#define FTDI_232RL_PID 0xFBFA  /* FTDI 232RL PID 0xFBFA or 0x6001 */ 
#define FTDI_FAKE_PID 0x0    /* FTDI fake PID */

static int debug;
static __u16 vendor = FTDI_VID;
static __u16 product= FTDI_FAKE_PID;

static struct usb_device_id id_table [] = { { USB_DEVICE(FTDI_VID, FTDI_FAKE_PID) }, { }, };

MODULE_DEVICE_TABLE(usb, id_table);

static int __init ftdi_fake_init(void)
{

dbg("%s", __FUNCTION__);
if(vendor > 0 && product >= 0) {
    printk(KERN_INFO "The key is to set to default product ID in Linux FTDI driver to 0x0 and add it to FTDI usb device id's table !!!" );
        }

    printk(KERN_INFO KBUILD_MODNAME ": " DRIVER_VERSION ": "
DRIVER_DESC "\n");
 /*   printk(KERN_INFO "\n" ); */
    printk(KERN_INFO "vid: 0x%x\n", vendor );
    printk(KERN_INFO "pid: 0x%x\n", product );

    return 0;    // Non-zero return means that the module couldn't be loaded.
}

static void __exit hello_cleanup(void)
{
    printk(KERN_INFO "Cleaning up module.\n");
}

module_init(ftdi_fake_init);
module_exit(hello_cleanup);

MODULE_LICENSE("GPL");
MODULE_AUTHOR(DRIVER_AUTHOR);
MODULE_DESCRIPTION(DRIVER_DESC);

module_param(debug, bool, S_IRUGO | S_IWUSR);
MODULE_PARM_DESC(debug, "Debug enabled or not");
module_param(vendor, ushort, 0);
MODULE_PARM_DESC(vendor, "User specified FTDI vendor ID (default="
                __MODULE_STRING(FTDI_VID)")");
module_param(product, ushort, 0);
MODULE_PARM_DESC(product, "User specified FTDI product ID (default="
__MODULE_STRING(FTDI_FAKE_PID)")" );

This module does nothing for the moment, only print kernel messages when successfully loaded and outputs detected USB device vid and pid visible in $ dmesg  output, added usb aliases for this fake pid,
As you can notice changed also main module init condition to accept this fake PID=0
Than change this code module init code to accept this FTDI fake PID 0 :

static int __init ftdi_fake_init(void)
{

   dbg("%s", __FUNCTION__);
   if(vendor > 0 && product >= 0) {

The key is to add this fake PID to this table I guess too

Code: [Select]

static struct usb_device_id id_table [] = { { USB_DEVICE(FTDI_VID, FTDI_FAKE_PID) }, { }, };
so, this will create alias for 0x403, 0x0 usb device to be able to attach it to our driver 

"usb:v0403p0000d*dc*dsc*dp*ic*isc*ip*"

Additionaly, we probably want in module init, after detecting we have bricked FTDI with PID==0,
overwrite it to proper product (PID) value, while probably there is another stuff which connects to device so it needs proper PID in variable product later.
But for the moment, one need to ensure that Linux will be able to attach bricked usb chip to this ftdi_fake module I've wrote,
so after recompiling, installing (copying it)  in /lib/modules/...../ (where ftdi_sio sits )  we need also recreate those aliases with:

Code: [Select]

# depmod -a

Than we should be able see in module info this alias for our fake module, by typing:

Code: [Select]

$ modinfo ftdi_fake
alias:          usb:v0403p0000d*dc*dsc*dp*ic*isc*ip*
depends:        usbserial
vermagic:       2.6.30.10-105.2.23.fc11.x86_64 SMP mod_unload
parm:           debug:Debug enabled or not (bool)
parm:           vendor:User specified vendor ID (default=0x0403) (ushort)
parm:           product:User specified product ID (ushort)
If this attaching worked, than overriding product variable in module init to PID of 232RL which I'm not sure but based on oryginal header files is 0xFBFA, maybe could allow use this bricked device under Linux without any problems, if it is possible to attach usb device with PID 0 as I wrote earlier 

Code: [Select]

#define FTDI_232RL_PID 0xFBFA
product= FTDI_232RL_PID;

Unfortunate, I have no bricked FTDI stuff, so can not test it, but if you want take this ftdi_fake.c source code and recompile on 2.6.x Linux machine with oryginal FTDI  Makefile but change names inside from ftdi_sio to ftdi_fake 

They changed this PID to 0 while they know from Linux source that they make this devices also useless under Linux without extra work, while in their Linux manuals they suggest using standard Linux ftdi_sio kernel module, and those modules has condition of vendor and product to be >0 before any other initializations in 2.6.x kernels 

More details there https://www.eevblog.com/forum/reviews/what-should-ftdi%27s-next-driver-update-look-like/msg540077/#msg540077, while this thread is spammed by a210210200 .

Linux is perfectly fine with the tools as well, just use "sudo ./ft232r_prog –old-pid 0x000 –new-pid 0x6001" there is also a .py script to even do it automatically for you someone else made that I posted a while ago in what you call "spam". Or are those tools not working?

[zapta]

The devices were on life support provided by the illegal use of FTDI drivers, FTDI figured out how to and turned off the switch. I believe it was within their rights to do so. No one is stopping you resurrecting the corpses by writing some other drivers or using the legal ones on Linux.

Rufus, you should petition FTDI to restore the VID reset.

Seriously, even FTDI realized they were wrong and you are the only one insisting that the VID should be reset.

[markb82]

http://bit.ly/1rUMwkt

New and Good quality !
Looks like a winner to me. Just over two dollars shipped.

[a210210200]

http://bit.ly/1rUMwkt

New and Good quality !
Looks like a winner to me. Just over two dollars shipped.

I wonder how to we review the sellers given we are intentionally looking for fakes. (I'll probably still give them 0 stars for a fake chip out of principle but it would be funny to see a review saying "expected fake chips got real ones, completely different than listing image" 0 stars )

[nitro2k01]

At least not as weird as...

[Fungus]

http://bit.ly/1rUMwkt

New and Good quality !
Looks like a winner to me. Just over two dollars shipped.

I can use them to replace the ones FTDI bricked. Get my devices working again.

[Fungus]

At least not as weird as...

I hate people who post XKCD images with no link - often the rollover text is as important as the comic.

("You can do this one in every 30 times and still have 97% positive feedback.")

[rolycat]

I hate people who post XKCD images with no link.

Fixed that for you.

[janoc]

Arguably you could say HDCP isn't legal either since the master key is leaked and it is no longer an "effective technical measure" it isn't really as anyone can make new HDCP keys themselves. But HDCP still is allowed to disable user equipment and is not banned in the EU and I don't think is facing any current legal challenges. Also with HDCP 2.2 it is just going to get even "better...", now it will be not backwards compatible, have distance latency checks, and all sorts of fun stuff.

Could we put this HDCP red herring out to pasture, please?

All that HDCP does is that Bluray discs can update a table of revoked keys and potentially "brick" unauthorized Bluray players. That is most likely illegal as well and the studios could get sued if someone got their player damaged like that.

You seem to imply that because nobody got sued, it is somehow legal, thus what FTDI did is legal too. Nonsense - the big difference with HDCP is that in order to legally (because of patent licenses, not applicable in FTDI case) implement a Bluray player, you must license the HDCP and agree to implement this sort of "feature" (and get the player certified that it does!). The Bluray consortium is extremely vigilant in stopping the unauthorized players from hitting the markets - typically via customs (same method as Fluke used to stop Sparkfun meters, Apple stopping sales of Samsung phones over patents, etc.). That is what FTDI should have done instead.

It is thus extremely rare that someone gets bitten by the player key revocation, thus the likelyhood of a lawsuit is very low - basically only greymarket imports can get affected, where you know that you are buying a product not intended for your market and thus all bets are off, not something you buy at Amazon in good faith (like a generic serial to USB adaptor), for example.

It is a difference between designing-in a killswitch and actually using it. Doesn't make it any more legal to brick the players, but the chance of actually doing harm to legit users (and thus getting sued) is fairly low. Basically HDCP is only "legal" because nobody has bothered to sue over a bricked grey market $200 player yet, that's all. The directive/DMCA protections don't apply here at all - nobody is trying to circumvent the protection mechanism. Also you have ignored the part 48 about not interfering with the normal functioning of the device.

Also you rarely get a critical equipment depend on a Bluray player - unlike something like the FTDI USB bridges, which can be parts of complex machinery and where breakage costs millions in lost production, for ex. I can guarantee you that the lawyers would come out in force should that happen somewhere - it is not end-user's responsibility to verify that all chips in his machine are genuine.

I wonder what other BS analogy will you come up with.