Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > General > Decrypting

Reply
 
Thread Tools Search this Thread Display Modes
Old 6th May 2020, 21:09   #501  |  Link
candela
Registered User
 
Join Date: Jun 2005
Posts: 204
Quote:
Originally Posted by Bomum View Post
In all versions except the current version,
Does it mean that the feature is always disabled?
Does Other than the latest version, 11.0.8.6,
that mean the feature is disabled?
It started when DVDFab added UHD support in Passkey v9.3.0.2 early 2018. So anything newer only uses UK so FindVUK can only get UK. Maybe you can still get other keys with FindVUK using older DVDFab versions for discs with lower MKB versions (like < 60). But for those discs that maybe will work you can get all keys yourself with aacskeys using public PK and HC

Last edited by candela; 6th May 2020 at 21:33.
candela is offline   Reply With Quote
Old 7th May 2020, 07:07   #502  |  Link
Bomum
Registered User
 
Join Date: Mar 2020
Posts: 6
Quote:
Originally Posted by candela View Post
It started when DVDFab added UHD support in Passkey v9.3.0.2 early 2018. So anything newer only uses UK so FindVUK can only get UK. Maybe you can still get other keys with FindVUK using older DVDFab versions for discs with lower MKB versions (like < 60). But for those discs that maybe will work you can get all keys yourself with aacskeys using public PK and HC
Is there any problem if you have the latest Fab, FindVUK, aacskeys?
Bomum is offline   Reply With Quote
Old 7th May 2020, 09:52   #503  |  Link
Losko
Registered User
 
Join Date: Dec 2010
Posts: 28
Quote:
Originally Posted by nalor View Post
Of course I could add some kind of incremental download specifically for the synchronisation - but honestly this would be a huge rework of the current setup and I cannot afford the time for this.
Hey, this is exactly what git was designed for!
git is great when managing text files with incremental modifications, and it's very, very efficient when synchronizing local and remote copies.
What if FindVUK did:
  1. first launch? then do 'git clone', else 'git pull'
  2. do your usual stuff
  3. exiting: new entries? then do 'git push'
If I think at the keys database as a repository, then the whole scenario seems so simplified!
(and, btw, there are plenty of git hosting sites out there)
Losko is offline   Reply With Quote
Old 8th May 2020, 19:20   #504  |  Link
nalor
Registered User
 
Join Date: Dec 2013
Posts: 391
I'm not sure that GIT is really an option - because the problem is that not all changes of every user are relevant for all the other users...
Usually GIT is used in case each change is relevant for everyone else .. but in our case there might be manual changes to the file that might remove data from the repository.
And as always with systems like GIT theres always the option that merge conflicts might occur - and the only way to handle them easily would be to perform a hard-reset to the current repository.

Finally I just want to tell that the only reason for me to start the online database has been the strange disappearance of Starbuck ...

But in case someone else wants to create a better solution I've absolutely no problem to stop my current implementation or add support for the new approach to FindVUK.
nalor is offline   Reply With Quote
Old 14th May 2020, 11:23   #505  |  Link
richy
Registered User
 
Join Date: Jun 2003
Posts: 12
Hi nalor!

The upload part when submitting new keys always seems to work fine and obviously it's just the download part of a sync where the free hosting problems kick in. I was going to suggest some sort of stop-gap measure like a monthly keydb.cfg update via tinyupload.com (or similar) so people could keep relatively up to date without needing to hammer the free host so much.

However, out of curiosity I just tried a sync for the first time in ages and the speed seemed to be a lot better and I noticed that it downloaded about 11mb instead of the full 31mb and then proceeded to unpack it. Basically, I was able to do a full sync with no problems. I'm guessing you've made a few changes somewhere so a sync doesn't require so much data to be downloaded? If so, it certainly seems to be working ok at the moment.

Just thought I'd mention it in case you wanted any feedback(!?) and also thought I'd just say a quick thanks for all the work you've put in to FindVUK
richy is offline   Reply With Quote
Old 16th May 2020, 22:22   #506  |  Link
nalor
Registered User
 
Join Date: Dec 2013
Posts: 391
I've changed only something really small - but maybe this did the trick.
In the beginning the file to download has been <10MB and everything has been fine.
Than at some point in time the file got bigger than 10MB and personally I think it still worked, but later on it started to get really slow.
In parallel I noticed that when downloading the file with a browser I don't get a progress information and started to analyze why this isn't working and finally got the info from the bplaced-support that each php-interpreter is limited to 10MB of memory and as the file is transmitted by a php-file and does exceed the assigned memory size, the filesize is not available in advance any longer and therefore it's not available to the browser.
So finally I've changed the behaviour so that the php-file just takes care the file is updated in case it's necessary and afterwards there's a redirect to the file in the filesystem.
So the data is now delivered directly by the webserver and a few days after this change the download problems disappeared...

Don't know if it's really related or if it's just a coincidence - but finally everything back to 'useable'
nalor is offline   Reply With Quote
Old 2nd June 2020, 22:01   #507  |  Link
nalor
Registered User
 
Join Date: Dec 2013
Posts: 391
Just want to tell that I'm working on a better synchronization feature - I think it will speed up the sync dramatically.
Basically FindVUK will store a hash of the file after a full-sync and the date of the sync and as long as the file is not modified externally it will just request delta-files for synchronisation (such a file is around 200kb for the last 60 days).
The server part is already done - see here:
Delta File since 2020.05.04 23:00:00

In case the requested date is older than 60 days or in the future or cannot be parsed at all, the full file is offered instead. The delta file includes all entries that got either created or modified in this time area.

Next I'll implement the required changes in FindVUK - but this will take a few days.

Small note:
It's also possible to use relative deltadate attributes - e.g. this here will always return a file with all entries changed during the last 24h:
Changed entries in last 1 day

Last edited by nalor; 14th June 2020 at 22:25.
nalor is offline   Reply With Quote
Old 9th June 2020, 21:35   #508  |  Link
nalor
Registered User
 
Join Date: Dec 2013
Posts: 391
Released FindVUK 1.34 - it includes the delta-synchronization and in my small tests it's working fine.

As long as the keydb.cfg isn't modified manually the delta sync is active. To check for modifications a hash is stored in a keydb_hash.ini file together with a timestamp used for the delta-sync. The timestamp is the time of the last change in the online database - it has nothing to do with the time of the last synchronisation.

The easiest way to trigger a full-sync again is to delete this ini file.
nalor is offline   Reply With Quote
Old 12th June 2020, 03:57   #509  |  Link
Roof Tile
Registered User
 
Join Date: Jun 2020
Posts: 4
Wanted to say thanks for your efforts to help expand the control people have over their material. You, candela, mick0, and many more have allowed me and others to overcome some of the key issues with owning Blu-rays and you all have my gratitude for that.

Beyond the simple thanks, I believe I have something that might be of interest to you. I've been using your program to get the various codes and keys and whatnot from my own Blu-rays uploaded to the main database you have. However, a strange error occurred when I used it on my copy of "The Usual Suspects". It was the first movie I had to enter the name for manually and it seemingly didn't like that. However, I then had to do the same for "Total Recall" and that went just fine without any weird error.
Don't really know what the issue is but I thought you'd maybe find it helpful. Just in advance, I hope I got the right parts for this for you to look at and sorry if I didn't.
*Wanted to use the scrolling CODE phrasing to put it up here and have a nicer flow, but it would have taken multiple posts so I just put it on TinyUpload instead as a RAR.*

Tiny Upload Link: http://s000.tinyupload.com/?file_id=...36899647016775

PS. I replaced my account name with *Account Name* in the logs. Hope that's ok.
Roof Tile is offline   Reply With Quote
Old 13th June 2020, 21:26   #510  |  Link
nalor
Registered User
 
Join Date: Dec 2013
Posts: 391
This problem is one I already know -but I still don't know how to solve it properly. The uploads from findvuk are directly processed and written to the database, this is working fine as long as everything is in perfect condition.
But with discs that require a manual title input there might be the chance that it already got uploaded previously with a different title. In the current example the disc got uploaded the first time at 23.03.2019 with a title 'THEUSUALSUSPECTS' and now you're entering another title 'The Usual Suspects' and finally my script only knows that those are not equal - but cannot decide which title is better and therefore the 'manual processing required' result is returned.

All those uploads are now flagged with 'manual processing required' and from time to time I'll check them manually and decide what to do.

But I think it might be an improvement to still report it as success instead of showing an error....
nalor is offline   Reply With Quote
Old 14th June 2020, 18:42   #511  |  Link
Roof Tile
Registered User
 
Join Date: Jun 2020
Posts: 4
Ah got it. Thanks for looking into it and for the succinct explanation!

-----Didn't want to make two posts one after another so I'm just editing this one-----
Encountered a new error. I used the program on my Guardians of the Galaxy and Star Trek The Motion Picture Blu-rays (the Star Trek one is from that big 50th Anniversary collection in case that matters) but it spit out an error at the end about something involving a "hash file". I think the uploads for both of the discs to the database went fine, as the log says that they did. However, I wanted to let you know before I continued doing any more discs just in case it was something important that could corrupt the data or something.

Just in case these details matter, I updated Passkey from 9388 to 9389 (the logs say that's ok but I just wanted to let you quickly know), I got a new version of the KeyDB (6-14-20) before I used the program with my discs to make sure it was as up to date as possible before adding new entries, and updated my VUK program to the new 1.34 version by extracting everything in the folder and letting it overwrite everything it wanted.

Here's a link to the Tiny Upload of the Logs: http://s000.tinyupload.com/?file_id=...97325744329857

Last edited by Roof Tile; 14th June 2020 at 20:10.
Roof Tile is offline   Reply With Quote
Old 15th June 2020, 22:44   #512  |  Link
nalor
Registered User
 
Join Date: Dec 2013
Posts: 391
Thanks for reporting!
Just checked my code and I think it's a stupid error from my side. At the end of each scan it tries to update the stored hash of the keydb.cfg file so that it's still detected as 'unchanged' - but this is only possible in case the hash-file is really available.
I never tried it without this file ... and I guess this is the situation in your case.

Please either:
  • execute a synchronization - this should create the file automatically
  • or create an empty textfile named 'keydb_fvhash.ini' next to the keydb.cfg file

I think both options should help.

I'll fix the bug with the next release.
nalor is offline   Reply With Quote
Old 15th June 2020, 22:52   #513  |  Link
Roof Tile
Registered User
 
Join Date: Jun 2020
Posts: 4
Glad to help and will do! Just to ask though, what does the hash-file do exactly? Do I need to redo my previous disc reads to make sure they have everything correct, or is it an "extra" sort of thing to make things easier for collecting info or uploading things?
Roof Tile is offline   Reply With Quote
Old 16th June 2020, 06:07   #514  |  Link
nalor
Registered User
 
Join Date: Dec 2013
Posts: 391
Quote:
Originally Posted by Roof Tile View Post
Glad to help and will do! Just to ask though, what does the hash-file do exactly? Do I need to redo my previous disc reads to make sure they have everything correct, or is it an "extra" sort of thing to make things easier for collecting info or uploading things?
Hash file is a new thing that is only used for the improved synchronisation, it has nothing to do with the result of a disc read.

So there is really no need to redo your reads.

Gesendet von meinem H8324 mit Tapatalk
nalor is offline   Reply With Quote
Old 16th June 2020, 13:40   #515  |  Link
Roof Tile
Registered User
 
Join Date: Jun 2020
Posts: 4
Ah got it. Thank you for the explanation.
Roof Tile is offline   Reply With Quote
Old 25th June 2020, 20:52   #516  |  Link
Buck
Registered User
 
Join Date: Mar 2019
Posts: 18
I came across a bug in the new version. Apparently, when writing to the "keydb" file, FindVUK 1.34 was looking for uppercase letters "KEYDB". I had lowercase letters "keydb" and it failed that operation with:

13:11:55 - Successful upload to OnlineDB
13:11:56 - ERROR! Couldn't open hash-file >C:\Users\***\AppData\Roaming\aacs\keydb_fvhash.ini<
13:11:56 - ERROR! Couldn't update hash file >C:\Users\***\AppData\Roaming\aacs\KEYDB.cfg<
13:11:56 - Eject the disc now from drive >E:\<


When I changed my keydb.cfg to uppercase "KEYDB.cfg", it completed that operation with:

13:19:38 - Successful upload to OnlineDB
13:19:38 - Eject the disc now from drive >E:\<

Also, I don't see a "keydb_fvhash.ini" file in my directory. So it doesn't create one when there is none. That's a problem, too.

Last edited by Buck; 26th June 2020 at 16:57.
Buck is offline   Reply With Quote
Old 29th June 2020, 17:10   #517  |  Link
nalor
Registered User
 
Join Date: Dec 2013
Posts: 391
Quote:
Originally Posted by Buck View Post
I came across a bug in the new version. Apparently, when writing to the "keydb" file, FindVUK 1.34 was looking for uppercase letters "KEYDB". I had lowercase letters "keydb" and it failed that operation with:

13:11:55 - Successful upload to OnlineDB
13:11:56 - ERROR! Couldn't open hash-file >C:\Users\***\AppData\Roaming\aacs\keydb_fvhash.ini<
13:11:56 - ERROR! Couldn't update hash file >C:\Users\***\AppData\Roaming\aacs\KEYDB.cfg<
13:11:56 - Eject the disc now from drive >E:\<


When I changed my keydb.cfg to uppercase "KEYDB.cfg", it completed that operation with:

13:19:38 - Successful upload to OnlineDB
13:19:38 - Eject the disc now from drive >E:\<

Also, I don't see a "keydb_fvhash.ini" file in my directory. So it doesn't create one when there is none. That's a problem, too.
Hi! I think it's not related to the case of the filename - the uppercase 'KEYDB.cfg' in the error message is just because the filename is created internally and I wrote it uppercase there

So I guess when you rename back to 'keydb.cfg' it's also working - very likely it's been a problem with the first run.
nalor is offline   Reply With Quote
Old 29th June 2020, 20:42   #518  |  Link
nalor
Registered User
 
Join Date: Dec 2013
Posts: 391
Uploaded a new release 1.35

It includes 2 changes:
-> FIX for the error message when using without synchronization
-> an auto-update function I know it's not really required because I don't update that often - but I wanted to try and I think it's working well, at least in my tests.

It can be disabled in the ini-file.

Additionally I've linked to the website of the online-database for download instead of using tinyupload.
nalor is offline   Reply With Quote
Old 3rd July 2020, 22:13   #519  |  Link
ZampNoxis
Registered User
 
Join Date: Jun 2020
Posts: 3
This is my first time using this forum, so I apologize if this isn't the proper thread to post this. I have some VUKs that aren't in the online database and would like to add them to my local keydb.cfg file and upload those changes to the online database for others to use. I obtained these VUKs by adding the DKs, PKs, and HCs from this post to my local keydb.cfg file and playing the Blu-rays in VLC: https://forum.doom9.org/showthread.p...55#post1883655

The VUKs for each disk showed up in AppData\Roaming\aacs\vuk. However, I don't know how to go about doing the proper formatting for the disk title, the VUK, and all the other necessary entries to match the existing entries in keydb.cfg. Do I have to manually input everything in my local keydb.cfg file or is this formatting usually done automatically by FindVUK when using it with a DVDfab program?
ZampNoxis is offline   Reply With Quote
Old 3rd July 2020, 23:26   #520  |  Link
qyot27
...?
 
qyot27's Avatar
 
Join Date: Nov 2005
Location: Florida
Posts: 1,193
This is the per-disc key backup script I use. Grew out of a solution I used prior to switching to FindVUK, but then repurposed to pretty-print things and continue to make sure that I have backups of the keys for the discs I actually own.
Code:
#!/bin/bash

VOLUMEDRIVE="$(ddwin64 --list 2>&1 > /dev/null | grep -A1 CD-ROM | grep Mounted | tail -c4)"
VOLUMENAME="$(cmd //c "vol $VOLUMEDRIVE" | grep "Volume in drive" | sed 's/is/\t/' | cut -f2 | sed 's/^ //')"
echo "$VOLUMENAME" > "$VOLUMENAME.aacsinfo.txt"
aacs_info "$VOLUMEDRIVE" >> "$VOLUMENAME.aacsinfo.txt"
DISCID="$(aacs_info "$VOLUMEDRIVE" | grep "Disc ID" | cut -f2 -d : | sed 's/ //g')"
VID="$(aacs_info "$VOLUMEDRIVE" | grep "VID" | cut -f2 -d : | sed 's/ //g')"
#VUK="$(cat $(echo $APPDATA\\aacs\\vuk\\$DISCID) | tr '[:lower:]' '[:upper:]')"
MEDK="$(aacs_info "$VOLUMEDRIVE" | grep -w "MK" | cut -f2 -d : | sed 's/ //g')"
FULLKEYS="$(cd "/e/Programs/aacskeys/bin/win64/" && aacskeys.exe "$VOLUMEDRIVE" v "$VID")"
VUK="$(cd "/e/Programs/aacskeys/bin/win64/" && aacskeys.exe "$VOLUMEDRIVE" "$VID" | grep "Volume Unique Key" | cut -f2 -d : | sed 's/ //g')"
MKB="$(grep MKB "$VOLUMENAME.aacsinfo.txt" | cut -f2 -d : | sed 's/ //g')"
fromdos "$VOLUMENAME.aacsinfo.txt"
sed -i  '/VID/aVUK    : '"$VUK"'' "$VOLUMENAME.aacsinfo.txt"
todos "$VOLUMENAME.aacsinfo.txt"

grep $DISCID "$APPDATA\\aacs\\KEYDB.cfg" > "$VOLUMENAME.keydb.txt"

mkdir -p aacsbk/vuk
echo "$VUK" > aacsbk/vuk/"$DISCID"

echo "$FULLKEYS" > "$VOLUMENAME.fullkeys.txt"

echo "0x$DISCID = $VOLUMENAME | V | 0x$VUK | M | 0x$MEDK | I | 0x$VID ; MKBv$MKB" > "$VOLUMENAME.keydb_forinsert.txt"
Requires ddwin, aacs_info (with working PK/DK/Cert in KEYDB.cfg), aacskeys (with working keys/cert in the right files), and standard GNU userland on Windows (MSys2, or maybe Cygwin if you change the paths to account for Windows drives being under /cygdrive there).

Note: it does use the old key order, but FindVUK adjusts it when it verifies the info. It also assumes aacskeys resides in E:\Programs\, so adjust that accordingly, especially if on something other than Windows.

Run the script first, see what differs between the *.keydb.txt and *.keydb_forinsert.txt. If the plain keydb output either lacks some keys or has NOTVALIDATED / LEGACY, then copy the line (or just the missing parts of the line) from _forinsert.txt into the main keydb.cfg.

Then optionally run FindVUK to let it fix things up (maybe just Synchronize if you don't care about some of the meta stuff), and then to re-verify, run the above script again and compare the *keydb/*forinsert files again to ensure things look okay.

The script is a little older, obviously; with libaacs allowing the MK cache and such now, those values could probably be read out a lot easier than they had to be at the time (although since the VUK isn't printed by aacs_info, that still needs aacskeys).
qyot27 is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 10:42.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.