Submit AAC v82 dump, Mecha-Ude Vol.4 JPN

[Keloid]

Already emailed svq@makemkv.com but just in case.

[MrPenguin]

Already emailed svq@makemkv.com but just in case.

Have you tried running SamuriHL's KEYDB Helper tool for this disk?

I understand that SamuriHL has also recently added a "validate disc" option...

[Keloid]

No. The issue, what i doubt, is that aacskeys do not return valid keys when VID start with 0x00. The given VID is 009BF53E840944CA2C4CEBFB94129889 but aacskeys change it to 9BF53E840944CA2C4CEBFB9412988900 arbitrarily and then calc it.

I really hope if somebody able to troubleshooting this. Before this specific VID begin with 0x00, i didn't have problem to calc v82 keys by my own.

[MrPenguin]

I really hope if somebody able to troubleshooting this. Before this specific VID begin with 0x00, i didn't have problem to calc v82 keys by my own.

There are only two ways to fix an incorrect KEYDB entry:

• Ask the DB maintainer to fix it manually.
• Execute "findvuk validateDisc drive=<your drive letter>" to upload a validated replacement entry.

If you own the physical disk then executing "findvuk validateDisc" is much, much faster.

[Keloid]

I just did it and obviously It's invalid. I don't see the point.

[MrPenguin]

I just did it and obviously It's invalid. I don't see the point.

Did you execute "findvuk synchronize" first?

But the point is that since you own this physical disk, you are the best person to fix this disk's entry. "findvuk validateDisc" wants to validate the Volume Unique Key (VUK) and/or the Unit Keys(s) in a KEYDB entry, so you need to add the correct value for at least one of these keys into KEYDB.cfg, remove any keys that you know are incorrect, and then execute "findvuk validateDisc" again. This will then replace the current incorrect entry with a validated entry.

"validateDisc" is also a good way to ensure that the keys you upload are correct. However, this means that it will only upload values that it can prove are correct. The only way to prove that a VID or a MK is correct is to use it to calculate a working VUK, which in turn means that a verifiable KEYDB entry would need to contain either both VID and MK, or neither VID nor MK.

[SamuriHL]

I'm not sure what my tool will do in this case. The info is complete but wrong. I'm not sure I handle that case at the moment. I need to think about that as it's a lot more common than any of us would like and the VUK is recalculated. But I don't think I check it against the keydb entry to see if it's different and probably should. Then we can fix this kind of crap more easily.

EDIT: Also if somehow the entry that's in the keydb is already "validated" status, then the KeyDB will create a new entry which causes problems. Nalor had to deal with this a few weeks ago on someone else's entry. It's a bit ugly.

[MrPenguin]

I'm not sure what my tool will do in this case. The info is complete but wrong.

Looking at that entry, it's missing its MK but I think the VID is correct. However, I don't believe FindVUK can validate a VID without also having the MK.

I suggest deleting both the VID and VUK values from that KEYDB entry, and then re-executing "findvuk validateDisc".

[SamuriHL]

Looking at that entry, it's missing its MK but I think the VID is correct. However, I don't believe FindVUK can validate a VID without also having the MK.

I suggest deleting both the VID and VUK values from that KEYDB entry, and then re-executing "findvuk validateDisc".

For blu-ray, I recalculate the MK, VID, VUK, and UKs anyway assuming they provide a valid device key in their local keydb. What I didn't do in this case when there's a discrepancy is recreate the keydb entry. That needs to happen before the validate disc is executed. It's a fairly simple code change but I likely won't get to it today as I've had a VERY long day already. But I will update it hopefully tomorrow to do this. Then it'll fix these kinds of issues.

[Keloid]

I think I made it. I assumed given MK, ViD, Enc Unit Keys are valid then re-compute them by openssl and xor manually. I guess this is a bug of aacskeys. aacskeys simply do not pop valid key set out for this specific BD - and as I said above this issue occurs when ViD start with 0x00.

[SamuriHL]

It's likely aacskeys is doing some trimming when it starts with 00 which would indeed be a bug.

Sent from my SM-S938U1 using Tapatalk

[MrPenguin]

I think I made it. I assumed given MK, ViD, Enc Unit Keys are valid then re-compute them by openssl and xor manually.

In the interest of fixing this KEYDB entry, could you try the following please?

• Execute "findvuk synchronize"
• Edit this disk's entry to remove both its VID and VUK, and leaving its Unit Key.
• Execute "findvuk validateDisc drive=<your-drive-letter>"

I suspect this Unit Key is correct, and hope that this will prove it.

[nalor]

And just in case the "validatedisc" does not deliver the expected result it would be great to get the logfile to check what's going wrong.

Thanks!

(This disc is not flagged as "validated" in the database so it should be easily fixable with a "validatedisc" execution, when the data in the keydb is correct).

(And yes, I could correct it easily directly in the db - but in the long run it's better to check why "validatedisc" does not work as expected to avoid the need for constant manual adjustments).

[MrPenguin]

(And yes, I could correct it easily directly in the db - but in the long run it's better to check why "validatedisc" does not work as expected to avoid the need for constant manual adjustments).

In this case, I suspect "validateDisc" did not work because the VUK value in the KEYDB entry being validated was incorrect.

[SamuriHL]

Yea, and my tool will be able to correct that and run findvuk's validate disc when I get a chance to update it. I can update the keydb entry easy enough and kick off the validate disc function. I just need a few minutes to update the code to do so when they don't match and I've internally validated that I have the correct data.