Bluray not needing any keys, how come?

[Losko]

I bought this Bluray of a recent italian movie "La cittÃ* proibita" and used my everyday PC (debian based) for watching it with mpv.
This disc was published in 2025 and I am aware I did not update my aacs keys in years, so I was going to set up FindVUK for finding the disc keys (and contribute to the database).

Unexpectedly, the disc played fine, and everything is perfectly watchable: main movie, extras, everything.

How come no new keys are needed for this disc?
Are there any Bluray discs using no/generic aacs keys? (I think there aren't)
How can I check which keys mpv is using for this disc?

My software stack:
libbluray-1.3.4
libbdplus-0.2.0
libaacs-0.11.1
mpv-0.35.1 using ffmpeg-5.1.8

Any explanations will be welcome.

[MrPenguin]

I bought this Bluray of a recent italian movie "La cittÃ* proibita" and used my everyday PC (debian based) for watching it with mpv.
This disc was published in 2025 and I am aware I did not update my aacs keys in years, so I was going to set up FindVUK for finding the disc keys (and contribute to the database).

Unexpectedly, the disc played fine, and everything is perfectly watchable: main movie, extras, everything.

How come no new keys are needed for this disc?

Every now and again, someone releases a disk that is not encrypted. Perhaps yours is such a disk? Or (only for an ordinary BD, not a UHD) maybe libaacs has been able to generate the disk's keys automatically?

Can you see any new keys in your $HOME/.cache/aacs directory?

[Losko]

Yes!
Here's what I have:
topolinik@faye:~/.cache/aacs$ vdir
totale 24
drwx------ 2 topolinik 4 3 gen 18.44 mk
drwx------ 3 topolinik 4 6 feb 2021 rdk
drwx------ 2 topolinik 4 3 gen 18.44 vid
drwx------ 2 topolinik 4 3 gen 18.44 vuk
-rw------- 1 topolinik 1 3 gen 18.44 drl
-rw------- 1 topolinik 1 3 gen 18.44 hrl
topolinik@faye:~/.cache/aacs$ vdir mk
totale 12
-rw------- 1 topolinik 1 6 ott 2022 160bc32576d1db575d57f497a2c11f617cfa0107
-rw------- 1 topolinik 1 3 gen 18.44 81e43bcbdc09f42e1bac790cc4fd2b637bb726b5
-rw------- 1 topolinik 1 26 gen 2024 8c7746cf3e437560a6674612b304d309e85d4a5b
topolinik@faye:~/.cache/aacs$ vdir rdk
totale 4
drwx------ 2 topolinik 4 6 feb 2021 a4bd2ace988a4808af4441d2390ab95fc785827f
topolinik@faye:~/.cache/aacs$ vdir vid
totale 8
-rw------- 1 topolinik 1 3 gen 18.44 81e43bcbdc09f42e1bac790cc4fd2b637bb726b5
-rw------- 1 topolinik 1 29 feb 2020 af7a41841aa11f1580fba51c7352ede8bc9552db
topolinik@faye:~/.cache/aacs$ vdir vuk
totale 8
-rw------- 1 topolinik 1 3 gen 18.44 81e43bcbdc09f42e1bac790cc4fd2b637bb726b5
-rw------- 1 topolinik 1 29 feb 2020 af7a41841aa11f1580fba51c7352ede8bc9552db
topolinik@faye:~/.cache/aacs$
...And actually yes, the reported date and time "3 gen 18:44" is the exact time I watched the film.
So, I assume this repeated key "81e43bcbdc09f42e1bac790cc4fd2b637bb726b5" is relevant for this disc, is it?

[spotter]

does your disc even have an AACS directory? I'd hazard to say it's a MOD disc without encryption. Could be wrong, but a thought.

[MrPenguin]

Yes!
Here's what I have:
...
...And actually yes, the reported date and time "3 gen 18:44" is the exact time I watched the film.
So, I assume this repeated key "81e43bcbdc09f42e1bac790cc4fd2b637bb726b5" is relevant for this disc, is it?
The latest KEYDB.cfg file contains an entry for that disk:
0x81E43BCBDC09F42E1BAC790CC4FD2B637BB726B5 = LaCittaProibita (LaCittàProibita) | D | 2025-05-27 | ...
The 0x81E43BCBDC09F42E1BAC790CC4FD2B637BB726B5 value is the SHA-1 hash of your disk's AACS/Unit_Key_RO.inf file, and it identifies your disk in the KEYDB.cfg file.

Your disk is an ordinary BD with MKBv81, and so libaacs has clearly managed to use the device key and host certificate in your old KEYDB.cfg file to compute your disk's MK, VID and VUK, and then write these values into your local AACS cache.