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

[Roof Tile]

Hello Nalor! I was finally getting back into getting some blu rays through the VUK process when one of them decided to be a bit strange. I was using VUK on the blu rays for the TNG series boxset and all of them went through it just fine, all except Season 2 Disc 1. For some reason VUK seems to be having trouble figuring out what to do with that one. The disc seems perfectly fine and even plays in VLC like normal (which doesn't surprise me given the series popularity made them all being scanned already likely). It's just strange that it's having trouble with it compared to the others. In any case, I've taken the log file and uploaded it to this post for your perusal to find what may be causing the problem. As always I thank you extremely for your work and hope you stay happy and healthy!

[twuplay]

Hello! I just noticed in the keydb.cfg some newer releases include both unitkeys and VUKs. If VUKs are no longer available from the DVDFab memory dump, how are people obtaining them? Also, when it comes to decrypting, what is the difference between using a VUK and unitkeys? Thanks!

[nalor]

Hello Nalor! I was finally getting back into getting some blu rays through the VUK process when one of them decided to be a bit strange. I was using VUK on the blu rays for the TNG series boxset and all of them went through it just fine, all except Season 2 Disc 1. For some reason VUK seems to be having trouble figuring out what to do with that one. The disc seems perfectly fine and even plays in VLC like normal (which doesn't surprise me given the series popularity made them all being scanned already likely). It's just strange that it's having trouble with it compared to the others. In any case, I've taken the log file and uploaded it to this post for your perusal to find what may be causing the problem. As always I thank you extremely for your work and hope you stay happy and healthy!

Please upload the log somewhere else as it's still not approved here. Thanks!

[nalor]

Hello! I just noticed in the keydb.cfg some newer releases include both unitkeys and VUKs. If VUKs are no longer available from the DVDFab memory dump, how are people obtaining them? Also, when it comes to decrypting, what is the difference between using a VUK and unitkeys? Thanks!

It does not make a difference if using VUK or directly UnitKeys. Internally the VUK is used to calculate the UnitKeys - so in the end it's always UnitKeys which are used to decrypt something.

And about the source of this VUKs: I guess the users have host certificates not published yet.

[coricopat]

Is it actually the case that VUKs are no longer available via DVDFab?

As long as these people who do have unpublished (especially also AACS2.0) HCs share their VUKs / UKs (or kinda "share" them like with DVDFab), I think it's actually for the benefit of the community (of people which want to be able to play back the stuff they bought on open source platforms or even once after BluRay players are no longer produced), that these HCs are not made public - makes it more difficult to revoke them ;-)

[coricopat]

Today I've received my first Blu-ray where Passkey 9.4.5.2 told me I have to update first ... :(


Does someone have a SHA256 or similar hash for the installer of 9.2.1.2 (IIRC that was the last version that worked)? DVDFab doesn't offer older versions to download, it seems.

Thanks :-)

[DrinkLyeAndDie]

Does someone have a SHA256 or similar hash for the installer of 9.2.1.2 (IIRC that was the last version that worked)? DVDFab doesn't offer older versions to download, it seems.

Thanks :-)

Passkey 9.2.1.2 (2017.07.24)

SHA-256: 15C9B88592B8751C8D9B19A508D318A02824E5745FF2B1978C8F70FFE6A7990E

[coricopat]

thx :-) ... and again, matches the download from videohelp.com. (So should be safe, unless of course you're the admin there ;-P)

[mick0]

Is it actually the case that VUKs are no longer available via DVDFab?

Yes, DVDfab doesn't use VUKs anymore and it has never used them for UHD discs.

However, if you want VUKs for non-UHD discs, why not try "FindVUK - AACSkeys.bat" instead of old DVDfab version?

You may have to copy-paste Device Keys and Host Certificate from this post (https://forum.doom9.org/showthread.php?p=1990091#post1990091) into your KEYDB manually though.

[coricopat]

Yes, DVDfab doesn't use VUKs anymore and it has never used them for UHD discs.

Well in principle the VID is enough, so I don't mind.

But just for "completeness"... is there "open" any way to get the VUKs vor UHDs?
IIRC, one could not extract (https://forum.doom9.org/showthread.php?t=184373) them from MakeMKV's disatt.dat either.


However, if you want VUKs for non-UHD discs, why not try "FindVUK - AACSkeys.bat" instead of old DVDfab version?

Sure, that's anyway clear :-)

[DrinkLyeAndDie]

thx :-) ... and again, matches the download from videohelp.com. (So should be safe, unless of course you're the admin there ;-P)

YW. Yeah. Definitely not.

[nalor]

Does someone have a SHA256 or similar hash for the installer of 9.2.1.2 (IIRC that was the last version that worked)? DVDFab doesn't offer older versions to download, it seems.

Thanks :-)

Passkey 9.4.5.2 is the last version that worked, everything later does not include unitkeys any longer in a way where I know how to parse them.

[Roof Tile]

Ah, didn't see that the file wasn't approved yet, strange. Well, here's a MEGA (https://mega.nz/file/YqcAVIRY#UTyhE7AJXn7QPt_8LwZ7K2-is1D-POtkt3KgIDdrfTo) link to the tiny thing for your perusal.

[nalor]

Ah, didn't see that the file wasn't approved yet, strange. Well, here's a MEGA (https://mega.nz/file/YqcAVIRY#UTyhE7AJXn7QPt_8LwZ7K2-is1D-POtkt3KgIDdrfTo) link to the tiny thing for your perusal.

Thanks! Checked the log and something is failing during analysis of the memory dump.
Can you please also upload the memory dump?
(the file >F:\Vxxxxxff\Blxxxxxuff\FindVUK Tool\FindVUK Program\dump\85670F37043778F22A8243E816DACC20946941DB_STAR_TREK_TNG_S2_D1.dmp<)

Thanks!

[Roof Tile]

No problem, here is a MEGA (https://mega.nz/file/B3EVECDS#fGrBk9adDGO_378f5viNA2zbelChfthV6zlYEa2j2rs) for that. Hope it has something useful for you!

[nalor]

No problem, here is a MEGA (https://mega.nz/file/B3EVECDS#fGrBk9adDGO_378f5viNA2zbelChfthV6zlYEa2j2rs) for that. Hope it has something useful for you!

Thanks! This helped! It's really funny that this problem never appeared before ...

Please try this version here: FindVUK 1.77 (http://fvonline-db.bplaced.net/findvuk/FindVUK_1.77.zip)

In case it's working I'll publish it as new official version :)

[Roof Tile]

Yup, seemed to work normally and uploaded all the stuff as usual! Thanks for the fix!

[nalor]

Published FindVUK 1.77 "officially".

No new features, just 2 bugfixes.

[coricopat]

Is someone else seeing issues with FindVUK + DVDFab since version 13.0.2.5?

[coricopat]

It works again after downgrading to 13.0.0.4 (which is the last version from which I have a standalone installer - I guess the versions in between were not available as standalone installer, or does any one have them?)

Send the logs with the error message via PM @nalor.

[BlazDT]

@coricopat
Sent you some versions via PM (if you receive them, did not get a confirmation).

[coricopat]

> Sent you some versions via PM (if you receive them, did not get a confirmation).

Got them (thanks again).

[BlazDT]

@coricopat
Do those versions work better than the latest one for you?

[coricopat]

I haven't been able to test them yet as I'm not home right now. And due to travel plans I'll probably find no time earlier than October. Did anyone else test 13.0.2.5 meanwhile (and also see the problems)?

[coricopat]

Other topic: Has anyone every tried to tunnel *all* FindVUK down/uploads (including DNS) via Tor?

I'm not really that experienced with Windows ... and a quick Google search didn't show any "official"/trusted solutions to tunnel all through Tor.

[Emulgator]

TOR = The One Ring...
The One to find them, The One to bind them, The One to rule them all ?
Not.

[BlazDT]

@Emulgator
https://www.torproject.org/

[Emulgator]

who is why, and why is who:
History

The core principle of Tor, known as onion routing, was developed in the mid-1990s by United States Naval Research Laboratory employees, mathematician Paul Syverson, and computer scientists Michael G. Reed and David Goldschlag, to protect American intelligence communications online.[11] Onion routing is implemented by means of encryption in the application layer of the communication protocol stack, nested like the layers of an onion. The alpha version of Tor, developed by Syverson and computer scientists Roger Dingledine and Nick Mathewson and then called The Onion Routing project (which was later given the acronym "Tor"), was launched on 20 September 2002.[12][13] The first public release occurred a year later.[14]

In 2004, the Naval Research Laboratory released the code for Tor under a free license, and the Electronic Frontier Foundation (EFF) began funding Dingledine and Mathewson to continue its development.[12] ...

Tor has been described by The Economist, in relation to Bitcoin and Silk Road, as being "a dark corner of the web".[31] It has been targeted by the American National Security Agency and the British GCHQ signals intelligence agencies, albeit with marginal success,[26] and more successfully by the British National Crime Agency in its Operation Notarise.[32]

Tor is not meant to completely solve the issue of anonymity on the web. Tor is not designed to completely erase tracking but instead to reduce the likelihood for sites to trace actions and data back to the user.[28]


Tor is also used for illegal activities. These can include privacy protection or censorship circumvention,[29] as well as distribution of ...content, drug sales, or malware distribution.[30]

This is like setting up a speak-easy, isn't it...

[magician]

Is someone else seeing issues with FindVUK + DVDFab since version 13.0.2.5?

I can confirm 13.0.2.4 works perfectly. Since seeing your message I have not yet dared to install 13.0.2.5 but maybe I will try it. Hopefully it only requires a small update by @nalor.

[rdodolak]

Is someone else seeing issues with FindVUK + DVDFab since version 13.0.2.5?

FindVUK seems to fail on every disc validation with 13.0.2.5 when I try it. Rolling back to 13.0.2.4 seems to at least fix this issue for the first disc validation thought it sometimes fails on subsequent disc inserts. Usually, cancelling and re-running FindVUK for the affected disc seems to address the issue.

[nalor]

I'll check 13.0.2.5 very likely today - hopefully it's easy to fix, else it might be impossible :(

[coricopat]

Proxy Support in FindVUK

Recently I've been looking whether FindVUK can be taught to use a proxy (mostly for Tor, see above).
By chance I've noticed that FindVUK seems to recognise the http_proxy environment variable.

If you set it to something (like localhost:9150) where nothing listens, Find VUK fails e.g. with downloading from the DB.

I've asked Nalor via PM, and got the hint that this is not implemented by FindVUK itself but probably the language it's written in.

It actually supports also other proxy types (not only HTTP):
https://www.purebasic.com/documentation/http/httpproxy.html
http:// - HTTP proxy (default)
socks4:// - SOCKS4 proxy
socks4a:// - SOCKS4 proxy with domain name support rather than IP address
socks5:// - SOCKS5 proxy
socks5h:// - SOCKS5 proxy and ask the proxy to do the hostname resolving
all via the http_proxy env var.

btw: For Tor, care must be taken to use the right proxy type, especially with respect to DNS.

Also, I haven't checked whether FindVUK really uses this everywhere (i.e. for all uploads/downloads)... if you need to be sure, you should check yourself.

[nalor]

I'll check 13.0.2.5 very likely today - hopefully it's easy to fix, else it might be impossible :(

Fixed - will release a new version soon.

[coricopat]

Fixed - will release a new version soon.

:thanks: :-)

[nalor]

New release 1.79 published, I've tested it with DVDfab 13.0.2.5 and 13.0.2.6 :)

[Mischi]

1.79 is detected as Trojan.Win32/Wacatac.H!ml by Microsoft Defender.

[nalor]

1.79 is detected as Trojan.Win32/Wacatac.H!ml by Microsoft Defender.

This is imho just a false positive - at least I'm sure my computer is not infected.

[ryanmcv]

All of the download links for FindVUK are dead. Running the Synchronize script gives these errors:

# 23 # [I] FindVUK_Main / / Update enabled - check for update
# 933 # [W] update / UPD_CheckUpdateAndDownload / Incorrect release information found >< >< ><
# 933 # [W] FindVUK_Main / / Update check failed >#UPD_ERR_READFILE<

[nalor]

Sorry, screwed it up yesterday.

Fixed it now (hopefully) :)

[prozistka]

I'm using DVDFAB 13.0.2.7 to get VUK of a UHD disk and got this message.

Using 13.0.2.6 simply says my firmware is not supported and cannot even make it to get unit keys.
Looking forward to updating.

Please PM me if you need the dump file.


Log file is attached.


###############################################################################
00:32:49 - --- PART 1 --- GET DUMP ---
-------------------------------------------------------------------------------

00:33:37 - Drive opened
00:33:37 - Volume Label detected >PLANET_EARTH_II_DISC_1<
00:33:38 - DriveLetter detected >F<
00:33:38 - Detected CopyProtections AACS >1< BD+ >0<
00:33:39 - DiscID found >394D0C6C585FB4FA8B0F997871F77CC402085EDE<
00:33:41 - MainPlaylist found >00000.mpls<
00:33:44 - DVDFab64 got Unit Keys - create memdump now!
00:33:45 - Dump successful! >1<
00:33:45 - MemDump successfully finished!
00:33:45 - Cancel DVDfab decryption now!
-------------------------------------------------------------------------------
00:33:45 - Get basic AACS data
-------------------------------------------------------------------------------
00:33:45 - AACS folder on disc is reachable - Validate is possible
00:33:46 - VolumeName >PLANET_EARTH_II_DISC_1<
00:33:46 - DiscId >394D0C6C585FB4FA8B0F997871F77CC402085EDE< (2017-01-09)
00:33:46 - DiscType >UHD<
00:33:46 - MKB Revision >61<
00:33:46 - Disc-BusEncEnabled >1<
00:33:46 - Drve-BusEncCapable >1<
00:33:46 - ==> Bus Encryption active!
00:33:46 - UnitKeyCount >1<
00:33:46 - >>> UnitKeyENC (1) >3B503C92B93158FB20A74CB9F4BEAD98<
-------------------------------------------------------------------------------
00:33:46 - Analyze dump
-------------------------------------------------------------------------------
00:33:46 - Start to analyze '2018' MemDump now!
.............-................-
00:33:46 - ERROR! Finding real UnitKey >0< (Err:-3) !
00:33:46 - ERROR! Couldn't find real unit keys in json from file >D:\FindVUK_1.79\dump\394D0C6C585FB4FA8B0F997871F77CC40
02085EDE_PLANET_EARTH_II_DISC_1.dmp<
00:33:46 - Error analyzing memory dump - please report in the doom9 forum!
00:33:46 - ERROR! Analyze 2018 failed!
00:33:46 - CloseAtTheEnd is active, close DVDfab now
Waiting 3 secs before quit...

[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]

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]

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

[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