UHD & Blu-ray Database / KEYDB.cfg [Archive]

View Full Version : UHD & Blu-ray Database / KEYDB.cfg

Relight

13th January 2018, 01:47

Would be nice if there was a user-contributable list/database for disc hashes with comprehensive version info...
This thread was originally meant for the development of a new database for Blu-ray and UHD data with the purpose being new (and improved) KEYDB.cfg output.

(Starbuck2010's database is offline and he indicated that he doesn't have time for it anymore.)

However, since FindVUK operates a database, this really isn't needed.

The following links were meant to be temporary pending the new database, circa January 22, 2018, and are no longer maintained:

Latest KEYDB.cfg for Blu-ray and UHD: http://s000.tinyupload.com/index.php?file_id=34856796669669839157

Latest KEYDB.cfg for UHD ONLY: http://s000.tinyupload.com/index.php?file_id=88574719705707482529

Latest so-called "hashed keys" (ONLY work with MakeMKV, frequently updated): http://makemkv.com/forum2/viewtopic.php?f=12&t=16959

DavVador

13th January 2018, 09:03

nalor

13th January 2018, 12:06

I noticed you already offer to select 'Bluray' as type when entering new data directly on your website and you've also added a field for the VUK.
Do you have plans to make your website the new central-aacs-database site?
If so it would be great if you could add support for all fields that are specified for the keydb.cfg file and a few more.

Here's an example of a MetaXML that I've created for FindVUK to upload to a 'to be developed' online database ;)

<?xml version="1.0" encoding="UTF-8"?>
<Bluray>
<FileType>BlurayMetaXML</FileType>
<DiscId Date="2017-08-22">16ABFD83376D41E8CD26D1438FF02146059663BD</DiscId>
<VolumeId>F18B48F2BC9719E471BED63EA43BDC25</VolumeId>
<MediaKey>D2BF8DAC6A288A80B84CA5E8924D76CB</MediaKey>
<VolumeUniqueKey>E7E516328BAFAE8D8D91C28530695EE8</VolumeUniqueKey>
<VolumeLabel>War for the Planet of the Apes</VolumeLabel>
<BDplus Date="2017.09.07">1</BDplus>
<BusEncryptionEnabled>1</BusEncryptionEnabled>
<MKBrev>50</MKBrev>
<MainPlaylist>00800.mpls</MainPlaylist>
<UnitKeys>
<UnitKey Nr="1">80CA0B712E1FD110E8B9287B9F3C4FAC</UnitKey>
</UnitKeys>
<MetaTitles>
<MetaTitle Language="eng">War for the Planet of the Apes</MetaTitle>
<MetaTitle Language="fra">La Planète des Singes : Suprématie</MetaTitle>
<MetaTitle Language="spa">La guerra del planeta de los simios</MetaTitle>
<MetaTitle Language="nld">War for the Planet of the Apes</MetaTitle>
<MetaTitle Language="deu">Planet der Affen: Survival</MetaTitle>
<MetaTitle Language="ita">The War - Il Pianeta delle Scimmie</MetaTitle>
<MetaTitle Language="jpn">War for the Planet of the Apes</MetaTitle>
<MetaTitle Language="cat">La guerra del planeta de los simios</MetaTitle>
</MetaTitles>
</Bluray>

(small note - there can be multiple UnitKey entries)

Would be great if you could add all the fields to your db and finally allow to download a language-specific keydb.cfg created from the data.

(and I think it would be easy to add a 'postmeta' mode to findvuk that just grabs all easily available information from the bluray/uhd disc and submits it automatically to the onlinedb.)

candela

13th January 2018, 12:31

(small note - there can be multiple UniqueKey entries)

they are actually called UnitKey for BD or TitleKey for HDDVD. Uniquekey can be general though but they aren't actually unique and shared by many discs ;)

being able to upload BD+ tables to the database would also be useful (but they are ~1MB/disc on average, 5-10 GB of storage will go a long way , tables for many discs are also identical)

nalor

13th January 2018, 12:40

they are actually called UnitKey for BD or TitleKey for HDDVD. Uniquekey can be general though but they aren't actually unique and shared by many discs ;)

:eek: oh man - you're absolutely right .... (changed the post above already)
Also corrected it immediatly in FindVUK ;)

BRC85sYrg

13th January 2018, 13:07

http://www.uhddb.com

I don't know what the old key database was like, since I never saw it and it's down now. But I'm more than happy to maintain and develop this. Suggestions, discussions, bug reports, etc. and most importantly submissions into the database are welcome.

Big thanks for your efforts!

The database page ran by Starbuck2010 which unfortunately is down right now looked like this:
https://web.archive.org/web/20170705103518/http://www.labdv.com/aacs/

manual updates were done at the following page:
https://web.archive.org/web/20170629100057/http://www.labdv.com:80/aacs/keydb-upload.php

I hope this is what you were looking for.

candela

13th January 2018, 13:22

ohter possible fields are:
- Region info (A,B,C)
- comment field for additional info

and not to discourage you but a database like this requires a proper design and serious thought in advance. For example:
- 1 DiscID can be linked to many UPC codes and have different VolumeLabels
- 1 UPC code can be linked to many countries
- people can upload fake data (prevention mechanisms needed such as detecting duplicate VUK, impossible keylengths, confirming VUK from MK/VID calculation, etc )
- how to deal with duplicate entries where the key cannot be confirmed at the moment (there are several in the old AACSupdater database)
- prevent re-upload from previously deleted entries
- correction of existing entries
- ...

Relight

13th January 2018, 17:28

I think all suggestions posted so far (thank you!) can be easily implemented - the only question is what is the best way to proceed.

What data is really necessary? Should the database just use FindVUK as the primary input method?

It seems there is at least some interest in what I have done so far. However, since I am not yet very knowledgable on the decryption side (for example candela mentions MK/VID calculation which I don't know), I would welcome to work in collaboration with any of the experts in the community.

Now that there are some entries as test data (thank you DavVador!), I will hold the submission form until the database is developed a little bit more, hopefully with help from anyone interested in advising on the data it should have, possible integrations, integrating previous data from KEYDB.cfg, etc.

I think it would be great to have users simply upload an XML submission from FindVUK - does that seem like a good idea? The whole UPC/Country thing really isn't required I think - I got into that because that's what others are doing with their spreadsheets - the SHA1 should be the identification method for people wondering if their particular UHD has had a VUK released yet.

I know it's more disc-related than decryption, but I like the region suggestion by candela, and I also wouldn't mind seeing info such as disc size and number of layers.

Relight

13th January 2018, 19:18

Updated first post with latest KEYDB.cfg files. I will keep those files updated.

I have some questions about some of the content in KEYDB.cfg, if anyone is willing to chat with me, please send me a PM - thanks!

DavVador

13th January 2018, 19:29

From my point of view, UPC/EAN is very interesting, it's an easy way to check if your bluray can be decrypted without the need to put the bluray in your burner or even before buying.
Region code or country is an extra even if it's less important imo.

I don't have much free time to be honest, but would be glad to help in any way.
I'm not an expert at all in crypto but i can help in the webcode (html/php) if needed ;)
Or if you need some testing, i'm ok (I got 2 drives, 1 UHD friendly and 1 official UHD) !

And being able to post an XML generated with FindVUK would help you a lot i think if you wish to get more people submitting fields in your DB.

ChaosKing

13th January 2018, 21:32

You could even combine it with a simple app to scan BDs in a store.

candela

13th January 2018, 23:24

Data in your database does not have to be limited to data in keydb. You can build an entire Bluray movie database if you want, even IMDb codes can be useful.

Keydb specification can be found here (http://git.videolan.org/?p=libaacs.git;a=blob;f=KEYDB.cfg;h=4628f8accc29dc128f4e4339f87455274b6714c4;hb=883d3c07b156dab21f90a00d7ae7ca5b40ef9564). Even though VUK is sufficient to play a certain disc (ignoring bd+, bus encryption, playlist obfuscation and other DRM crap), I have explained here (https://forum.doom9.org/showthread.php?p=1811656#post1811656) why it is a mistake to collect only VUK

Even if keydb does not have support for some data, it should still be collected as separate data fields in the database (e.g. BD+, MKBrev, Region) and can be written in the keydb comment field. Keydb should be regarded as just 1 kind of output format. There should be for example CSV or SQL output which is much easier to work with for data analysis.

For example, a FindVUK XML

<?xml version="1.0" encoding="UTF-8"?>
<Bluray>
<FileType>BlurayMetaXML</FileType>
<DiscId Date="2011-06-06">113B873574ABF236895BE54376AA14649DA0152E</DiscId>
<VolumeId>A56C5A7AAAA8CBDE3D83834C836D8830</VolumeId>
<MediaKey>DF991ABB947C503E4BC18DC09F4F5579</MediaKey>
<VolumeUniqueKey>73C153CC28B32B650F23F8A9891331B9</VolumeUniqueKey>
<VolumeLabel>RETURN_OF_THE_JEDI</VolumeLabel>
<BDplus Date="2011-05-04">1</BDplus>
<BusEncryptionEnabled>0</BusEncryptionEnabled>
<MKBrev>19</MKBrev>
<MainPlaylist>00800.mpls</MainPlaylist>
<UnitKeys>
<UnitKey Nr="1">04B80421D00B2C68134BCE7807421287 </UnitKey>
<UnitKey Nr="2">85581552DC02679109AF39A4EA5077EB </UnitKey>
<UnitKey Nr="3">013BE88A01E408202A1994CD0252184C </UnitKey>
<UnitKey Nr="4">C2E9C5B3D4D68C80EBD4982C2D0B0584 </UnitKey>
<UnitKey Nr="5">BA966BE272D3AD16EAF4F2FF2A596B38 </UnitKey>
<UnitKey Nr="6">9571943B2E4CBA7CDADF6EA2D70141A1 </UnitKey>
<UnitKey Nr="7">6FB81616BF05A6A554CF99B396FF260D </UnitKey>
</UnitKeys>
<MetaTitles>
<MetaTitle Language="eng">Return of the Jedi</MetaTitle>
<MetaTitle Language="fra">Le retour du Jedi</MetaTitle>
</MetaTitles>
</Bluray>

can become a keydb.cfg entry similar to this:

0x113B873574ABF236895BE54376AA14649DA0152E = RETURN_OF_THE_JEDI (Return of the Jedi)
| D | 2011-06-06
| V | 0x73C153CC28B32B650F23F8A9891331B9
| U | 1-0x04B80421D00B2C68134BCE7807421287 | 2-0x85581552DC02679109AF39A4EA5077EB | 3-0x013BE88A01E408202A1994CD0252184C
| 4-0xC2E9C5B3D4D68C80EBD4982C2D0B0584 | 5-0xBA966BE272D3AD16EAF4F2FF2A596B38 | 6-0x9571943B2E4CBA7CDADF6EA2D70141A1 | 7-0x6FB81616BF05A6A554CF99B396FF260D
| M | 0xDF991ABB947C503E4BC18DC09F4F5579
| I | 0xA56C5A7AAAA8CBDE3D83834C836D8830
; FindVUK 1.02/MKBv19/BD+/Region-B-/Playlist00800

If you only take input from "trusted" sources like FindVuk you should not be too concerned with validation of the data or calculation of MK/VID to VUK (although without encryption anyone can fake entries). I just wanted to point out that there will be submissions for the same DiscId containing different data, for a multitude of reasons. You need to take into account how to deal with such scenarios as without access to the actual disc, the data is hard or impossible to verify.

With support for regular Bluray, we are not talking about a database of 200 UHD discs, easily maintainable manually. This will be in the region of 80.000 known DiscIds just to start with (and several 100.000 UPC if you want to track those)

Also it should be possible to submit from sources other than FindVUK, e.g. a program similar to AACSUpdater (this could even be built in to FindVUK) can harvest DiscID/VUK/VID keys from VLC AACS cache directories

nalor

14th January 2018, 01:04

I already added a 'synchronize' mode to FindVUK that downloads a keydb.cfg from a website, compares it to the local file and finally:
1) adds new entries from the online file to the local file
2) apply changes of entries that are different between both files to the local file (the online file is the 'master')
3) uploads new entries from the local file to the online db also as xml in a different format.

Here's an example:

<?xml version="1.0" encoding="UTF-8"?>
<Bluray>
<FileType>BlurayLegacyXML</FileType>
<LegacyEntries>
<LegacyEntry>
<DiscId Date="">C0A58017FAD25AC92C3B9F19D74FC1E5BFC1B025</DiscId>
<Title>MARAUDERS (Marauders)</Title>
<VolumeUniqueKey>1A741C903EB21F024F94B2F3F3F19D2A</VolumeUniqueKey>
<VolumeId/>
<MediaKey/>
<Comment>MKBv62/FindVUK 0.96</Comment>
</LegacyEntry>
<LegacyEntry>
<DiscId Date="">E20E7A19466208B7C58D0A87B8050425564E0F49</DiscId>
<Title>Bikini Destination triple fantasy</Title>
<VolumeUniqueKey>0E0BCB9F4F66870166F4C6FC23A3020F</VolumeUniqueKey>
<VolumeId/>
<MediaKey/>
<Comment/>
</LegacyEntry>
</LegacyEntries>
</Bluray>

And I also thought how it's possible to prevent invalid entries in the database created by super funny script kiddies .. and decided that it's necessary to sign the xml in order to decide if it's trustworthy or not.

I know there's an XML signature specification but it's not included in Purebasic and after reading the spec I decided that it would definitely be too much work to reimplement it in Purebasic (and I also thought that I could use an external library - but it's also too complicated or I'm too stupid..).

In the end I created my own format that looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<Main>
<Data>
<UUID>fa9c7bdf-00d5-49e6-9c27-ba4d39d9c9f8</UUID>
<Timestamp>2018-01-13T10:00:44+0000</Timestamp>
<Base64>PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz48Qmx1cmF5PjxGaWxlVHlwZT5CbHVyYXlNZXRhWE1MPC9G
aWxlVHlwZT48RGlzY0lkIERhdGU9IjIwMTctMDgtMjIiPjE2QUJGRDgzMzc2RDQxRThDRDI2RDE0MzhGRjAyMTQ2MDU5NjYzQkQ8L0Rp
c2NJZD48Vm9sdW1lSWQ+RjE4QjQ4RjJCQzk3MTlFNDcxQkVENjNFQTQzQkRDMjU8L1ZvbHVtZUlkPjxNZWRpYUtleT5EMkJGOERBQzZB
Mjg4QTgwQjg0Q0E1RTg5MjRENzZDQjwvTWVkaWFLZXk+PFZvbHVtZVVuaXF1ZUtleT5FN0U1MTYzMjhCQUZBRThEOEQ5MUMyODUzMDY5
NUVFODwvVm9sdW1lVW5pcXVlS2V5PjxWb2x1bWVMYWJlbD5XYXIgZm9yIHRoZSBQbGFuZXQgb2YgdGhlIEFwZXM8L1ZvbHVtZUxhYmVs
PjxCRHBsdXMgRGF0ZT0iMjAxNy4wOS4wNyI+MTwvQkRwbHVzPjxCdXNFbmNyeXB0aW9uRW5hYmxlZD4xPC9CdXNFbmNyeXB0aW9uRW5h
YmxlZD48TUtCcmV2PjUwPC9NS0JyZXY+PE1haW5QbGF5bGlzdD4wMDgwMC5tcGxzPC9NYWluUGxheWxpc3Q+PFVuaXF1ZUtleXM+PFVu
aXF1ZUtleSBOcj0iMSI+ODBDQTBCNzEyRTFGRDExMEU4QjkyODdCOUYzQzRGQUM8L1VuaXF1ZUtleT48L1VuaXF1ZUtleXM+PE1ldGFU
aXRsZXM+PE1ldGFUaXRsZSBMYW5ndWFnZT0iZW5nIj5XYXIgZm9yIHRoZSBQbGFuZXQgb2YgdGhlIEFwZXM8L01ldGFUaXRsZT48TWV0
YVRpdGxlIExhbmd1YWdlPSJmcmEiPkxhIFBsYW7DqHRlIGRlcyBTaW5nZXMgOiBTdXByw6ltYXRpZTwvTWV0YVRpdGxlPjxNZXRhVGl0
bGUgTGFuZ3VhZ2U9InNwYSI+TGEgZ3VlcnJhIGRlbCBwbGFuZXRhIGRlIGxvcyBzaW1pb3M8L01ldGFUaXRsZT48TWV0YVRpdGxlIExh
bmd1YWdlPSJubGQiPldhciBmb3IgdGhlIFBsYW5ldCBvZiB0aGUgQXBlczwvTWV0YVRpdGxlPjxNZXRhVGl0bGUgTGFuZ3VhZ2U9ImRl
dSI+UGxhbmV0IGRlciBBZmZlbjogU3Vydml2YWw8L01ldGFUaXRsZT48TWV0YVRpdGxlIExhbmd1YWdlPSJpdGEiPlRoZSBXYXIgLSBJ
bCBQaWFuZXRhIGRlbGxlIFNjaW1taWU8L01ldGFUaXRsZT48TWV0YVRpdGxlIExhbmd1YWdlPSJqcG4iPldhciBmb3IgdGhlIFBsYW5l
dCBvZiB0aGUgQXBlczwvTWV0YVRpdGxlPjxNZXRhVGl0bGUgTGFuZ3VhZ2U9ImNhdCI+TGEgZ3VlcnJhIGRlbCBwbGFuZXRhIGRlIGxv
cyBzaW1pb3M8L01ldGFUaXRsZT48L01ldGFUaXRsZXM+PC9CbHVyYXk+</Base64>
</Data>
<Signature>
<Checksum cipher="SHA256">0da227c5c0419892e196a8fff53f6f43e94a378e67359ddeba51416f5bfa6ed6</Checksum>
<Signature>1D783940EFA594B7955B21F353336A3F2228265A44F445B18DB9029B585CD2A17EE68CD1C7
C3C2D69C534C78040130F073CC1075D55A63FCA62843BD0EBD4A09</Signature>
</Signature>
</Main>
(usually Base64-Data and the Signature do not include linebreaks - just added them here to reduce the length of the lines)

The original XML (BlurayMetaXML or BlurayLegacyXML) is Base64 encoded - a SHA256 checksum is created from the data, a unique uuid and the timestamp - and the checksum is signed with libsodium and a private key that is 'embedded' into findvuk.
On the other end I've created a php-script that checks if the checksum matches the data and if the signature validates against the checksum with the help of a public key.
I know embedding a key into an application isn't really a secure solution - but I think it serves the purpose (if someone has a better idea just tell me).

So this is everything that is already working on my side :)

Relight

14th January 2018, 01:20

So this is everything that is already working on my side :)
Cool :)

I need to think a bit more about Legacy entries. I sent you a couple messages, let's make things happen :)

Snap

14th January 2018, 01:49

Neato. Pity ol' vBulletin doesn't support notifications or I would have noticed it sooner :)

Lately I've been checking this list (https://club.myce.com/t/titles-support-list/399337) maintained by a MyCE user, as recommended to me by a user perusing the keys thread. What might be time saving is if their spreadsheet could be used as a source to populate the site perhaps (given permission/credit of course), as it's already a pretty solid set of info per disc, including which releases are compatible with DeUHD (which at this point has become the only actively updated decryption method).

One thought on the UHDDB site is the Submission section asks for the type of release and AACS version. Seeing as the domain and home page suggest its for UHD releases only maybe it could be more straightforward to focus submissions to just UHD? Or perhaps creating a separate browsing category to clearly separate them and simplifying the submission to just UHD or Blu-Ray as an option. Just a thought.

Looking forward to how this progresses.

DavVador

14th January 2018, 13:28

I already added a 'synchronize' mode to FindVUK...
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.

Relight

14th January 2018, 22:42

New development and new keys here: http://makemkv.com/forum2/viewtopic.php?f=12&t=16959

Anyone have any thoughts about what these "hashed keys" are?

candela

14th January 2018, 23:21

New development and new keys here: http://makemkv.com/forum2/viewtopic.php?f=12&t=16959

Anyone have any thoughts about what these "hashed keys" are?

At first glance, these hashed keys are just a way to force people into using makemkv. Why else would he also not release the specification for this fantastic new file format in this announcement. He even states it is possible to encode the keys in both formats but then only releases the hashed keys. Also, no info on how these keys are better. The format itself is obviously not superior since it contains no info except a volumelabel and some kind of unknown hash which provides no way to identify a disc you own like the SHA-1 hash keydb uses. For all we know he can simply take the discid+vuk, encrypt them and then apply something similar to base64 encoding

datman

15th January 2018, 00:26

At first glance, these hashed keys are just a way to force people into using makemkv. Why else would he also not release the specification for this fantastic new file format in this announcement. He even states it is possible to encode the keys in both formats but then only releases the hashed keys. Also, no info on how these keys are better. The format itself is obviously not superior since it contains no info except a volumelabel and some kind of unknown hash which provides no way to identify a disc you own like the SHA-1 hash keydb uses. For all we know he can simply take the discid+vuk, encrypt them and then apply something similar to base64 encoding
Well all due respect can't you just copy them into your KEYDB.cfg file. Me it contains keys I need so all smiles here.:)

Snap

15th January 2018, 04:45

Well all due respect can't you just copy them into your KEYDB.cfg file. Me it contains keys I need so all smiles here.:)

The VUK and the 'Hashed Keys' (maybe I'll abbreviate it to 'HK') are different formats, and HK is only compatible with MakeMKV currently.

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).

The part in the announcement about the key being able to be read from a keydb.cfg or HK format is just regarding how MakeMKV can read it, afaik. In other words, now that MakeMKV supports reading two formats the user can use either one, but as of now only MakeMKV can read and convert to the HK format.

candela

15th January 2018, 10:32

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

15th January 2018, 23:44

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

16th January 2018, 07:25

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

18th January 2018, 20:58

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

Relight

18th January 2018, 21:19

nalor

18th January 2018, 22:02

@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

18th January 2018, 22:05

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

18th January 2018, 22:10

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

18th January 2018, 22:16

but I won't tell you what or give any hints".Where and when exactly did I said this?

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.

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

18th January 2018, 23:00

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

18th January 2018, 23:01

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

18th January 2018, 23:02

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

19th January 2018, 18:16

@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

22nd January 2018, 19:54

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

28th February 2018, 17:38

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

Relight

28th February 2018, 17:40

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

28th February 2018, 18:18

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

28th February 2018, 18:39

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

1st March 2018, 06:06

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

1st March 2018, 10:00

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.

nalor

1st March 2018, 11:35

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.

I have to finish my work on the database, currently all uploads are only stored, but not processed.

I've been working on the page a few weeks ago, but something else crossed my mind and so I stopped my work - but started again when I read the posts yesterday ;)

Finally there will be a simple download link on the page that is also reachable from linux.

libredr

4th March 2018, 09:03

Thank you very much nalor! Sounds exciting.

jpsdr

10th March 2018, 16:55

I've just got my first UHD disc, and i have a "friendly" drive. I don't think the title is in the database. Is there any information or thing i can do to help figure out/provide the key ?

Edit :
It seems my UHD BR that it was in the database finaly, i've been able to start the rip.

Edit 2 :
Finaly the key may have not been in the database, the rip failed at around 20% of the file.