Re: [PATCH] usb: serial: Add "bricked" FTDI device PID
> On Thu, Oct 23, 2014 at 04:27:50PM +0800, Perry Hung wrote: >> It doesn't seem so, there's an IDA pro dump from somebody who decompiled the >> driver: >> >> https://twitter.com/marcan42/status/525126731431038977/photo/1 > > A picture of the source code created by disassembling a binary driver > that was written to brick a cloned USB controller device. > > Reverse engineering inception layers... And I used a Windows disassembler/decompiler... running on Wine, which itself is a clone of the Windows API. :-) FWIW, here's a more accurate analysis, after I had time to figure out exactly what's going on: https://marcan.st/transf/ftdi_evil.png The code only reprograms the PID to 0, but leave the VID alone. FTDI's driver's INF file only registers it for devices under FTDI's own VID, so it should be safe to say that this update will only bork devices with VID 0403, and so we only need to add 0403/ to the ID list. FTDI's code also only touches devices with bcdDevice & 0xFF00 == 0x600 (because, amusingly, the code will actually brick other legitimate FTDI devices, just not FT232RL due to its specific EEPROM quirk): https://marcan.st/transf/checkbrick.png Amusing note: they're evidently missing a return statement for non-232RL devices, which ended up returning the dev pointer as garbage, which confused the decompiler as to the type of the return value. It's ignored anyway, but it seems they don't care about compiler warnings! If some manufacturer incorporates this update into their own driver package, with a custom INF and VID, and they are also shipping counterfeit/clone chips, then we could end up with another VID also being affected, but this is probably relatively unlikely (hopefully those shipping their own customized drivers are aware of this saga and will either not ship this build or will make damn sure they haven't sold any devices with clones). (I hope I got the In-Reply-To header right this time around...) -- Hector Martin (hec...@marcansoft.com) Public Key: http://www.marcansoft.com/marcan.asc -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: serial: Add "bricked" FTDI device PID
On Thu, Oct 23, 2014 at 04:27:50PM +0800, Perry Hung wrote: > It doesn't seem so, there's an IDA pro dump from somebody who decompiled the > driver: > > https://twitter.com/marcan42/status/525126731431038977/photo/1 A picture of the source code created by disassembling a binary driver that was written to brick a cloned USB controller device. Reverse engineering inception layers... thanks for that link, very cool. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: serial: Add "bricked" FTDI device PID
On Thu, Oct 23, 2014 at 10:17:03AM +0200, Johan Hovold wrote: > On Thu, Oct 23, 2014 at 04:10:54PM +0800, Greg Kroah-Hartman wrote: > > On Thu, Oct 23, 2014 at 09:58:20AM +0200, Johan Hovold wrote: > > > On Thu, Oct 23, 2014 at 11:39:50AM +0800, Greg Kroah-Hartman wrote: > > > > On Wed, Oct 22, 2014 at 11:31:34PM -0400, Perry Hung wrote: > > > > > An official recent Windows driver from FTDI detects counterfeit > > > > > devices > > > > > and reprograms the internal EEPROM containing the USB PID to 0, > > > > > effectively > > > > > bricking the device. > > > > > > How sneaky. > > > > > > Is idProduct the only field that is rewritten? > > > > According to all of the reports I've read, yes, this is what happens, as > > there are api calls to the device that allow anyone to reprogram the > > idProduct field. > > > > > I'm curious about whether the type is still detected "correctly". > > > > What "type" are you referring to? > > We try to detect the type during probe (encoded as an enum > ftdi_chip_type), which is later used when setting the baud rate (but > also affects the packet layout for legacy SIO devices). > > It's done based on bNumInterfaces and bcdDevice. Ah, ok, I don't think those fields can be changed through the api. I could be totally wrong, I'm going to try to dig and find a "clone" device to test it out with, but for now, odds are, this patch should be all that is needed. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: serial: Add "bricked" FTDI device PID
On Thu, Oct 23, 2014 at 04:10:54PM +0800, Greg Kroah-Hartman wrote: > On Thu, Oct 23, 2014 at 09:58:20AM +0200, Johan Hovold wrote: > > On Thu, Oct 23, 2014 at 11:39:50AM +0800, Greg Kroah-Hartman wrote: > > > On Wed, Oct 22, 2014 at 11:31:34PM -0400, Perry Hung wrote: > > > > An official recent Windows driver from FTDI detects counterfeit devices > > > > and reprograms the internal EEPROM containing the USB PID to 0, > > > > effectively > > > > bricking the device. > > > > How sneaky. > > > > Is idProduct the only field that is rewritten? > > According to all of the reports I've read, yes, this is what happens, as > there are api calls to the device that allow anyone to reprogram the > idProduct field. > > > I'm curious about whether the type is still detected "correctly". > > What "type" are you referring to? We try to detect the type during probe (encoded as an enum ftdi_chip_type), which is later used when setting the baud rate (but also affects the packet layout for legacy SIO devices). It's done based on bNumInterfaces and bcdDevice. Johan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: serial: Add "bricked" FTDI device PID
On Thu, Oct 23, 2014 at 09:58:20AM +0200, Johan Hovold wrote: > On Thu, Oct 23, 2014 at 11:39:50AM +0800, Greg Kroah-Hartman wrote: > > On Wed, Oct 22, 2014 at 11:31:34PM -0400, Perry Hung wrote: > > > An official recent Windows driver from FTDI detects counterfeit devices > > > and reprograms the internal EEPROM containing the USB PID to 0, > > > effectively > > > bricking the device. > > How sneaky. > > Is idProduct the only field that is rewritten? According to all of the reports I've read, yes, this is what happens, as there are api calls to the device that allow anyone to reprogram the idProduct field. > I'm curious about whether the type is still detected "correctly". What "type" are you referring to? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: serial: Add "bricked" FTDI device PID
On Thu, Oct 23, 2014 at 11:39:50AM +0800, Greg Kroah-Hartman wrote: > On Wed, Oct 22, 2014 at 11:31:34PM -0400, Perry Hung wrote: > > An official recent Windows driver from FTDI detects counterfeit devices > > and reprograms the internal EEPROM containing the USB PID to 0, effectively > > bricking the device. How sneaky. Is idProduct the only field that is rewritten? I'm curious about whether the type is still detected "correctly". > > Add support for this VID/PID pair to correctly bind the driver on these > > devices. > > > > See: > > http://hackaday.com/2014/10/22/watch-that-windows-update-ftdi-drivers-are-killing-fake-chips/ > > > > Signed-off-by: Perry Hung > > Thanks for doing this, Johan, feel free to add: > > Cc: stable > Acked-by: Greg Kroah-Hartman > > to it when/if you apply it to your tree. Applied. Thanks, Johan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: serial: Add "bricked" FTDI device PID
On Wed, Oct 22, 2014 at 11:31:34PM -0400, Perry Hung wrote: > An official recent Windows driver from FTDI detects counterfeit devices > and reprograms the internal EEPROM containing the USB PID to 0, effectively > bricking the device. > > Add support for this VID/PID pair to correctly bind the driver on these > devices. > > See: > http://hackaday.com/2014/10/22/watch-that-windows-update-ftdi-drivers-are-killing-fake-chips/ > > Signed-off-by: Perry Hung Thanks for doing this, Johan, feel free to add: Cc: stable Acked-by: Greg Kroah-Hartman to it when/if you apply it to your tree. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: serial: Add "bricked" FTDI device PID
An official recent Windows driver from FTDI detects counterfeit devices
and reprograms the internal EEPROM containing the USB PID to 0, effectively
bricking the device.
Add support for this VID/PID pair to correctly bind the driver on these
devices.
See:
http://hackaday.com/2014/10/22/watch-that-windows-update-ftdi-drivers-are-killing-fake-chips/
Signed-off-by: Perry Hung
---
drivers/usb/serial/ftdi_sio.c | 1 +
drivers/usb/serial/ftdi_sio_ids.h | 6 ++
2 files changed, 7 insertions(+)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index dc72b92..41d6642 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -942,6 +942,7 @@ static const struct usb_device_id id_table_combined[] = {
{ USB_DEVICE_INTERFACE_NUMBER(INFINEON_VID, INFINEON_TRIBOARD_PID, 1) },
/* GE Healthcare devices */
{ USB_DEVICE(GE_HEALTHCARE_VID, GE_HEALTHCARE_NEMO_TRACKER_PID) },
+ { USB_DEVICE(FTDI_VID, FTDI_BRICK_PID) },
{ } /* Terminating entry */
};
diff --git a/drivers/usb/serial/ftdi_sio_ids.h
b/drivers/usb/serial/ftdi_sio_ids.h
index 5937b2d..f9c3c49 100644
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -1397,3 +1397,9 @@
*/
#define GE_HEALTHCARE_VID 0x1901
#define GE_HEALTHCARE_NEMO_TRACKER_PID 0x0015
+
+/*
+ * Certain versions of the official Windows FTDI driver reprogrammed
+ * counterfeit FTDI devices to PID 0. Support these devices anyway.
+ */
+#define FTDI_BRICK_PID 0x
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
