Hello!
To make things easier I simply zipped the AACS folder of the disc an
uploaded it to tinyupload:
http://s000.tinyupload.com/index.php?file_id=43898648543121342749
MKB_RO.inf and MKB_RW.inf are completely empty - both are 1024kb in size
contain only NULL bytes.
But I noticed that Unit_Key_RO.inf is not completely empty.. within the
first 48 bytes there are 6 bytes <> NULL (this is the reason why your
hash is different from the one I got... don't know why I didn't notice
this 6 bytes until now... )
*00 00 00 20* 00 00 00 00 00 00 00 00 00 00 00 00
01 01 00 00 00 01 00 01 00 00 00 00 00 00 00 00
*00 01* 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 20 >> Unit Key Block start address - and at this address we
find the Num_of_CPS_Unit and this is '00 01' >> so basically we'd expect
1 Unit Key - but as all the other bytes in the file are NULL this 1 unit
key if also filled with NULL values... so it's not valid in any way.
Unfortunately I've no idea how this image has been created - it's a BD9
image (only 8GB in size) and it only contains the main movie of the
original disc, so I guess it has been created by some kind of
'shrinking' software (and just to be on the safe side: I only got this
image for research purposes and additionally I've bought the movie in
original... so I can compare the 'eventually-source-original' disc with
the shrinked-image - initially I though the problematic-image is a 1:1
of the original-disc).
The BD9-image is a working 3D blu-ray image that can also be played with
e.g. Nero Blu-ray player (that's the only software player I have) - so
basically I don't think it's completely corrupt... at least this
commercial blu-ray player can play this disc.
The main problem is: in case libbluray is used without libaacs this
image can be played without problems because libbluray doesn't try to
aacs-decode the disc in any way, but when libaacs is available libbluray
notices the 'aacs' directory on the disc and tries to use libaacs to
decode the aacs content - but this is detected as 'corrupt' and playback
is broken in this combination.
When you google for the sha-1 hash
'ec6afe5df8a1325068b95313f82bd72c09d4f963' you'll find the glimpse of
another disc that has (in my personal opinion) also created with the
same shrinking-software so I guess there might be more than this one
image be available in the wild and as this makes 2 of them with the same
sha-1 hash I guess that all of them share the same sha-1 discid >> I
came to the idea to simply check for this discid and return
'AACS_SUCCESS' because the decryption process itself is working without
problems as the videofiles are all already decrypted on the disc.
If someone has a better idea to handle this disc I'm open for all
suggestions - I simply want to achieve that there's no difference
between libbluray-standalone and libbluray+libaacs-combination
Thanks, Roland
On 15.12.2015 12:55, Petri Hintukainen wrote:
On ke, 2015-12-09 at 21:52 +0100, Roland Fischer wrote:
A few discs have an aacs folder with a unit_key_ro.inf file
consisting only of NULL bytes and only unencrypted content in
BDMV/STREAM directory.
Interesting ... Is MKB file empty too ?
Any ideas where such discs come from ? I think AACS specification
requires valid files even with unencrypted discs.
Have you tried if any other player (ex. PowerDVD) can play such discs ?
This case can be detected on their always identical discid value
In case such a disc is deteced return AACS_SUCCESS to allow
playback of disc.
Reason of change: https://github.com/OpenELEC/OpenELEC.tv/pull/4378
---
src/libaacs/aacs.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/libaacs/aacs.c b/src/libaacs/aacs.c
index 1bd8ad5..5de09ac 100644
--- a/src/libaacs/aacs.c
+++ b/src/libaacs/aacs.c
@@ -1067,6 +1067,10 @@ int aacs_open_device(AACS *aacs, const char
*path, const char *configfile_path)
error_code = _calc_title_hash(aacs);
if (error_code != AACS_SUCCESS) {
return error_code;
+ } else if (!memcmp(aacs->disc_id,
"\xEC\x6A\xFE\x5D\xF8\xA1\x32\x50\x68\xB9\x53\x13\xF8\x2B\xD7\x2C\x09
\xD4\xF9\x63", 20)) {
+ /* in case the unit_key_ro.inf contains only NULL byte
values it's SHA1 hash is 'ec6afe5df8a1325068b95313f82bd72c09d4f963'
*/
With 65536 NUL bytes I get 1adc95bebe9eea8c112d40cd04ab7a8d75c4f961.
+ BD_DEBUG(DBG_AACS, "Detected 0-Byte AACS file - no AACS
processing necessary\n");
+ return AACS_SUCCESS;
}
cf = keydbcfg_config_load(configfile_path);
_______________________________________________
libaacs-devel mailing list
libaacs-devel@videolan.org
https://mailman.videolan.org/listinfo/libaacs-devel
_______________________________________________
libaacs-devel mailing list
libaacs-devel@videolan.org
https://mailman.videolan.org/listinfo/libaacs-devel