Quote:
Originally Posted by Exiton
So will this make a stand alone app to retrieve keys? Or still work with a software player and get the key from an error memory dump?
|
I'm going to take a shot at answering this. I'm nowhere near to fully understanding the whole system, so take this for what it's worth - and wait for someone to correct me if I'm wrong.
I think the answer is yes, this could make a stand alone app. I think there's enough here for someone to make a software player.
I think the app would stop working if and when the AACSLA changes the MKB.
Obviously, the app would have to read data off the disk. I'm assuming that's possible IOW, I'm assuming that there is nothing in the firmware of the drives being sold that reads an HD or BD disk and says to itself "I'm not authorized to tell the PC what's in the MKB of this disk" or that if there is such a thing that the drive firmware could be cracked/hacked to allow the MKB to be read. I've read the AACS specs about Drive Revocation Lists (drive=the optical drive) and Host Revocation Lists (host=the software player) and I'm not fully certain of the implications of those lists.
I'm also assuming that the Processing Key we have now would not equal a new Processing Key calculated from a future disk released with a new MKB. After a drive revocation and new MKB, someone would again have to find the new Processing Key/Device Key. (It would be stupid to design AACS so that a revoked device key could not calculate the Processing key from the new MKB, but if it could calculate it, the answer would be the same as it would have gotten by calculating the processing key from an older MKB with the revoked device key. Of course, I can't really say with any authority how stupid/smart the AACS system might be.)