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
