UHD & Blu-ray Database / KEYDB.cfg

[candela]

Originally Posted by Snap

The announcement post did however state 'no other software can read files in this format so far' (emphasis mine) so I'm not sure if that's a challenge to other devs or if they'll open it up (though currently this feature does give MakeMKV an edge vs the outrageously expensive DeUHD).

It is clear that the Makemkv author has no interest in advancing public knowledge. Read his faq about BD+ which basically states: "the info on Wikipedia is incorrect but I won't tell you what or give any hints". He does not contribute to Videolan's Bluray libraries, instead he writes replacements which redirect calls to Makemkv. Instead of making a new format, he could have simply proposed a new key entry in Keydb, e.g. | H | [hashed key] and update Videolan's library to support it. Unless the 'incorrect assumptions' in keydb are that a DiscID do not uniquely correlate with the required keys (i.e. DiscIDA can have VUKA or VUKB meaning duplicate entries are needed), there was 0 reason for this new format.

He can do whatever he wants but should simply state 'I want people to use my program so I'm encrypting the keys, good luck figuring it out'. Anyway, 0 fucks given by me about UHD, I'm interested in opening up regular Bluray playback

By the way, Relight's database can simply store these hashed keys, and output the desired format when needed. People on myce will probably correlate the hashed keys with the regular DiscIDs in their excel list (and we will see if the DiscID was indeed an 'incorrect assumption' or not)

[nalor]

Originally Posted by DavVador

Is there a place where we can download your latest version of FindVUK ?
The only one i can find is 1.02.
Unless it's not for public release.

Not yet, but I'll try to offer the next release during the next weekend.

Gesendet von meinem E5823 mit Tapatalk

[DavVador]

Originally Posted by nalor

Not yet, but I'll try to offer the next release during the next weekend.

Gesendet von meinem E5823 mit Tapatalk

Great news, thanks !

[candela]

@nalor did see my msg about adding MD5(MKB_RO.inf)

[Relight]

What's this about MD5 for MKB_RO.inf?

I will wait for a few updates to FindVUK XML output before proceeding with database, just because it's easier/better to do it once we have the final "template" of the XML file. One of the additions I spoke with nalor about is for the XML to report the version of FindVUK - perhaps something along the lines of:
<Application>FindVUK X.XX</Application>

[nalor]

Originally Posted by candela

@nalor did see my msg about adding MD5(MKB_RO.inf)

MD5 for a specific file shouldn't be problem - but how should I call this value ?

[candela]

MD5 hash is just and extra parameter for information purposes. The application parameter is useful, for other sources besides Findvuk . It would be nice if your database can handle unknown parameters though.

We can just call it <MKB_MD5> or <MKBmd5> or possibly a general thing, maybe more interesting hashes are useful in the future. Don't known at the moment . Maybe BD+ table hash although bd+ tables can actually have different headers so the hash isn't unique

<Hashes>
<Hash Type="MD5" File="MKB_RO.inf" Size="1048576">C002518F549F81797B4694E527092D</Hash>
<Hash Type="MD5" File="convtab.bin" Size="123000">503F781E6A5C62606ABA45BF5AE9FF</Hash>
</Hashes>

[Relight]

Yes, the database will have a method to handle unknown parameters, although obviously I would like to start with as much information as possible so that we can at least limit the changes needed after submissions start.

[Mike Chen]

Originally Posted by candela

but I won't tell you what or give any hints".

Where and when exactly did I said this?

Originally Posted by candela

People on myce will probably correlate the hashed keys with the regular DiscIDs in their excel list (and we will see if the DiscID was indeed an 'incorrect assumption' or not)

You can as well just ask. I will happily provide UKRO and/or MKB hash for each hashed key entry, I just really don't see the point. Besides, no one has asked.

Originally Posted by candela

He does not contribute to Videolan's Bluray libraries, instead he writes replacements which redirect calls to Makemkv.

So you are saying that maintaining a linux port, keeping it open source, integrated into libbluray and all essentially giving it away for free for the 10 years is still not good enough for you, and I should just release all keys to everyone in the format of your choice? Point taken...

[DavVador]

Originally Posted by Mike Chen

You can as well just ask. I will happily provide UKRO and/or MKB hash for each hashed key entry, I just really don't see the point. Besides, no one has asked.

This would help me a lot actually, i'm trying to figure out which of my UHD can be converted with MakeMKV or not, and having a hash would save me lot of time.
As for now, i got to put my discs in the drive, one by one, wait for the disc to be identified, then try to backup, wait a 1 minute, clic the on the window popping, wait a few more minutes and then i can see if it works or not.
Having the hashes for UK RO or MKB RO would allow me to just check my excel file and see if my disc can be decripted or not.

PS: I sent you some dumps for the ones missing, with UK hash and EAN in case you would like to make a database with more infos.
And good job by the way

[nalor]

Originally Posted by Relight

What's this about MD5 for MKB_RO.inf?

I will wait for a few updates to FindVUK XML output before proceeding with database, just because it's easier/better to do it once we have the final "template" of the XML file. One of the additions I spoke with nalor about is for the XML to report the version of FindVUK - perhaps something along the lines of:
<Application>FindVUK X.XX</Application>

Already added 'Application' to the file, now I'm checking how I can submit the 'READ CAPACITY' command to the drive to get the full disc size.

And I've added a parameter to just request the MetaInfos from a disc in drive - e.g. for the single UHD I have I get this:

<?xml version="1.0" encoding="UTF-8"?>
<Bluray>
	<FileType>BlurayMetaXML</FileType>
	<DiscId Date="2016-03-18">F58AA868C40D5894C332F9BDB978522432D5CC82</DiscId>
	<VolumeLabel>DEADPOOL</VolumeLabel>
	<BDplus>0</BDplus>
	<BusEncryptionEnabled>1</BusEncryptionEnabled>
	<MKBrev>60</MKBrev>
	<MetaTitles>
		<MetaTitle Language="eng">Deadpool</MetaTitle>
	</MetaTitles>
	<Application>FindVUK 1.xx</Application>
	<VolumeSize>0</VolumeSize>
</Bluray>

[candela]

Originally Posted by Mike Chen

Where and when exactly did I said this?

You can as well just ask. I will happily provide UKRO and/or MKB hash for each hashed key entry, I just really don't see the point. Besides, no one has asked.

So you are saying that maintaining a linux port, keeping it open source, integrated into libbluray and all essentially giving it away for free for the 10 years is still not good enough for you, and I should just release all keys to everyone in the format of your choice? Point taken...

You didn't say it explicitly, you simply state in your faq the info is wrong but not what is wrong. And you do not correct Wikipedia or Libbdplus code. And for these hashed keys, you state old assumptions about AACS are no longer valid but you don't say what is not valid. Why bother saying it if you don't want to share the information. Not many people have the skill to figure it out. I certainly don't, everything I know is based on information shared on this forum or from trying to understand Videolan libs

People on myce seemed to be interested in the DiscIDs and I was under the impression you were following the topic. And the DiscID would obviously be helpful for storing the hashed keys in the database Relight is trying to make

And I didn't say you need to release the keys for everyone. I said you can do what you want. But you don't give a real reason for this magical new format and the only obvious one is keeping the keys secret. So just say it.

Also many thanks for your program, it's been most useful for me. I'm just more a fan of the Videolan open source kind. You know, the free beer vs freedom thing.

[candela]

@nalor, can you also let Findvuk submit info to the db even if key retrieval fails. Things like DiscID, MD5, Volumelabel, MetaData is still useful even without keys (also did you see the edit in my post for the hash format)

@relight can your db handle this? in the end this will result in multiple submits for the same discid that need to be combined

This way it's also possible to write a program that just collects Bluray info in general.

[nalor]

Uploaded new FindVUK release in the other thread. Please test with the synchronization feature.
It's possible to define different backup modes in the ini file - this way copies of the different xml files are stored locally so you can study them.

In case something isn't working as expected just tell me

PS: the download url can also be a local filename either as 'cfg' file or as zip file with an included keydb.cfg in it - in case you're using an internet url it has to be a zip file.. will add detection of the online filetype in the next release, but currently it expects that it gets a zip file in this case.

And one more thing - when it calls the download-url from the ini file it attaches the parameter ?lang=xx where xx is the preferred language from the ini file, the idea has been that it's possible to deliver a keydb.file with localized names in it.

[libredr]

Hi, has there been any progress with replacing the VUK database?

[Relight]

As per first post updated on Feb 18, this is no longer really needed or being developed since FindVUK now has its own database.

[libredr]

Alright, thanks. However, for Linux users, it would be great to have a way to extract the data indepedently to running FindVUK. Is this possible?

[Relight]

Since decrypting methods aren't publicly available, it's not possible to have a standalone cross-platform application, which would be ideal. FindVUK relies on another program running to discover the keys. The ideal solution would be a standalone program or even an existing program such as MakeMKV, which can discover all information about a disc, to then dump all disc information to a proper database. Unfortunately, those who have the actual knowledge of disc decryption don't seem to be interested in such data gathering.

[m4tthi4s]

Originally Posted by libredr

Alright, thanks. However, for Linux users, it would be great to have a way to extract the data indepedently to running FindVUK. Is this possible?

try for Linux: https://github.com/m4tthi4s/vukextract

[libredr]

Thanks to you both. However I misspoke: I meant, how to get the FindVUK database of VUKs (already decrypted) without running FindVUK? Similar to the old KEYDB.cfg file from the old database.