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

[nalor]

The main issue I reported earlier (https://forum.doom9.org/showthread.php?p=1990248#post1990248) was the lack of support for UHD in FindVUK 1.64+ with DVDFab 12.1.0.0 and higher (it works with DVDFab 12.0.9.9).

Please test with FindVUK 1.66 - for me it's now working with DVDfab 12.1.0.1 and 12.1.1.15

[nalor]

Since you did not mention a new version of FindVUK, are the changes just on the server side?

(Sorry for the multiple posts, I have occasionally been getting my submissions moderated by the forum and I'm not sure if it's because they are too long or what...)

No - I just didn't think about "non-friendly" drives ...

[SamuriHL]

Yes, sadly you would need a friendly drive. When FindVUK submits validated meta info, I believe it includes a signature to prove the data came from FindVUK. This is how it distinguishes between keys that FindVUK itself has validated and keys from other sources (that may or may not be correct), in order to protect against accidental or malicious poisoning of the data. Probably the bad key for your disc was submitted first via the "legacy" sync mechanism or came from a prior version of the keydb.cfg before the validation system was started. Likewise, unless you can submit your own key with the real-time validation, it would also be considered non-validated.

Of course, I assume nalor could manually fix or remove the "000000" entry in the DB since it is obviously wrong.

Yea it's not for one of my discs. Someone else has the disc and noticed the key was wrong. I'm simply trying to help correct it, given that i know what the correct key should be. We should all want the data to be as accurate as possible. Just trying to do my part to help.

[magician]

Please test with FindVUK 1.66 - for me it's now working with DVDfab 12.1.0.1 and 12.1.1.15

Working great - thanks! I have more bug reports and a feature request.

1) Bug report

The unit keys for discs with multiple unit keys is represented in the keydb.cfg in the form:
| U | 1-0x012...ABC|2-0x345...DEF|...|7-0xFED...987

When FindVUK newly obtains unit keys for such a disc, it unexpectedly adds spaces around the numbered key separators, like so:
| U | 1-0x012...ABC | 2-0x345...DEF | ... | 7-0xFED...987

Then it gets confused when comparing with existing data in the KeyDB and thinks the unit keys are new, when the only difference might be just the amount of whitespace. That's because when processing a subsequent, different disc, the program normalizes the data it reads in from the master KeyDB file and removes the extra spacing (and writes back this "fixed" version).

Addressing this minor inconvenience would stop FindVUK from interpreting otherwise identical KeyDB entries as changed.

2) Bug report

When the synchronize function operates in delta mode, it optimizes the amount of data needed for syncing by only downloading updates since the last timestamp recorded in keydb_fvhash.ini if the checksum value matches the keydb.cfg.

However, it doesn't update that INI after syncing. So if I immediately run the sync script again, it falls back to a full sync. Incidentally, so-called legacy entries appear to be uploaded only during a full sync. Not sure if this behavior is intentional, but I thought I'd bring it to your attention.

3) Feature request

In AACSkeys mode, FindVUK refuses to validate a BEE disc (non-UHD, of course). If the RDK is already available in the cache and FindVUK can use it, or I can have a way to disable the drive check in this mode so LibreDrive can handle the bus decryption, then I can do everything through AACSkeys and wouldn't have to run the disc again through DVDFab.

[SamuriHL]

Ok well now I can't submit ANY UHD keys at all. They're not taking. This is not awesome. :(

EDIT: I cleaned out my OnlineDB_Backup directory and was able to upload 3 new entries just now. Still no luck on updating the one with an invalid key.

EDIT2: NOPE. I redownload the keydb after it tells me it uploaded them successfully and they aren't there. This is super frustrating!


12:18:42 - LocalKeyFile: add >1< new/changed Title entries
12:18:42 - Title entry missing in ONLINE file >4C809E0173A9D23C04A53B9A5206BA58737D2D37<
12:18:42 - Different Title entry >4B8692B5BBBF9F7B4D420C3AF756D61A24FF6B6B< - sync changes To LOCAL file (And check relevance For OnlineDB)
12:18:42 - Title entry missing in ONLINE file >3FC3DF3C065B5D9F23E8B4DD85397B7B3EB6FF40<
12:18:42 - Title entry missing in ONLINE file >7A312B6BB9B255F35B103C9DC47AA0CBC72E3D8F<
12:18:42 - DeviceKey - LocalKeyFile >3< keys - OnlineKeyFile >3< keys
12:18:42 - LocalKeyFile: add >0< new/changed DeviceKey entries
12:18:42 - HostCertificate - LocalKeyFile >1< keys - OnlineKeyFile >1< keys
12:18:42 - LocalKeyFile: add >0< new/changed HostCertificate entries
12:18:42 - ProcessingKey - LocalKeyFile >3< keys - OnlineKeyFile >3< keys
12:18:42 - LocalKeyFile: add >0< new/changed ProcessingKey entries
12:18:42 - OnlineKeyFile: add new entries
12:18:42 - MapSize OnlineDiff Title >3< DK >0< HC >0< PK >0<
12:18:43 - LOCAL-Keyfile:
Title 0 new entries, 2 changed entries
DeviceKey 0 new entries, 0 changed entries
HostCertificate 0 new entries, 0 changed entries
ProcessingKey 0 new entries, 0 changed entries
12:18:43 - ONLINE-KeyFile:
Title 3 new entries, 0 synced entries
12:18:43 - #### Upload changes to OnlineDB ####
Establishing connection
12:18:44 - Successfully posted to the OnlineDB! >
Preconditions fulfilled - process upload now
Detected BlurayLegacyXML
Upload written to database!
< - now triggering the processing
12:18:44 - Processing starts - iteration 1
12:18:44 - Processing of last iteration 1 finished ><


Any thoughts on this? As I can no longer now upload new keys which does NOT seem good!

[Grimsdyke]

Can't you just purchase a LibreDrive ?

[SamuriHL]

All of my drives are "LibreDrive" compatible. They aren't UHD friendly. And they can't be flashed to UHD friendly.

[nalor]

Ok well now I can't submit ANY UHD keys at all. They're not taking. This is not awesome. :(

Any thoughts on this? As I can no longer now upload new keys which does NOT seem good!

Hi! Sorry for the problems - but I've no spontaneous idea ...

Can you post the 3 new entries here or send me a pm with them so I can add them to my file and check what is happening?

Thanks!

[nalor]

All of my drives are "LibreDrive" compatible. They aren't UHD friendly. And they can't be flashed to UHD friendly.

Can you tell me which model your drive is? You signature shows a few details about your setup - but exactly this information is missing ;)

Thanks!

[nalor]

Working great - thanks! I have more bug reports and a feature request.


Bug 1: you're right - already found the the place, will fix it tomorrow
Bug 2: already fixed locally, based on my research I'd say this never worked correctly ...

Feature request: will check tomorrow :)

[SamuriHL]

Hi! Sorry for the problems - but I've no spontaneous idea ...

Can you post the 3 new entries here or send me a pm with them so I can add them to my file and check what is happening?

Thanks!

I'll PM you the missing keys. Someone who checks regularly said there's been no new keys added at all since Sunday night. Isn't that when you made the first back end change?

[SamuriHL]

Can you tell me which model your drive is? You signature shows a few details about your setup - but exactly this information is missing ;)

Thanks!

BU40N 1.00
Pioneer which is irrelevant for this discussion as it's not supported by DVDFab anyway. :)

[nalor]

I'll PM you the missing keys. Someone who checks regularly said there's been no new keys added at all since Sunday night. Isn't that when you made the first back end change?

Fixed - made a stupid mistake so that the uploaded files did not get processed any longer ... as nothing has been lost, I've processed them manually now and fixed the original problem.

[nalor]

2) Bug report

When the synchronize function operates in delta mode, it optimizes the amount of data needed for syncing by only downloading updates since the last timestamp recorded in keydb_fvhash.ini if the checksum value matches the keydb.cfg.

However, it doesn't update that INI after syncing. So if I immediately run the sync script again, it falls back to a full sync. Incidentally, so-called legacy entries appear to be uploaded only during a full sync. Not sure if this behavior is intentional, but I thought I'd bring it to your attention.



Just released 1.67 with the fix for this bug.

[SamuriHL]

Fixed - made a stupid mistake so that the uploaded files did not get processed any longer ... as nothing has been lost, I've processed them manually now and fixed the original problem.

Oh excellent!! This is great news.

[metalsonic88]

I get this too with LG WH16NS60 FW 1.00 + UHD disc. It did work before the BE validation was added. AFAIK DVDfab won't work with FW 1.01 or later.

This is just a guess, but it could be caused by FindVUK attempting to read AACS drive certificate for DriveID calculation when AACS2 is active. If this is the case then FindVUK should probably read AACS2 drive certificate on UHD official drive when UHD disc is inserted.

AACS2 drive certificate can be read by changing the Key Class from 02h to 03h. In fact all AACS2 authentication related MMC commands should use Key Class 03h. See libaacs source (https://code.videolan.org/videolan/libaacs/-/blob/master/src/libaacs/mmc.c#L74) for reference.

Apologies for being so late to notice this, but is this instruction directed at me, or just advice for nalor to potentially solve my issue? Because despite the new version my issue still persists and I continue to get error 1605 when attempting to use FindVUK with UHDs just as described in my earlier post.

[mick0]

Apologies for being so late to notice this, but is this instruction directed at me, or just advice for nalor to potentially solve my issue? Because despite the new version my issue still persists and I continue to get error 1605 when attempting to use FindVUK with UHDs just as described in my earlier post.

It's directed to nalor. I'm getting that same error with LG WH16NS60.

If you want FindVUK to work and validate UHD entries with this drive, the only workaround I know is to use old FindVUK with DriveCheck disabled and remove BE with makemkv.

[SamuriHL]

Just a heads up. DVDFab 13 was just released and they changed the logging a bit. They also somewhat changed the timing of writing the log so that's fun, too. I suspect FindVUK is likely affected but I don't know for sure.

[nalor]

Yea it's not for one of my discs. Someone else has the disc and noticed the key was wrong. I'm simply trying to help correct it, given that i know what the correct key should be. We should all want the data to be as accurate as possible. Just trying to do my part to help.

The entry is already fixed.
The problem was that FindVUK did not even upload the entry to the server as in case of 2 different but unvalidated entries, it's not possible to tell which one is better and therefore no upload is performed.
The next release will check if the online entry is looking strange and in case it is' will upload the local entry as it's very likely better.
Unfortunately there are only very few "strange" entries, so this is nothing that will help to fix the majority of the wrong entries.

So I'm planning to create an option to invalidate existing entries somehow...
I'm thinking about creating API keys for selected users that allow to perform this modifications, I don't like the idea that everybody can invalidate entries in the database ...

But I haven't started to add the features so it's just an idea for the moment.

[nalor]

BU40N 1.00
Pioneer which is irrelevant for this discussion as it's not supported by DVDFab anyway. :)

Now I have the same drive:)

But I haven't tried anything with it so far.

[metalsonic88]

nalor I really am sorry to pester, but do you have any idea what the error code I posted corresponds to? I assume that since it throws a code there is some sort of meaning behind it and it isn't just generic, but I really can't find anything about it. As you seem to be the only public maintainer of this project you're the only one I know of who can potentially answer this. Or if for some reason you can't find out either, can you at least weigh in on mick0's guess about the issue relating to AACS2?

For reference, this is the error code I refer to:
What exactly is AACS error 1605 when using FindVUK? Attempting to rip UHD discs always gives me this error after the Get Basic AACS Data section starts.

[SamuriHL]

The entry is already fixed.
The problem was that FindVUK did not even upload the entry to the server as in case of 2 different but unvalidated entries, it's not possible to tell which one is better and therefore no upload is performed.
The next release will check if the online entry is looking strange and in case it is' will upload the local entry as it's very likely better.
Unfortunately there are only very few "strange" entries, so this is nothing that will help to fix the majority of the wrong entries.

So I'm planning to create an option to invalidate existing entries somehow...
I'm thinking about creating API keys for selected users that allow to perform this modifications, I don't like the idea that everybody can invalidate entries in the database ...

But I haven't started to add the features so it's just an idea for the moment.

I saw the key was updated. Thanks for that! API keys is a good idea for sure.

Now I have the same drive:)

But I haven't tried anything with it so far.

Well, looking forward to when you do. :) Thanks for your hard work!

[nalor]

nalor I really am sorry to pester, but do you have any idea what the error code I posted corresponds to? I assume that since it throws a code there is some sort of meaning behind it and it isn't just generic, but I really can't find anything about it. As you seem to be the only public maintainer of this project you're the only one I know of who can potentially answer this. Or if for some reason you can't find out either, can you at least weigh in on mick0's guess about the issue relating to AACS2?

For reference, this is the error code I refer to:

Can you post the logline you're getting? The thing is I'm not assigning the error codes manually and usually I try to output a human readable name of the error directly.
In case this is missing for this logline I'd add it there and you can try again afterwards to get an idea what is going wrong.

[metalsonic88]

This is the line the console displays
Failed to init disc >AACS UNKNOWN ERROR >-1605<<

And this is likely the relevant portion of the log.
2023-10-16 01:31:17 # 74440 # [I] / / Get basic AACS data
2023-10-16 01:31:19 # 76126 # [I] / FVMAIN_Mode_FindVUK_WaitForAACS / AACS folder on disc is reachable - ValidateVUK is possible
2023-10-16 01:31:35 # 92014 # [I] bluray_aacs / BRAACS_InitDisc / Got DiscID from disc >6451406DE42B86F78AB0189A93C7EF1D69E6450B<
2023-10-16 01:31:35 # 92014 # [I] bluray_aacs / BRAACS_InitDisc / Got DateDiscId from disc >2020-06-23<
2023-10-16 01:31:35 # 92446 # [I] bluray_aacs / BRAACS_IsBDplusProtected / Directory >F:\BDSVM\< does not exist - disc is not BD+ protected
2023-10-16 01:31:35 # 92450 # [I] drive_mmc / DRMMC_GetDriveDetails / REAL DRIVE detected - FeatureSupported >1<
2023-10-16 01:31:35 # 92450 # [I] bluray_aacs / BRAACS_InitDisc / Drive is BusEncryptionCapable
2023-10-16 01:31:35 # 92453 # [E] drive_mmc / device_send_cmd_buffer / 'DeviceIoControl' - 'CHECK CONDITION' - not implemented yet
2023-10-16 01:31:35 # 92454 # [E] drive_mmc / DRMMC_Drive_ReadDriveCert / ERROR! ReportKey failed >#DRMMC_ERR_CHECK_CONDITION_UNSUP<
2023-10-16 01:31:35 # 92454 # [E] bluray_aacs / BRAACS_InitDisc / ERROR! Couldn't get drive certificate! >#DRMMC_ERR_CHECK_CONDITION_UNSUP<
2023-10-16 01:31:35 # 92454 # [E] / FVMAIN_Mode_FindVUK_GetMetaInfo_AACS / Failed to init disc >AACS UNKNOWN ERROR >-1605<<
2023-10-16 01:31:35 # 92574 # [I] / FVMAIN_Mode_FindVUK_CloseDVDfab / CloseAtTheEnd is active, close DVDfab now

If you want the whole log you can find it here: https://pastebin.com/HjuGi8vs

---

Edit: I'll add all the possibly relevant info that I and mick0 have posted so far just to consolidate it.

It is an official drive, specifically LG-WH16NS60, but it has been flashed with libredrive. I've used this same drive in the past on UHDs with no issue, but trying it again now, even on discs I'm certain worked before, gives that error.

For further context, DVDFab itself and MakeMKV seem to have no issues with UHDs. I can even play them with VLC so long as I skip the menus.

I get this too with LG WH16NS60 FW 1.00 + UHD disc. It did work before the BE validation was added. AFAIK DVDfab won't work with FW 1.01 or later.

This is just a guess, but it could be caused by FindVUK attempting to read AACS drive certificate for DriveID calculation when AACS2 is active. If this is the case then FindVUK should probably read AACS2 drive certificate on UHD official drive when UHD disc is inserted.

AACS2 drive certificate can be read by changing the Key Class from 02h to 03h. In fact all AACS2 authentication related MMC commands should use Key Class 03h. See libaacs source (https://code.videolan.org/videolan/libaacs/-/blob/master/src/libaacs/mmc.c#L74) for reference.

[SamuriHL]

Don't worry. If nalor tests his new bu40n drive, he'll see that error first hand. It happens with official uhd drives.

Sent from my SM-G998U1 using Tapatalk

[nalor]

Thanks for the infos! Took me a while, but finally I've found a quite recent "INF-8090" documentation including the required AACS2 informations - this make it easier to support it properly :D
Will post an update during the next days.

[SamuriHL]

That's awesome!

[nalor]

Here is a 1.68 to test AACS2: http://fvonline-db.bplaced.net/findvuk/FindVUK_1.68.zip

But note I only added basic support (reading drive certificate is now working) - for the next enhancements I need your support ;)

Passkey does not support my BU40N Libredrive (I think it only supports UHD friendly drives) and so it would be great to get a small explanation how to get VolumeId, MediaKey, VUK, UnitKeys or something like that from this drive :D

Thanks!

[SamuriHL]

I'm not sure you can. There's no publicly known device keys for AACS 2.x. The only thing I've been able to get is the unit keys from DVDFab using a process similar to how FindVUK works (memory dump reading). I don't have PassKey but the process I use works with DVDFab 12/13 and PlayerFab with official drives. But it only can pull the unit key and nothing more. I don't know of a way to get the rest. I mean, MakeMKV can get the VolumeID when LibreDrive is enabled. But that's not super useful without the Media Key.

[mick0]

Passkey does not support my BU40N Libredrive (I think it only supports UHD friendly drives) and so it would be great to get a small explanation how to get VolumeId, MediaKey, VUK, UnitKeys or something like that from this drive :D

DVDFab should support this drive if you downgrade the firmware to so called "DE" firmware. E.g. DVDFab supports LG WH16NS60 FW 1.00, but not any later firmwares.

When your drive has a firmware that is supported by DVDFab, FindVUK should be able to dump unit keys and read data key from DVDFab.

Reading volume id using the official way (libaacs, aacskeys) on AACS2 drive one would need to have a valid AACS2 host certificate and for calculating media key one would need to have a working AACS2 device key or processing key. No AACS2 HC, DK or PK have been published.

[SamuriHL]

No no no do not try to cross flash that drive! It's not a desktop drive. You will brick it.

You can downgrade it to bu40n 1.00 which is what I use. Fully compatible with dvdfab.

Sent from my SM-G998U1 using Tapatalk

[mick0]

No no no do not try to cross flash that drive! It's not a desktop drive. You will brick it.

You can downgrade it to bu40n 1.00 which is what I use. Fully compatible with dvdfab.

Yes, do not cross flash it with a desktop drive FW.

Just downgrading it to "friendly" FW should be enough. So called "MK" firmware is not friendly.

[SamuriHL]

Yes, do not cross flash it with a desktop drive FW.

Just downgrading it to "friendly" FW should be enough. So called "MK" firmware is not friendly.

Well, there's a bit of a mix-up in terminology here. The bu40n is not a "friendly" drive, even when downgrading to 1.00. It's still official. VS a friendly drive that is not meant to be used for UHD but has the ability to due to m-disc compatibility. I know this is somewhat semantics but it helps to be clear on this point in the case of the bu40n. It will always be an official drive rather than friendly with any firmware that's flashed.

MK firmware can be friendly depending on the drive. And it can be official depending on the drive. I think your use of friendly in this case refers strictly to whether it works with DVDFab, which none of the MK firmware does.

[mick0]

Well, there's a bit of a mix-up in terminology here. The bu40n is not a "friendly" drive, even when downgrading to 1.00. It's still official. VS a friendly drive that is not meant to be used for UHD but has the ability to due to m-disc compatibility. I know this is somewhat semantics but it helps to be clear on this point in the case of the bu40n. It will always be an official drive rather than friendly with any firmware that's flashed.

MK firmware can be friendly depending on the drive. And it can be official depending on the drive. I think your use of friendly in this case refers strictly to whether it works with DVDFab, which none of the MK firmware does.

Like you said, it depends how you define friendly. If you define it "not an official drive, but can read UHD discs" then it is like you said.

My definition of friendly is "allows bypassing bus encryption without needing a host certificate or drive hacks like LibreDrive". By that definition BU40N is a friendly drive. Whether it's an official drive or not is irrelevant.

[SamuriHL]

As long as it's clear it's all good. :)

[metalsonic88]

1.68 seems to work for me. The second UHD I tested it with, Scott Pilgrim vs. the World, initially gave an error saying the unit key was invalid and none of the files on it could be decoded, but after restarting FindVUK and DVDFab it then worked properly. I have 7 UHDs and that was the only one that had any issues at all. If there's more that I can do to help with any testing using my drive let me know. And thank you once again for fixing another problem that I brought up.

For the sake of posterity I have a (slightly edited for file size) copy of the log generated when reading these UHDs uploaded to pastebin here: https://pastebin.com/rZHrFyz2

---

Off topic, but now that this has been sorted out I've been able to narrow down what exactly is failing when I try to play UHDs directly from the drive with VLC. If you too are experiencing issues with that and want to read my post about it on the VideoLAN forums you can do so here (https://forum.videolan.org/viewtopic.php?f=2&t=160098).

[magician]

Off topic, but now that this has been sorted out I've been able to narrow down what exactly is failing when I try to play UHDs directly from the drive with VLC. If you too are experiencing issues with that and want to read my post about it on the VideoLAN forums you can do so here (https://forum.videolan.org/viewtopic.php?f=2&t=160098).

If it's MakeMKV that you need to run before playing the disc, then you probably haven't cached the ReadDataKey, which is needed to overcome bus encryption for your disc/drive, ahead of time. Both FindVUK and RDKfromMMKV (https://forum.doom9.org/showthread.php?t=184373) can do that for you.

Here is a 1.68 to test AACS2: http://fvonline-db.bplaced.net/findvuk/FindVUK_1.68.zip

But note I only added basic support (reading drive certificate is now working) - for the next enhancements I need your support ;)

Thanks for all your hard work on this program, nalor. I've read the last few pages of posts but I didn't quite follow what you have changed in 1.68, probably because the previous versions already work for my UHD setup (I have a UHD-friendly drive).

Are the new updates intended to improve support for UHD-official drives on "friendly" firmware? (I also have a UHD-official drive but it doesn't have such firmware so I probably can't test this.)

Just released 1.67 with the fix for this bug.

Thanks! The synchronize mode works great now.

Bug 1: you're right - already found the the place, will fix it tomorrow
Bug 2: already fixed locally, based on my research I'd say this never worked correctly ...

Feature request: will check tomorrow :)

Did you ever have a chance to look at this bug #1 and the feature request again? No rush but it would be great to have a fix after you finish with the UHD drive concerns.

[metalsonic88]

If it's MakeMKV that you need to run before playing the disc, then you probably haven't cached the ReadDataKey, which is needed to overcome bus encryption for your disc/drive, ahead of time. Both FindVUK and RDKfromMMKV (https://forum.doom9.org/showthread.php?t=184373) can do that for you.

I see that FindVUK is in fact getting an RDK for each of my UHD discs, but it seems to be saving them to the wrong location. I have my config set up to save keys to %ProgramData%\aacs but it is always saving the rdk files to %AppData%. I presume this is a bug.

However, even after duplicating all the data in both locations, I still can't play these discs. I don't want to derail the thread too bad, so if this isn't the place to discuss it then I'll take it elsewhere. But if people think it's relevant then I'd love any other ideas about what might be going wrong here.

[mick0]

However, even after duplicating all the data in both locations, I still can't play these discs.

I assume you're using libaacs?

If so, then libaacs needs to be patched to use AACS2 drive certificate as a drive id similar to FindVUK. I'm not sure whether this discussion belongs to this topic though.

[nalor]

Here is a 1.68 to test AACS2: http://fvonline-db.bplaced.net/findvuk/FindVUK_1.68.zip

But note I only added basic support (reading drive certificate is now working) - for the next enhancements I need your support ;)

Passkey does not support my BU40N Libredrive (I think it only supports UHD friendly drives) and so it would be great to get a small explanation how to get VolumeId, MediaKey, VUK, UnitKeys or something like that from this drive :D

Thanks!

I noticed my changes are not really correct ... this release does not check if the current disc is BD or UHD and this very likely breaks support for BusEncryption with ReadDataKey (I always try to get an AACS2 drive certificate - but it fails in case a BD is in the drive).
I'll release a new "test" version with fixes hopefully tomorrow.

[MrPenguin]

Hi,

Can I assume that any entry whose comment contains "/BEE" declares that disk has "Bus Encryption Enabled", please? Because if so, then I believe these two entries would need updating accordingly:

0xD3F08E3F0C831B4858172FDC606F3520068EFF56 = OPPENHEIMER (Oppenheimer)
0x317A0AAFB05CBE1E1FB3BDF96D3B2F95C9053C20 = OPPENHEIMER_SPECIAL_FEATURES (Special Features)

I've already tried to update them myself, except my "synchronize" didn't change anything :(.

Thanks.

[nalor]

here is a new "test" release - I've added libredrive support for supported UHD drives:
when it comes to validation, "libredrive mode" is enabled -> this disables the bus-encryption and so it's easily possible for FindVUK to validate the current values.
I tried it with 1 disc and it worked (because I only own 1 UHD).

Download from here: FindVUK_1.70 (http://fvonline-db.bplaced.net/findvuk/FindVUK_1.70.zip)

Please report if it's working - thanks :)

@mick0 - it should also fix the wrong calculation of the driveid, but I did not add your 2nd idea yet as I read our message a minute ago.

[Grimsdyke]

Just tested a German and US UHD and it seem to work as you describe ! Nice.
Oh, I always wanted to ask - why does the size of the local keydb decreases in size when FindVUK loads it ? Or is it only my system where this happens ...

[SamuriHL]

I just tested it out with my bu40n drive and it worked perfectly. Very nice!

[magician]

here is a new "test" release - I've added libredrive support for supported UHD drives:
when it comes to validation, "libredrive mode" is enabled -> this disables the bus-encryption and so it's easily possible for FindVUK to validate the current values.
I tried it with 1 disc and it worked (because I only own 1 UHD).

Thanks for the update. I tried and it works, but I'm interested in a deeper explanation of what changed. For me, the "get ReadDataKey from dump and use that to bypass bus encryption" method from before already worked (?), has fewer apparent dependencies and is several seconds faster for validating the unit keys than this new approach of using LibreDrive. In other words, 1.70 is slower than 1.67, the last version I tested. I'm probably not the intended audience, but who is? Is it people like metalsonic88 and mick0 with drives that expect AACS2 authentication but still work with DVDFab because they have friendly firmware?

[SamuriHL]

They're not "friendly" drives, they're official drives. Official drives require aacs 2.x bus encryption and there are no host certs available for that. So while dvdfab is able to use certain official drives like my bu40n, with that bus encryption there was no way to validate the extracted key. With libredrive active, bus encryption is simply disabled so that validation can take place.

Sent from my SM-G998U1 using Tapatalk

[mick0]

They're not "friendly" drives, they're official drives. Official drives require aacs 2.x bus encryption and there are no host certs available for that. So while dvdfab is able to use certain official drives like my bu40n, with that bus encryption there was no way to validate the extracted key. With libredrive active, bus encryption is simply disabled so that validation can take place.

Sent from my SM-G998U1 using Tapatalk

This is not entirely accurate.

FindVUK starting from v1.68 extracts data key from DVDFab on UHD official drives such as BU40N or WH16NS60. No LibreDrive or Host Certificate is required for playback/decrypt/verify when data keys are available.

[mick0]

It seems FindVUK 1.70 now fails during validation step on my system. FindVUK 1.68 works.

Relevant part from the log
2023-12-07 00:00:00 # 40386 # [I] findvuk_validate / _CommonValidation / Disc is AACS 2.0 and BusDescryption is required -> check if MakeMKV is installed
2023-12-07 00:00:00 # 40387 # [I] bluray_mmkv / BRMMKV_CheckIfInstalledAndLicensed / MakeMKV is installed!
2023-12-07 00:00:00 # 40387 # [I] bluray_mmkv / BRMMKV_CheckIfInstalledAndLicensed / MakeMKV has a license key!
2023-12-07 00:00:00 # 40387 # [I] findvuk_validate / _CommonValidation / MakeMKV is installed -> now check if drive >D< is Libredrive supported
2023-12-07 00:00:00 # 40387 # [E] bluray_mmkv / BRMMKV_CheckSdfSupport / ERROR! Couldn't get the MakeMKVcon path! ()
2023-12-07 00:00:00 # 40387 # [E] findvuk_validate / _CommonValidation / ERROR! Couldn't check for Libredrive support! >#BRMMKV_ERR_MAKEMKV_FILE<
2023-12-07 00:00:00 # 40387 # [I] findvuk_validate / FVVAL_Mode_FindVUK / Finished with result >-2812<


I don't currently have makemkv installed on this system, but FindVUK thinks it is and tries to use it.

Can you perhaps add an config option for disabling LD support?

[SamuriHL]

This is not entirely accurate.

FindVUK starting from v1.68 extracts data key from DVDFab on UHD official drives such as BU40N or WH16NS60. No LibreDrive or Host Certificate is required for playback/decrypt/verify when data keys are available.

Nor is this entirely accurate. That may work on blu-ray but trust me, it didn't work for me on UHD's. It does now with 1.70 and LibreDrive.

[mick0]

Nor is this entirely accurate. That may work on blu-ray but trust me, it didn't work for me on UHD's. It does now with 1.70 and LibreDrive.

Well, it works on my WH16NS60 with slightly patched libaacs (UHD and BD). Using data keys is the official way to handle bus encryption after all and it is what DVDfab and PowerDVD are using for instance. It should definitely work, unless FindVUK is unable to extract the data key for your disc/drive for some reason.