<div dir="ltr"><a href="https://www.techdirt.com/articles/20141023/15502828928/microsoft-windows-update-completely-kill-devices-that-might-possibly-be-used-piracy.shtml">https://www.techdirt.com/articles/20141023/15502828928/microsoft-windows-update-completely-kill-devices-that-might-possibly-be-used-piracy.shtml</a><div><br></div><div>It looks like FTDI is deliberately bricking chips!</div><div><br></div><div>You can fix it, but you need an FTDI flash program, and need to know the original chip PID.</div><div><br></div><div>Quote from an AC that seems to know what's going on:</div><div><br></div><div><span style="color:rgb(51,51,51);font-family:'Trebuchet MS',Arial,Helvetica,sans-serif;font-size:12px;line-height:17.2368011474609px">There's no doubt they did it on purpose. Someone reverse-engineered the bricking routine from the driver. It</span><em style="color:rgb(51,51,51);font-family:'Trebuchet MS',Arial,Helvetica,sans-serif;font-size:12px;line-height:17.2368011474609px">unconditionally</em><span style="color:rgb(51,51,51);font-family:'Trebuchet MS',Arial,Helvetica,sans-serif;font-size:12px;line-height:17.2368011474609px"> writes 0 to the PID and a matching value to the checksum, but does so in a specific way that fails to write on genuine parts*.</span><br style="color:rgb(51,51,51);font-family:'Trebuchet MS',Arial,Helvetica,sans-serif;font-size:12px;line-height:17.2368011474609px"><br style="color:rgb(51,51,51);font-family:'Trebuchet MS',Arial,Helvetica,sans-serif;font-size:12px;line-height:17.2368011474609px"><span style="color:rgb(51,51,51);font-family:'Trebuchet MS',Arial,Helvetica,sans-serif;font-size:12px;line-height:17.2368011474609px">There's no legitimate purpose for the bricking routine. It's a no-operation on genuine parts. It's not "something useful the driver does which happens to do the wrong thing on non-genuine parts". The only possible explanation for the existence of that routine is to zero the PID on counterfeit or compatible parts**.</span><br style="color:rgb(51,51,51);font-family:'Trebuchet MS',Arial,Helvetica,sans-serif;font-size:12px;line-height:17.2368011474609px"><br style="color:rgb(51,51,51);font-family:'Trebuchet MS',Arial,Helvetica,sans-serif;font-size:12px;line-height:17.2368011474609px"><span style="color:rgb(51,51,51);font-family:'Trebuchet MS',Arial,Helvetica,sans-serif;font-size:12px;line-height:17.2368011474609px">* From what I could understand, the genuine parts can only write to the EEPROM in 32-bit units, sent as a pair of 16-bit units. The bricking code sent only one of the 16-bit units, so the write never happened. The compatible parts write each 16-bit unit as it's received, so the write happened.</span><br style="color:rgb(51,51,51);font-family:'Trebuchet MS',Arial,Helvetica,sans-serif;font-size:12px;line-height:17.2368011474609px"><br style="color:rgb(51,51,51);font-family:'Trebuchet MS',Arial,Helvetica,sans-serif;font-size:12px;line-height:17.2368011474609px"><span style="color:rgb(51,51,51);font-family:'Trebuchet MS',Arial,Helvetica,sans-serif;font-size:12px;line-height:17.2368011474609px">** My guess as to why they only erased the PID, and not the VID: due to word alignment, if they erased the VID it would happen even on genuine parts. Luckly, this makes it easier to recover: if the VID is FTDI and the PID is zero, it's a part which used to have a PID of 6001 but was bricked. The Linux driver has been patched to recognize a bricked part as a valid FTDI part.</span><br></div><div><br></div><div>Sincerely,<br>Arthur Moore<br>(256) 277-1001<br>
</div></div>