FindVUK tool - get VUK of all Blurays supported by DVDfab applications

[jayper]

Any cryptographic hash supplied over HTTP would have the same issue with verification and would effectively be no better than an error checksum. If you're that concerned about security the two options are either HTTPS (easy) or code/download signing (complicated).

Regardless the current security warnings are just false positives. If you're concerned your downloading is being tampered with my v1.79 FindVUK.exe file has the SHA1 hash:
0e422651601af06cb2e352b2784007f01c74e36a

and aacskeys.exe has the hash:
5533db69cde95ea16cb2e11fbb6959370f0af613
Thanks for these. They match my current downloads... it's a small bit of relief.

[coricopat]

Any cryptographic hash supplied over HTTP would have the same issue with verification and would effectively be no better than an error checksum.


That's why I've said "list SHA512 sums in the main post" (i.e. here on doom9).

There you have https, and that's the original "trust" (on first use) point, where we all were introduced to the upstream author of FindVUK (nalor).
You won't get any better trust chain than that.

[Gabu]

False positive or not, Windows is being VERY annoying and won't let me keep the file at all.

Downloaded an earlier version that works but it wants me to update and when it does, same issue. Windows just won't open, says there's a virus period.

Something is up and Windows is being completely asanine about it. And considering you can't use the program without updating I'd say this is a huge issue that needs to be fixed.

[Toad King]

False positive or not, Windows is being VERY annoying and won't let me keep the file at all.

Downloaded an earlier version that works but it wants me to update and when it does, same issue. Windows just won't open, says there's a virus period.

Something is up and Windows is being completely asanine about it. And considering you can't use the program without updating I'd say this is a huge issue that needs to be fixed.

You can find these lines in the config/FindVUK.ini file:

[FindVUK_AutoUpdate]
AutoUpdateEnabled = 1

Changing the 1 to 0 should stop the auto-updating.

[foxyshadis]

False positive or not, Windows is being VERY annoying and won't let me keep the file at all.

Downloaded an earlier version that works but it wants me to update and when it does, same issue. Windows just won't open, says there's a virus period.

Something is up and Windows is being completely asanine about it. And considering you can't use the program without updating I'd say this is a huge issue that needs to be fixed.

If you regularly use tools that mess with cryptographic properties in the system, you have to be ready to whitelist things (https://support.microsoft.com/en-us/windows/add-an-exclusion-to-windows-security-811816c0-4dfd-af4a-47e4-c301afe13b26) or temporarily disable the protection entirely (I don't recommend that).

FindVUK is regularly reported as a virus, probably by content owners, and then it takes a bit to get it untagged as such again. Even deeper tools like Mimikatz get it worse.

[lamp]

Hello, this is my first time using this utility and I attempted to run this with the trial version of DVDFab 13.0.2.5 and it generated the following

0x2637EE08F12D2647DD22A9663C5733C5B7741C95 = PULP_FICTION (Pulp Fiction) | D | 2022-08-16 | U | 1-0xA7E207B4BA878F397A346F00F1F74B47 ; MKBv77/BEE/UHD/FindVUK 1.79


During that initial run where it generated the key it logged

2025-01-22 21:58:12 # 300966 # [I] findvuk_validate / FVVAL_GetAllDriveDetails / Drive is detected as 'REAL BLURAY' drive
2025-01-22 21:58:12 # 300968 # [I] findvuk_validate / _CheckAndAddDriveToDriveList / Drive is already in the KnownDrivesList
2025-01-22 21:58:12 # 301004 # [I] bluray_aacs / BRAACS_ValidateUnitKeys / M2TS files found >113<
2025-01-22 21:58:12 # 301004 # [I] findvuk_validate / _GenericCallback / M2TS files found >113<
2025-01-22 21:58:12 # 301004 # [I] bluray_aacs / BRAACS_IsFileEncryptedv2 / Check if file >E:\BDMV\STREAM\00174.m2ts< is encrypted (UDF >0<)
2025-01-22 21:58:13 # 301953 # [I] bluray_aacs / BRAACS_ValidateUnitKeys / File >E:\BDMV\STREAM\00174.m2ts< is encrypted! (Size >93235200<)
2025-01-22 21:58:13 # 301955 # [I] bluray_aacs / BRAACS_ValidateUnitKeys / Decrypted first unit of file >E:\BDMV\STREAM\00174.m2ts< with UnitKey >1<
2025-01-22 21:58:13 # 301955 # [I] findvuk_validate / _GenericCallback / Decrypted first unit of file >E:\BDMV\STREAM\00174.m2ts< with UnitKey >1<
2025-01-22 21:58:13 # 301955 # [I] bluray_aacs / BRAACS_ValidateUnitKeys / All UnitKeys are VALID! No need to test other files
2025-01-22 21:58:13 # 301955 # [I] findvuk_validate / _GenericCallback / All UnitKeys are VALID! No need to test other files
2025-01-22 21:58:13 # 301955 # [I] findvuk_validate / _Validate / Validation successful! UnitKeys are valid!!

but I have been unable to reproduce these results. I also attempted using the new KEYDB.cfg with MakeMKV to test and it was unable to decrypt using it as well.

When I try to do `AACSkeys` command I get

2025-01-22 22:20:34 # 22753 # [I] findvuk_validate / FVVAL_GetAllDriveDetails / Drive is detected as 'REAL BLURAY' drive
2025-01-22 22:20:34 # 22754 # [I] findvuk_validate / _CheckAndAddDriveToDriveList / Drive is already in the KnownDrivesList
2025-01-22 22:20:34 # 22755 # [I] bluray_aacs / BRAACS_ValidateUnitKeys / M2TS files found >113<
2025-01-22 22:20:34 # 22755 # [I] findvuk_validate / _GenericCallback / M2TS files found >113<
2025-01-22 22:20:34 # 22755 # [I] bluray_aacs / BRAACS_IsFileEncryptedv2 / Check if file >E:\BDMV\STREAM\00174.m2ts< is encrypted (UDF >0<)
2025-01-22 22:20:34 # 22756 # [I] bluray_aacs / BRAACS_ValidateUnitKeys / File >E:\BDMV\STREAM\00174.m2ts< is encrypted! (Size >93235200<)
2025-01-22 22:20:34 # 22756 # [E] findvuk_validate / _Validate / ERROR! Validation of VUK failed >#BRAACS_ListError<
2025-01-22 22:20:34 # 22756 # [I] findvuk_validate / FVVAL_Mode_FindVUK / Finished with result >-2<


So I believe that the key that was submitted may be incorrect. I tried to generate it again (after a computer restart) and it logs a new unit key that leads to a failure.

2025-01-22 22:18:43 # 66480 # [I] findvuk_validate / FVVAL_GetAllDriveDetails / Drive is detected as 'REAL BLURAY' drive
2025-01-22 22:18:43 # 66482 # [I] findvuk_validate / _CheckAndAddDriveToDriveList / Drive is already in the KnownDrivesList
2025-01-22 22:18:43 # 66525 # [I] bluray_aacs / BRAACS_ValidateUnitKeys / M2TS files found >113<
2025-01-22 22:18:43 # 66525 # [I] findvuk_validate / _GenericCallback / M2TS files found >113<
2025-01-22 22:18:43 # 66526 # [I] bluray_aacs / BRAACS_IsFileEncryptedv2 / Check if file >E:\BDMV\STREAM\00174.m2ts< is encrypted (UDF >0<)
2025-01-22 22:18:43 # 66526 # [I] bluray_aacs / BRAACS_ValidateUnitKeys / File >E:\BDMV\STREAM\00174.m2ts< is encrypted! (Size >93235200<)
2025-01-22 22:18:43 # 66527 # [E] bluray_aacs / BRAACS_DecryptUnit / Decryption failed
2025-01-22 22:18:43 # 66527 # [E] bluray_aacs / _AACS_ValidateUnitKey / DecryptUnit failed >#BRAACS_UnitKeyInvalid<
2025-01-22 22:18:43 # 66527 # [E] bluray_aacs / BRAACS_ValidateUnitKeys / ERROR! Decryption of file >E:\BDMV\STREAM\00174.m2ts< failed with all possible UnitKeys!
... (repeats with many m2ts files)
2025-01-22 22:18:59 # 82539 # [I] bluray_aacs / BRAACS_ValidateUnitKeys / Potentially invalid UnitKey >6985E6265F62D27535D2AAAFFC88EC05<
2025-01-22 22:18:59 # 82539 # [I] findvuk_validate / _GenericCallback / Potentially invalid UnitKey >6985E6265F62D27535D2AAAFFC88EC05<
2025-01-22 22:18:59 # 82539 # [I] bluray_aacs / BRAACS_ValidateUnitKeys / Unfortunately no candidate to get a correct unit key >6985E6265F62D27535D2AAAFFC88EC05<
2025-01-22 22:18:59 # 82539 # [I] findvuk_validate / _GenericCallback / Unfortunately no candidate to get a correct unit key >6985E6265F62D27535D2AAAFFC88EC05<
2025-01-22 22:18:59 # 82539 # [W] bluray_aacs / BRAACS_ValidateUnitKeys / There are still 113 files that cannot be decoded with the provided unit keys!
2025-01-22 22:18:59 # 82539 # [W] findvuk_validate / _GenericCallback / There are still 113 files that cannot be decoded with the provided unit keys!
2025-01-22 22:18:59 # 82540 # [W] findvuk_validate / _Validate / Validation failed - VUK/UnitKeys are INVALID!!!!!!!
2025-01-22 22:18:59 # 82540 # [W] findvuk_validate / _Validate / Please report this in the Doom9 forum and attach the logfile!
2025-01-22 22:18:59 # 82540 # [I] findvuk_validate / FVVAL_Mode_FindVUK / Finished with result >-2<


Is there any way for me to test if the initial key it got was valid?

[SamuriHL]

Findvuk validatedisc option can validate the unit key. But this won't help you with makemkv as that requires a vuk.

Sent from my SM-S928U1 using Tapatalk

[MrPenguin]

Is there any way for me to test if the initial key it got was valid?
When FindVUK uses DVDFab to extract a disk's Unit Keys, it validates those keys before uploading a new KEYDB meta-entry. You will notice your log says
2025-01-22 21:58:13 # 301955 # [I] findvuk_validate / _GenericCallback / All UnitKeys are VALID! No need to test other files
2025-01-22 21:58:13 # 301955 # [I] findvuk_validate / _Validate / Validation successful! UnitKeys are valid!!
So this Unit Key is valid :).

The reason why you are now struggling with AACSkeys is almost certainly because AACS bus encryption is still active. I believe DVDFab will also have extracted the disk's "Read Device Key" (RDK), which is used to reverse bus encryption. Bus encryption must be removed from the media content before you can attempt to decrypt the movie using the Unit Key.

[lamp]

The reason why you are now struggling with AACSkeys is almost certainly because AACS bus encryption is still active. I believe DVDFab will also have extracted the disk's "Read Device Key" (RDK), which is used to reverse bus encryption. Bus encryption must be removed from the media content before you can attempt to decrypt the movie using the Unit Key.

Hmm I see, I ran the VID/RDK program from the forums as well so I do have a copy of those available to me. I was under the impression that libredrive would remove the bus encryption (both my drives have the firmware flashed on them and I can see the step about enabling it in the logs), I wonder if that failed? The logs indicate that was a success but maybe there was an issue somewhere. It seems like the Key was updated by someone else as it now seems to have a full entry in KEYDB.cfg instead of just the Unit Key I showed above so now when I tried I didn't run into any issues accessing the disc.

[johannu]

I tried to find the AACS key from "The Last Men" because it was not available in the file keydb.cfg

Method 1: Using the command "FindVUK AACSkeys=F" (F is the drive letter of my LG drive WH16NS60 1.0) failed.

11:41:15 - --- PART 1 --- GET AACSKEYS DATA ---
-------------------------------------------------------------------------------

11:41:15 - Check >1< with HostCert >0203005CFFFF800001C100003A5907E685E4CBA2A8CD5616665DFAA74421A14F6020D4CFC9847C23107697C39F9D109C8B2D5B93280499661AAE588AD3BF887C48DE144D48226ABC2C7ADAD0030893D1F3F1832B61B8D82D1FAFFF81< Comment >Revoked in MKBv72<
11:41:15 - HostCert >909250D0C7FC2EE0F0383409D896993B723FA965< is known to be revoked on the target drive - is skipped
11:41:15 - Couldn't get MediaKey, VolumeId and VUK from AACSkeys - close now
Waiting 3 secs before quit...

Method 2: I then tried successfully FindVUK (v1.79) and PlayerFab v7.0.5.1 to dump the AACS.

Why does method 1 fail?

Thank you!

[MrPenguin]

Why does method 1 fail?
Because your Host Certificate was revoked in MKBv72, and at some point you have inserted a disk into your drive which uses MKBv72 or above. Unfortunately, your drive remembers the highest MKB version that it has even been asked to read, regardless of which version MKB your current disk uses.

You need to add a new "| HC |" entry into your KEYDB.cfg file which contains a new non-revoked Host Certificate. Have you seen this (https://forum.doom9.org/showthread.php?p=1990091#post1990091)?

[johannu]

@MrPenguin: Thank you very much for your hint!

Basically the FindVUK-command to find the AACS key of my BD discs works very well now with new new given Host Certificate. Anyway I have some issues with two of my BD discs.

I get this error with this BD disc on all my drives (WH16NS60 1.00 LibreDrive enabled, BU40N 1.00 LibreDrive enabled): JOKER_FOLIE_A_DEUX
14:32:34 - Get basic AACS data
-------------------------------------------------------------------------------
14:32:34 - AACS folder on disc is reachable - Validate is possible
14:32:35 - Different VolumeName detected - most likely the disc has been changed... take the new name
14:32:35 - VolumeName >JOKER_FOLIE_A_DEUX<
14:32:35 - DiscId >AA704C4B1A154F305153A47651F282FDB13F9BA2< (2024-10-16)
14:32:35 - DiscType >BD<
14:32:35 - MKB Revision >68<
14:32:35 - Disc-BusEncEnabled >1<
14:32:35 - Drve-BusEncCapable >1<
14:32:35 - ==> Bus Encryption active!
14:32:35 - UnitKeyCount >1<
14:32:35 - >>> UnitKeyENC (1) >E78D506D86980DF35649727ED3C399C2<
14:32:35 - UnitKeys recalculated with VUK:
14:32:35 - UnitKeyCount >1<
14:32:35 - >>> UnitKeyDEC (1) >96D5CBF744EEAC3E04791A0A05FDEAEA<
-------------------------------------------------------------------------------
14:32:35 - BusEncryption enabled => either ReadDataKey or disabling of BusEncryption required
-------------------------------------------------------------------------------
14:32:35 - Try to read ReadDataKey from RDK cache
14:32:35 - RDK not found in cache! Cannot validate disc!
14:32:35 - BusEncryption could not be defeated! Stop now.

Any ideas?

UHD disc: UHD_JW4
FindVUK does not work! It stops working after PART 1 --- GET AACSKEYS DATA

Any ideas?

I also wanted to make a 1:1 copy (ISO file with all protetctions included) of one my BD discs. I therefore used Xreveal and makemkv with ImgBurn. I then burned this ISO file to disc and then wanted to find the AACS key using FindVUK again.
I got this error:
12:30:26 - AACSkeys could not get data with host certificate >4B7AEF00859AF7F8E88AE97418D862FBE404571A< - #BRAKEYS_AacsKeysError<
12:30:26 - Couldn't get MediaKey, VolumeId and VUK from AACSkeys - close now

Any ideas?

And interestingly non of these burned BD disc does work in my TV Blu-ray player.

Thank you very much?

[MrPenguin]

14:32:35 - BusEncryption enabled => either ReadDataKey or disabling of BusEncryption required
-------------------------------------------------------------------------------
14:32:35 - Try to read ReadDataKey from RDK cache
14:32:35 - RDK not found in cache! Cannot validate disc!
14:32:35 - BusEncryption could not be defeated! Stop now.

Any ideas?

Yes, you need to defeat bus encryption. So either you need to discover the Read Device Key (RDK) for your drive/disk and add it to the local AACS cache, or you need to activate LibreDrive - probably by setting this value in FindVUK.ini:
Disable_Bus_Encryption_Cmd = "C:\Program Files (x86)\MakeMKV\makemkvcon.exe" info dev:$DRIVE$
Assuming this is where you have installed MakeMKV, of course.

I also wanted to make a 1:1 copy (ISO file with all protections included) of one my BD discs. I therefore used Xreveal and makemkv with ImgBurn.

Not even MakeMKV can make a 1:1 copy of a BluRay disk, which is why its "back-up" feature also creates discatt.dat or discattd.dat files. AFAIK Xreveal only understands AACS, and does not attempt to break any BluRay protections.

You probably just want to use MakeMKV's "back-up" feature with ImgBurn. I don't see why you would need Xreveal here.

[coricopat]

I also wanted to make a 1:1 copy (ISO file with all protetctions included) of one my BD discs.

Under Linux you can e.g. use dd for such task, but for the resulting UDF image (BDs don't use ISO ;-) ) to be useful, you still need to defeat bus encryption (if that is used).
Such image would contain all the regular encryption methods (except bus encryption, if you managed to circumvent it - which, AFAIU, is however anyway not really on the medium, so it would be more or less the best raw copy you can get).

[johannu]

@MrPenguin: Thank you very much, the command for defeating bus encryption works flawless...

But now my LG BU40N has revoked this (https://forum.doom9.org/showthread.php?p=1990091#post1990091) Host Certificate, when I analysed a BD disc using MKBv72... unbelievable... the result is, that I can't use this drive anymore to find AACS keys.

It seems, that - as you already said - this drive remembers the highest MKB version that it has even been asked to read. Where does this information be stored in the drive and can it be deleted? Or is there a new non revoked Host Certificate available?

Thank you!

[MrPenguin]

It seems, that - as you already said - this drive remembers the highest MKB version that it has even been asked to read. Where does this information be stored in the drive and can it be deleted? Or is there a new non revoked Host Certificate available?
The revocation lists are stored in flash memory within the drive, and you'd probably need to be an Electronics Whizz-kid with a soldering iron to do anything about them :(.

Do you have any other drives, apart from your BU40N?

I believe your link contains the latest publicly known AACSv1 host certificate, which AFAIK was revoked by MKBv76. There are (unfortunately!) no publicly known AACSv2 host certificates. However, you might want to consider reading the rest of the messages in that thread for advice about AACSv1.

[johannu]

Finding The Revocation List (https://hacks.esar.org.uk/un-bricking-a-blu-ray-drive/)... very interesting...

Yes, I also own a WH16NS60 that is not affected from revoked Host Certificate. As long makemkv works with my BU40N it's not a very huge problem that it has revoked known Host Certificates.

[MrPenguin]

Yes, I also own a WH16NS60 that is not affected from revoked Host Certificate. As long makemkv works with my BU40N it's not a very huge problem that it has revoked known Host Certificates.
Before I discovered MakeMKV, my solution to this problem was to buy a brand new drive specifically for those MKB versions that wouldn't revoke my Host Certificates. This did at least allow me to continue playing my existing BDs while I was waiting for the next Host Certificate to appear. However, it's obviously not a viable strategy for UHD disks for which we don't have any Host Certificates in the first place.

[SamuriHL]

Under Linux you can e.g. use dd for such task, but for the resulting UDF image (BDs don't use ISO ;-) ) to be useful, you still need to defeat bus encryption (if that is used).
Such image would contain all the regular encryption methods (except bus encryption, if you managed to circumvent it - which, AFAIU, is however anyway not really on the medium, so it would be more or less the best raw copy you can get).

This isn't accurate. At least not fully. One of the things that will NOT be in that image is the Volume unique IDentifier (VID). So unless you already know the VID or the unit keys are already available for your disc in the keydb, the UDF image is NOT complete enough to be decrypted. This is why MakeMKV creates a discatt.dat file which contains the VID when it does a backup. The VID is in a protected part of the disc and has no place to be stored in an image.

[coricopat]

This isn't accurate. At least not fully. One of the things that will NOT be in that image is the Volume unique IDentifier (VID).

Well I've assumed that all key material would of course be gathered via some of the usual means. :-)

I wonder whether there's any FLOSS way to dump the regions outside of the regular image.

[MrPenguin]

I wonder whether there's any FLOSS way to dump the regions outside of the regular image.
Sure, it's called "write your own drive firmware" ;).

[SamuriHL]

Well I've assumed that all key material would of course be gathered via some of the usual means. :-)

I wonder whether there's any FLOSS way to dump the regions outside of the regular image.

If you have a valid AACS 2.x host certificate and device key, sure. ;)

Other than that, no. Supposedly Libredrive was going to be made open source at some point but that hasn't happened.

[coricopat]

Do these region contain anything other than the VID?

But anyway, I'd still argue that, if one has (at least) the unit keys, the raw image of the UDF (with bus encryption circumvented) can be considered complete.

[SamuriHL]

Yea, there's a few things in the protected parts of the disc. It's laid out in the AACS specs.

I wasn't arguing against being able to use an image. I create protected images with bus encryption disabled all the time. I was simply correcting the "you have everything you need with an image" part because UNLESS you have the unit keys, which will have to be derived ultimately from an actual disc by someone, the image is not everything you need. What I mean is this, and this is relevant to FindVUK in a tangential way...

If no one has scanned the actual disc with something like FindVUK, DVDFab, MakeMKV, then the unit keys can't be found. This means that if you do the following:

1) Disable/Circumvent bus encryption
2) Create ISO image with your favorite image creation tool
3) Try to use the image mounted in Daemon Tools with FindVUK (or alternatively open said image with DVDFab), it will NOT be decrypted UNTIL someone opens FindVUK or DVDFab with the actual disc first

That is the reason I point this out. Because we are in the FindVUK thread where this is quite relevant. Someone thinking they can make an image first without scanning the disc with DVDFab, either directly or through FindVUK, won't be able to decrypt it if the unit keys aren't already known.

[Toad King]

One of the disc entries in the keydb is incorrect but submitting a correct version doesn't seem to fix it. Is it possible to reset this one so I can upload a correct version?

0xA6F5AC52B2EDC7BA254CAD6D491799EEC1EADC03 = BAD_BOYS_FOR_LIFE (Bad Boys for Life - 4K Ultra HD)

[SamuriHL]

Try using the ValidateDisc option. It should allow the entry to be corrected in theory.

[Toad King]

Try using the ValidateDisc option. It should allow the entry to be corrected in theory.

I put in the correct keys and did that and it validates but the wrong keys are still in the download.

[SamuriHL]

Odd. Nalor will have to chime in then.

Sent from my SM-S938U1 using Tapatalk

[MrPenguin]

I put in the correct keys and did that and it validates but the wrong keys are still in the download.
This disk's entry in KEYDB already appears to be a validated "meta-entry", which suggests that its Unit Key has been proved to work. Does this mean you were successful in updating it?

[Toad King]

This disk's entry in KEYDB already appears to be a validated "meta-entry", which suggests that its Unit Key has been proved to work. Does this mean you were successful in updating it?

The "validated" entry in the keydb is incorrect and does not work. I'm trying to update it to the correct keys.

[MrPenguin]

The "validated" entry in the keydb is incorrect and does not work. I'm trying to update it to the correct keys.
OK, that's weird because I though FindVUK 1.79 wouldn't do that...

[mick0]

The "validated" entry in the keydb is incorrect and does not work. I'm trying to update it to the correct keys.

FWIW the current entry for this disc has been mark both "validated" and "unknown" status in the database.
<?xml version="1.0" encoding="UTF-8"?>
<Bluray>
<FileType>BlurayMetaXML</FileType>
<DiscId Date="2020.02.12">A6F5AC52B2EDC7BA254CAD6D491799EEC1EADC03</DiscId>
<DiscType>UHD</DiscType>
<VolumeId/>
<MediaKey/>
<VolumeUniqueKey/>
<Validated>1</Validated>
<VolumeLabel>BAD_BOYS_FOR_LIFE</VolumeLabel>
<BDplus>0</BDplus>
<BusEncryptionEnabled>1</BusEncryptionEnabled>
<MKBrev>68</MKBrev>
<MainPlaylist/>
<UnitKeys>
<UnitKey Nr="1" Status="unknown">F81FFC84B05A73FEE1AF02E2403D3762</UnitKey>
</UnitKeys>
<EncryptedValues>
<UnitKeysENC>
<UnitKey Nr="1">4831785627C690A0C350C93D2F569AA8</UnitKey>
</UnitKeysENC>
</EncryptedValues>
<MetaTitles>
<MetaTitle Language="eng">Bad Boys for Life - 4K Ultra HD</MetaTitle>
</MetaTitles>
<Hashes>
<Hash Type="MD5" File="MKB_RO.inf" Size="5242880">02FFEE0285F49144CBE8D5388425DB8E</Hash>
<Hash Type="MD5" File="Unit_Key_RO.inf" Size="65536">17D66594B45B5C4C43FFB0293788E2D3</Hash>
</Hashes>
<Application>FindVUK 1.79</Application>
<VolumeSize>58874855424</VolumeSize>
</Bluray>


There is also another upload for this disc that has been marked fully validated. I suppose these are the correct keys for this title?
<?xml version="1.0" encoding="UTF-8"?>
<Bluray>
<FileType>BlurayMetaXML</FileType>
<DiscId Date="2020.02.12">A6F5AC52B2EDC7BA254CAD6D491799EEC1EADC03</DiscId>
<DiscType>UHD</DiscType>
<VolumeId>A7BB091D19F7C0B3A1880CC4BDE007BE</VolumeId>
<MediaKey>864BFC8833D4A106DE6ACD240AEB9CF8</MediaKey>
<VolumeUniqueKey>C2B9CEAC8512D8C9E00912D89FBC51EC</VolumeUniqueKey>
<Validated>1</Validated>
<VolumeLabel>BAD_BOYS_FOR_LIFE</VolumeLabel>
<BDplus>0</BDplus>
<BusEncryptionEnabled>1</BusEncryptionEnabled>
<MKBrev>68</MKBrev>
<MainPlaylist/>
<UnitKeys>
<UnitKey Nr="1" Status="valid">452519DA5B47634BE7D925E06B91F64F</UnitKey>
</UnitKeys>
<EncryptedValues>
<UnitKeysENC>
<UnitKey Nr="1">4831785627C690A0C350C93D2F569AA8</UnitKey>
</UnitKeysENC>
</EncryptedValues>
<MetaTitles>
<MetaTitle Language="eng">Bad Boys for Life - 4K Ultra HD</MetaTitle>
</MetaTitles>
<Hashes>
<Hash Type="MD5" File="MKB_RO.inf" Size="5242880">02FFEE0285F49144CBE8D5388425DB8E</Hash>
<Hash Type="MD5" File="Unit_Key_RO.inf" Size="65536">17D66594B45B5C4C43FFB0293788E2D3</Hash>
</Hashes>
<Application>FindVUK 1.79</Application>
<VolumeSize>58874855424</VolumeSize>
</Bluray>

[TTide]

There is also another upload for this disc that has been marked fully validated. I suppose these are the correct keys for this title?


I thought AACSv2 Discs couldn't be watched on free software players.

https://forum.doom9.org/showthread.php?p=1997540#post1997540

[SamuriHL]

I thought AACSv2 Discs couldn't be watched on free software players.

https://forum.doom9.org/showthread.php?p=1997540#post1997540

Sure they can. They just need aacslib and a keydb entry. What we don't have is a processing/device key to decrypt the mediakey. But if you have the unit keys, any free player that supports the keydb can play it. If a processing/device key ever becomes available (unlikely but you never know) then the aacslib would in theory be able to do the whole decryption. Yes, there's host certs and all that to contend with but with LibreDrive, that could be bypassed.

[Toad King]

FWIW the current entry for this disc has been mark both "validated" and "unknown" status in the database.
<?xml version="1.0" encoding="UTF-8"?>
<Bluray>
<FileType>BlurayMetaXML</FileType>
<DiscId Date="2020.02.12">A6F5AC52B2EDC7BA254CAD6D491799EEC1EADC03</DiscId>
<DiscType>UHD</DiscType>
<VolumeId/>
<MediaKey/>
<VolumeUniqueKey/>
<Validated>1</Validated>
<VolumeLabel>BAD_BOYS_FOR_LIFE</VolumeLabel>
<BDplus>0</BDplus>
<BusEncryptionEnabled>1</BusEncryptionEnabled>
<MKBrev>68</MKBrev>
<MainPlaylist/>
<UnitKeys>
<UnitKey Nr="1" Status="unknown">F81FFC84B05A73FEE1AF02E2403D3762</UnitKey>
</UnitKeys>
<EncryptedValues>
<UnitKeysENC>
<UnitKey Nr="1">4831785627C690A0C350C93D2F569AA8</UnitKey>
</UnitKeysENC>
</EncryptedValues>
<MetaTitles>
<MetaTitle Language="eng">Bad Boys for Life - 4K Ultra HD</MetaTitle>
</MetaTitles>
<Hashes>
<Hash Type="MD5" File="MKB_RO.inf" Size="5242880">02FFEE0285F49144CBE8D5388425DB8E</Hash>
<Hash Type="MD5" File="Unit_Key_RO.inf" Size="65536">17D66594B45B5C4C43FFB0293788E2D3</Hash>
</Hashes>
<Application>FindVUK 1.79</Application>
<VolumeSize>58874855424</VolumeSize>
</Bluray>


There is also another upload for this disc that has been marked fully validated. I suppose these are the correct keys for this title?
<?xml version="1.0" encoding="UTF-8"?>
<Bluray>
<FileType>BlurayMetaXML</FileType>
<DiscId Date="2020.02.12">A6F5AC52B2EDC7BA254CAD6D491799EEC1EADC03</DiscId>
<DiscType>UHD</DiscType>
<VolumeId>A7BB091D19F7C0B3A1880CC4BDE007BE</VolumeId>
<MediaKey>864BFC8833D4A106DE6ACD240AEB9CF8</MediaKey>
<VolumeUniqueKey>C2B9CEAC8512D8C9E00912D89FBC51EC</VolumeUniqueKey>
<Validated>1</Validated>
<VolumeLabel>BAD_BOYS_FOR_LIFE</VolumeLabel>
<BDplus>0</BDplus>
<BusEncryptionEnabled>1</BusEncryptionEnabled>
<MKBrev>68</MKBrev>
<MainPlaylist/>
<UnitKeys>
<UnitKey Nr="1" Status="valid">452519DA5B47634BE7D925E06B91F64F</UnitKey>
</UnitKeys>
<EncryptedValues>
<UnitKeysENC>
<UnitKey Nr="1">4831785627C690A0C350C93D2F569AA8</UnitKey>
</UnitKeysENC>
</EncryptedValues>
<MetaTitles>
<MetaTitle Language="eng">Bad Boys for Life - 4K Ultra HD</MetaTitle>
</MetaTitles>
<Hashes>
<Hash Type="MD5" File="MKB_RO.inf" Size="5242880">02FFEE0285F49144CBE8D5388425DB8E</Hash>
<Hash Type="MD5" File="Unit_Key_RO.inf" Size="65536">17D66594B45B5C4C43FFB0293788E2D3</Hash>
</Hashes>
<Application>FindVUK 1.79</Application>
<VolumeSize>58874855424</VolumeSize>
</Bluray>


Yes, that second entry has the correct keys. I guess the generated keydb file is only grabbing that first entry and not the second one for some reason. (How can a key be validated if the unit key status is unknown?)

Also how are you getting these individual entries for the DB from? I assume there's some other API for getting this extra data.

[mick0]

Also how are you getting these individual entries for the DB from? I assume there's some other API for getting this extra data.

It's all public information, see the "Online DB - BlurayMeta Archive" link in this post (https://forum.doom9.org/showthread.php?p=1860873#post1860873).

[MrPenguin]

If a processing/device key ever becomes available (unlikely but you never know) then the aacslib would in theory be able to do the whole decryption.
To be fair, any AACSv2 processing/device key would be revoked as soon as it became publicly available. So I seriously doubt this will happen unless the key could be replaced quickly and easily.

Personally, I'd quite like an AACSv2 host certificate because that would allow me to disable bus encryption on my Pioneer XD08U drive that doesn't support LibreDrive.

[SamuriHL]

I agree that it's highly unlikely we'll ever see a device/processing key for aacs 2.x.

That's true, a valid host cert would negate bus encryption and would make findvuk easier, as well. Maybe that'd allow dvdfab to finally support pio drives, as well.

Sent from my SM-S938U1 using Tapatalk

[nalor]

OK, that's weird because I though FindVUK 1.79 wouldn't do that...

This is definitely strange - need to check that.

[coricopat]

@nalor ...maybe if you're at it and have some time, perhaps you could check/consider the following:

a) On some mediums, when using FindVUK from Linux via Wine, the VolumeLabel field contains a traling 0x1F, which causes the submission to fail.
Perhaps FindVUK could strip that (or any control characters) off


b) The same medium would give different values for VolumeSize on at least Windows 10 and Linux (via wine).
I've checked it a while ago and it seemed Linux' value was more correct and if I remember correctly, Windows 11 even calculates it now how Linux does (but not sure about that9.

Not sure how you determine the value,... maybe one could instead sum up all the file sizes?
That should be portable, but OTOH require to read all file sizes (which may take a while)... and also invalidate all current entries.

So... no idea what one should do, if anything at all.

Cheers.

[nalor]

@nalor ...maybe if you're at it and have some time, perhaps you could check/consider the following:

a) On some mediums, when using FindVUK from Linux via Wine, the VolumeLabel field contains a traling 0x1F, which causes the submission to fail.
Perhaps FindVUK could strip that (or any control characters) off


b) The same medium would give different values for VolumeSize on at least Windows 10 and Linux (via wine).
I've checked it a while ago and it seemed Linux' value was more correct and if I remember correctly, Windows 11 even calculates it now how Linux does (but not sure about that9.

Not sure how you determine the value,... maybe one could instead sum up all the file sizes?
That should be portable, but OTOH require to read all file sizes (which may take a while)... and also invalidate all current entries.

So... no idea what one should do, if anything at all.

Cheers.

(a) is (hopefully) already fixed in my local code for a long time, just missed to create a new release.

(b) sum of filesizes would not be right as e.g. on 3D discs sectors are referenced by multiple files so the sum of all files is greater than the actual disc.
Currently I'm using a windows api: GetDiskFreeSpaceEx


And in general I think I found the bug with the validate=true although there are no validated unit keys - I missed to return the correct result in case validation failed for a bus encrypted disc - very likely due to a wrong RDK.

Try to release a fixed 1.80 tomorrow.

[SamuriHL]

Any chance while you're in there you can add a switch to validatedisc to process one disc only and then exit? It would help me immensely but understand if you don't want that or don't have time. Thanks!

[Toad King]

(b) sum of filesizes would not be right as e.g. on 3D discs sectors are referenced by multiple files so the sum of all files is greater than the actual disc.
Currently I'm using a windows api: GetDiskFreeSpaceEx

Not sure how Windows works obviously but in Wine that API calls statfs/fstatfs (https://linux.die.net/man/2/statfs) under the hood which looks correct.

Looking at the docs for GetDiscFreeSpaceEx (https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getdiskfreespaceexw) it looks like it can return a smaller value based on whether the whole disc is "available to the user" or not. It might be more accurate to use something like IOCTL_DISK_GET_LENGTH_INFO (https://learn.microsoft.com/en-us/windows/win32/api/winioctl/ni-winioctl-ioctl_disk_get_length_info) or IOCTL_DISK_GET_DRIVE_GEOMETRY_EX (https://learn.microsoft.com/en-us/windows/win32/api/winioctl/ni-winioctl-ioctl_disk_get_drive_geometry_ex), although it looks like some of those might not be implemented in Wine so it may need a fallback.

[coricopat]

See my earlier post (https://forum.doom9.org/showthread.php?p=2009867#post2009867) here, which explains - if I'm correct - how Windows (10 only?) and Linux count the UDF size differently.

Windows seems to include the actual "data area" (PSPACE) + all leading parts of the "partitions"... Linux only take the PSPACE.

[nalor]

Published FindVUK 1.81 (I noticed I already created an 1.80 back in september 2024 which only fixes the volumename problem in wine).

[nalor]

Any chance while you're in there you can add a switch to validatedisc to process one disc only and then exit? It would help me immensely but understand if you don't want that or don't have time. Thanks!

Have you tried the ini-switch "ExitAfterprocessing" ? I'd expect that it already does what you need... in case it does not, let me know and I'll fix it.

[Toad King]

Published FindVUK 1.81 (I noticed I already created an 1.80 back in september 2024 which only fixes the volumename problem in wine).

It seems to work. (it errors out and doesn't send anything when validating on the incorrect info.) I think the DB entry for 0xA6F5AC52B2EDC7BA254CAD6D491799EEC1EADC03 still has to be fixed manually since I still can't upload the correct keys to it still.

Also, is it possible to implement the changes from this post in a future release? It'll help auto-ejecting work under Wine: https://forum.doom9.org/showthread.php?p=2009416#post2009416

[SamuriHL]

Have you tried the ini-switch "ExitAfterprocessing" ? I'd expect that it already does what you need... in case it does not, let me know and I'll fix it.

I have not as I didn't know about that one. I'll give it a try thanks!

[nalor]

I put in the correct keys and did that and it validates but the wrong keys are still in the download.

Please try again - I've changed the entry in the db to "validated=0" - so I think a new validation should result in an update.

There are 11 more entries that look strange .. will check tomorrow in detail.

[SamuriHL]

Have you tried the ini-switch "ExitAfterprocessing" ? I'd expect that it already does what you need... in case it does not, let me know and I'll fix it.

I have not as I didn't know about that one. I'll give it a try thanks!

Looks like I already had that set and it doesn't seem to take affect for validatedisc unless I'm doing something wrong. (So apparently I did know about it last time I updated the ini file LOL)

EDIT: This is what happens with that set in the ini after it ejects the disc (which is also set to not eject):


18:50:55 - AACS folder on disc in drive >g< is not accessible - keep waiting for disc to appear (abort with ESC)