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

[nalor]

Originally Posted by magician

The main issue I reported earlier 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]

Originally Posted by magician

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]

Originally Posted by magician

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]

Originally Posted by nalor

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]

Originally Posted by SamuriHL

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]

Originally Posted by SamuriHL

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]

Originally Posted by magician

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]

Originally Posted by nalor

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]

Originally Posted by nalor

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]

Originally Posted by SamuriHL

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]

Originally Posted by magician

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]

Originally Posted by nalor

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]

Originally Posted by mick0

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

Originally Posted by metalsonic88

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]

Originally Posted by SamuriHL

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]

Originally Posted by SamuriHL

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.