I had this AACS key revocation issue pop up recently ("Can't read AACS VID from disc - most likely current AACS host certificate is revoked by your drive"), and I've been doing some reading about it here on the forums to understand it. I figured I'd post a new thread rather than replying to the existing ones in order to avoid resurrecting a several-year-old zombie thread.

From reading this thread (viewtopic.php?f=8&t=17605&p=63537) I think I understand the following:
When the MPAA or AACS people discover a compromised key out in the world, they add it to a data table of such compromised keys that is baked into certain BD discs when they're authored. Then, when said discs are inserted into BD drives, the drive reads the table off the disc and prevents any any application that's using any of the keys included in the table from reading not only that disc, but *ANY* BD disc... essentially bricking the drive for use with BD discs via that application.

That's what I've understood so far. Please correct me if any of that is wrong.

Here's my question:
In order for the above to work, it seems to me that the drive would have to store, internally, the table of compromised AACS keys in memory somewhere. If that's the case, has anybody figured out where the drives store that data? Can that memory be flashed? If it is stored in the drive's firmware, would reinstalling some early version of the drive's firmware (ideally the original v1.00 firmware) remove that table of data and allow the drive to use the old keys again?

(I know that this question is made partially moot by the fact that Mike can change MakeMKV's AACS key with each new version so if a key gets revoked we could just wait until the next version, but in the interim between versions, it would be handy to have a way of un-bricking our drives...)

I'm guessing no one is certain about the answer (or even understood the question), hence no responses. The storage area can't be huge.

A test would be for someone that has a drive with flashable firmware to get a disk with a key revocation, lets it revoke the key in their drive, and see if flashing it with the original firmware overwrites the table. If it does, the drive would become usable without a MakeMKV update; If not, well, they'll have to wait until Mike generates the new key.

Probably would be best to wait until a new version of MakeMKV is ready to cover the new AACS version, to be on the safe side.

The group working with flashing UHD Friendly drives may be the ones in the best position to do the test, since they've accumulated a number of firmware sets.

For those who read this thinking it's about how to get Mike to create a new AACS key....

In your MakeMKV data directory, there should be a file generated that shows the highest AACS version MakeMKV has seen on your machine. The file name will start with MKB_v, followed by the version number, then the name of the disk that had that version of AACS. Examples:

What is the highest numbered file in your MakeMKV data directory? MakeMKV v1.12.2 and 1.12.3 know how to deal with AACS through v65.

If it isn't the newest disk you've had in the drive, what is the newest disk you've inserted? You didn't even need to play it, if it is a revoking version. But it would be important to provide Mike with the MKB file from it.