Dump Submitted - Disney's Snow White 2025 4K UHD TGZ Key File

[FootFungus07]

Well... someone had to do it.
Disney's Snow White TGZ Key File:
MKB20_v77_SNOW_WHITE_6B6E.tgz

[MrPenguin]

Well... someone had to do it.

Do you expect an apple...?

[keydb_helper]

Well... someone had to do it.
Disney's Snow White TGZ Key File:
MKB20_v77_SNOW_WHITE_6B6E.tgz

Thanks for making a suitable disc dump file available. The 6B6E variant of Snow White has been added to the public keydb.

I feel like this will mostly benefit folks making 4K memes but there may be some people watching the actual movie...

[j_F_S]

I got a copy with AACS Version 82.
I also submitted the zgz to the svq mail.

[miket]

The 9E92 variant of Snow White has also been added to the public keydb.

[MrPenguin]

The 9E92 variant of Snow White has also been added to the public keydb.

Actually, that entry doesn't check out. The 6B6E variant is MKBv77 whereas the 9E92 variant is MKBv82, which means that the two disks will have different Media Keys, and hence the computed VUK must be wrong .

[miket]

Ok, I‘m sorry. I see the Unitkey is invalid. I still have to learn. So you have to wait a liitle bit longer.

[SamuriHL]

When invalid entries, especially ones that contain a media key and VUK, have been added to the keydb, it makes it INCREDIBLY difficult to fix them. Basically a corrected entry has to be given to the person who has the disc, they have to overwrite the entry in their local keydb.cfg file, and then run findvuk's validate on the disc. It's the only way to fix them. Validating the unit keys BEFORE adding an entry is really the only safe way to do it.

[j_F_S]

Is there a way I can help with fixing the issue?

[j_F_S]

The 9E92 variant of Snow White has also been added to the public keydb.

Actually, that entry doesn't check out. The 6B6E variant is MKBv77 whereas the 9E92 variant is MKBv82, which means that the two disks will have different Media Keys, and hence the computed VUK must be wrong .

I read your private message but can't answer due to my account being new.
I replaced the line in my local keydb.cfg copy but validating still fails.
If you need any screenshots let me know.

[MrPenguin]

I replaced the line in my local keydb.cfg copy but validating still fails.
If you need any screenshots let me know.

Are you using SamuriHL's utility? You might also have multiple copies of the KEYDB.cfg file. FindVUK downloads its own copy, and then I think SamuriHL's tool copies it into MakeMKV's data directory (i.e. where MakeMKV also writes its TGZ dump file). You need to edit the KEYDB.cfg file that FindVUK is using.

[SamuriHL]

That's correct. I use findvuk to sync the keydb and then copy it to the makemkv data directory after the sync. If you change it manually don't sync again until you test it as it'll overwrite the entry if you modified the makemkv copy.

If you modify the version that findvuk downloads in your roaming/aacs directory do not sync again until you've validated it because it will upload it to the keydb which isn't good if it's not been validated. That's a findvuk thing and nothing I can really control.

Sent from my SM-S938U1 using Tapatalk

[j_F_S]

I now successfully validated the disk with the KEYDB line MrPenguin provided me.

I copied the keydb file to the makmkv data folder (and renamed it to KEYDB) but am still not able to decrypt the disc. Am I missing something?

[MrPenguin]

I copied the keydb file to the makmkv data folder (and renamed it to KEYDB) but am still not able to decrypt the disc. Am I missing something?

Maybe execute "findvuk synchronize" again? That line was only designed to remove the incorrect data from the KEYDB database, and was not sufficient for MakeMKV to decrypt your disk.

[j_F_S]

Yeah it worked. Thank you. Glad I could help to add a new disk with a 2/10 Rating on IMDB