That's not how HDCP works. All they can do is make new discs not work on players which they have revoked the keys for. Old discs are unaffected, as is the Bluray player itself. Nothing is bricked, it just wont work with new discs.
I have seen this article:
http://hackaday.com/2014/09/08/unbricking-a-bluray-drive/
Which seems to imply the contrary (disk can revoke the key of the player and the device stops working ...). However, why someone would design a player with the revocation list in a writeable flash is beyond me. Maybe the HDCP/Bluray spec/license requires it.
I have seen this article:
http://hackaday.com/2014/09/08/unbricking-a-bluray-drive/
Which seems to imply the contrary (disk can revoke the key of the player and the device stops working ...).
I have seen this article:
http://hackaday.com/2014/09/08/unbricking-a-bluray-drive/
Which seems to imply the contrary (disk can revoke the key of the player and the device stops working ...).That is AACS, where a disc does not want to reveal its keys to a player it does not trust. a210210200 has been banging on about HDCP, where a player does not want to send restricted video to an untrusted display.
I think he must know his analogy is false. The player just declines to interact with the "revoked" display, it does not brick its EDID to 0×0 pixels like FTDI would have.
Also, the fact that some technical means exists, and licensees have been forced to agree to it, does not mean it is lawful to use. Expect the courts to become involved if the keys to a best-selling display are ever revoked while millions of units are still under warranty.
In any case, it's not the disk that does the bricking. The disk only caries the list of revoked keys. The device itself, if it respects the "standard", reads the list, introspects and compares, then self performs the bricking if "necessary". Quite the difference from FTDI clones that are being directly.... molested.
Also anyone feel like writing an FTDI compatible implementation based on a microcontroller with USB? Could be fun
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.
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.
That's not how HDCP works. All they can do is make new discs not work on players which they have revoked the keys for. Old discs are unaffected, as is the Bluray player itself. Nothing is bricked, it just wont work with new discs.
It's still evil of course, and they have used it in the past with software Bluray players which can be updated easily, but I don't know if they have ever used it with stand alone players or if a firmware update was possible. In any case, you can easily buy HDMI capture cards that let you rip protected content bit-perfect.
I have seen this article:
http://hackaday.com/2014/09/08/unbricking-a-bluray-drive/
Which seems to imply the contrary (disk can revoke the key of the player and the device stops working ...). However, why someone would design a player with the revocation list in a writeable flash is beyond me. Maybe the HDCP/Bluray spec/license requires it.In any case, it's not the disk that does the bricking. The disk only caries the list of revoked keys. The device itself, if it respects the "standard", reads the list, introspects and compares, then self performs the bricking if "necessary". Quite the difference from FTDI clones that are being directly.... molested.
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?
static int __init cp210x_init(void)
793 {
794 int retval;
795
796 retval = usb_serial_register(&cp210x_device);
797 if (retval)
798 return retval; /* Failed to register */
799
800 retval = usb_register(&cp210x_driver);
801 if (retval) {
802 /* Failed to register */
803 usb_serial_deregister(&cp210x_device);
804 return retval;
805 }
806
807 /* Success */
808 printk(KERN_INFO KBUILD_MODNAME ": " DRIVER_VERSION ":"
809 DRIVER_DESC "\n");
810 return 0;
811 }
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.
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?Those Linux tools are not available on FTDI official website.
They only provide 5 years old ftdi_sio.c drivers, which will not work with this fake FTDI PID for reasons I've shown above.
http://www.ftdichip.com/Drivers/VCP.htm
In comparision Silicon Laboratories CP210x USB to RS232 serial adaptor driver which I use as fake FTDIs replacement cp210x.c do not have all this mess with verifying vendor and product for >0 but as simply as it is in its cp210x_init:Code: [Select]static int __init cp210x_init(void)
793 {
794 int retval;
795
796 retval = usb_serial_register(&cp210x_device);
797 if (retval)
798 return retval; /* Failed to register */
799
800 retval = usb_register(&cp210x_driver);
801 if (retval) {
802 /* Failed to register */
803 usb_serial_deregister(&cp210x_device);
804 return retval;
805 }
806
807 /* Success */
808 printk(KERN_INFO KBUILD_MODNAME ": " DRIVER_VERSION ":"
809 DRIVER_DESC "\n");
810 return 0;
811 }
I've made this investigation only because of I was interested in why those chips faked by FTDI stopped working under Linux.
Prosecutors and lawyers also may want to know and have black&white without messing with Linux modules details how they [FTDI] made those faked devices useless under Linux too by this stupid override of product ID (PID) in someones hardware attached to USB -PID needed to attach device to module by its aliased USB vid:pid numbers
.
I have seen this article:
http://hackaday.com/2014/09/08/unbricking-a-bluray-drive/
Which seems to imply the contrary (disk can revoke the key of the player and the device stops working ...).That is AACS, where a disc does not want to reveal its keys to a player it does not trust. a210210200 has been banging on about HDCP, where a player does not want to send restricted video to an untrusted display.
I think he must know his analogy is false. The player just declines to interact with the "revoked" display, it does not brick its EDID to 0×0 pixels like FTDI would have.
Also, the fact that some technical means exists, and licensees have been forced to agree to it, does not mean it is lawful to use. Expect the courts to become involved if the keys to a best-selling display are ever revoked while millions of units are still under warranty.
Again, all of this is irrelevant to the fact that FTDI may have committed a cyber-crime by making unauthorized changes to end-user's equipment. It is also at least possible that there have been other [indirect] damages caused by their actions. For example, if a control system in a plant suddenly stopped working because of the FTDI driver with trojan malware in it, and that plant malfunctioned and killed some people, well, if I were on the jury in that trial I think I would have to go with the plaintiff. Same thing if there was a medical device that suddenly malfunctioned due to FTDI's driver with trojan malware in it-- and somebody died [or were seriously harmed] because of that. It's too early right now to know if any of these things have happened [or may be in the process of happening].
We will have to wait and see how all of this unfolds, but one thing is very clear-- I can no longer design in FTDI chips into my products, because of all of the FUD [Fear, Uncertainty, and Doubt] surrounding these parts-- I don't want my clients, and customers of my client's products worrying over this issue. So far the FTDI devices have worked well for me, and I really hate to change to another product that I have no experience with [the SiLabs CP2104], but unfortunately, FTDI actions on this matter have forced my hand-- I *must* change to a different part, and just make it work. It's going to be interesting to watch all of this unfold over the next few years-- kind of like a slow motion train wreck...
Below is a post that I put up on the FTDI blog site, which is still waiting "moderation" [and I seriously doubt that they will let it post, so I am posting here]:
Below is a post that I put up on the FTDI blog site, which is still waiting "moderation" [and I seriously doubt that they will let it post, so I am posting here]:
Probably the best summation of this whole thing, except for the prison bit. FTDI will not post this comment as they haven't approved any others though. Still a bit of unneeded hubris.
IMHO, What you *should* have done, is write your driver so that it refuses to “talk” to non-FTDI chips...
I think you should re-write your driver to just “not work” with non-FTDI devices...
Sometimes these cables are used for linking critical systems. I hope that your driver does not end up killing someone [medical device or plant operations, etc.-- which can be dangerous if they suddenly stop working].
Again, all of this is irrelevant to the fact that FTDI may have committed a cyber-crime by making unauthorized changes to end-user's equipment.
If the detection is to write the PID, then check it is 0000 and then rewrite it to what it was, is that not also unauthorized modification of a users product without permission, this time twice, or many more times each time it is plugged in?
If it detects a non-FTDI chip and refuses to talk won't that have the same effect to the critical system?
If the detection is to write the PID, then check it is 0000 and then rewrite it to what it was, is that not also unauthorized modification of a users product without permission, this time twice, or many more times each time it is plugged in?
Don't forget that EEPROM wears out...
1. The driver installs for the first time with an empty SN revocation list.
2. A user plugs in an FT232 chip.
3. The serial number of the chip is checked against the revocation list.
4. If the SN in the list, the driver refuses to load, and it is done.
5. If the SN is not in the list. Run the current test to see if you can modify the devices EEPROM (ie detect a clone) AND restore the EEPROM to its original form.
6. If you detected a clone, add it to the revocation list and refuse to load the driver. Display error message.
7. It is not on the list, and it safely passed the clone check, you load the driver.
On any subsequent insertion, the clone would not have the EEPROM check ran, so the EEPROM wear level of the clone would be not be affected.
If it detects a non-FTDI chip and refuses to talk won't that have the same effect to the critical system?The reason it is NOT the same is because the equipment has been CHANGED so that it no longer performs as designed.
So you can't simply connect the gadget to a different computer with the legacy driver and restore functionality.
You can't revert the driver back to the version that worked before.
You may not even be able to connect to a different OS because it doesn't work the same as before the sabotage.
If the detection is to write the PID, then check it is 0000 and then rewrite it to what it was, is that not also unauthorized modification of a users product without permission, this time twice, or many more times each time it is plugged in?
Are you promoting them to modify something that is not theirs?