Czy wolisz polską wersję strony elektroda?
Nie, dziękuję Przekieruj mnie tam@ElektrodaBot What is the situation with the FT232 scandal?
• The “FT232 scandal” (often called “FTDI-gate”) peaked in 2014-2016 when FTDI Windows drivers intentionally disabled counterfeit FT232R USB-to-UART chips – first by rewriting their USB Product-ID to 0x0000 (bricking), later by injecting the text “NON GENUINE DEVICE FOUND!” into the data stream.
• After a global backlash Microsoft withdrew the offending drivers, and FTDI replaced them with non-destructive versions that simply refuse to enumerate with suspected clones.
• Today (2024-2025) no shipping FTDI driver bricks or corrupts devices. Genuine parts work as before; suspected counterfeits just fail to load an FTDI driver and enumerate as “USB Serial Device”.
• The episode remains a case study in supply-chain risk, IP protection and driver ethics; designers now either buy FTDI parts from authorised distributors or switch to alternatives such as Silicon Labs CP210x, WCH CH34x, Prolific PL2303, or MCU-integrated USB.
Timeline & technical mechanism
• Oct 2014 – Windows Update published driver v2.12.00. When the driver spotted a non-genuine FT232R it re-programmed the internal EEPROM:
– PID was set to 0x0000 → device no longer matched any driver, effectively “soft-bricked”.
• Nov 2014 – Community uproar; Microsoft pulled the driver (KB3014802).
• Jan 2016 – Driver v2.12.26 used a softer tactic: leave EEPROM intact but substitute every UART byte with the ASCII string “NON GENUINE DEVICE FOUND!”. Systems relying on binary protocols crashed.
• Feb 2016 – After renewed criticism, FTDI replaced this driver with versions that:
– Identify suspected clones;
– Return error code 10 and do not enumerate (no bricking, no data corruption).
Why FTDI acted
• Counterfeit volumes were high (tens of millions) and visually indistinguishable.
• Support costs: users blamed FTDI for failures actually caused by poor-quality clones.
• Goal: create a deterrent without costly litigation in multiple jurisdictions.
Collateral damage
• End-users who unknowingly bought products with clones lost functionality overnight.
• Manufacturers learned that “good looking” ICs from the grey market can still be fake.
• Linux developers added a patch that can restore PID 0x0000 devices; Windows users could often un-brick with FT_Prog if they had a legacy driver or external programmer.
Current driver behaviour (2024-2025)
• Windows WHQL 2.12.36, 2.13.x, 2.14.x: enumerate only genuine chips (no destructive writes).
• macOS and modern Linux kernels (ftdi_sio) never adopted the bricking logic; they simply fail to bind to clones with PID 0x0000.
• FTDI now embeds cryptographic chip-ID options (e.g., FT231X, FT232H-B) and offers the FTDI Chip-ID utility so OEMs can authenticate devices during manufacturing.
Industry aftermath
• Design diversification: many boards migrated to CP2102/4, CH340E/K, or MCU USB CDC.
• Component sourcing policies tightened – authorised distributors, lot traceability, X-ray & decap on random samples.
• Driver security debate influenced Microsoft’s Windows Update review process; today a vendor cannot silently push a destructive driver through the automatic channel.
• Supply-chain security is now a mainstream design requirement; COTS “clone-proof” parts incorporate unique IDs and optional SHA-256 challenge–response.
• Several ODMs (e.g., Espressif for ESP32-S3) integrate native USB, reducing demand for external bridges.
• Open-source USB stacks (TinyUSB, Zephyr USB) mature – lowering barrier to in-house solutions.
• Counterfeit FT232RLs are still widespread on low-cost modules from online marketplaces (AliExpress, eBay); reported failure rate ~10–30 %.
• Why PID 0x0000 bricks the device
USB enumeration relies on the tuple <Vendor-ID, Product-ID>. Setting PID to 0x0000 means no generic driver will claim the interface; Windows shows “Unknown USB Device (Device Descriptor Request Failed)”.
• EEPROM write was possible because FT232R exposes an I²C-like MTP block writable over USB with no physical protection. Newer FTDI parts can lock this field, preventing unauthorised PID changes.
• Legality: changing user hardware without consent may violate computer-misuse or anti-tamper laws in some regions. No precedent lawsuit reached court, but the risk remains.
• Ethics: balancing IP protection against collective punishment of end-users; consensus within IEEE/ACM ethics boards is that non-destructive refusal is acceptable, destructive modification is not.
• Safety: corrupting serial data can create latent hazards in medical or industrial systems; this was a key argument leading to the 2016 driver’s withdrawal.
• Component purchasing
– Use authorised distributors (Mouser, Digi-Key, Farnell, etc.).
– Audit incoming lots: visual inspection, FT_Prog read-out, functional loop-back test.
• Firmware & driver deployment
– Freeze a qualified driver version in production images; disable automatic driver updates on critical equipment.
– For field upgrades, stage on a test bench with clone-detection logs enabled.
• Design alternatives
– If BOM cost is critical and data rates ≤2 Mbps, CH340E/K or CP2102N-A01 are <$0.60 in volume.
– For high-speed multiprotocol, consider FT232H or Cypress FX2LP.
• Recovery of bricked units
– On Linux load ftdi_sio with PID override or use libftdi + ftdi_eeprom to restore PID 0x6001.
– On Windows, install pre-2014 driver, run FT_Prog, reprogram PID, then re-install current driver.
• Some grey-market “FT232RL” now contain genuine FTDI silicon in a re-marked package (factory surplus). Not all non-authorised parts are fake, but verification is essential.
• Future driver policies could change; always review FTDI release notes before mass-deployment.
• Hardware root-of-trust in commodity interface ICs (e.g., PUF or OTP-signed descriptors).
• Blockchain-based supply-chain provenance for semiconductors.
• User-space libraries that gracefully fall back to CDC-ACM when FTDI driver refuses enumeration.
• Impact of USB4 and native-USB microcontrollers on the discrete bridge market.
The FT232 scandal showed what can happen when anti-counterfeit measures are pushed into device drivers without adequate user protection. After the 2014 “bricking” and 2016 “data corruption” drivers were withdrawn, FTDI adopted non-destructive refusal combined with authentication tools. Present-day drivers no longer harm hardware, but the episode permanently raised awareness of counterfeit risks and prompted many designers to verify their supply chains or migrate to alternative USB-UART solutions.
