New AACS keys public database and updater [Archive]

Starbuck2010

16th October 2014, 08:21

I've created a free database of AACS keys and and open-source software to keep local KEYDB.cfg files up-to-date.

Local VUK keys saved by libaacs (in %APPDATA%/aacs/vuk folder) are parsed and uploaded to enrich the database.

Project page: http://www.labdv.com/aacs/

Updater program page: http://www.labdv.com/aacs/updater.php

Windows installers of VLC 2.x and MPlayer 1.1 with libaacs.dll and libbdplus.dll
KEYDB.cfg updater program to download and upload new AACS keys
Source code with API in AacsDatabaseObject.cpp
Windows, Linux and Mac OS X
Gratis and open source

Zombiedeth

3rd November 2014, 20:36

There is a newer Host cert that dizzier found that's not in your KEYDB.cfg.

http://forum.doom9.org/showpost.php?p=1657679&postcount=529

Here it is formatted for KEYDB.cfg.

; host certificate v43
| HC | HOST_PRIV_KEY 0x88B245EA25315F46E6E99D9D521EB1194454A82D \
| HOST_CERT 0x0201005CFFFF800000C400005BF6843ED1AA9C9D \
0xEEFEAD8174479C72AB5457691EEB75669105BB19 \
0x5D4B9133069A18FD5357797116CEC22D7FE8F366 \
0xC2A092E1D00DB770E9E01DB687456B6FBFA28C96 \
0x2D88F05DD43F584ECC821AF7 \
| HOST_NONCE 0x2923BE84E16CD6AE529049F1F1BBE9EBB3A6DB3C \
| HOST_KEY_POINT 0x8A60C80BD60C23605FBE90B27BF96B2DB38195C1 \
0x801F54EB29E0F6EC57AC2B9168E88B2D56977508

dizzier

4th November 2014, 09:01

It is present there, but labeled "host certificate from aacskeys-0.4.0, v4" for whatever reason;)

candela

29th November 2014, 18:06

Thanks for the tool but is there any way to get VUK for any new discs. Is it possible to get them from the paying version of MakeMKV or AnydvdHD for example ? Because with those host certificates all blacklisted and no new processing keys nobody can get keys with VLC anymore (except those hacked drives that accept any host certifcate can still get pre MKB30 with that latest processing key)

I also see some issues on your site:
1) http://www.labdv.com/aacs/updater.php states %APPDATA%/libbdplus/vm0 which should be %APPDATA%/bdplus/vm0

2) http://www.labdv.com/aacs/advanced-users.php step 4 links to http://www.labdv.com/aacs/libaacs/keydb.bz2 instead of the vm0 file

3) http://www.labdv.com/aacs/libbdplus/bdplus-vm0.bz2 linked to on http://www.labdv.com/aacs/advanced-users.php
If I unzip this on my windows PC I get a file with no extension. It's a tar which needs to be extracted again, somewhat confusing

nalor

15th August 2015, 09:24

@starbuck: thanks for the great tool! :thanks: :thanks: :thanks:

@candela: i asked myself the same question as you and finally found a way to retrieve VUKs of all blurays supported by dvdfab passkey.

In case you are interested take a look at my post about this topic http://forum.doom9.org/showthread.php?t=172472

Starbuck2010

9th September 2015, 10:29

@nalor nice job dude :thanks::thanks::thanks: for FinVdUK (http://forum.doom9.org/showthread.php?t=172472)

candela

9th September 2015, 14:53

@Starbuck2010, any possibility of replacing the old nameless keys from Libaacs in your database with the ones from FindVUK with the Volume Label and MKB information ? Because after running AACS updater I noticed the findvuk keys I obtained were overwritten with libaacs ones that were already in the db (i assume).

shadowofdarkness

20th September 2015, 11:33

Is it possible that not all my new vuks are getting uploaded by this program. Over the last few days since finding out about this I have went through my entire Bluray collection getting them all done and have successfully uploaded 169 but I keep seeing miss-matching numbers from my local files to what is reported as uploaded

First from the comfort of my home I went through all discs using libaacs on Linux and had it add 142 to my local vuk directory but when I uploaded them it only said 138 new added. At first I thought it was because the central database had just been updated and by coincidence someone else added a couple of them first.

But when I visited a family members house to access a Windows PC to use FindVUK on the ones unsupported by publicly available PKs I got 23 more on that system but it only uploaded 22

Finally on a third computer running the same setup I did 10 more discs and only 9 uploaded.

No other updates came during the 2nd and 3rd uploads so no one could of beat me to the discs.

The central database has not updated yet since I added all mine so I can't even check if I can spot any missing ones.

Also could you make it easier to get the updater on Linux I ended up giving up and copying my aacs vuk folder onto a Windows version running under WINE just to do the first upload.

When the main DB is updated I should be able to at least check for missing ones from the FindVUK since they include names but I'm not going to check the big first upload which will all be noname.

nalor

20th September 2015, 19:17

@shadowofdarkness: because of your fear that eventually not all local keys are correctly uploaded to the central key database I've created a small tool to compare a private keyfile with the main keyfile: keydbcompare.zip (http://www.file-upload.net/download-10922700/keydbcompare.zip.html)

Update 20170105: new Link to tool KeyDBcompare-002 (http://s000.tinyupload.com/index.php?file_id=03433259431125862246)

Simply copy all your private keyfiles in one file and next drag it onto the keydbcompare.exe and it will compare your local file with the main keyfile and tell you if all your keys are included or not (and also if they are included, but with a different title)

@Starbuck2010:

With my small comparison tool I noticed the same that candela already posted: although there are 'nice' title values in the local database they aren't used for the central database - so there are a lot of entries where my comparison tool tells me something like this:

DiscID >46E62022B6353C507194311E9A7826181BC7EE0F< Title >THE_EYE_BD< - already in MainKeyfile, but with different title >_NONAME_<

I'm with candela that it would be a good idea to replace the _NONAME_ title entries with the more meaningful title-values from FindVUK and I think it would also make sense to replace the current comment with the FindVUK value in such a case.

Another thing I noticed is that there are 37 entries in the main keydb file that exist at least 2 times with different VUK's ? I guess you don't know which VUK is the correct one - but wouldn't it make sense to remove those 37 at all? I created a duplicate entry in the keydb.cfg for one of my blurays where I damaged the VUK of the first entry - libaacs isn't using the 2nd entry (with the correct VUK) at all.. so I think it doesn't make sense to keep those discids with multiple VUKs in the database.

shadowofdarkness

27th September 2015, 10:15

nalor

4th October 2015, 21:59

Just noticed that AACS update cannot detect title-entry lines in the keydb file that include a date-entry field.
I checked your source and noticed the regex you're using to parse the lines is not flexible enough to handle the existence of additional entries to the common vuk-entry.

I think it would be good if you could enhance it so that it is working correctly in this case - and basically it would be a good idea to include the date-entry in your database as well because it gives a hint how old a disc/title is - this was my intention when I decided to add it to the file.

nalor

11th October 2015, 21:13

Just released my FindVUK 0.80 and to parse the keydb-file I've started with your regex, but when I noticed that it cannot read entries with a date entry I started to define my own regex - maybe it's an option for you:

^\s*(?:0x)?(?<discid>[0-9ABCDEFabcdef]{40,40})\s*=\s*(?<title>[^\|]*)(?:\|\s+(?:(?:(?:[V])\s+\|\s+(?:0x)?(?<vuk>[0-9ABCDEFabcdef]{32,32})[^\|;]*)|(?:(?:[D])\s+\|\s+(?<date>\d{4}-\d{2}-\d{2})[^\|;]*)|(?:(?:[^DV])\s+\|\s+[^\|;]*)))+(?:;\s*(?<comment>.*))?

It looks quite complex, but basically it isn't ;)

comment lines are ignored
has to start with a discid (with or without 0x prefix)
next the = character
and the title
followed by multiple entry-sections - the sections for D and V are returned (their syntax is verified), all the other entries are simply ignored
finally the comment is extracted - in case there is one
whitespace characters between entries are ignored
the interesting regex-groups are returned by name: discid, title, vuk, date, comment

It's working pretty good and so I thought I share it with you :)

candela

12th December 2015, 18:12

There's a bug in AACS Updater

I had these lines at the bottom of KEYDB.CFG

0x9F56F8D9DA8DDA353235CE1C7B897AAB8236F31D = LE_MAGASIN_DES_SUICIDES | V | 0x396BFEFA4A2E78E369BF63A3BCDFEBC5 ; MKBv36/FindVUK 0.82
0x4714A119CF534A9960628613B97F927830E69407 = WELCOME_TO_THE_JUNGLE | V | 0x690718DA8C101432B774E80C71F4CB65 ; MKBv43/FindVUK 0.82
0x1835457FACF2F9E4977F8FE22A9205038349F5C2 = DEATH_SPA (Death Spa) | V | 0x6A5FECC8C7C9F807BD8CA05E566AF479 ; MKBv46/FindVUK 0.83
0x27C3A04734D273645FB975BCC5CD13E7C3FB4CA4 = HOUSE OF MAGIC (House of Magic) | V | 0x15D0813593513F58CCFD1D2DBF483C0B ; MKBv47/FindVUK 0.84
0x2A31F0CCA9F474F72F3A815D14AE203D8820CF0D = LES_CONTES_DE_LA_NUIT_3D | V | 0xE3A111EB49E31E7A3311E4472F300A13 ; MKBv23/FindVUK 0.82
0x874C3216FD2F88272A2AE0EA6FE2FFF7F37439B4 = SURLAPISTEDUMARSUPILAMI (Sur la piste du Marsupilami) | V | 0x68E1DE0EB0B820645F707394752B196B ; MKBv20/FindVUK 0.83
0x821E34E81764A19ADC5E6CE7081AB06C44FF7270 = O APOSTOLO | V | 0xEBD47ACEE43A7D30FDDE8A047781D9F1 ; MKBv52/FindVUK 0.81
0xE76996856701F53CE508DD982350EA7447FFBADA = BOUNTY KILLER (Bounty Killer - Blu-ray™) | V | 0x32D902EF69FE69B9D868C64547776DA2 ; MKBv44/FindVUK 0.84
0x0E6D10549251FBBEF3E22835986D9A1BE090EE59 = Fright_Night_(1985) (Fright Night (1985) – Blu-ray™) | V | 0x0026E20D58D070D3C270EBB3E2796B14 ; MKBv47/FindVUK 0.84
0xA003637A3AA902D6F51F3AEA5EF6A43D66DE1880 = VS054 | V | 0x5601519FDD76BA4C2F44D7394340DD44 ; MKBv47/FindVUK 0.84

After running AACS Updater, the last line disappeared and for the other 2 the titles are messed up

0xE76996856701F53CE508DD982350EA7447FFBADA = BOUNTY KILLER (Bounty Killer - Blu-ray?? | V | 0x32D902EF69FE69B9D868C64547776DA2 ; MKBv44/FindVUK 0.84
0x0E6D10549251FBBEF3E22835986D9A1BE090EE59 = Fright_Night_(1985) (Fright Night (1985) | V | 0x0026E20D58D070D3C270EBB3E2796B14 ; MKBv47/FindVUK 0.84

LM2005

26th July 2016, 22:10

Has anyone else got an error message from AACSupdater? When I run it there is an messagebox saying "The ordinal 3906 could not be located in the dynamic link library LIBEAY32.dll. The title of the messagebox is AACS Updater: AACS Updater.exe - Ordinal Not Found.

When I run the program immediately after installation, when the installer SW? asks do you want to run it too, it works.

I have Win 7 32.

LM2005

27th July 2016, 10:23

I just did what I should have done first. I Googled the DLL name. It looks like it is part of the openSSL package. The package has two DLLs, the other is there in the install directory, but this problem DLL isn't. I wonder why it does work at first.

But I now have a matching set of DLLs and there are no error messages. But there are no updates. Very few users? But that is a topic for an other post.

candela

27th July 2016, 11:20

I always got that DLL error, it never prevented getting updates when there actually were updates. Starbuck simply hasn't been updating the database lately, a shame

LM2005

27th July 2016, 14:12

Well. I have uploaded a couple of updates there. And now when it really worked, I got something like 14000 updates. So there are new updates, but perhaps this bug has prevented people getting them or uploading them.

Database in my machine is around 1.47Mbytes.

Starbuck2010

9th August 2016, 08:10

@shadowofdarkness: because of your fear that eventually not all local keys are correctly uploaded to the central key database I've created a small tool to compare a private keyfile with the main keyfile: keydbcompare.zip (http://www.file-upload.net/download-10922700/keydbcompare.zip.html)

Simply copy all your private keyfiles in one file and next drag it onto the keydbcompare.exe and it will compare your local file with the main keyfile and tell you if all your keys are included or not (and also if they are included, but with a different title)

@Starbuck2010:

With my small comparison tool I noticed the same that candela already posted: although there are 'nice' title values in the local database they aren't used for the central database - so there are a lot of entries where my comparison tool tells me something like this:

I'm with candela that it would be a good idea to replace the _NONAME_ title entries with the more meaningful title-values from FindVUK and I think it would also make sense to replace the current comment with the FindVUK value in such a case.

Another thing I noticed is that there are 37 entries in the main keydb file that exist at least 2 times with different VUK's ? I guess you don't know which VUK is the correct one - but wouldn't it make sense to remove those 37 at all? I created a duplicate entry in the keydb.cfg for one of my blurays where I damaged the VUK of the first entry - libaacs isn't using the 2nd entry (with the correct VUK) at all.. so I think it doesn't make sense to keep those discids with multiple VUKs in the database.

_NONAME_ comes when key is discovered with libaacs (no human look so disc name is not known)

candela

9th August 2016, 19:16

_NONAME_ comes when key is discovered with libaacs (no human look so disc name is not known)

The point was that if someone else then uses FindVUK for the same disc, the better volume ID is ignored by AACS Updater because "_NONAME_" is already in the database

Starbuck2010

9th August 2016, 19:30

I've got some time these days to work on AACS Updater.

I've introduced nalor suggested regex, just have to change the date field to (?<date>\\d{4}[/\\-]\\d{2}[/\\-]\\d{2})

I'm now working on a process to subtitute the _NONAME_ when title is known (not changing that the very first uploaded title always wins)...

I may release 1.2 this week (hopefully).

candela

9th August 2016, 19:44

Are you sure it's safe for libaacs to change KEYDB.cfg from ASCII to UTF-8 (to support ™ char for example)?

According to this spec (http://git.videolan.org?p=libaacs.git;a=blob;f=KEYDB.cfg;h=4628f8accc29dc128f4e4339f87455274b6714c4;hb=HEAD) included with Videolan's Libaacs it should be UTF-8 without BOM

Starbuck2010

10th August 2016, 10:59

Thanks, working on UTF-8 support, will be AAS Updater 2.0

Starbuck2010

10th August 2016, 16:39

Database updated with 3286 new keys:

; KEYDB.cfg
; 2016-08-10 17:36:51
;
; server: http://www.labdv.com/aacs
; processing keys: 18 (18 from doom9.org forum)
; host certificates: 7 (6 from doom9.org forum)
; disc VUK keys: 17254 keys for 17208 discs (945 from doom9.org forum)

Starbuck2010

10th August 2016, 23:59

I've replaced more than 450 _NONAME_ titles with knowndisc names in the uploaded keys :)

Was a painful SQL work... will try to make the replacement automatically onne uploads...

Starbuck2010

11th August 2016, 15:09

I don't remember if I already posted this:

For advanced users:

AACS Updater can be run in debug mode with option -d or --debug

Starbuck2010

13th August 2016, 07:52

I've release AACS Updater 2.0 (http://www.labdv.com/aacs/updater.php):

Fix:

improve VUK parsing with nalor regex (from doom9))
^\s*(?:0x)?(?<discid>[0-9ABCDEFabcdef]{40,40})\s*=\s*(?<title>[^\|]*)(?:\|\s+(?:(?:(?:[V])\s+\|\s+(?:0x)?(?<vuk>[0-9ABCDEFabcdef]{32,32})[^\|;]*)|(?:(?:[D])\s+\|\s+(?<date>\d{4}-\d{2}-\d{2})[^\|;]*)|(?:(?:[^DV])\s+\|\s+[^\|;]*)))+(?:;\s*(?<comment>.*))?
with (?<date>\d{4}[/\\-]\d{2}[/\\-]\d{2})
keys and KEYDB.CFG format changed to UtF-8 (QTextStream with setCodec("UTF-8"))
see http://git.videolan.org/?p=libaacs.git;a=blob;f=KEYDB.cfg;h=4628f8accc29dc128f4e4339f87455274b6714c4;hb=HEAD
according to this spec included with Videolan's Libaacs, CONFIG.CFG should be UTF-8 without BOM
database columns changed from ascii_general_ci to utf8_general_ci
show new keys to upload, like downloaded ones
improve GUI animation (no more freezing while loading and analyzing keys)

Installers for Windows:

added libeay32.dll in installers
AACS Updater and its bundles only (libbdplus.dll available for win32 only)

Build:

Windows 32 bits with Qt 5.6.0
Windows 64 bits with Qt 5.6.0

candela

14th August 2016, 21:39

Thanks for the update, some remarks:

1) there are 32 and 64 bit libbdplus.dll & libaacs.dll made available here (http://forum.doom9.org/showthread.php?p=1744883#post1744883) by dizzier. There is also libbluray.dll but it's not used by VLC as far as I can tell. However, libbluray includes the program bd_info.exe which tells you the BD+ version. I believe only versions 1-3 are supported by libbdplus. The lowest version I have found so far in my collection is 4 and it doesn't decrypt properly. Not including the dll will make VLC complain when trying to play a BD+ title so i'm assuming the 64 bit version works though

2) your site about AACS Updater is quite confusing I think. You have 3 different pages with a multitude of download links. There is no clear link between these 3 pages and they all have overlapping info

3) Can previously uploaded UTF-8 characters be "repaired" or was the character encoding permanently destroyed ? for example "BOUNTY KILLER (Bounty Killer - Blu-ray™)" was wrong in the old db but now it's still wrong.

Starbuck2010

18th August 2016, 18:05

1) downloading... will release in aacs updater bundles
2) agree, I'll try to make it better when I'll release the bundles
3) I guess problem is that KEYDB.CFG has no BOM header so for example UltraEdit can't show ™ to me while Chrome shows it correctly: http://www.labdv.com/aacs/KEYDB.cfg

candela

18th August 2016, 20:15

3) I guess problem is that KEYDB.CFG has no BOM header so for example UltraEdit can't show ™ to me while Chrome shows it correctly: http://www.labdv.com/aacs/KEYDB.cfg

I don't think so

KEYDB.cfg you linked has the TM char encoded as 0x99. This is TM in the Windows-1252 character set

KEYDB.cfg from AACS Updater 1.0 has it encoded as 0x3f 0x3f 0x20 [here the ) is also missing]

I think you then manually edited it because the KEYDB.cfg from AACS Updater 2.0 has it as 0x3f [here the ) is back]

In UTF-8 the TM character requires 3 bytes 0xE2 0x84 0xA2

1252 vs UTF-8 (http://www.i18nqa.com/debug/table-iso8859-1-vs-windows-1252.html)

If I look at the FindVUK backup file, it actually has it as 0xE2 0x84 0xA2 and it displays fine in Notepad++

BTW: there is an error in the KEYDB.cfg
0xEE07066F15EDA23B04AEA33106BE1EDF9DF537D1 = The Day After To
AACS Updater 1.0
2016 | V | 0x07181A359AF9ED6AC7E2F5587FC96629 ; mkbv12

Starbuck2010

19th August 2016, 09:36

1) Uploaded new AACS Updater and VLC bundles with libaacs 0.8.1 / libbdplus 0.1.2 libraries
2) Cleaned up a bit the AACS Updater web site
3) Validated 69 new uploaded keys (with 48 new disc titles from FindVUK to replace _NONAME_)
4) ™ is correct in the database with utf8_general_ci and AACS Updater download and save with QTextStream with UTF-8 codec (if one could have a look at the source code, I guess I was mistaken somewhere but couldn't find out)

; KEYDB.cfg
; 2016-08-19 10:36:22
;
; server: http://www.labdv.com/aacs
; processing keys: 18 (18 from doom9.org forum)
; host certificates: 7 (6 from doom9.org forum)
; disc VUK keys: 17351 keys for 17312 discs (930 from doom9.org forum)

candela

21st August 2016, 18:10

4) ™ is correct in the database with utf8_general_ci and AACS Updater download and save with QTextStream with UTF-8 codec (if one could have a look at the source code, I guess I was mistaken somewhere but couldn't find out)

Are you sure the online database is actually UTF-8. I re-downloaded the KEYDB.cfg with AACS Updater after your last update. The TM character is now encoded as 0xef 0xbf 0xbd which is the "replacement character". Like I mentioned before, http://www.labdv.com/aacs/KEYDB.cfg has TM encoded as 0x99 which does not exist in UTF-8. If you try to save this KEYDB.cfg locally as UTF-8, the invalid character 0x99 is replaced with 0xef 0xbf 0xbd by QT

ro-ee

24th August 2016, 21:36

™ as 0x99 is actually Windows-Codepage 1252 (which is *not* the same as Latin-1), so yeah, that is not UTF-8.

Starbuck2010

5th September 2016, 09:25

415 new keys and 21 disc titles updated
; KEYDB.cfg
; 2016-09-05 10:19:38
;
; server: http://www.labdv.com/aacs
; processing keys: 18 (18 from doom9.org forum)
; host certificates: 7 (6 from doom9.org forum)
; disc VUK keys: 17766 keys for 17727 discs (916 from doom9.org forum)

Starbuck2010

6th September 2016, 19:02

:) The message you have entered is too short. Please lengthen your message to at least 5 characters.

Starbuck2010

6th September 2016, 19:03

I've fixed UTF-8 issues with central DB and local KEYDB.CFG, I guess...

Released AACS Updater 2.1

Starbuck2010

7th September 2016, 07:00

Got new libaacs/libbdplus DLL builds from dizzier
AACS Database CHANGELOG
==================

Updated by Starbuck (http://www.labdv.com/aacs/)
September 7th, 2016

version 2.1.1.0: updated libaacs 0.8.1.1

Known bugs and limitations:
- UTF-8 displayed badly in monitor displays
- libaacs.dll and libbdplus.dll not working with VLC 2.3.x

Fix:
- New libaacs.dll and libbdplus.dll builds fix issues running Windows 10
- New libaacs.dll and libbdplus.dll tested with VLC 2.2.x

Installers for Windows:
- Updated libaacs.dll with 0.8.1.1 builds by dizzier@doom9
http://forum.doom9.org/showthread.php?p=1780031

Starbuck2010

8th September 2016, 05:04

dizzier

10th September 2016, 21:07

The libaacs.dll provided by the newest AACS Updater (v.2.1.1.0) does not work with any of the latest mpv-builds for Windows! (→ https://mpv.io/installation/)

Using the libaacs.dll from your (older) MPlayer-package or the one provided on vlc-bluray.whoknowsmy.name does the trick.

I've just checked both lachs0r and shinchiro builds, 32 and 64 bit. They all work fine for me, even with a BD+ disc.

I've launched it just like that:
mpv.exe --bluray-device=d: bluray://

Builds I've tested:
mpv-i686-20160826
mpv-x86_64-20160826
mpv-i686-20160910-git-d054a71
mpv-x86_64-20160910-git-d054a71

Are you sure you didn't mix 32/64 libraries? If you launch mpv from console using mpv.com, instead of mpv.exe, you can see console output, maybe there will be something useful there.

Starbuck2010

12th September 2016, 06:43

I've just checked both lachs0r and shinchiro builds, 32 and 64 bit. They all work fine for me, even with a BD+ disc.

I've launched it just like that:
mpv.exe --bluray-device=d: bluray://

Builds I've tested:
mpv-i686-20160826
mpv-x86_64-20160826
mpv-i686-20160910-git-d054a71
mpv-x86_64-20160910-git-d054a71

Are you sure you didn't mix 32/64 libraries? If you launch mpv from console using mpv.com, instead of mpv.exe, you can see console output, maybe there will be something useful there.

Good!

Was a user feedback, should have tested myself, sorry.

Starbuck2010

15th October 2016, 17:28

841 new keys and 106 disc titles updated (most of them from FindVUK 0.99/0.98)

; KEYDB.cfg
; 2016-10-15 18:27:30
;
; server: http://www.labdv.com/aacs
; processing keys: 18 (18 from doom9.org forum)
; host certificates: 7 (6 from doom9.org forum)
; disc VUK keys: 18639 keys for 18582 discs (0 from doom9.org forum)

xplt

22nd October 2016, 13:16

841 new keys and 106 disc titles updated (most of them from FindVUK 0.99/0.98)

Hey, Starbuck2010! Thanks for the update. I have one small request: could you please put the date of your latest updates of KEYDB somewhere on the page (just like you do it for AACS Updater)?

candela

10th November 2016, 13:59

bug: AACSUpdater (also 2.1.1.0) keeps deleting dizzier's new host certificate (http://forum.doom9.org/showthread.php?p=1779105#post1779105) from KEYDB.CFG

feature request: can you add support for all the other keys (mediakey, unit/title key, volumeid) than VUK in KEYDB.cfg. The keys are explained in the KEYDB.cg specification from videolan

nalor

10th November 2016, 20:05

@Starbuck2010

Feature request from my side: would be fine if you could increase the max length of currently 40 characters for the TITLE entry in the database (and eventually also the limit for the COMMENT entry?)

Thanks!

Starbuck2010

11th November 2016, 11:39

Starbuck2010

11th November 2016, 11:46

bug: AACSUpdater (also 2.1.1.0) keeps deleting dizzier's new host certificate (http://forum.doom9.org/showthread.php?p=1779105#post1779105) from KEYDB.CFG

Done :D

HC update is done manually because once a year :o

Just drop me a mail when you get a new one (I missed this one)

Starbuck2010

11th November 2016, 11:49

feature request: can you add support for all the other keys (mediakey, unit/title key, volumeid) than VUK in KEYDB.cfg. The keys are explained in the KEYDB.cg specification from videolan

Can you point me to the KEYDB.cg specification from videolan?

Starbuck2010

11th November 2016, 12:04

1) Added 1 HC key from Dizzier
2) Replaced 68 new disc titles (from FindVUK to replace _NONAME_)
3) Validated 697 new disc keys (uploaded VUK)

; KEYDB.cfg
; 2016-11-11 12:03:26
;
; server: http://www.labdv.com/aacs
; processing keys: 18 (18 from doom9.org forum)
; host certificates: 8 (7 from doom9.org forum)
; disc VUK keys: 19336 keys for 19282 discs (0 from doom9.org forum)

Starbuck2010

11th November 2016, 12:07

Hey, Starbuck2010! Thanks for the update. I have one small request: could you please put the date of your latest updates of KEYDB somewhere on the page (just like you do it for AACS Updater)?
I guess the date is present and quoted in my posts:
; KEYDB.cfg
; 2016-10-15 18:27:30

candela

11th November 2016, 12:14

Can you point me to the KEYDB.cg specification from videolan?

You already have it (http://forum.doom9.org/showthread.php?p=1776709#post1776709)

Done :D

HC update is done manually because once a year :o

Just drop me a mail when you get a new one (I missed this one)

In understand but AACSUpdater site states:

Please note that Host Certificates, PK and VUK keys that you add manually in your KEYDB.cfg file are not altered when running AACS Updater (they're merged at the end of central KEYDB.cfg ).

So it shouldn't delete