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

[nalor]

Released FindVUK 0.65 - it should fix all problems reported by shadowofdarkness and has a few additional features

After the last keydb update of Starbuck2010 I noticed there are a few discs with volumename 'BDROM' - as this isn't that meaningful I implemented a new feature that reads the movie-title from the meta-files on the disc.
The metafiles can be available for different languages - and so I've introduced 2 new ini parameters for this feature:

Section 'BlurayMeta'

• PreferredLanguages - this allows to specify an order of preferred languages, e.g. 'deu,fra,ita,spa,eng' means that it should try to read at first the german title, in case it's not available read the french title, next the italian title, ... in case this parameter is empty it always tries to read the english title and when this isn't available it simply takes the first meta file available. so usually you only have to specify your own language (in case it's different from english) and not a complete list
• AlwaysAddMetaTitleToVolumename - usually the meta-title is only added to the volumename in the keydb-file when the volumename is 'BDROM' - when you set this parameter to 1 it is always added

(Update 201510111: I've checked FindVUK 0.80 with my complete bluray-library and there are the names of all languages that I've found on my discs:

• ces = czech
• deu = german (also found 'gem' on IceAge3 that is also german - taking care of it internally in FindVUK)
• eng = english
• fra = french
• hun = hungarian
• ita = italian
• jpn = japanese
• nld = dutch
• pol = polish
• rus = russian
• spa = spanish
• tur = turkish

So basically I think the ISO 639-2/T 3 character codes are used: Wikipedia-List_of_ISO_639-1_codes
)

When the meta-title is added to the volumename it is surrounded by parenthesis - e.g. BDROM (This is the Meta-Title)
In case the volumename is BDROM but no meta-files are available on the disc (as it is for example on the Resident Evil bluray) FindVUK asks you to input the Movie Title manually - in this case it is added to the volumename and surrounded by square brackets - e.g. BDROM [Resident Evil]

The next thing I noticed when studying the post from Starbuck2010 is that the comments field in the keyfile is limited to 40 characters - so I shortened everything that FindVUK writes in the comment section to stay within this limit:

• changed all ' - ' separator to '/'
• changed 'BusEncrEn' to 'BEE'
• changed 'MKBrev xx' to 'MKBvxx'
• changed 'VUKNOTVALIDATED!!' warning to 'VUKNOTVAL!'

>> at the moment even in the worst case it should not exceed 38 characters (e.g. MKBv99/BD+/BEE/VUKNOTVAL!/FindVUK 0.65)

And a few bugfixes - the biggest is a correction to a stupid mistake - although I already had a loop to try all available unit-keys I stopped the loop when the first one didn't match...

@shadowofdarkness: please report if it really corrects all your problems - thanks

[shadowofdarkness]

v0.65 fixed both problems. Thanks.

[Neph]

I'm currently trying to get the VUK of a few german blu-rays with the DVDFab Media Player and version 0.65 of FindVUK.

For "Maze Runner": I opened FindVUK, agreed to the Eula, it then opened the media player on its own and I started the playback but when I then started FindVUK again, it only gave me the following error message:
Error! Couldn't open the DVDfab logfile......
ERROR, couldn't follow the logfile properly

I then created the dumpfile manually, opened it with TextPad and there's really some kind of VUK after the disc ID (disc ID, a few random symbols, path of the Temp folder, then the kinda VUK twice) but it's too long compared to the VUKs in the KEYDB.cfg file.
I already tested it with a few other blu-rays (Mama, RED 2, Paranormal Activity: The Marked Ones, Resident Evil: Retribution, Iron Man 3) but it always gave me the same error message in your program and it didn't even put any kind of VUK into the dump file. VLC still can't read the BRs and acts like it's simply missing the VUK. The DVDFab Media Player can play them just fine and it always got the VUK according to the logfile but, like I said, I can't find the actual VUK to add those blu-rays to the database.

Any recommendations, what I could do to fix it and/or find the real VUK?

[nalor]

Hi!
When you start FindVUK - does it print the correct filename for the Mediaplayer-Logfile?

In my case I get this Information displayed directly after the start:

-----------------------------------------------------------
2015.09.27 18:27:34 - ----------- FindVUK yyy -----------
-----------------------------------------------------------
2015.09.27 18:27:34 - SettingsFile: >C:\FindVUK\config\FindVUK.ini<

2015.09.27 18:27:34 - MediaPlayer is preferred and available!
2015.09.27 18:27:34 - MediaPlayer-MainFile: >C:\Program Files (x86)\DVDFab Media Player 2\FabPlayer.exe<
2015.09.27 18:27:34 - MediaPlayer-LogFile: >C:\Users\xxx\Documents\DVDFab Media Player\\win_player.log<
2015.09.27 18:27:34 - KEYDB-Path: >C:\Users\xxx\AppData\Roaming\aacs<
2015.09.27 18:27:34 - ProcDumpFile: >C:\FindVUK\tool\procdump.exe<

So in my case it detected 'C:\Users\xxx\Documents\DVDFab Media Player\\win_player.log' as the logfile of MediaPlayer - can you check if the logfile that is shown in your case is the correct one? Does it really exist?
(I just noticed the double \\ in the path, this is fixed in the next version, but I'm not aware of any problems related to this issue)

And another question - as far as I know MediaPlayer isn't working at the moment due to the changes of the server software from dvdfab: DVDfab Forum: Media Player Pro refuses to open blu-rays

Can you still watch Blurays with MediaPlayer on your computer?

[Neph]

Here's what it shows me with R.E.D. 2:

2015-09-27 20:12:23 # 23097840 # ----------- FindVUK 0.65 -----------
2015-09-27 20:12:23 # 23097842 # SettingsFile: >C:\xxx\FindVUK\config\FindVUK.ini<
2015-09-27 20:12:23 # 23097844 # Information! Passkey MainApp is not valid! >< - please check if it is installed properly!
2015-09-27 20:12:23 # 23097846 # Information! DVDfab MainApp is not valid! >< - please check if it is installed properly!
2015-09-27 20:12:23 # 23097848 # Preferred application is not available
2015-09-27 20:12:23 # 23097850 # MediaPlayer is available!
2015-09-27 20:12:23 # 23097851 # MediaPlayer-MainFile: >C:\Program Files (x86)\xxx\DVDFabMediaPlayer2\FabPlayer.exe<
2015-09-27 20:12:23 # 23097853 # MediaPlayer-LogFile: >C:\Users\xxx\Documents\DVDFab Media Player\\win_player.log<
2015-09-27 20:12:23 # 23097854 # KEYDB-Path: >C:\Users\xxx\AppData\Roaming\aacs<
2015-09-27 20:12:23 # 23097856 # ProcDumpFile: >C:\xxx\FindVUK\tool\procdump.exe<
2015-09-27 20:12:23 # 23097859 # No running application process discovered - start it now >C:\Program Files (x86)\xxx\DVDFabMediaPlayer2\FabPlayer.exe<

The problem I described in my last post occured on September 21st but since you have to be a member for at least 5 days until you can write posts, I posted it today.
Yes, the file does exist but the Windows explorer can't open it with the double backslashes, when I copy the path into the address field. If I use just one, it can open the file just fine.
But no, I can't watch BRs with the media player atm. It did work on September 21st, though.

[nalor]

Released 0.67 - includes only a few changes, one of them is to create a backup of each discovered VUK in the subdirectory VUKbackup, this is to keep a backup of the result including the comment and the title - at the moment those details are lost in case the 'main' keydb.cfg is synchronized to the master-database and there's an older entry of the same disc present in the master-file without title and comment.

I noticed that sometimes even with MediaPlayer and DVDfab9 it happens that the disc is not accessible to validate the VUK - in this case FindVUK will automatically close the application so it can continue without asking the user to close the application.

Finally a small bugfix - the path to the logfile for MediaPlayer and Passkey included a double-backslash, although I never noticed any problems with it, it's corrected now

[nalor]

@Neph: I think I've found your problem

The default path to the mediaplayer logfile in the ini file seems to be wrong - I just managed to reproduce your problem with a fresh mediaplayer installation
What is happening is the following: when you install mediaplayer only a few registry entries are written, for all the other values mediaplayer simply uses it's internal 'default' values.
So directly after a fresh installation of mediaplayer there's no special registry entry to read the 'logfolder' - and as a fallback I use the value from the ini file.
The entry from the ini file looks like this:

%userprofile%\Documents\DVDFab Media Player\Log

but should be this:

%userprofile%\Documents\DVDFab Media Player

To fix your problem you have 2 options:

1. edit the ini-file and remove the '\log' from the end
2. open the mediaplayer settings and simply press OK - this way the logfolder entry is written to the registry

In 0.67 the logfile shows a little bit more details about the logfinding process - so I guess when you start the 0.67 without executing step 2 from above you'll find a line like this in the logfile:

2015-09-27 22:49:28 # 377650 # Couldn't read MediaPlayerLogDir from registry - take the info from the ini file

As Mediaplayer isn't working at the moment I'd recommend DVDfab9 to you - as long as you don't use the DVDfab 'main' functions like decoding the content the trial period will never start so it will never expire but nevertheless decrypt the bluray to get the vuk

PS: in the next release the default path for the mediaplayer log in the ini file will be correct

[nalor]

Decided to create a new release with the fix immediatly - because it definitely is a show-stopper for first-time users

In case the ini-parameter is still set to the wrong entry it's changed to the correct entry.

So 0.68 is now available in the first post.

Kudos to Neph for finding this bug!

[avih]

@nalor, v0.68 is detected with 4 threats from 41 engines - https://www.metascan-online.com/#!/r...0cfbf3/regular

I hope that these are false positives, but I can't tell for sure and I don't intend to dig into it to find out. I think it'd be best if you could find a proper external host to place your files at.

[nalor]

Hi, just checked your results and as far as i can see 3 of the 4 hits are related to the automatic download of the dump Tool from sysinternals.
Couldnt find details about the last of the 4 results at the moment.
Will check all of them tonight after work.
Regarding the file hoster, i dont care which one i am using. Make a suggestion :-)
I upload every release also directly into the forum, but it takes about a week until the forum file gets the admin approval and this is the reason why i am uploading the file also to a different location.

As i know that there are is no malware hidden in my tool i am sure all 4 hits are false positives.

Will post a hash value for all releases tonight, so everybody can check if his download is really untouched ;-)


Gesendet von meinem D5803 mit Tapatalk

[nalor]

Released 0.70 with a few bugfixes and new features - for details take a look at the first post.

Unfortunately I haven't found time to check for the 4 threats...

Edit: I compiled a release where I've simply removed the download option but it didn't make a change - need to check tomorrow what is really the problem with those false positives (in case they find 4 threats in a fresh compiled exe those alerts are false positives for sure... ) so I can also say that the file-hoster file-upload.net isn't respoonsible for those 4 detected problems ...
It has to be something special in the compiler I'm using...

[avih]

Originally Posted by nalor

Regarding the file hoster, i dont care which one i am using. Make a suggestion :-)

Open source your code, put it on github, and use github releases to host your releases. Or just pay for some host and put up a web page for this application. Or find a free one. Really, up to you.

Originally Posted by nalor

I upload every release also directly into the forum, but it takes about a week until the forum file gets the admin approval and this is the reason why i am uploading the file also to a different location.

Because admins don't approve attachments daily.

Originally Posted by nalor

As i know that there are is no malware hidden in my tool i am sure all 4 hits are false positives.

I didn't say it was malware, just that the scan found threats and I don't intend to dig into it. Also, if you had malicious intents (which I believe you don't, but still), then your response would have been the same, something like "yeah, they're all false positives, go ahead and use it".

Bottom line, we don't have the resources to validate which threats are false positives, discuss it with authors which upload executables, and put the time into figuring out whether or not it's actually a threat.

Just find a proper external host for your files, free or payed-for or github, and use it as the main distribution for your releases.

[Sparktank]

If you go open-source, there's also a greater chance that someone might be able to see what's causing the false-positives.

In most cases like this, for freeware tools, it's usually come down to the installer itself.

But, you would need to be more open for others to volunteer to look into things.

I'm no dev, but just what I see in most cases.

[avih]

Ultimately, this is a forum for discussions. It's not a free hosting service for applications, and especially not a free hosting service for closed source applications.

Occasional attachments are fine when they contribute to the discussion, preferably that they're not executable.

We also approve the occasional executable attachment when we feel it's appropriate, maybe because they're posted by credible and respected members of the community, or are some test releases of well known small software packages, or are binaries which are hard to find otherwise because thy're not maintained anymore, or just when we feel it's appropriate.

Your application is being actively developed and you do frequent releases, which is great, but please don't use this forum as the main hosting platform for your close source application.

Discussing it here and posting links to new releases, however, is absolutely fine, and very appropriate.

[nalor]

Just want to report that I've spent some time investigating the 'Malware' issue and my first result is that I've sent false-positive-reports to Baidu and Filseclab.

Finally I've reduced my source to this quite useless piece of code but those 2 engines still detect a threat in it:

Procedure.s Test1(iNumber.i)
ProcedureReturn "result1"
EndProcedure

Procedure.s Test2(iNumber1.i, sString1.s, sString2.s)
Test1(234)
ProcedureReturn "result2"
EndProcedure

Procedure Test2 calls procedure Test1, but Test2 itself is never called... so this does really nothing and is still detected as threat. But when the call from Test2 to Test1 is removed, the compiled result is considered harmless
I'm using purebasic 5.31 x86 - just in case you want to reproduce my results.
Test Result of the Metascan

Unfortunately procedures are quite often called from other procedures in purebasic - so it's really impossible to get a green result in a purebasic application that really does something useful...

So I'm waiting to get feedback from both malware-detection-engines and when they've fine tuned their detection algorithm I'll continue my work to get a 'green' state on https://www.metascan-online.com

Hope this is acceptable for everybody

[nalor]

And a few words about the hosting issue and going open source:

The only reason why I'm uploading the files also into the forum because I already noticed that files from older threads that have been uploaded to various other locations on the internet are sometimes really hard to find, very often the original hoster is not available any longer and hopefully a copy of the wanted file can be found with the help of google... so I thought that because my app is really small I simply upload it to forum so it will never get lost

Going open source is still an option - but as the response in the forum here isn't that overwhelming I think the interest in the tool isn't that big at all and as I mentioned already in the first post: reduced to the basics my tool is simply a small convenience-tool that can easily be replaced by 5 minutes of handwork, so in case someone fears that my tool is doing evil things with his computer he should stick with the manual method.

[nalor]

Now I've written also reports for the original findvuk exe file to 3 companies:

Baidy, ByteHero, F-Prot=Cyren (don't know why they're listet as separate engines at the metascan-page).

I'm curios how long it takes to get a response from them - I'll post here when I have news about this topic

[avih]

Like I said, judging by your useful previous posts, my guess is that these are false positives and I never suspected you had malicious intents, or else I'd have been much less nice already. However, we just don't have the time/resources/capacity/will to investigate this on every binary attachment or to reproduce binaries which end up as false positive "threats", or to negotiate it with the attachment uploader, etc.

Really, seeing that you already offer it as freeware and it doesn't look to me like you intend to sell it, my best suggestion would be to open source your code such that others could contribute as well, and use whatever platform you choose to also be the main host for your binaries (github, bitbucket, whatever).

[nalor]

I've never done anything with github - so in case I'm going open source I think I would simply include the source into the zip file of the application...

And as the list of features it offers is that short, I can't think of any third party interest to help with development
Apart from that Purebasic as programming-language isn't that wide spread at all - although it's a small application it still has ~5000 lines of code and also uses some winapi functions, so only the commercial purebasic edition can be used to compile the source code.
The main reason for going open source would be to make it easier to understand how the aacs decryption works - basically I think that 'basic' code is easier to read and understand than for example the code of the libaacs-library.

At the moment there's exactly one feature missing I'd like to add:

• check in the main-keydb.cfg if the currently detected key is already in the database and if it is check the other values if it makes sense to write a new entry to the file or not.

As soon as this is done development from my side will most likely be reduced to a maintenance mode to check compatibility with new releases of the required external DVDfab applications.

And as long as nobody else is reporting errors or feature request I wouldn't have an idea what else I could integrate

(I thought about a GUI or to limit detection to a fixed drive letter - but decided against it because the tool does at the moment everything it needs to do... and I think it's doing it quite well so no reason to change the workflow fundamentally..)

[avih]

Originally Posted by nalor

I've never done anything with github - so in case I'm going open source I think I would simply include the source into the zip file of the application...

Using github (and any version control system, and git too) does have a learning curve to it, sometimes even a non trivial one, but I think you could benefit greatly from learning to work within such system.

Originally Posted by nalor

And as the list of features it offers is that short, I can't think of any third party interest to help with development
Apart from that Purebasic as programming-language isn't that wide spread at all - although it's a small application it still has ~5000 lines of code and also uses some winapi functions, so only the commercial purebasic edition can be used to compile the source code.

That's fine. The mere fact that you host your sources publicly is enough to give it more credit than some arbitrary binary by an unknown(?) developer. Of course, it doesn't guarantee anything, but it would be appreciated by users and developers alike. In your case, I really think it would be a good move.

Originally Posted by nalor

The main reason for going open source would be to make it easier to understand how the aacs decryption works - basically I think that 'basic' code is easier to read and understand than for example the code of the libaacs-library.

That sounds to me like a good reason indeed.

And while I don't need this tool myself, it does sound to me like a useful tool which is good to have. So do keep up the good work