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

[Toad King]

Been validating my library and I ran into a potentially invalid entry:

2024-10-31 20:25:19 # 6876 # [I] findvuk_showresult / _KeyDB_CheckIfWrite / Keys in Keyfile: 157564 keys - KeyFile: C:\Users\XXX\AppData\Roaming\aacs\KEYDB.cfg
2024-10-31 20:25:19 # 6876 # [I] findvuk_showresult / _KeyDB_CheckIfWrite / Disc with ID >C3B7077E9480ACE42F6B38A8717322018FCDAC7B< is already in file - need to compare the details
2024-10-31 20:25:19 # 6877 # [I] findvuk_showresult / _KeyDB_CheckIfWrite / VUK different - KeyDbVUK >5A0766CA9BEB6291BFE2BB021A3AF8F5< NewVUK >6FF3A42C467FBB07D0712A3DDAA4BC36<
2024-10-31 20:25:19 # 6877 # [I] findvuk_showresult / _KeyDB_CheckIfWrite / DATE different - KeyDbDATE >2023-08-24< NewDATE >2023-05-04<
2024-10-31 20:25:19 # 6877 # [I] findvuk_showresult / _KeyDB_CheckIfWrite / VOLUMEID different - KeyDbVolumeId >2B68A3481671A871C8865FA7FEE7990B< NewVolumeId >6D7E8A629B38E49557A3055285730AC0<
2024-10-31 20:25:19 # 6877 # [I] findvuk_showresult / _KeyDB_CheckIfWrite / COMMENT different - KeyDbCOMMENT >(LEGACY) (NOTVALIDATED) (BD)< NewCOMMENT >MKBv81/FindVUK 1.79<
2024-10-31 20:25:19 # 6877 # [I] findvuk_showresult / _KeyDB_CheckIfWrite / UNITKEYS different - KeyDbUnitKeys >1-0x9878A83C6A42116BFCB491716B127419< NewUnitKeys >1-0x75F59CE2FDEDEB9A9432F0B89F496716<
2024-10-31 20:25:19 # 6877 # [I] findvuk_showresult / _KeyDB_CheckIfWrite / KEYDB: entry for this disc already present in keydb-file
2024-10-31 20:25:19 # 6878 # [I] findvuk_showresult / _KeyDB_CheckIfWrite /  >> but VUK is NOT identical!!
2024-10-31 20:25:19 # 6878 # [I] findvuk_showresult / _KeyDB_CheckIfWrite /  >> The new VUK has been successfully validated, please report in the forum (http://forum.doom9.org/showthread.php?t=171298) that the old entry is definitely wrong!

[Toad King]

Sorry to double-post but I also have a suggestion for the next version of FindVUK for better Linux/Wine support: When ejecting a disc the program currently checks the drive type (via GetDriveType) and does different eject behavior between "CD-ROM" and "removable" types. For removable types it does The following IOCTL's in order:

FSCTL_LOCK_VOLUME
FSCTL_DISMOUNT_VOLUME
IOCTL_STORAGE_MEDIA_REMOVAL
IOCTL_STORAGE_EJECT_MEDIA

However, for CD-ROM types it only does IOCTL_STORAGE_EJECT_MEDIA. In Wine at least the FSCTL_DISMOUNT_VOLUME command is also needed for ejecting to happen properly. (FSCTL_LOCK_VOLUME can be called too but it's just a stub in Wine.) IOCTL_STORAGE_MEDIA_REMOVAL would also be required for drives with door locks (it calls the CDROM_LOCKDOOR Linux ioctl under the hood), but that command throws an error for me so it might make sense to just call that IOCTL without checking if it succeeds or not.

If this can be fixed it would make ValidateDisc mode work as expected on Linux instead of erroring out after every disc.



EDIT: There also appears to be a bug in the FindVUK program/website: If a UHD disc has a verified UK only and I try to reverify with VID/MK/VUK, it says the new VUK validates and uploads but the full entry with VID/MK/VUK doesn't get put in the full KEYDB file downloaded from the site. I have to do a manual full synchronize with my local KEYDB file before it gets uploaded and starts appearing in the download version.

[nalor]

Originally Posted by Toad King

Sorry to double-post but I also have a suggestion for the next version of FindVUK for better Linux/Wine support: When ejecting a disc the program currently checks the drive type (via GetDriveType) and does different eject behavior between "CD-ROM" and "removable" types. For removable types it does The following IOCTL's in order:

FSCTL_LOCK_VOLUME
FSCTL_DISMOUNT_VOLUME
IOCTL_STORAGE_MEDIA_REMOVAL
IOCTL_STORAGE_EJECT_MEDIA

However, for CD-ROM types it only does IOCTL_STORAGE_EJECT_MEDIA. In Wine at least the FSCTL_DISMOUNT_VOLUME command is also needed for ejecting to happen properly. (FSCTL_LOCK_VOLUME can be called too but it's just a stub in Wine.) IOCTL_STORAGE_MEDIA_REMOVAL would also be required for drives with door locks (it calls the CDROM_LOCKDOOR Linux ioctl under the hood), but that command throws an error for me so it might make sense to just call that IOCTL without checking if it succeeds or not.

If this can be fixed it would make ValidateDisc mode work as expected on Linux instead of erroring out after every disc.



EDIT: There also appears to be a bug in the FindVUK program/website: If a UHD disc has a verified UK only and I try to reverify with VID/MK/VUK, it says the new VUK validates and uploads but the full entry with VID/MK/VUK doesn't get put in the full KEYDB file downloaded from the site. I have to do a manual full synchronize with my local KEYDB file before it gets uploaded and starts appearing in the download version.

I'll take care of both of your posts during the next days

[Toad King]

Originally Posted by nalor

I'll take care of both of your posts during the next days

Thanks.

Also I think I sent this in a PM but the site's been acting up for me recently so I don't know if it went through: I somehow accidentally validated an incorrect UK for a disc when trying to add some info for it. Can this disc be fixed to use these keys?

0xA6F5AC52B2EDC7BA254CAD6D491799EEC1EADC03 = BAD_BOYS_FOR_LIFE (Bad Boys for Life - 4K Ultra HD) | D | 2020-02-12 | M | 0x864BFC8833D4A106DE6ACD240AEB9CF8 | I | 0xA7BB091D19F7C0B3A1880CC4BDE007BE | V | 0xC2B9CEAC8512D8C9E00912D89FBC51EC | U | 1-0x452519DA5B47634BE7D925E06B91F64F ; MKBv68/BEE/UHD/FindVUK 1.79

[coricopat]

Hey.

FYI:

I've noted that when using FindVUK via wine from Linux, the generated entries have a different VolumeSize than that used when it's run from Windows.
And it seems further, that this results in entries being actually overwritten in the Online DB?!

For example for one particular BD:

Wine/Linux: 70144229376 B / 34250112 blocks
Windows:    7014481920 B / 3425040 blocks

Inspecting the UDF filesystem directly gives the following:

blocksize=2048
blocks=34250688
usedblocks=34250112
freeblocks=0
behindblocks=0
numfiles=325
numdirs=33
udfrev=2.50
udfwriterev=2.50
lastblock=34250688
integrity=closed
accesstype=readonly
softwriteprotect=no
hardwriteprotect=no
start=16, blocks=3, type=VRS
start=32, blocks=16, type=MVDS
start=64, blocks=1, type=LVID
start=256, blocks=1, type=ANCHOR
start=288, blocks=34250112, type=PSPACE
start=34250431, blocks=1, type=ANCHOR
start=34250432, blocks=16, type=RVDS
start=34250687, blocks=1, type=ANCHOR

(Numbers are in blocks.)

One sees that the partition space entry is 34250112 blocks long, exactly what Linux gives.

Windows however gives exactly 34250112 + 288 blocks, so it also counts in the leading sections by which the PSPACE is shifted.

IMO, Linux is right, as it makes no sense to count it only the leading parts, but not the trailing ones either (which would give the actual overall size of the fs).

I even found one post somewhere (though I cannot find again) where it was said that would be a Windows 10 bug that might have been fixed later (cannot check that).

Anyway... not sure whether FindVUK could use a call under Windows to get the true full size of the fs (above that be the 34250688) and whether that's then correct under Windows. Even if, that would of course "invalidate" all current (size) entries.

One could also add another config option that allows people under Linux to specify a program which calculates the size Windows would show.
But that might be overkill (and not so easy, if a medium would have multiple PSPACES - not sure what Windows does there).

So probably just live with what we have and get changing sizes every now and then.

Cheers,
Coricopat.

[Toad King]

When using FindVUK on a UHD disc, PassKey was able to find a UK for a disc. However, the disc in question has three UKs and FindVUK/PassKey only seems to find one of the keys. MakeMKV doesn't seem to work with only incomplete UK lists, even if it can decrypt some of the streams. Are there any files/dumps I can send to help debug this?

DiscID: 0x0E2BF198E8008FD5CA109C3D7ADADEEB725F4998 (Twilight of the Warriors: Walled In)

EDIT: Nevermind, the disc only has one UK and VLC can play it just fine with the keydb. Looks like this is a bug in MakeMKV. I'll report it there.

[SamuriHL]

As I replied in your thread on makemkv forum, it's not a bug in makemkv. For whatever reason, Mike chose to only support keydb entries with vuks not unit keys.

Sent from my SM-S928U1 using Tapatalk

[etto]

Originally Posted by Toad King

When using FindVUK on a UHD disc, PassKey was able to find a UK for a disc. However, the disc in question has three UKs and FindVUK/PassKey only seems to find one of the keys. MakeMKV doesn't seem to work with only incomplete UK lists, even if it can decrypt some of the streams. Are there any files/dumps I can send to help debug this?

DiscID: 0x0E2BF198E8008FD5CA109C3D7ADADEEB725F4998 (Twilight of the Warriors: Walled In)

EDIT: Nevermind, the disc only has one UK and VLC can play it just fine with the keydb. Looks like this is a bug in MakeMKV. I'll report it there.

It seems %25 percent increase in the file and the update and for taking the initiative to report the potential bug to MakeMKV's team directly. That's the best course of action since they can properly investigate any software issues. Glad you were able to get it working with VLC in the end. It's always helpful when users follow up with solutions they find - it helps others who might encounter similar issues in the future.

[jayper]

FindVUK is triggering a virus warning by Windows security, and new downloads are currently blocked as they are being served by HTTP, not HTTPS. Anyone else experiencing something similar?

[coricopat]

Downloads have always been plain HTTP only, though it would perhaps make sense to list SHA512 sums in the main post for verifying new versions.

[Toad King]

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

[jayper]

Originally Posted by Toad King

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]

Originally Posted by Toad King

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.