E.T. extra-terrestrial UHD disk (ET40TH_UPK5) : never stop analysing the disk, too many sync errors

[tomty89]

Hmm, that's somewhat weird, as in, encrypted backup produced by MakeMKV should have no bus encryption applied. (At the very least, otherwise MakeMKV should tell you that the M2TS files obtained are corrupted or so as it should verify them against the hashes.)

Some USB adapters are known have problem accepting/passing the LibreDrive-related SCSI commands to the drive, which result in failure in disabling bus encryption. I have no idea whether it's "expected" that they would work occasionally though.

(Maybe sometimes some sort of "reset" would occur which "invalidate" the effect of the LibreDrive commands?)

Either way, I guess in this case you should try to open the "good" encrypted backup with MakeMKV (or play it with VLC using libmmbd). Maybe now it would work fine?

---

For libaacs to work with it, you'd need to get an entry added to the KeyDB through the "usual procedure" (posting some dump to the respective thread; idk).

The thing is with the current issue, I'm not sure if it's "safe" to do so (like I don't know if whatever dump needed can be made correctly when bus encryption is not disabled successfully or so).

(EDIT: I mentioned VID in discatt.dat earlier but it's actually somewhat irrelevant in the case of UHD BD / AACS 2.0 -- as in, the VID is not enough for libaacs to handle the encryption.)

[YannArtoie]

Thanks, this actually helped narrow things down quite a bit.

You were right about the USB/bus encryption part.

After completely power-cycling the Pioneer drive, I was finally able to create an encrypted MakeMKV backup that passes XReveal's Content Hash Verifier without any mismatches.

So it looks like my earlier encrypted backups were indeed affected by the drive or bus-encryption state.

However, I then opened this known-good encrypted backup directly in MakeMKV, and unfortunately the result is exactly the same as with the original disc.

MakeMKV never reaches the title list, reports the same hash/AV synchronization errors, and eventually loops indefinitely.

I then went one step further: I completely disconnected the Pioneer drive and repeated the test using only the verified encrypted backup stored on the hard drive.

MakeMKV reports that no optical drives are present, opens the backup from disk, and reproduces exactly the same behaviour. It outputs the same sequence of "tp=" debug lines and eventually gets stuck during analysis.

So the issue is now fully reproducible from a static encrypted backup that has already been verified successfully with XReveal's Content Hash Verifier. At this point, neither the optical drive, the USB bridge nor the current LibreDrive state are involved anymore.

I also followed your bluraybackup suggestion.

I modified the source to allow opening a backup directory instead of only a block device, and successfully compiled it on macOS.

With this modification, bluraybackup does open the encrypted MakeMKV backup, but it immediately stops inside libaacs with:


Error calculating media key. Missing right processing key?
AACS handled: no
(no matching processing key)
Unsupported AACS encoding.


So I could not continue that test any further because libaacs itself cannot decrypt this title without a matching key.

At this point, the remaining issue appears to be entirely reproducible from a verified encrypted backup, independently of the optical drive itself.

[tomty89]

viewtopic.php?t=38293

I don't know if there's a better way to get the required disc dump when there's seemingly key for the title in the Hashed Keys, but I suppose you can at least remove them and untick "enable internet access" in Preferences. (Make sure you restart MakeMKV then before you open the disc to get the dump produced.)

Not really sure where they are saved in macOS. Maybe also ~/.MakeMKV like in Linux? (There would be a _private_data.tar which contains the Hashed Keys and other stuff.)

[keydb_helper]

I don't know if there's a better way to get the required disc dump when there's seemingly key for the title in the Hashed Keys, but I suppose you can at least remove them and untick "enable internet access" in Preferences. (Make sure you restart MakeMKV then before you open the disc to get the dump produced.)

Not really sure where they are saved in macOS. Maybe also ~/.MakeMKV like in Linux? (There would be a _private_data.tar which contains the Hashed Keys and other stuff.)

I posted a brief guide on generating your own disc dump file here: Link

If a protected (non-decrypted) backup has already been made it will have everything required to produce a synthetic disc dump file.

Trashing the private data and disabling internet access won't be enough to force MakeMKV to generate a complete disc dump file for an arbitrary AACS 2.x disc.

[tomty89]

Trashing the private data and disabling internet access won't be enough to force MakeMKV to generate a complete disc dump file for an arbitrary AACS 2.x disc.

Hmm, I thought a dump will be made as long as MakeMKV has no key to decrypt a disc. (And unlike AACS 1.0, MakeMKV cannot "synthesize" the VUK using VID obtained through LibreDrive.) Do you mean like the dump could be incomplete anyway Particularly, are you referring to something other than:

If your disc dump is less than 1MB, you will need to manually include the MKB_RO.inf file when uploading your disc dump file.

Btw, I saw:

FindVUK on Windows can also be used to generate MKBv1-MKBv81 AACS 1.0 disc keys without MakeMKV or any other commercial tool as long as your drive hasn't been exposed to AACS MKBv82

I thought FindVUK uses the host cert/key from KeyDB which is revoked in MKBv72. Does it really have a "newer" one (that is revoked in MKBv82) embedded in itself?

[keydb_helper]

Hmm, I thought a dump will be made as long as MakeMKV has no key to decrypt a disc. (And unlike AACS 1.0, MakeMKV cannot "synthesize" the VUK using VID obtained through LibreDrive.) Do you mean like the dump could be incomplete anyway

I was strictly referring to full disc dumps. MakeMKV has a bundled list of disc/key identifiers which is checked before creating a full vs partial disc dump file. This check is independent of the private data contents.

I thought FindVUK uses the host cert/key from KeyDB which is revoked in MKBv72. Does it really have a "newer" one (that is revoked in MKBv82) embedded in itself?

FindVUK has no special embedded keys or certs. The latest publicly available host cert is still valid in MKBv81 (revoked in MKBv82). Look for 0x0203005CFFFF80000217... in the Doom9 thread Up to MKB v68 KEYDB.cfg file. This HC had a funny history as it was revoked in MKBv76, unrevoked in MKBv81, and then revoked again in MKBv82.

There are a few fun alternatives to host certificates that will be available at some point.

[tomty89]

MakeMKV has a bundled list of disc/key identifiers which is checked before creating a full vs partial disc dump file. This check is independent of the private data contents.

Interesting.

This HC had a funny history as it was revoked in MKBv76, unrevoked in MKBv81, and then revoked again in MKBv82.

Odd. Didn't know that's even technically possible.

There are a few fun alternatives to host certificates that will be available at some point.

Hmm, other than LibreDrive?