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

[nalor]

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)

Checked the code and you're right - is not working yet.

Whats your preference:
* eject disc and exit
* or just exit
* or use the ini parameter EjectDisc to define if the disc shall be ejected before the exit?

[SamuriHL]

Checked the code and you're right - is not working yet.

Whats your preference:
* eject disc and exit
* or just exit
* or use the ini parameter EjectDisc to define if the disc shall be ejected before the exit?

I'd prefer to have the ini params honored if possible. Thanks so much for looking at this!

[Toad King]

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.

That did it! Thanks for the help.

[coricopat]

* eject disc and exit
* or just exit
* or use the ini parameter EjectDisc to define if the disc shall be ejected before the exit?

IMO it would be neat if one could control both via config setting:
- whether the programs run in a loop
- whether the disc would be auto-ejected (would also be nice for Linux, where that fails as Toad King mentioned (https://forum.doom9.org/showthread.php?p=2016587#post2016587), so one could simply disable it).

[Toad King]

- whether the disc would be auto-ejected (would also be nice for Linux, where that fails as Toad King mentioned (https://forum.doom9.org/showthread.php?p=2016587#post2016587), so one could simply disable it).

In the meantime, I've been able to patch the executable to fix ejection on Linux. I don't recommend doing this for Windows users. And you need a recent version of Wine for ejection to still work properly. (Anything after 10.0 should work.)

You can patch the 1.81 executable with this command:

xxd FindVUK.exe | sed -e 's/00217fd0: 8b5c 2418 83fb 020f 8503/00217fd0: 8b5c 2418 83fb 090f 8403/' -e 's/00218330: 0448 2d00 ff74 2420 e87d 76f2 ff21 c074/00218330: 0448 2d00 ff74 2420 e87d 76f2 ff21 c066/' -e 's/00218340: 0431/00218340: 9031/' | xxd -r > FindVUK.patched.exe

Afterwards the new patched executable should have a SHA1 checksum of 8f5e0033b2247af683b94b1c50f6d1efcc52c802.

This patches two things:
* Always do the FSCTL_LOCK_VOLUME/FSCTL_DISMOUNT_VOLUME/IOCTL_STORAGE_MEDIA_REMOVAL ioctls, regardless of drive type.
* Skip checking the return value of IOCTL_STORAGE_MEDIA_REMOVAL, since that fails in Wine.

EDIT: After some more investigating it looks like FindVUK tries to eject the disc drive twice in a row, which is the part that's triggering the bug.

2025-03-18 23:27:07 # 5444 # [I] findvuk_showresult / _EjectDisc / Eject the disc now from drive >e:\<
2025-03-18 23:27:07 # 5444 # [I] drive_ms / DRVMS_EjectMedia / Eject drive >e<
2025-03-18 23:27:10 # 8177 # [I] findvuk_showresult / _EjectDisc / Successfully ejected the media in drive e!
2025-03-18 23:27:10 # 8178 # [I] FindVUK_Main / / Eject disc from drive >e< - insert next disc to validate or exit with ESC
2025-03-18 23:27:10 # 8178 # [I] FindVUK_Main / FVMAIN_Mode_ValidateDisc_EjectDisc / Eject the disc now from drive >e:\<
2025-03-18 23:27:10 # 8179 # [I] drive_ms / DRVMS_EjectMedia / Eject drive >e<
2025-03-18 23:27:10 # 8219 # [E] drive_ms / DRVMS_EjectMedia / ERROR! Couldn't remove the media in drive e!
2025-03-18 23:27:10 # 8269 # [E] FindVUK_Main / FVMAIN_Mode_ValidateDisc_EjectDisc / ERROR! Couldn't remove the media in drive e!

The first eject succeeds here but the second one called immediately after it is failing. If that is fixed then the IOCTL_STORAGE_MEDIA_REMOVAL call won't have to be patched to ignore the return value. Only the unmounting stuff for CD drives will still be required.

[nalor]

This patches two things:
* Always do the FSCTL_LOCK_VOLUME/FSCTL_DISMOUNT_VOLUME/IOCTL_STORAGE_MEDIA_REMOVAL ioctls, regardless of drive type.
* Skip checking the return value of IOCTL_STORAGE_MEDIA_REMOVAL, since that fails in Wine.

EDIT: After some more investigating it looks like FindVUK tries to eject the disc drive twice in a row, which is the part that's triggering the bug.


Found it - will prevent the double ejection in next release :)

[nalor]

The first eject succeeds here but the second one called immediately after it is failing. If that is fixed then the IOCTL_STORAGE_MEDIA_REMOVAL call won't have to be patched to ignore the return value. Only the unmounting stuff for CD drives will still be required.

A workaround is to set "EjectDisc=0" in the ini file - this prevents the first of the 2 ejects.

The fix will be to skip the 2nd eject in case the parameter is set to 1.

[Toad King]

A workaround is to set "EjectDisc=0" in the ini file - this prevents the first of the 2 ejects.

The fix will be to skip the 2nd eject in case the parameter is set to 1.

That works here. With that the only other thing required for Wine support is the FSCTL_LOCK_VOLUME/FSCTL_DISMOUNT_VOLUME/IOCTL_STORAGE_MEDIA_REMOVAL calls for disc drive volumes.

[nalor]

That works here. With that the only other thing required for Wine support is the FSCTL_LOCK_VOLUME/FSCTL_DISMOUNT_VOLUME/IOCTL_STORAGE_MEDIA_REMOVAL calls for disc drive volumes.

The code used for disc-eject is basically the one as recommended by Microsoft:

MS KB165721 (https://web.archive.org/web/20150815183515/https://support.microsoft.com/en-us/kb/165721)

Update: just noticed there's a major difference, because the example always locks, dismounts and media-removes ... will check tomorrow in detail ...

[Revolutrix]

I have been using version 1.79 for a long time and last week an automatic update to version 1.81 was carried out. On Saturday, I ran the program again and Bitdefender came up.
Gen:Suspicious.Cloud.2.dBW@auankqni
Trojan:Win32/Wacatac.B!ml

Is this a cause for concern? Or just add it as an exception. Is there a Sha1 value of the current version, to avoid an error during download?

[nalor]

I have been using version 1.79 for a long time and last week an automatic update to version 1.81 was carried out. On Saturday, I ran the program again and Bitdefender came up.
Gen:Suspicious.Cloud.2.dBW@auankqni
Trojan:Win32/Wacatac.B!ml

Is this a cause for concern? Or just add it as an exception. Is there a Sha1 value of the current version, to avoid an error during download?

This is the SHA1 of the exe:
SHA1: 791194cd9a5081663f44974b312216dbf31aadae

The virus message is an error, there's something in the exe files created by Purebasic that triggers the antivirus tools ... usually they learn after a few days that it's a false positive.

[nalor]

That works here. With that the only other thing required for Wine support is the FSCTL_LOCK_VOLUME/FSCTL_DISMOUNT_VOLUME/IOCTL_STORAGE_MEDIA_REMOVAL calls for disc drive volumes.

Published 1.82 - imho the "eject" is now using the correct sequence of commands.
Note: in case the "lock" fails, the eject continues even without lock.

[Toad King]

Published 1.82 - imho the "eject" is now using the correct sequence of commands.
Note: in case the "lock" fails, the eject continues even without lock.

Tested in Wine, validate mode now ejects and waits properly without having to patch the executable. Thanks!

[SamuriHL]

Thanks for the new version! I'll give it a try for my use case a bit later. Much appreciated!

[coopervid]

Published 1.82 - imho the "eject" is now using the correct sequence of commands.
Note: in case the "lock" fails, the eject continues even without lock.

The update hangs.

Update process started >E:\bluray\FindVUK\mod.update.exe< - end current process now. It seems all versions of the links in the first post for FindVUK don't work anymore.

[nalor]

The update hangs.

Update process started >E:\bluray\FindVUK\mod.update.exe< - end current process now. It seems all versions of the links in the first post for FindVUK don't work anymore.

Just checked locally and cannot reproduce, on my Win 11 notebook update from 1.79 to 1.82 worked flawless.
(and the update process hasn't been changed since a long time)

[coopervid]

Just checked locally and cannot reproduce, on my Win 11 notebook update from 1.79 to 1.82 worked flawless.
(and the update process hasn't been changed since a long time)

Some update of Windows must block now http connections and therefore the synchronize process hangs. For both Chrome and Firefox the download only works when I specifically allow the download of the file from fvonline-db.bplaced.net via http. I need then to manually install the newest FindVUK.

[luigiish]

I don't know if this is the right place to share this, but anyway...

I didn't find Love Live! Superstar!! 3rd Season 3 in the keydb. Without it, I'm not able to reproduce it on VLC. There's only Love Live! Superstar!! 3rd Season 1, 2 and 4 keys there.

[MrPenguin]

I didn't find Love Live! Superstar!! 3rd Season 3 in the keydb. Without it, I'm not able to reproduce it on VLC. There's only Love Live! Superstar!! 3rd Season 1, 2 and 4 keys there.
If you have the disks yourself then feel free to add them to keydb ;).

[luigiish]

If you have the disks yourself then feel free to add them to keydb ;).

I'd like to do it, but I'm basically newbie in this type of thing. I have no idea on how to do it.

[MrPenguin]

I'd like to do it, but I'm basically newbie in this type of thing. I have no idea on how to do it.
This thread (https://forum.doom9.org/showthread.php?t=176924) should explain how install libaacs and libbluray, which should be able to handle any standard BluRay - once you've also installed an up-to-date KEYDB.cfg file.

libaacs cannot yet generate keys for UHD disks.

See also here (https://forum.doom9.org/showthread.php?p=2016431#post2016431) and here (https://forum.doom9.org/showthread.php?p=1990091#post1990091).

[SamuriHL]

Just want to say thanks to Nalor for the changes to validate disc. I was able to add that functionality to my front-end UI for findvuk and have been able to validate a bunch of discs with it. Very nice!

[markfilipak]

FindVUK 1.82, 'FindVUK.exe AACSkeys=H', asked me to post this here.
+ VENDOR # PRODUCT-IDENTIF. # REV. # FIRMWARE CR. # INTERFACE # DRIVETYPE # BusEncryptionCapable # BindingNonceGeneration # VENDOR SPECIFIC # FEATURE DESCRIPTOR # COMMENT
| HL-DT-ST | BD-RE BP50NB40 | 1.03 | 212107081603 | Serial ATAPI | BLURAY/DVD/CD-WRITER | 1 | 1 | N000300SIK05N15F004 | 01 0D 09 04 17 01 02 01 |

I'm bewildered. Is there a non-codesmith roadmap to FindVUK?

[markfilipak]

I have many movies and concert videos that are not found in keydb.cfg but that anydvd decrypted. Is there a way to take what anydvd did and add it to keydb.cfg?

[Emulgator]

The full database is here:
http://fvonline-db.bplaced.net/

[markfilipak]

The full database is here:
http://fvonline-db.bplaced.net/
Hello, my friend,

You've always been helpful. I appreciate you!

Yes, that's the keydb.cfg. Is there a way to 'take' what anydvd did and integrate it into that database?

[SamuriHL]

Not easily, no. You can't just "extract keys" from AnyDVD unfortunately. FindVUK will use DVDFab to find the keys if you have a compatible DVDFab product. If these are blu-rays then you can use the AACSKEYS option in FindVUK to find them without DVDFab products assuming you have the latest device keys in your local keydb.cfg.

[Emulgator]

You may want to get the legacy version and search for the titles you mean.
At >130.000 entries your titles might be already in there.
I don't remember the exact link address ATM, the earlier FindVUK downloaded the full version, the later only kept the necessary entries.

[markfilipak]

... If these are blu-rays then you can use the AACSKEYS option in FindVUK to find them without DVDFab products assuming you have the latest device keys in your local keydb.cfg.

What do I make of this?
===anydvd's log===
Anydvd has the good sense to automatically open the log in the default text editor.
Error reading from drive H:!
Verify Error Sectors: 10342680-10342694
Verify Error Sectors: 10342695-10342709
Verify Error Sectors: 10342710-10342724
Verify Error Sectors: 10342725-10342739
Verify Error Sectors: 10342740-10342754
Verify Error Sectors: 10342755-10342769
Verify Error Sectors: 10342770-10342784
Verify Error Sectors: 10342785-10342799
Verify Error Sectors: 10342800-10342814
Verify Error Sectors: 10342815-10342829
I aborted at that point. I'm currently rerunning anydvd to get _all_ the 'error' sectors.

===keydb.cfg lists===
0x651B81BF4C928831A2B77BB1717B79CBD4E5D010 = ERBRD5182 (Peter Gabriel Live in Athens 1987) | D | 2013-07-24 | V | 0x96DD33ABDB05A9017A657A4C05A0D088 | M | 0x3B1BF3B12C22A73C5410419EFF4233AB | I | 0x04D3602C288FA2E201A89C999CB8D594 | U | 1-0x5038124D690BC67B24E80BA759B8AA93 ; (LEGACY) (NOTVALIDATED) (BD)
0x32339FD6045AD1209AA297284F888F8D6C289006 = EVB334649 (Peter Gabriel Live in Athens 1987) | D | 2013-07-25 | V | 0x9403B1DE5B2912F84E914940BE474422 | M | 0xC95494367FDC54D36BBA41434C9A0A28 | I | 0xDA71DCF798D9223969D0AB0B87EFF7E0 | U | 1-0x0BCA8CDCFC2608831CF7D8D3619900D6 ; MKBv39 - MainPlaylist: 00002.mpls - VolumeSize: 41052796928 (LEGACY) (NOTVALIDATED) (BD)

Mine is the second one: "| D | 2013-07-25".
Note "; MKBv39 - MainPlaylist: 00002.mpls - VolumeSize: 41052796928 (LEGACY) (NOTVALIDATED) (BD)". I will check the VolumeSize after anydvd is done and will post it with _all_ the 'error' sectors.

===running findvuk===
G:\[D]\D\setup\Video\Xreveal\2025-03-29 FindVUK_1.82>findvuk aacskeys=h
-----------------------------------------------------------
16:08:27 - ----------- FindVUK 1.82 -----------
-----------------------------------------------------------
To close FindVUK simply press the ESC key
-----------------------------------------------------------
16:08:27 - MODE: AACSkeys

16:08:27 - DriveLetter : h

16:08:27 - SettingsFile: >G:\[D]\D\setup\Video\Xreveal\2025-03-29 FindVUK_1.82\config\FindVUK.ini<
16:08:27 - Logfile >G:\[D]\D\setup\Video\Xreveal\2025-03-29 FindVUK_1.82\log\2025-04-19_FindVUK.txt< Default Loglevel >2<
16:08:27 - Update enabled - check for update
16:08:27 - Update check failed >#UPD_ERR_DOWNLOADFAILED<
16:08:27 - Open Main-KEYDB file: >C:\Users\Administrator\AppData\Roaming\aacs\KEYDB.cfg<
16:08:27 - Open Backup-KEYDB file: >G:\[D]\D\setup\Video\Xreveal\2025-03-29 FindVUK_1.82\VUKbackup\KEYDB.cfg<
16:08:27 - Driveletter for AACSkeys set to >h<

###############################################################################
16:08:27 - --- PART 1 --- GET AACSKEYS DATA ---
-------------------------------------------------------------------------------

-------------------------------------------------------------------------------
16:08:27 - Get basic AACS data
-------------------------------------------------------------------------------
16:08:27 - AACS folder on disc is reachable - Validate is possible
16:08:33 - Different VolumeName detected - most likely the disc has been changed... take the new name
16:08:33 - VolumeName >EVB334649<
16:08:33 - DiscId >32339FD6045AD1209AA297284F888F8D6C289006< (2013-07-25)
16:08:33 - DiscType >BD<
16:08:33 - MKB Revision >39<
16:08:33 - Disc-BusEncEnabled >0<
16:08:33 - Drve-BusEncCapable >1<
16:08:33 - UnitKeyCount >1<
16:08:33 - >>> UnitKeyENC (1) >039AA3691B032FAC8F9D1465AE8F2166<
-------------------------------------------------------------------------------
16:08:33 - --- PART 2 --- VALIDATE VUK/UNITKEYS ---
-------------------------------------------------------------------------------
16:08:34 - Drive is detected as 'REAL BLURAY' drive
16:08:34 - M2TS files found >12<
16:08:34 - There are still 12 files that cannot be decoded with the provided unit keys!
16:08:34 - Validation failed - VUK/UnitKeys are INVALID!!!!!!!
16:08:34 - Please report this in the Doom9 forum and attach the logfile!
I would put findvuk's log here but doom9 won't let me -- too many bytes.

[SamuriHL]

My guess would be read errors on the disc but hard to say. Try cleaning it even if it "looks" clean.

[markfilipak]

My guess would be read errors on the disc but hard to say. Try cleaning it even if it "looks" clean.
I did that, and examined it under magnification. The disc is pristine.

UPDATE: Anydvd is recording all 'error' sectors. It is behaving like _every_ sector past 10342679 is an 'error'. It says it will complete in just over 1200 hours -- that's 50 days. Of course, I will stop it before 50 days, but I'll let it run for awhile. That all sectors past 10342679 are 'error' is highly improbable. The likely verdict is that the key changes at sector 10342680.

[markfilipak]

UPDATE
I allowed anydvd to run for two hours. It reported
Verify Error Sectors beginning with sector 10342680 through at least sector 10358774 -- I stopped it.
That's 16095 sectors without a break. I'm sure I don't need to convince anyone that every sector in 16095 sectors is in 'error' is well beyond believable.

G:\[D]\D\setup\Video\Xreveal\2025-03-29 FindVUK_1.82>findvuk validatedisc drive=h
-----------------------------------------------------------
19:24:24 - ----------- FindVUK 1.82 -----------
-----------------------------------------------------------
To close FindVUK simply press the ESC key
-----------------------------------------------------------
19:24:24 - MODE: ValidateDisc

19:24:24 - DriveLetter : h

19:24:24 - SettingsFile: >G:\[D]\D\setup\Video\Xreveal\2025-03-29 FindVUK_1.82\config\FindVUK.ini<
19:24:24 - Logfile >G:\[D]\D\setup\Video\Xreveal\2025-03-29 FindVUK_1.82\log\2025-04-19_FindVUK.txt< Default Loglevel >2<
19:24:24 - Update enabled - check for update
19:24:24 - Update check failed >#UPD_ERR_DOWNLOADFAILED<
19:24:24 - Open Main-KEYDB file: >C:\Users\Administrator\AppData\Roaming\aacs\KEYDB.cfg<
19:24:24 - Open Backup-KEYDB file: >G:\[D]\D\setup\Video\Xreveal\2025-03-29 FindVUK_1.82\VUKbackup\KEYDB.cfg<
-------------------------------------------------------------------------------
19:24:24 - Get basic AACS data
-------------------------------------------------------------------------------
19:24:24 - AACS folder on disc is reachable - Validate is possible
19:24:29 - VolumeName >EVB334649<
19:24:29 - DiscId >32339FD6045AD1209AA297284F888F8D6C289006< (2013-07-25)
19:24:29 - DiscType >BD<
19:24:29 - MKB Revision >39<
19:24:29 - Disc-BusEncEnabled >0<
19:24:29 - Drve-BusEncCapable >1<
19:24:29 - UnitKeyCount >1<
19:24:29 - >>> UnitKeyENC (1) >039AA3691B032FAC8F9D1465AE8F2166<
19:24:29 - No entry for discid >32339FD6045AD1209AA297284F888F8D6C289006< available in keydb >C:\Users\Administrator\AppData\Roaming\aacs\KEYDB.cfg< - no validation pos
sible!
19:24:29 - Eject the disc now from drive >h:\<

19:24:33 - Successfully ejected the media in drive h!
-------------------------------------------------------------------------------
19:24:33 - Get basic AACS data
-------------------------------------------------------------------------------
19:24:33 - AACS folder on disc in drive >h< is not accessible - keep waiting for disc to appear (abort with ESC)
Note the UnitKeyENC: 0x039AA3691B032FAC8F9D1465AE8F2166
That's new and is not in keydb.cfg.

How do I proceed?

[MrPenguin]

Note the UnitKeyENC: 0x039AA3691B032FAC8F9D1465AE8F2166
That's new and is not in keydb.cfg.

How do I proceed?
Isn't this your disk?
0x32339FD6045AD1209AA297284F888F8D6C289006 = EVB334649 (Peter Gabriel Live in Athens 1987) | D | 2013-07-25 | ...
It's already in KEYDB.cfg, so this should work provided your disk is OK.

KEYDB entries only contain decrypted unit keys, whereas UnitKeyENC is the Unit Key that has been encrypted using the VUK. And AFAICT your UnitKeyENC value is consistent with the disk's entry in KEYDB.cfg.
19:24:29 - No entry for discid >32339FD6045AD1209AA297284F888F8D6C289006< available in keydb >C:\Users\Administrator\AppData\Roaming\aacs\KEYDB.cfg< - no validation pos
sible!
This doesn't look right. Have you tried executing "findvuk synchronize" to ensure your copy of KEYDB.cfg is up-to-date?

[markfilipak]

Thanks for replying...
Isn't this your disk?

No, it isn't.

KEYDB entries only contain decrypted unit keys, whereas UnitKeyENC is the Unit Key that has been encrypted using the VUK. And AFAICT your UnitKeyENC value is consistent with the disk's entry in KEYDB.cfg.
19:24:29 - No entry for discid >32339FD6045AD1209AA297284F888F8D6C289006< available in keydb >C:\Users\Administrator\AppData\Roaming\aacs\KEYDB.cfg< - no validation pos
sible!
This doesn't look right. Have you tried executing "findvuk synchronize" to ensure your copy of KEYDB.cfg is up-to-date?
My keydb.cfg is up to date. I downloaded it today. Regarding synchronize, I can't do that. Windows is not connected to the Internet.

[markfilipak]

Well, I'm really confused now. I don't know how I arrived here, but I thought that FindVUK had to do with KeyDB.cfg and movie discs, but I see from here: BD-Video_Key_Extraction (http://wiki.redump.org/index.php?title=BD-Video_Key_Extraction), that it is for game discs. Or am I wrong and that's just a coincidence?

[SamuriHL]

Findvuk has nothing to do with game discs. It is for Blu-ray and uhd.

Sent from my SM-S938U1 using Tapatalk

[MrPenguin]

No, it isn't.

Your own FindVUK output says that your DiscId is 0x32339FD6045AD1209AA297284F888F8D6C289006, and this DiscId does indeed have an entry in KEYDB.cfg. Moreover, the UnitKeyENC value provided by your FindVUK output is entirely consistent with this KEYDB.cfg entry too.

The probability that this entry is not for your disk is therefore bordering on the preposterous...

Have you computed the SHA1 hash of your disk's AACS/Unit_Key_RO.inf file?
My keydb.cfg is up to date. I downloaded it today.
OK, but did you copy it to the correct place? Your FindVUK output says that it failed to find your DiscId in
C:\Users\Administrator\AppData\Roaming\aacs\KEYDB.cfg
However, KEYDB.cfg has contained an entry for DiscId=0x32339FD6045AD1209AA297284F888F8D6C289006 since February at least, which makes me think that the Adminstrator's KEYDB.cfg file is not today's version.

[markfilipak]

One mystery closes, and another, deeper mystery opens: How was 'C:\Users\Administrator\AppData\Roaming\aacs\' created?
Your own FindVUK output says that your DiscId is 0x32339FD6045AD1209AA297284F888F8D6C289006, and this DiscId does indeed have an entry in KEYDB.cfg. Moreover, the UnitKeyENC value provided by your FindVUK output is entirely consistent with this KEYDB.cfg entry too.

The probability that this entry is not for your disk is therefore ordering on the preposterous...
I agree.
Have you computed the SHA1 hash of your disk's AACS/Unit_Key_RO.inf file?
Thank you! Now I know the file and which hash to apply.

It's 0x32339fd6045ad1209aa297284f888f8d6c289006, and that _is_ in KeyDB.cfg as expected.

The mystery deepens.
OK, but did you copy it to the correct place?
Yes. As instructed: 'c:\ProgramData\aacs\KeyDB.cfg'.
Your FindVUK output says that it failed to find your DiscId in
C:\Users\Administrator\AppData\Roaming\aacs\KEYDB.cfg
Where did FindVUK get that path?

A search for KeyDB.cfg finds three:
'c:\ProgramData\aacs\KeyDB.cfg':)
'c:\Users\All Users\aacs\KeyDB.cfg':rolleyes:
'c:\Users\Administrator\AppData\Roaming\aacs\keydb.cfg':devil:

Regarding :) and :rolleyes: 'c:\Users\All Users\' is a hard link to 'c:\ProgramData\', so they are in fact the same file. 'c:\Users\All Users\aacs\' is virtual -- don't ya just love Windows.

Regarding :devil: It's a zero-length file.
I did not make 'c:\Users\Administrator\AppData\Roaming\aacs\'. I did not make a zero-length file. I wonder who did. :sly:

I'm running Windows 7, SP1.

I'm rerunning Xreveal for the thousandth time. Xreveal says,
"Retrieved keys from keydb.cfg.
Verified keys succeed.
Removed AACS protection.
Removed 3 UOPs protection."
as it has in the past.
I will post an update when it's finished.

[MrPenguin]

Yes. As instructed: 'c:\ProgramData\aacs\KeyDB.cfg'.
Is that "%ProgramData%\aacs"?

I did not make 'c:\Users\Administrator\AppData\Roaming\aacs\'. I did not make a zero-length file. I wonder who did. :sly:
I believe "C:\Users\Administrator\AppData\Roaming\aacs" is "%APPDATA%\aacs" for the Administrator user. You would need to check this KEYDB.cfg file's timestamps to discover when it was created, but I suspect that you have executed FindVUK as Administrator at some point.

Personally speaking, I don't recommend running anything as Administrator unless strictly necessary.

[markfilipak]

Is that "%ProgramData%\aacs"?

I believe "C:\Users\Administrator\AppData\Roaming\aacs" is "%APPDATA%\aacs" for the Administrator user. You would need to check this KEYDB.cfg file's timestamps to discover when it was created, but I suspect that you have executed FindVUK as Administrator at some point.

Personally speaking, I don't recommend running anything as Administrator unless strictly necessary.
I am always Administrator. That's why Windows is not connected to the Internet. I connect to the Internet through an Oracle VBox virtual machine running Linux. As Administrator, I avoid all permissions problems and I don't run any anti-virus. It's as close to a single-user system as is possible.

[markfilipak]

Xreveal failed at exactly the same point where AnyDVD failed. I turned Xreveal OFF and tried to play the disc with PowerDVD 18. PowerDVD would not play it but that's not definitive because PowerDVD 18 has not been updated for many years and cannot be updated.

However, at this point, I believe the BD is bad. This is why I have 20TB of disk. This is why I make copies. (...goodbye Peter. It was a great show, but I guess I'll never see it again.)

That stills leaves the mystery: How was 'C:\Users\Administrator\AppData\Roaming\aacs\' created?

[markfilipak]

Is that "%ProgramData%\aacs"?

From the environment:
APPDATA=C:\Users\Administrator\AppData\Roaming
ProgramData=C:\ProgramData

'%APPDATA%\aacs\keydb.cfg' = 0 bytes.
'%ProgramData%\aacs\keydb.cfg' = 57,433,037 bytes.

THOUGHTS: My guess is that some part of Xreveal sometimes uses '%APPDATA%\aacs\keydb.cfg', and sometimes uses '%ProgramData%\aacs\keydb.cfg'.

'c:\Users\All Users' is a hard link to 'c:\ProgramData', so 'c:\Users\All Users\aacs\KeyDB.cfg'=='c:\ProgramData\aacs\KeyDB.cfg'.

[Toad King]

I would assume most tools use "%APPDATA%\aacs\keydb.cfg" (except MakeMKV which needs it in its own directory). I would simply copy the file there and delete the program data one.

To be specific, libaacs uses the CSIDL_APPDATA directory as the base directory and on modern Windows that is "C:\Users\<username>\AppData\Roaming" most of the time.

[MrPenguin]

Xreveal failed at exactly the same point where AnyDVD failed. I turned Xreveal OFF and tried to play the disc with PowerDVD 18. PowerDVD would not play it but that's not definitive because PowerDVD 18 has not been updated for many years and cannot be updated.
But KEYDB.cfg already contains all the keys for your disk, so I cannot fathom why you are bothering with either Xreveal or AnyDVD in the first place. Just play the disk with VLC...

If you want to check your disk's readability then you should be able just to copy its entire contents to your hard disk because this BD doesn't use bus encryption.
That stills leaves the mystery: How was 'C:\Users\Administrator\AppData\Roaming\aacs\' created?
My guess would be that you executed FindVUK at some point before %ProgramData%\aacs\KEYDB.cfg existed, and FindVUK created an empty one for you. Once deleted, I expect FindVUK to find the system KEYDB.cfg instead, and then you can execute
findvuk validateDisc drive=H
The point is that FindVUK is currently finding %AppData%\aacs\KEYDB.cfg before %ProgramData%\aacs\KEYDB.cfg, so you need to delete one of these files and ensure the other is correct.

[markfilipak]

I would assume most tools use "%APPDATA%\aacs\keydb.cfg" (except MakeMKV which needs it in its own directory). I would simply copy the file there and delete the program data one.

To be specific, libaacs uses the CSIDL_APPDATA directory as the base directory and on modern Windows that is "C:\Users\<username>\AppData\Roaming" most of the time.
My emphasis.

The instructions say to copy to here: 'c:\ProgramData\aacs\KeyDB.cfg'.

[markfilipak]

But KEYDB.cfg already contains all the keys for your disk, so I cannot fathom why you are bothering with either Xreveal or AnyDVD in the first place. Just play the disk with VLC...

Uh, I don't play with VLC. I make ISOs and store them in my 20TB backup. I mount them and play with MPV.

If you want to check your disk's readability then you should be able just to copy its entire contents to your hard disk because this BD doesn't use bus encryption.

I reckon that wouldn't gain me anything. Why bother?

My guess would be that you executed FindVUK at some point before %ProgramData%\aacs\KEYDB.cfg existed, and FindVUK created an empty one for you. ...

Bad guess. I only recently became aware of FindVUK's existence.

... Once deleted, I expect FindVUK to find the system KEYDB.cfg instead, and then you can execute
findvuk validateDisc drive=H
The point is that FindVUK is currently finding %AppData%\aacs\KEYDB.cfg before %ProgramData%\aacs\KEYDB.cfg, so you need to delete one of these files and ensure the other is correct.
You cannot be correct. Xreveal decrypts 51% of the disc before failing, so it must be finding the valid keydb.cfg.

[MrPenguin]

I make ISOs and store them in my 20TB backup. I mount them and play with MPV.
MPV can decrypt AACS just fine, so long as it also has a valid KEYDB.cfg file.

I reckon that wouldn't gain me anything. Why bother?
Copying the disk directly to your hard disk would remove Xreveal, FindVUK and any other program from the problem, and would determine whether even Windows can read your disk.

Bad guess. I only recently became aware of FindVUK's existence.

Whatever. Check the timestamps on the empty KEYDB.cfg file. Maybe that will provide you with a clue?
Xreveal decrypts 51% of the disc before failing, so it must be finding the valid keydb.cfg.
I was talking about FindVUK, not Xreveal. FindVUK failed to validate your disk because it found the empty KEYDB.cfg file.

[markfilipak]

MPV can decrypt AACS just fine, so long as it also has a valid KEYDB.cfg file.

Copying the disk directly to your hard disk would remove Xreveal, FindVUK and any other program from the problem, and would determine whether even Windows can read your disk.

Yes. That's exactly what I do. I make an ISO on a hard disk. The ISO can be mounted and played (or transcoded, remuxed, etc.) without Xreveal (or AnyDVD) because it's no longer encrypted.

Whatever. Check the timestamps on the empty KEYDB.cfg file. Maybe that will provide you with a clue?

Too late.

I was talking about FindVUK, not Xreveal. FindVUK failed to validate your disk because it found the empty KEYDB.cfg file.

Well, my friend, you are right of course. That's why I copied 'C:\ProgramData\aacs\KeyDB.cfg' to ' C:\Users\Administrator\AppData\Roaming\aacs\KeyDB.cfg'.

At the moment, I'm ripping the disc for the 1001st time, and Xreveal has passed sector 10342680! Woo-hoo! Xreveal is now at sector 10476690. I think it's going to succeed.

[SamuriHL]

Hey, Nalor what's this one mean?


Failed to init disc >AACS UNKNOWN ERROR >-725<<


Trying to open a blu-ray using validate disc. Tried two different drives got it on both. It's got a valid keydb entry, just trying to validate all the ones I can and ran into this.

[coricopat]

(@nalor and/or others) Minor… "bug" in FindVUK:

I've had already stumbled over this before and first thought it was a bug, then wasn't able to reproduce it again later, but now I found it again. It probably won't apply to most people (which is why I put the bug in quotes).

I typically execute FindVUK from within Cygwin and when doing so in aacskeys mode, this seems to fail if the aacskeys.exe binary doesn't have the POSIX-style executable bit set (which Cygwin somehow magically maps to to files on Windows filesystems - I think it uses extended attributes from NTFS).

The problem is that the error message is completely misleading, it complains that the HC would have been revoked (well it has been in MKBv82, but the drive hasn't seen that yet)... and as soon as I chmod a+x aacskeys.exe it works again.

I could imagine that FindVUK simply checks for a zero exit status of aacskeys.exe? At least under POSIX, if an exec fails the exit status is typically 127, so maybe FindVUK could specifically check for whether aacskeys.exe just failed or whether it couldn't even be executed at all.
But, don't put too much effort into this... as said it's really a niche case.

Cheers.