Hello!
Thanks for your answer! I'm clearly with you - using the disc is has
been really a hackish way ;)
But although I've checked each and every flag in the Unit_Key_RO.inf
file I never noticed this CCI file and also missed the chapter about the
unencrypted content in the specification - so after your hint I read the
specification yesterday evening and thought I'll try to put something
together today, but during the day I noticed the changes from npzacs :)
Thanks a lot for them! It's really awesome how fast those have been coded!
Tried them today and the detection of the unencrypted content is working
like a charm :)
Just found a few small errors in _calc_uks and just send a patch to fix
those last remaining issues. For me everything is working perfectly with
those last changes!
Tried playback of different discs with the compiled library in windows 8.1:
# problematic disc-image BD9 AACS unencrypted
# and 10 different encrypted discs and none of them made a problem :)
Thanks for the great help!
br, Roland
On 12.01.2016 10:42, Petri Hintukainen wrote:
On ke, 2015-12-16 at 21:38 +0100, Roland Fischer wrote:
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.
Yes, those files are invalid. So, in the other files there must be
something that prevents media key calculation.
Interesting point is that also .cci file is not empty.
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.
It is still valid file (and encrypted unit key). If the resulting key
was used to encrypt the stream, it would work just well. But, without
MKB the key can't be decrypted.
So, there must be something in the disc
that indicates keys are not needed.
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
One possible solution could be adding fake VUK entry to config file or
cache. It should do more or less the same thing, but does not require
changing the code when other similar discs are found.
Another would be calculating the keys on demand, but that would require
changing how errors are reported and handled in applications.
using disc id is quite hackish way to handle this. There must be some
other way too. I think the necessary information to handle such discs
is in CPS Unit Usage File(s). [chapter 7.2 in AACS "Blu-ray Disc Pre
-recorded Book"].
_______________________________________________
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
