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

[coopervid]

Yes there is. It's in the aacs directory that FindVUK downloads and extracts the keydb.cfg to.

Thanks a lot, Sam! That was not trivial to look there. So hopefully nalor fixes that soon. Otherwise this has to be done manually if you want to avoid to download the whole keydb.cfg file.

[SamuriHL]

Not for me it doesn't. ;) I fix it automagically before I do the sync.

[SamuriHL]

Just run this powershell script before you run the findvuk sync.


# Script to convert keydb_fvhash.ini timestamp format
# From: yyyyMMDDTHHmmssZ (e.g., 20260303T161635Z)
# To: yyyy.MM.dd HH:mm:ss (e.g., 2026.03.03 16:16:35)

$filePath = "$env:APPDATA\aacs\keydb_fvhash.ini"

if (-not (Test-Path $filePath)) {
Write-Error "File not found: $filePath"
exit 1
}

# Read the file
$content = Get-Content $filePath -Raw

# Replace timestamps in yyyyMMDDTHHmmssZ format with yyyy.MM.dd HH:mm:ss format
$content = $content -replace '(\d{4})(\d{2})(\d{2})T(\d{2})(\d{2})(\d{2})Z', '$1.$2.$3 $4:$5:$6'

# Write back to file
Set-Content -Path $filePath -Value $content -NoNewline

Write-Host "Timestamp format updated successfully!"
Get-Content $filePath

[coopervid]

Just run this powershell script before you run the findvuk sync.


# Script to convert keydb_fvhash.ini timestamp format
# From: yyyyMMDDTHHmmssZ (e.g., 20260303T161635Z)
# To: yyyy.MM.dd HH:mm:ss (e.g., 2026.03.03 16:16:35)

$filePath = "$env:APPDATA\aacs\keydb_fvhash.ini"

if (-not (Test-Path $filePath)) {
Write-Error "File not found: $filePath"
exit 1
}

# Read the file
$content = Get-Content $filePath -Raw

# Replace timestamps in yyyyMMDDTHHmmssZ format with yyyy.MM.dd HH:mm:ss format
$content = $content -replace '(\d{4})(\d{2})(\d{2})T(\d{2})(\d{2})(\d{2})Z', '$1.$2.$3 $4:$5:$6'

# Write back to file
Set-Content -Path $filePath -Value $content -NoNewline

Write-Host "Timestamp format updated successfully!"
Get-Content $filePath


Nice workaround. Thank you!:thanks:

[nalor]

For the past day running `FindVUK.exe synchronize` seems to download the entire KeyDB instead of an incremental update. Is this a known issue?

Running under Linux with Wine in case it makes a difference.

I'm sorry - I've changed something and did not notice that this resulted in a problem for FindVUK as the change itself was by design non-breaking ... but in the end it revealed a bug in FindVUK that exists since 2020: when it tries to read the http header "FVDB_ChangeDate" it does not search for an exact header of this name but instead just for a header that begins with this name .. and I added a new header "FVDB_ChangeDate_ISO" that includes the changedate as ISO8601 with a UTC timestamp ...
Finally I changed the order of the headers: first the UTC and next the other one - because FindVUK takes the last matching header.
The next release will fix the header-bug correctly.
In the meantime the changed order on the server fixed the problem a few hours ago.

Another finding: my change also removed a feature where I thought nobody is using it: to specify a relative delta date like "-1day" - this is also fixed again.

[Xuqiwu]

First time user of this tool.

DVDFab Passkey v9.4.7.8 Not Working

DVDFab 13.0.5.7 Working

[nalor]

First time user of this tool.

DVDFab Passkey v9.4.7.8 Not Working

DVDFab 13.0.5.7 Working

Your're right - Passkey support stopped at 9.4.5.2 a long time ago - I've updated the first post to show this.

[KH]

Hi nalor, I'm trying to update the keydb entry for All Quiet on the Western Front (0x9B55936E76E564DDEB69A363FB2654AD67651C03) but no changes are reflected in the public keydb. I haven't recently encountered this issue with any other title.

Any thoughts?

[SamuriHL]

I have that disc and tried doing a validate on it several times and while it shows that it uploaded the entry, it does not seem to be updating it.

[nalor]

Hi nalor, I'm trying to update the keydb entry for All Quiet on the Western Front (0x9B55936E76E564DDEB69A363FB2654AD67651C03) but no changes are reflected in the public keydb. I haven't recently encountered this issue with any other title.

Any thoughts?

I'm checking what is happening here.

It got uploaded the first time in 2023 with a unitkey labelled as "invalid" and although better uploads happened in the meantime, no update has been performed ... strange.

[nalor]

I'm checking what is happening here.

It got uploaded the first time in 2023 with a unitkey labelled as "invalid" and although better uploads happened in the meantime, no update has been performed ... strange.

Found the problem - "optimized" the processing too much, need to change that. When I detect that the old entry is already "validated" everything else is skipped... and this makes it impossible to add additional data with a manual validation :(

[KH]

Found the problem - "optimized" the processing too much, need to change that. When I detect that the old entry is already "validated" everything else is skipped... and this makes it impossible to add additional data with a manual validation :(

Thanks for following up nalor. The record for 0x9B5593... is now complete after resubmitting, so that is great to see.

Are you able to tell from your end whether any other titles may have encountered a similar issue? The original failed submission attempt for the full record of 0x9B5593... was 30 December 2024, so it seems possible that other titles may have been affected.

[nalor]

Thanks for following up nalor. The record for 0x9B5593... is now complete after resubmitting, so that is great to see.

Are you able to tell from your end whether any other titles may have encountered a similar issue? The original failed submission attempt for the full record of 0x9B5593... was 30 December 2024, so it seems possible that other titles may have been affected.

Found 3 other entries with "invalid" unitkeys, 2 of them being UHDs.

First I want to improve my fix a little bit further - and once this is done I'll check those 3 entries also.

[magician]

@nalor: While you're here, I wonder if you can take a look at the logic in the workarounds for the latest versions of DVDFab. I have found that in FindVUK >= 1.79 and DVDFab >= 13.0.2.5, on discs with bus encryption, it will sometimes locate the RDK in the memory dump and decide that it is also the first decrypted UnitKey. Since it is not the real UnitKey, it will fail to validate the disc. I often have to retry FindVUK several times before it succeeds. In every case I have seen, the value that it kept finding in the failed runs did turn out to be the correct RDK for my drive/disc. It just didn't identify the correct UnitKey.

I sent you a logfile for a similar report in 2024 by PM but you did not respond.

[nalor]

@nalor: While you're here, I wonder if you can take a look at the logic in the workarounds for the latest versions of DVDFab. I have found that in FindVUK >= 1.79 and DVDFab >= 13.0.2.5, on discs with bus encryption, it will sometimes locate the RDK in the memory dump and decide that it is also the first decrypted UnitKey. Since it is not the real UnitKey, it will fail to validate the disc. I often have to retry FindVUK several times before it succeeds. In every case I have seen, the value that it kept finding in the failed runs did turn out to be the correct RDK for my drive/disc. It just didn't identify the correct UnitKey.

I sent you a logfile for a similar report in 2024 by PM but you did not respond.

I'm sorry for not responding :(

The problem is already fixed in 1.83 and I'll published it now.

This is a release with fixes/improvements I've implemented in the last 12 months, but never managed to create a release.

After the fix of the problem above I've created the 1.83 and it's available for about 2 weeks - but I missed to post anything (so only a few users did test it so far).

But afaik it's working fine - so making it public now :)

Generally I wanted to finish another feature and publish a 1.84, but it's still in the works: in case the online db is not available it's retried for 60 seconds and afterwards the file is saved and when findvuk is started the next time, the transmission is retried again.

[Xuqiwu]

Have you already taken down v1.83 since i'm getting "503 Service Unavailable" all the time.

[Xuqiwu]

Link is working now, thank you.

[magician]

I'm sorry for not responding :(

The problem is already fixed in 1.83 and I'll published it now.

This is a release with fixes/improvements I've implemented in the last 12 months, but never managed to create a release.

After the fix of the problem above I've created the 1.83 and it's available for about 2 weeks - but I missed to post anything (so only a few users did test it so far).

But afaik it's working fine - so making it public now :)

Generally I wanted to finish another feature and publish a 1.84, but it's still in the works: in case the online db is not available it's retried for 60 seconds and afterwards the file is saved and when findvuk is started the next time, the transmission is retried again.

Thank you! And thanks also for the new release, glad you already fixed a number of bugs.

[nalor]

Have you already taken down v1.83 since i'm getting "503 Service Unavailable" all the time.

I don't think this is related to the new release ... the 503 problem is due to the load on the website in combination the free offer I'm using.

So usually it takes a few seconds/minutes and it's working again (in the kodi plugin I've released recently it retries every 10 seconds until it's succesful again).

[lamp]

I was able to capture the download for 1.83 in the internet archive in case anyone runs into issues in the future, just throw the download URL into the wayback machine

[coricopat]

@Nalor, maybe overkill, but the following might help with the site load:

- (you) generate a OpenPGP key and publish the public one as yours here
- then e.g. daily, or perhaps every few hours, sign the full keydb.cfg and XML archive ZIPs with your private key
- upload the ZIPs and their signatures to some file hoster which you can use anonymously (and script)
- continue to provide the full ZIPs at least for a while on the current website, remove that later should people still download manually from there)
- provide a txt file on that website (perhaps also signed) which names the current download place
- let tools merely download the link, get the files from there and let them verify the sigs with your public key

So people who do full downloads can do it from there, and not put load on the main site (which eventually, if necessary, might even be changed to delta only - and of course uploads).
You might even sign the FindVUK program package that way and move downloads somewhere else.

[MrPenguin]

The problem is already fixed in 1.83 and I'll published it now.

I've started seeing delta mode failing with FindVUK 1.83:

2026-03-30 12:05:25 # 373381 # [I] FindVUK_Main / FVMAIN_Mode_Synchronize / INFO! DeltaFile requested, but got full file - disable delta mode
2026-03-30 12:05:25 # 373383 # [I] FindVUK_Main / FVMAIN_Mode_Synchronize / #### Uncompress downloaded OnlineDB file ####

So I'm requesting the delta file, but sometimes getting the full file instead. Is anyone else seeing this?

[Xuqiwu]

For me the DeltaMode is working as expected with v1.83

[magician]

So I'm requesting the delta file, but sometimes getting the full file instead. Is anyone else seeing this?

I get frequent 503s when trying to access the site, so it may have been overloaded and/or not responding correctly.

Amusingly, I saw this in my log while running a delta sync (notice the progress percentage is wildly off due to the denominator being a lot less than what was supposedly fetched).
11:49:15 - Downloading OnlineDB - Progress: 56.51% - 16.46KB/29.12KB - Speed 33.64 KB/s
11:49:15 - Downloading OnlineDB - Progress: 173.50% - 50.53KB/29.12KB - Speed 69.50 KB/s
11:49:16 - Finished download of OnlineDB - received 62.35KB in 1,504 seconds

[magician]

A few bug reports I've been meaning to submit about ValidateDisc mode (ordered from most to least certain, as in how certain I am that you can reproduce it):
- It complains that MK+VID != VUK when VUK is empty, even though it's correctly computed and not actually cleared.
- If |UK|>1, it refuses to compute VUK from MK+VID (AACS unknown error).
- When configured not to exit after processing, it locks the keydb.cfg files. During subsequent validations in the same process, it may complain that files do not exist even though internally it is still holding onto the contents in memory and does not try to output an empty file. It also does not seem to work correctly (e.g. "Something went wrong enriching data!", does not update keydb_fvhash.ini, etc.).

[coopervid]

I've started seeing delta mode failing with FindVUK 1.83:

2026-03-30 12:05:25 # 373381 # [I] FindVUK_Main / FVMAIN_Mode_Synchronize / INFO! DeltaFile requested, but got full file - disable delta mode
2026-03-30 12:05:25 # 373383 # [I] FindVUK_Main / FVMAIN_Mode_Synchronize / #### Uncompress downloaded OnlineDB file ####

So I'm requesting the delta file, but sometimes getting the full file instead. Is anyone else seeing this?

I have the same issue. Synchronize just loads the full file.

[MrPenguin]

I have the same issue. Synchronize just loads the full file.
But not every time either! It currently appears to be random whether I receive the delta or not :confused:.

[coopervid]

But not every time either! It currently appears to be random whether I receive the delta or not :confused:.
Yap. Same here. Last run had 28 new entries and the one after that loads again the full database.

[metalsonic88]

This might be a stupid question, but historically I haven't paid much attention to the output/logs that are generated by FindVUK unless there is an issue. But lately I have been watching them a bit closer and I've noticed that every now and then a disc is coming up with no VUK, MEDIAKEY, or VOLUMEID, but no errors or warnings or anything happen and the verification continues as normal. Is that how things should work? Do some discs simply lack this information, or is something wrong here?

An example:

-----------------------------------------------------------
22:53:30 - ----------- FindVUK 1.83 -----------
-----------------------------------------------------------
To close FindVUK simply press the ESC key
-----------------------------------------------------------
22:53:30 - SettingsFile: >C:\{redacted}\FindVUK\config\FindVUK.ini<
22:53:30 - Logfile >C:\{redacted}\FindVUK\log\2026-03-31_FindVUK.txt< Default Loglevel >2<
22:53:30 - Update enabled - check for update
22:53:31 - No update required
22:53:31 - Open Main-KEYDB file: >C:\ProgramData\aacs\KEYDB.cfg<
22:53:33 - Open Backup-KEYDB file: >C:\{redacted}\FindVUK\VUKbackup\KEYDB.cfg<
22:53:33 - DVDfab Version >12.1.1.5< found
22:53:33 - >>> everything should work as expected!

22:53:33 - Preferred application >PassKey< is not available
22:53:33 - DVDfab is available!
22:53:33 - DVDfab-MainFile: >C:\Program Files\DVDFab\DVDFab 12\DVDFab64.exe<
22:53:33 - DVDfab-LogFile: >C:\Users\{redacted}\Documents\DVDFab\DVDFab12\Log\dvdfab_internal.log<
22:53:33 - KEYDB-Path: >C:\ProgramData\aacs\<
22:53:33 - KEYDB-Backup-Path: >C:\{redacted}\FindVUK\VUKbackup\<
22:53:33 - ProcDumpFile: >C:\{redacted}\FindVUK\tool\procdump64.exe<

###############################################################################
22:53:33 - --- PART 1 --- GET DUMP ---
-------------------------------------------------------------------------------

22:53:33 - No running application process discovered
22:53:33 - >> Start it now >C:\Program Files\DVDFab\DVDFab 12\DVDFab64.exe<

22:54:17 - Drive opened
22:54:17 - Volume Label detected >DEAR BROTHER DISC 2<
22:54:19 - DriveLetter detected >F<
22:54:19 - Detected CopyProtections AACS >1< BD+ >0<
22:54:19 - DiscID found >AD0274C51352D03668DC41A25200106720EB50F4<
22:54:22 - MainPlaylist found >00000.mpls<
22:54:22 - DVDFab64 got Unit Keys - create memdump now!
22:54:23 - Dump successful! >1<
22:54:23 - MemDump successfully finished!
22:54:23 - Cancel DVDfab decryption now!
-------------------------------------------------------------------------------
22:54:23 - Get basic AACS data
-------------------------------------------------------------------------------
22:54:23 - AACS folder >F:\AACS< on disc is reachable - Validate is possible
22:54:24 - VolumeName >DEAR BROTHER DISC 2<
22:54:24 - VolumeSize >46881177600<
22:54:24 - DiscId >AD0274C51352D03668DC41A25200106720EB50F4< (2021-03-07)
22:54:24 - DiscType >BD<
22:54:24 - MKB Revision >70<
22:54:24 - Disc-BusEncEnabled >0<
22:54:24 - Drve-BusEncCapable >1<
22:54:24 - UnitKeyCount >1<
22:54:24 - >>> UnitKeyENC (1) >5E8EEDE3CBA99D3B80533E75D3FD51F0<
-------------------------------------------------------------------------------
22:54:24 - Analyze dump
-------------------------------------------------------------------------------
22:54:24 - Start to analyze '2018' MemDump now!
..-...............................-
22:54:25 - DiscID >AD0274C51352D03668DC41A25200106720EB50F4<
22:54:25 - UnitKeyCount >1<
22:54:25 - >>> UnitKeyDEC (1) >CFB1F8EAA8F4BA50900B2E2D30230413<
-------------------------------------------------------------------------------
22:54:25 - --- PART 2 --- VALIDATE VUK/UNITKEYS ---
-------------------------------------------------------------------------------
22:54:25 - Drive is detected as 'REAL BLURAY' drive
22:54:25 - M2TS files found >19<
22:54:25 - Decrypted first unit of file >F:\BDMV\STREAM\00016.m2ts< with UnitKey >1<
22:54:25 - All UnitKeys are VALID! No need to test other files

-------------------------------------------------------------------------------
22:54:25 - Validation successful! UnitKeys are valid!!
-------------------------------------------------------------------------------

22:54:25 - Disc with ID >AD0274C51352D03668DC41A25200106720EB50F4< is already in file - need to compare the details
22:54:25 - -------------------------------------------------------
22:54:25 - MetaTitle : Dear Brother Disc 2
22:54:25 - VolumeName : DEAR BROTHER DISC 2
22:54:25 - DiscID : AD0274C51352D03668DC41A25200106720EB50F4
22:54:25 - DateDiscID : 2021-03-07
22:54:25 - DiscType : BD
22:54:25 - VUK :
22:54:25 - MEDIAKEY :
22:54:25 - VOLUMEID :
22:54:25 - >>> UnitKeyDEC (1) >CFB1F8EAA8F4BA50900B2E2D30230413< (Valid)
22:54:25 - MKBrev : 70
22:54:25 - BusEncrEn : 0
22:54:25 - AACS : 1
22:54:25 - BD+ : 0
22:54:25 - MainPlaylist: 00000.mpls
22:54:25 - -------------------------------------------------------


-------------------------------------------------------------------------------
22:54:25 - --- Write entry in main-keydb file ---
-------------------------------------------------------------------------------

22:54:25 - Keys in Keyfile: 179944 keys - KeyFile: C:\ProgramData\aacs\KEYDB.cfg
22:54:25 - Disc with ID >AD0274C51352D03668DC41A25200106720EB50F4< is already in file - need to compare the details

22:54:25 - KEYDB: Identical entry already present in keydb-file
22:54:25 - >> Identical: TITLE, VUK, DATE, MEDIAKEY, VOLUMEID, UNITKEYS, COMMENT - Different: nothing >> will NOT write new entry in keydb-file

22:54:25 - Identical entry already present in keydb-file - file is not changed


-------------------------------------------------------
22:54:25 - --- Write entry in backup-keydb file ---
-------------------------------------------------------

22:54:25 - Keys in Keyfile: 469 keys - KeyFile: C:\{redacted}\FindVUK\VUKbackup\KEYDB.cfg
22:54:25 - Disc with ID >AD0274C51352D03668DC41A25200106720EB50F4< is already in file - need to compare the details

22:54:25 - KEYDB: Identical entry already present in keydb-file
22:54:25 - >> Identical: TITLE, VUK, DATE, MEDIAKEY, VOLUMEID, UNITKEYS, COMMENT - Different: nothing >> will NOT write new entry in keydb-file

22:54:25 - Identical entry already present in keydb-file - file is not changed


-------------------------------------------------------
22:54:25 - --- Write entry in main-bluraydb file ---
-------------------------------------------------------

22:54:25 - Entries in DB-File: 303 entries - DB-File: C:\Users\{redacted}\AppData\Roaming\bluray\bluraydb.cfg

22:54:25 - Disc with ID >AD0274C51352D03668DC41A25200106720EB50F4< is already >1< times in the bluraydb-file
22:54:25 - -------------------------------------------------------
22:54:25 - BLURAYDB: Identical entry already present in bluraydb-file (line 302)

22:54:25 - Identical entry already present in bluraydb-file - file is not changed

22:54:25 - -------------------------------------------------------
22:54:25 - --- Upload MetaXML to OnlineDB file ---
22:54:25 - -------------------------------------------------------
Establishing connection
Establishing connection
HTTP-POST success
22:54:26 - Successfully posted to the OnlineDB! >
Preconditions fulfilled - process upload now
Detected BlurayMetaXML - DiscId >AD0274C51352D03668DC41A25200106720EB50F4<
Upload written to database!
Meta-Upload successfully processed!
<
22:54:26 - Successful upload to OnlineDB
22:54:26 - Eject the disc now from drive >F:\<

22:54:30 - Successfully ejected the media in drive F!

[MrPenguin]

Yap. Same here. Last run had 28 new entries and the one after that loads again the full database.
This isn't an "April 1st" joke, but it looks like there a "Content-Length" HTTP header missing:

2026-04-01 15:06:11 # 8743 # [I] FindVUK_Main / FVMAIN_Mode_Synchronize / Hash identical - DeltaMode enabled with date >20260401t135309<
2026-04-01 15:06:11 # 8745 # [I] FindVUK_Main / FVMAIN_Mode_Synchronize / #### Download from OnlineDB ####
2026-04-01 15:06:11 # 8745 # [I] FindVUK_Main / DownloadFile / Establishing connection
2026-04-01 15:06:11 # 9247 # [W] FindVUK_Main / DownloadFile / ContentSize unknown >-1802< (#HTTPA_ERR_HEADERNOTFOUND)
2026-04-01 15:06:11 # 9247 # [I] FindVUK_Main / DownloadFile / Downloading - Filename >KeyDbDelta.cfg< Filesize >-1802< Filedate >2026.04.01 15:38:50<
2026-04-01 15:06:11 # 9247 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -962.1% - 16.93KB/-1802 B - Speed 34.54 KB/s
2026-04-01 15:06:12 # 9751 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -962.1% - 16.93KB/-1802 B - Speed 0.00 Byte/s
2026-04-01 15:06:12 # 10253 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -2007.% - 35.34KB/-1802 B - Speed 37.54 KB/s
2026-04-01 15:06:13 # 10757 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -2007.% - 35.34KB/-1802 B - Speed 0.00 Byte/s
2026-04-01 15:06:13 # 11261 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -3003.% - 52.86KB/-1802 B - Speed 35.60 KB/s
2026-04-01 15:06:14 # 11763 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -3003.% - 52.86KB/-1802 B - Speed 0.00 Byte/s
2026-04-01 15:06:14 # 12266 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -4020.% - 70.75KB/-1802 B - Speed 36.41 KB/s
2026-04-01 15:06:15 # 12769 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -4020.% - 70.75KB/-1802 B - Speed 0.00 Byte/s
2026-04-01 15:06:15 # 13271 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -5048.% - 88.84KB/-1802 B - Speed 36.92 KB/s
2026-04-01 15:06:16 # 13773 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -5770.% - 101.55KB/-1802 B - Speed 25.92 KB/s
2026-04-01 15:06:16 # 14275 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -5770.% - 101.55KB/-1802 B - Speed 0.00 Byte/s
2026-04-01 15:06:17 # 14778 # [I] FindVUK_Main / DownloadFile / Received a HTTP 200 - save response now
2026-04-01 15:06:17 # 14781 # [I] FindVUK_Main / DownloadFile / Finished download of OnlineDB - received 101.55KB in 6,033 seconds

[lamp]

This might be a stupid question, but historically I haven't paid much attention to the output/logs that are generated by FindVUK unless there is an issue. But lately I have been watching them a bit closer and I've noticed that every now and then a disc is coming up with no VUK, MEDIAKEY, or VOLUMEID, but no errors or warnings or anything happen and the verification continues as normal. Is that how things should work? Do some discs simply lack this information, or is something wrong here?

An example:

-------------------------------------------------------------------------------
22:54:23 - Get basic AACS data
-------------------------------------------------------------------------------
22:54:23 - AACS folder >F:\AACS< on disc is reachable - Validate is possible
22:54:24 - VolumeName >DEAR BROTHER DISC 2<
22:54:24 - VolumeSize >46881177600<
22:54:24 - DiscId >AD0274C51352D03668DC41A25200106720EB50F4< (2021-03-07)
22:54:24 - DiscType >BD<
22:54:24 - MKB Revision >70<
22:54:24 - Disc-BusEncEnabled >0<
22:54:24 - Drve-BusEncCapable >1<
22:54:24 - UnitKeyCount >1<
22:54:24 - >>> UnitKeyENC (1) >5E8EEDE3CBA99D3B80533E75D3FD51F0<
-------------------------------------------------------------------------------
22:54:24 - Analyze dump
-------------------------------------------------------------------------------
22:54:24 - Start to analyze '2018' MemDump now!
..-...............................-
22:54:25 - DiscID >AD0274C51352D03668DC41A25200106720EB50F4<
22:54:25 - UnitKeyCount >1<
22:54:25 - >>> UnitKeyDEC (1) >CFB1F8EAA8F4BA50900B2E2D30230413<


My understanding is that DVDFab only loads the Unit Keys into memory so the memdump is only able to extract that. This is technically all that would be needed to be decrypt a disc (as most of the other keys are used to end up derive/decrypt the unit keys), however some software (such as MakeMKV) may also want the VUK. Unfortuantely with the just the Unit Keys I don't think there is a way to work backwards to get any of the other keys. Since this is technically all that is needed for libaacs I don't think there are any issues here.

If you have a drive that has not seen a MKBv82 disc then you can use Device keys and Host Certificates from other threads and use .\FindVUK.exe aacskeys=<drive> in order to have it actually calculate the keys and it will populate everything, however if you have ever put a MKBv82 disc in then we don't have a valid host certificate so you would need to do extra steps to try and calculate everything. The logs will tell you if it has been revoked already. This method does not work on AACS 2.0 discs (4k UHD Blu-Rays).

[nalor]

This isn't an "April 1st" joke, but it looks like there a "Content-Length" HTTP header missing:

2026-04-01 15:06:11 # 8743 # [I] FindVUK_Main / FVMAIN_Mode_Synchronize / Hash identical - DeltaMode enabled with date >20260401t135309<
2026-04-01 15:06:11 # 8745 # [I] FindVUK_Main / FVMAIN_Mode_Synchronize / #### Download from OnlineDB ####
2026-04-01 15:06:11 # 8745 # [I] FindVUK_Main / DownloadFile / Establishing connection
2026-04-01 15:06:11 # 9247 # [W] FindVUK_Main / DownloadFile / ContentSize unknown >-1802< (#HTTPA_ERR_HEADERNOTFOUND)
2026-04-01 15:06:11 # 9247 # [I] FindVUK_Main / DownloadFile / Downloading - Filename >KeyDbDelta.cfg< Filesize >-1802< Filedate >2026.04.01 15:38:50<
2026-04-01 15:06:11 # 9247 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -962.1% - 16.93KB/-1802 B - Speed 34.54 KB/s
2026-04-01 15:06:12 # 9751 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -962.1% - 16.93KB/-1802 B - Speed 0.00 Byte/s
2026-04-01 15:06:12 # 10253 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -2007.% - 35.34KB/-1802 B - Speed 37.54 KB/s
2026-04-01 15:06:13 # 10757 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -2007.% - 35.34KB/-1802 B - Speed 0.00 Byte/s
2026-04-01 15:06:13 # 11261 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -3003.% - 52.86KB/-1802 B - Speed 35.60 KB/s
2026-04-01 15:06:14 # 11763 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -3003.% - 52.86KB/-1802 B - Speed 0.00 Byte/s
2026-04-01 15:06:14 # 12266 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -4020.% - 70.75KB/-1802 B - Speed 36.41 KB/s
2026-04-01 15:06:15 # 12769 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -4020.% - 70.75KB/-1802 B - Speed 0.00 Byte/s
2026-04-01 15:06:15 # 13271 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -5048.% - 88.84KB/-1802 B - Speed 36.92 KB/s
2026-04-01 15:06:16 # 13773 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -5770.% - 101.55KB/-1802 B - Speed 25.92 KB/s
2026-04-01 15:06:16 # 14275 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -5770.% - 101.55KB/-1802 B - Speed 0.00 Byte/s
2026-04-01 15:06:17 # 14778 # [I] FindVUK_Main / DownloadFile / Received a HTTP 200 - save response now
2026-04-01 15:06:17 # 14781 # [I] FindVUK_Main / DownloadFile / Finished download of OnlineDB - received 101.55KB in 6,033 seconds



Hmm - maybe I've damaged something ... either in 1.83 or on the website .. .I'm currently adding php7 type declarations to the code and sometimes I get strange results :D

Give me a minute, I'll check on my side.

[nalor]

What I can say so far: the Content Length header is missing because the server uses chunked transfer. The progress display in FindVUK needs this header, so the progress is way off.
But in general it should download the correct file and also sync properly ...

Will fix it tomorrow .. sorry :(

[MrPenguin]

What I can say so far: the Content Length header is missing because the server uses chunked transfer. The progress display in FindVUK needs this header, so the progress is way off.
But in general it should download the correct file and also sync properly ...

Will fix it tomorrow .. sorry :(
OK, that makes sense, thanks. Can you also see why a "delta mode" request is sometimes receiving the full file please?

[nalor]

OK, that makes sense, thanks. Can you also see why a "delta mode" request is sometimes receiving the full file please?

I'm trying to fix all bugs recently introduced :( Not sure if it was a good idea to add the type declarations .. but I thought it might be a good idea to modernize the code a little bit ...

[SamuriHL]

I'm trying to fix all bugs recently introduced :( Not sure if it was a good idea to add the type declarations .. but I thought it might be a good idea to modernize the code a little bit ...

The curse of every developer, sadly. No good dead goes unpunished. :D

[coopervid]

The curse of every developer, sadly. No good dead goes unpunished. :D

Deed you mean. You can't punish deads.:sly:

[SamuriHL]

Deed you mean. You can't punish deads.:sly:

You never know :D

[nalor]

"Progress" Bug is fixed, finally understood why it's happening (although I don't understand why the behaviour changed):

I didn't compress the delta-files but always delivered them as play .cfg file

=> in this case Apache performs an on-the-fly compression and as it does not know the final number of bytes to transfer, the whole transfer is done as "chunked" transfer and no content-length is available to the client receiving the data.

So I've changed this to compress the file always into a zip file and so the content-length is present again :)
(And FindVUK knows how to uncompress and use the file)


Now I'm checking the next problem: the frequent full-download.

This is something that I have somehow introduced with my changes for the KODI plugin... the requested timestamp is detected as being in the future and in this case the full-file is delivered as no delta is possible.

Hve to check why this is happening.

[nalor]

"Full" instead of "Delta" problem should be fixed too .. I defined the wrong timezone in the settings and as result the comparison of delta-time and "now" was 1h off since the switch to summertime in central europe ... now the timezone matches the regional one and the result looks good in my tests :)
(and fixed another problem introduced with the type declarations ... )

[SamuriHL]

Nice that should make things more stable.

[metalsonic88]

If you have a drive that has not seen a MKBv82 disc then you can use Device keys and Host Certificates from other threads and use .\FindVUK.exe aacskeys=<drive> in order to have it actually calculate the keys and it will populate everything, however if you have ever put a MKBv82 disc in then we don't have a valid host certificate so you would need to do extra steps to try and calculate everything. The logs will tell you if it has been revoked already. This method does not work on AACS 2.0 discs (4k UHD Blu-Rays).


I'm near certain that my drive has seen an MKBv82 disc and thus this method will not work, but FindVUK sure isn't interested in telling me anything either way.

This is the output from the same disc as earlier:

-----------------------------------------------------------
20:31:05 - ----------- FindVUK 1.83 -----------
-----------------------------------------------------------
To close FindVUK simply press the ESC key
-----------------------------------------------------------
20:31:05 - MODE: AACSkeys

20:31:05 - DriveLetter : F

20:31:05 - SettingsFile: >C:\{redacted}\FindVUK\config\FindVUK.ini<
20:31:05 - Logfile >C:\{redacted}\FindVUK\log\2026-04-03_FindVUK.txt< Default Loglevel >2<
20:31:05 - Update enabled - check for update
20:31:06 - Update check failed >#UPD_ERR_READFILE<
20:31:06 - Open Main-KEYDB file: >C:\ProgramData\aacs\KEYDB.cfg<
20:31:08 - Open Backup-KEYDB file: >C:\{redacted}\FindVUK\VUKbackup\KEYDB.cfg<
20:31:08 - Driveletter for AACSkeys set to >F<

###############################################################################
20:31:08 - --- PART 1 --- GET AACSKEYS DATA ---
-------------------------------------------------------------------------------


And that's it. It crashes or something when it reaches Part 1 without any further message or error. I can't imagine this is intended behavior.

[lamp]

And that's it. It crashes or something when it reaches Part 1 without any further message or error. I can't imagine this is intended behavior.

That looks like the behavior when you have a 4k disc in, which uses AACS 2.0, the aacskeys program is kind of old so it seems to break on that. Usually for normal blu-rays I see it printing the host certificate and saying that it was revoked on this drive or something similar. Just to confirm, is that a normal blu-ray? or a UHD one?

[MrPenguin]

"Progress" Bug is fixed, finally understood why it's happening (although I don't understand why the behaviour changed):

Hmm, this download progress is still broken:

...
2026-04-04 16:11:16 # 8663 # [I] FindVUK_Main / FVMAIN_Mode_Synchronize / Hash identical - DeltaMode enabled with date >20260404t112124<
2026-04-04 16:11:16 # 8664 # [I] FindVUK_Main / FVMAIN_Mode_Synchronize / #### Download from OnlineDB ####
2026-04-04 16:11:16 # 8665 # [I] FindVUK_Main / DownloadFile / Establishing connection
2026-04-04 16:11:16 # 9166 # [W] FindVUK_Main / DownloadFile / ContentSize unknown >-1802< (#HTTPA_ERR_HEADERNOTFOUND)
2026-04-04 16:11:16 # 9167 # [I] FindVUK_Main / DownloadFile / Downloading - Filename >KeyDbDelta.zip< Filesize >-1802< Filedate >2026.04.04 16:48:27<
2026-04-04 16:11:16 # 9167 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -449.0% - 7.90KB/-1802 B - Speed 16.15 KB/s
2026-04-04 16:11:17 # 9669 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -449.0% - 7.90KB/-1802 B - Speed 0.00 Byte/s
2026-04-04 16:11:17 # 10171 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -898.2% - 15.81KB/-1802 B - Speed 16.13 KB/s
2026-04-04 16:11:18 # 10674 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -898.2% - 15.81KB/-1802 B - Speed 0.00 Byte/s
2026-04-04 16:11:18 # 11176 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -1347.% - 23.71KB/-1802 B - Speed 16.13 KB/s
2026-04-04 16:11:19 # 11678 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -1347.% - 23.71KB/-1802 B - Speed 0.00 Byte/s
2026-04-04 16:11:19 # 12180 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -1796.% - 31.62KB/-1802 B - Speed 16.13 KB/s
2026-04-04 16:11:20 # 12682 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -2245.% - 39.52KB/-1802 B - Speed 16.12 KB/s
2026-04-04 16:11:20 # 13185 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -2245.% - 39.52KB/-1802 B - Speed 0.00 Byte/s
2026-04-04 16:11:21 # 13687 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -2245.% - 39.52KB/-1802 B - Speed 0.00 Byte/s
2026-04-04 16:11:21 # 14190 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -2695.% - 47.43KB/-1802 B - Speed 16.10 KB/s
2026-04-04 16:11:22 # 14693 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -3144.% - 55.33KB/-1802 B - Speed 16.10 KB/s
2026-04-04 16:11:22 # 15197 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -3144.% - 55.33KB/-1802 B - Speed 0.00 Byte/s
2026-04-04 16:11:23 # 15700 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -3593.% - 63.24KB/-1802 B - Speed 16.10 KB/s
2026-04-04 16:11:23 # 16203 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -3593.% - 63.24KB/-1802 B - Speed 0.00 Byte/s
2026-04-04 16:11:24 # 16705 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -4042.% - 71.14KB/-1802 B - Speed 16.12 KB/s
2026-04-04 16:11:24 # 17208 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -4042.% - 71.14KB/-1802 B - Speed 0.00 Byte/s
2026-04-04 16:11:25 # 17711 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -4523.% - 79.60KB/-1802 B - Speed 17.21 KB/s
2026-04-04 16:11:25 # 18213 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -4523.% - 79.60KB/-1802 B - Speed 0.00 Byte/s
2026-04-04 16:11:26 # 18716 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -4972.% - 87.50KB/-1802 B - Speed 16.10 KB/s
2026-04-04 16:11:26 # 19217 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -4972.% - 87.50KB/-1802 B - Speed 0.00 Byte/s
2026-04-04 16:11:27 # 19720 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -5421.% - 95.41KB/-1802 B - Speed 16.13 KB/s
2026-04-04 16:11:27 # 20223 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -5421.% - 95.41KB/-1802 B - Speed 0.00 Byte/s
2026-04-04 16:11:28 # 20726 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -5870.% - 103.32KB/-1802 B - Speed 16.10 KB/s
2026-04-04 16:11:28 # 21228 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -5870.% - 103.32KB/-1802 B - Speed 0.00 Byte/s
2026-04-04 16:11:29 # 21730 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -6346.% - 111.68KB/-1802 B - Speed 17.06 KB/s
2026-04-04 16:11:29 # 22233 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -6346.% - 111.68KB/-1802 B - Speed 0.00 Byte/s
2026-04-04 16:11:30 # 22734 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -6722.% - 118.30KB/-1802 B - Speed 13.54 KB/s
2026-04-04 16:11:30 # 23237 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -6722.% - 118.30KB/-1802 B - Speed 0.00 Byte/s
2026-04-04 16:11:31 # 23739 # [I] FindVUK_Main / DownloadFile / Received a HTTP 200 - save response now
2026-04-04 16:11:31 # 23742 # [I] FindVUK_Main / DownloadFile / Finished download of OnlineDB - received 118.30KB in 15,074 seconds
2026-04-04 16:11:31 # 23743 # [I] FindVUK_Main / DownloadFile / Return result >1<
2026-04-04 16:11:31 # 23744 # [I] FindVUK_Main / FVMAIN_Mode_Synchronize / #### Uncompress downloaded OnlineDB file ####
2026-04-04 16:11:31 # 23756 # [I] FindVUK_Main / FVMAIN_Mode_Synchronize / #### Open downloaded OnlineDB file ####
...

[metalsonic88]

Just to confirm, is that a normal blu-ray? or a UHD one?

It is a normal blu ray.

[nalor]

Hmm, this download progress is still broken:


You're right - I'll create a support ticket for the provider because I have no further ideas, whatever I try to disable the Apache compression is ignored :(

[nalor]

For information: I've upgraded the account and hopefully it's more stable now (at least for the next 12 months :D ).

But this also introduces an automatic redirect from http to https ... hopefully this does not introduce another level of problems ....

[magician]

For information: I've upgraded the account and hopefully it's more stable now (at least for the next 12 months :D ).

But this also introduces an automatic redirect from http to https ... hopefully this does not introduce another level of problems ....

Website is lightning fast now. Plus no more HTTPS confusion. Thank you!

[nalor]

I noticed my KODI plugin stopped working and after some hours of digging I noticed it's a bug in PHP 8.5:
https://github.com/php/php-src/issues/21018

I wasn't aware of this "replace" feature at all - but setting it to "false" helps.

(and I've learned that underscores in headers are against the rules...)

And I disabled the redirection from HTTP to HTTPS .. so HTTPS is working, but requires to adjust the urls.

[metalsonic88]

Any chance you have done or could do a bit of digging into my aacskeys issue from earlier? Like I said, I'm reasonably confident that this method won't actually work for getting keys in my case, but a bit of output actually saying what went wrong would clarify that.